基于知识图谱的实时资讯流实践
摘要：本文整理自北京深鉴智源科技有限公司架构师郑荣凯，在深入浅出OceanBase第四期的分享。
本篇内容主要分为六个部分：
1.微澜用知识图谱做了什么？
2.为什么选择知识图谱？
3.什么要在知识图谱中加入NewSQL？
4.NewSQL在微澜的系统中如何选型？
5.微澜如何实现？
6.用户问答
一、微澜用知识图谱做了什么？
北京深鉴智源科技有限公司的产品微澜是一款用于查询技术、行业、企业、科研机构、学科及其关系的且具有十亿级实体，百亿级关系的知识图谱应用。
微澜是全球第一个基于人工智能的个人认知提升助手（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的极致应用使得任务的并行粒度很细，可以把性能尽可能发挥出来。
经过综合考虑，微澜最终选择使用OceanBase。在微澜的所有业务中，微澜选择使用OceanBase来存储图谱中所有的一度关系。图数据库无法覆盖的海量关系查询排序已经被完美解决。
对比之前微澜使用的ScyllaDB，作为NewSQL的OceanBase，自然比NoSQL数据库能覆盖更多的业务场景，比如多个条件的筛选并排序。现在微澜两周一次30亿records的数据更新已经在OceanBase上被验证了很多次，可以适配微澜的业务需求。
微澜采用推送架构而不是拉取架构，类似于微博给千万级大V单独建表推送给关注者的逻辑，用户不管是关注数个百万级新闻的实体还是只关注单个新闻数量很少的实体得到消息推送的速度都基本一致。
五、微澜如何实现？
微澜的业务架构，如上图所示。首先，用户在后端，关注一个实体。然后，微澜关联到实体ID，在用户资讯表，关联ID的新闻。最后，写入用户资讯表，将新闻展示给用户。
相比传统的资讯平台，由于知识图谱的加入并且与新闻深度耦合，可以扩展更多比如针对某实体的新闻时间线，查询两条新闻之间的关系以及获取领域交叉等功能。
知识图谱采用演绎法而非传统技术分析的归纳法，推理结果保证是存在的事实而非通过分析得到的推论，领域交叉运算可溯源且真实可靠。
六、用户问答
问：现在的集群规模有多大？
答：微澜只有三台机器。
问：这些模型是固定好的？还是根据即时需求生成的？
答：大部分大部分是固定好的。如果客户对微澜提出了新的需求，微澜在生产新的功能，满足相关的需求。
问：你们怎样控制合并机制？
答：在业务方，手动合并。目前微澜还没有完全解决合并问题，但现在可以正常运行。
问：OceanBase在知识图谱的用法，可以复制到类似的业务场景下吗？这种场景有什么突出的特点？
答：原生的存储数据的形式不具有排序功能。OceanBase可以索引，做更多复杂的业务。
