腾讯音乐知识图谱搜索实践
分享嘉宾：Elvin 腾讯音乐 高级工程师
编辑整理：李一 中科雨辰
出品平台：DataFunTalk
导读： 近几年来，图数据在计算机领域得到了广泛的应用。互联网数据量指数级增长，大数据技术、图数据方面的应用增长很快，各家互联网大厂都在图数据分析和应用方面大量投入。为了让我们的搜索更加智能化，腾讯音乐也借助了知识图谱。今天和大家分享下腾讯音乐在图谱检索与业务实践方面的探索，主要包括以下几大部分：
- 音乐知识图谱介绍
- 图数据库选型
- 项目架构介绍
- 知识图谱搜索功能应用举例
- 总结与展望
01 音乐知识图谱介绍
首先和大家介绍下音乐知识图谱的相关知识。
1. 音乐数据分类
图状数据广泛存在，其中与音乐相关的业务数据主要有以下三类：
- 内容方面有歌曲、综艺、影视、专辑等；
- 歌手方面有歌手信息、歌手之间的关系，包括组合、相似等；
- 歌手和歌手内容之间的关系有演唱、作词、作曲等。
2. 音乐知识图谱的应用场景
(1) 复杂搜索需求实现
音乐知识图谱不仅可以做简单的搜索，还可以实现复杂搜索需求。例如要查询周杰伦的男女对唱的歌曲有哪些，如果要实现这个查询，需要对周杰伦的歌曲进行一定的过滤，歌手的数量要等于2，另一位歌手的性别是女性，还要考虑基于播放量、歌手权重等等的排序。在传统关系型数据要实现这个功能很复杂。利用知识图谱就比较简单了，先找到歌手周杰伦，查找周杰伦的所有歌曲中满足2人合唱，另一个歌手性别是女性的，只要两跳就可以实现复杂的搜索查询。
(2) 搜索结果的相关推荐
可以根据搜索的关键词，查询图谱中的实体节点，根据实体节点查询出关联的节点，用关联的节点给出推荐的结果。例如用户搜索周华健，可以通过关联信息推荐出李宗盛。如果通过搜索引擎，很难推荐出李宗盛，而用知识图谱，只要两跳，周华健歌手到对应组合（纵贯线），从组合再到另一歌手李宗盛，只要两跳。
(3) 基于知识计算给出答案
可以根据知识图谱的计算来给出一些答案，通过图谱的关联信息，实体上下位信息，实体属性信息，查询出相应的答案。例如用户搜索刘德华90年年代的歌曲，用知识图谱的话，只要歌手刘德华，时间90年代歌曲，两个联合起来就可以得到结果。
3. 搜索召回和知识图谱召回优缺点
搜索召回，是基于文本匹配的，召回之后会涉及相关性排序，相对来说比较复杂，精准度不足，可能过度召回。搜索召回的流程比较复杂，排序策略也相对复杂。
知识图谱召回，是基于实体之间的关系进行查询，可以做到精准召回，也没有过召回，召回的流程可以很短，也就是几条图查询的语句。另外，知识图谱还具备一定的推理能力。
02 图数据库选型
要实现图查询，首先得做图数据库的选型。
图数据库的选型，需要考虑以下几点因素：
- 开源非付费 ，考虑到成本及源码可控性，选择拥抱开源；
- 分布式框架可扩展 ，随着数据的增加和减少，后台必须是可扩展的；
- 高性能毫秒级多跳查询 ，要做到毫秒级的在线响应；
- 支持千亿级规模数据量 ；
- 支持数据批量导入导出 。
我们对比了8个数据库，对优缺点进行了分析，对这些数据库进行了分类：
- 第一类，以Neo4j为代表的，只有单机版本，性能比较优秀，但是不满足分布式可扩展性要求。Neo4j的商业版本支持分布式，但是却是收费的。
- 第二类，JanusGraph、HugeGraph这类数据库，支持分布式可扩展的，他们的共同特点是在现有的图谱上增加了通用的图语义解释层，受到存储层架构的限制，存储层是外部数据库实现，不支持计算下推的功能，导致性能较差。
- 第三类，以NebulaGraph为代表，这一类数据库都实现了自己的存储层，支持计算下推，做了效率上的优化，性能提升很多。
从上图看到综合性能测试数据。我们通过1度邻居（跟点直接相连的点），2度邻居，共同邻居，这三个方面来对数据库性能进行测试，可以看到Nebula不管是单机性能，还是集群性能，都要远超于其他竞品。考虑到性能，社区活跃度，版本迭代速度，语言上的通用性，我们最终选择了Nebula数据库做为我们项目的图数据库。
03 项目架构介绍
1. 在线层
包含以下模块：
- Storaged 负责具体数据的存储，包括点数据、边数据，以及相关的索引；
- Metad 负责存储图数据的meta信息，例如数据库的schema、addition等；
- Nebula graphd 负责数据计算的逻辑层，是无状态的，可以进行平行扩展，内部执行计算引擎来完成查询的整个过程。
- Nebula proxy 是我们新增的模块，作为整个nebula模块的代理层，可以接受外部的命令，并对图数据进行操作，包括图的查询，更新，删除。另外，nebula proxy也负责协议的转换，集群的心跳和路由注册。
由于单集群有重建数据的需求，也为了防止机房故障，我们选择双集群来支撑整个服务的可用性。
在线层请求处理的流程为，cgi在接收到用户请求后，将用户请求传给broker模块，broker请求模版匹配生成相应的图查询语句，从Zookeeper中提取可用的集群，将查询语句发给nebula proxy进行图谱召回，nebula proxy将具体的查询语句传递给nebula graphd, nebula graphd负责执行最终的语句，然后把结果返回给broker层，broker层补充一些前端显示摘要后，将数据返回给前端做展示。
2. 离线层
音乐数据有实时的新增数据，例如新增发行的唱片，还有全量数据的更新，所以我们选择了全量加增量的数据层方案。
(1) 全量数据生成方案
音乐很多数据存在数据库中，先将数据从DB中dump出来后，由IndexBuilder模块将数据格式转换为所需的格式后形成一个全量的源数据，将全量的源数据上传到HDFS后，通过运行spark任务，把数据转为Nebula底层所需的数据文件，IndexMgr发现有新的常量数据生成后，将数据文件下载下来，将全量数据加载到NebulaProxy，这样全量数据就生成好了。
(2) 实时数据的生成
每隔一段时间，通常是几分钟，将几分钟之内的业务修改数据dump出来后，转为特定的格式，形成一个增量的源数据，增量的源数据存入到Kafka里面，可以用于数据的重发和恢复，DataSender从Kafka队列里面拉取到最新的数据，通过NebulaProxy发送到集群，这样增量数据就生效了。
这里涉及到了一个增量补发的问题，因为存量过程dump过程中要耗费很长时间，可能要花几个小时，在全量数据dump过程中也有新的增量数据，这期间的增量数据可能并没有进入到全量的数据当中。所以这里需要进行一个历史增量的补发，从T0后（全量同步开始时间）的新增数据，不在全量数据中，需要将T0之后的数据全部进行补发。
04 知识图谱搜索功能应用举例
1. 配置化召回
常规召回方式为：根据Query生成查询语句，获取召回结果，根据策略混排，召回结果展示。
这样做的问题是，每做一次，每增加一种新的召回策略，以上四步都要重复，所以召回不够灵活，业务改动大。
我们增加了一种新的基于Query模板的召回方式，就是根据模板生成对应的查询语句，同时预先设置了一些常用的混排策略。比如我们配置一个学校加校歌的模板，当查询校歌的时候，我们把学校的名字提取出来，填到查询语句里面，形成一个完整的图查询语句。同时也预置了一些混排插入策略，填入对应的混排参数，就可以做到上线。这样做的优点就是召回比较灵活，和搜索相比，召回上线的代价比较小。
2. 业务应用
我们最终上线了上图这些业务，支持各类搜索场景。
- 校歌搜索：当用户搜索大学校名和校歌组合时，召回对应的学校的校歌；
- 歌手场景：当用户搜索歌手名字的时候，返回歌手所在组合，以及合唱过知名歌曲的合作歌手等；
- 影视场景：当用户搜索影视主题曲、片尾曲、插曲等等的时候，返回对应的影视的歌曲。
05 总结与展望
今天的讨论从图数据的选型开始，到schema分类定义，项目架构层设计，再到知识图谱的搜索。结论是采用图数据，可以很好的把专家经验智能融入图谱。通过图数据技术实现的知识库，增强了检索、推荐、可视化等功能，腾讯音乐很好的对知识图谱技术进行了应用，大大提高了客户的搜索体验感，增强了客户黏度。让我们拥抱AI技术，让其更好地服务于生活。
06 精彩问答
Q：在搜索过程中有考虑音频信息吗？
A：这个是有考虑的，我们可以通过音频识别技术，首先去识别歌曲的一个大的分类流派，比如说像民谣摇滚流行这些流派，然后在线检索的时候，我们会通过这种语音搜索去召回。另外，我们跟QQ音乐天津实验室也有合作，比如像听目前的金科视曲，后台走的也是走我们的限量搜索，也是通过对音频信息进行的召回。
Q：语义检索结果排在第几位？是怎么和关键词检索一起排序的？
A：首先我们会通过算法去挖掘某一个语义标签跟某一首歌曲的相似度，语意搜索的话就可以通过语音标签进行召回，优先把语义相似度高的结果排到前面。当然也会有一些奇异的情况，比如说像赵雷有一首歌叫民谣，民谣这首歌就是一个歌曲，它同时也是一个语义，我们排序的时候也会兼顾这种混排的效果，最下层排序，首先会把民谣的歌曲放在前面，因为它毕竟是一个比较知名歌手的歌曲，下面会把对应的语义的结构放在后面，然后我们在更上层会有基于算法的排序模型去给用户推荐点击量高的调前。
Q：全量索引版本切换双buffer内存是否会翻倍？
A：实际上我们索引切换的过程中是没有双buffer的，是按每一个分片下的每一个副本进行逐个切换，切换的时候会进行动态的卸载，所以并没有占用额外的内存。
Q：跨越截断，是在index截断好，还是在线选择截断？
A：是在线选择截断，如果离线截断会导致数据丢失，这样是没办法回溯的。截断也是分片的，向量检索也是可以分片之后，做并行检索。
分享嘉宾：
