> 本文整理自 五矿集团-五矿期货有限公司副总经理-张剑锋 在 NebulaGraph 2022 年度用户大会上的分享。现场视频如下——

大家好，我是五矿期货的张剑锋。今天十分感谢 NebulaGraph 能够提供这个跟各位专家，还有行业技术大拿们当面学习和交流的机会。

首先介绍一下期货行业。在中国的六大金融行业里面，银行，保险，还有信托，是银保监会体系下的，俗称大金融行业。期货行业属于证监会管辖下，有证券期货和基金，属于小金融行业。

我们这个行业有三大主要的功能：发现价格，管理风险，还有配置资源。发现价格重点给大家介绍一下，因为期货市场的参与者众多，除了有生产者、贸易商，还有我们消费者，以及市场上大量的投机者。因为有这样不同类型的大量的交易者在期货市场上通过多空博弈产生出来一个价格，是相对客观和真实的，所以可以用于指导这些产业客户和实体经济相关参与者安排自己的生产和经营活动。

期货行业最主要的作用是服务实体经济和产业客户，所以我们这个行业的特点也是和实体经济挂钩会比较紧密。这几年才兴起的像保险+期货、乡村振兴、场外期权等等都是直接服务产业客户的业务模式。

下面介绍下五矿期货的一些情况。 五矿期货是中国五矿集团旗下的金融企业，**五矿集团是 16 年五矿集团和中冶集团两家世界 500 强企业战略性重组，最新的世界 500 强排名是 58位**。五矿集团是国家的金属资源领域的冶金建设国家队，我们的控股股东是五矿资本有限公司，是 A 股的上市公司，也是隶属五矿集团的，然后我们也是一个 **A 股市场稀缺的全牌照的金融控股公司**。

# 为什么要搭建知识图谱平台？

## 知识图谱的价值

关于知识图谱的价值，我来谈一下我们的理解。

![知识图谱的价值](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/7.jpeg)

因为期货行业是一个信息高度密集的行业，我们日常的经营过程中会产生大量的结构化数据，数据类型也很多。除了像各种的客户的交易数据，还有一些像客户行为埋点数据、用户事件数据等等。同时还有很多非结构化的数据， 像各类研究报告，新闻资讯。

另外，由于监管对我们业务有特殊要求，比如客户开通特定品种要求的双录等会产生大量的音频视频数据，所以（拥有）大量多维的、多类型的数据是期货投资行业的一个特点。**我们认为利用知识图谱能够实现数据的汇集和治理、知识挖掘和应用，以及辅助业务分析和决策**。


另外，期货行业也是知识密集型行业，因为期货行业的业务规则很复杂还会经常变化，所以如何把知识沉淀到公司，作为公司知识的传承，还有在知识基础上做相应的智能化的应用都是非常重要的，所以我们认为知识图谱在我们这个行业会有很大的作用和意义。

## 知识图谱的优点

![知识图谱的优点](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/8.jpeg)

从技术方面，知识图谱的优点大概有四个方面——

**第一，灵活的多维数据叠加**

孤岛的数据其实是没有太多意义，也不利于数据的挖掘和分析。而图结构比较灵活，通过图的点面关系，可以把有价值的多维数据叠加和连接在一起，会有更大的意义。

**第二，依托经验分析可解释**

因为在图谱上模型设计和决策，它的计算路径和过程是很清晰的，可以使用图很方便地回溯推导过程，并可以和人的经验相互应证。

**第三，数据的高效直观表达**

图数据相对来说是比较容易可视化的，通过将知识图谱可视化展示给用户，可以使用户快速学习或者是发现新的知识。

**第四，增强现有模型准确率**

因为使用知识图谱技术把整个数据拉通之后，有助于数据的数据质量的提升，同时可以提高整个模型的准确率。

# 使用过程中面临的困境

![使用知识图谱面临的困境](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/9.jpeg)


在我们实践和探索过程中，我们也遇到了一些困难。总结起来主要有三点，第一个就是因为知识图谱技术相对来说比较新，在我们这个行业里应用几乎没有，所以我们只能去摸着石头过河去一步一步来，这个过程其实蛮艰辛的。


第二个就是人才，我们对传统的数据库还是有一些人才储备的，但是现有新的领域，招聘人员、储备人员、培养人员都需要很长的时间，这是第二个痛点。

第三个就是业务部门认知不到位，这也导致参与度不高，所以推进就没那么快，所以刚建的时候走走停停，推的过程就比较困难。

## 如何走出困境

![五矿期货是如何成功走出困境的](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/10.jpeg)

面临这种困境，我们很庆幸就是说找到两家很好的合作伙伴，一个是今天的东道主悦数科技，我们认为他们是一家很好、很可靠的公司，**NebulaGraph 图数据库除了稳定可靠、性能高效，另外还是国产的，而且是支持信创的。因为我们公司是证监会指定的信创试点单位，所以综合考虑我们认为 NebulaGraph 图数据库是最佳的选择方案**。

另外要感谢的就是普适智能，因为我们是缺乏技术储备的，我们就比较依赖厂商的支持。**普适智能是很专业地专注于知识图谱的应用，而且他们愿意深耕金融行业，对金融行业的业务模式有比较深的沉淀，所以他们可以给我们提供一站式的知识图谱平台的解决方案**。

我们很多的业务场景都是 NebulaGraph 和普适在驻场和我们业务部门、技术部门一起配合很长时间梳理清楚，把业务搬到知识平台上，帮我们一步一步搭建起到现在这样一个平台，所以在此十分感谢这两个公司。

# 知识图谱在期货行业的应用场景

## 场景一：辅助投研

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/15.jpeg)

这是我们投研平台知识图谱应用的一个逻辑图。首先我们公司会有很多的内部数据，包括一些非公开的数据、行业的数据，还有一些外部数据，包括我们购买的很多商业数据源、数据研报等等。内外部数据打通之后，我们**依托知识图谱平台实现了知识的沉淀复用，为后续产业链的研究，研报的生成，以及风险预测等等这些业务场景去赋能**。

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/16.jpeg)


这是我们整个投研过程的描绘：研究员从发现线索出发，然后整理相关资料，经过分析研究框架的判断，最终形成投资决策和应用。


传统来说以前就是数据纯粹的罗列，检索也比较简单，然后我们用知识图谱平台可以**实现自定义的投研主页，让用户每天高效获取他所需要的信息，而不需要去浪费过多时间去找线索**。另外就是我们优化了检索算法和信息展示的交互界面，形成了更加贴合用户习惯的页面，提升了信息获取的效率和用户的使用感受。


之前数据比较割裂，因为搜集数据的渠道来源很多，也很不方便，通过这个平台把多维的数据整合，加上自有数据的上传，还有指标编辑等功能，实现了数据收集效率的大幅提升。


然后我们底层使用的是批流一体的图谱技术，让数据更加及时，拓展性也更强了。以前的分析判断过程是研究人员分析判断完全依赖个人经验，分析工具也比较少，导致效率比较低。我们**通过机器学习来辅助数据的分析和挖掘，能够主动定位可能的分析方向，提高探索效率**。


在决策和应用阶段，以前研究人员仅是能够生成这个报告，但是写的报告一个是精度可能比较低，另外它的准确度有可能会比较模糊，所以**我们联通了用户的分析过程和报告产生的过程，然后能够快速获取研究分析所依赖的数据以及分析的流程，帮助他们去提升整个分析的逻辑，让数据和研究员的个人经验去做一个印证**。有可能他的知识或者他的框架可能有错误和偏差，通过这样的数据分析也可以优化。

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/17.jpeg)

具体来说，辅助投研场景是这样的——因为期货行业里面有很多品种是存在比较强的相关关系的。比如说原油，它的衍生品有燃料油、化纤、化工类产品、沥青等等。

一个品种的价格变动，对相关的品种都是有影响的，所以我们投研平台第一步就要先要找到对应关系，把它在这个平台上用图谱形式去展示出来，然后通过一些模型的训练，除了找到影响的关系之外，还要找到影响的程度，就是它的权重。

当然了，这要经过大量的模型训练或者验证，**通过找到一个品种价格变化传导到其他相关品种价格的关系，来辅助研究人员做相应的研判**。

![五矿期货知识图谱应用场景一：辅助投研](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/18.jpeg)


除了品种之间有较强的相关性之外，期货行业有些相关品种的产业链是比较强的，因为上游可能有很多层级，下游消费方可能也有很多的节点，所以我们**以研究员的视角，在平台上绘制出整个产业链的结构图，目的是找到整个产业链的价格传导机制**。


图上展示的就是能源板块的一个产业链。比如煤炭，除了国家的政策会影响到煤炭的生产之外，衍生品的情况也有影响。煤炭的衍生品也就是产业链下游，就是焦煤、焦炭，还有动力煤。动力煤是用来发电的，焦煤焦炭是用来炼钢的，第一步先练成粗钢，然后粗钢再炼成螺纹钢和热轧卷板，同时钢这个黑色品种又和铁矿石有关系，铁矿石除了炼钢之外，它还有像锰铁锰硅之类的一些副产，研究人员在这个平台上可以把这个品种的整个上下游产业链和它的关联关系去描绘出来。

**对研究人员本身来说，他借助这个平台可以提升自己的知识，同时这个平台在使用过程中也会逐渐的增强自身的能力和价值**。



## 场景二：金融事件分析

![五矿期货知识图谱应用场景二：金融事件分析](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/20.jpeg)

第二个场景是金融事件分析。因为期货行业的价格影响，除了既有的产业链模型之外，还有很多突发性事件，类似于黑天鹅事件， 所以舆情或者资讯对商品的价格可能也会有很大的影响。

所以我们也做了这样一个模型，而且这个模型会持续地去打上时间的标签，因为时间对行情的影响是有很大的影响的，越老的资讯可能影响度就更低一些。

![五矿期货知识图谱应用场景二：金融事件分析](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/21.jpeg)

举个例子，年初的俄乌战争对期货市场上的行情影响比较大，主要影响是两个，一个是镍这个品种大家可能都知道或者都看到过。因为俄罗斯是镍主要的供应国，发生战争之后，俄罗斯的镍不能够给中国出口，所以导致镍出现了极端的行情。同时，下游产品像不锈钢主要是用镍去生产的，所以间接也影响到不锈钢这个品种的价格走势。

所以我们希望能够以关联这个数据为基础，从期货行业固有的逻辑和实时事件双管齐下，通过平台实时洞察不同事件组合对特定商品价格影响的强度，同时也随时观察期货相关联的历史事件。

## 场景三：合规风控

![五矿期货知识图谱应用场景三：合规风控](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/22.jpeg)

场景三是合规风控，因为期货行业是一个高风险行业，所以无论是监管机构，还是期货公司自身的风控要求都十分严格，合规风控能力也是我们一个核心竞争力。

一般来说，我们有两类风控模型，一个是不同的客户在同一个 MAC 地址下，买卖期货合约品种以及它的交易行为时间点高度一致，它可能会存在“拖拉机账户”，也就说是一个客户操控了多个账户，这在期货行业里是不允许的。**通过图上的交叉关系或者汇聚的密集程度，合规风控人员很容易地去判断出这类行为**。

