MaxCompute:Évaluer l'efficacité de l'élimination des partitions

Contexte

Dans MaxCompute, définissez un ou plusieurs champs comme colonnes de partition lors de la création d'une table partitionnée. Lors de l'interrogation des données, spécifiez un nom de partition pour lire uniquement les données de la partition correspondante. Cette approche évite une analyse complète de la table, améliore l'efficacité du traitement et réduit les coûts.

L'élimination des partitions applique des conditions de filtre aux colonnes de partition. Une requête SQL lit ainsi un sous-ensemble de partitions au lieu d'analyser toute la table, ce qui économise des ressources et améliore l'efficacité des requêtes. Toutefois, l'élimination des partitions échoue fréquemment.

Déterminer si l'élimination des partitions est efficace

Scénarios d'échec de l'élimination des partitions

• Échec causé par une fonction définie par l'utilisateur

  L'élimination des partitions peut échouer si la condition de filtre sur une colonne de partition utilise une fonction définie par l'utilisateur (UDF) ou certaines fonctions intégrées. Si vous utilisez une fonction non standard pour filtrer les valeurs de partition, utilisez la commande EXPLAIN pour afficher le plan d'exécution et confirmer l'efficacité de l'élimination des partitions.

  explain
  select ...
  from xxxxx_base2_brd_ind_cw
  where ds = concat(SPLIT_PART(bi_week_dim(' ${bdp.system.bizdate}'), ',', 1), SPLIT_PART(bi_week_dim(' ${bdp.system.bizdate}'), ',', 2))

  Remarque

  Les UDF prennent désormais en charge l'élimination des partitions. Pour plus d'informations, consultez la description dans Clause WHERE (WHERE_condition).

• Échec lors de l'utilisation de jointures

  Lorsque vous utilisez JOIN dans une instruction SQL :

  • Si les conditions de filtre de partition se trouvent dans la clause WHERE, l'élimination des partitions prend effet.

  • Si les conditions de filtre de partition se trouvent dans la clause ON, l'élimination est efficace pour la table de droite dans une LEFT JOIN, mais pas pour la table de gauche.

  Cette section décrit le comportement pour trois types de jointures :

  • LEFT OUTER JOIN

    • Toutes les conditions de filtre de partition se trouvent dans la clause ON

      set odps.sql.allow.fullscan=true;
      explain
      select a.seller_id
          ,a.pay_ord_pbt_1d_001
      from xxxxx_trd_slr_ord_1d a
      left outer join
           xxxxx_seller b
      on a.seller_id=b.user_id
      and a.ds='20150801'
      and b.ds='20150801';

      Après avoir exécuté l'instruction explain précédente, le plan d'exécution renvoyé est le suivant. Le plan indique que la source de données de la table de gauche analyse les 1 770 partitions et que la condition de filtre est transmise à l'opérateur FIL :

      In Task M2_Stg1:
        Data source: xxx ller/ds=20101001, xxx seller/ds=20101002, xxx seller/ds=20101003...(total 1770)
        xxx
            RS: order: +
                optimizeOrderBy: False
              valueDestLimit: 0
              keys:
                   b.user_id
              values:
                   b.ds
              partitions
                b.user_id
      In Task J3_1_2_Stg1:
          JOIN: a LEFT OUTER JOIN b
            filter:
                0:
                1:
            FIL: And(EQUAL(a. col96, '20150801'), EQUAL(b. col209, '20150801'))
          SEL: xxx
            FS: output: None

      La sortie précédente montre qu'une analyse complète de la table est effectuée sur la table de gauche, tandis que l'élimination des partitions est efficace pour la table de droite.

    • Toutes les conditions de filtre de partition se trouvent dans la clause WHERE

      set odps.sql.allow.fullscan=true;
      explain
      select a.seller_id
          ,a.pay_ord_pbt_1d_001
      from xxxxx_trd_slr_ord_1d a
      left outer join
          xxxxx_seller b
      on a.seller_id=b.user_id
      where a.ds='20150801'
      and b.ds='20150801';

      Task M2_Stg1:
        Data source: xxx/ds=seller/ds=20150801
        TS: alias: b
            FIL: EQUAL(b.ds, '20150801')
                RS: order: +
                    optimizeOrderBy: False
                    valueDestLimit: 0
                    keys:
                        b.user_id
                    values:
                    partitions:
                        b.user_id
      In Task J3_1_2_Stg1:
        JOIN: a LEFT OUTER JOIN unknown
            filter:
                0:
                1:
            SEL: a._col0, a._col20
            FS: output: None
      In Task M1_Stg1:
        Data source: xxx/ds= trd slr ord 1d/ds=20150801
        TS: alias: a

      Le plan d'exécution indique que l'élimination des partitions est efficace pour les deux tables.

  • RIGHT OUTER JOIN

    Comme pour une LEFT OUTER JOIN, si les conditions de filtre de partition se trouvent dans la clause ON d'une RIGHT OUTER JOIN, l'élimination des partitions n'est efficace que pour la table de gauche. Si les conditions se trouvent dans la clause WHERE, l'élimination des partitions est efficace pour les deux tables.

  • FULL OUTER JOIN

    Pour une FULL OUTER JOIN, les conditions de filtre de partition ne sont efficaces que si elles se trouvent dans la clause WHERE. Si elles se trouvent dans la clause ON, l'élimination des partitions n'est efficace pour aucune des deux tables.

Précautions

• Les échecs d'élimination des partitions peuvent avoir un impact significatif et sont souvent difficiles à détecter. Vérifiez donc ces échecs avant de valider votre code.

• Pour utiliser l'élimination des partitions avec une fonction définie par l'utilisateur, modifiez la classe ou ajoutez set odps.sql.udf.ppr.deterministic = true; avant votre instruction SQL. Pour plus d'informations, consultez Clause WHERE (WHERE_condition).