CN109857898A - 一种海量数字音频指纹存储与检索的方法及系统 - Google Patents

Abstract

本发明公开了一种海量数字音频指纹存储与检索的方法，包括数字音频指纹存储和数字音频指纹检索两个步骤，数字音频指纹存储包括：将待存储音频文件Hash处理，获得每个音频文件的唯一标识；提取出待存储音频文件的音频指纹，每个音频文件的音频指纹构造成一个字符串；将每个待处理音频文件Hash后得到的标识作为Hbase的Rowkey，指纹字符串作为一个列的值，meta信息作为另一个列的值，写入Hbase的表中并写入Hbase；将每个待处理音频文件Hash后得到到标识和指纹字符串作为该待处理音频文件对应文档的两个字段写入ES。利用ES的近实时全文搜索和分布式特性，在保证高效率查询的同时，支持并发和实时查询。

Description

一种海量数字音频指纹存储与检索的方法及系统

技术领域

本发明属于音乐识别查询检索技术领域，具体地说，涉及一种海量数字音频指纹存储与检索的方法及系统。

背景技术

现阶段音乐的识别的应用有听歌识曲、哼唱识曲、广播流版权监控、车载音乐识别、视频BGM版权鉴别等，这些应用的核心就是对提取音频独特的特征量构成特殊指纹后，再将提取出来的指纹与曲库中音乐的指纹做比较。在上述多个要求精准度较高的场景下需要保留尽可能多的指纹用于对比，这样一段普通时长的音乐提取出来的指纹可能就有近万或者几万个指纹，当曲库达到大数量级时候其中的指纹数将是一个超大规模的级别，因此指纹库的设计将决定曲库大小及识别检索的速度。

最知名的听歌识曲应用音乐雷达(shazam)对外宣称有超过120亿标识，国内听歌识曲应用：虾米音乐、网易云音乐、QQ音乐等也有上千万曲库大小，国内版权识别服务ACRCloud也宣称拥有1300多万的曲库大小。

现有的音乐检索有多种方案，其中Echoprint是利用自身提取指纹算法结合solr来查询结果，solr是基于Lucene的全文搜索服务器，同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。Echoprint的识别过程大致为将待识别的指纹作为文本利用solr来获取与查询的指纹最相似的topN，然后提取TopN的指纹来做进一步匹配。Echoprint采用的solr来进行筛选具有查询速度快的特性，但是solr不合适实时数据查询，solr在建立实时索引的时候会产生IO阻塞，此时性能大幅度下降，因此solr在更新索引的时候，搜索效率会明显下降。

另一种方式是利用搜索引擎的工作方式将数据库设计成一个指纹指向一个包含多个元信息的倒排索引的方式，如果指纹长度为L，指纹由二进制构成，那么数据库最多能存储2^L个指纹。但是与搜索引擎相比较，音乐指纹复杂度更大。主要是因为指纹库有着与搜索词库相等的数量级，且单次匹配需要检索成千上万的指纹，这也意味着一次检索就等同于搜索引擎做上万次检索，这就限制了该方式只能适用于单机且数据库不能太大。

发明内容

针对现有技术中上述的不足，本发明提供一种海量数字音频指纹存储与检索的方法及系统，利用ES的近实时全文搜索和分布式特性，在保证高效率查询的同时，支持并发和实时查询，且随着数据量的上升，搜索效率不会有明显变化。

为了达到上述目的，本发明采用的解决方案是：一种海量数字音频指纹存储与检索的方法，包括数字音频指纹存储和数字音频指纹检索两个步骤，

所述的数字音频指纹存储包括如下子步骤：

S11：将待存储音频文件Hash处理，获得每个音频文件的唯一文件标识；

S12：提取出待存储音频文件的音频指纹，每个音频文件的音频指纹构造成一个字符串；

S13：将每个待处理音频文件Hash处理得到的文件标识作为Hbase的Rowkey，指纹字符串作为一个列的值，meta信息作为另一个列的值，写入Hbase的表中；

S14：将每个待处理音频文件Hash处理得到的文件标识和指纹字符串作为该待处理音频文件对应文档的两个字段写入ES；

所述的数字音频指纹检索包括如下步骤：

S21：音乐识别单元收到待识别音频后，提取出待识别音频的音频指纹，并构造成字符串传输到ES进行检索；

S22：ES检索获取与待识别文件的音频指纹字符串最相似的top N个文档中的音频文件Hash处理得到的文件标识；

S23：根据N个文档所代表的音频文件Hash处理得到的文件标识，批量查询Hbase，获取这N个音频文件的详细指纹和文件的meta信息；

S24：音乐识别单元对这N个音频文件的指纹进行进一步的精准识别，确定最终的识别结果；

S25：返回最终识别结果文件的meta信息，完成检索。

