乐趣区

关于nebula:在-Spark-数据导入中的一些实践细节

jiezi 

本文由合合信息大数据团队柳佳浩撰写

1. 前言

图谱业务随着工夫的推移愈发的复杂化，逐步体现出了性能上的瓶颈：单机不足以反对更大的图谱。然而，从性能上来看，Neo4j 的原生图存储有着不可代替的性能劣势，这一点是之前调研的 JanusGraph、Dgraph 等都难以逾越的鸿沟。即便 JanusGraph 在 OLAP 下面十分杰出，对 OLTP 也有肯定的反对，然而 GraphFrame 等也足以撑持其 OLAP 需要，更何况在 Spark 3.0 会提供 Cypher 反对的状况下，图谱的 OLAP 需要相比 OLTP 有更多路径能够解决。这个时候，Nebula Graph 的“横空出世”无疑是对分布式 OLTP 效率低下现状的一种冲破。

之前在各类调研、部署后，特地是从 JanusGraph 的 OLTP 效率最终测试发现无奈满足线上需要之后，咱们不再对同一图谱能够同时进行 OLAP 和 OLTP 进行强制性要求，而 Nebula Graph 的架构刚好合乎图谱方面的须要：

  1. 分布式——shared-nothing 分布式架构
  2. 高速 OLTP（性能须要和 Neo4j 相近）——Nebula Graph 的存储层架构查问间接映射 物理地址，实际上能够算是原生图存储
  3. 服务的高可用（即在非人为状况下，图谱能够稳固提供服务）——部分失败服务可用、有快照机制
  4. 保障可扩展性——反对线性扩容，因为开源、反对二次开发

综上所述，Nebula Graph 架构上符合实际生产需要，因而对 Nebula Graph 进行了调研、部署、测试。对于部署、性能测试 (美团 NLP 团队性能测试、腾讯云平安团队性能测试) 的局部无论是官网还是其他同学在博客中都有比拟详尽的数据，本文次要从 Spark 导入登程，算是对 Nebula Graph 对 Spark 的反对进行浅显的了解。

2. 测试环境

  1. Nebula Graph 集群

    1. 3 台 32 c（理论限度了 16 c）
    2. 400 G 内存（理论配置了 100 G）
    3. SSD
    4. 版本信息：Nebula Graph 版本 1.0.0（过后测试比拟早）。
  2. 网络环境：万兆。
  3. 图谱大小：十亿级别节点（属性较少），百亿级别边（有向，无属性或带权值）。

  4. Spark 集群

    1. 版本信息：Spark 2.1.0

实际上 Nebula Graph 的应用资源共计 2T 左右 memory (3 30 executor + 1 driver) 25G。

3.Spark 批量导入

3.1 根底流程

  1. 打包 sst.generator（Spark 生成 sst 所须要的包）。
  2. 配置 Nebula Graph 集群，Nebula Graph 集群失常启动，创立图谱。
  3. Spark 配置文件 config.conf（能够参考文档《Spark 导入工具》）进行配置。
  4. 排查 Spark 集群是否存在抵触的包。
  5. Spark 启动时应用配置文件和 sst.generator 高兴地导入。
  6. 数据校验。

3.2 一些细节

  1. 批量导入前 举荐先建设索引。

这里举荐先建设索引的起因是：批量导入仅在非线上图谱进行，尽管建设索引能够抉择是否在提供服务的同时进行，然而为了避免后续 REBUILD 呈现问题，这边能够优先建好索引。带来的问题就是在批量导入结点时绝对较慢。

  1. 举荐用 int 型节点 ID（能够应用 Snowflake 算法 等），如果节点的 ID 不是 int 型，这里能够通过在节点 / 边中退出 policy: "uuid" 来设置主动生成 uuid。
  2. 如果应用的是独自的 Spark 集群可能不会呈现 Spark 集群有抵触包的问题，该问题次要是 sst.generator 中存在可能和 Spark 环境内的其余包产生抵触，解决办法是 shade 掉这些抵触的包，或者改名。
  3. Spark 调优方面：能够依据理论状况调整参数，尽量升高 memory 以节约资源，绝对的能够适当进步并行度减速。

3.3 导入后果

十亿级别节点（属性较少），百亿级别边（有向，无属性或带权值），提前建好索引的状况下大概耗费 20 小时左右导入全图。

3.4 对于 PR

因为在较早的版本应用了 Spark 导入，天然也有一些不太欠缺的中央，这边也提出了一些高见，对 SparkClientGenerator.scala 略作了批改。

  1. 最早在应用 Spark Writer（现：Exchange）写入 Nebula Graph 时，发现错列的问题。

通过看源码发现 SparkClientGenerator.scala 存在 BUG，读取的是配置文件的地位而非 parquet/json 文件的地位，修复后提了我第一个 PR#2187，有幸通过

  1. 后续发现应用 SparkClientGenerator 主动生成 uuid/hash 性能时，存在会呈现反复的双引号的问题，导致无奈导入。

这块能够说是因为解决问题的想法不同，提交了好屡次。反复引号的问题归根结底是对类型转化的时候增加了一次双引号，我这边发现有个 extraIndexValue 的办法能够把用户自填的非 string 类型的转成 string 类型，我这边想着可能会有用户想 把非 string 型的 index 转成 uuid/hash（比方 array），所以批改的比拟多。

然而和官网 @darionyaphet 沟通后，发现我这种做法其实是对数据源进行了批改，用户传 array 等不反对的类型时，应该报错而不是转换类型（这个的确，一开始只思考到了逻辑上跑通以及本人这边业务的应用，没思考通用性）。从新批改，提交 PR #2258，通过。通过这次 PR 我也学到了很多。

  1. 之后发现 nebula-python 也有和官网 thrift 抵触的问题，原本想 shade 后提 PR，然而感觉这个改变太大了，所以间接提给官网，近期也修复了。

Nebula Graph 旁白：欢送社区小伙伴来 GitHub 给咱们提 PR，GitHub 传送门：https://github.com/vesoft-inc/nebula/issues

4. 总结 & 瞻望

因为之前调研过 JanusGraph，Nebula Graph 给我的第一印象就是：暗坑绝对较少、社区反馈十分及时。在测试后 Nebula Graph 又用她的效率证实了本人，成为了分布式图谱的首选项。

Nebula Graph 社区、群组、PR 官网反馈十分及时，这是图谱迅速、茁壮成长的不可代替的重要因素，也心愿能够后续能够持续见证 Nebula Graph 的成长，持续为 Nebula Graph 生态的欠缺添砖加瓦！

喜爱这篇文章？来来来，给咱们的 GitHub 点个 star 表激励啦~~ ????‍♂️????‍♀️ [手动跪谢]

Nebula Graph Meetup 深圳场报名中：https://www.huodongxing.com/event/4572357498700，期待你来现场交换技术 ????

退出移动版