This talk explain how Delta Lake can be used as a reference architecture for data lakehouse. It gives the main concepts and principles behind Delta lake

1. CONSTRUIRE UN LAKEHOUSE
AVEC DELTA LAKE

2. Bio
• Depuis 2009 Pr IAV Hassan II, Rabat
• 2000-2009: Consultant IT Paris, Lyon, et Enseignant à
l’Université Lyon 1
• Intérêt: Big Data Spatial / Spark

5. Un peu d’histoire
et quelques tendances/contraintes
Data Lake
Cloud
Storage
Data
Warehouse
Big Data
Traditionnel

6. Data Lake
• Un data lake est une approche de stockage de données
massives utilisée par le big data.
• Ces données sont gardées dans leurs formats originaux ou
sont très peu transformées:
• Structurées (BD..)
• NoSQL
• Semi-structurées (fichiers CSV, journaux, XML, JSON...) ;
• Non structurées (emails, documents, PDF) ;
• Blob (images, audio, vidéo…).

7. Data Lake
• Lorsqu’une donnée est intégrée au sein du Data Lake,
• Elle se voit attribuer un identifiant unique
• Elle est marquée au moyen d'un jeu de balises de métadonnées.
• Lorsqu'un besoin se présente, le Data Lake est parcouru
pour y rechercher des informations pertinentes.

8. Difficultés générales avec Data Lake
• Le risque de se retrouver avec une masse de
données devenues massives et inexploitables, voire
inutilisables:
• Marécage de données ou Data Swamp
• Difficultés d’appliquer du BI sur les données brutes du
data lake
• Complexe à mettre en oeuvre et Faible performance
• Non optimisé pour les requêtes SQL

9. Difficultés générales avec Data Lake
• Pas de propriétés ACID traditionnelles.
• A dans ACID représente Atomicity:
• Soit tous les changements aient lieu ou aucun, le système n’est jamais à mi-chemin.
• C dans ACID représente Consistency:
• Les données doivent être cohérentes et valides dans le système en tout temps.
• I dans ACID représente Isolation:
• Plusieurs transactions se produisent isolément
• D dans ACID représente Durability:
• Les modifications apportées une fois apportées ne sont jamais perdues, même en cas de
défaillance du système.

10. Difficultés techniques avec Data Lake
1. Difficile de rajouter des données (Append)
L’ajout de nouvelles données, mène à des erreurs dans la lecture
2. La modification des données existantes est
difficile
GDPR/CCPA nécessite des changements “fine grained” aux données
existantes dans le data lake
3. Les jobs se terminent en milieu de parcours
La moitié des données apparaissent dans le data lake, le reste est manquant

11. Difficultés techniques avec Data Lake
4. Opérations en temps réel
Mélange de streaming et de Batch conduit à l’incohérence
5. Coûteux de conserver des versions
historiques
6. Difficile à manipuler de grandes métadonnées
Pour les grands lacs de données, les métadonnées elles-mêmes deviennent
difficiles à gérer

12. Difficultés techniques avec Data Lake
7. Problèmes de « trop de fichiers »
Les Data Lake ne sont pas excellents pour traiter des millions de petits fichiers
8. Difficile d’obtenir de grandes performances
Partitionnement des données pour les performances est sujette aux erreurs et
difficile à modifier
9. Problèmes de qualité des données
C’est un casse-tête constant pour s’assurer que toutes les données sont
correctes et de haute qualité

13. Data Warehouse
• Data Warehouses ont été spécialement conçus
pour la BI et les rapports
• Cependant
• Pas de prise en charge de la vidéo, audio, texte
• Pas de prise en charge de Data Science, ML
• Prise en charge limitée pour streaming
• Des formats fermés et propriétaires

14. Cloud Storage
• The cloud is eating Software
•Stockage dans le Cloud pas trop cher:
• Amazon S3, Azure Data Lake Storage …sont parmi les
systèmes de stockage les plus larges et les plus rentables
de la planète
• Elasticity: Pay as you Go, Scale on demand
• Cycle rapide de Version/release
• Uniquement deux versions à maintenir:
L’actuelle et la prochaine
• …

