Limitations de Delta Lake sur S3
Delta Lake sur Databricks présente des limitations spécifiques lors du stockage de tables dans Amazon S3, notamment les contraintes de versioning de compartiment, les restrictions d'écriture multi-clusters et les risques liés à la suppression directe de fichiers.
Gestion de versions de bucket et Delta Lake
Databricks vous recommande de ne pas activer la gestion des versions de compartiments pour les compartiments qui stockent des données Delta Lake, y compris les tables gérées par Unity Catalog. Delta Lake implémente sa propre gestion des versions et son propre nettoyage de la mémoire.
Lorsque vous activez le versioning de compartiment, S3 conserve des copies des métadonnées et des fichiers de données que les processus manuels et automatisés sur Databricks considèrent comme supprimés. Ceci inclut les fichiers de données que VACUUM supprimerait définitivement et les Logs de transaction nettoyés automatiquement pendant les Opérations de table Delta Lake régulières.
Si vous choisissez d'utiliser le versionnement de buckets, Databricks recommande de conserver trois versions et de mettre en œuvre une politique de gestion du cycle de vie qui conserve les versions pendant 7 jours ou moins pour tous les buckets S3 avec le versionnement activé.
Si vous rencontrez un ralentissement des performances sur les tables stockées dans des compartiments avec versioning activé, mentionnez que le versioning des compartiments est activé lorsque vous contactez le support Databricks.
Limitations d'écriture multi-clusters
Pour éviter les problèmes potentiels de corruption et de perte de données, Databricks vous recommande de ne pas modifier la même table Delta Lake stockée dans S3 à partir de différents Workspace.
Le modèle *éventuellement cohérent* utilisé dans Amazon S3 peut entraîner des problèmes potentiels lorsque plusieurs systèmes ou clusters modifient simultanément les données de la même table.
Databricks et Delta Lake prennent en charge les écritures multi-clusters par default, ce qui signifie que les query écrivant dans une table à partir de plusieurs clusters simultanément n'endommageront pas la table. Pour les tables Delta Lake stockées sur S3, cette garantie est limitée à un seul workspace Databricks.
Les fonctionnalités suivantes ne sont pas prises en charge lors de l’exécution dans ce mode :
- Chiffrement côté serveur avec des clés de chiffrement fournies par les clients
- Chemins S3 avec des identifiants dans un cluster qui ne peuvent pas accéder au service de jetons de sécurité AWS
Vous pouvez désactiver les écritures multi-clusters en définissant spark.databricks.delta.multiClusterWrites.enabled sur false. Si elles sont désactivées, les écritures dans une seule table doivent provenir d’un seul cluster.
La désactivation de spark.databricks.delta.multiClusterWrites.enabled et la modification simultanée de la même table Delta Lake à partir de plusieurs clusters peut entraîner une perte de données ou une corruption des données.
Pour plus d'informations sur les écritures multiclusters dans Databricks, consultez Configurer les paramètres liés au service de commit S3 de Databricks.
Données obsolètes après la suppression de fichiers avec rm -rf
N'utilisez pas rm -rf pour supprimer une table Delta Lake. Voir Supprimer ou remplacer une table.