Carnets

À quoi sert cette carte

Elle organise le vault par question plutôt que par dossier et propose un ordre de lecture. Chaque note commence par un résumé, indique ses prérequis et finit par ses notes liées. Le Glossaire data engineering définit le vocabulaire commun.

Parcours conseillé

Chaque note indique ses prérequis ; l’ordre ci-dessous va du plus général au plus spécifique.

1. OLTP vs OLAP et stockage en colonnes : deux charges de travail, deux dispositions physiques.
2. Parquet, le format de fichier colonnaire : le format de fichier d’un lac.
3. Normalisation 2NF et 3NF : base relationnelle, anomalies, formes normales.
4. ACID vs BASE : quelles garanties de cohérence, et leur coût.
5. Schema-on-Write vs Schema-on-Read : définir la structure avant ou après le chargement.
6. Staging, ODS, DWH et architecture médaillon : le flux de la donnée brute à la donnée modélisée.
7. Inmon, Kimball et Data Vault : comment modéliser l’entrepôt.
8. Schéma en étoile, de bout en bout : construire faits et dimensions.
9. Slowly Changing Dimensions, types 0 à 3 : garder ou non l’historique d’un attribut.
10. Idempotence et backfill : des traitements rejouables sans doublons.
11. Change Data Capture (CDC) : capter les changements d’une source.
12. dbt — Fondamentaux : transformer dans l’entrepôt.
13. Observabilité des données : détecter une donnée fausse avant les consommateurs.
14. Data lake vs lakehouse : ce qu’ajoute une couche de table à un lac.
15. Lakehouse, cinq situations concrètes : les différences, données à l’appui.
16. Écosystème lakehouse, formats, catalogues et moteurs : formats de table, catalogues, moteurs.
17. Choisir entre lake, lakehouse et warehouse : décider.
18. Maintenance d’un lakehouse : ce que le modèle coûte en exploitation.
19. dbt et le lakehouse : dbt sur des formats de table ouverts.
20. Lakehouse auto-hébergé sur Scaleway : une mise en œuvre concrète, avec retour d’expérience.

Gouvernance et organisation (niveau avancé) :

21. Data mesh : répartir la responsabilité de la donnée par domaine.
22. Data product : l’unité du mesh, et la différence entre les deux.
23. Data contract et ODCS : l’engagement écrit et vérifiable d’un produit.

• Annexe : Data product, définitions et points de vue.

Notes de spécialité, à lire au besoin :

• dbt Incremental Models vs Snowflake Dynamic Tables : maintenir une table à jour sans tout recalculer.
• Union all vs unpivot : un schéma SQL qui relit la même table.
• Journal d’exécution dbt, macros complètes : enregistrer chaque exécution dbt dans une table.
• dbt_bigquery_monitoring : surveiller le coût d’un projet dbt sur BigQuery, avec son catalogue de modèles en annexe.

Par question

Comment garantir la cohérence de mes données ?

ACID vs BASE pour les transactions et la cohérence distribuée ; Idempotence et backfill pour des relances sûres ; Maintenance d’un lakehouse pour l’effacement et la rétention.

Quand imposer la structure ?

Schema-on-Write vs Schema-on-Read, puis Data lake vs lakehouse pour la réponse du lakehouse.

Comment modéliser mon entrepôt ?

OLTP vs OLAP et stockage en colonnes, Normalisation 2NF et 3NF, Inmon, Kimball et Data Vault, Schéma en étoile, de bout en bout, Slowly Changing Dimensions, types 0 à 3, puis Staging, ODS, DWH et architecture médaillon.

Lake, lakehouse ou warehouse ?

Choisir entre lake, lakehouse et warehouse, puis Lakehouse auto-hébergé sur Scaleway si l’on veut garder la maîtrise du stockage.

Comment construire et surveiller un projet dbt ?

dbt — Fondamentaux, dbt Incremental Models vs Snowflake Dynamic Tables, dbt et le lakehouse, dbt_bigquery_monitoring.

Qui est responsable de la donnée, et qu'est-ce qui est garanti ?

Data mesh, Data product, Data contract et ODCS.

Comment capte-t-on les changements d'une source ?

Change Data Capture (CDC), puis Idempotence et backfill pour les appliquer sans doublons.

Comment savoir qu'un traitement a produit de bonnes données ?

Observabilité des données, puis Data contract et ODCS pour l’engagement écrit.