MaxCompute:Rangeクラスタリング

Rangeクラスタリングは、クラスターキーの完全なソートに基づいて、データを複数のばらばらの範囲に分割します。 各範囲はバケットと見なされ、次の両方の条件を満たす必要があります。

• 重複した値は同じバケットに格納されます。

• 各バケットの値の数は概算です。

次のサンプルステートメントは、Tという名前のテーブルを作成します。

CREATE TABLE T (C1 int) 
    RANGE CLUSTERED BY (C1) 
    SORTED BY (c1) 
    INTO 3 BUCKETS;

C1列の値は、{ 1、8、-3、2、4、1、1、3、8、20、-8、9 } です。

Rangeクラスタリングを有効にすると、次のバケットが取得されます。

• バケット0 : { -8, -3, 1, 1}

• バケット1 : { 2、3、4}

• バケット2 : { 8、8、9、20}

Rangeクラスタリングプロセスは、MaxComputeによって自動的に実装されます。 各範囲を手動で指定する必要はありません。 ビッグデータシナリオでは、範囲の手動構成は効率的または実現可能ではありません。 MaxComputeは、データを自動的にソートおよびサンプリングし、各範囲のデータ分布に基づいてヒストグラムを作成し、各範囲のヒストグラムを組み合わせて計算します。 これにより、MaxComputeは範囲クラスタリングの最適なパフォーマンスを実現します。

テーブルを作成するときに、RANGE CLUSTERED BYとSORTED BYの両方を指定して、データがグローバルにソートされるようにすることができます。 次に、MaxComputeは、グローバルインデックスとファイルインデックスの2つのレベルのインデックスを自動的に作成します。 次の図に示すように、インデックスを使用してキー値をすばやく検索します。

Rangeクラスタリングには、ハッシュクラスタリングに対して次の利点があります。

• Rangeクエリがサポートされています。

  たとえば、クエリ条件がc < 3の場合、システムはグローバルインデックスに基づいてバケット2とバケット3を除外し、バケット0とバケット1からデータをクエリできます。 ハッシュクラスタリングの場合、バケットのプルーニングは等価クエリに対してのみ実行できます。

• マルチキークエリがサポートされています。

  たとえば、テーブル作成時にRANGE CLUSTERED BY (c1, c2, c3) SORTED BY (c1, c2, c3) を指定した場合、範囲クラスタリングとデータストレージはc1、c2、c3の順に実装されます。 このようにして、c1 = 100 AND c2 > 0やc1 = 100 AND c2 = 50 AND c3 < 5などの複雑な条件に基づいてテーブルデータを照会できます。 このタイプのクエリは、ハッシュクラスタリングに基づいて実装することはできません。

  重要

  複数のキーに基づくクエリの場合、クエリ条件のキーは順番に並べ替える必要があり、最後のキーのみを使用して値の範囲を指定できます。

• 範囲クラスタリングは、グローバルソートの効率的な実装を提供します。

  範囲クラスタリングを使用する前は、MaxComputeでは1つのインスタンスのみを使用してデータをグローバルにソートできます。 範囲クラスタリングを使用した後、各範囲のデータを同時にソートしてから組み合わせることができ、効率が大幅に向上します。

CREATE TABLEステートメントを使用して、範囲クラスタ化テーブルを作成できます。 このステートメントでは、RANGE CLUSTERED BYパラメーターを指定する必要があります。 INTO number_of_buckets BUCKETSおよびSORTED BYパラメーターはオプションです。 ほとんどの場合、SORTED BYとRANGE 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>], ...)]
               [RANGE 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 int)
                 RANGE CLUSTERED BY (c)
                 SORTED by (c)
                 INTO 1024 BUCKETS;

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

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

