Nebula Graph 在企查查的应用

>>>>背景
企查查是企查查科技有限公司旗下的一款企业信用查询工具，旨在为用户提供快速查询企业工商信息、法院判决信息、关联企业信息、法律诉讼、失信信息、被执行人信息、知识产权信息、公司新闻、企业年报等服务。

为更好地展现企业之间的法律诉讼、风险信息、股权信息、董监高法等信息，我们抽取结构化/非结构化的企业数据构建企业知识图谱，为用户提供真实可靠的服务。

>>>>图数据库选择
在最初的时候，我们用的是 Neo4j HA cluster 作为存储端。随着数据和业务规模的不断扩展，要求我们需要一个读写性能良好，分布式的图数据库作支撑。经过几番调研，在 Dgraph、Nebula Graph、Galaxybase、HugeGraph 中进行选择，最终选择了 Nebula Graph。
关于选型维度，我们相对侧重社区活跃度、资料获取难易程度、最基本的读写、子图查询性能等方面。

具体的测评因为没有社区其他用户之前分享的文章那么详实，这里就不展开了。这里附上之前美团的测评：主流开源分布式图计算框架 Benchmark 🔗。

>>>>Nebula Graph 简介

Nebula Graph 是什么

Nebula Graph 是一款开源的、分布式的、易扩展的原生图数据库，能够承载数千亿个点和数万亿条边的超大规模数据集，并且提供毫秒级查询。

基于图数据库的特性使用 C++ 编写的 Nebula Graph，可以提供毫秒级查询。众多数据库中，Nebula Graph 在图数据服务领域展现了卓越的性能，数据规模越大，Nebula Graph 优势就越大。

Nebula Graph 采用 shared-nothing 架构，支持在不停数据库服务的情况下进行扩缩容操作。

Nebula Graph 开放了越来越多的原生工具，例如 Nebula Studio、Nebula Console、Nebula Exchange 等，更多工具可以查看生态工具概览（https://docs.nebula-graph.com.cn/3.0.0/20.appendix/6.eco-tool-version/）。

此外，Nebula Graph 还具备与 Spark、Flink、HBase 等产品整合的能力，在这个充满挑战与机遇的时代，大大增强了自身的竞争力。

上面内容来源于 Nebula Graph 文档站点：https://docs.nebula-graph.com.cn/2.6.2/1.introduction/1.what-is-nebula-graph/

Nebula Graph 架构
Nebula Graph 由三种服务构成：Graph 服务、Meta 服务和 Storage 服务，是一种存储与计算分离的架构。

每个服务都有可执行的二进制文件和对应进程，用户可以使用这些二进制文件在一个或多个计算机上部署 Nebula Graph 集群。

下图展示了 Nebula Graph 集群的经典架构。

上面内容来源于 Nebula Graph 文档站点：https://docs.nebula-graph.com.cn/2.6.2/1.introduction/3.nebula-graph-architecture/1.architecture-overview/

>>>>流程优化

Nebula Graph 的数据导入
在我们接触 Nebula Graph 初期，当时周边工具不够完善。我们对 Nebula Graph 数据的导入不管全量还是增量都是采用 Hive 表推到 Kafka，消费 Kafka 批量写入 Nebula Graph 的方式。后来随着越来越多的数据和业务切换到 Nebula Graph，发现当前的方式存在三个较大问题：

1. 全量导入的时长增多，到了难以接受的地步
2. 增量数据消费由于 Kafka 多个分区，部分时序性无法保证
3. 时间较长后如何减少增量数据进入 Nebula Graph 后整体数据的偏差
   针对以上问题，我们针对各个 Space 的业务特性，由实时性的需求不同，做不同的优化方案。

1. 在尝试 Nebula Spark Connector 和 Nebula Importer 之后，从便于维护和迁移多方面考虑，采用 hive table -> csv -> nebula server -> importer 的方式进行全量的导入，整体耗时时长也有较大的提升。
2. 经过拆分，测试把增量由多个分区合并到一个分区中消费。这样不会影响实时性，实时的误差可以保证在 1 min 内，可以接受。
3. 对不同字段设置 TTL 属性，定期导入全量校正数据，同时补消费导入全量期间的数据，以免数据覆盖导致的错误数据。

服务的故障发现
当前我们已经升级到 v2.6.1，在最初的 v1.x 和 v2.0.1 存在部分 bug，经常容易出现的就是 OOM 导致 graph down。当时为了尽可能减少 graph down 的影响，做了相关脚本监控进程，出现宕机会立刻重启。

此外，为了提高整体服务的可用性，对集群节点的 CPU、内存、硬盘、TCP 等做了相应监控与告警。Nebula Graph 服务层的部分指标也接入了 Grafana，比较重要的几个告警指标如下:

nebula_metad_heartbeat_latency_us_avg_60 > 200000

nebula_graphd_num_slow_queries_rate_60 > 60
nebula_graphd_slow_query_latency_us_avg_60 >400000   
nebula_graphd_slow_query_latency_us_p95_60 > 900000

nebula_graphd_num_query_errors_rate_60 > 10        

nebula_storaged_add_edges_latency_us_avg_60 > 90000       
nebula_storaged_add_vertices_latency_us_avg_60 > 90000      
nebula_storaged_delete_edges_latency_us_avg_60 > 90000      
nebula_storaged_delete_vertices_latency_us_avg_60 > 90000    
nebula_storaged_get_neighbors_latency_us_avg_60 > 200000

同时应用层的接口做了慢查询和流量监控告警：

后来 Nebula 官方自己推出了 Nebula Dashboard（https://github.com/vesoft-inc/nebula-dashboard）用于各个方面指标的监控, 不过貌似暂时没有告警功能。（企业版 Nebula Dashboard 支持该功能）

经过前面的介绍，我们这边 Nebula Graph 的基本框架流程如下图：

P.S.：企查查为 Nebula 社区贡献了 Node 客户端，有需要使用 Node 客户端的朋友可以去使用，欢迎共建。此处附上 repo 链接：https://github.com/nebula-contrib/nebula-node
>>>>Nebula Graph 在企查查的使用场景

• 子图查询
      业务需求：展示某公司/个人两跳以内的企业关系（例如: 董监高法），以图的形式直观展示。
      更多、更详细的介绍可以访问企查查官网，查看更多、更全面的企业/个人关系图谱、风险图谱、股东关系穿透等内容。
  
• 找关系
      业务需求: 寻找任意两个或者多个实体（公司或者人）之间的关系，关系包括不限于董监高法、控股、历史董监高法、历史控股。
      遗憾的是经过内部多轮交叉对比测试，发现切过来后性能损失较大，Nebula Graph 目前的路经查询功能暂时无法满足业务需求。所以目前还没有从 Neo4j 切到       Nebula Graph，有关于这块的支持给官方提了 issue（https://github.com/vesoft-inc/nebula/issues/3221）。该 issue 目前在 enhancement list 中，期待官方的优化，我们也会持续跟进。
  

>>>>展望
Nebula 目前提供了超强的读写能力和丰富的生态，以及良好的社区环境、技术支持服务。但是在复杂的查询表达能力和路径查找及其节点过滤上还有待加强，期望社区越做越强，尽快完善相关功能，我们也方便将业务都切到 Nebula Graph，不必维护两套数据库。

   END