MaxCompute:Clustering par plage

Les tables avec clustering par hachage présentent les avantages suivants :

• Pour interroger des données en fonction d'une valeur de colonne spécifique, l'algorithme de hachage localise directement le compartiment de hachage (hash bucket). Ce processus, appelé élagage des compartiments (bucket pruning), réduit la quantité de données analysées. Si les données du compartiment sont stockées de manière triée, vous pouvez utiliser des index pour localiser plus précisément les données, ce qui améliore l'efficacité des requêtes.

• Lors de la jointure de deux tables via une colonne spécifique dans chaque table, si la colonne de l'une des tables est hachée, l'étape de redistribution (shuffle) peut être supprimée, permettant ainsi d'économiser des ressources de calcul.

Pour plus d'informations sur la fonctionnalité de clustering par hachage, consultez Clustering par hachage.

Le clustering par hachage présente les limites suivantes :

• La création de compartiments via l'algorithme de hachage peut entraîner des problèmes de déséquilibre des données. Semblables aux problèmes de déséquilibre lors des jointures, ces déséquilibres sont inhérents à l'algorithme de hachage. Une répartition inégale des données d'entrée entre les compartiments provoque des variations considérables de volume de données. Avec le clustering par hachage, chaque compartiment constitue généralement une unité de traitement parallèle. Des différences de volume entre les compartiments sont susceptibles de générer des effets de longue traîne (long tails).

• L'élagage des compartiments prend uniquement en charge les requêtes d'égalité. Pour les conditions d'inégalité (par exemple, valeurs d'une colonne supérieures à 0), il est impossible de localiser les compartiments contenant les données recherchées. Vous devez alors interroger les données dans tous les compartiments.

• Pour les requêtes basées sur plusieurs clés de clustering, les performances ne s'améliorent que si toutes les clés de clustering sont disponibles et si toutes les conditions de requête sont des conditions d'égalité.

  Par exemple, pour interroger des données à partir de la table créée avec l'instruction suivante, les performances ne s'améliorent que si la condition de requête est C1=x AND C2=y. Si vous utilisez C1=x ou C2=y comme condition, la requête n'est pas accélérée par le clustering par hachage. En effet, les valeurs de hachage des clés sont combinées par paires lors des requêtes. Sans cette combinaison, il est impossible de localiser le compartiment contenant les données recherchées ou d'effectuer l'élagage des compartiments.

  CREATE TABLE T2 (C1 int, C2 int, C3 string)
     CLUSTERED BY (C1, C2)
        SORTED by (C1, C2)
         INTO 1024 BUCKETS;

Le clustering par plage divise les données en plusieurs plages disjointes basées sur le tri complet des clés de clustering. Chaque plage est considérée comme un compartiment et doit respecter les deux conditions suivantes :

• Les valeurs dupliquées sont stockées dans le même compartiment.

• Le nombre de valeurs dans chaque compartiment est approximativement équivalent.

L'instruction suivante crée une table nommée T.

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

Les valeurs de la colonne C1 sont { 1, 8, -3, 2, 4, 1, 1, 3, 8, 20, -8, 9 }.

Après activation du clustering par plage, les compartiments suivants sont obtenus.

• Compartiment 0 : { -8, -3, 1, 1, 1 }

• Compartiment 1 : { 2, 3, 4 }

• Compartiment 2 : { 8, 8, 9, 20 }

MaxCompute met automatiquement en œuvre le processus de clustering par plage. Vous n'avez pas besoin de spécifier manuellement chaque plage, ce qui serait inefficace et irréalisable dans les scénarios de big data. MaxCompute trie et échantillonne automatiquement les données, crée un histogramme basé sur la distribution des données de chaque plage, puis combine et calcule l'histogramme de chaque plage. Ainsi, MaxCompute atteint les performances optimales du clustering par plage.

Lors de la création d'une table, spécifiez à la fois RANGE CLUSTERED BY et SORTED BY pour garantir un tri global des données. Ensuite, MaxCompute crée automatiquement deux niveaux d'index : un index global et un index de fichier. Ces index permettent de localiser et de rechercher rapidement les valeurs clés, comme illustré dans la figure suivante.

Le clustering par plage présente les avantages suivants par rapport au clustering par hachage :

• Prise en charge des requêtes par plage.

  Par exemple, si la condition de requête est c < 3, le système exclut le Compartiment 2 et le Compartiment 3 sur la base de l'index global, puis interroge les données dans le Compartiment 0 et le Compartiment 1. Avec le clustering par hachage, l'élagage des compartiments n'est possible que pour les requêtes d'égalité.

