从 Titan（在 HBase 上）读取大图到 Spark

Question

我正在研究 Titan（在 HBase 上）作为大型分布式图形数据库的候选者。我们需要 OLTP 访问（对图进行快速、多跳查询）和 OLAP 访问（将图的全部（或至少大部分）加载到 Spark 中进行分析）。

据我了解，我可以使用 Gremlin 服务器来处理我的结果集很小的 OLTP 样式查询。由于我的查询将由 UI 生成，因此我可以使用 API 与 Gremlin 服务器交互。到目前为止，一切顺利。

问题与 OLAP 用例有关。由于 HBase 中的数据将与 Spark 执行器位于同一位置，因此使用 HDFSInputFormat 将数据读入 Spark 会很有效。从驱动程序执行 Gremlin 查询然后将数据分发回执行程序是低效的（事实上，考虑到投影图的大小，这是不可能的）。

我发现的最佳指导是来自 Titan GitHub 存储库 (https://github.com/thinkaurelius/titan/issues/1045) 的未结束讨论，这表明（至少对于 Cassandra 后端）标准 TitanCassandraInputFormat 应该 > 阅读 Titan 表格。没有任何关于 HBase 后端的声明。

但是，在阅读了有关底层 Titan 数据模型 (http://s3.thinkaurelius.com/docs/titan/current/data-model.html) 的信息后，“原始”图数据的部分似乎是序列化的，没有解释如何从内容中重建属性图。

所以，我有两个问题：

1) 我上面所说的一切都是正确的，还是我错过/误解了什么？

2) 有没有人设法从 HBase 读取“原始”Titan 图并在 Spark 中重建它（在 GraphX 中或作为 DataFrames、RDD 等）？如果有，能否指点一下？

Answer 1

大约一年前，我遇到了与您描述的相同的挑战——我们有一个非常大的 Titan 实例，但我们无法在其上运行任何 OLAP 进程。

我对该主题进行了深入研究，但我发现的任何解决方案（SparkGraphComputer、TitanHBaseInputFormat）要么非常缓慢（在我们的规模中需要几天或几周的时间），要么只是错误和丢失的数据。速度慢的主要原因是他们都使用了HBase主API，结果是速度瓶颈。

所以我实现了Mizo - 它是 HBase 上 Titan 的 Spark RDD，它绕过 HBase 主 API，并解析 HBase internal data files（称为 HFiles）。

我已经在相当大的范围内对其进行了测试——一个包含数千亿元素的 Titan 图，重约 25TB。

因为它不依赖于 HBase 公开的 Scan API，所以速度要快得多。例如，计算我提到的图表中的边大约需要 10 小时。