Combiner Delta Lake avec MinIO pour les lacs de données multi-cloud

Delta Lake est une infrastructure de stockage open source utilisée pour créer des lacs de données au-dessus du stockage d'objets dans une architecture Lakehouse. Delta Lake prend en charge les transactions ACID, la gestion évolutive des métadonnées et le traitement unifié des données en continu et par lots. Delta Lake est couramment utilisé pour assurer la fiabilité, la cohérence et l'évolutivité des applications Apache Spark. Delta Lake s'exécute au-dessus du stockage de lac de données existant, tel que MinIO, et est compatible avec les API Apache Spark.

L'article original de Delta Lake ( Delta Lake : Stockage de table ACID haute performance sur les magasins d'objets cloud ) décrit comment il a été conçu pour le stockage d'objets cloud. Lorsque Vertica a testé l'utilisation de Delta Lake pour les tables externes, ils se sont appuyés sur MinIO. Les clients HPE Ezmeral Runtime Enterprise exécutent Delta Lake sur MinIO . MinIO prend en charge les exigences de durabilité de Delta Lake, car MinIO suit des modèles de cohérence stricts lecture après écriture et liste après écriture pour toutes les opérations d'E/S en mode distribué et autonome et est largement reconnu pour exécuter les charges de travail Delta Lake.

De nombreuses organisations s'appuient sur des magasins d'objets cloud natifs tels que MinIO et AWS S3 pour héberger de grands ensembles de données structurés, semi-structurés et non structurés. Chaque table est stockée sous la forme d'un ensemble d'objets Parquet ou ORC, et organisée en partitions. Les requêtes sur des fichiers volumineux sont essentiellement des analyses qui s'exécutent rapidement.

Sans Delta Lake, les charges de travail Spark plus complexes, en particulier celles qui modifient, ajoutent ou suppriment des données, sont confrontées à des problèmes de performances et d'exactitude sous de lourdes charges multi-utilisateurs/multi-applications. Les mises à jour multi-objets ne sont pas atomiques et les requêtes ne sont pas isolées, ce qui signifie que si une suppression est effectuée dans une requête, les autres requêtes simultanées obtiendront des résultats partiels car la requête d'origine met à jour chaque objet. La restauration des écritures est délicate et un plantage au milieu d'une mise à jour peut entraîner une table corrompue. Le véritable tueur de performances sont les métadonnées - pour les tables massives avec des millions d'objets qui sont des fichiers Parquet contenant des milliards ou des billions d'enregistrements, les opérations de métadonnées peuvent arrêter complètement les applications construites sur un lac de données.

Delta Lake a été conçu pour combiner la fiabilité transactionnelle des bases de données avec l'évolutivité horizontale des lacs de données. Delta Lake a été conçu pour prendre en charge les charges de travail de style OLAP avec une couche de stockage de table ACID sur des magasins d'objets cloud natifs tels que MinIO. Comme décrit dans l'article Delta Lake: stockage de table ACID haute performance sur les magasins d'objets cloud , «l'idée de base de Delta Lake est simple: nous conservons des informations sur les objets qui font partie d'une table Delta d'une manière ACID, en utilisant une écriture- journal d'avance qui est lui-même stocké dans le magasin d'objets cloud. Les objets sont encodés dans Parquet et peuvent être lus par un moteur qui comprend Parquet. Plusieurs objets peuvent être mis à jour à la fois "de manière sérialisée tout en obtenant des performances de lecture et d'écriture parallèles élevées". Le journal contient des métadonnées telles que les statistiques min/max pour chaque fichier, "permettant des recherches de métadonnées d'un ordre de grandeur plus rapides" que la recherche directe de fichiers dans le magasin d'objets.

Delta Lake fournit ce qui suit :