• パラメーター

  • によって集められた範囲

    範囲クラスタリングのキーを指定します。 パラメーターを指定すると、MaxComputeは指定したバケット数に基づいて、1つ以上のデータ列を適切な範囲に並べ替えてサンプリングします。 データスキューの問題やホットスポットを防ぎ、同時クエリのパフォーマンスを向上させるために、RANGE CLUSTERED BYで、値の範囲が大きく、重複するキー値がほとんどない列を指定することをお勧めします。 クエリのパフォーマンスを最適化するには、RANGE CLUSTERED BYで一般的に使用される集計キーまたはフィルターキーを指定することを推奨します。

  • によって歌われた

    バケット内のフィールドをソートする方法を指定します。 最適なクエリパフォーマンスを実現するには、SORTED BYとRANGE CLUSTERED BYで同じ値を指定することを推奨します。 SORTED BYを指定すると、MaxComputeはグローバルインデックスとファイルインデックスを自動的に生成し、インデックスを使用してクエリを高速化します。

  • 番号_of_bucketsバケットへ

    ハッシュクラスタリングとは異なり、INTO number_of_buckets BUCKETSは範囲クラスタリングのオプションです。 このパラメーターを指定しない場合、MaxComputeはデータ量に基づいてバケット数を自動的に決定します。 ほとんどの場合、実際の状況に基づいてバケットの数を指定することをお勧めします。

    ハッシュクラスタリングと同様に、範囲クラスタリングのバケットサイズ (512 MB〜1 GB) に基づいてバケット数を設定することを推奨します。 テーブルが大きすぎる場合、多数のバケットが必要になります。 ただし、テーブル内のバケット数は4,000を超えないようにすることを推奨します。

パーティション分割テーブルの場合、ALTER TABLEステートメントを実行して、範囲クラスタリングプロパティを追加または削除できます。

• 構文

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

• 使用上の注意

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

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

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

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

範囲クラスタ化テーブルを作成した後、次のステートメントを実行してテーブルのプロパティを表示できます。 範囲クラスタリングプロパティは、返された結果のExtended Infoに表示されます。

DESC EXTENDED <table_name>;

次の図は、返される結果の例を示しています。 パーティションテーブルの場合、次のステートメントを実行して、パーティションのクラスタリングプロパティを表示することもできます。

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

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

たとえば、単純なクエリ条件id < 3の場合、システムはオプティマイザから条件を抽出し、条件を値の範囲 (-∞, 3) に変換します。 この場合、バケットプルーニングにグローバルインデックスを使用して、データが前の値の範囲内にないバケット2とバケット3の両方を除外できます。 次に、システムはバケット0とバケット1の各ファイルのインデックスを使用して、データをすばやく見つけることができます。 このプロセスは、次の図に示すように、述語プッシュダウンと呼ばれます。次のサンプルステートメントは、データセットに対して範囲クラスタリングが実行された後に、100 GBのデータセットからデータをクエリするために使用されるTPC-H Query 6ステートメントです。 TPC-Hクエリ6ステートメントでは、範囲フィルタリングに基づいて集計操作が実行されます。 範囲クラスタリングでは、2レベルのインデックスを使用してデータをすばやく検索できます。 このようにして、クエリの実行時間と消費されるCPUおよびメモリリソースが大幅に削減されます。

select sum(l_extendedprice * l_discount) as revenue
  from tpch_lineitem l
 where l_shipdate >= '1994-01-01'
   and l_shipdate < '1995-01-01'
   and l_discount >= 0.05
   and l_discount <= 0.07
   and l_quantity < 24;

この例では、次のステートメントを使用して、mf_tabテーブルを範囲クラスタ化テーブルに変更します。 これは、マルチキークエリをよりよく理解するのに役立ちます。

ALTER TABLE mf_project.mf_tab 
            RANGE CLUSTERED BY (project_name, name)
            SORTED BY (project_name, name)
            INTO 1024 BUCKETS;

テーブルが範囲クラスタ化テーブルに変更された後、プロジェクトレベルで集計クエリを実行できます。 例：

SELECT COUNT(*)
  from mf_project.mf_tab
 WHERE project_name="xxxdw"
   AND ds="20180115"
   AND type="TABLE";

複数のキーを使用して、テーブルを正確に見つけることもできます。 例：

SELECT count(*)
  from mf_project.mf_tab
 WHERE project_name="xxxdw"
   AND name="adm_ctu_cle_kba_midun_trade_dd"
   AND type="TABLE";

