Phase 6 : Concevoir l'architecture Delta Lake

Dans cette phase, vous concevez l'architecture de stockage Delta Lake et les modèles d'organisation des données pour le lakehouse.

Conception d'une architecture en médaillon

L'architecture en médaillon organise les données en couches afin d'améliorer la qualité des données au fur et à mesure qu'elles progressent dans le pipeline. Ce modèle est fondamental pour construire un lakehouse bien structuré.

Dans sa forme la plus simple, l'architecture en médaillon se compose de trois couches : la couche Bronze (données brutes), la couche Silver (données raffinées) et la couche Gold (données prêtes à l'emploi).

Couche Bronze (données brutes)

Ingérez les données source dans la première couche du lakehouse et conservez-les à cet endroit. Lorsque toutes les données en aval sont créées à partir de la couche bronze, vous pouvez reconstruire les couches ultérieures à partir de cette couche si nécessaire.

Caractéristiques de la couche Bronze

• Source de vérité : Données brutes telles qu'elles arrivent des systèmes sources.
• Transformation minimale : données stockées dans leur format d'origine (ou converties en Delta pour l'auditabilité).
• Immuable : Les données sont en ajout seulement, jamais mises à jour ni supprimées.
• Schema-on-read : gestion flexible des schémas pour divers systèmes sources.
• Piste d'audit : Pour certaines applications (telles que GDPR ou les données réglementées), il peut être approprié de convertir cette couche au format Delta.

Bonnes pratiques pour la couche bronze

• Conservez tous les champs de données source pour une auditabilité complète.
• Utilisez les volumes Unity Catalog pour le dépôt de fichiers bruts.
• Mettre en œuvre l'ingestion incrémentielle pour éviter le re-traitement complet.
• Partitionner par date d'ingestion pour une gestion de données efficace.
• Documentez les sources de données et les plannings d'ingestion.

Couche Silver (données raffinées)

Le but de la deuxième couche est de contenir les données nettoyées, affinées, filtrées et agrégées.

Caractéristiques de la couche Silver

• **Qualité des données** : supprime les doublons, gère les valeurs manquantes, applique le schéma.
• Enrichissement : Joint des données provenant de plusieurs sources pour créer des datasets intégrés.
• **Normalisation **: Applique des types de données, des formats et des conventions de nommage cohérents.
• **Règles métier** : implémente des règles de validation et une logique métier.
• **Prend en charge l'analytique** : Base pour le reporting, les tableaux de bord et le Machine Learning.

Bonnes pratiques pour la couche Silver

• Implémentez des contrôles de qualité des données et un monitoring.
• Utilisez les tables gérées par Unity Catalog pour les données de la couche argent.
• Partitionner par dimensions commerciales (par exemple, date, région, produit).
• Documenter la logique de transformation et les règles métier.
• Établir des SLA pour la fraîcheur des données.

