手動バケット化
パーティションを使用する場合、DISTRIBUTED .. ステートメントは各パーティション内でデータを分割するためのルールを記述します。
パーティションを使用しない場合、テーブル全体でデータを分割するためのルールを記述します。
各パーティションに対して個別にバケット方法を指定することも可能です。
バケットカラムは複数のカラムが可能です。AggregateモデルとUniqueモデルでは、Keyカラムである必要がありますが、duplicate keyデータモデルでは、keyカラムとvalueカラムの両方が可能です。バケットカラムは、Partitionカラムと同じでも異なっていても構いません。
バケットカラムの選択には、クエリスループットとクエリ同時実行性のトレードオフが関わります:
- 複数のバケットカラムが選択された場合、データ分布はより均一になります。クエリ条件がすべてのバケットカラムの等価条件を含まない場合、クエリはすべてのバケットの同時スキャンをトリガーし、クエリスループットが向上し、個々のクエリのレイテンシが減少します。このアプローチは高スループット、低同時実行性のクエリシナリオに適しています。
- 1つまたは少数のバケットカラムが選択された場合、ポイントクエリは1つのバケットのスキャンのみをトリガーできます。この場合、複数のポイントクエリが同時実行される際、異なるバケットのスキャンをトリガーする可能性が高くなり、クエリ間のIO影響を軽減します(特に異なるバケットが異なるディスクに分散されている場合)。そのため、このアプローチは高同時実行性のポイントクエリシナリオに適しています。
バケット数とデータ量の推奨事項:
- テーブルのtablet総数は(Partition num * Bucket num)に等しくなります。
- 拡張を考慮しない場合、テーブルのtablet数はクラスター内のディスク総数よりもわずかに多くすることを推奨します。
- 理論的には、単一tabletのデータ量に上限や下限はありませんが、1G - 10Gの範囲内にすることを推奨します。単一tabletのデータ量が小さすぎると、データ集約効果が良くなく、メタデータ管理の負荷が高くなります。データ量が大きすぎると、レプリカの移行と補充に不利であり、Schema ChangeやRollupなどの失敗した操作の再試行コストが増加します(これらの操作の再試行粒度はtabletです)。
- tabletのデータ量原則と数量原則が競合する場合、データ量原則を優先することを推奨します。
- テーブル作成時、各パーティションのバケット数は統一して指定されます。ただし、パーティションを動的に追加する場合(
ADD PARTITION)、新しいパーティションのバケット数を個別に指定できます。この機能は、データ削減や拡張を処理する際に便利に使用できます。 - パーティションのバケット数が指定されると、変更することはできません。そのため、バケット数を決定する際は、クラスター拡張シナリオを事前に考慮する必要があります。例えば、各々1ディスクを持つ3台のホストのみがあり、バケット数を3以下に設定した場合、後でマシンを追加しても、同時実行性を向上させることはできません。
いくつかの例を示します:10台のBEがあり、それぞれ1つのディスクを持つと仮定します。テーブルの総サイズが500MBの場合、4-8 tabletを検討できます。5GBの場合:8-16 tablet。50GBの場合:32 tablet。500GBの場合:テーブルをパーティション化し、各パーティションサイズを約50GB、パーティションあたり16-32 tabletにすることを推奨します。5TBの場合:テーブルをパーティション化し、各パーティションサイズを約50GB、パーティションあたり16-32 tabletにすることを推奨します。
テーブルのデータ量は SHOW DATA コマンドを使用して確認でき、結果をレプリカ数で割ることで、テーブルの実際のデータ量を取得できます。
ランダム分散
- OLAPテーブルにupdate型のフィールドがない場合、テーブルのデータバケットモードをRANDOMに設定することで、深刻なデータスキューを回避できます。データがテーブルの対応するパーティションにインポートされる際、単一インポートジョブの各バッチは、書き込み用にtabletをランダムに選択します。
- テーブルのバケットモードがRANDOMに設定されている場合、バケットカラムがないため、バケットカラムの値に基づいて少数のバケットのみをクエリすることはできません。テーブルへのクエリは、パーティションにヒットするすべてのバケットを同時にスキャンします。この設定は、テーブルデータ全体の集約クエリ分析に適していますが、高同時実行性のポイントクエリには適していません。
- OLAPテーブルのデータ分散がRandom Distributionの場合、データインポート時にシングルタブレットインポートモードを設定できます(
load_to_single_tabletをtrueに設定)。その後、大容量データインポート時、タスクは対応するパーティションにデータを書き込む際に1つのtabletにのみ書き込みます。これにより、データインポートの同時実行性とスループットを向上させ、データインポートとコンパクションによる書き込み増幅を削減し、クラスターの安定性を確保できます。