进一步地，步骤22中所述的ES检索包括如下步骤：

S2201：将待识别文件的音频指纹字符串处理为文本格式，并生成文档存入ES；

S2202：ES为该文档生成一个文档标识，然后将文档收集到内存索引缓存，并对其分词；

S2203：在ES存储的全部分片中检索每个词项所在的文档；

S2204：合并检索结果并为每个检索出来的文档生成一个分数，获取与待识别文件的音频指纹字符串最相似的top N个文档的标识。

进一步地，所述的meta信息包括歌名、歌手名、所属专辑以及词、曲、录音版权的归属、专辑或者歌手的图片。

进一步地，所述的N为预设的整数。

进一步地，所述的将待识别文件的音频指纹字符串处理为文本格式具体为：将全部指纹合在一起并用空格隔开构造成一个新的字符串后生成文档。

应用一种海量数字音频指纹存储与检索的方法的系统，包括音乐识别单元、指纹提取单元、ES和Hbase，所述的音乐识别单元用于获取待识别音频，并在检索完成后返回最佳识别结果的meta信息；所述的ES用于根据待识别音频的音频指纹进行检索，识别出与待识别音频的音频指纹最相似的top N个文档，得到这N个文档中的音频文件Hash处理得到的文件标识；所述的Hbase用于存储数据库中音乐文件的音频指纹和meta信息。

进一步地，所述的音乐识别单元包括待识别音乐文件获取模块、音频指纹提取模块和显示模块；所述的待识别音乐文件获取模块用于调取待识别的音频文件、获取待识别音视频文件中的音频或者流式传输的待识别音频；所述的音频指纹提取模块用于提取出待识别音频文件的音频指纹；所述的显示模块用于向用户推送识别出来的音频文件的meta信息。

本发明的有益效果是：

(1)利用ES的近实时全文搜索和分布式特性，在保证高效率查询的同时，支持并发和实时查询，且随着数据量的上升，搜索效率不会有明显变化。

附图说明

图1为ES生成指纹文档示意图；

图2为ES生成倒排表示意图；

图3为查询倒排表示意图；

图4为ES中分片和内存缓存示意图；

图5为一个未提交的可搜寻段示意图；

图6为音乐入库流程图；

图7为音乐检索流程图。

具体实施方式

以下结合附图对本发明作进一步描述：

solr和Elasticsearch都是基于Lucene实现的，Elasticsearch，即ES，是一个分布式、可扩展、实时的搜索与数据分析引擎。同时它又不仅仅只是全文搜索，它还能处理结构化搜索、数据分析、复杂的语言处理、地理位置和对象间关联关系等。

ES的基本概念：

文档(Document)：文档是索引和搜索的原子单位，它是包含了一个或多个字段(Field)的容器。

词项(Term)：搜索时的一个单位，代表文本中的某个词。

分片(Shard)：一个索引中的数据保存在多个分片中，相当于水平分表。一个分片便是一个Lucene的实例，它本身就是一个完整的搜索引擎。ES实际上就是利用分片来实现分布式。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时，ES会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。一个分片可以是主分片或者副本分片，索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。一个副本分片只是一个主分片的拷贝，副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

段(Segment)：ES中每个分片包含多个段，一个段就是一个倒排索引，在查询的时候ES会把全部分片中的全部段的结果进行汇总。

ES指纹检索原理：

因为指纹通常会构造为一系列的字符串或者数字，因此很容易处理为一个文本格式，即将全部指纹合在一起并用空格隔开，构造成一个新的字符串，并将该字符串存入ES。ES得到该文档(Document)后会自动为文档生成一个标识，然后将文档收集到内存索引缓存。如图1所示，新获取的指纹文档插入ES，ES为文档设定一个标识C，并将该文档放入内存索引缓存。对该文档进行分词(按照空格分离)，然后形成一个倒排索引，该倒排索引除了统计词项Term出现的次数和文档外，ES还会保存每一个词项出现过的文档总数，在对应的文档中一个具体词项出现的总次数，词项在文档中的顺序，每个文档的长度，所有文档的平均长度等等。这些统计信息允许ES决定哪些词比其它词更重要，哪些文档比其它文档更重要。如图2所示，将内存索引缓存中原本的文档与C文档一起切分，并形成一个倒排表。

ES将数据按照倒排表存储，一方面倒排表能显著缩小数据存储所需容量，另一方面倒排表类似于KeyValue的字典拥有超高的查询效率。按照此方式构造指纹检索库，当查询的指纹片段时，ES按照上述流程对文档分词然后在全部分片中检索每个词项Term所在的文档，最后合并结果并为每个文档生成一个分数。如图3所示，对查询文档进行切分后与倒排表匹配统计每个文档出现的次数，并依据它构成一个分数。实际查询过程中，ES会返回整个最佳匹配的10个文档(默认10)的全部信息。

