Saut de données
Dans Databricks Runtime 13.3 et versions supérieures, Databricks recommande l'utilisation du clustering liquide pour la Layout de table. Le clustering n'est pas compatible avec le Z-ordering. Consultez Utiliser le clustering liquide pour les tables.
Les statistiques de saut de données sont collectées automatiquement lorsque vous écrivez des données dans une table Delta Lake ou Apache Iceberg gérée. Databricks utilise des statistiques par fichier (valeurs minimales et maximales, nombre de valeurs nulles et nombre total d'enregistrements) au moment de la requête pour ignorer les fichiers non pertinents et accélérer les requêtes.
Vous devez avoir des statistiques collectées pour les colonnes utilisées dans les instructions ZORDER. Consultez Qu’est-ce que le Z-ordering ?.
Spécifier les colonnes de statistiques
Pour les tables externes de Unity Catalog, les statistiques sont collectées par default sur les 32 premières colonnes définies dans le schéma de votre table. Pour les tables gérées de Unity Catalog, les statistiques d'ignorer les fichiers sont choisies intelligemment en utilisant l'optimisation prédictive, et n'ont pas de limite de 32 colonnes. L'optimisation prédictive exécute automatiquement ANALYZE, une commande de collecte de statistiques. Databricks recommande d'activer l'optimisation prédictive pour toutes les tables gérées par Unity Catalog afin de simplifier la maintenance des données et de réduire les coûts de stockage. Consultez l'optimisation prédictive pour les tables gérées par Unity Catalog.
Si vous n’utilisez pas l’optimisation prédictive, vous pouvez modifier le comportement qui limite les collections de statistiques à 32 colonnes en définissant l’une des propriétés de table suivantes :
Propriété de table | Databricks Runtime pris en charge | Description |
|---|---|---|
| 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. |
| Databricks Runtime 13.3 LTS ou version ultérieure | Spécifiez une liste de noms de colonnes pour lesquelles les statistiques sont collectées. Remplace |
Les propriétés de table peuvent être définies lors de la création de la table ou avec des déclarations ALTER TABLE. Consultez la référence des propriétés de table. L'exemple suivant annule le comportement de collecte de statistiques par default pour définir la collecte de statistiques sur les colonnes nommées :
- Delta Lake table
- Iceberg table
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')
ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')
La mise à jour de ces propriétés ne recalcule pas automatiquement les statistiques pour les données existantes. Il influe plutôt sur le comportement de la collecte future de statistiques lors de l'ajout ou de la mise à jour de 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 les colonnes spécifiées pour les statistiques, vous pouvez manuellement Trigger le recalcul des statistiques d'une table à l'aide de la commande suivante :
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
Les longues chaînes sont tronquées lors de la collecte des statistiques. Vous pouvez choisir d'exclure les colonnes de chaîne longues de la collecte de statistiques, surtout si les colonnes ne sont pas fréquemment utilisées pour filtrer les query.
Qu'est-ce que le Z-ordering ?
Databricks recommande d'utiliser le clustering liquide pour toutes les nouvelles tables. Vous ne pouvez pas utiliser ZORDER en combinaison avec le clustering liquide. Voir Utiliser le clustering liquide pour les tables.
Z-ordering est une technique pour colocaliser les informations connexes dans le même ensemble de fichiers. Les algorithmes de saut de données Databricks utilisent automatiquement cette colocalisation. Ce comportement réduit la quantité de données qui doivent être lues. Pour Z-order les données, spécifiez les colonnes à classer dans la clause ZORDER BY :
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
Si vous vous attendez à ce qu'une colonne soit couramment utilisée dans les prédicats de query et si cette colonne a une cardinalité élevée (c'est-à-dire, un grand nombre de valeurs distinctes), alors utilisez ZORDER BY.
Vous pouvez spécifier plusieurs colonnes pour ZORDER BY sous forme de liste séparée par des virgules. Cependant, l'efficacité diminue avec chaque colonne supplémentaire.
Databricks vous recommande de ne pas utiliser ZORDER BY sur les colonnes pour lesquelles les statistiques ne sont pas collectées, car cela est inefficace et utilise des ressources de compute inutiles. L'omission de données nécessite des statistiques locales par colonne telles que min, max et count. Vous pouvez configurer la collecte de statistiques sur certaines colonnes en réorganisant les colonnes dans le schéma, ou vous pouvez augmenter le nombre de colonnes sur lesquelles collecter des statistiques.
-
Le Z-ordering est non idempotent mais vise à être une opération incrémentielle. Le temps nécessaire au Z-ordering n'est pas garanti de diminuer sur plusieurs exécutions. Cependant, si aucune nouvelle donnée n'a été ajoutée à une partition qui venait d'être Z-ordered, une autre Z-ordering de cette partition n'a aucun effet.
-
Z-ordering vise à produire des fichiers de données équilibrés en ce qui concerne le nombre de tuples, mais pas nécessairement la taille des données dans le stockage. Bien que les tailles de fichier et le nombre de tuples soient corrélés, il peut y avoir des situations où ils ne le sont pas, ce qui affecte l'optimisation des temps de tâche.
Par exemple, si vous
ZORDER BYla date et que vos enregistrements les plus récents sont tous beaucoup plus larges (tels que des tableaux ou des valeurs de chaîne plus longs) que ceux du passé,OPTIMIZEles durées de tâche et les tailles de fichier résultantes de votre Job pourraient être faussées. Ceci n'est, cependant, un problème uniquement pour la commandeOPTIMIZEelle-même ; cela n'a probablement aucun effet négatif sur les queries suivantes.