Partager via

Saut de données pour Delta Lake

  • Article

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. Consultez Utilisation des clustering liquides pour les tableaux Delta.

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

Par défaut, Delta Lake collecte des statistiques sur les 32 premières colonnes définies dans votre schéma de table. Pour cette collection, chaque champ d’une colonne imbriquée est considéré comme une colonne individuelle. Vous pouvez modifier ce comportement en définissant l’une des propriétés de tableau suivantes :

Propriété de tablea Databricks Runtime pris en charge Description
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.

La mise à jour de cette propriété n’entraîne pas automatiquement le recalcul des 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 ultérieur, vous pouvez déclencher manuellement le recalcul des statistiques pour une table Delta en utilisant 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 collecte de statistiques, en particulier si les colonnes ne sont pas fréquemment utilisées pour filtrer les 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.

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.

Notes

  • 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 datez ZORDER BY et que vos enregistrements les plus récents sont tous plus larges (par exemple, des tableaux ou des valeurs de chaîne plus longs) que ceux du passé, vous pouvez vous attendre à ce que les durées des tâches du travail OPTIMIZE soient faussées, ainsi que les tailles de fichiers résultantes. Toutefois, il ne s’agit là que d’un problème pour la commande OPTIMIZE elle-même ; elle ne doit pas avoir d’impact négatif sur les requêtes suivantes.