我正在研究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等)？如果是的话,你能给我指点吗？

最佳答案 大约一年前,我遇到了与你描述的相同的挑战 – 我们有一个非常大的Titan实例,但是我们无法在其上运行任何OLAP进程.

我已经非常深入地研究了这个主题,但是我发现的任何解决方案(SparkGraphComputer,TitanHBaseInputFormat)要么非常慢(我们规模上的几天或几周),要么只是错误和错过数据.缓慢的主要原因是所有这些都使用了HBase主API,结果成为速度瓶颈.

所以我实现了Mizo – 它是HBase上Titan的Spark RDD,它绕过了HBase主API,并解析了HBase internal data files(称为HFiles).

我已经对它进行了大规模的测试 – 一个拥有数千亿元素的Titan图表,重约25TB.

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