範囲クエリに複数のキーを使用することもできます。 次のステートメントは、名前がadmで始まるテーブルを照会します。

SELECT count(*)
  from mf_project.mf_tab
 WHERE project_name="xxxdw"
   AND name>="adm"
   AND name < "adn"
   AND type="TABLE";

前述のクエリはすべて、rangeクラスタリングのグローバルソート機能を完全に利用し、述語プッシュダウンを実行して、テーブルスキャンのI/O操作の数を減らし、データフィルタリングとコンピューティングに消費されるCPUとメモリリソースを節約できます。

たとえば、k1、k2は、Tという名前のテーブル内のクラスタキーです。

• クエリ条件がk1 < 5の場合、インデックスベースのクエリの高速化を実現できます。

• クエリ条件がk1 = 10 AND k2 = 20の場合、インデックスベースのクエリ高速化を実現できます。

• クエリ条件がk1 = 10 AND k2 < 0の場合、インデックスベースのクエリ高速化を実現できます。

• クエリ条件がk2 < 0の場合、インデックスベースのクエリの高速化を実現できません。 これは、クエリ条件にk1が指定されていないためです。

• クエリ条件がk1 < 0 AND k2 > 0の場合、インデックスベースのクエリアクセラレーションを使用して、条件k1 < 0を満たすデータを取得できます。 k2 > 0の条件を満たすデータについては、テーブルスキャンが必要である。

たとえば、Tという名前のテーブルは、次のCREATE tableステートメントを使用して作成されます。 テーブルからデータをクエリする場合は、マップステージのテーブルデータに対してGROUP BY操作を実行できます。

CREATE TABLE T (department int, team string, employee string)
       RANGE CLUSTERED BY (department, team)
       SORTED BY (c1, c2)
       INTO 1024 BUCKETS;

SELECT COUNT(*) from T GROUP BY department, team;

次のステートメントは、テーブルfooのデータ構造を示しています。

create table foo(a bigint, b bigint, c bigint)
       range clustered by (a,b)
       sorted by(a,b) into 3 buckets;

テーブルfooのバケットに格納されているデータの範囲は次のとおりです。

Bucket 0: [1,1 : 3,3]
Bucket 1: [5,5 : 7,7]
Bucket 2: [8,8 : 9,9]

上記のバケット範囲は、bucket N: [lower bound values : upper bound values] の形式で指定します。 データが列aで集計される場合、代わりに次のバケット範囲が使用されます。

Bucket 0: [1 : 3]
Bucket 1: [5 : 7]
Bucket 2: [8 : 9]

列aと列bで集計操作の実行計画を直接生成し、3つのインスタンスを開始して各バケットのデータを集計し、出力結果を返すことができます。

ただし、列aの値が複数のバケットに分散している場合、無効な結果が返されます。 例：

Bucket 0: [1,1 : 3,3]
Bucket 1: [3,5 : 7,7]
Bucket 2: [7,8 : 9,9]

列aには2つの値3と7があり、2つのバケットに別々に格納されます。 有効な結果を取得するには、列aに同じ値を持つタプルを同じインスタンスに配置し、タプルを集計する必要があります。 このようにして、次の図に示すように、バケットが再度作成されます。 赤の2本の破線の間隔は、各インスタンスが読み取ることができるデータの範囲を指定します。ヒストグラムは、範囲クラスタリングに必要です。 範囲クラスター化テーブルの場合、クラスターキーとソートキーが同じ場合、各バケットに対応するワーカーは、範囲クラスター化テーブルにデータを挿入するときにクラスターキーの値を取得するために、10,000行ごとにタプルをサンプリングします。 得られた値はヒストグラムに保存される。 各バケットのヒストグラムは、クラスターメタデータファイルに保存されます。 このタイプのヒストグラムは、等深度ヒストグラムと呼ばれる。

各バケットのヒストグラムを取得したら、次のルールに基づいて各ワーカーのバケットを再作成できます。

• 同じグループ化キーを持つタプルは、同じバケットに格納されます。

• データはバケットに均等に分散されます。

各新しいバケットの下限値に基づいて、各ワーカーは有効な範囲のデータを読み取り、有効な結果を返すことができます。