• ACID garantit : Delta Lake garantit que toutes les modifications apportées aux données sont écrites dans le stockage et validées pour la durabilité tout en étant disponibles pour les utilisateurs et les applications de manière atomique. Il n'y a plus de fichiers partiels ou corrompus dans votre lac de données.
• Gestion évolutive des données et des métadonnées : toutes les lectures et écritures à l'aide de Spark (ou d'un autre moteur de traitement distribué) peuvent évoluer jusqu'à des pétaoctets. Contrairement à la plupart des autres formats de stockage et moteurs de requête, Delta Lake exploite Spark pour faire évoluer tout le traitement des métadonnées et peut gérer efficacement les métadonnées de milliards de fichiers pour des tables à l'échelle du pétaoctet.
• Historique d'audit et voyage dans le temps : le journal des transactions de Delta Lake enregistre des détails sur chaque modification apportée aux données, y compris une piste d'audit complète des modifications. Les instantanés de données permettent aux développeurs d'accéder et de revenir à des versions antérieures des données pour des audits, des restaurations ou pour toute autre raison.
• Application du schéma et évolution du schéma : Delta Lake empêche automatiquement l'insertion de données qui ne correspondent pas au schéma de table existant. Cependant, le schéma de table peut être évolué explicitement et en toute sécurité pour s'adapter aux modifications de la structure et du format des données.
• Prise en charge des suppressions, des mises à jour et des fusions : la plupart des frameworks de traitement distribué ne prennent pas en charge les opérations de modification de données atomiques sur les lacs de données. En revanche, Delta Lake prend en charge les opérations de fusion, de mise à jour et de suppression pour les cas d'utilisation complexes tels que la capture de données modifiées, les opérations de dimension à changement lent et les upserts en continu.
• Streaming et unification par lots : une table Delta Lake a la capacité de fonctionner en mode batch et en tant que source et puits de streaming. Delta Lake fonctionne sur une grande variété de latences, y compris l'ingestion de données en continu et le remplissage historique par lots pour fournir des requêtes interactives en temps réel. Les tâches de streaming écrivent de petits objets dans la table avec une faible latence, puis les combinent de manière transactionnelle en objets plus grands pour de meilleures performances.
• Mise en cache : s'appuyer sur le stockage d'objets signifie que les objets d'une table Delta et de son journal sont immuables et peuvent être mis en cache localement en toute sécurité, où que se trouve localement le multicloud.

L'architecture Lakehouse, Delta Lake en particulier, apporte de nouvelles fonctionnalités clés aux lacs de données construits sur le stockage d'objets. Delta Lake fonctionne avec une liste importante et croissante d'applications et de moteurs de calcul tels que Spark, Starburst, Trino, Flink et Hive, et comprend également des API pour Scala, Java, Rust, Ruby et Python. Conçu pour le cloud, MinIO natif de Kubernetes permet des applications de lac de données performantes, résilientes et sécurisées partout - à la périphérie, dans le centre de données et dans le cloud public/privé.

Dossiers du lac Delta

Une table Delta est une collection de fichiers qui sont stockés ensemble dans un répertoire (pour un système de fichiers) ou un compartiment (pour MinIO et d'autres stockages d'objets). Pour lire et écrire à partir du stockage d'objets, Delta Lake utilise le schéma du chemin pour identifier dynamiquement le système de stockage et utiliser l'implémentation LogStore correspondante pour fournir des garanties ACID. Pour MinIO, vous utiliserez S3A, voir Storage configuration — Delta Lake Documentation . Il est essentiel que le système de stockage sous-jacent utilisé pour Delta Lake soit capable de lectures/écritures atomiques simultanées, tout comme MinIO.

La création de tables Delta consiste en fait à écrire des fichiers dans un répertoire ou un compartiment. Les tables delta sont créées (ouvertes) en écrivant (en lisant) un Spark DataFrame et en spécifiant le format et le chemin delta . Dans Scala, par exemple :

 // Create a Delta table on MinIO: spark.range(5).write.format("delta").save("s3a://<your-minio-bucket>/<path-to-delta-table>") // Read a Delta table on S3: spark.read.format("delta").load("s3a://<your-mnio-bucket>/<path-to-delta-table>").show()

Delta Lake s'appuie sur un compartiment par table, et les compartiments sont généralement modélisés d'après les chemins du système de fichiers. Une table Delta Lake est un compartiment qui contient des données, des métadonnées et un journal des transactions. La table est stockée au format Parquet. Les tables peuvent être partitionnées en plusieurs fichiers. MinIO prend en charge S3 LIST pour répertorier efficacement les objets à l'aide de chemins de style système de fichiers. MinIO prend également en charge les requêtes de plage d'octets afin de lire plus efficacement un sous-ensemble d'un grand fichier Parquet.

