タイタンからHBaseの大きなグラフをSparkに読み込む

Question

私は大規模な分散グラフデータベースの候補としてTitan（HBase上）を研究しています。 OLTPアクセス（グラフ上の高速マルチホップクエリ）とOLAPアクセス（グラフの全部または少なくとも大部分を解析用にSparkにロード）の両方が必要です。

私が理解しているように、Gremlinサーバーを使用して、OLTPスタイルのクエリを処理して、結果セットを小さくすることができます。私のクエリはUIによって生成されるので、APIを使ってGremlinサーバとインターフェースすることができます。ここまでは順調ですね。

この問題は、OLAPの使用例に関係しています。 HBaseのデータはSparkエグゼキュータと同じ場所に配置されるため、HDFSInputFormatを使用してデータをSparkに読み込むと効率的です。ドライバからGremlinクエリを実行し、そのデータをエグゼキュータに戻すのは非効率的です（実際には、投影されたグラフのサイズでは不可能です）。

私が見つけた最高のガイダンスは標準TitanCassandraInputFormatは、タイタンのテーブルを読み取るための作業がすべき（少なくともカサンドラバックエンド用）ことを示唆しているタイタンGitHubのレポ（https://github.com/thinkaurelius/titan/issues/1045）からの未締結の議論です。 HBaseバックエンドについては何も主張されていません。

しかし、基本的なタイタンデータモデル（http://s3.thinkaurelius.com/docs/titan/current/data-model.html）について読むと、内容からプロパティグラフを再構築する方法についての説明がなく、「生の」グラフデータがシリアル化されているように見えます。

だから、私は2つの質問があります。

1）は、私が正しいの上に述べてきたすべてのものか、それとも私が見逃している/誤解何か？

2）HBaseの「生の」タイタングラフを読んで、Spark（GraphXまたはDataFrames、RDDなど）で再構築できた人はいますか？もしそうなら、あなたは私に何か指針を与えることができますか？

Answer 1

約1年前、私はあなたと同じ挑戦に遭遇しました - 私たちは非常に大きなTitanインスタンスを持っていましたが、OLAPプロセスを実行できませんでした。

私はかなり深く研究しましたが、私が見つけた解決策（SparkGraphComputer、TitanHBaseInputFormat）は非常に遅い（数日または数週間の問題）か、データが不足していました。低速の主な理由は、すべてが速度のボトルネックと判明したHBaseメインAPIを使用していたことでした。

Mizoを実装しました。HBaseの主APIをバイパスし、HBase internal data files（HFilesと呼ばれます）を解析するのはHBaseのTitanのSpark RDDです。

私はこれを非常に大規模にテストしました。数千億個の要素を持ち、約25TBのタイタングラフです。

HBaseが公開するスキャンAPIに依存しないため、はるかに高速です。例えば、私が述べたグラフの辺の数は、約の10時間となります。