• Prise en charge des requêtes multi-clés.

  Par exemple, si vous spécifiez RANGE CLUSTERED BY (c1, c2, c3) SORTED BY (c1, c2, c3) lors de la création d'une table, le clustering par plage et le stockage des données s'effectuent dans l'ordre c1, c2 et c3. Ainsi, vous pouvez interroger les données de la table selon des conditions complexes, telles que c1 = 100 AND c2 > 0 ou c1 = 100 AND c2 = 50 AND c3 < 5. Ce type de requête ne peut pas être réalisé avec le clustering par hachage.

  Important

  Pour une requête basée sur plusieurs clés, les clés de la condition de requête doivent être triées dans l'ordre et seule la dernière clé peut être utilisée pour spécifier une plage de valeurs.

• Mise en œuvre efficace du tri global.

  Avant l'utilisation du clustering par plage, MaxCompute ne pouvait utiliser qu'une seule instance pour trier globalement les données, ce qui entraînait une faible efficacité. Avec le clustering par plage, les données de chaque plage sont triées simultanément puis combinées, ce qui améliore considérablement l'efficacité.

Utilisez l'instruction CREATE TABLE pour créer une table avec clustering par plage. Dans cette instruction, vous devez spécifier le paramètre RANGE CLUSTERED BY. Les paramètres INTO number_of_buckets BUCKETS et SORTED BY sont facultatifs. Nous vous recommandons généralement de spécifier les mêmes valeurs dans SORTED BY et RANGE CLUSTERED BY pour obtenir l'effet d'optimisation optimal.

• Syntaxe

  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]

• Exemples

  • Table non partitionnée

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

  • Table partitionnée

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

• Paramètres

  • RANGE CLUSTERED BY

    Spécifie les clés pour le clustering par plage. Après avoir spécifié ce paramètre, MaxCompute trie et échantillonne une ou plusieurs colonnes de données dans des plages appropriées en fonction du nombre de compartiments spécifié. Pour éviter les problèmes de déséquilibre des données et les points chauds, et pour améliorer les performances des requêtes parallèles, nous vous recommandons de spécifier dans RANGE CLUSTERED BY des colonnes avec de grandes plages de valeurs et peu de valeurs de clés dupliquées. Pour optimiser les performances des requêtes, nous vous conseillons de spécifier dans RANGE CLUSTERED BY les clés d'agrégation ou de filtrage couramment utilisées.

  • SORTED BY

    Spécifie comment trier les champs dans un compartiment. Pour obtenir des performances de requête optimales, nous vous recommandons de spécifier les mêmes valeurs dans SORTED BY et RANGE CLUSTERED BY. Après avoir spécifié SORTED BY, MaxCompute génère automatiquement un index global et des index de fichier, et utilise ces index pour accélérer les requêtes.

  • INTO number_of_buckets BUCKETS

    Contrairement au clustering par hachage, INTO number_of_buckets BUCKETS est facultatif pour le clustering par plage. Si vous ne spécifiez pas ce paramètre, MaxCompute détermine automatiquement le nombre de compartiments en fonction du volume de données. Nous vous recommandons généralement de spécifier le nombre de compartiments en fonction de votre situation réelle.

    Comme pour le clustering par hachage, nous vous recommandons de définir le nombre de compartiments en fonction de la taille du compartiment (512 Mo à 1 Go) pour le clustering par plage. Pour les tables extrêmement volumineuses, un grand nombre de compartiments est requis. Toutefois, nous recommandons que le nombre de compartiments dans une table ne dépasse pas 4 000.

Pour les tables partitionnées, exécutez l'instruction ALTER TABLE pour ajouter ou supprimer les propriétés de clustering par plage.

• Syntaxe

  -- 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;

• Remarques d'utilisation

  • L'instruction ALTER TABLE ne peut modifier que les propriétés de clustering d'une table partitionnée. Pour une table non partitionnée, les propriétés de clustering ne peuvent pas être modifiées après leur ajout à la table.

  • L'instruction ALTER TABLE prend effet uniquement pour les nouvelles partitions d'une table, y compris les nouvelles partitions générées à l'aide de l'instruction INSERT OVERWRITE. Les nouvelles partitions sont stockées selon les propriétés de clustering. Les formats de stockage des partitions existantes restent inchangés.

  • L'instruction ALTER TABLE prend effet uniquement pour les nouvelles partitions d'une table. Par conséquent, vous ne pouvez pas spécifier de partitions dans cette instruction.

