Optimiseur basé sur les coûts

Spark SQL peut utiliser un optimiseur basé sur les coûts (CBO) pour améliorer les plans de requête. Cela s’avère particulièrement utile pour les requêtes avec plusieurs jointures. Pour que cela fonctionne, il est essentiel de collecter des statistiques de tables et de colonnes et de les tenir à jour.

Collecter des statistiques

Pour tirer pleinement parti de l’optimiseur basé sur les coûts (CBO), il est important de collecter les statistiques de colonnes et les statistiques de tables. Vous pouvez utiliser la ANALYZE TABLE commande pour collecter manuellement des statistiques.

Conseil

Pour maintenir les statistiques à jour, exécutez ANALYZE TABLE après avoir écrit dans le tableau.

Utilisez ANALYZE.

L’optimisation prédictive s’exécute ANALYZEautomatiquement, une commande permettant de collecter des statistiques sur des tables gérées par le catalogue Unity. Databricks recommande d’activer l’optimisation prédictive pour toutes les tables managées par Unity Catalog afin de simplifier la maintenance des données et de réduire les coûts de stockage. Consultez ANALYZE TABLE.

Vérifier les plans de requête

Il existe plusieurs façons de vérifier le plan de requête.

EXPLAIN commande

Pour vérifier si le plan utilise des statistiques, utilisez la commande EXPLAINSQL.

Si des statistiques sont manquantes, il se peut que le plan de requête ne soit pas optimal.

== Optimized Logical Plan ==
Aggregate [s_store_sk], [s_store_sk, count(1) AS count(1)L], Statistics(sizeInBytes=20.0 B, rowCount=1, hints=none)
+- Project [s_store_sk], Statistics(sizeInBytes=18.5 MB, rowCount=1.62E+6, hints=none)
   +- Join Inner, (d_date_sk = ss_sold_date_sk), Statistics(sizeInBytes=30.8 MB, rowCount=1.62E+6, hints=none)
      :- Project [ss_sold_date_sk, s_store_sk], Statistics(sizeInBytes=39.1 GB, rowCount=2.63E+9, hints=none)
      :  +- Join Inner, (s_store_sk = ss_store_sk), Statistics(sizeInBytes=48.9 GB, rowCount=2.63E+9, hints=none)
      :     :- Project [ss_store_sk, ss_sold_date_sk], Statistics(sizeInBytes=39.1 GB, rowCount=2.63E+9, hints=none)
      :     :  +- Filter (isnotnull(ss_store_sk) && isnotnull(ss_sold_date_sk)), Statistics(sizeInBytes=39.1 GB, rowCount=2.63E+9, hints=none)
      :     :     +- Relation[ss_store_sk,ss_sold_date_sk] parquet, Statistics(sizeInBytes=134.6 GB, rowCount=2.88E+9, hints=none)
      :     +- Project [s_store_sk], Statistics(sizeInBytes=11.7 KB, rowCount=1.00E+3, hints=none)
      :        +- Filter isnotnull(s_store_sk), Statistics(sizeInBytes=11.7 KB, rowCount=1.00E+3, hints=none)
      :           +- Relation[s_store_sk] parquet, Statistics(sizeInBytes=88.0 KB, rowCount=1.00E+3, hints=none)
      +- Project [d_date_sk], Statistics(sizeInBytes=12.0 B, rowCount=1, hints=none)
         +- Filter ((((isnotnull(d_year) && isnotnull(d_date)) && (d_year = 2000)) && (d_date = 2000-12-31)) && isnotnull(d_date_sk)), Statistics(sizeInBytes=38.0 B, rowCount=1, hints=none)
            +- Relation[d_date_sk,d_date,d_year] parquet, Statistics(sizeInBytes=1786.7 KB, rowCount=7.30E+4, hints=none)

Important

La statistique rowCount est particulièrement importante pour les requêtes avec plusieurs jointures. Si rowCount est manquant, cela signifie qu’il n’y a pas assez d’informations pour le calculer (autrement dit, certaines colonnes requises n’ont pas de statistiques).

Dans Databricks Runtime 16.0 et versions ultérieures, la sortie de la EXPLAIN commande répertorie les tables référencées manquantes, partielles et complètes, comme dans l’exemple de sortie suivant :

== Optimizer Statistics (table names per statistics state) ==
  missing = date_dim, store
  partial =
  full    = store_sales
Corrective actions: consider running the following command on all tables with missing or partial statistics
  ANALYZE TABLE <table-name> COMPUTE STATISTICS FOR ALL COLUMNS

Interface utilisateur de Spark SQL

Utilisez la page de l’interface utilisateur de Spark SQL pour afficher le plan exécuté et la précision des statistiques.

Une ligne telle rows output: 2,451,005 est: N/A signifie que cet opérateur produit environ 2 millions de lignes et qu’il n’y avait pas de statistiques disponibles.

Une ligne telle que rows output: 2,451,005 est: 1616404 (1X) signifie que cet opérateur produit environ 2 millions de lignes, tandis que l’estimation était d’environ 1,6 million. Le facteur d’erreur d’estimation était donc de 1.

Une ligne telle que rows output: 2,451,005 est: 2626656323 signifie que cet opérateur produit environ 2 millions de lignes, tandis que l’estimation était d’environ 2 milliards. Le facteur d’erreur d’estimation était donc de 1 000.

Désactiver l’optimiseur basé sur les coûts

L’optimiseur basé sur les coûts est activé par défaut. Vous désactivez l’optimiseur basé sur les coûts en modifiant l’indicateur spark.sql.cbo.enabled.

spark.conf.set("spark.sql.cbo.enabled", false)