我正在研究titan（在hbase上）作为一个大型分布式图形数据库的候选者。我们需要oltp访问（快速、多跳的图形查询）和olap访问（将图形的全部或大部分加载到spark中进行分析）。
据我所知，我可以使用gremlin服务器来处理oltp风格的查询，其中我的结果集很小。因为我的查询将由ui生成，所以我可以使用api与gremlin服务器接口。到目前为止，还不错。
这个问题与olap用例有关。由于hbase中的数据将与spark执行器位于同一位置，因此使用 HDFSInputFormat . 如果从驱动程序执行gremlin查询，然后将数据分发回执行者，则效率会很低（实际上，考虑到投影的图形大小，这是不可能的）。
我找到的最好的指导是titan github回购的一个未结束的讨论(https://github.com/thinkaurelius/titan/issues/1045)这表明（至少对于cassandra后端而言）标准 TitanCassandraInputFormat 应该是用来阅读泰坦表的。hbase后端没有任何声明。
然而，在阅读了底层的titan数据模型之后(http://s3.thinkaurelius.com/docs/titan/current/data-model.html)似乎“原始”图形数据的一部分是序列化的，没有解释如何从内容重建属性图。
所以，我有两个问题：
1） 我上面所说的一切是正确的，还是我遗漏了什么/误解了什么？
2） 有没有人能够从hbase读取一个“原始”的泰坦图，并在spark中重建它（在graphx中或者作为Dataframe、rdd等）？如果是的话，你能给我一些建议吗？
1条答案
按热度按时间nimxete21#
大约一年前，我遇到了与您描述的相同的挑战—我们有一个非常大的titan示例，但我们无法在其上运行任何olap进程。
我对这个问题研究得相当深入，但我找到了什么解决办法(
SparkGraphComputer,TitanHBaseInputFormat)要么速度很慢（在我们的量表中是几天或几周），要么就是有故障和丢失数据。慢的主要原因是他们都使用了hbase主api，这成为了速度的瓶颈。所以我实现了mizo-它是hbase上titan的spark rdd，它绕过hbase主api，解析hbase内部数据文件（称为hfiles）。
我已经在一个相当大的规模上进行了测试——一个包含数千亿元素的泰坦图，重约25tb。
因为它不依赖hbase公开的scanapi，所以速度要快得多。例如，在我提到的图中计算边大约需要10个小时。