Cette rubrique répond aux questions fréquentes concernant l'utilisation de Delta Lake sur Alibaba Cloud EMR.
Pourquoi Spark Streaming génère-t-il autant de petits fichiers dans Delta Lake ?
Pourquoi l'exécution de OPTIMIZE prend-elle autant de temps ?
Pourquoi des petits fichiers subsistent-ils après l'exécution de OPTIMIZE ?
Pourquoi des petits fichiers subsistent-ils après l'exécution de VACUUM ?
Pourquoi les fichiers journaux Delta subsistent-ils après l'exécution de VACUUM ?
Delta Lake prend-il en charge la planification automatique de OPTIMIZE ou VACUUM ?
Pourquoi ne puis-je pas créer une table ?
Delta Lake exige le paramètre LOCATION lors de la création d'une table. Ce paramètre spécifie le répertoire de stockage des données de la table, ce qui fait que la table résultante est une table externe dans Apache Spark.
Le comportement varie selon l'existence préalable de ce répertoire :
Le répertoire n'existe pas : Delta Lake crée une nouvelle table avec le schéma que vous avez défini.
Le répertoire existe déjà : Le schéma que vous spécifiez doit correspondre exactement à celui enregistré dans le fichier journal Delta situé dans ce répertoire. Toute divergence entraîne l'échec de la création de la table.
Vérifiez le fichier journal Delta existant dans le répertoire et alignez le schéma de votre commande CREATE TABLE pour qu'il corresponde.
Pourquoi Spark Streaming génère-t-il autant de petits fichiers dans Delta Lake ?
Spark Streaming écrit les données sous forme de séries de mini-lots, chaque mini-lot produisant un ou plusieurs fichiers. Avec de petites tailles de lot et une exécution continue, le nombre de fichiers augmente rapidement.
Choisissez une stratégie adaptée à vos exigences de latence :
| Stratégie | Quand l'utiliser | Compromis |
|---|---|---|
| Augmenter la taille des mini-lots | Une latence de quelques minutes est acceptable | Moins de fichiers, mais une latence de bout en bout légèrement plus élevée |
| Exécuter OPTIMIZE selon une planification | Une réponse en temps réel est requise | Surcharge de compactage plus fréquente ; accumulation de fichiers entre les exécutions |
Vous pouvez combiner ces deux stratégies : définissez une taille de lot plus importante pour ralentir l'accumulation de fichiers, puis exécutez OPTIMIZE périodiquement pour compacter les fichiers restants.
Pourquoi l'exécution de OPTIMIZE prend-elle autant de temps ?
Lorsque OPTIMIZE n'a pas été exécuté depuis longtemps, un grand nombre de petits fichiers s'accumulent dans Delta Lake. OPTIMIZE doit lire et réécrire tous ces fichiers, ce qui prolonge proportionnellement la durée d'exécution.
Configurez une tâche planifiée pour exécuter OPTIMIZE régulièrement. La fréquence appropriée dépend de votre charge de travail :
Meilleures performances des requêtes : exécutez OPTIMIZE plus souvent (quotidiennement ou plus fréquemment).
Coût réduit : exécutez-le moins souvent.
Une exécution quotidienne de OPTIMIZE constitue un bon point de départ, idéalement pendant les heures creuses lorsque les coûts de calcul sont plus faibles. Ajustez la fréquence en fonction des performances observées de vos requêtes et de vos coûts.
Pourquoi OPTIMIZE échoue-t-il ?
Delta Lake utilise un mécanisme de verrouillage optimiste : lorsque plusieurs transactions d'écriture sont validées simultanément, l'une d'elles échoue. OPTIMIZE étant lui-même une transaction d'écriture, il peut entrer en conflit avec des écritures concurrentes.
OPTIMIZE risque davantage d'échouer lorsqu'un travail de streaming supprime ou met à jour des données en continu, un scénario courant dans les workflows de Capture des Données Modifiées (CDC). Si le travail de streaming se contente d'ajouter des données sans suppression ni mise à jour, OPTIMIZE n'échoue pas.
Pour réduire les conflits, partitionnez la table par heure et exécutez OPTIMIZE sur chaque partition après l'écriture complète des données. Cela évite que OPTIMIZE n'entre en concurrence avec une fenêtre d'écriture active.
Pourquoi des petits fichiers subsistent-ils après l'exécution de OPTIMIZE ?
OPTIMIZE compacte les petits fichiers en fichiers plus grands, mais ne supprime pas les fichiers d'origine. Delta Lake conserve ces fichiers pour prendre en charge l'isolation des instantanés : les requêtes démarrées avant le compactage peuvent toujours lire les fichiers d'origine afin d'accéder à un instantané cohérent de la table.
Pour supprimer les fichiers compactés, exécutez VACUUM après OPTIMIZE. VACUUM supprime les fichiers qui ont été remplacés et dont la période de rétention a expiré (7 jours par défaut).
Pourquoi des petits fichiers subsistent-ils après l'exécution de VACUUM ?
VACUUM ne supprime que les fichiers remplissant deux conditions : ils ont été fusionnés par OPTIMIZE et leur période de rétention a expiré. La période de rétention par défaut est de 7 jours.
Si les fichiers sont encore dans la période de rétention ou n'ont pas encore été fusionnés, VACUUM les laisse en place. Exécutez d'abord OPTIMIZE, puis attendez que la période de rétention s'écoule avant d'exécuter VACUUM pour garantir que les fichiers soient éligibles à la suppression.
Comment supprimer les petits fichiers récemment fusionnés ?
Les fichiers récemment fusionnés se trouvent encore dans la période de rétention de 7 jours, donc VACUUM ne les supprimera pas par défaut. Cette fenêtre de rétention protège l'accès aux instantanés historiques : la suppression prématurée des fichiers peut interrompre les requêtes reposant sur la fonctionnalité de voyage dans le temps (time travel).
Le contournement de la période de rétention peut provoquer l'échec des requêtes actives si elles lisent encore les fichiers que vous supprimez. N'agissez ainsi que si vous êtes certain qu'aucune requête ni aucun travail de streaming n'accède aux instantanés historiques de cette table.
Si vous êtes certain que l'opération est sans risque, utilisez l'une des méthodes suivantes :
Désactiver la vérification de la période de rétention : Définissez la propriété de configuration Spark
spark.databricks.delta.retentionDurationCheck.enabledsurfalseet transmettez-la en tant que paramètre au démarrage de votre travail Spark. Ensuite, exécutez VACUUM avec un intervalle de rétention court.Réduire la période de rétention globale : Dans le fichier
spark-defaults.conf, définissezspark.databricks.delta.properties.defaults.deletedFileRetentionDurationsurinterval 1 hour. Cette modification s'applique globalement à toutes les tables Delta du cluster.
Pourquoi les fichiers journaux Delta subsistent-ils après l'exécution de VACUUM ?
VACUUM gère les fichiers de données, pas les fichiers journaux Delta. Delta Lake gère automatiquement le cycle de vie des fichiers journaux :
Tous les 10 commits, Delta Lake fusionne les fichiers journaux.
Après la fusion, Delta Lake identifie et supprime les fichiers journaux expirés.
La période de rétention par défaut pour les fichiers journaux Delta est de 30 jours.
Aucune intervention manuelle n'est nécessaire. Si vous constatez la présence de nombreux fichiers journaux, c'est probablement parce qu'ils se trouvent encore dans la fenêtre de rétention de 30 jours ou n'ont pas encore atteint le seuil de 10 commits.
Delta Lake prend-il en charge la planification automatique de OPTIMIZE ou VACUUM ?
Non. Delta Lake est une bibliothèque, pas un moteur d'exécution, il ne dispose donc d'aucun planificateur intégré. OPTIMIZE et VACUUM doivent être déclenchés de manière externe.
Configurez une tâche planifiée dans votre système d'orchestration de workflows, tel qu'Apache Airflow ou une tâche cron, pour exécuter ces commandes périodiquement sur vos tables Delta.