我正在研究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等）？如果是这样，你能给我任何指示吗？
答案 0 :(得分：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小时。