另外一类就是同一个账户，同时存在多个交易的 IP 和 MAC 地址，这类行为可能是有配资嫌疑的，结合其他数据和模型，我们可以更加精准地判断它是否存在配资的嫌疑。这对合规风控来说，极大提高了它的判断能力，我们可以对这类交易进行提前的干预，有效避免合规风险。

## 场景四：客户洞察

![五矿期货知识图谱应用场景四：客户洞察](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/23.jpeg)


第四类场景是客户洞察，我们基于客户交易行为进行汇总，把他们进行一些社群划分，比如感兴趣交易哪些品种、感兴趣哪类研报，我们把这些作为划分依据，用于进行相对精准的一些推送。

因为期货行业服务的同质化比较严重，所以我们也希望能够通过数据来做数字化的运营，**给客户提供差异化的服务和精准营销，实现更好的客户体验**。

## 场景五：智能运维 AIOps

![五矿期货知识图谱应用场景五：智能运维AIOps](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/24.jpeg)

AIOps 是我们最近才梳理的一个场景。像我们公司有十几个机房部署在全国各地，可能有上千台服务器，整个交易系统会产生大量的数据和日志等，而且不同的机房不同的系统之间网络也都是通的，一些应用组件都是互相调用的关系，它其实本身就是一个巨大的网络。


所以我们把这些运维的数据，服务调用的数据，还有批量作业数据设备部署的数据以及系统运行的日志数据，整合到这个平台里，然后把他们的关系提取出来，实体也提取出来，构建这样一个智能运维的模型。


我们可以更加细化到具体的运维设计场景，比如说故障影响分析，当某个节点或设备出现故障时，和它有关联的系统或应用也可能会存在问题。接下来根据业务调用关系，它（故障）有可能会传达到别的系统，还有可能会影响到不同类型的客户，所以我们要把关系描绘出来，以进行一些系统切换或故障通知等等。


另外就是变更，因为业务系统 80% 的风险，或者说它的故障运维事件，都是因为这个系统升级变更造成的。升级某一个组件可能会影响到哪些系统、哪些客户需要哪些部门的人去做一些干预或协调、怎么更好地去应急等，我觉得在图谱上都可以实现，以便更好地指导我们的日常运营工作。

还有像系统架构的分析，像系统架构合不合理、有没有存在单点的故障，这些我觉得都可以在图谱这个平台上去实现。

## 场景六：网络安全

![五矿期货知识图谱应用场景六：网络安全](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/wukuang-graph-database-practice/26.jpeg)

另外一个就是网络安全，这块我们觉得也是可以应用到的。因为我们现在有这样一个安全监控平台，它的规则是基于系统产生的日志，如果日志发生了或者是平台感受到它和现有的规则不匹配，系统会产生告警信息。但是告警信息是一种孤岛， 哪里出现问题哪里告警，但是**我们希望能够把整个安全模型构建出来，然后找出故障的传导机制，进而分析出它可能会对哪些系统或者说网络安全环境造成影响**。

另外一个就是攻击行为或者说病毒，通过知识图谱可以更加方便、有效地回溯它的路径或者预测攻击行为，这样能够更加智能化地去辅助我们的安全管理人员去做好安全管理工作。

所以安全知识图谱，我们认为是作为安全领域的一个专用知识图谱，**它可以结合安全知识经验和数据发挥知识整合的优势，将离散分布的多元异构的安全数据组织起来，加速安全领域的智能化和自动化**。

# 总结&期望

作为第一家和 NebulaGraph 合作的期货公司，我们很荣幸，也希望更多的技术专家能够关注到期货这个行业，能够输送人才去指导期货行业金融科技的发展。所以最后感谢悦数科技，谢谢大家。


---

- **相关推荐**：