L'instruction ALTER TABLE convient aux tables existantes. Après l'ajout des propriétés de clustering par plage, les nouvelles partitions sont stockées selon ces propriétés.

Après avoir créé une table avec clustering par plage, exécutez l'instruction suivante pour consulter les propriétés de la table. Les propriétés de clustering par plage sont affichées dans Extended Info du résultat renvoyé.

DESC EXTENDED <table_name>;

Exemple de sortie :

Owner: ALIYUNxxx                | Project: xxx
  TableComment:

+----------------------------+
| CreateTime:               2018-01-15 16:05:30  |
| LastDDLTime:              2018-01-15 16:05:30  |
| LastModifiedTime:         2018-01-15 16:05:30  |
+----------------------------+
| InternalTable: YES   | Size: 0               |
+----------------------------+
| Native Columns:                                |
+----------------------------+
| Field            | Type     | Label | Comment  |
+----------------------------+
| l_orderkey       | bigint   |       |          |
| l_partkey        | bigint   |       |          |
| l_suppkey        | bigint   |       |          |
| l_linenumber     | bigint   |       |          |
| l_quantity       | double   |       |          |
| l_extendedprice  | double   |       |          |
| l_discount       | double   |       |          |
| l_tax            | double   |       |          |
| l_returnflag     | string   |       |          |
| l_linestatus     | string   |       |          |
| l_shipdate       | string   |       |          |
| l_commitdate     | string   |       |          |
| l_receiptdate    | string   |       |          |
| l_shipinstruct   | string   |       |          |
| l_shipmode       | string   |       |          |
| l_comment        | string   |       |          |
+----------------------------+
| Extended Info:                                 |
+----------------------------+
| TableID:                   xxx                 |
| IsArchived:                false               |
| PhysicalSize:              0                   |
| FileNum:                   0                   |
| ClusterType:               range               |
| BucketNum:                 1024                |
| ClusterColumns:            [l_orderkey]        |
| SortColumns:               [l_orderkey ASC]    |
+----------------------------+

Dans la section Extended Info, ClusterType est range, BucketNum est 1024, ClusterColumns est [l_orderkey] et SortColumns est [l_orderkey ASC], ce qui confirme que la table a été configurée avec succès avec les attributs de clustering par plage.

Pour une table partitionnée, vous pouvez également exécuter l'instruction suivante pour consulter les propriétés de clustering d'une partition.

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

Dans la sortie, les quatre attributs ClusterType, BucketNum, ClusterColumns et SortColumns indiquent la configuration de clustering par plage de la partition.

odps@ tpch_100g>desc extended xndai_test_range partition(pt="20180115");

| PartitionSize: 0

| CreateTime:               2018-01-15 16:31:10
| LastDDLTime:              2018-01-15 16:31:10
| LastModifiedTime:         2018-01-15 16:31:10

| IsExstore:          false
| IsArchived:         false
| PhysicalSize:       0
| FileNum:            0
| ClusterType:        range
| BucketNum:          1024
| ClusterColumns:     [c1]
| SortColumns:        [c1 ASC]

Par exemple, pour une condition de requête simple id < 3, le système extrait la condition de l'optimiseur et la convertit en la plage de valeurs (-∞, 3). Dans ce cas, le système utilise l'index global pour l'élagage des compartiments afin d'exclure le Compartiment 2 et le Compartiment 3 dont les données ne se trouvent pas dans la plage de valeurs précédente. Ensuite, le système utilise l'index de chaque fichier dans le Compartiment 0 et le Compartiment 1 pour localiser rapidement les données. Ce processus est appelé poussée de prédicat (predicate pushdown), comme illustré dans la figure suivante. L'instruction suivante est une instruction TPC-H Query 6 utilisée pour interroger des données à partir d'un ensemble de données de 100 Go après application du clustering par plage. Dans une instruction TPC-H Query 6, une opération d'agrégation est effectuée basée sur un filtrage par plage. Le clustering par plage utilise deux niveaux d'index pour localiser rapidement les données. Ainsi, la durée d'exécution de la requête ainsi que les ressources CPU et mémoire consommées sont considérablement réduites.

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;

Dans cet exemple, l'instruction suivante convertit la table mf_tab en une table avec clustering par plage. Cela vous aide à mieux comprendre les requêtes multi-clés.

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

Après la conversion de la table en table avec clustering par plage, vous pouvez effectuer des requêtes d'agrégation au niveau du projet. Exemple d'instruction :

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

