Bigtable から Dataflow にデータを読み取るには、Apache Beam Bigtable I/O コネクタを使用します。
並列処理
並列処理は、Bigtable クラスタ内のノードの数で制御されます。各ノードは 1 つ以上のキー範囲を管理しますが、キー範囲はロード バランシングの一環としてノード間を移動できます。詳細については、Bigtable ドキュメントの読み取りとパフォーマンスをご覧ください。
インスタンスのクラスタ内のノードの数に応じて課金されます。Bigtable の料金をご覧ください。
パフォーマンス
次の表に、Bigtable 読み取りオペレーションのパフォーマンス指標を示します。ワークロードは、Apache Beam SDK 2.48.0 for Java を使用して、1 つの e2-standard2
ワーカーで実行されています。Runner v2 は使用されていません。
1 億件のレコード | 1 KB | 1 列 | スループット(バイト) | スループット(要素) |
---|---|---|
読み取り | 180 MBps | 170,000 要素/秒 |
これらの指標は、単純なバッチ パイプラインに基づいています。これは I/O コネクタ間でのパフォーマンスの比較を目的としており、必ずしも実際のパイプラインを表すものではありません。Dataflow パイプラインのパフォーマンスは複雑で、VM タイプ、処理されるデータ、外部のソースとシンクのパフォーマンス、ユーザーコードに左右されます。指標は Java SDK の実行に基づくものであり、他の言語 SDK のパフォーマンス特性を表すものではありません。詳細については、Beam I/O のパフォーマンスをご覧ください。
ベスト プラクティス
新しいパイプラインの場合は、
CloudBigtableIO
ではなくBigtableIO
コネクタを使用します。パイプラインのタイプごとに個別のアプリ プロファイルを作成します。アプリ プロファイルを使用すると、サポートと追跡の両方で、パイプライン間のトラフィックの識別に役立つ指標を使用できます。
Bigtable ノードをモニタリングします。パフォーマンスのボトルネックが発生した場合は、Bigtable 内で CPU 使用率などのリソースが制限されているかどうかを確認します。詳細については、モニタリングをご覧ください。
デフォルトのタイムアウトは、ほとんどのパイプラインで適切に調整されています。ストリーミング パイプラインで Bigtable からの読み取りが停止しているように見える場合は、
withAttemptTimeout
を呼び出して試行タイムアウトを調整してみてください。Bigtable 自動スケーリングを有効にするか、Bigtable クラスタのサイズを変更して、Dataflow ジョブのサイズに合わせてスケーリングすることを検討してください。
Dataflow ジョブに
maxNumWorkers
を設定して、Bigtable クラスタの負荷を制限することを検討してください。シャッフルの前に Bigtable 要素で大規模な処理が行われると、Bigtable の呼び出しがタイムアウトすることがあります。その場合は、
withMaxBufferElementCount
を呼び出して要素をバッファに格納できます。読み取りオペレーションをストリーミングからページ分割に変換することで、問題を回避できます。ストリーミング パイプラインとバッチ パイプラインの両方に単一の Bigtable クラスタを使用し、Bigtable 側でパフォーマンスが低下する場合は、クラスタにレプリケーションを設定することを検討してください。次に、バッチ パイプラインとストリーミング パイプラインを分離して、異なるレプリカから読み取るようにします。詳細については、レプリケーションの概要をご覧ください。
次のステップ
- Bigtable I/O コネクタのドキュメントを確認する。
- Google 提供のテンプレートのリストを確認する。