データフロー ジョブを使用して Google ストレージから BigTable にデータを書き込んでいます。
Big テーブルの「Write-requests」グラフを確認すると、1.5k から 9k の間で変動していることがわかります。一貫してデータを渡しているため、一貫性を保つ必要があります。
ログを確認したところ、このステートメントが頻繁に出てくることがわかりました'Retrying failed call. Failure #1, got: Status{code=UNAVAILABLE, description=Temporary problem while looking up metadata for table AID_KRUXID, cause=null}'
「Write-requests」でこのような変化が見られる理由を理解したいのですが、上記のロガーステートメントは書き込み要求に影響を与えますか、それとも私が認識していない他の理由がありますか?
ありがとう！あらかじめ
コメントによると、OP は空のテーブルに書き込みます。
空のテーブルへの書き込みのパフォーマンスを向上させるには、テーブルを事前に分割する必要があります。テーブルを事前に分割しない場合、テーブルには単一の Cloud Bigtable サーバー ノードによってホストされる単一のタブレットが含まれるため、スループットはクラスタ全体で並列化されるのではなく、単一のノードに制限されます。
テーブルを事前に分割することで、Cloud Bigtable に多数の (空の) タブレットを作成するように指示し、それらのタブレットをさまざまなサーバー ノードに分散させます。
テーブルを事前に分割できるのは、作成時のみです。テーブルを作成すると、Bigtable がタブレットの分割と結合の管理を引き継ぎ、影響を与えることはできなくなります。
もう 1 つ注意すべき点は、分割前のテーブルをしばらく (たとえば 1 日以上) アイドル状態のままにしておくと、テーブルにアクティビティがないため、Bigtable が分割を元に戻してしまうことです。したがって、作業が取り消される前に、作成後すぐに事前分割テーブルの使用を開始する必要があります。
もう 1 つの経験則は、各タブレットが最大 512 MB のデータを持つようにタブレット スプリットを作成することです。
テーブルを事前に分割するように Bigtable に指示するには、次の 2 つの方法があります。
これらの管理 API のいずれかを使用します。
Admin.createTable(HTableDescriptor desc, byte[][] splitKeys)
分割キーを自分で計算して手動で指定します。データが辞書式キースペース全体に均等に分散されていない場合に役立ちます。
Admin.createTable(HTableDescriptor desc, byte[] startKey, byte[] endKey, int numRegions)
Bigtable に、提供された 2 つのキーとnumRegionsの間に偶数の分割を作成するように依頼します。Bigtable が Tablets と呼んでいるものは、HBase が region と呼んでいるため、これらの用語は同等であることに注意してください。startKeyendKey
Admin.createTableAsync(HTableDescriptor desc, byte[][] splitKeys)
最初の方法と同じですが、非同期です。
9 つの Dataflow ワーカーを使用するか、ジョブの実行中に Bigtable クラスタを 8～9 ノードに増やすことを検討してください。25 個のワーカーが 3 つの Bigtable クラスタを圧倒し、大きなレイテンシが原因で再試行が発生して Bigtable がさらに圧倒されるという悪い状態につながります。私の経験則では、3 つのクライアント側 CPU と 1 つの Bigtable ノードです。
あなたはすでにSOでこの質問を数回しており、私は答えました。私の答えが明確でない場合は申し訳ありません。Dataflow ワーカーと Cloud Bigtable ノードの適切なバランスが、この問題を解決する唯一の方法です。