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.
Remarque
Dans Databricks Runtime 13.3 et versions ultérieures, Databricks recommande d’utiliser le clustering liquide pour la disposition du tableau Delta. Le clustering n’est pas compatible avec la commande Z. Voir Utilisation du clustering liquide pour les tables.
Les informations ignorées par les données sont collectées automatiquement lorsque vous écrivez des données dans une table Delta. Delta Lake sur Azure Databricks tire parti de ces informations (valeurs minimales et maximales, nombre de valeurs null et nombre total d’enregistrements par fichier) au moment de la requête pour fournir des requêtes plus rapides.
Vous devez collecter des statistiques pour les colonnes utilisées dans les instructions ZORDER. Consultez Qu’est-ce que l’ordre de plan ?.
Spécifier des colonnes de statistiques Delta
Pour les tables externes du catalogue Unity, Delta Lake collecte les statistiques sur les 32 premières colonnes définies dans votre schéma de table par défaut. Pour les tables gérées par le catalogue Unity, Delta Lake choisit les statistiques d’ignorer les fichiers intelligemment à l’aide de l’optimisation prédictive et n’a pas de limite 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é de tablea | Databricks Runtime pris en charge | Descriptif |
|---|---|---|
delta.dataSkippingNumIndexedCols |
Toutes les versions de Databricks Runtime prises en charge | Augmentez ou diminuez le nombre de colonnes sur lesquelles Delta collecte des statistiques. Dépend de l’ordre des colonnes. |
delta.dataSkippingStatsColumns |
Dans Databricks Runtime 13.3 LTS et versions ultérieures | Spécifiez la liste des noms de colonnes pour lesquels Delta Lake collecte des statistiques. 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 Référence sur les propriétés de table Delta. 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 :
ALTER TABLE table_name SET TBLPROPERTIES('delta.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. Delta Lake ne tire pas profit des statistiques pour les colonnes qui ne sont pas 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 Delta à l’aide de la commande suivante :
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
Remarque
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 de plan ?
Remarque
Databricks recommande l’utilisation du clustering liquide pour toutes les nouvelles tables Delta. Vous ne pouvez pas utiliser ZORDER en combinaison avec le clustering liquide. Voir Utilisation du clustering liquide pour les tables.
L’ordre de plan est une technique qui permet d’héberger les informations associées dans le même ensemble de fichiers. Cette colocalisation est automatiquement utilisée par Delta Lake sur les algorithmes Azure Databricks servant à ignorer des données. Ce comportement réduit considérablement la quantité de données devant être lues par Delta Lake sur Azure Databricks. Pour trier les données dans l’ordre de plan, vous spécifiez les colonnes à 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é de la localité chute avec chaque colonne supplémentaire. L’ordre de plan sur les colonnes qui n’ont pas de statistiques collectées est inefficace et constitue un gaspillage de ressources. En effet, le fait d’ignorer des données nécessite des statistiques locales de colonne telles que min, max et count. Vous pouvez configurer la collecte des statistiques sur certaines colonnes en recommandant les colonnes du schéma ou vous pouvez accroître le nombre de colonnes sur lesquelles les statistiques doivent être collectées.
Remarque
L’ordre de plan n’est pas idempotent, mais il vise à être une opération incrémentielle. Le temps nécessaire pour l’ordre de plan n’est pas garanti pour une réduction sur plusieurs exécutions. Toutefois, si aucune nouvelle donnée n’a été ajoutée à une partition uniquement triée en ordre de plan, un autre ordre de plan de cette partition n’aura aucun effet.
L’ordre de plan a pour but de produire des fichiers de données uniformément équilibrés en ce qui concerne le nombre de tuples, mais pas nécessairement la taille des données sur le disque. Les deux mesures sont le plus souvent corrélées, mais il peut y avoir des situations où cela n’est pas le cas, ce qui se traduit par un décalage dans l’optimisation des temps de tâche.
Par exemple, si vous
ZORDER BYdatez et que vos enregistrements les plus récents sont tous beaucoup plus larges (par exemple, des tableaux ou des valeurs de chaîne plus longs) que ceux du passé, il est prévu que lesOPTIMIZEdurées des tâches du travail soient asymétriques, ainsi que les tailles de fichier résultantes. Toutefois, il ne s’agit là que d’un problème pour la commandeOPTIMIZEelle-même ; elle ne doit pas avoir d’impact négatif sur les requêtes suivantes.