MaxCompute:ハッシュクラスタリング

次のステートメントを使用して、ハッシュクラスタ化テーブルを作成できます。 ステートメントでは、CLUSTERED BYおよびINTO number_of_buckets BUCKETSパラメーターを設定する必要があります。 CLUSTERED BYパラメーターは、ハッシュキーとも呼ばれるクラスターキーを指定します。 INTO number_of_buckets BUCKETSパラメーターは、バケットの数を指定します。 SORTED BYパラメーターはオプションです。 最適な最適化パフォーマンスを実現するには、CLUSTERED BYパラメーターと同じ値を指定することを推奨します。

• 構文

  CREATE TABLE [IF NOT EXISTS] <table_name>
               [(<col_name> <data_type> [comment <col_comment>], ...)]
               [comment <table_comment>]
               [PARTITIONED BY (<col_name> <data_type> [comment <col_comment>], ...)]
               [CLUSTERED BY (<col_name> [, <col_name>, ...])
               [SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])]
               INTO <number_of_buckets> BUCKETS] [AS <select_statement>]

• 例

  • パーティション分割されていないテーブル

    CREATE TABLE T1 (a string, b string, c bigint)
                 CLUSTERED BY (c)
                 SORTED by (c) INTO 1024 BUCKETS;

  • パーティションテーブル

    CREATE TABLE T1 (a string, b string, c bigint)
           PARTITIONED BY (dt string)
           CLUSTERED BY (c)
           SORTED by (c) INTO 1024 BUCKETS;

• パラメーター

  • クラスター

    MaxComputeが指定された列に対してハッシュ操作を実行するハッシュキーを指定します。 ハッシュ操作が実行されると、MaxComputeはハッシュ値に基づいてデータをバケットに分散します。 データスキューやホットスポットの問題を防ぎ、同時実行効率を向上させるために、CLUSTERED BYでは、値の範囲が大きく、重複するキー値の数が少ない列を指定することをお勧めします。 結合操作を最適化するには、一般的に使用される結合キーまたは集計キーを選択することを推奨します。 結合キーおよび集合キーは、従来のデータベースにおける主キーと同様である。

  • によって歌われた

    バケット内のフィールドをソートする方法を指定します。 クエリのパフォーマンスを向上させるために、SORTED BYの設定をCLUSTERED BYパラメーターの設定と一致させることを推奨します。 SORTED BYパラメーターを指定すると、MaxComputeは自動的にインデックスを生成し、インデックスに基づいてクエリを高速化します。

  • 番号_of_bucketsバケットへ

    バケットの数を指定します。 このパラメータは必須であり、データ量に基づいて決定されます。 バケットが多いほど、ジョブの同時実行性が高く、実行効率が高いことを示します。 しかしながら、過剰な数のバケットが存在する場合、過剰な小さなファイルが生成され得る。 過度に高い同時実行もCPU時間を増加させます。 各バケットのデータサイズは500 MB〜1 GBにすることを推奨します。 テーブルが非常に大きい場合は、各バケットのデータサイズを適切に増やすことができます。 結合最適化シナリオでは、シャッフルおよびソートステップを2つのテーブルの結合操作から削除する必要があります。 したがって、テーブル内のバケット数は、他のテーブル内のバケット数の倍数でなければなりません。 例えば、一方のテーブルは256個のバケットを有し、他方のテーブルは512個のバケットを有する。 バケットの数を、512、1,024、2,048、4,096などのN乗の2に設定することを推奨します。 これにより、MaxComputeはバケットを自動的に分割およびマージし、シャッフルとソートのステップを削除できます。

パーティションテーブルの場合、MaxComputeではALTER tableステートメントを実行して、ハッシュクラスタリングプロパティをテーブルに追加したり、ハッシュクラスタリングプロパティをテーブルから削除したりできます。

• 構文

  -- Change a table to a hash-clustered table.
  ALTER TABLE <table_name> [CLUSTERED BY (<col_name> [, <col_name>, ...])
                         [SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])]
                         INTO <number_of_buckets> BUCKETS];
  -- Change a hash-clustered table to a non-hash-clustered table.
  ALTER TABLE <table_name> NOT CLUSTERED;

