Migrer un lac de données Parquet vers Delta Lake
Cet article fournit des recommandations pour la conversion d’un lac de données Parquet existant vers Delta Lake. Delta Lake est le format sous-jacent de Databricks Lakehouse. Consultez Présentation de Delta Lake.
Considérations relatives à la conversion vers Delta Lake
Votre lac de données Parquet a probablement une stratégie de partitionnement optimisée pour vos charges de travail et vos systèmes existants. Bien que vous puissiez effectuer une conversion vers Delta Lake et conserver cette structure de partitionnement, les tables surpartitionnées sont l’une des principales cause de la lenteur des charges de travail sur Delta Lake. Consultez Quand partitionner des tables sur Azure Databricks et Recommandations relatives à l’adaptation du code Spark à Databricks.
Vous devez également déterminer si les données converties continuent d’augmenter ou non ainsi que la fréquence d’interrogation des données. Vous pouvez choisir différentes approches pour les différentes tables Parquet de votre lac de données.
Approches liées à la conversion vers Delta Lake
La matrice suivante décrit les quatre approches principales pour la conversion d’un lac de données Parquet vers Delta Lake ainsi que certains compromis. Pour clarifier chaque colonne :
- Incrémentielle : désigne la fonctionnalité qui prend en charge la conversion de données supplémentaires ajoutées à la source de conversion, une fois la conversion commencée.
- Duplique les données : indique si les données sont écrites à un nouvel emplacement ou si elles sont modifiées sur place.
- Conserve la structure de données : indique si la stratégie de partitionnement est conservée durant la conversion.
- Renvoi des données : indique la fonctionnalité qui prend en charge le renvoi des données ajoutées à la source de conversion, une fois la conversion commencée.
- Facilité d’utilisation : indique le niveau d’effort de l’utilisateur pour configurer et exécuter la conversion de données.
| Méthode | Incrémentiel | Duplique les données | Conserve la structure de données | Renvoi des données | Simplicité d'utilisation |
|---|---|---|---|---|---|
Opération CLONE Parquet en profondeur |
Oui | Oui | Oui | Oui | Facile |
Opération CLONE Parquet superficielle |
Oui | Non | Oui | Oui | Facile |
CONVERT TO DELTA |
Non | Non | Oui | Non | Facile |
| Chargeur automatique | Oui | Oui | Non | Facultatif | Un peu de configuration |
| Travail par lots Spark | Logique personnalisée | Oui | Non | Logique personnalisée | Logique personnalisée |
Les sections suivantes décrivent chacune de ces options plus en détail.
Migrer des données Parquet avec CLONE Parquet
Vous pouvez utiliser CLONE Parquet pour copier de manière incrémentielle les données d’un lac de données Parquet vers Delta Lake. Les clones superficiels créent des pointeurs vers des fichiers Parquet existants, ce qui permet de conserver votre table Parquet à son emplacement et dans son format d’origine tout en fournissant un accès optimisé via les statistiques de fichiers collectées. Vous pouvez écrire dans la table créée par un clone superficiel sans impacter la source de données d’origine.
Le clonage en profondeur copie tous les fichiers de données de la source vers un nouvel emplacement durant la conversion vers Delta Lake. Le clonage en profondeur vous permet de détecter de manière incrémentielle les nouveaux fichiers ainsi que les opérations de renvoi, au cours de l’exécution suivante de la logique. Consultez cloner de manière incrémentielle les tableaux Parquet et Iceberg vers Delta Lake.
L’exemple suivant montre comment utiliser CLONE :
CREATE OR REPLACE TABLE <target-table-name> [SHALLOW] CLONE parquet.`/path/to/data`;
Migrer les données Parquet avec CONVERT TO DELTA
Vous pouvez utiliser CONVERT TO DELTA pour transformer un répertoire de fichiers Parquet en table Delta à l’aide d’une seule commande. Une fois que vous avez converti une table au format Delta Lake, vous devez arrêter les opérations de lecture et d’écriture dans la table à l’aide de la logique Parquet. Les données écrites dans le répertoire cible après le démarrage de la conversion risquent de ne pas être reflétées dans la table Delta résultante. Consultez Convertir en Delta Lake.
L’exemple suivant montre l’utilisation de CONVERT TO DELTA :
CONVERT TO DELTA parquet.`abfss://container@storageAccount.dfs.core.windows.net/parquet-data`;
Migrer des données Parquet avec Auto Loader
Bien qu’Auto Loader soit un produit conçu pour l’ingestion des données de manière incrémentielle à partir du stockage d’objets cloud, vous pouvez l’utiliser pour implémenter un modèle qui copie de façon incrémentielle toutes les données d’un répertoire spécifique vers une table cible. Consultez Qu’est-ce que Auto Loader ?.
L’exemple de code suivant inclut des configurations qui :
- Traitent tous les fichiers existants dans le répertoire source.
- Déclenchent un travail de renvoi hebdomadaire automatique pour capturer les fichiers qui ont pu être manqués.
- Autorisent Apache Spark à utiliser de nombreux travaux Spark pour éviter les erreurs de dépassement et de mémoire insuffisante associées aux partitions de données volumineuses.
- Fournissent des garanties de traitement de bout en bout en une seule fois.
(spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "parquet")
.option("cloudFiles.includeExistingFiles", "true")
.option("cloudFiles.backfillInterval", "1 week")
.option("cloudFiles.schemaLocation", checkpoint_path)
.load(file_path)
.writeStream
.option("checkpointLocation", checkpoint_path)
.trigger(availableNow=True)
.toTable(table_name)
)
Vous pouvez utiliser Auto Loader dans Delta Live Tables en Python ou SQL :
Charger des données à l’aide de tables de streaming (notebook Python/SQL)
Charger des données à l’aide de tables de streaming dans Databricks SQL
Migrer des données Parquet avec une logique de traitement par lots Apache Spark personnalisée
L’écriture d’une logique Apache Spark personnalisée offre une grande souplesse pour contrôler la façon et le moment où les différentes données de votre système source sont migrées. Toutefois, elle peut nécessiter une configuration étendue pour fournir des fonctionnalités intégrées à d’autres approches.
Au cœur de cette approche se trouve une simple opération de lecture et d’écriture sur Apache Spark, dont voici un exemple :
spark.read.format("parquet").load(file_path).write.mode("append").saveAsTable(table_name)
Pour effectuer des renvois ou une migration incrémentielle, vous devrez peut-être vous appuyer sur la structure de partitionnement de votre source de données. Vous devrez peut-être également écrire une logique personnalisée pour effectuer le suivi des fichiers ajoutés depuis le dernier chargement des données à partir de la source. Bien que vous puissiez utiliser les fonctionnalités de fusion de Delta Lake pour éviter d’écrire des enregistrements en double, la comparaison de tous les enregistrements d’une grande table source Parquet au contenu d’une grande table Delta est une tâche coûteuse en calcul.
Quand devez-vous éviter d’effectuer une conversion vers Delta Lake ?
Avant de convertir toutes vos données Parquet existantes au format Delta Lake, vous devrez probablement prendre en compte des compromis potentiels.
Azure Databricks conçoit de nombreuses fonctionnalités optimisées du lakehouse autour de Delta Lake. De plus, Delta Lake fournit un riche écosystème open source avec des connecteurs natifs pour de nombreux langages et systèmes de données d’entreprise. Delta Sharing étend le partage des données stockées via Delta Lake avec d’autres clients.
Dans la mesure où Delta Lake repose sur Parquet, Azure Databricks dispose également d’outils de lecture et d’écriture optimisés pour interagir avec les fichiers Parquet.
Databricks recommande d’utiliser Delta Lake pour toutes les tables qui reçoivent régulièrement des mises à jour ou des requêtes en provenance d’Azure Databricks. Vous pouvez choisir de conserver les données au format Parquet dans certains cas, par exemple :
- Un système en amont qui écrit des données dans Parquet ne prend pas en charge l’écriture native dans Delta Lake.
- Un système en aval qui lit les données Parquet ne peut pas lire Delta Lake.
Dans les deux cas, vous pouvez être amené à répliquer vos tables sur Delta Lake afin de tirer parti des performances pour la lecture, l’écriture, la mise à jour et la suppression des enregistrements de la table.