Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Note
Dans Databricks Runtime 13.3 et versions ultérieures, Databricks recommande d’utiliser le clustering liquide pour la disposition des tables. Le clustering n’est pas compatible avec le Z-ordering. Consultez Utilisation de Liquid Clustering pour les tables.
Les statistiques de saut de données sont collectées automatiquement lors de l’écriture de données dans une table Delta Lake ou Apache Iceberg gérée. Azure Databricks utilise des statistiques par fichier (valeurs minimales et maximales, nombres null et enregistrements totaux) au moment de la requête pour ignorer les fichiers non pertinents et accélérer les requêtes.
Vous devez collecter des statistiques pour les colonnes utilisées dans les instructions ZORDER. Voir Qu’est-ce que l’ordre Z ?.
Spécifier des colonnes de statistiques
Pour les tables externes du catalogue Unity, les statistiques sont collectées sur les 32 premières colonnes définies dans votre schéma de table par défaut. Pour les tables gérées du catalogue Unity, les statistiques de saut de fichiers sont choisies intelligemment grâce à l’optimisation prédictive et ne sont pas limitées au niveau de 32 colonnes. L’optimisation prédictive s’exécute ANALYZEautomatiquement, une commande pour collecter des statistiques. 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 Optimisation prédictive pour les tables managées Unity Catalog.
Si vous n’utilisez pas d’optimisation prédictive, vous pouvez modifier le comportement qui limite les regroupements de statistiques à 32 colonnes en définissant l’une des propriétés de tableau suivantes :
| Propriété du tableau | Databricks Runtime pris en charge | Description |
|---|---|---|
dataSkippingNumIndexedCols |
Toutes les versions de Databricks Runtime prises en charge | Augmentez ou diminuez le nombre de colonnes sur lesquelles les statistiques sont collectées. Dépend de l’ordre des colonnes. |
dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS et versions ultérieures | Spécifiez la liste des noms de colonnes pour lesquels les statistiques sont collectées. Remplace dataSkippingNumIndexedCols. |
Vous pouvez définir des propriétés de table au moment de la création d’une table ou à l’aide d’instructions ALTER TABLE. Consultez les informations de référence sur les propriétés de la table. L’exemple suivant remplace le comportement de collecte de statistiques par défaut pour définir la collection de statistiques sur les colonnes nommées :
Delta Lake
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')
Table Iceberg
ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')
La mise à jour de ces propriétés ne récompute pas automatiquement les statistiques pour les données existantes. En revanche, cela a un impact sur le comportement des futures collectes de statistiques lorsque vous ajoutez ou mettez à jour des données dans la table. Les statistiques ne sont pas utilisées pour les colonnes non incluses dans la liste actuelle des colonnes de statistiques.
Dans Databricks Runtime 14.3 LTS et versions ultérieures, si vous avez modifié les propriétés de la table ou modifié les colonnes spécifiées pour les statistiques, vous pouvez déclencher manuellement la recomputation des statistiques pour une table à l’aide de la commande suivante :
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
Note
Les chaînes longues sont tronquées pendant la collecte de statistiques. Vous pouvez choisir d’exclure les colonnes de chaînes longues de la collection de statistiques, en particulier si les colonnes ne sont pas utilisées fréquemment pour le filtrage des requêtes.
Qu’est-ce que l’ordre Z ?
Note
Databricks recommande d’utiliser le clustering liquide pour toutes les nouvelles tables. Vous ne pouvez pas utiliser ZORDER en combinaison avec le clustering liquide. Consultez Utilisation de Liquid Clustering pour les tables.
Le Z-ordering est une technique qui permet de colocaliser des informations liées dans le même ensemble de fichiers. Les algorithmes d'évitement de données d'Azure Databricks utilisent automatiquement cette colocalisation. Ce comportement réduit la quantité de données qui doivent être lues. Pour ordonner les données selon l’ordre Z, spécifiez les colonnes sur lesquelles trier dans la clause ZORDER BY :
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
Si vous pensez qu’une colonne est couramment utilisée dans les prédicats de requête et si cette colonne a une cardinalité élevée (autrement dit, un grand nombre de valeurs distinctes), utilisez ZORDER BY .
Vous pouvez spécifier plusieurs colonnes pour ZORDER BY sous la forme d’une liste séparée par des virgules. Toutefois, l’efficacité diminue avec chaque colonne supplémentaire.
Databricks recommande de ne pas utiliser ZORDER BY les colonnes qui n’ont pas de statistiques collectées, car elles sont inefficaces et utilisent des ressources de calcul inutiles. Le saut de données nécessite des statistiques locales à chaque colonne, telles que le minimum, le maximum et le nombre. Vous pouvez configurer la collecte de statistiques sur certaines colonnes en réorganisant l’ordre des colonnes dans le schéma, ou vous pouvez augmenter le nombre de colonnes pour lesquelles des statistiques sont collectées.
Note
L’ordre Z n’est pas idempotent, mais se veut une opération incrémentielle. Le temps nécessaire à l’ordonnancement Z n’est pas garanti de diminuer au fil de plusieurs exécutions. Toutefois, si aucune nouvelle donnée n’a été ajoutée à une partition qui n’était qu’ordonnée par Z, une autre commande Z de cette partition n’a aucun effet.
L’ordre Z vise à produire des fichiers de données équilibrés uniformément par rapport au nombre de tuples, mais pas nécessairement à la taille des données dans le stockage. Bien que la taille des fichiers et le nombre de tuples soient corrélés, il peut arriver que, dans certains cas, ce ne soit pas le cas, ce qui fausse la durée des tâches d’optimisation.
Par exemple, si vous
ZORDER BYdate et que vos enregistrements les plus récents sont tous beaucoup plus volumineux (par exemple, des tableaux plus longs ou des valeurs de chaîne plus longues) que les anciens, les durées des tâches duOPTIMIZEjob et les tailles de fichiers qui en résultent peuvent être faussées. Toutefois, il s’agit uniquement d’un problème pour laOPTIMIZEcommande elle-même ; il n’a probablement pas d’effets négatifs sur les requêtes suivantes.