15. Difficultés avec Cloud Storage
• Malheureusement, leur implémentation en tant
que key value store rend difficile la réalisation de
transactions ACID et de hautes performances:
• les opérations de métadonnées telles que la liste des objets sont
coûteuses et les garanties de cohérence sont limitées.

16. Difficultés des Big Data Traditionnels
• Les approches big data actuelles (MapReduce, Spark,
etc) ont été concu initialement pour les data centers
on-premise (gérer vous-même vos serveurs internes)
Comment les évoluer pour bénéficier du cloud?

17. Et si le lakehouse était la solution ?
• Une architecture Lakehouse a les caractéristiques clés
suivantes :
- Prise en charge de divers types de données et formats
- Capacité d’utiliser des outils BI directement sur les données sources
- Fiabilité des données et cohérence
- Support pour diverses charges de travail (BI, science des données, apprentissage
automatique et analyse)
• Le but c’est de construire quelques fonctionnalités d'entrepôt de
données au-dessus du lac de données.

18. Quelques exemples actuels

19. Delta Lake
▪ Delta Lake est une couche de stockage (partie d’une
architecture Lakehouse ) qui apporte de la fiabilité aux lacs de
données:
▪ en apportant les transactions ACID
▪ au dessus des systèmes de stockage existants tels que S3, ADLS, GCS et HDFS.
▪ Unifie le traitement des données en continu et par lots

20. 5 concepts pour mieux comprendre
1. Couche transactionnelle au dessus du data lake
2. Delta Table
3. Log transactionnel
4. Delta architecture design pattern
5. Delta Engine

21. 1- Couche transactionnelle au dessus du
data lake
- Elle s’exécute au-dessus du stockage cloud qui contient les
données.
- Toutes les données restent dans des fichiers dans le stockage d’objets
- Elle suit (tracking) et indexe ces fichiers.

22. 2. Delta Table
• Une table Delta est une collection de données et se
compose de trois choses:
• Les fichiers Delta (en format parquet) contenant les données et
conservés dans le stockage d’objets
• Le journal des transactions Delta conservé avec les fichiers Delta
dans le stockage d’objets
• Une table enregistrée dans le Metastore (facultatif)

23. 3- Log transactionnel: single source of truth
(source uniquede vérité)
- C’est un enregistrement ordonné de
chaque transaction qui a déjà été
effectuée sur une table Delta Lake
depuis sa création.
- Pour chaque opération sur la table
(INSERT, UPDATE, DELETE), Delta
Lake décompose cette opération en
une série d'étapes distinctes
composées d'une ou plusieurs des
actions ci-dessous:
• - Add File
• - Remove File
• - Update Metadata ..
- Ces actions sont ensuite
enregistrées dans le journal des
transactions en tant qu'unités
atomiques ordonnées appelées
commits

24. 3- Log transactionnel- Exemple
• Création de table  création automatique delta_log

25. ACID Transactions
•En gardant une trace des chemins
supprimés, ajoutés et autres
informations de métadonnées dans le
delta_log
Delta Lake est compatible ACID

26. 4- Delta architecture design pattern
Bronze Tables
• Données brutes (ou
très peu de
traitement)
• Les données seront
stockées au format
Delta
Silver Tables
• Des données
directement
interrogeables et
prêtes pour les
insights
• Les mauvais
enregistrements ont
été traités, les types
ont été appliqués
Gold Tables
• Vues très raffinées
des données
• Tables agrégées pour
BI
Ce pattern décrit comment les données brutes seront transformées
et chargées dans des tables Delta Lake successivement plus propres.

27. 5- Delta Engine
▪ File management optimizations
▪ Performance optimization with
Delta Caching
▪ Dynamic File Pruning
▪ Adaptive Query Execution
DELTA ENGINE
Streaming
Analytics
BI Data
Science
Machine
Learnin
Structured, Semi-Structured and
Unstructured Data

28. PLUS DE DETAILS

29. Références
• Databricks.com
• VLDB 2020 paper: Delta Lake: High-Performance ACID
Table Storage over Cloud Object Stores
• Webinar : How to build a Lakehouse ? Instructor: Doug
Bateman
• https://delta.io/
• Data Lakehouse: Building the Next Generation of Data
Lakes using Apache Hudi https://medium.com/slalom-
build/data-lakehouse-building-the-next-generation-of-
data-lakes-using-apache-hudi-41550f62f5f