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