MinIO est une excellente maison pour les tables Delta Lake en raison de ses performances de pointe. La combinaison d'évolutivité et de hautes performances de MinIO met chaque charge de travail, aussi exigeante soit-elle, à portée de main. MinIO est capable de performances exceptionnelles - une référence récente a atteint 325 Gio/s (349 Go/s) sur les GET et 165 Gio/s (177 Go/s) sur les PUT avec seulement 32 nœuds de SSD NVMe prêts à l'emploi. MinIO offre plus que les performances nécessaires pour alimenter les charges de travail les plus exigeantes sur Delta Lake.

Il est probable que les buckets Delta Lake contiendront de nombreux fichiers Parquet et JSON, ce qui s'aligne très bien avec toutes les optimisations de petits fichiers que nous avons intégrées à MinIO pour une utilisation en tant que lac de données. Les petits objets sont enregistrés en ligne avec les métadonnées, ce qui réduit les IOPS nécessaires à la fois pour lire et écrire de petits fichiers comme les transactions Delta Lake.

La plupart des entreprises ont besoin d'une fonctionnalité multi-cloud pour Delta Lake. MinIO inclut la réplication active-active pour synchroniser les données entre les emplacements - sur site, dans le cloud public/privé et à la périphérie. La réplication active-active permet aux entreprises de concevoir une résilience multi-géo et un basculement chaud-chaud rapide. Chaque compartiment, ou table Delta Lake, peut être configuré pour la réplication séparément pour une sécurité et une disponibilité optimales.

Transactions ACID avec Delta Lake

L'ajout de transactions ACID (atomicité, cohérence, isolation et durabilité) aux lacs de données est un gros problème, car les organisations ont désormais un meilleur contrôle, et donc une plus grande confiance, dans la masse de données stockées dans le lac de données. Auparavant, les entreprises qui comptaient sur Spark pour travailler avec des lacs de données manquaient d'API atomiques et de transactions ACID, mais maintenant, Delta Lake le permet. Les données peuvent être mises à jour après avoir été capturées et écrites, et avec la prise en charge d'ACID, les données ne seront pas perdues si l'application échoue pendant l'opération. Delta Lake y parvient en agissant comme intermédiaire entre Spark et MinIO pour la lecture et l'écriture de données.

Au centre de Delta Lake se trouve le DeltaLog , un enregistrement ordonné des transactions effectuées par les utilisateurs et les applications. Chaque opération (comme une UPDATE ou une INSERT) effectuée sur une table Delta Lake par un utilisateur est une validation atomique composée de plusieurs actions ou tâches. Lorsque chaque action se termine avec succès, la validation est enregistrée en tant qu'entrée dans le DeltaLog. Si une tâche échoue, la validation n'est pas enregistrée dans le DeltaLog. Sans atomicité, les données pourraient être corrompues en cas de panne matérielle ou logicielle entraînant une écriture partielle des données.

Delta Lake décompose les opérations en une ou plusieurs des actions suivantes :

• Ajouter un fichier - ajoute un fichier

• Supprimer le fichier - supprime un fichier

• Mettre à jour les métadonnées - enregistre les modifications apportées au nom, au schéma ou au partitionnement de la table

• Set transaction - enregistre qu'une tâche de streaming a validé des données

• Informations sur le commit - informations sur le commit, y compris l'opération, l'utilisateur et l'heure

• Changer de protocole - met à jour DeltaLog avec le dernier protocole logiciel

  
  

Ce n'est pas aussi compliqué qu'il y paraît. Par exemple, si un utilisateur ajoute une nouvelle colonne à une table et y ajoute des données, alors Delta Lake décompose cela en ses actions de composant - mettre à jour les métadonnées pour ajouter la colonne et ajouter un fichier pour chaque nouveau fichier ajouté - et les ajoute au DeltaLog lorsqu'ils sont terminés.

Delta Lake s'appuie sur un contrôle de concurrence optimiste pour permettre à plusieurs lecteurs et rédacteurs d'une table donnée de travailler sur la table en même temps. Le contrôle de concurrence optimiste suppose que les modifications apportées à une table par différents utilisateurs peuvent se terminer sans conflit. À mesure que le volume de données augmente, la probabilité que les utilisateurs travaillent sur différentes tables augmente également. Delta Lake sérialise les commits et suit une règle d'exclusion mutuelle si deux commits ou plus ont lieu en même temps. Ce faisant, Delta Lake atteint l'isolation requise pour ACID et la table aura le même aspect après plusieurs écritures simultanées que si ces écritures s'étaient produites en série et séparément les unes des autres.

