微澜：用 OceanBase 搭建基于知识图谱的实时资讯流的应用实践

本文作者： 北京深鉴智源科技有限公司架构师  郑荣凯

本文整理自北京深鉴智源科技有限公司架构师郑荣凯，在《深入浅出 OceanBase 第四期》的分享。

知识图谱是一项综合性的系统工程，需要在在各种应用场景中向用户展示经过分页的一度关系。

微澜是一款用于查询技术、行业、企业、科研机构、学科及其关系的知识图谱应用，具有十亿级实体以及百亿级关系。在我们公司的业务场景中，在数据上存在若干超级节点，这些节点是实用户访问概率极高的关键节点，因此，它们并不应被轻易地视为长尾问题的范畴。又因为我们当前的用户基数相对有限，遇到缓存的频率较低，因此我们需要一套解决方案来降低用户的查询延迟。

为了解决这个的业务痛点，微澜通过在知识图谱中引入OceanBase，突破了技术挑战，完美地在新闻资讯体系中搭建起了自己独有的体系，有效保证了信息的速度以及信息的可溯源与真实可靠。

一、微澜用知识图谱做了什么？

微澜由北京深鉴智源科技有限公司出品，是基于人工智能的个人认知提升助手（PCA）及创新的外部知识管理工具，有助于启发及解决工作、学习及生活中的有效选择及效率问题；打破“信息茧房”，消除“内卷”。

微澜在知识架构上增加了新闻资讯的架构。假如用户关注了某公司，系统会持续推送有关该公司的新闻，以及与这条新闻相关的实体。

二、为什么选择知识图谱？

微澜的客户一般在行业上游，挖掘商业逻辑。所以客户需要的信息相对比较宏观，需要更大的知识图谱，更多的实体承载这个架构。微澜的客户注重平衡“特殊”与“一般”。客户既要普适的结论也需要一些特殊性的结果，从而观察相关领域的风险以及机遇。与此同时，微澜的客户注重因果推断，他们希望所有的数据、结论能够溯源。

大卫休谟曾经说过：“运用归纳法的正当性，永远不可能从理性上被证明。”如果采用归纳法，归纳以往的数据、经验、结论，用这些数据推断未来的可能性，这件事情永远不可能在理性上被证明。

Inductive Reasoning（归纳推理）是从观察到的现象得出的一个结论，一个原则。假设看到的所有羊都是白的，利用 Inductive Reasoning （归纳推理）总结羊一定全都是白色的。

Deductive Reasoning（演绎推理）是已经知道一个原则，利用这个原则去预测看到的现象。假设一个定律是所有的乌龟都有壳。现在出现一个乌龟，就可以预料到这个乌龟一定也有壳。

思想关系与事实之间的区别，通常被称为“休谟之叉”，即 Hume's Fork 。通常带有负面暗示，即休谟可能非法排除了不适合这两个类别或同时适合这两个类别的有意义的命题。

休谟对知识的二分法被称为“休谟之叉”，是后来西方哲学认识论中分析命题和综合命题划分的先导。从“休谟之叉”又可以推出诸多不同标准下的知识，如先天的和后天的知识、分析的和综合的知识、必然的和偶然的知识，而这些知识的区分标准都已被“休谟之叉”点破。

以苹果公司为例，它存在着四万多个核心技术，所有的核心技术都可以在微澜溯源。

微澜发的新闻架构是基于知识图谱扩展的。实体一和实体二之间有关系，所以实体一关的新闻与实体二的新闻，也有潜在关系。

如上图所示，一个实体连着三条新闻，在不同的时间，发生了这三条新闻。所以微澜可以组成关于这个实体新闻流的时间线，便于用户理解实体发展的商业过程。

在微澜的知识图谱业务中，很多场景需要展示复杂的关系。同时，微澜的数据中存在一些超级节点，根据微澜的业务场景，超级节点是用户最可能访问的节点。

所以超级节点不能被简单归类到长尾问题。

