关于数据库:Nebula-Graph-在企查查的应用

7次阅读

共计 2861 个字符,预计需要花费 8 分钟才能阅读完成。

本文首发于 Nebula Graph Community 公众号

背景

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

为更好地展示企业之间的法律诉讼、危险信息、股权信息、董监高法等信息,咱们抽取结构化 / 非结构化的企业数据构建企业常识图谱,为用户提供实在牢靠的服务。

图数据库抉择

在最后的时候,咱们用的是 Neo4j HA cluster 作为存储端。随着数据和业务规模的一直扩大,要求咱们须要一个 读写性能良好,分布式的图数据库作撑持。通过几番调研,在 Dgraph、Nebula、Galaxybase、HugeGraph 中进行抉择,最终抉择了 Nebula Graph。

对于 选型维度 ,咱们绝对偏重 社区活跃度、材料获取难易水平、和最根本的读写、子图查问性能 等方面。

具体的测评因为没有社区其余用户之前分享的文章那么详实,这里就不开展了。这里附上之前美团的测评链接:美团传送门。

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 等,更多工具能够查看生态工具概览。

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

下面内容来源于 Nebula Graph 文档站点

Nebula Graph 架构

Nebula Graph 由三种服务形成:Graph 服务、Meta 服务和 Storage 服务,是一种存储与计算拆散的架构。

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

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

下面内容来源于 Nebula Graph 文档站点

流程优化

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. 通过拆分,测试把增量由多个分区合并到一个分区中生产。这样不会影响实时性,实时的误差能够保障在 1min 内,能够承受
  3. 对不同字段设置 TTL 属性,定期导入全量校对数据,同时补生产导入全量期间的数据,免得数据笼罩导致的谬误数据。

服务的故障发现

以后咱们曾经降级到 v2.6.1,在最后的 v1 和 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 用于各个方面指标的监控, 不过貌似临时没有告警(企业版有告警性能)。

通过后面的介绍,咱们这边 Nebula Graph 的根本框架流程如下图:

Nebula Graph 在企查查的经典业务

  • 子图查问
    业务需要:展现某公司 / 集体两跳以内的企业关系(例如: 董监高法),以图的模式直观展现。
    更多、更具体的信息能够拜访企查查官网查看,有更多、更全面的企业 / 集体关系图谱、危险图谱、股东关系穿透等。传送门

  • 找关系
    业务需要: 寻找任意两个或者多个实体(公司或者人)之间的关系,关系包含不限于董监高法,控股,历史董监高法,历史控股。
    遗憾的是 Nebula Graph 目前官网的门路查问,通过多轮穿插比照测试,发现切过来后性能损失较大,临时无奈满足业务需要。咱们目前还没有从 Neo4j 切到 Nebula Graph,通过屡次沟通提了 issue。目前在 enhancement list 中期待官网的优化,咱们会继续跟进。

瞻望

Nebula 目前提供了 超强 的读写能力和丰盛的生态,以及优良的社区活跃度、官网反对等。然而在简单的查问表达能力和门路查找及其节点过滤上还有待增强,冀望社区越做越强,尽快欠缺相干性能,咱们也不便都切到 Nebula Graph,不用保护两套数据库。

交换图数据库技术?退出 Nebula 交换群请先填写下你的 Nebula 名片,Nebula 小助手会拉你进群~~

关注公众号

正文完
 0