本文由英特西格信息有限公司(IntSig)大数据团队工程师刘家浩编写。他一直在玩星云图,是我们引以为豪的 GitHub 贡献者之一。这篇文章分享他的经验导入数据星云图与火花。

为什么选择星云图?

与图形相关的业务越来越复杂,一些流行的图形数据库中也发现了性能瓶颈。例如,单个计算机很难缩放到较大的图形。在性能方面,Neo4j的本机图形存储具有不可替代的优势。在我的调查中,JanusGraph、Dgraph 和其他图形数据库在这方面无法与 Neo4j 相媲美。JanusGraph 在 OLAP 中性能非常好,可以在一定程度上支持 OLTP。但是,这不再是 JanusGraph 的优势,因为某些技术(如 GraphFrame)足以满足 OLAP 要求。此外,由于 Spark 3.0 开始支持 Cypher,我发现与图形的 OLTP 要求相比,其 OLAP 要求可以满足更多技术。因此,星云图无疑是对低效率分布式OLTP数据库的突破。

我做了大量的研究,并部署了一些图形数据库。当我对 JanusGraph 的 OLTP 效率进行测试,发现它不能满足我的在线业务需求时,我不再要求图形数据库的 OLAP 和 OLTP 具有相等或接近的性能。但我突然想到星云图的架构具有满足图形要求的所有功能,例如:

  • 分布式:星云图在存储中采用无共享分布式体系结构。
  • 高速 OLTP,这意味着性能应与 Neo4j 相媲美:在星云图中,其存储层查询可直接映射物理地址,物理地址可视为本机图形存储。
  • 高可用服务,这意味着,无需人工中断,数据库可以持续提供稳定的服务:服务在部分故障时可用,快照功能可用。
  • 保证可扩展性:星云图形支持线性扩展,并且支持自定义开发,因为它是开源的。

星云图的架构似乎满足了我们在生产环境中的实际要求。因此,我进行了星云图的研究、部署和测试。在部署和性能测试方面,您可以在星云图官方网站和一些技术博客上找到一些详细信息。请参阅Meituan 的基准测试和腾讯云的性能测试。本文主要介绍我在星云图中的理解和经验后,我使用 Spark 应用程序导入数据到星云图0.0 (测试很早就完成了)

  • 网络:10G网络
  • 图形大小:数十亿个顶点(属性很少),数百亿条边(定向且无属性或加权)
  • 火花群集:使用 Spark 2.1.0。
  • 在此测试中,星云图形总共使用了 2 个 TG 内存,该内存由方程计算:(3*30 执行器 = 1 个驱动程序) * 25 GB。

    使用 Spark 批量导入数据

    程序

    1. sst.generator ,这是 Spark 生成 SST 文件所需的。
    2. 配置星云图形群集,启动星云图形群集,然后创建架构。
    3. 修改 Spark 配置文件 ( config.conf . .有关详细信息,请参阅 Spark配置文件
    4. 检查并确保 Spark 群集中不存在冲突包。
    5. Spark 启动后,使用配置文件 sst.generator 并导入数据。
    6. 验证数据。

    一些提示要遵循

    以下是使用 Spark 应用程序的一些提示:

    1. 我建议在导入数据之前创建索引。

    批量导入数据只能对脱机图形执行。在星云图形中,您可以选择为联机或离线图形服务创建索引。但是,当服务处于脱机状态时,必须重新生成索引。为了防止过程中出现可能 REBUILD INDEX 的问题,我建议在数据插入之前创建一个索引。当然,这样的操作可能会减慢顶点批量导入的速度。

    1. 我建议使用类型 int 值作为顶点 ID。

    您可以使用某些算法(如雪花算法)生成值。如果顶点 ID 不是类型 int ,您可以在配置文件 policy: "uuid" 中用于顶点或边缘类型配置。

    1. 如果您的 Spark 部署在独立模式下,您可以忽略冲突包问题,而这种情况模式下可能不会发生。如果您的 Spark 在群集上运行,则可能会出现此问题,因为 中某些包可能与 Spark sst.generator 群集中某些包冲突。若要解决冲突,可以对这些冲突包进行着色或重命名。

    2. Spark 调优 您可以调整参数以满足业务需求,尽可能减少内存消耗,从而节省资源并加快并行性。

    数据导入性能

    当索引提前构建时,需要大约 20 个小时来批处理导入数十亿顶点(属性很少)和数百亿条边(定向且无属性或加权)。

    将 GitHub PR 提交星云图时吸取的经验教训

    我使用 Spark 应用程序与早期版本的星云图, 所以问题是不可避免的Scala。

    1. 在使用 Spark Writer(现在交换)将数据导入星 云图的早期阶段,某些列无法正确对齐。通过阅读源代码,我发现在 SparkClientGenerator.scala 中存在一个错误,即已读取 Parquet 配置文件 JSON (而不是 或 文件)。我修复了错误,并提交了PR#2187,我的第一个公关星云图。我很高兴公关被批准。

    2. 之后,当我使用 或 SparkClientGenerator 函数时 uuid() hash() ,我发现引入了重复的双引号,因此无法完成批处理导入。

    在数据类型转换过程中引入了额外的双引号。我发现调用的 extraIndexValue 函数可用于将用户定义的值从非字符串类型转换为 String 类型。我想有些用户可能想要将非字符串(例如数组值)索引转换为 uuidhash ,因此我更改了一些源代码并提交了新的 PR。

    不幸的是,新的公关是非常艰难的。我犯了几次承诺,但还是没有得到批准。在与星@darionyaphet图的开发人员)沟通后,我知道我更改了源数据的格式。在他看来,一般来说,当用户导入某些不受支持的格式的数据时,正确的回答是引发异常,而不是直接转换格式。是的,这是有道理的。我过于专注于我的业务场景,我唯一的目标是让代码成功运行,但没有考虑该工具的一般用途。

    对此,我提交了另一个公关,公关#2258,它被批准和合并。我从这个公关中学到很多东西。

    1. 后来,我发现在星云蛇节俭有冲突 fbthrift 。我想我可以遮蔽冲突,并提交另一个公关,但考虑到巨大的修改,我放弃了,并选择提出一个问题星云图,这是最近修复。

    来自星云图的单词:欢迎在 GitHub 上向星云图形提交 PR。以下是供您参考的一些问题:https://github.com/vesoft-inc/nebula/issues

    总结

    在开始使用星云图之前,我已经对JanusGraph进行了彻底的评估。经过比较,我印象非常深刻的是相对较少的秘密错误和星云图的活跃社区。测试后,星云图证明了自己的效率,并成为分布式图形系统的首选 所有用户都可以非常快速地获得答复,并且对资源进行有效审查。我认为这是这个图形数据库快速而强劲增长最重要的因素。我希望我能不断见证星云图的成长,为星云图生态的改善做出贡献!

    Comments are closed.