Couche Gold (données prêtes pour l'entreprise)

La troisième couche est créée en fonction des besoins métier ou du projet. Il offre une vue différente sous forme de produits de données à d'autres unités commerciales ou projets, préparant les données en fonction des besoins de sécurité (par exemple, des données anonymisées) ou optimisant les performances (par exemple, des vues pré-agrégées).

Caractéristiques de la couche Gold

• Spécifiques à l’entreprise : adaptés à des cas d’utilisation et des consommateurs spécifiques.
• Optimisées pour la performance : Pré-agrégées, dénormalisées pour des queries rapides.
• Contrôle d'accès : implémente la sécurité au niveau des lignes et le masquage des colonnes.
• Prêt à la consommation : Structuré pour les outils de BI, les applications et les modèles de machine learning.
• Produits de données : Publiés en tant que datasets réutilisables dans toute l'organisation.

Bonnes pratiques pour la couche Gold

• Créez des tables Gold distinctes pour différentes unités commerciales ou cas d'utilisation.
• Utilisez des vues dynamiques pour la sécurité au niveau des lignes et des colonnes.
• Implémentez l'optimisation prédictive pour les tables fréquemment query.
• Documentez le data lineage du bronze au Gold.
• Publier des produits de données dans Unity Catalog avec une propriété claire.

Considération de la zone d'atterrissage

Les pipelines dans les grandes organisations ont souvent une zone d'atterrissage supplémentaire dans le cloud. La zone d'atterrissage reçoit les fichiers bruts des systèmes externes avant l'ingestion dans la couche bronze.

Modèles de zone d'accueil

• Stockage d'objets cloud : compartiments S3, ADLS Gen2 ou GCS pour les dépôts de fichiers.
• Volumes Unity Catalog : Sécurisez l'accès aux fichiers de style POSIX avec la gouvernance Unity Catalog.
• Accès tiers : les systèmes externes peuvent écrire directement dans les zones d’atterrissage.
• Notification Trigger : utilisez les notifications d'événements pour déclencher des pipelines d'ingestion.

Pour des directives complètes sur l'architecture en médaillon, consultez Qu'est-ce que l'architecture lakehouse en médaillon ?.

Concevoir une stratégie d'ingestion des données

L'ingestion de données dans la couche Bronze est la première étape de l'architecture en médaillon. Concevez votre stratégie d'ingestion en fonction des sources de données, des volumes et des exigences en matière de latence.

Méthodes d'ingestion

LakeFlow Connect

Lakeflow Connect est un service géré d'ingestion de données fourni par Databricks qui peut synchroniser régulièrement des données provenant de sources externes dans Databricks sans écrire une seule ligne de code.

Outils d'ingestion de partenaires

Des outils tels que Fivetran peuvent également ingérer des données à partir de sources non prises en charge par Lakeflow Connect. Toutes ces données brutes et non structurées doivent être stockées dans des volumes Unity Catalog (plutôt que dans des emplacements externes).

Pipelines d'ingestion personnalisés

Pour les exigences de transformation complexes ou les sources non prises en charge, créez des pipelines d'ingestion personnalisés à l'aide de LakeFlow Pipelines ou de Notebooks.

Modèles d'ingestion

Ingestion par batch

• Planifier des chargements de données réguliers (par exemple, horaires, quotidiens, hebdomadaires).
• Idéal pour de grands volumes de données historiques.
• Coût inférieur par rapport au streaming.
• Latence acceptable pour les charges de travail analytiques.

Ingestion en streaming

• Ingestion de données en continu avec une faible latence.
• Utilisez les LakeFlow Pipelines avec Auto Loader pour l'ingestion de fichiers en streaming.
• Idéal pour l'analytique en temps réel et les cas d'utilisation opérationnels.
• Coûts de compute plus élevés mais données récentes.

Capture des données modifiées (CDC).

• Capturez et appliquez les modifications incrémentielles des systèmes sources.
• Efficace pour les grandes tables avec des mises à jour fréquentes.
• Préserve le data lineage et la piste d'audit.
• Pris en charge par Lakeflow Connect et Lakeflow pipelines.

Bonnes pratiques pour l'ingestion de données

• Utilisez les volumes du Unity Catalog pour l'ingestion des données brutes avant l'ingestion bronze.
• Mettez en œuvre une ingestion idempotente pour gérer les nouvelles tentatives en toute sécurité.
• Utilisez Auto Loader pour une ingestion de fichiers efficace depuis le stockage cloud.
• Configurer les politiques de rétention pour les données de la zone d'atterrissage.
• Surveillez les pipelines d’ingestion pour détecter les défaillances et les problèmes de qualité des données.

Conception de la stratégie de gestion des tables

Les tables et les volumes peuvent être créés comme gérés ou externes. Comprendre les compromis vous aide à concevoir la bonne stratégie de table.

Tables gérées ou externes

Tables et volumes gérés

Unity Catalog gère l'accès aux tables et volumes externes depuis Databricks, mais ne contrôle pas les fichiers sous-jacents et ne gère pas entièrement managé l'emplacement de stockage de ces fichiers. Les tables et les volumes gérés, quant à eux, sont entièrement managés par Unity Catalog et stockés dans un emplacement de stockage géré associé au schéma conteneur.

Databricks recommande les volumes gérés et les tables gérées pour la plupart des charges de travail, car ils simplifient la configuration, l'optimisation et la gouvernance. De nouvelles fonctionnalités, telles que l'optimisation prédictive et la reprise d'activité gérée, sont disponibles uniquement pour les tables gérées.

Tables externes et volumes

La plus grande différence avec l'externe est que les tables gérées n'offrent pas la structure de dossiers simple de schema_name/table_name, mais utilisent plutôt des dossiers internes de type GUID. Ces dossiers ne doivent être accessibles que via Unity Catalog.

Quand utiliser les tables externes

• Les données doivent rester dans des chemins de stockage cloud spécifiques pour des raisons réglementaires ou de conformité.
• Les systèmes externes nécessitent un accès direct aux fichiers de données.
• Partage de données avec des systèmes qui ne peuvent pas utiliser OpenSharing.
• Données existantes qui ne peuvent pas être migrées vers le stockage géré.

Bonnes pratiques pour la gestion des tables

• Utilisez des tables gérées pour toutes les nouvelles données du lakehouse (bronze, silver, gold).
• Utilisez des volumes gérés pour la zone d'atterrissage et les données brutes non structurées.
• Réservez les tables externes uniquement pour les données qui doivent rester dans des chemins spécifiques.
• Documentez la propriété et les politiques de cycle de vie pour toutes les tables.
• Activer l'optimisation prédictive pour les tables gérées fréquemment interrogées.

Conception en étoile en médaillon

Le modèle de conception hub-and-spoke peut être combiné à une architecture en médaillon pour les déploiements d'entreprise. Ce modèle centralise les actifs de données partagés tout en permettant le traitement de données spécifiques au domaine.

Caractéristiques du médaillon en étoile.

• Data hub : ingère, conserve et gère les assets à l'échelle de l'organisation (par exemple, les données SAP ou les assets généraux tels que la météo ou les données financières). Ceux-ci peuvent être considérés comme des produits de données liés à la source.
• Domaines de données : Chaque domaine lit certains des produits de données organisés par le hub et ingère et organise également ses propres données brutes spécifiques au domaine. Les domaines produisent ensuite des produits de données spécifiques au domaine.
• Publication des modèles
  • Publication centralisée : les domaines publient des produits de données vers le hub pour une consommation à l'échelle de l'organisation.
  • Publication distribuée : Les domaines publient des produits de données au sein de leurs propres catalogues pour une utilisation spécifique au domaine.

Exemple de modèle en étoile

Data Hub (Central)
├── Bronze: Organization-wide raw data (SAP, financials, weather)
├── Silver: Curated shared datasets
└── Gold: Enterprise-wide data products

Sales Domain
├── Bronze: Sales-specific raw data + shared hub data
├── Silver: Sales analytics datasets
└── Gold: Sales data products (published to hub or domain)

Engineering Domain
├── Bronze: Engineering telemetry + shared hub data
├── Silver: Engineering metrics
└── Gold: Engineering dashboards (published within domain)

Bonnes pratiques pour le médaillon hub-and-spoke

• Utilisez le hub pour les données partagées à l'échelle de l'organisation que plusieurs domaines consomment.
• Permettre aux domaines d'ingérer et de gérer leurs propres données spécifiques au domaine.
• Établir des politiques claires de publication de produits de données (centralisées ou distribuées).
• Utilisez les catalogues Unity Catalog pour séparer les données du hub et du domaine.
• Utilisez OpenSharing géré par Databricks pour partager des produits de données entre le hub et les domaines.

Conception stratégie gouvernance des données

La gouvernance des données assure la qualité des données, leur découvrabilité et la conformité au sein de Databricks. Concevoir des stratégies de gouvernance adaptées à la maturité et aux exigences de votre organisation.

Stratégie de qualité des données

Quelle que soit la variante de l’architecture en médaillon, la qualité des données doit s’améliorer à mesure que les données progressent à travers les couches. Par conséquent, la confiance dans les données augmentera ensuite d'un point de vue commercial.

Outils de qualité des données

• Contraintes : Assurez-vous que la qualité et l'intégrité des données ajoutées à une table sont automatiquement vérifiées.
• **Clés primaires et étrangères** : codent les relations entre les champs des tables (à titre d'information, non appliquées).
• **Attentes** : Prévenir la propagation des problèmes de qualité des données en aval (actuellement avec LakeFlow Pipelines, bientôt avec toutes les tables Unity Catalog).
• Lakehouse Monitoring : Surveillez les propriétés statistiques et la qualité des données dans toutes les tables de votre compte.

Bonnes pratiques en matière de qualité des données

• Mettre en œuvre des contrôles de qualité des données lors de l'ingestion de type bronze (par exemple, validation du schéma, contrôles des valeurs nulles).
• Appliquez des règles de qualité plus strictes à mesure que les données passent au niveau Silver et Gold.
• Surveiller les métriques de qualité des données et les tendances au fil du temps.
• Définissez des SLA de qualité des données pour les datasets critiques.
• Automatiser les alertes en cas de violations de la qualité des données.

Éviter les silos de données

Le déplacement, la copie et la duplication des données prennent du temps et peuvent réduire la qualité des données dans le lakehouse, surtout lorsque cela conduit à des silos de données. Pour bien faire la distinction entre copie de données et silo de données, une copie de données autonome ou jetable n’est pas nocive en soi. Il est parfois nécessaire de stimuler l’agilité, l’expérimentation et l’innovation. Lorsque ces copies deviennent opérationnelles avec des produits de données d'entreprise en aval qui en dépendent, elles deviennent des silos de données. Ces silos deviennent rapidement désynchronisés, ce qui finit par rendre le data lake moins fiable.

Bonnes pratiques pour éviter les silos de données

• Utilisez les vues Unity Catalog et OpenSharing plutôt que de copier les données.
• Établissez une source unique de vérité pour chaque dataset.
• Décourager les copies et les doublons de données au niveau des départements.
• Utilisez le lineage Unity Catalog pour suivre les dépendances de données.
• Retirez régulièrement les jeux de données redondants.

Data catalog et découverte

Unity Catalog offre une découverte et une traçabilité des données pour l'utilisabilité et la gouvernance des données.

Découverte des données

Les utilisateurs de tous les domaines d'activité, en particulier dans un modèle de libre-service, doivent pouvoir découvrir des données pertinentes. Par conséquent, le lakehouse a besoin d'un data catalog qui couvre toutes les données pertinentes pour l'entreprise. Les principaux objectifs d'un data catalog sont de :

• Permettre aux utilisateurs de rechercher et de découvrir des datasets.
• Fournissez des métadonnées, des descriptions et de la documentation pour les datasets.
• Affichez le data lineage de la source à la consommation.
• Afficher les métriques de qualité des données et les informations sur la fraîcheur.

Traçabilité des données

Suivez précisément le data lineage afin que les utilisateurs puissent expliquer comment les données ont atteint leur forme actuelle. Unity Catalog capture automatiquement la traçabilité pour :

• Dépendances entre les tables.
• Exécutions de notebooks et de jobs qui lisent ou écrivent des données.
• Systèmes sources en amont.
• Consommateurs en aval et produits de données.

Bonnes pratiques pour le data catalog

• Ajouter des descriptions et des étiquettes à tous les catalogues, schémas et tables.
• Documentez les propriétaires de données et les experts en la matière.
• Utilisez la recherche Unity Catalog pour activer la découverte des données.
• Veuillez examiner et mettre à jour régulièrement les métadonnées.
• Utilisez la traçabilité pour comprendre les dépendances de données avant d'apporter des modifications.

Recommandations d'architecture Delta Lake

Recommandations

• Utilisez l'architecture en médaillon pour structurer le data lake (bronze, argent, Gold).
• Utilisez les tables gérées par Unity Catalog pour toutes les données du lakehouse (du Bronze au Gold).
• Utilisez les volumes Unity Catalog pour les zones d’atterrissage et les données brutes non structurées.
• Mettez en œuvre des contrôles de qualité des données à chaque couche (Bronze, Silver, Gold).
• Utilisez Unity Catalog pour activer la découverte des données et le suivi du lignage.
• Activer l'optimisation prédictive pour les tables gérées fréquemment interrogées.
• Établir des politiques claires de publication de produits de données pour les architectures en étoile.

Éviter

• Ne créez pas de silos de données en dupliquant les données opérationnelles entre les domaines.
• N'utilisez pas de tables externes, sauf si les données doivent rester dans des chemins de stockage spécifiques.
• Ne sautez pas la couche Bronze (préservez toujours les données brutes comme source de vérité).
• Ne contournez pas les contrôles de qualité des données pour respecter les délais de livraison.
• N'autorisez pas la prolifération de données non gérées sans la gouvernance Unity Catalog.

Résultats de la phase 6

Après avoir terminé la Phase 6, vous devriez avoir :

• Architecture en médaillon conçue (couches Bronze, Silver et Gold avec des objectifs clairs).
• Stratégie d'ingestion de données définie (batch, streaming, ou CDC en fonction des exigences).
• Stratégie de gestion des tables conçue (tables gérées vs externes).
• Architecture en médaillon en étoile évaluée (pour les organisations multi-domaines).
• Stratégie de qualité des données définie avec des contrôles appropriés à chaque couche.
• Politiques de gouvernance des données établies (par exemple, catalogue, lignage, découverte).
• Architecture de zone d'atterrissage conçue (si nécessaire pour les systèmes externes).
• Modèle de publication de produit de données défini (centralisé, distribué ou hybride).

Phase suivante : Phase 7 : Planifier l'approche Infrastructure as Code

Conseils de mise en œuvre : Pour des instructions étape par étape sur l'implémentation de votre conception Delta Lake, consultez Qu'est-ce que Delta Lake dans Databricks ?.