手動バケッティング

パーティションを使用する場合、DISTRIBUTED ..文は各パーティション内でデータを分割するルールを記述します。

パーティションを使用しない場合、Table全体にわたってデータを分割するルールを記述します。

各パーティションに対して個別にバケッティング方法を指定することも可能です。

バケットカラムは複数のカラムが可能です。AggregateとUniqueモデルの場合、Keyカラムである必要がありますが、duplicate key data modelの場合、keyとvalueの両方のカラムが可能です。バケットカラムはPartitionカラムと同じでも異なっていても構いません。

バケットカラムの選択には、クエリスループットとクエリ同時実行性とのトレードオフが伴います：

• 複数のバケットカラムを選択した場合、データ分散はより均一になります。クエリ条件にすべてのバケットカラムの等価条件が含まれていない場合、クエリはすべてのバケットの同時スキャンを引き起こし、クエリスループットを向上させ、個々のクエリのレイテンシを削減します。このアプローチは高スループット、低同時実行のクエリシナリオに適しています。
• 1つまたは少数のバケットカラムのみを選択した場合、ポイントクエリは1つのバケットのスキャンのみを引き起こすことができます。この場合、複数のポイントクエリが同時実行される際、異なるバケットのスキャンを引き起こす確率が高くなり、クエリ間のIO影響を削減します（特に異なるバケットが異なるディスクに分散されている場合）。したがって、このアプローチは高同時実行ポイントクエリシナリオに適しています。

バケット数とデータ量の推奨事項：

• Tableのtabletの総数は（パーティション num * バケット num）と等しくなります。
• 拡張を考慮しない場合、Tableのtablet数はクラスター内のディスクの総数をやや上回ることを推奨します。
• 理論的には、単一tabletのデータ量に上限や下限はありませんが、1G - 10Gの範囲内にすることを推奨します。単一tabletのデータ量が小さすぎる場合、データ集約効果が良くなく、メタデータ管理の負荷が高くなります。データ量が大きすぎる場合、レプリカの移行と補充に不利であり、Schema ChangeやRollupなどの失敗した操作の再試行コストが増加します（これらの操作の再試行の粒度はtabletです）。
• tabletのデータ量の原則と数量の原則が競合する場合、データ量の原則を優先することを推奨します。
• Table作成時は、各パーティションのバケット数を統一して指定します。ただし、パーティションを動的に追加する際（ADD PARTITION）、新しいパーティションのバケット数を個別に指定できます。この機能は、データの削減や拡張を処理する際に便利に使用できます。
• パーティションのバケット数は一度指定すると変更できません。したがって、バケット数を決定する際は、クラスター拡張シナリオを事前に考慮する必要があります。例えば、ディスクが1つずつある3台のホストしかなく、バケット数を3以下に設定した場合、後でマシンを追加しても同時実行性は改善されません。

以下にいくつかの例を示します：10台のBEがあり、それぞれ1つのディスクを持つと仮定します。Tableの合計サイズが500MBの場合、4-8個のtabletを検討できます。5GBの場合：8-16個のtablet。50GBの場合：32個のtablet。500GBの場合：Tableをパーティション化することを推奨し、各パーティションサイズを約50GBとし、パーティションあたり16-32個のtabletにします。5TBの場合：Tableをパーティション化することを推奨し、各パーティションサイズを約50GBとし、パーティションあたり16-32個のtabletにします。

Tableのデータ量はSHOW DATAコマンドを使用して確認でき、結果をレプリカ数で割ることでTableの実際のデータ量を取得できます。

ランダム分散

• OLAPTableに更新タイプのフィールドがない場合、TableのデータバケッティングモードをRANDOMに設定することで、深刻なデータスキューを回避できます。データがTableの対応するパーティションにインポートされる際、単一のインポートジョブの各バッチは書き込み用にtabletをランダムに選択します。
• TableのバケッティングモードがRANDOMに設定されている場合、バケッティングカラムがなく、バケッティングカラムの値に基づいて少数のバケットのみをクエリすることはできません。Tableに対するクエリは、パーティションにヒットするすべてのバケットを同時にスキャンします。この設定はTableデータ全体の集約クエリ分析に適していますが、高同時実行ポイントクエリには適していません。
• OLAPTableのデータ分散がRandom Distributionの場合、データインポート中にsingle-tabletインポートモードを設定できます（load_to_single_tabletをtrueに設定）。その後、大容量データインポート中、タスクは対応するパーティションにデータを書き込む際、1つのtabletにのみ書き込みます。これにより、データインポートの同時実行性とスループットを改善し、データインポートとcompactionによる書き込み増幅を削減し、クラスターの安定性を確保できます。