[《美团：图数据库平台建设及业务实践》](https://www.nebula-graph.com.cn/posts/meituan-graph-database-platform-practice)

[《中国移动：NebulaGraph 图数据库在金融风控领域的落地应用》](https://www.nebula-graph.com.cn/posts/cmcc-financial-riskcontrol-practice)

[《快手：百亿级图数据在快手安全情报的应用与挑战》](https://www.nebula-graph.com.cn/posts/kuaishou-security-intelligence-platform-with-nebula-graph)

[《微众银行：NebulaGraph 在微众银行数据治理业务的实践》](https://www.nebula-graph.com.cn/posts/practicing-nebula-graph-webank)

[《泰康在线：图数据库在理赔反欺诈及数据治理中的实践》](https://www.nebula-graph.com.cn/posts/tk.cn-knowledge-graph-practice)


高性能的原生分布式图数据库 NebulaGraph 目前已被 1000+ 企业采纳并应用于金融风控、实时推荐、知识图谱等多个场景， 欢迎点击 [下载《图技术应用案例集》 PDF 版](https://www.nebula-graph.com.cn/download-white-book) 查看更多真实用户分享～








五矿期货是世界 500 强企业中国五矿集团旗下的金融企业，作为首家使用 NebulaGraph 图数据库的期货公司分享了知识图谱平台在期货投资领域的应用和未来实践方向的探索及心得。

五矿期货：NebulaGraph 图数据库在金融期货行业的应用与实践探索

> 本文整理自 中国移动算法工程师 汪海涛 在 NebulaGraph 2022 年度用户大会上的分享，现场视频如下——

<video width="100%" height="500" controls>
  <source src="https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/videos/nuc-2022/speaker-wanghaitao-chinamobile.mp4" type="video/mp4">
</video>

各位朋友上午好，我是来自中国移动的算法工程师汪海涛。接下来我主要聊一聊图数据库在中国移动，特别是金融风控场景的落地应用。

# 为什么中国移动要建设图平台？

## 「全国 9 亿用户，每天产生大量数据」

中国移动有非常多的数据，全国的用户每天都会产生海量的数据。**如何从这么大数据量里面挖掘出有用的信息，然后用到金融风控场景？这就是我们需要做的事情**。

之前，我们是以手机号为维度去提取特征，然后去做一些模型或规则判断一个手机号是否是有违约风险。但仅仅基于手机号很难综合去考虑风险情况，因此我们就想采用图计算技术去综合看一个手机号以及周围的其他手机号的信息，然后共同评判它的风险。

最开始是基于消费金融的场景，从比如说像蚂蚁金服、微信以及京东白条这样一些产品切入，通过用户通话数据、短信数据、设备等多维度的一些信息，去判断用户风险。但中国移动数据量这么大，**不管我们要做什么，最大的诉求就是需要有一个非常高性能的平台去支撑数据分析**。

# 为什么选择 NebulaGraph 图数据库？

## 「JanusGraph vs TigerGraph vs NebulaGraph」

我们最早是采用了 JanusGraph 加上 Spark 去建设我们平台，但是通过一些测试，我们发现 JanusGraph 的查询性能以及导入性能都比较一般，然后 GraphX 的话，它的计算性能其实也比较一般，特别是它需要的内存量特别大，因此我们后来又开始去调研了市场上很多的图产品，并且对一些图产品做了测试，包括国外的产品，像 TigerGraph 之类的等等，但是因为一些特殊原因，中国移动是在美国商务部的实体清单上，所以很多外国的产品我们是没法去采购和使用的。

因此最后，我们是选择国内的几家厂商进行了一些测试和比较，**最后选择了以 NebulaGraph 作为图数据库，然后以 Plato 作为图计算引擎这样一个整体的架构**。


# 中国移动是如何搭建图平台的？

## 图平台建设概况

![中国移动_以NebulaGraph为底座的图数据库平台概览图](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/4.jpeg)

我们整体的架构大概是这样的——

**最底层是我们的数据源**，中国移动建设有一个全国大数据中心，主要包括通话数据、位置数据、消费数据、设备数据、用户数据和 APP 数据等等，我们每月把这些数据抽取到 HDFS 里面，然后把其中有用的数据抽取到 NebulaGraph 数据库里面，那么这里用的就是 Nebula 的一个导入工具，这是我们图数据存储这一层。

**再上一层是计算分析层**，这也是我们建模和业务分析人员主要使用的一些框架。首先第一个是 Plato，它是腾讯之前开源的一个图计算引擎，但是据我所知腾讯现在已经不维护这一套引擎了，因此我们也是专门找一些工程师，然后去维护这里面的一套框架，以及修复一些小 bug 之类的。

那么它包含的算法其实很多的，这里我主要是列举了两个社区发现算法、Louvain 算法和 HANP 算法。它里面还包含一个 LPA 算法，因为LPA 算法的话是 HANP 算法一个简化版，所以这里我没有列出来。

然后里面还有一个我们有可能后面会用到的关于随机游走类的算法，主要是基于随机游走得到一个节点序列，会为我们后面用于图神经网络训练做一个前期数据预处理的工作。

第三个是 GNN，就是图神经网络。图神经网络是最近几年兴起的一个领域，我们现在主要是基于这些模型做一些简单的产品，看看能不能取得比以往的方法更好的一些效果。最后就是基于 NebulaGraph 查询语言，主要就是 go 语句和 fetch 语句做一些简单查询。

**再上一层的话就是应用层**。首先是关联风险分，关联风险分主要是基于配套的社区发现算法来做的。第二个号码风险分和最后一个催收分析主要是基于 Nebula 的查询语句来做的，主要就是查询用户跟一度、二度联系人以及一些违约用户，或是催收专用号码进行一些主动或被动的呼叫。第三个信用评分卡是基于图神经网络来做的，主要是用逻辑回归或者决策树之类的模型，希望通过图神经网络做一些提高。

## 图数据结构介绍

![中国移动_导入图数据库的点边数据结构](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/7.jpeg)

- **点数据**

点数据主要是有四类，第一个是手机号，手机号也是我们最重要的点数据，主要是包括比如这手机号它是属于哪个市的，是否发生过停机等等，还有一些消费信息。第二个是地理位置，主要基于基站。第三个身份证，作为唯一身份证识别，可能也会有年龄或学历之类的标志。最后是设备信息，一般手机会有一个设备值，有对应的型号、设备系统等。

- **边数据**

目前边数据的话，一个是用户跟用户的通话数据，第二个是手机号和身份之间的对应关系，第三个是手机号和设备之间对应关系，第四个是手机号跟地理位置之间对应关系，那么这些是我们在图数据库里面保存的一些数据。


# 图技术在中国移动有哪些应用？

## 应用1：号码风险分

![中国移动_怎样建立号码风险分模型](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/8.jpeg)

首先是号码风险分模型，**主要用在羊毛党识别这个场景**。我们会根据用户的通话流量位置以及手机行为信息去判断一个号码有没有可能是个羊毛党，主要通过四个模块——

第一个是接码模块，我们会跟一些外面数据公司合作，判断一个号码有没有可能是一个接码号码，如果是，我们会认为这个号码是薅羊毛的可能性就很大。

第二个行为异常号码，比如说这个手机号是否当月一次通话都没有，然后是不是每月都基本只有固定的月租这样的消费。这种号码我们认为它可能是一个小号，或者是专门用来去薅羊毛的号码。

第三个是位置异常，比如说这个手机是否一个月下来就是在一个位置从来没有动过，可能只是放在家里偶尔用一下，不会带出去这种。对于这种号码的话，我们认为它的风险也是相对比较大的。

![染灰模块是什么、怎样实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/9.jpeg)

**第四个是染灰模块，图技术主要就是用于这个模型**。基于前三个模块的结果，我们首先获得了一批已经确定的羊毛党用户，那么我们可不可以发现他的一些共同特征？比如说可能有几个羊毛党（号码）是属于同一个用户的，那么我们是不是可以看看这个用户下面其他手机号是不是也可能是羊毛党？

另外，如果发现有一堆手机号是之前在同一个设备上使用过，我们可能也会认为这个设备上对应的其他手机号也可能会是一些羊毛党。专业的羊毛党会采用卡池这种设备专门去薅羊毛，用图技术就可以快速发现并识别。


## 应用2 ：关联风险分

![关联风险分是什么以及应用场景](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/10.jpeg)

然后是关联风险分，通俗来说就是「近朱者赤近墨者黑」。

在平时交际圈，如果你的违约可能性比较低，那么周围人可能违约性也会比较低。基于这样一种想法，我们主要做法就是首先基于移动所有用户构建一个关系网络，然后采用一些社区发现类的算法去挖掘这个社区中个人的评分以及个人之间的关系，通过对这个社区打分，去识别出这个社区是否是欺诈或低信用社区。

**关联风险分的主要应用场景就是欺诈领域，比如信贷欺诈、交易欺诈、营销欺诈、支付欺诈以及账户欺诈等等多个方面**。

## 应用3：图神经网络（GNN）

![图神经网络在中国移动的应用](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/12.jpeg)

最后是关于图神经网络的一些应用，**主要是用于金融风控信用评分卡的场景**。过去我们用做信用评分卡大部分都是先提取用户特征，再然后训练一个逻辑回归模型或者是角色数字类的模型。

那么现在，我们想通过图神经网络做一些模型，通过用户之间通话数据，比如近三个月主动通话、被动通话以总通话次数是否达到要求，去判断要不要保留这样一条边。

我们大概提取 100 多个主要的特征去录模，这里的模型相对来说比较简单，目前是尝试了一个双塔的模型，左边的是关于图神经网络聚合的这样一个模型，右边用户特征本身的一个全连接网络做了这样 MLP 的模型。左边的神经网络聚合，是比较简单也是最常用的——GCN、GrapSAGE 和 GAT 这三个模型。

另外我们现在采用的是一个同构图的网络建模，后面可能会考虑异构图，比如说考虑用 HAN 这样的一些异构图的模型去建模，把用户的身份证和设备以及位置信息这些点都归纳进来，然后一起进行建模。

# 图数据应用的未来展望

![中国移动_图数据库平台的未来展望](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/NUC2022/cmcc-financial-riskcontrol-practice/14.jpeg)

## 1.数据血缘

中国移动大数据中心会提供给大概 30 多家客户的 50 多个项目进行共同的建模，建模工作里包含的数据维表会特别多，因为我们会给每个用户都匹配数据，然后帮他们生成特征，最后会把结果表也保存在数据库里面，大概现在有 1000 多张数据表，平时基本靠人工管理，后面看看能不能通过数据血缘的方式去做一个归纳。

## 2.图神经网络

中国移动除了大数据中心，还有人工智能中心，那里有很多的 GPU 资源进行人工神经网络的训练，但是目前模型训练效率比较低下，所以后面看看怎么用图数据技术去解决这个问题。


- **相关推荐**：

[《美团：图数据库平台建设及业务实践》](https://www.nebula-graph.com.cn/posts/meituan-graph-database-platform-practice)

[《五矿期货：图数据库在金融期货行业的应用与实践探索》](https://www.nebula-graph.com.cn/posts/wukuang-graph-database-practice)

[《快手：百亿级图数据在快手安全情报的应用与挑战》](https://www.nebula-graph.com.cn/posts/kuaishou-security-intelligence-platform-with-nebula-graph)

[《微众银行：NebulaGraph 在微众银行数据治理业务的实践》](https://www.nebula-graph.com.cn/posts/practicing-nebula-graph-webank)

[《泰康在线：图数据库在理赔反欺诈及数据治理中的实践》](https://www.nebula-graph.com.cn/posts/tk.cn-knowledge-graph-practice)

---
想要感受  NebulaGraph 企业版的最新特性？
点击 [链接](https://www.nebula-graph.com.cn/contact)，立刻开启您的图数据库之旅！


拥有9亿多用户的中国移动基于NebulaGraph 图数据库搭建的图平台在金融风控领域有哪些落地应用？一起来看中国移动的算法工程师汪海涛在NUC2022上的精彩分享。

中国移动：NebulaGraph 图数据库在金融风控领域的落地应用

同盾科技是一家专注决策智能的人工智能企业，其基于 NebulaGraph 图数据库技术打造的知识图谱平台在金融保险、政府公安、互联网等行业有广泛应用，一起来了解下这套全栈式解决方案的优势以及NebulaGraph 在其中发挥的重要作用吧。

同盾科技：聊聊知识图谱在金融风控场景中的应用｜NUC2022



![58 同城基于 NebulaGraph 一键部署运维架构的实践](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58%E5%90%8C%E5%9F%8E_%E7%94%BB%E6%9D%BF%201.jpg)

# 图计算业务背景介绍

## 我们为什么选择 NebulaGraph？

在公司各个业务线中，有不少部门都有着关系分析等图探索场景，随着业务发展，相关的需求越来越多。大量需求使用多模数据库来实现，开发成本和管理成本相对较高。

随着图数据库的发展，相关系统应用越来越成熟，于是引入专业图数据库来满足这部分业务需求的事务也提上日程。接下来要考虑的问题就是图数据库选型了。

首先，NebulaGraph 有大量互联网大厂应用案例，说明 NebulaGraph 可以应对海量数据的图探索场景。另外，目前 NebulaGraph 在 DB-Engines 在图数据库领域排名 14，而且增长势头强劲。排名靠前的图数据库，部分不开源或者单机版开源，场景受限。

![图计算业务背景介绍](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-1.png)

## NebulaGraph 实际测试表现如何

在导入性能上，数据量小的时候 NebulaGraph 的导入效率稍慢于 neo4j，但在大数据量的时候 Nebula Graph 的导入明显优于其他两款图数据库。在 3 种查询场景下，NebulaGraph 的效率都明显高于 neo4j，与 HugeGraph 相比也有一定的优势。

![图计算业务背景介绍](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-2.png)

## 适用场景有哪些

公司有多种线上业务，工程复杂度和架构复杂度都较高，各个业务部门都需要专门的图数据库来实现对实体关系数据的处理和探索。

通过图数据库实现对任务依赖的运行时间进行监控，及时获取延迟任务、销售激励平台任务血缘关系处理、分析应用内部的类/方法级调用关系、业务风险数据分析、记录企业高管、法人、股东关系，用于签单业务等场景。

## 资源申请和集群管理方式

为了更好的管理和维护，图数据库在运维部门集中运维管理。用户按需在工单平台中提交申请即可，工单中填写详细的资源需求数据和性能需求指标，由运维同学统一审核交付集群资源。

公司目前服务器环境是自建机房，采用高配物理机，单机多实例混部数据库服务。为了实现规模化管理和维护，需要提前制定好实例标准和规则。

## 集群规模

得益于NebulaGraph良好的图计算能力，我们已经持续交付集群接近20套，目前还有业务部门在持续申请相关集群服务资源。


# NebulaGraph 规范和架构设计

由于需要满足大量业务需求，未来会有大量的集群需要交付和维护。为了高效管理和运维规模化的集群，需要提前规划和制定规范。

## 版本规范

目前使用版本为 2.0.1

## 路径规范

1）、程序路径为 /opt/soft/nebula201,该路径下有 bin、scripts、share 等，作为公共的服务依赖路径，从服务路径中抽离出来

同样，升级为 3.X 版本，只需要将程序路径抽离出来作为公共的服务依赖路径即可。

2）、服务路径为 /work/nebulagraph+graph 端口，该路径下有 data、etc、logs、pids

## 端口规范

1）、集群之间端口递增 5，因为 storage 副本需要端口通信，通常是 storage 端口 -1，例如两套集群 graph 端口分别是 60000 和 60005;

2）、每种服务端口和 http、http2 端口之间步长为 10000，例如 graph 端口是 60000，ws_http_port 就是 50000 ，ws_h2_port 就是 40000；

3）、三种服务端口之间相差 1000，例如 graph 端口是 60000，meta 端口就是 61000，storage 端口就是 62000；

60000 graph 端口；  50000 ws_http_port；40000 ws_h2_port

61000 meta 端口；   51000 ws_http_port；41000 ws_h2_port

62000 storage 端口；52000 ws_http_port；42000 ws_h2_port

## 运维规范

1）、创建 space 需用 ngdb_ 左前缀，分片默认是节点数的 2 倍，副本数默认为 2，参考 CREATE SPACE `ngdb_demo` (partition_num=6,replica_factor=2,charset=utf8,collate=utf8_bin,vid_type=FIXED_STRING(128),atomic_edge=false) ON default;

2）、授予业务账号 DBA 角色：GRANT ROLE DBA ON ngdb_demo TO demo_wr;

3）、搭建一套 NebulaGraph 集群后，将内置账号 root的 密码重置，之后将 /work/nebulagraph+graph 端口路径打包生成 rpm，作为标准安装包

![NebulaGraph 规范和架构设计](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-3.png)

服务请求直接通过 DNS 和网关服务到 Graph，方便计算和存储服务直接交互，由于是通过 DNS 访问，不对外暴露 Meta 节点信息，可以更灵活的运维，较少服务绑定 Meta 节点 ip 带来的运维代价。

这种架构限制了Java 等驱动的访问，需要用其他驱动替代。

4）、基础集群套餐是 3 个 Graph 节点、3 个 Meta 节点、3 个 Storage 节点，在保证高可用的同时也能保证足够的处理能力。

基础集群分布在 3 台物理机上，存储和计算不需要过多的网络交互。

![NebulaGraph 规范和架构设计](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-4.png)

# 集群部署自动化实现

为了能够一键部署服务，集中式管理服务，我们需要借助远程管理工具 Ansible，能帮我们做到快速部署。依据三种角色服务的端口规范，生成 ansible 的配置文件。

![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-5.png)

* 由于将版本信息写到了配置文件中，在兼容多版本场景下，只需要在bootstrap.yml文件中增加相应判断即可，主程序兼容多版本成本非常有限。

部署实例时，根据 graph 角色分发文件，也可以每个节点单独分发文件。

* 依据三种角色，分别分发配置文件到目的路径下，并且按照文件命名规则生成最终配置文件。


```
more bootstrap.yml
- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init elasticsearch file on data
      command: cp -r /opt/soft/nebulagraph201 {{ nebula_home }}

- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init config graphfile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201graph dest="{{ nebula_etc }}nggraphd.conf" owner=root group=root mode=0755
- hosts: meta
  become: yes
  remote_user: root
  tasks:
    - name: init config metafile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201meta dest="{{ nebula_etc }}ngmetad.conf" owner=root group=root mode=0755
- hosts: storage
  become: yes
  remote_user: root
  tasks:
    - name: init config storagefile on master {{ version }}
      template: src=/opt/soft/ngdeploy/conf/templates/201storage dest="{{ nebula_etc }}ngstoraged.conf" owner=root group=root mode=0755
```

配置文件的分发最为关键，有较多变量需要处理，这些变量需要提前在 ansible 的配置文件中定义，nebulagraphd 路径规范和服务端口需要使用 graphport、meta_server_addrs 需要用到 for 循环语法实现。

```
more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{ graphport }}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{ graphport }}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{ graphport }}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{ graph_h1_port }}
--ws_h2_port={{ graph_h2_port }}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password
```

同样，nebulametad 服务配置文件路径规范和服务端口需要使用 metahport、meta_server_addrs 需要用到 for 循环语法实现。
```
more templates/201meta 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{graphport}}/pids/nebula-metad.pid
########## logging ##########
--log_dir=/work/nebulagraph{{graphport}}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=metad-stdout.log
--stderr_log_file=metad-stderr.log
--stderrthreshold=2

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--port={{metaport}}
--ws_ip={{inventory_hostname}}
--ws_http_port={{meta_h1_port}}
--ws_h2_port={{meta_h2_port}}
########## storage ##########
--data_path=/work/nebulagraph{{graphport}}/data/meta

########## Misc #########
--default_parts_num=100
--default_replica_factor=1
--heartbeat_interval_secs=10
--timezone_name=CST-8
```

同样，nebulastoraged 服务配置文件路径规范和服务端口需要使用 storageport、meta_server_addrs 需要用到 for 循环语法实现。

```
more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{ graphport }}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{ graphport }}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{ hostvars[host].inventory_hostname }}:{{ hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{ graphport }}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{ graph_h1_port }}
--ws_h2_port={{ graph_h2_port }}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password
```

需要部署新集群时，需要按照规则和目的服务器信息生成 ansible 的配置文件，然后调用 ansible-playbook，按照 bootstrap.yml 定义的行为执行即可。

![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-10.png)

部署完毕之后，需要按照服务角色依次启动 start.yml 的脚本文件提前定义好三种服务的启动命令和配置文件。

![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-11.png)

调用 ansible-playbook，根据 start.yml 的脚本文件依次执行三种服务的启动命令即可。
![集群部署自动化实现](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-15.png)

# 可视化图探索平台

有赖于将目标 host 前置于 web 平台的设置，我们只需要对多个项目的开发提供一套公共的 web 平台即可，减少了 NebulaGraph 集群的组件数量，有别于 ELK 的标准架构。

![可视化图探索平台](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-12.png)

开发可以通过 NebulaGraph Studio实现可视化管理数据，轻松实现数据导入和导出，便于用户探索数据关系。直接呈现出点边关系，使探索图数据之间的关系更为直观。

 ![可视化图探索平台](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/58.%20Com%20Inc/58-13.png)

以上是我们在规模化管理维护 NebulaGraph 集群过程中的一些经验，希望对大家有些帮助。

___
交流图数据库技术？加入 NebulaGraph 交流群[请先填写下你的 NebulaGraph 名片](https://wj.qq.com/s2/8321168/8e2f)，NebulaGraph 小助手会拉你进群~~

NebulaGraph 的开源地址：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula) 
觉得使用体验还不错的话，给我们的 GitHub 点个 ❤️ 鼓励下开源路上的我们呢~




58 同城在应对业务所需的关系分析等图探索场景时，经过多个图数据库产品的对比后，选择 NebulaGraph 部署其运维架构。

58 同城基于 NebulaGraph 一键部署运维架构的实践

携程经过多个图数据库产品的调研，最终选择 NebulaGraph 用于其运维治理的解决方案，主要基于 NebulaGraph 的横向扩展能力、自研的原生存储层、兼容主流的图技术语言 openCypher、社区活跃且用户知名度高等因素。

携程：基于分布式图数据库 NebulaGraph 的运维治理实践

苏宁通过 CMDB、调用链等数据构建软硬件知识图谱，在此基础上通过历史告警数据构建告警知识图谱，并最终应用知识图谱进行告警收敛和根因定位。本文主要包括运维知识图谱构建、知识图谱存储、告警收敛及根因定位等内容。

苏宁基于 NebulaGraph 构建知识图谱的大规模告警收敛和根因定位实践


> 本文整理自微众银行大数据平台：周可在 nMeetup 深圳场的演讲，演讲视频参见：[B站](https://www.bilibili.com/video/BV1Pr4y1F7kA/?vd_source=1938285003b2fa2c63998dac65e1876e)

![微众银行用 NebulaGraph 进行数据血缘治理的实践](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/case-webank/webank_01.jpg)

# 公司简介

微众银行是国内首家互联网银行，专注为小微企业和普罗大众提供在线金融服务。为了对全局数据的来源及影响范围进行实时检测和深度分析，从2020年开始微众银行将 NebulaGraph 接入了他们的大数据平台，目前全行 AIOps 都已经接入 NebulaGraph 平台。

# 业务挑战

1. 随着业务的扩展和数据来源的增长，互联网交易风险也呈指数增长。
2. 用户的信息来源，分析数据的血缘来源及影响范围决定了业务的稳定性和风险预警。
3. 如何在前线业务的压力下快速发现数据问题、快速分析&响应。

# 解决方案

## NebulaGraph 数据血缘治理方案 

银行业务开展过程中经常面临着大量数据分析、数据来源分析的问题，基于 NebulaGraph 搭建的数据系统，能够快速导入大规模数据，并进行低时延的实时计算，最终帮助银行生成一份数据地图；它采集了各个数据源的数据，并通过微众自有的大数据平台对数据进行加工存储，最后返回一份全行完整的数据资产 / 数据字典。

此外，NebulaGraph 确保在整个构建过程中，大数据平台的结构完全符合银行数据治理的规范和要求，免除了银行客户的后顾之忧。

![微众银行-NebulaGraph-整体架构图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/webank-case-p1.jpeg)

**血缘数据实时查询**：以某个表为起始节点遍历得到上游表和下游表；服务端通过 Nebula Java Client 连接 NebulaGraph 查询得到血缘关系。

![微众银行-NebulaGraph-血缘数据实时查询界面](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/webank-case-p2.jpeg)

上图就是以蓝色表为中心数据查询下游的一度关系表和上游的一度关系表，NebulaGraph 的大数据平台支持在构建图数据库数据模型时加入时间属性，因此可基于时间维度进行数据过滤和检索，比如：某区域的个人贷款业务表从昨天到今天的数据产生、流转变化情况等，都可以通过快速索引实现实时查询。

**血缘数据批量分析**：以某个租户、某个部门的表、某个产品的表为起始节点批量分析得到这些表的上游表和下游表的完整链路；大数据任务通过 Nebula Spark Connector 连接 Neubla Graph 批量导入点数据和边数据，使用基于 GraphX 实现的算法批量分析得到完整的血缘链路。

![微众银行-NebulaGraph-异地容灾数据结构图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/webank-case-p3.png)

**数据异地容灾备份**：主要依赖于 NebulaGraph 本身提供的容灾特性，比如：Checkpoint。系统每天将 Checkpoint 做数据备份同步到异地的容灾集群，一旦主集群出问题，即刻切换系统到异地灾备集群，确保数据不丢失不遗漏，大大提高了数据安全性。

# 技术选型

JanusGraph ：
1. 性能较差：功能实现依赖其他数据组件，后续稳定性不能保证
2. 非分布式：存储依赖Hbase，无法满足银行业“两地三中心”架构规范要求
3. 维护成本高：不支持高可用，处理大规模数据需要花成本解决很多技术问题

NebulaGraph：
1. 性能更强大：经过测试相较于同类竞品，NebulaGraph 查询和导入性能更优秀
2. 原生分布式：支持集群模式，具备存储和计算的横向扩展能力，更加符合银行场景下的分布式和高可用要求
3. 生态系统全：Nebula Spark/Flink Connector、NebulaGraph Exchange 提供了和大数据平台数据流结合的能力
4. 运维服务好：社区、群组反馈及时

# 使用效果

**大规模数据处理能力提升**：NebulaGraph 强一致特性，具较强的读写平衡能力，同时能达到每秒百万行级的导入能力，实现了数据血缘场景下的实时和批量查询的要求。

**系统部署成本得到降低**：NebulaGraph 分布式及存算分离的架构，具备较好的计算和存储层横向扩展能力及电信级高可用能力，能够满足数据和业务动态扩缩容要求，确保集群运行稳定。

**大数据生态兼容性更好**：Nebula Spark/Flink Connector、Nebula Exchange提供了良好的大数据生态兼容能力，有效降低了用户使用门槛。

除了产品性能，微众银行更看重是否能满足银行业所要求的安全性架构支持，NebulaGraph 的**原生分布式**属性正能满足这一要求。除此之外，NebulaGraph **优秀的开源生态能帮助企业构建一个完整的数据流的平台，提高了金融场景下处理大规模数据的效果和速度**。

---

交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![关注公众号](https://www-cdn.nebula-graph.com.cn/nebula-blog/WeChatOffical.png)


本文介绍了微众银行使用 NebulaGraph 分析数据血缘及影响范围，解决金融行业在互联网业务场景中面临的数据量突破式增长、风控能力不足、数据问题发现不及时等问题，帮助企业全面提升业务稳定性和风险预警能力。

微众银行：利用 NebulaGraph 进行全局数据血缘治理的实践

携程金融从 2020 年开始引入大规模图存储和图计算技术，基于 NebulaGraph 构建了千亿级节点的图存储和分析平台，并取得了一些实际应用成果。

干货 | 百亿节点，毫秒级延迟，携程金融基于 NebulaGraph 的大规模图应用实践

本文主要分享 OPPO 知识图谱建设过程中算法相关的技术挑战和对应的解决方案，主要包括实体分类、实体对齐、信息抽取、实体链接和图谱问答 query 解析等相关算法内容。

OPPO 自研大规模知识图谱及其在数智工程中的应用


> 本文整理自智联招聘资深工程师李世明在「[智联招聘推荐场景应用](https://www.bilibili.com/video/BV1k94y1d7jd)」的实践分享

![智联招聘的推荐实践分享](https://www-cdn.nebula-graph.com.cn/nebula-blog/zhilian-graph-database-practice.jpg)

# 搜索推荐架构

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-01.jpg)

在讲具体的应用场景之前，我们先看下智联招聘搜索和推荐页面的截图。
这是一个简单的智联搜索页面，登录到智联招聘 App 的用户都能看到，但是这个页面背后涉及到的推荐、召回逻辑以及排序概念，是本文的重点。

## 功能矩阵

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-02.jpg)

从功能上来说，从矩阵图我们可以了解到做搜索和推荐时，系统分为 Online 和 Offline 两个部分。

在 Online 部分，主要涉及到实时操作，例如：搜索某个关键词、实时展示个人推荐。而这些功能性操作需要其他功能支持，比如：热词联想，以及根据特定的输入进行实体识别、意图理解，或是个人用户画像的绘制。再下一步操作便是召回，利用倒排索引，根据文本、相似度匹配，以及引入 [NebulaGraph](https://nebula-graph.com.cn/) 实现图索引、向量索引，都是为了解决召回问题。最后，便是搜索结果的展示——如何排序。这里会有个粗排，比如常见的排序模型 [TF/IDF](https://zh.m.wikipedia.org/zh/Tf-idf)，[BM25](https://en.wikipedia.org/wiki/Okapi_BM25)，向量的[余弦相似](https://zh.m.wikipedia.org/zh-hans/%E4%BD%99%E5%BC%A6%E7%9B%B8%E4%BC%BC%E6%80%A7) 等召回引擎排序。粗排后面是精排，即：机器学习的排序，常见的有线性模型、树型模型、深度模型。

上述为在线 Online 流程，相对应的还有一套 Offline，离线流程。离线部分主要是整个业务的数据加工处理工作，把用户的相关行为，例如：数据采集、数据加工，再把数据最终写到召回引擎，像是上文提及过的倒排索引的 Solr 和 ES、图索引的 NebulaGraph 以及向量索引的 [Milvus](https://milvus.io/)，以提供线上的召回能力。

## 线上架构

![在线架构](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-03.jpg)

当一个用户点击了智联招聘的搜索按钮，会发生什么呢？如上图所示，经过一个 API 调用，再通过 Query DSL 的统一封装加工，再进入三路（之前提过的倒排索引、图索引和向量索引）召回，机器学习排序，最终将结果返回到前端进行展示。

## 离线架构

![离线架构](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-04.jpg)

如同上面功能矩阵方面介绍的那般，离线部分主要是数据的加工处理，将诸如 HBase、关系型数据库 PostgreSQL、KV 数据库 TiDB 之类的数据平台通过数据链路进行加工，最终写入到数据存储层。

## 整体业务流程

将在线和离线架构进行整合，下图细化了 API 请求的处理、缓存、分页、A/B Test、用户画像、Query Understanding、多路召回等流程。

![整个架构](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-05.jpg)

## 平台架构

介绍了线上和离线的功能架构，现在来讲下智联招聘是如何支撑整个功能矩阵的。

![平台架构](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-06.jpg)

从底层来说，智联技术团队是通过构建了这三个平台来支撑整个功能矩阵的。

首先最上方就是我们整个的搜索推荐架构平台，分为数据处理、聚合层、机器学习三个模块。在数据处理模块，主要用来完成数据加工、数据同步、数据合并、格式转换等数据层事项；聚合层则处理意图识别、AB 测试、在线召回、排序模型；而机器学习模块，主要用来做特征加工、特征抽取、模型更新之类的事情。

在搜索推荐架构平台下方，便是搜索召回引擎，由 Solr、Elasticsearch、NebulaGraph、Milvus 组成，分别负责倒排索引、图索引和向量索引。

最下层，是大数据平台，对接 Pulsar、Flink、HBase、HIVE、Redis、TiDB 等数据源。

# NebulaGraph 在推荐场景下的应用

## 智联的数据规模

智联这边线上环境部署了 9 台高配物理机，机器配置的话 CPU 核数大概在 64~72，256G 左右的内存。每台机器部署 2 个 storaged 节点，一共有 18 个 storaged 节点，查询 graphd 和元数据 metad 节点分别部署了 3-5 个。线上环境目前有 2 个 namespace，一共 15 个分片，三副本模式。

而测试环境，采用了 K8s 部署，后续线上的部署也会慢慢变成 K8s 方式。

说完部署情况，再来讲下智联招聘这块的使用情况，目前是千万级别的点和十亿级别的边。线上运行的话，最高 QPS 是 1,000 以上；耗时 P99 在 50 ms 以下。

下图为智联自研的监控系统，用来看 Prometheus 的监控数据，查看节点状态、当前查询的 QPS 和耗时，还有更详细的 CPU 内存耗损等监控指标。

![监控截图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-07.jpg)
 
## 业务场景介绍

下面来简单介绍下业务场景

### 推荐场景下的协同过滤

![协同过滤模型](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-08.jpg)

推荐场景下有个比较常见的业务是协同过滤，主要用来解决上图左下角的 4 个业务：

1. U2U：user1 和 user2 为相似用户；
2. I2I：itemA 和 itemB 为相似物品；
3. U2I2I：基于物品的协同，推荐相似物品；
4. U2U2I：基于用户的协同，推荐相似用户的偏好物品；

上面 U2U 是在创建 user to user 的某种关系，可能是矩阵（向量级别）相似，也可能是行为级别的相似。1. 和 2. 是基本的协同（相似性），把用户和用户、物品和物品建立好关系，基于这种基本协同再延伸出更复杂的关系，比如：通过物品的协同给用户推荐相似物品，或是根据用户的协同，推荐相似用户的偏好物品。简单来说，这个场景主要是实现用户通过某种关系，可得到相关物品的相似推荐或者是相似用户的关联物品推荐。

下面来分析一波这个场景

### 协同过滤的需求分析

![协同过滤具体模型](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-09.jpg)

具体来说，招聘领域来说，CV（简历）和 JD（职位）之间存在关联关系，聚焦到上图的中间部分，CV 和 JD 之间存在用户行为和矩阵相似关系，像用户查看了某个职位、用户投递了某个职位，或者是企业端的 HR 浏览了某个简历这些用户行为，或者是基于某种算法，都会给 CV 和 JD 建立起某种关联。同时，还要创建 CV 和 CV 之间的联系，也就是上文说到的 U2U；JD 和 JD 之间的关系，就是上面的 I2I。关联创建之后，可以整点有意思的事情——通过用户 A 查看过 CV1（简历）推荐相似的 CV2（简历），用户 B 浏览过职位，也可以根据职位的相似性，给他推荐另外的 JD…这里再提下这个需求的“隐藏”重点，就是需要进行属性过滤。什么是属性过滤呢？系统会根据 CV 的相似度来推荐 CV，这里就要做相关的属性匹配了：基于期望城市、期望薪资、期望行业进行属性过滤。召回的实现一定要考虑上述因素，不能 CV1 的期望城市是北京，你推荐的相似 CV 期望城市却是厦门。

### 技术实现

##### 原先的技术实现——Redis

![Redis 实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-10.jpg)

智联这边最开始实现协同过滤的方式是用 Redis 将关系通过 kv 方式存储起来，方便进行查询。显而易见的是，这样操作是能带来一定的好处：

1. 架构简单，能快速上线；
2. Redis 使用门槛低；
3. 技术相对成熟；
4. Redis 因为是内存数据库的原因，很快，耗时低；

但，与此同时，也带来一些问题：

属性过滤实现不了，像上面说到的基于城市、薪资之类的属性过滤，使用 Redis 这套解决方案是实现不了的。举个例子，现在要给用户推 10 个相关职位，通过离线我们得到了 10 个相关职位，然后我们创建好了这个关联关系，但如果这时候用户修改了他的求职意向，或者是增加了更多的筛选条件，就需要在线来实时推荐，这种场景下是无法满足的。更不用提上面说到过的复杂的图关系，实际上这种查询用图来做的话，1 跳查询就能满足。

##### 再尝试倒排索引实现——ES 和 Solr

![ES 实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-11.jpg)

因为智联在倒排索引这块有一定的积累，所以后面尝试了倒排索引的方式。基于 Lucene 角度，它有一个索引的概念。可以将关系保存为子索引 nested，然后过滤这块的话，子索引中存关系 ID，再通过 JOIN query 实现跨索引 JOIN，这样属性就可以通过 JOIN 方式进行过滤。这种形式相比较 Redis 实现的话，关系也能存上了，属性过滤也能实现。但实际开发过程中我们发现了一些问题：

1. 不能支持大数据量存储，当关系很大时，相对应的单个倒排会特别大。对于 Lucene 来说它是标记删除，先将标记的删除了再插入新的，每次子索引都要重复该操作。
2. 关系较多时 JOIN 性能不好，虽然实现了跨索引 JOIN 查询，但是它的性能并不好。
3. 关系只能全量更新，其实设计跨索引时，我们设计的方案是单机跨索引 JOIN，都在一个分片里进行 JOIN 操作，但这种方案需要每个分片存放全量的 JOIN 索引数据。
4. 使用资源较多，如果跨索引涉及到跨服务器的话，性能不会很好，想要调好性能就比较耗资源。

上图右侧是一个具体的实现实录，数据格式那边是关系的存储方式，再通过 JOIN JD 的数据进行属性过滤，这个方案最终虽然实现了功能但是没在线上运行。

##### 图索引——NebulaGraph

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-12.jpg)

经过我们调研，业界对 NebulaGraph 评价挺高，智联这边用了 NebulaGraph 来实现图索引。像刚在 U2U 和 U2I 的场景，通过图的方式把 CV 和 JD 存储成点，边则存储关系。至于属性过滤，如上图所示将 JD 诸如所在城市、学历要求、薪资要求、经验要求等属性存储为点的属性；而相关性的话，则在关系边上存了一个“分”，最终通过分进行相关性排序。

新技术方案唯一的缺点便是新领域的学习成本，不过在熟悉图数据库之后就方便很多了。

##### 基于 NebulaGraph 的推荐

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-13.jpg)

具体的 CV 推 CV、CV 推 JD、JD 推 JD、JD 推 CV 场景，都能满足，像下面这条语句：


```
match (cv:CV_TAG)-[p]-(jd:JD_TAG) 

    where id(cv)==1 AND p.SALARY>2000

return jd.ID, jd.TITLE, p.score

ORDER BY p.score DESC 

SKIP 0 LIMIT 1000;
```

便是一个 CV 推 JD 的具体 nGQL 语句：通过简历（CV）开始进行查询，经过一些属性过滤条件，比如：薪资，根据边上的相似分进行 ORDER BY 排序，最终返回一个推荐 JD 信息。

整个业务这块，因为关系相对简单，所以这里一共涉及了 5 种 Tag 和 20+ 种边关系，以及创建 100 多种索引，整个数据量在千万级点和十亿级别的边。

# NebulaGraph 使用过程中问题总结

## 数据写入

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-14.jpg)

数据写入这里主要分为了 3 个方面：

首先 T+1 数据刷新。展开来说，因为数据是提前加工的，要给在线业务使用的话，涉及了 T+1 数据刷新问题。刷数据的话，一开始可能是个冷数据，或者是没有数据，刷新的时候是直接写入关系数据，这个边数据可能连起始点都没有。整个边数据刷新之后，就需要将不存在的点插入。所以这里有个改进点，我们先插入点数据之后再写入边数据，这样关系能更好地创建起来。数据刷新这块还有个问题，就是边数据是 T+1 跑出来的，所以前一天的数据已经失效了，这里就需要把已经存在的关系删掉，再将新的关系写入。

再来讲下数据格式转换，之前我们使用了倒排索引或者是 KV 来存储关系，在数据结构这块，图结构同之前略有不同。像刚才提到的关系，两个点之间需要创建什么关系边，边上存储何种数据，都是需要重新设定的。智联这边当时开发了个内部工具，用来自定义 Schema，可以方便地将数据存储为点，部分数据存储为边，可以灵活操作配置。即便有别的业务接入，有了这个小工具也无需通过 Coding 方式来解决 Schema 设定。

最后一个问题是数据持续增加带来的数据失效。像常见的累积线上活跃用户，经过一段时间，像是三个月之前的活跃用户现在可能是个沉寂用户了，但按照累积机制的话，活跃用户的数据是会一直增加的，这无疑会给服务器带来数据压力。因此，我们给具有时效性的特性增加 TTL 属性，定期删除已经失效的活跃用户。

## 数据查询

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-15.jpg)

数据查询这块主要也是有 3 个方面的问题：

1. 属性多值问题
2. Java 客户端 Session 问题
3. 语法更新问题

具体来说，Nebula 本身不支持属性多值，我们想到给点连接多条边，但是这样操作的话，会带来额外的一跳查询的成本。但，我们想了另外个易操作的方法来实现属性多值问题，举个例子，我们现在要存储 3 个城市，其中城市 A 的 ID 是城市 B 的 ID 前缀，这里如果用简单的文本存储，会存在检索结果不精准问题。像上面查询 5 时便会把 530 这个城市也查询出来，于是我们写入数据时，给数据前后加入了标识符，这样进行前缀匹配时不会误返回其他数据。

第二个是 Session 管理问题，智联这边在一个集群中创建了多个 Space，一般来说多 Space 的话是需要切换 Space 再进行查询的。但是这样会存在性能损耗，于是智联这边实现了 Session 共享功能。每个 Session 维护一个 Space 的连接，相同的 Session 池是不需要切 Space 的。

最后一个是语法更新问题，因为我们是从 v2.0.1 开始使用的 NebulaGraph，后来升级到了 v2.6，经历了语法迭代——从最开始的 GO FROM 切换到了 MATCH。本身来说，写业务的同学并不关心底层使用了何种查询语法。于是，这里智联实现了一个 DSL，在查询语言上层抽象一层进行语法转换，将业务的语法转换成对应的 nGQL 查询语法。加入 DSL 的好处还在于场景的查询语句不再拘泥于单一的语法，如果用 MATCH 实现效果好就用 MATCH，用 GO 实现好就采用 GO。

## 统一 DSL 的实现

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-16.jpg)

上图便是统一 DSL 的大概想法，首先从一个点（CV）出发（上图上方蓝色块），去 join 某条边（上图中间蓝色块），再落到某个点上（上图下方蓝色块），最终通过 select 来输出字段，以及 sort 来进行排序，以及 limit 分页。

实现来说，图索引这块主要用到 match、range 和 join 函数。match 用来进行相等匹配，range 是用来进行区间查询，比如说时间区间或者是数值范围。而 join 主要实现一个点如何关联另外一个点。除了这 3 个基本函数之外，还搭配了布尔运算。

通过上面这种方式，我们统一了 DSL，无论是 Nebula 还是 Solr、还是 Milvus 都可以统一成一套用法，一个 DSL 便能调用不同的索引。

# 智联 NebulaGraph 的后续规划  

## 更有意思更复杂的场景

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-17.jpg)

上面讲的业务实现是基于离线加工的数据，后面智联这边将处理在线实时关系。像上图所示，对于一个用户和一个职位而言，二者存在的关系可以很复杂。比如它们都同某个公司有关系，或者是职位所属的公司是某个用户之前任职过的，用户更倾向于求职某一个领域或者行业，职位要求用户熟练掌握某种技能等等，这些构建成一个复杂的关系网络。

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-18.jpg)

而智联的下一步尝试便是构建起这种复杂的关系网络，再做些比较有意思的事情。例如，某个用户在公司 A 就职过，于是通过这个关系查询出他的同事，再进行相关性推荐；或者是用户同校的上一届学生 / 下届学生倾向投递某个职位或者公司，这种都可以进行相关推荐；像用户投递的这个职位曾经和谁聊过天这种行为数据，这个用户的求职意向要求：薪资水平、城市、领域行业等信息，便可以通过在线的方式进行关联推荐。

## 更方便的数据展示

目前数据查询都是通过特定的查询语法，但是下一步操作便是让更多的人低门槛的查询数据。

## 更高的资源利用率

![图索引实现方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/zhilianzhaopin-recommendation-19.jpg)

目前来说，我们的机器部署资源利用率不高，现在是一个机器部署两个服务节点，每台物理机配置要求较高，这种情况下 CPU、内存使用率不会很高，如果我们将它加入 K8s 中，可以将所有的服务节点打散，可以更方便地利用资源，一个物理节点挂了，可以借助 K8s 快速拉起另外一个服务，这样容灾能力也会有所提升。还有一点是现在我们是多图空间，采用 K8s 的话，可以将不同 Space 进行隔离，避免图空间之间的数据干扰。

## 更好用的 NebulaGraph

最后一点是，进行 NebulaGraph 的版本升级。目前，智联用的是 v2.6 版本，其实社区发布的 v3.0 中提到了对 MATCH 进行了性能优化，这块我们后续将会尝试进行版本升级。

---

交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

如何让用户在搜索某个 JD 或者招聘者快速浏览到更匹配要求的候选人，是智联招聘需要解决的一大问题。在本文你将了解智联技术团队是如何用图数据库和各类索引实现召回、排序等功能。

智联招聘：图数据在实时推荐场景中的应用


![基于 NebulaGraph 构建百亿关系知识图谱实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/use-case-build-ten-billion-graph-knowledge-with-nebula-graph.jpg)

# 一、项目背景

微澜是一款用于查询技术、行业、企业、科研机构、学科及其关系的知识图谱应用，其中包含着百亿级的关系和数十亿级的实体，为了使这套业务能够完美运行起来，经过调研，我们使用 NebulaGraph 作为承载我们知识图谱业务的主要数据库，随着 NebulaGraph 的产品迭代，我们最终选择使用 v2.5.1 版本的 NebulaGraph 作为最终版本。

# 二、为什么选择 NebulaGraph？

在开源图数据库领域，无疑存在着很多选择，但为了支撑如此大规模数据的知识图谱服务，NebulaGraph 对比其他的图数据库具有以下几个优点，这也是我们选择 NebulaGraph 的原因：

1. **对于内存的占用较小**

在我们的业务场景下，我们的 QPS 比较低且没有很高的波动，同时相比起其他的图数据库，NebulaGraph 具有更小的闲时内存占用，所以我们可以通过使用内存配置更低的机器去运行 NebulaGraph 服务，这无疑为我们节省了成本。

2. **使用 multi-raft 一致性协议**

multi-raft 相比于传统的 raft，不仅增加了系统的可用性，而且性能比传统的 raft 要高。共识算法的性能主要在于其是否允许空洞和粒度切分，在应用层无论 KV 数据库还是 SQL ，能成功利用好这两个特性，性能肯定不会差。由于 raft 的串行提交极其依赖状态机的性能，这样就导致即使在 KV 上，一个 key 的 op 慢，显著会拖慢其他 key。所以，一个一致性协议的性能高低的关键，一定是在于状态机如何让可以并行地尽量并行，纵使 multi-raft 的粒度切分比较粗（相比于 Paxos），但对于不允许空洞的 raft 协议来说，还是有巨大的提升。

3. **存储端使用 RocksDB 作为存储引擎**

RocksDB 作为一款存储引擎/嵌入式数据库，在各种数据库中作为存储端得到了广泛地使用。更关键的是 NebulaGraph 可以通过调整 RocksDB 的原生参数来改善数据库性能。

4. **写入速度快**

我们的业务需要频繁地大量写入，NebulaGraph 即使在具有大量长文本内容的 vertex 的情况下（集群内3 台机器、3 份数据，16 线程插入）插入速度也能达到 2 万/s 的插入速度，而无属性边的插入速度在相同条件下可以达到 35 万/s。

# 三、使用 NebulaGraph 时我们遇到了哪些问题？

在我们的知识图谱业务中，很多场景需要向用户展示经过分页的一度关系，同时我们的数据中存在一些超级节点，但根据我们的业务场景，**超级节点一定会是用户访问可能性最高的节点，所以这不能被简单归类到长尾问题上**；又因为我们的用户量并不大，所以缓存必然不会经常被撞到，我们需要一套解决方案来使用户的查询延迟更小。

举例：业务场景为查询这个技术的下游技术，同时要根据我们设置的排序键进行排序，此排序键是局部排序键。比如，某个机构在某一领域排名特别高，但是在全局或者其他领域比较一般，这种场景下我们必须把排序属性设置在边上，并且对于全局排序项进行拟合与标准化，使得每个维度的数据的方差都为 1，均值都为 0，以便进行局部的排序，同时还要支持分页操作方便用户查询。

语句如下：

```SQL
MATCH (v1:technology)-[e:technologyLeaf]->(v2:technology) WHERE id(v2) == "foobar" \ 
RETURN id(v1), v1.name, e.sort_value AS sort ORDER BY sort | LIMIT 0,20;
```
此节点有 13 万邻接边，这种情况下即使对 sort_value 属性加了索引，查询耗时还是将近两秒。这个速度显然无法接受。

我们最后选择使用蚂蚁金服开源的 OceanBase 数据库来辅助我们实现业务，数据模型如下：

technologydownstream

|technology_id|downstream_id|sort_value|
| --------| -----| --------|
|foobar|id1|1.0|
|foobar|id2|0.5|
|foobar|id3|0.0|

technology

|id|name|sort_value|
| --------| -----| --------|
|id1|aaa|0.3|
|id2|bbb|0.2|
|id3|ccc|0.1|

查询语句如下：

```SQL
SELECT technology.name FROM technology INNER JOIN (SELECT technologydownstream.downstream_id FROM technologydownstream 
WHERE technologydownstream.technology_id = 'foobar' ORDER BY technologydownstream.sort_value DESC LIMIT 0,20) AS t 
WHERE t.downstream_id=technology.id; 
```
此语句耗时 80 毫秒。这里是整个架构设计

![基于 NebulaGraph 构建百亿关系知识图谱实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/use-case-build-ten-billion-graph-knowledge-with-nebula-graph-01.jpeg)

# 四、使用 NebulaGraph 时我们如何调优？

前面讲过 NebulaGraph 的一个很大的优势就是可以使用原生 RocksDB 参数进行调优，减少学习成本，关于调优项的具体含义以及部分调优策略我们分享如下：

| RocksDB 参数|含义|
| --------| -----|
|max_total_wal_size|一旦 wal 的文件超过了 max_total_wal_size 会强制创建新的 wal 文件，默认值为 0时，max_total_wal_size = write_buffer_size * max_write_buffer_number * 4 |
| delete_obsolete_files_period_micros |删除过期文件的周期，过期的文件包含 sst 文件和 wal 文件， 默认是 6 小时|
|max_background_jobs|最大的后台线程数目 = max_background_flushes + max_background_compactions|
| stats_dump_period_sec |如果非空，则每隔 stats_dump_period_sec 秒会打印 rocksdb.stats 信息到 LOG 文件	|
| compaction_readahead_size |压缩过程中预读取硬盘的数据量。如果在非 SSD 磁盘上运行 RocksDB，为了性能考虑则应将其设置为至少 2 MB。如果是非零，同时会强制new_table_reader_for_compaction_inputs=true|
| writable_file_max_buffer_size |WritableFileWriter 使用的最大缓冲区大小 RocksDB 的写缓存，对于 Direct IO 模式的话，调优该参数很重要。|
| bytes_per_sync |每次sync的数据量，累计到 bytes_per_sync 会主动 Flush 到磁盘，这个选项是应用到 sst 文件，wal 文件使用 wal_bytes_per_sync|
| wal_bytes_per_sync |wal 文件每次写满 wal_bytes_per_sync 文件大小时，会通过调用 sync_file_range 来刷新文件，默认值为 0 表示不生效|
| delayed_write_rate |如果发生 Write Stall， 写入的速度将被限制在 delayed_write_rate 以下|
| avoid_flush_during_shutdown |默认情况下，DB 关闭时会刷新所有的 memtable，如果设置了该选项那么将不会强制刷新，可能造成数据丢失|
| max_open_files |RocksDB 可以打开文件的句柄数量(主要是 sst文件)，这样下次访问的时候就可以直接使用，而不需要重新在打开。当缓存的文件句柄超过 max_open_files 之后，一些句柄就会被 close 掉，要注意句柄 close 的时候相应 sst 的 index cache 和 filter cache 也会一起释放掉，因为 index block 和 filter block 缓存在堆上，数量上限由 max_open_files 选项控制。依据 sst 文件的 index_block 的组织方式判断，一般来说 index_block 比 data_block 大 1 到 2 个数量级，所以每次读取数据必须要先加载 index_block，此时 index 数据放在堆上，并不会主动淘汰数据；如果大量的随机读的话，会导致严重的读放大，另外可能导致 RocksDB 不明原因的占据大量的物理内存，所以此值的调整非常重要，需要根据自己的 workload 在性能和内存占用上做取舍。如果此值为 -1，RocksDB 将一直缓存所有打开的句柄，但这个会造成比较大量的内存开销|
| stats_persist_period_sec |如果非空，则每隔 stats_persist_period_sec 自动将统计信息保存到隐藏列族___ rocksdb_stats_history___。|
| stats_history_buffer_size |如果不为零，则定期获取统计信息快照并存储在内存中，统计信息快照的内存大小上限为 stats_history_buffer_size|
| strict_bytes_per_sync|RocksDB 把数据写入到硬盘时为了性能考虑，默认没有同步 Flush，因此异常情况下存在丢失数据的可能，为了对丢失数据数量的可控，需要一些参数来设定刷新的动作。如果此参数为 true，那么 RocksDB 将严格的按照 wal_bytes_per_sync 和 bytes_per_sync 的设置刷盘，即每次都刷新完整的一个文件，如果此参数为 false 则每次只刷新部分数据：也就是说如果对可能的数据丢失不怎么 care，就可以设置 false，不过还是推荐为 true|
| enable_rocksdb_prefix_filtering |是否开启 prefix_bloom_filter，开了之后会根据写入 key 的前 rocksdb_filtering_prefix_length 位在 memtable 构造 bloom filter|
| enable_rocksdb_whole_key_filtering |在 memtable 创建 bloomfilter，其中映射的 key 是 memtable 的完整 key 名，所以这个配置和 enable_rocksdb_prefix_filtering 冲突，如果 enable_rocksdb_prefix_filtering 为 true，则这个配置不生效|
|rocksdb_filtering_prefix_length|见 enable_rocksdb_prefix_filtering|
| num_compaction_threads|后台并发 compaction 线程的最大数量，实际是线程池的最大线程数，compaction 的线程池默认为低优先级|
|rate_limit|用于记录在代码里通过 NewGenericRateLimiter 创建速率控制器的参数，这样重启的时候可以通过这些参数构建 rate_limiter。rate_limiter 是 RocksDB 用来控制 Compaction 和 Flush 写入速率的工具，因为过快的写会影响数据的读取，我们可以这样设置：`rate_limit = {"id":"GenericRateLimiter"; "mode":"kWritesOnly"; "clock":"PosixClock"; "rate_bytes_per_sec":"200"; "fairness":"10"; "refill_period_us":"1000000"; "auto_tuned":"false";}`|
| write_buffer_size|memtable 的最大 size，如果超过了这个值，RocksDB 就会将其变成 immutable memtable，并创建另一个新的 memtable|
| max_write_buffer_number|最大 memtable 的个数，包含 mem 和 imm。如果满了，RocksDB 就会停止后续的写入，通常这都是写入太快但是 Flush 不及时造成的|
| level0_file_num_compaction_trigger|Leveled Compaction 专用触发参数，当 L0 的文件数量达到 level0_file_num_compaction_trigger 的值时，则触发 L0 和 L1 的合并。此值越大，写放大越小，读放大越大。当此值很大时，则接近 Universal Compaction 状态|
|level0_slowdown_writes_trigger|当 level0 的文件数大于该值，会降低写入速度。调整此参数与level0_stop_writes_trigger 参数是为了解决过多的 L0 文件导致的 Write Stall 问题|
|level0_stop_writes_trigger|当 level0 的文件数大于该值，会拒绝写入。调整此参数与level0_slowdown_writes_trigger 参数是为了解决过多的 L0 文件导致的 Write Stall 问题|
| target_file_size_base|L1 文件的 SST 大小。增加此值会减少整个 DB 的 size，如需调整可以使target_file_size_base = max_bytes_for_level_base / 10，也就是 level 1 会有 10 个 SST 文件即可|
| target_file_size_multiplier |使得 L1 上层(L2...L6)的文件的 SST 的 size 都会比当前层大 target_file_size_multiplier 倍|
| max_bytes_for_level_base|L1 层的最大容量（所有 SST 文件大小之和），超过该容量就会触发 Compaction|
| max_bytes_for_level_multiplier|每一层相比上一层的文件总大小的递增参数|
| disable_auto_compactions|是否禁用自动 Compaction|

---

交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

本文讲述了 NebulaGraph 是如何护航微澜的实时资讯业务之余，用了大篇幅来讲述底层数据库的调优方法。

基于 NebulaGraph 构建百亿关系知识图谱实践


![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice.jpg)

本文整理自 BIGO 在 nMeetp 上的主题分享，主要介绍 BIGO 过去一年在数据管理建设方面的理解和探索。而 BIGO 数据管理的核心重点在于元数据平台的建设，用以支撑上层数据管理和建设应用，包括数据地图、数据建模、数据治理和权限管理等等。本文主要围绕以下五个方向展开：

1. OneMeta 基础建设；
2. 图引擎：Nebula 替换 JanusGraph
3. 数据资产平台应用；
4. Adhoc 即席查询；
5. 未来规划

> BIGO 是欢聚时代（YY 直播母公司）原移动新产品部基础上成立的独立公司，致力于打造全球领先的社区化视频直播应用与品牌。旗下主打产品 BIGO LIVE，上线仅一个月就荣登泰国免费 APP 榜首。

# 数据管理平台

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-01.jpeg)

上图为 BIGO 数据资产管理平台的抽象图，如上图所示，在元数据平台里面存储着技术元数据、业务元数据、数据血缘、数据计量、规范模型、权限内容等数据，基于元数据平台上层对接应用层，包括：地图、成本、取数、权限、治理、模型。

# OneMeta 基础建设

## 业务背景

目前 BIGO 数据管理面临以下问题：

1. 元数据杂乱无标准，没有统一的搜索和管理平台；
2. 数据没有血缘关系，各个开发平台如同数据孤岛；
3. 没有业务类元数据，业务方难以查询及统一口径；
4. 数据权限管控粗放，权限申请及审批流程原始化；

简单来说：缺少标准、数据缺少联系、缺少业务元数据、缺少细颗粒度的权限管控，为此，BIGO 内部搭建了元数据管理平台 OneMeta 来解决上述问题。

而 OneMeta 的平台能力如下：

1. 全域元数据实时入库及管理功能，统一构建公司个人及团队数据资产目录。
2. 数据地图、取数查询、数据治理、血缘姻联、权限管理、规范模型等应用存储管理能力。
3. 支持 HIVE / HDFS / OOZIE / CLICKHOUSE / BAINA / SPARKSQL / KYUUBI / KAFKA 等元数据及血缘关系的存储。
4. 精准计量业务元数据：各式各样的元数据的操作次数、冷热程度、业务归属等信息更新。

# 元数据平台架构

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-02.jpeg)

BIGO 元数据平台主要依赖 Apache Atlas、Vesoft Nebula、Yandex ClickHouse 和 BIGO 内部开发的 DataCollector 进行构建，整体上可以划分为四层。

最上层（蓝色部分）是数据采集的源头和 DataCollector 服务，各个平台的技术元数据主要以 Hook 的形式实时收集，而业务元数据则通过 DataCollector 服务以小时或天级定时调度、更新；第二层（橙色部分）是消息队列和 API 层，提供通道接入数据到 Atlas；第三层则是 Atlas（绿色部分），这是最核心的元数据管理层，所有元数据、属性信息和血缘关系等都在 Atlas 进行管理，此外 Atlas 层还提供了接口供应用调用；最底层（紫色部分）是存储层，主要使用 NebulaGraph、Elasticsearch 和 ClickHouse，其中主要的元数据都存储在 Nebula 中，其中需要全文索引的数据通过 NebulaGraph 转存到 ES，而需要查询历史趋势或聚合的数据时，则去 CK（ClickHouse）中读取数据。

## Apache Atlas 优化

这部分讲解下 BIGO 基于开源的 Atlas 做了何种优化，主要有以下方面的优化：

1. 通过 SpringBoot 切面实现审计能力建设。
2. 引入 MicroMeter 和 Prometheus 实现监控告警能力建设。
3. 抽离图引擎依赖，支持分布式 NebulaGraph 图引擎的读写，新增 3w+ 行代码。
4. 新增访问速度控制及黑白名单功能，控制突发流量和恶意访问，保证系统稳定。
5. 定期任务，以便清理失效 Process 过程数据，避免数据膨胀。
6. 添加 Atlas 平滑退出机制，防止因重启导致消费消息丢失。
7. 重构血缘关系 DAG 图展示，优化用户视觉体验同时避免大图渲染过慢问题。
8. 支持血缘关系关联调度引擎工作流，解决数据血缘中最重要的「查找产出」一环。
9. Hook 拓展：全新支持 Oozie、Kyuubi、Baina、ClickHouse、Kafka 等元数据采集。
10. 若干原生版本代码中的 BUG 修复。

## Data Collector 功能

在 BIGO 元数据平台中有个比较重要的功能——DataCollector，它是一个数据采集服务，主要功能用于定时收集并更新业务元数据（服务于上层的数据计量等应用），比如 HIVE 表每天的访问次数和访问人员、HDFS 路径的存储量、元数据的业务线归属、元数据的冷热判断、元数据的真实负责人等业务元数据。同时，DataCollector 还具备数据清理（生命周期 TTL）和同步数据接入层（Baina）元数据的功能。

# 图引擎替代

Atlas 原生图引擎是 JanusGraph，在使用过程中发现 Atlas Janus 有以下缺陷：第一，Atlas 依赖的内嵌 JanusGraph 图引擎存在单点问题，并发量上来后存在计算瓶颈。第二，JanusGraph 依赖 Solr 构建索引，虽然 JanusGraph 声称可用 Elasticsearch 替换 Solr，但实际操作起来却存在不少问题。此外，BIGO 内部对 Solr 不存在相关的技术累计，这需要投入一定的人力成本。第三，海量数据场景下 JanusGraph 搜索性能差，并存在偶发搜索不到数据的 BUG 难以解决。第四，JanusGraph 没有开源社区与公司内部团队支持，维护成本高。

再来说下 NebulaGraph 替换 JanusGraph 的几大优势。首先，**业务同学和运维同学多方测试证明 NebulaGraph 在图探索性能上是 JanusGraph 的 N 倍以上**。再者，**NebulaGraph 是个分布式图数据库，支持分布式部署，计算和存储均可横向扩展，并且支持高并发**。此外，**NebulaGraph 开源社区活跃，产品不断迭代优化，支持千亿顶点和万亿边的数据量**。最后，在 BIGO 内部有合作团队支持与维护 NebulaGraph 平台功能维护和开发。

## 图引擎替换的挑战&解决方案

虽然在选型上确定了用 NebulaGraph 来替换 JanusGraph，但是在实际的替换过程中还是存在一定的挑战。

首先是在数据模型上，NebulaGraph 是个强 Schema 类型数据库，如果要替换弱类型的 JanusGraph 的话，需要弱化 Tag 和 Edge 的概念。然后，在数据类型支持方面二者也有出入，原生 NebulaGraph 对 MAP、LIST 之类的复杂类型支持程度不高。再者是索引的设计问题，在 NebulaGraph 中索引功能并非起到加速作用，而是 `LOOKUP` 此类搜索的必备条件。此外，NebulaGraph 本身是不支持事务的，这块给我们增加了不少的工作量。最后一点，是使用习惯的转变，在查询方式上 NebulaGraph 自研查询语言 nGQL，而 JanusGraph 支持通过 Java API 和 Gremlin 进行查询。

问题出现了如何解决呢？在强弱类型转换上，BIGO 内部修改了 Atlas 的核心代码，增加参数动态判断 DDL 数据类型。简单来说，在写入数据或者执行查询时，通过特定参数来判断该条 nGQL 操作何种数据类型。在数据类型支持方面，Atlas 业务层自定义数据序列化方式来支持复杂类型。在原生索引搜索上，在系统初始化时自动创建独立索引和复合索引解决 Atlas 的搜索问题。在事务方面，在 Atlas 业务层新增半事务接口，减少 NebulaGraph 存储层数据出错的概率。

## Atlas 和 NebulaGraph 的改造

这里，集中讲述在图引擎替换过程中 BIGO 对 Atlas 和 NebulaGraph 的改造。

在 Atlas 改造过程中，BIOG 新增 3w+ 行代码解藕 Atlas 和原生图引擎 JanusGraph 并支持分布式图引擎 NebulaGraph 读写。通过改造全文索引实现在 Atlas 层以 `INTERSECT` 方式多条件并发过滤查询，从而提升搜索速度。还将 Atlas 的多属性更新改造为并发更新，加速元数据入库的更新速度。对消费消息丢失的预处理上，BIGO 在 Atlas 层添加平滑退出机制，防止因重启导致消费消息丢失。此外，Atlas 通过支持自定义多种（反）序列化方式实现对复杂类型数据的支持。刚有提到过事务支持，在 Atlas 层新增 `Vertex#openTranscation/Vertex#commit` 接口支持半事务，减少由于 NebulaGraph 无事务回滚出错。最后，在 Atlas 层合并大量独立索引为复合索引，通过创建默认索引和属性优化系统初始化速度。

而 NebulaGraph 方面，BIGO 也对其进行了改造。首先是对 `LOOKUP` 子句的改造，让其支持并发执行，经测试扫描 100 万数据的 Latency 从 8s 降低到了 1s。此外，支持了 `LOOKUP` 从 Elasticsearch 查询分页功能。再者，其他部分改造工作集中在 Elasticsearch，BIGO 支持了后端 ElasticSearch 中的数据更新和删除；对 Listener 也做了 Commitsnapshot 的支持，以及全量数据的更新。对全文索引支持了 `REBUILD` 功能，并将 `REBUILD INDEX` 权限下发到 admin 用户。BIGO 还增加了单独创建和删除全文索引功能，避免所有的列写入 ElasticSearch 增加其存储使用量。最后，对 NebulaGraph 的定期 Compaction 操作也进行了优化，减少上层性能波动。

## 替换之后搜索性能

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-03.png)

上图展示了 BIGO 用 NebulaGraph 替换 JanusGraph 之后的搜索性能。上图 P99 需要耗时 2s 多的原因是搜索总存在大搜索，会拖慢搜索速度。替换之后，搜索速度提升 5 倍以上，从原先的 5s 返回结果降低到了 1s 以内；而且再也不会出现偶尔搜索不到数据的问题，系统维护也无需额外维护索引，还支持了高并发和超大数据量存储。

# 数据资产平台应用

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-04.jpeg)

之前有分享过下层的统一元数据平台架构，这里再来详细讲解下。如上图所示，下层主要为统一元数据平台，上层则为产品应用层。左下部分为实时元数据入库模块，包括 Hive、Kyuubi、Oozie、Baina、CK（ClickHouse）、HDFS 等等数据源，经过 Hook 通过 Kafka 消息队列写入到统一元数据库平台。统一元数据库平台核心组件是 Atlas，其依赖 ClickHouse 和 NebulaGraph。此外，统一元数据平台还依赖 BIGO 内部的 OneSQL 平台，主要是统一 SQL 查询引擎，以及 Ranger 主要负责权限管控。

而数据资产平台上层则对接了应用层，包括：REST 接口、数据地图、实时血缘、即席查询、数仓建模、可视化建表、离职交接、权限管理等应用。

下面着重来介绍下相关应用。

## 数据地图

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-05.png)

上图为数据地图-搜索（部分），支持全域元数据（HIVE、HDFS、CK、BAINA）搜索与发现（数据源还在增加中）、结果排序和下载、支持筛选、支持高级搜索等功能。在搜索界面，左侧为筛选条件，顶部为搜索框入口，下方为搜索结果展示数据。

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-06.png)

上图为数据地图-详情（部分），通过搜索找到特定的元数据之后，可点击查看技术明细、数据计量、业务归属、生命周期、历史趋势等元数据基础信息。在详情界面，以上图 HIVE 元数据的详情为例，主要分为上方的基本信息和下方的明细信息、血缘关系、数据预览展示。

基本信息罗列了昨日查询次数 107 次，数据大小 1.27 TiB，占用空间为 3.8 TiB…此外，通过【编辑】操作可对数据生命周期、业务线进行管理。

明细信息（下方左侧）罗列字段信息：HIVE 表的字段、字段类型、字段相关描述，供产品、运营使用。下方右侧为分区字段信息，如果某个数据是分区表的话，该模块会展示分区字段的信息；如果是个全量表的话，则不会展示分区字段信息。此外，数据血缘关系、数据预览功能这里不作详细介绍。

## 实时血缘

在实时血缘模块，BIGO 重构了有向无环图 DAG 图，新增数据表格展示，实现了数据懒加载、关联和搜索工作流，在业务层的血缘关系图里实时地展示工作流的执行状态。

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-07.png)

血缘模块支持图表和可视化两类视图，上图选择了可视化视图模式。可视化视图部分可在上、下游节点中选择对应节点，配有【显示过程】按钮用来显示或者隐藏过程工作流。举个例子，a 表和 b 表，b 表是由 a 表通过一个工作流生成，打开【显示过程】按钮则会展示该生成过程，关闭【显示过程】则会屏蔽这个过程数据。

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-08.png)

上图为数据血缘核心模块，展示了某个元数据的上下游。左侧浮动深度和过滤选项，可选择以某个元数据为中心的上下游层数（深度），比如，上图就选择了 tiki_core_india... 数据的 2 层上游和下游节点。

## 数据治理

数据治理这块，主要展示 TTL 管理，用于管理通用打点表各个事件的生命周期。

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-09.png)

