共计 3940 个字符，预计需要花费 10 分钟才能阅读完成。
本文首发于 DataFunTalk
导读：近几年来，图数据在计算机领域失去了宽泛的利用。互联网数据量指数级增长，大数据技术、图数据方面的利用增长很快，各家互联网大厂都在图数据分析和利用方面大量投入人力和物力。为了让咱们的搜寻更加智能化，腾讯音乐也借助了常识图谱。明天和大家分享下腾讯音乐在图谱检索与业务实际方面的摸索，次要包含以下几大部分：
- 音乐常识图谱介绍
- 图数据库选型
- 我的项目架构介绍
- 常识图谱搜寻性能利用举例
- 总结与瞻望
音乐常识图谱介绍
首先和大家介绍下音乐常识图谱的相干常识。
1. 音乐数据分类
图状数据宽泛存在，其中与音乐相干的业务数据次要有以下三类：
- 内容方面有歌曲、综艺、影视、专辑等；
- 歌手方面有歌手信息、歌手之间的关系，包含组合、类似度等；
- 歌手和歌手内容之间的关系有演唱、作词、作曲等。
2. 音乐常识图谱的利用场景
(1) 简单搜寻需要实现
音乐常识图谱不仅能够做简略的搜寻，还能够实现简单搜寻需要。例如要查问周杰伦的男女对唱的歌曲有哪些，如果要实现这个查问，须要对周杰伦的歌曲进行肯定的过滤，歌手的数量要等于 2，另一位歌手的性别是女性，还要思考基于播放量、歌手权重等等的排序。在传统关系型数据要实现这个性能很简单。利用常识图谱就比较简单了，先找到歌手周杰伦，查找周杰伦的所有歌曲中满足 2 人独唱，另一个歌手性别是女性的，只有两跳就能够实现简单的搜寻查问。
(2) 搜寻后果的相干举荐
能够依据搜寻的关键词，查问图谱中的实体节点，依据实体节点查问出关联的节点，用关联的节点给出举荐的后果。例如用户搜寻周华健，能够通过关联信息举荐出李宗盛。如果通过搜索引擎，很难举荐出李宗盛，而用常识图谱，只有两跳，周华健歌手到对应组合（纵贯线），从组合再到另一歌手李宗盛，只有两跳。
(3) 基于常识计算给出答案
能够依据常识图谱的计算结果来给出一些答案，通过图谱的关联信息，实体上下位信息，实体属性信息，查问出相应的答案。例如用户搜寻刘德华 90 年代的歌曲，用常识图谱的话，只有歌手刘德华；工夫 90 年代歌曲，两个联结起来就能够失去后果。
3. 搜寻召回和常识图谱召回优缺点
搜寻召回，是基于文本匹配的，召回之后会波及相关性排序，相对来说比较复杂，精准度有余，可能适度召回。搜寻召回的流程比较复杂，排序策略也绝对简单。
常识图谱召回，是基于实体之间的关系进行查问，能够做到精准召回，召回的流程能够很短，也就是几条图查问的语句。另外，常识图谱还具备肯定的推理能力。
图数据库选型
要实现图查问，首先得做图数据库的选型。
图数据库的选型，须要思考以下几点因素：
- 开源非付费，思考到老本及源码可控性，抉择拥抱开源；
- 分布式框架可扩大，随着数据的减少和缩小，后盾必须是可扩大的；
- 高性能毫秒级多跳查问，要做到毫秒级的在线响应；
- 反对千亿级规模数据量；
- 反对数据批量导入导出。
咱们比照了 8 个数据库，对优缺点进行了剖析，对这些数据库进行了分类：
- 第一类，以 Neo4j 为代表的，只有单机版本，性能比拟优良，然而不满足分布式可扩展性要求。Neo4j 的商业版本反对分布式，然而却是免费的。
- 第二类，JanusGraph、HugeGraph 这类数据库，反对分布式可扩大，他们的独特特点是在现有的图谱上减少了通用的图语义解释层，受到存储层架构的限度（存储层是内部数据库实现），不反对计算下推的性能，导致性能较差。
- 第三类，以 Nebula Graph 为代表，这一类数据库都实现了本人的存储层，反对计算下推，做了效率上的优化，性能晋升很多。
从上图看到综合性能测试数据。咱们通过 1 度街坊（跟点间接相连的点）、2 度街坊、独特街坊，这三个方面来对数据库性能进行测试，能够看到 Nebula Graph 不论是单机性能，还是集群性能，都要远超于其余竞品。思考到性能、社区活跃度、版本迭代速度、语言上的通用性，咱们最终抉择了 Nebula Graph 作为咱们我的项目的图数据库。
我的项目架构介绍
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 Graph 底层所需的数据文件，IndexMgr 发现有新的常量数据生成后，将数据文件下载下来，将全量数据加载到 NebulaProxy，这样全量数据就生成好了。
(2) 实时数据的生成
每隔一段时间，通常是几分钟，将几分钟之内的业务批改数据 dump 进去后，转为特定的格局，造成一个增量的源数据，增量的源数据存入到 Kafka 外面，能够用于数据的重发和复原，DataSender 从 Kafka 队列外面拉取到最新的数据，通过 NebulaProxy 发送到集群，这样增量数据就失效了。
这里波及到了一个增量补发的问题，因为存量数据 dump 过程中要消耗很长时间，可能要花几个小时，在全量数据 dump 过程中也有新的增量数据，这期间的增量数据可能并没有进入到全量的数据当中。所以这里须要进行一个历史增量的补发，从 T0 后（全量同步开始工夫）的新增数据，不在全量数据中，须要将 T0 之后的数据全副进行补发。
常识图谱搜寻性能利用举例
1. 配置化召回
惯例召回形式为：依据 Query 生成查问语句，获取召回后果，依据策略混排，召回后果展现。
这样做的问题是，每做一次，每减少一种新的召回策略，以上四步都要反复，所以召回不够灵便，业务改变大。
咱们减少了一种新的基于 Query 模板的召回形式，就是依据模板生成对应的查问语句，同时事后设置了一些罕用的混排策略。比方咱们配置一个学校加校歌的模板，当查问校歌的时候，咱们把学校的名字提取进去，填到查问语句外面，造成一个残缺的图查问语句。同时也预置了一些混排插入策略，填入对应的混排参数，就能够做到上线。这样做的长处就是召回比拟灵便，和搜寻相比，召回上线的代价比拟小。
2. 业务利用
咱们最终上线了上图这些业务，反对各类搜寻场景。
- 校歌搜寻：当用户搜寻大学校名和校歌组合时，召回对应的学校的校歌；
- 歌手场景：当用户搜寻歌手名字的时候，返回歌手所在组合，以及独唱过出名歌曲的单干歌手等；
- 影视场景：当用户搜寻影视主题曲、片尾曲、插曲等等的时候，返回对应的影视的歌曲。
总结与瞻望
明天的探讨从图数据的选型开始，到 schema 分类定义，我的项目架构层设计，再到常识图谱的搜寻。论断是采纳图数据，能够很好的把专家教训智能融入图谱。通过图数据技术实现的知识库，加强了检索、举荐、可视化等性能，腾讯音乐很好的对常识图谱技术进行了利用，大大提高了客户的搜寻体验感，加强了客户黏度。让咱们拥抱 AI 技术，让其更好地服务于生存。
精彩问答
Q：在搜寻过程中有思考音频信息吗？
A：这个是有思考的，咱们能够通过音频辨认技术，首先去辨认歌曲的一个大的分类流派，比如说像民谣、摇滚、风行这些流派，而后在线检索的时候，咱们会通过这种语音搜寻去召回。另外，咱们跟 QQ 音乐天津实验室也有单干，比方像听目前的金科视曲，后盾走的也是走咱们的限量搜寻，也是通过对音频信息进行的召回。
Q：语义检索后果排在第几位？是怎么和关键词检索一起排序的？
A：首先咱们会通过算法去开掘某一个语义标签跟某一首歌曲的类似度，语义搜寻的话就能够通过语意标签进行召回，优先把语义类似度高的后果排到后面。当然也会有一些奇怪的状况，比如说像赵雷有一首歌叫民谣，民谣这首歌就是一个歌曲，它同时也是一个语义，咱们排序的时候也会兼顾这种混排的成果，最上层排序，首先会把民谣的歌曲放在后面，因为它毕竟是一个比拟出名歌手的歌曲，上面会把对应的语义的构造放在前面，而后咱们在更下层会有基于算法的排序模型去给用户举荐点击量高的调前。
Q：全量索引版本切换双 buffer 内存是否会翻倍？
A：实际上咱们索引切换的过程中是没有双 buffer 的，是按每一个分片下的每一个正本进行一一切换，切换的时候会进行动静的卸载，所以并没有占用额定的内存。
Q：逾越截断，是在 index 截断好，还是在线抉择截断？
A：是在线抉择截断，如果离线截断会导致数据失落，这样是没方法回溯的。截断也是分片的，向量检索也是能够分片之后，做并行检索。
明天的分享就到这里，谢谢大家。
分享嘉宾：
交换图数据库技术？退出 Nebula 交换群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~
