从titan(在hbase上)读取一个大的图形到spark

s8vozzvw  于 2021-06-10  发布在  Hbase
关注(0)|答案(1)|浏览(648)

我正在研究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等)?如果是的话,你能给我一些建议吗?

nimxete2

nimxete21#

大约一年前,我遇到了与您描述的相同的挑战—我们有一个非常大的titan示例,但我们无法在其上运行任何olap进程。
我对这个问题研究得相当深入,但我找到了什么解决办法( SparkGraphComputer , TitanHBaseInputFormat )要么速度很慢(在我们的量表中是几天或几周),要么就是有故障和丢失数据。慢的主要原因是他们都使用了hbase主api,这成为了速度的瓶颈。
所以我实现了mizo-它是hbase上titan的spark rdd,它绕过hbase主api,解析hbase内部数据文件(称为hfiles)。
我已经在一个相当大的规模上进行了测试——一个包含数千亿元素的泰坦图,重约25tb。
因为它不依赖hbase公开的scanapi,所以速度要快得多。例如,在我提到的图中计算边大约需要10个小时。

相关问题