文档插入到搜索引擎后，需要通过一个文件同步fsync操作将文档写到磁盘。确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。但是fsync操作代价很大，如果每次索引一个文档都去执行一次的话会造成很大的性能问题，这也是solr会有IO瓶颈的问题所在。

在ES和磁盘之间是文件系统缓存。像之前描述的一样，在内存索引缓存区中的文档会被写入到一个新的段中。但是这里新段会被先写入到文件系统缓存，这一步代价会比较低，稍后再被刷新到磁盘，这一步代价比较高。不过只要文件已经在文件系统缓存中，就可以像其它文件一样被打开和读取了，稍后ES再将文件系统缓存的文件同步到磁盘。

ES底层的Lucene允许新段被写入和打开，使其包含的文档在未进行一次完整提交时便对搜索可见。这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。文档先存放在内存索引缓存，如图4所示，一个分片包含一次提交点和3个段和包含多个文档的缓存。

因为倒排索引不可更改，所以ES采用追加段的方式来更新索引。如图5所示，ES会将缓存中的文档构成一个新的段并写到文件缓存系统，此时该段还没有进行提交但已经可以搜索，所以一般一个文档会在1秒内可以搜索到。

最后缓存被提交，该段和包含该段名字的提交点被写入磁盘，磁盘进行同步所有文件缓存中数据都刷新到磁盘确保都被写入，然后清空缓存等待接受新文档。ES利用文件缓存系统实现了近实时搜索，在这种场景中查询效率好过solr。

将ES作为一个一级查询返回最相似的TopN，然后再对TopN进行进一步精准分析，为了减少ES的压力确保其拥有最大限度的并发能力，还需要一个拥有高读写性能的分布式数据库Hbase。

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。而且它采用列式存储的存储方式，所谓列式存储是以列相关存储架构进行数据存储的数据库，主要适合于批量数据处理和即时查询。列式存储的主要优点之一就是可以大幅降低系统的I/O，尤其是在海量数据查询时，I/O向来是系统的主要瓶颈之一。

因此，在将指纹文档存储ES之前需要现在HBASE中存储一个副本，将Hbase中作为行键Rowkey作为文档的一个字段一并存入ES。这样在检测出TopN的结果时就能获得Hbase中的Rowkey。在获取到TopN的Rowkey后可以通过批量查询获取全部的文档，而该操作几乎是毫秒级。

基于以上分析，提供了一种海量数字音频指纹存储与检索的方法，包括数字音频指纹存储和数字音频指纹检索两个步骤。存储音乐数据前，首先将音乐文件和对应的音乐信息如歌曲名、专辑、艺人等信息准备好，可以提前存放在数据库也可以通过文档或其他方式存储只需要通过文件能检索到这部分信息。

如图6所示，数字音频指纹存储包括如下子步骤：

S11：将待存储音频文件Hash处理，获得每个音频文件的唯一文件标识；

S12：提取出待存储音频文件的音频指纹，每个音频文件的音频指纹构造成一个字符串；

S13：将每个待处理音频文件Hash处理得到的文件标识作为Hbase的Rowkey，指纹字符串作为一个列的值，meta信息，即元数据，作为另一个列的值，写入Hbase的表中；

S14：将每个待处理音频文件Hash处理得到的文件标识和指纹字符串作为该待处理音频文件对应文档的两个字段写入ES；

如图7所示，数字音频指纹检索包括如下步骤：

S21：音乐识别单元收到待识别音频后，提取出待识别音频的音频指纹，并构造成字符串传输到ES进行检索；音乐识别单元识别到的并不一定是一个完整的音频文件，也可能是视频中的北京音乐，更多的是部分音乐片段，根据这些音乐片段提取出指纹片段传输到ES进行检索；

S22：ES检索获取与待识别音频的音频指纹字符串最相似的top N个文档中的音频文件Hash处理得到的文件标识；

S23：根据N个文档所代表的音频文件Hash处理得到的文件标识，批量查询Hbase，获取这N个音频文件的详细指纹和文件的meta信息；

S24：音乐识别单元对这N个音频文件的指纹进行进一步的精准识别，确定最终的识别结果；

S25：返回最终识别结果文件的meta信息，完成检索。

进一步地，所述的meta信息包括歌名、歌手名、所属专辑以及词、曲、录音版权的归属、专辑或者歌手的图片。

进一步地，所述的N为预设的整数。

应用一种海量数字音频指纹存储与检索的方法的系统，包括音乐识别单元、指纹提取单元、ES和Hbase，所述的音乐识别单元用于获取待识别音频，并在检索完成后返回最佳识别结果的meta信息；所述的ES用于根据待识别音乐文件的音频指纹进行检索，识别出与待识别音频的音频指纹最相似的top N个文档，得到这N个文档中的音频文件Hash处理得到的文件标识；所述的Hbase用于存储音乐文件的音频指纹和meta信息。

