簡単に言えば、一連の ASCII テキスト ファイル (別名「入力ファイル」) に含まれるデータを Accumulo に取り込むことを希望する顧客がいます。
これらのファイルは、さまざまなデータ フィード デバイスから出力され、非 Hadoop/非 Accumulo ノード (別名「フィード ノード」) で継続的に生成されます。すべてのフィードの全体的なデータ スループット レートは、非常に高いと予想されます。
簡単にするために、すべてのデータが Accumulo の 1 つの順方向インデックス テーブルと 1 つの反転 [逆] インデックス テーブルになると仮定します。
pyaccumulo を使用して、Thrift Proxy 経由で Accumulo への接続を確立し、ローカル ファイルシステム (HDFS ではない) から入力ファイルを読み取って解析し、コードで適切な順方向および逆方向のインデックス ミューテーションを作成し、そしてBatchWriter を使用して、順方向および逆方向のインデックス テーブルにミューテーションを書き込みます。ここまでは順調ですね。しかし、それだけではありません。
さまざまな情報源から、Accumulo の高速取り込みには少なくともいくつかの標準的なアプローチがあり、それが私のシナリオに適用される可能性があることを知りました。リソースの使用に関してどのオプションが最も理にかなっているかについてアドバイスを求めています。実装とメンテナンスの容易さ。以下にいくつかのオプションを示します。
- フィード ノードの BatchWriter クライアント: フィード ノードで Accumulo クライアントを実行します。このオプションには、ネットワークを介して順方向と逆方向の両方のインデックス ミューテーションを送信するという欠点があります。また、Accumulo クライアントをサポートするには、フィード ノードで Accumulo/Thrift ライブラリを使用できる必要があります。ただし、このオプションには、入力ファイルの解析とミューテーションの作成の作業が並列化されるという利点があり、以下のオプションと比較して Hadoop クラスターでのディスク I/O を最小限に抑えるようです。
- Accumulo マスター ノード上の BatchWriter クライアント: フィード ノードから Accumulo マスター ノードへの入力ファイルを scp/sftp し、ローカル ファイルシステム上のディレクトリに配置します。次に、Accumulo マスター ノードのみで Accumulo クライアントを実行します。このオプションには、フィード ノードから Accumulo マスター ノードにネットワーク経由で順方向と逆方向の両方のインデックス ミューテーションを送信しないという利点があり、フィード ノードで Accumulo/Thrift ライブラリを使用できる必要はありません。ただし、入力ファイルの解析とミューテーションの作成のすべての作業を Accumulo マスター ノードに行わせ、Accumulo マスターのローカル ディスクを入力ファイルのウェイポイントとして使用するという欠点があります。
- AccumuloOutputFormat を使用した MapReduce: フィード ノードから Accumulo マスター ノードへの入力ファイルを scp/sftp します。次に、それらを定期的に HDFS にコピーし、HDFS から入力ファイルを読み取って解析し、ミューテーションを作成し、AccumuloOutputFormat を使用してそれらを書き込む MapReduce ジョブを実行します。このオプションには、上記の #2 の利点があり、さらに、入力ファイルの解析とミューテーションの作成の作業が並列化されます。ただし、これには、MapReduce ジョブのスピンアップとブレークダウンが常に発生し、それらのプロセスに関連するすべてのオーバーヘッドが発生するという欠点があります。また、関連付けられたディスク I/O で 2 つのディスク ウェイポイント (ローカルおよび HDFS) を使用するという欠点もあります。継続的な取り込みのために実装して維持するのは、やや面倒に思えます。
- AccumuloOutput*File*Format (rfiles) を使用した MapReduce: 入力ファイルをフィード ノードから Accumulo マスター ノードに scp/sftp します。次に、それらを定期的に HDFS にコピーし、HDFS から入力ファイルを読み取って解析し、ミューテーションを作成し、AccumuloOutputFileFormat を使用して rfile を書き込む MapReduce ジョブを実行します。次に、Accumulo シェルを使用して rfile を「取り込み」ます。このオプションには上記の #3 のすべての利点がありますが、他の利点があるかどうかはわかりません (そうですか? Accumulo のマニュアルには、一括取り込みについて次のように記載されています。 BatchWriters を使用してクライアントを介して取り込みます。」どのような場合ですか?)。また、関連するディスク I/O で 3 つのディスク ウェイポイント (ローカル、HDFSx2) を使用することを除いて、上記 #3 のすべての欠点があります。継続的な取り込みのために実装して維持するのは面倒に思えます。
個人的には、Accumulo マスター ノードが関連する処理負荷 (非並列入力ファイルの解析) を処理できる限り、オプション #2 が最も気に入っています。各 Accumulo ノードで Accumulo クライアントを実行し、異なるフィード ノードの出力を異なる Accumulo ノードに送信する #2 のバリアント、またはラウンド ロビンには、クラウド全体で順方向および逆方向のインデックス ミューテーションを送信するという欠点がまだあります。ただし、入力ファイルの解析をより並行して実行できるという利点があります。
私が知る必要があるのは、実行可能なオプションを見逃していませんか? 各オプションの利点/欠点を見逃していませんか? 問題のコンテキスト、特にネットワーク帯域幅/CPU サイクル/ディスク I/O のトレードオフに関係なく、長所/短所のいずれかが取るに足らないか、または非常に重要ですか? BatchWriter と比較して、rfile の有無にかかわらず MapReduce は問題に値しますか? 「戦記」を持っている人はいますか？
ありがとう！