Vous pouvez également utiliser plusieurs clés pour localiser précisément une table. Exemple d'instruction :

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

Vous pouvez également utiliser plusieurs clés pour des requêtes par plage. L'instruction suivante interroge les tables dont les noms commencent par adm.

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

Toutes les requêtes précédentes tirent pleinement parti de la fonctionnalité de tri global du clustering par plage et effectuent une poussée de prédicat pour réduire le nombre d'opérations d'E/S lors de l'analyse de la table, tout en économisant les ressources CPU et mémoire consommées pour le filtrage et le calcul des données.

Par exemple, k1, k2 sont des clés de clustering dans une table nommée T.

• Si la condition de requête est k1 < 5, l'accélération des requêtes basée sur les index peut être réalisée.

• Si la condition de requête est k1 = 10 AND k2 = 20, l'accélération des requêtes basée sur les index peut être réalisée.

• Si la condition de requête est k1 = 10 AND k2 < 0, l'accélération des requêtes basée sur les index peut être réalisée.

• Si la condition de requête est k2 < 0, l'accélération des requêtes basée sur les index ne peut pas être réalisée. En effet, k1 n'est pas spécifié dans la condition de requête.

• Si la condition de requête est k1 < 0 AND k2 > 0, l'accélération basée sur les index peut être utilisée pour obtenir les données répondant à la condition k1 < 0. Pour les données répondant à la condition k2 > 0, une analyse complète de la table est requise.

Par exemple, une table nommée T est créée à l'aide de l'instruction CREATE TABLE suivante. Si vous interrogez des données à partir de la table, vous pouvez effectuer l'opération GROUP BY sur les données de la table dans une étape de map.

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;

L'instruction suivante montre la structure de données de la table foo.

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

Les données stockées dans les compartiments de la table foo se situent dans les plages suivantes :

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

Les plages de compartiments précédentes sont spécifiées au format Bucket N: [lower bound values : upper bound values]. Si les données sont agrégées par la colonne a, les plages de compartiments suivantes sont utilisées à la place :

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

Vous pouvez générer directement un plan d'exécution pour les opérations d'agrégation par la colonne a et la colonne b, démarrer trois instances pour agréger les données dans chaque compartiment, puis renvoyer le résultat de sortie.

Cependant, si les valeurs de la colonne a sont distribuées sur plusieurs compartiments, un résultat invalide est renvoyé. Exemple :

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

La colonne a possède deux valeurs, 3 et 7, qui sont stockées séparément dans deux compartiments. Pour obtenir un résultat valide, vous devez placer les tuples ayant la même valeur dans la colonne a dans la même instance et agréger les tuples. Ainsi, les compartiments sont recréés, comme illustré dans la figure suivante. L'espace entre deux lignes pointillées rouges spécifie la plage de données qui peut être lue par chaque instance. Des histogrammes sont requis pour le clustering par plage. Pour une table avec clustering par plage, si les clés de clustering et les clés de tri sont identiques, le worker correspondant à chaque compartiment échantillonne un tuple toutes les 10 000 lignes pour obtenir les valeurs des clés de clustering lors de l'insertion des données dans la table. Les valeurs obtenues sont enregistrées dans un histogramme. L'histogramme de chaque compartiment est stocké dans les fichiers de métadonnées de cluster. Ce type d'histogramme est appelé histogramme équi-profond (equi-depth histogram).

Après obtention de l'histogramme de chaque compartiment, vous pouvez recréer des compartiments pour chaque worker selon les règles suivantes :

• Les tuples ayant la même clé de regroupement sont stockés dans le même compartiment.

• Les données sont réparties uniformément entre les compartiments.

Sur la base des valeurs limites inférieures de chaque nouveau compartiment, chaque worker peut lire les données dans une plage valide et renvoyer un résultat valide.

Le contenu suivant utilise la table partsupp avec 1 To de données dans un ensemble de données TPC-H pour tester les améliorations de performance. Exécutez l'instruction suivante pour transformer la table partsupp en une table avec clustering par plage :

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;

Exécutez l'instruction de requête suivante pour effectuer le test :

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