进一步地，所述的音乐识别单元包括待识别音乐文件获取模块、音频指纹提取模块和显示模块；所述的待识别音乐文件获取模块用于调取待识别的音频文件、获取待识别音视频文件中的音频或者流式传输的待识别音频；所述的音频指纹提取模块用于提取出待识别音频文件的音频指纹；所述的显示模块用于向用户推送识别出来的音频文件的meta信息。

本发明的一个实施例中，采用16核CPU、128G内存服务器*5作为ES集群，4核CPU、16G内测服务器*5作为Hbase集群。在这样的集群配置下，导入了超过2000万的音乐指纹最终集群包含的数百亿指纹，然后在50并发量下完成全部检索只需要800ms左右，且增加节点或升级配置将进一步提升性能。且ES支持近实时检索，不存在solr的弊端，通常在插入一段新的指纹后1秒之内即可检索，且搜索性能不会下降。

以上所述实施例仅表达了本发明的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (7)

1.一种海量数字音频指纹存储与检索的方法，其特征在于：包括数字音频指纹存储和数字音频指纹检索两个步骤，

所述的数字音频指纹存储包括如下子步骤：

S11：将待存储音频文件Hash处理，获得每个音频文件的唯一文件标识；

S12：提取出待存储音频文件的音频指纹，每个音频文件的音频指纹构造成一个字符串；

S13：将每个待处理音频文件Hash处理得到的文件标识作为Hbase的Rowkey，指纹字符串作为一个列的值，meta信息作为另一个列的值，写入Hbase的表中；

S14：将每个待处理音频文件Hash处理得到的文件标识和指纹字符串作为该待处理音频文件对应文档的两个字段写入ES；

所述的数字音频指纹检索包括如下步骤：

S21：音乐识别单元收到待识别音频后，提取出待识别音频的音频指纹，并构造成字符串传输到ES进行检索；

S22：ES检索获取与待识别音频的音频指纹字符串最相似的top N个文档中的音频文件Hash处理得到的文件标识；

S23：根据N个文档所代表的音频文件Hash处理得到的文件标识，批量查询Hbase，获取这N个音频文件的详细指纹和文件的meta信息；

S24：音乐识别单元对这N个音频文件的指纹进行进一步的精准识别，确定最终的识别结果；

S25：返回最终识别结果文件的meta信息，完成检索。

2.根据权利要求1所述的一种海量数字音频指纹存储与检索的方法，其特征在于：步骤22中所述的ES检索包括如下步骤：

S2201：将待识别文件的音频指纹字符串处理为文本格式，并生成文档存入ES；

S2202：ES为该文档生成一个文档标识，然后将文档收集到内存索引缓存，并对其分词；

S2203：在ES存储的全部分片中检索每个词项所在的文档；

S2204：合并检索结果并为每个检索出来的文档生成一个分数，获取与待识别文件的音频指纹字符串最相似的top N个文档的标识。

3.根据权利要求1所述的一种海量数字音频指纹存储与检索的方法，其特征在于：所述的meta信息包括歌名、歌手名、所属专辑以及词、曲、录音版权的归属、专辑或者歌手的图片。

4.根据权利要求1所述的一种海量数字音频指纹存储与检索的方法，其特征在于：所述的N为预设的整数。

5.根据权利要求2所述的一种海量数字音频指纹存储与检索的方法，其特征在于：所述的将待识别文件的音频指纹字符串处理为文本格式具体为：将全部指纹合在一起并用空格隔开构造成一个新的字符串后生成文档。

6.应用权利要求1-5中任意一项所述的一种海量数字音频指纹存储与检索的方法的系统，其特征在于：包括音乐识别单元、指纹提取单元、ES、和Hbase，所述的音乐识别单元用于获取待识别音频，并在检索完成后返回最佳识别结果的meta信息；所述的ES用于根据待识别音频的音频指纹进行检索，识别出与待识别音频的音频指纹最相似的top N个文档，得到这N个文档中的音频文件Hash处理得到的文件标识；所述的Hbase用于存储音乐文件的音频指纹和meta信息。

7.根据权利要求6所述的一种海量数字音频指纹存储与检索的系统，其特征在于：所述的音乐识别单元包括待识别音乐文件获取模块、音频指纹提取模块和显示模块；所述的待识别音乐文件获取模块用于调取待识别的音频文件、获取待识别音视频文件中的音频或者流式传输的待识别音频；所述的音频指纹提取模块用于提取出待识别音频文件的音频指纹；所述的显示模块用于向用户推送识别出来的音频文件的meta信息。