上图为数据治理 TTL 管理部分截图，从上文提到的数据地图详情部分点击【编辑】按钮即可对数据进行 TTL 生命周期管理。当然，BIGO 数据治理除了生命周期管理之外，还有别的功能这里不做详细介绍。

## 数据建模

在数据建模方面，元数据统一平台提供 SQL 脚本方式用来创建表模型，供数仓开发者和数据分析师交互使用。

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-10.png)

图注：一条 SQL 模型数据

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-11.png)

图注：数据建模入口

## 监控大盘

BIGO 内部的监控大盘实时展示公司数据，包括资源总量、各业务线资源占比、变化趋势和热门资源等，从而推动团队、业务线进行成本优化。

![BIGO 的数据管理与应用实践](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-12.png)

图注：脱敏的大盘截图

除了上述的应用之外，数据资产管理平台还有模板取数、权限管理、离职交接、群组管理、数据预览，以及收藏下载等应用。

# Adhoc 即席查询

## 业务背景

BIGO 原来使用 Cloudera HUE 作为即席查询平台，但由于多种原因，HUE 早已无法适配内部查询需求，经常被用户投诉难用且不稳定。主要原因有：

1. 代码陈旧，基本处于被开源放弃状态；
2. BIGO 历史原因经历至少六位员工接手 HUE，堆积大量内部代码；
3. HUE 运维非常繁琐；
4. 编辑窗口不符合用户实际需求；
5. BIGO 已内部建设统一 SQL 路由器，无需让用户选择执行引擎。