某个机构在某领域的排名特别高，但在全局或者其他领域一般。在这种场景下，微澜必须显示排序属性，并且对于全局排序项，进行拟合标准化，使每个维度的数据方差都为1，均值都为0，以便用户进行局部排序，方便用户查询。

三、为什么要在知识图谱中加入 NewSQL ？

为了解决上述问题，微澜在知识图谱中加入 NewSQL ，把图中的一度关系问题转化为传统RDBMS中的联合主键即可解决图数据库中海量数据排序下推的问题。

对于初创企业而言，在数据量大的情况下， NewSQL 的运维成本和件成本都很低。

传统DBMS容错方案的重点是保障数据更新不会丢失。 NewSQL 除了这点以外，还能最小化停机时间，使其一直保持应用在线。

四、 NewSQL 在微澜的系统中如何选型？

微澜有30亿的 records 数据，但没有复杂分库分表的运维能力。而 ScyllaDB 无法适应新业务的查询要求，所以微澜需要一个能实现传统 RDBMS 的 query 功能的数据库。

除此之外，微澜需要进行周期性的大量写入。所以微澜 在OceanBase ， TiDB ， CockroachDB 之间选型。

Tikv 采用 Range 的方式分区，但微澜更需要 hash 的分区方式，因为微澜的业务更偏向于单点查询而非范围查询，写入速度比较慢，无法适应微澜周期性的大量写入的业务场景

CockroachDB（小强数据库）是 PG 型数据库，团队之前接触的比较少，对于单表的数据量支持一般，不符合业务需求。

OceanBase 有优秀的写入能力，支持 hash 分区策略。对于单表大数据量的支撑强而有力，有良好的社区支持，支持 B tree 索引策略复合业务。对于 Paxos 的极致应用使得任务的并行粒度很细，可以把性能尽可能发挥出来。

经过综合考虑，微澜最终选择使用 OceanBas e。在微澜的所有业务中，微澜选择使用 OceanBase 来存储图谱中所有的一度关系。图数据库无法覆盖的海量关系查询排序已经被完美解决。

对比之前微澜使用的 ScyllaDB ，作为 NewSQL 的 OceanBase ，自然比 NoSQL 数据库能覆盖更多的业务场景，比如多个条件的筛选并排序。现在微澜两周一次30亿 records 的数据更新已经在 OceanBase 上被验证了很多次，可以适配微澜的业务需求。

微澜采用推送架构而不是拉取架构，类似于微博给千万级大V单独建表推送给关注者的逻辑，用户不管是关注数个百万级新闻的实体还是只关注单个新闻数量很少的实体得到消息推送的速度都基本一致。

五、微澜如何实现？

微澜的业务架构，如上图所示。首先，用户在后端，关注一个实体。然后，微澜关联到实体 ID ，在用户资讯表，关联 ID 的新闻。最后，写入用户资讯表，将新闻展示给用户。

相比传统的资讯平台，由于知识图谱的加入并且与新闻深度耦合，可以扩展更多。比如针对某实体的新闻时间线，查询两条新闻之间的关系以及获取领域交叉等功能。

知识图谱采用演绎法而非传统技术分析的归纳法，推理结果保证是存在的事实而非通过分析得到的推论，领域交叉运算可溯源且真实可靠。

附录、用户问答

问：现在的集群规模有多大？

答：微澜只有三台机器。

问：这些模型是固定好的？还是根据即时需求生成的？

答：大部分是固定好的。如果客户对微澜提出了新的需求，微澜再生产新的功能，满足相关的需求。

问：你们怎样控制合并机制？

答：在业务方，手动合并。目前微澜还没有完全解决合并问题，但现在可以正常运行。

问： OceanBase 在知识图谱的用法，可以复制到类似的业务场景下吗？这种场景有什么突出的特点？

答：原生的存储数据的形式不具有排序功能。 OceanBase 可以索引，做更多复杂的业务。