• Exécutez la commande suivante pour désactiver l'optimisation :

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

  Ce qui suit montre le journal d'exécution de la tâche lorsque l'optimisation est désactivée.

  
  resource cost: cpu 9.17 Core * Min, memory 15.15 GB * Min
  inputs:
      yuan_tpch_range_1t.partsupp: 800000000 (3376541880 bytes)
  outputs:
  Job run time: 14.000
  Job run mode: fuxi job
  Job run engine: execution engine
  M1:
      instance count: 128
      run time: 7.000
      instance time:
          min: 2.000, max: 4.000, avg: 2.000
      input records:
          TableScan1: 800000000 (min: 5496040, max: 6780663, avg: 6251772)
      output records:
          StreamLineWrite1: 200001977 (min: 1374023, max: 1695182, avg: 1562958)
      writer dumps:
          StreamLineWrite1: (min: 0, max: 0, avg: 0)
  R2_1:
      instance count: 43
      run time: 14.000
      instance time:
          min: 3.000, max: 4.000, avg: 3.000
      input records:
          StreamLineRead1: 200001977 (min: 4647288, max: 4654888, avg: 4651214)
      output records:
          AdhocSink1: 200000000 (min: 4647242, max: 4654834, avg: 4651168)
      reader dumps:
          StreamLineRead1: (min: 0, max: 0, avg: 0)

• Exécutez la commande suivante pour activer l'optimisation :

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

  Exemple de sortie :

  
  resource cost: cpu 4.38 Core * Min, memory 4.38 GB * Min
  inputs:
      yuan_tpch_range_1t.partsupp: 800000000 (18493328320 bytes)
  outputs:
  Job run time: 6.000
  Job run mode: fuxi job
  Job run engine: execution engine
  M1:
      instance count: 128
      run time: 6.000
      instance time:
          min: 1.000, max: 3.000, avg: 2.000
      input records:
          TableScan1: 800000000 (min: 5625876, max: 6259956, avg: 6254874)
      output records:
          AdhocSink1: 200000000 (min: 1406469, max: 1564989, avg: 1563718)

Le résultat du test indique que la vitesse de requête est améliorée de 57 %, l'utilisation du CPU est diminuée de 52 % et l'utilisation de la mémoire est diminuée de 71 % après activation de l'optimisation. Les améliorations de performance varient en fonction du volume de données et des types de requête.

Par défaut, l'accélération du tri global est désactivée pour les tables avec clustering par plage. Pour activer l'accélération du tri global, exécutez la commande suivante :

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

Par rapport au clustering par hachage, le clustering par plage présente les limites suivantes :

• Les coûts de génération des données pour le clustering par plage sont plus élevés que ceux du clustering par hachage. Le clustering par hachage n'est qu'une opération simple de hachage et de tri des données. Cependant, pour le clustering par plage, l'échantillonnage des données, le tri et la combinaison d'histogrammes sont requis. La consommation globale, y compris les durées d'exécution, les coûts CPU et les coûts mémoire, est supérieure à la consommation globale du clustering par hachage. Par conséquent, si le clustering par hachage peut résoudre les problèmes, vous n'avez pas besoin d'utiliser le clustering par plage.

• Le clustering par plage n'est pas pris en charge dans DYNAMIC PARTITION ou INSERT INTO.

• Le clustering par plage est pris en charge uniquement pour les opérations de jointure suivantes : inner join, left outer join, right outer join et semi join. Le clustering par plage n'est pas pris en charge pour anti-join ou full outer join.

• Pour les tables avec clustering par plage, les clés spécifiées dans RANGE CLUSTERED BY doivent être identiques à celles spécifiées dans SORTED BY. Par exemple, si range clustered by (a,b) sorted by (a,b) est spécifié pour une table nommée foo lors de sa création, l'optimisation décrite dans cette rubrique peut être réalisée sur la table. Cependant, si range clustered by(a,b) sorted by (b,a) est spécifié pour une table nommée bar, l'optimisation décrite dans cette rubrique ne peut pas être réalisée sur la table.

• Les clés spécifiées dans JOIN ou GROUP BY doivent être les préfixes ou l'ensemble des clés spécifiées dans RANGE CLUSTERED BY. Par exemple, range clustered by(a,b,c) sorted by(a,b,c) est spécifié dans une instruction de création de table. L'optimisation décrite dans cette rubrique peut être réalisée sur la table uniquement si a, a,b ou a,b,c est spécifié comme clé dans JOIN ou GROUP BY. L'optimisation décrite dans cette rubrique ne peut pas être réalisée si b ou a,c est spécifié comme clé dans JOIN ou GROUP BY.

• Pour une table partitionnée avec clustering par plage, si vous souhaitez lire des données à partir de deux partitions ou plus de la table, l'optimisation décrite dans cette rubrique ne peut pas être réalisée. L'optimisation décrite dans cette rubrique ne peut être réalisée que sur les tables partitionnées ayant une seule partition et les tables non partitionnées.