基于上述原因，决定自研一套全新 SQL 查询平台，解决上述问题，统一元数据管理和数据查询到资产管理平台，并加入以下特性：第一点，建设统一 SQL 路由器（onesql），根据语法规则自动路由 SQL 到后端 sparksql/hive/presto/flinksql 引擎执行；第二点，提供全新查询入口给用户执行 SQL，并规范化 DDL 语句，为数据治理、权限管理及成本控制提供便利；第三点，根据产品调研设计全新多 TAG 交互操作的编辑窗口；第四点，提供通过 SQL 建表 / LOAD 数据或通过可视化建表 / LOAD 数据的功能；第五点，自动兼容 pad / phone 等移动设备端查询，方便国内外同事使用；第六点，增加日常用户访问审计 / 全面监控告警；最后一点，支持在统一入口查询 ClickHouse 数据（规划中）。

# 未来展望

数据平台未来规划的话，主要围绕：元数据建设、产品增加、业务赋能三方面。

在元数据建设方面，将会覆盖接入层、计算层、调度层、存储层所有平台的元数据。此外，我们还在规划计算资源治理以及一站式任务开发（Python / Jar / Shell / SQL）等。

在产品增强方面主要分为治理、成本、效率、应用四块内容，在治理方面，加强数据治理能力，自动治理不健康的数据；在成本方面，帮助公司各团队实现成本分析闭环，为成本优化提供工具；在效率方面，通过规范建表、精准计量、查询优化、血缘建设等提升用户工作效率；在应用方面，进一步完善集成即席查询和分布式调度系统功能，增强用户使用体验。

在业务赋能方面，将会进行智能归因诊断，赋能业务团队自动分析问题能力。此外，还会迭代优化模板取数，赋能业务团队简单挖掘更多数据价值。

以上，为本次 BIGO 数据平台实践分享。
---

交流图数据库技术？加入 Nebula 交流群请先[填写下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![关注公众号](https://www-cdn.nebula-graph.com.cn/nebula-blog/WeChatOffical.png)


缺少标准、数据缺少联系、缺少业务元数据、缺少细颗粒度的权限管控，为此，BIGO 内部搭建了元数据管理平台来解决上述问题。