Lorsqu'un utilisateur exécute une nouvelle requête sur une table ouverte qui a été modifiée depuis la dernière fois qu'elle a été lue, Spark consulte le DeltaLog pour déterminer si de nouvelles transactions ont été publiées dans la table et met à jour la table de l'utilisateur avec ces nouvelles modifications. Cela garantit que la version d'une table d'un utilisateur est synchronisée avec la table principale dans Delta Lake avec l'opération la plus récente et que les utilisateurs ne peuvent pas effectuer de mises à jour conflictuelles sur une table.

DeltaLog, le contrôle de concurrence optimiste et l'application du schéma (combinés à la capacité de faire évoluer le schéma) garantissent à la fois l'atomicité et la cohérence.

Creuser dans DeltaLog

Lorsqu'un utilisateur crée une table Delta Lake, le journal des transactions de cette table est automatiquement créé dans le sous-répertoire _delta_log . Au fur et à mesure que l'utilisateur modifie la table, chaque validation est écrite sous forme de fichier JSON dans le sous-répertoire _delta_log dans l'ordre croissant, c'est-à-dire 000000.json , 000001.json , 000002.json et ainsi de suite.

Supposons que nous ajoutions de nouveaux enregistrements à notre table à partir des fichiers de données 1.parquet et 2.parquet . Cette transaction est ajoutée au DeltaLog et enregistrée sous le fichier 000000.json . Plus tard, nous supprimons ces fichiers et ajoutons un nouveau fichier 3.parquet à la place. Ces actions sont enregistrées dans un nouveau fichier, 000001.json .

Après avoir ajouté 1.parquet et 2.parquet , ils ont été supprimés. Le journal des transactions contient les deux opérations même si elles s'annulent. Delta Lake conserve tous les commits atomiques pour permettre un historique d'audit complet et des fonctionnalités de voyage dans le temps qui montrent aux utilisateurs à quoi ressemblait une table à un moment précis. De plus, les fichiers ne sont pas rapidement supprimés du stockage tant qu'une tâche VACUUM n'est pas exécutée. La gestion des versions MinIO fournit une autre couche d'assurance contre la suppression accidentelle.

Durabilité avec Delta Lake et MinIO

Delta Lake atteint la durabilité en stockant des tables et des journaux de transactions sur des supports persistants. Les fichiers ne sont jamais écrasés et doivent être activement supprimés. Toutes les modifications de données écrites dans le stockage sont mises à la disposition des utilisateurs de manière atomique au fur et à mesure qu'elles se produisent. Les fichiers partiels et corrompus appartiennent au passé. Delta Lake ne conserve pas très longtemps les tables et les journaux dans la RAM et les écrit directement dans MinIO. Tant que les données de validation ont été enregistrées dans le DeltaLog et que les fichiers JSON ont été écrits dans le compartiment, les données sont durables en cas de plantage du système ou de la tâche.

MinIO garantit la durabilité après l'écriture d'une table et de ses composants via plusieurs mécanismes :

• Erasure Coding divise les fichiers de données en blocs de données et de parité et les encode afin que les données primaires soient récupérables même si une partie des données encodées n'est pas disponible. Les systèmes de stockage distribués évolutifs horizontalement s'appuient sur le codage d'effacement pour assurer la protection des données en enregistrant les données codées sur plusieurs disques et nœuds. Si un disque ou un nœud tombe en panne ou si des données sont corrompues, les données d'origine peuvent être reconstruites à partir des blocs enregistrés sur d'autres disques et nœuds.
• Bit Rot Protection capture et répare les objets corrompus à la volée pour éliminer cette menace silencieuse à la durabilité des données
• L'immuabilité des compartiments et des objets protège les données enregistrées sur MinIO contre la suppression ou la modification en utilisant une combinaison de verrouillage d'objet, de rétention et d'autres mécanismes de gouvernance. Les objets écrits dans MinIO ne sont jamais écrasés.
• Bucket et Object Versioning protègent davantage les objets. MinIO conserve un enregistrement de chaque version de chaque objet, même s'il est supprimé, vous permettant de remonter dans le temps (un peu comme le voyage dans le temps de Delta Lake). La gestion des versions est un composant clé de la gestion du cycle de vie des données qui permet aux administrateurs de déplacer des buckets entre les niveaux, par exemple pour utiliser NVMe pour les charges de travail intensives en performances, et de définir une date d'expiration sur les versions afin qu'elles soient purgées du système pour améliorer l'efficacité du stockage.