次のコンテンツでは、TPC-Hデータセット内の1テラバイトのデータを含むpartsuppテーブルを使用して、パフォーマンスの向上をテストします。 次のステートメントを実行して、partsuppテーブルをrange-clusteredテーブルに変換します。

CREATE TABLE partsupp ( PS_PARTKEY BIGINT NOT NULL,
                        PS_SUPPKEY BIGINT NOT NULL,
                        PS_AVAILQTY BIGINT NOT NULL,
                        PS_SUPPLYCOST  DECIMAL(15,2)  NOT NULL,
                        PS_COMMENT     VARCHAR(199) NOT NULL)
             RANGE CLUSTERED BY(PS_PARTKEY, PS_SUPPKEY)
             SORTED BY(PS_PARTKEY, PS_SUPPKEY) INTO 128 BUCKETS;

次のクエリ文を実行してテストを実行します。

SELECT ps_partkey, count(*) c FROM partsupp GROUP BY ps_partkey;

• 次のコマンドを実行して、最適化を無効にします。

   set odps.optimizer.enable.range.partial.repartitioning=false;

  サンプル出力:

• 次のコマンドを実行して最適化を有効にします。

  set odps.optimizer.enable.range.partial.repartitioning=true;

  サンプル出力:

テスト結果は、最適化が有効になった後、クエリ速度が57% 向上し、CPU使用率が52% 減少し、メモリ使用量が71% 減少したことを示しています。 パフォーマンスの向上は、データ量とクエリの種類によって異なります。

デフォルトでは、範囲クラスタ化テーブルのグローバルソートアクセラレーションは無効になっています。 グローバルソートの高速化を有効にするには、次のコマンドを実行します。

set odps.optimizer.distribute.ordering.enable=true;

ハッシュクラスタリングと比較して、範囲クラスタリングには次の制限があります。

• rangeクラスタリングのデータ生成コストは、ハッシュクラスタリングのそれよりも高い。 ハッシュクラスタリングは、データのハッシュとソートのための単純な操作にすぎません。 ただし、範囲クラスタリングでは、データのサンプリング、ソート、およびヒストグラムの組み合わせが必要です。 実行期間、CPUコスト、メモリコストを含む全体的な消費は、ハッシュクラスタリングの全体的な消費よりも高くなります。 したがって、ハッシュクラスタリングを使用して問題を解決できる場合は、範囲クラスタリングを使用する必要はありません。

• DYNAMIC PARTITIONまたはINSERT INTOでは、範囲クラスタリングはサポートされていません。

• rangeクラスタリングは、inner join、left outer join、right outer join、semi joinの結合操作でのみサポートされます。 範囲クラスタリングは、反結合または完全外部結合ではサポートされていません。

• rangeクラスタ化テーブルの場合、range clustered BYで指定されるキーは、SORTED BYで指定されるキーと同じである必要があります。 たとえば、テーブルの作成時にfooという名前のテーブルにrange clustered by (a,b) sorted by (a,b) が指定されている場合、このトピックで説明されている最適化をテーブルで実行できます。 ただし、barという名前のテーブルにrange clustered by(a,b) sorted by (b,a) が指定されている場合、このトピックで説明されている最適化はテーブルでは実行できません。

• JOINまたはGROUP BYで指定されるキーは、RANGE CLUSTERED BYで指定されるプレフィックスまたはすべてのキーである必要があります。 たとえば、range clustered by(a,b,c) sorted by(a,b,c) をテーブル作成ステートメントで指定します。 このトピックで説明する最適化は、JOINまたはGROUP BYでキーとしてa、a、b、またはa、b、cが指定されている場合にのみ、テーブルで実行できます。 JOINまたはGROUP BYでキーとしてbまたはa,cが指定されている場合、このトピックで説明されている最適化は実現できません。

• rangeクラスタ化パーティションテーブルの場合、テーブルの2つ以上のパーティションからデータを読み取る場合、このトピックで説明されている最適化は実現できません。 このトピックで説明する最適化は、単一のパーティションを持つパーティションテーブルと非パーティションテーブルでのみ実現できます。