• 使用上の注意

  • ALTER TABLEステートメントは、パーティション分割テーブルのクラスタリングプロパティのみを変更できます。 クラスタリングプロパティは、パーティション分割されていないテーブルに追加した後は変更できません。

  • ALTER TABLEステートメントは、INSERT OVERWRITEステートメントを使用して生成された新しいパーティションを含む、テーブルの新しいパーティションに対してのみ有効です。 新しいパーティションは、ハッシュクラスタリングプロパティに基づいて格納されます。 既存のパーティションのストレージ形式は変更されません。

  • ALTER TABLE文は、テーブルの新しいパーティションに対してのみ有効です。 したがって、このステートメントでパーティションを指定することはできません。

ALTER TABLEステートメントは、既存のテーブルにのみ適しています。 ハッシュクラスタリングプロパティが既存のテーブルに追加された後、ハッシュクラスタリングプロパティに基づいて新しいパーティションが格納されます。

ハッシュクラスタ化テーブルを作成した後、次のステートメントを実行してテーブルのプロパティを表示できます。 ハッシュクラスタリングのプロパティは、返された結果の拡張情報に表示されます。

DESC EXTENDED <table_name>;

次の図は、返される結果の例を示しています。 パーティションテーブルの場合、テーブル内のパーティションのプロパティを表示するには、次のステートメントも実行する必要があります。

DESC EXTENDED <table_name> partition(<pt_spec>);

次の図は、返される結果の例を示しています。

次のサンプルステートメントは、クエリ操作を示しています。

CREATE TABLE t1 (id bigint, 
                 a string, 
                 b string)
             CLUSTERED BY (id)
             SORTED BY (id) into 1000 BUCKETS; 
... 
SELECT t1.a, t1.b FROM t1 WHERE t1.id=12345;

共通テーブルの場合、クエリ操作には完全なテーブルスキャン操作が必要です。 テーブルのデータ量が多すぎると、多くのリソースを消費する可能性があります。 上記のCREATE TABLEステートメントでは、データはハッシュシャッフルされ、id列に基づいてソートされます。 このようにして、クエリ操作は著しく単純化される。

1. クエリジョブは、値12345に対応するバケットを見つけることができます。 このように、ジョブは、すべての1,000バケットではなく、単一のバケット内のデータをスキャンする必要があります。 このプロセスはバケットプルーニングと呼ばれます。

2. バケット内のデータは、id列に基づいてソートおよび保存されます。 MaxComputeは自動的にインデックスを作成し、INDEX LOOKUP関数を使用して関連するレコードを検索します。

これにより、マッパーの数と、MaxComputeによってロードされて読み取られるデータの量が大幅に削減されます。 ロードおよび読み取りされるデータの量を減らすために、MaxComputeでは、マッパーがインデックスを使用してデータが保存されているページを直接検索できます。

次のサンプルステートメントは、クエリ操作を示しています。

SELECT department, SUM(salary) FROM employee GROUP BY (department);

ほとんどの場合、テーブルからdepartment列のデータを照会すると、department列のデータがシャッフルされ、ソートされます。 そして、ストリーム集約操作を行い、departmentでデータをグループ化する。 ただし、テーブルの作成時にCLUSTERED BY (department) とSORTED BY (department) をステートメントで指定すると、クエリ操作にはシャッフル操作と並べ替え操作は不要になります。

例えば、簡単な実験が行われる。 この実験では、TPC-Hデータセットに100 GBのデータを含むlineitemテーブルを使用します。 テーブルには、INT、DOUBLE、STRINGなどのさまざまなデータ型のデータが含まれています。 同じデータと同じ圧縮方法が使用されている場合、ハッシュクラスタ化テーブルはストレージスペースの約10% を節約できます。 以下の図は、比較結果を示す。

• ハッシュクラスタリングは使用されません。

• ハッシュクラスタリングが使用される。

次の図は、TPC-HのQ4クエリが共通テーブルに対して実行されるFuxiジョブの実行計画を示しています。次の図は、テーブルのハッシュクラスタリングを有効にした後のFuxiジョブの実行計画を示しています。 実行計画では、有向非巡回グラフ (DAG) が大幅に簡略化されており、これがパフォーマンス向上の鍵となります。