MinIO sécurise les tables Delta Lake à l'aide du cryptage et régule l'accès à celles-ci à l'aide d'une combinaison de contrôles d'accès IAM et basés sur des politiques. MinIO chiffre les données en transit avec TLS et les données sur les disques avec un chiffrement granulaire au niveau de l'objet à l'aide d'algorithmes de chiffrement modernes et conformes aux normes de l'industrie, tels que AES-256-GCM, ChaCha20-Poly1305 et AES-CBC. MinIO s'intègre à des fournisseurs d'identité externes tels qu'ActiveDirectory/LDAP, Okta et Keycloak pour IAM. Les utilisateurs et les groupes sont ensuite soumis au PBAC compatible AWS IAM lorsqu'ils tentent d'accéder aux tables Delta Lake.

Tutoriel Delta Lake et MinIO

Cette section explique comment démarrer rapidement la lecture et l'écriture de tables Delta sur MinIO en utilisant le mode cluster unique.

Conditions préalables

1. Téléchargez et installez Apache Spark.
2. Téléchargez et installez MinIO. Enregistrez l'adresse IP, le port TCP, la clé d'accès et la clé secrète.
3. Téléchargez et installez le client MinIO.
4. Les fichiers jar suivants sont requis. Vous pouvez copier les jars à n'importe quel emplacement requis sur la machine Spark, par exemple /home/spark .
5. Hadoop - hadoop-aws-2.6.5.jar - Delta Lake a besoin de la classe org.apache.hadoop.fs.s3a.S3AFileSystem du package hadoop-aws , qui implémente l'API FileSystem de Hadoop pour S3. Assurez-vous que la version de ce package correspond à la version Hadoop avec laquelle Spark a été créé.
6. AWS- aws-java-sdk-1.7.4.jar

Configurer Apache Spark avec Delta Lake

Démarrez le shell Spark (Scala ou Python) avec Delta Lake et exécutez des extraits de code de manière interactive.

À Scala :

 bin/spark-shell --packages io.delta:delta-core_2.12:1.2.1 --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" --conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog"

Configurer Delta Lake et AWS S3 sur Apache Spark

Exécutez la commande suivante pour lancer un shell Spark avec prise en charge de Delta Lake et S3 pour MinIO :

 bin/spark-shell \ --packages io.delta:delta-core_2.12:1.2.1,org.apache.hadoop:hadoop-aws:3.3.1 \ --conf spark.hadoop.fs.s3a.access.key=<your-MinIO-access-key> \ --conf spark.hadoop.fs.s3a.secret.key=<your-MinIO-secret-key> --conf "spark.hadoop.fs.s3a.endpoint=<your-MinIO-IP:port> \ --conf "spark.databricks.delta.retentionDurationCheck.enabled=false" \ --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" \ --conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog"

Créer un compartiment dans MinIO

Utilisez le client MinIO pour créer un bucket pour Delta Lake :

 mc alias set minio http://<your-MinIO-IP:port> <your-MinIO-access-key> <your-MinIO-secret-key> mc mb minio\delta-lake

Créer une table de test Delta Lake sur MinIO

Essayez-le et créez une table Delta Lake simple à l'aide de Scala :

 // Create a Delta table on MinIO: spark.range(500).write.format("delta").save("s3a://delta-lake/demo1")

Vous verrez quelque chose indiquant que Spark a écrit la table avec succès.

Ouvrez un navigateur pour vous connecter à MinIO à http://<your-MinIO-IP:9001> avec votre clé d'accès et votre clé secrète. Vous verrez le tableau Delta Lake dans le bucket :

MinIO et Delta Lake pour des transactions ACID hautes performances sur des lacs de données

La combinaison de MinIO et de Delta Lake permet aux entreprises de disposer d'un lac de données multi-cloud qui sert de source unique consolidée de vérité. La possibilité d'interroger et de mettre à jour les tables Delta Lake fournit aux entreprises des informations détaillées sur leurs activités et leurs clients. Divers groupes accèdent aux tables de Delta Lake pour leurs propres initiatives d'analyse ou d'apprentissage automatique, sachant que leur travail est sécurisé et que les données sont disponibles en temps opportun.

Pour aller plus loin, téléchargez MinIO et voyez par vous-même ou lancez une instance de marché sur n'importe quel cloud public. Avez-vous des questions? Demandez sur Slack ou via [email protected].