Qu'est-ce que l'architecture lakehouse médaillon ?

L'architecture en médaillon décrit une série de couches de données qui indiquent la qualité des données stockées dans le lakehouse. Databricks recommande d'adopter une approche multicouche pour établir une source unique de vérité pour les produits de données d'entreprise.

Cette architecture garantit l'atomicité, la cohérence, l'isolation et la durabilité, car les données passent par plusieurs couches de validations et de transformations avant d'être stockées dans un Layout optimisé pour une analytique efficace. Les termes bronze (brutes), silver (validées) et gold (enrichies) décrivent la qualité des données dans chacune de ces couches.

Architecture en médaillon en tant que modèle de conception de données

Une architecture en médaillon est un modèle de conception de données utilisé pour organiser les données de manière logique. Son objectif est d'améliorer la structure et la qualité des données de manière incrémentielle et progressive à mesure qu'elles traversent chaque couche de l'architecture (des tables de couches Bronze, Silver et Gold). Les architectures en médaillon sont parfois également appelées architectures multi-sauts .

En faisant progresser les données à travers ces couches, les organisations peuvent améliorer de manière incrémentielle la qualité et la fiabilité des données, les rendant plus adaptées aux applications de Business Intelligence et de Machine Learning.

Suivre l'architecture en médaillon est une bonne pratique recommandée, mais ce n'est pas une exigence.

Question	Bronze	Argent	Gold
Que se passe-t-il dans cette couche ?	Ingestion de données brutes	Nettoyage et validation des données	Modélisation dimensionnelle et agrégation
Qui est l'utilisateur prévu ?	data engineer - Opérations de données - Équipes de conformité et d'audit	data engineer - Data analysts (utilisent la couche Silver pour un dataset plus raffiné qui conserve toujours des informations détaillées nécessaires à une analyse approfondie) - Data scientists (créent des modèles et effectuent de l'analytique avancée)	Analystes métier et développeurs BI - Data scientists et ingénieurs en machine learning (ML) – Dirigeants et décideurs - Équipes opérationnelles

Question	Bronze	Argent	Gold
Que se passe-t-il dans cette couche ?	Ingestion de données brutes	Nettoyage et validation des données	Modélisation dimensionnelle et agrégation
Qui est l'utilisateur prévu ?	data engineer - Opérations de données - Équipes de conformité et d'audit	data engineer - Data analysts (utilisent la couche Silver pour un dataset plus raffiné qui conserve toujours des informations détaillées nécessaires à une analyse approfondie) - Data scientists (créent des modèles et effectuent de l'analytique avancée)	Analystes métier et développeurs BI - Data scientists et ingénieurs en machine learning (ML) – Dirigeants et décideurs - Équipes opérationnelles

Exemple d'architecture en médaillon

Cet exemple d'architecture en médaillon montre des couches Bronze, Silver et Gold à utiliser par une équipe des opérations commerciales. Chaque couche est stockée dans un schéma différent du catalogue des opérations.

• Couche Bronze (ops.bronze) : Ingère les données brutes du stockage cloud, de Kafka et de Salesforce. Aucun nettoyage ni aucune validation des données n’est effectué ici.

• Couche Silver (ops.silver) : le nettoyage et la validation des données sont effectués dans cette couche.

  • Les données concernant les clients et les transactions sont nettoyées en supprimant les valeurs nulles et en mettant en quarantaine les enregistrements non valides. Ces jeux de données sont joints en un nouveau dataset appelé customer_transactions. Les data scientists peuvent utiliser ce dataset pour l'analytique prédictive.
  • De même, les comptes et les datasets d'opportunités de Salesforce sont joints pour créer account_opportunities, qui est enrichi d'informations sur le compte.
  • Les données leads_raw sont nettoyées dans un dataset appelé leads_cleaned.

• Couche Gold ops.gold() : cette couche est conçue pour les utilisateurs métier. Il contient moins de datasets que silver et bronze.

  • customer_spending: Dépenses moyennes et totales pour chaque client.
  • account_performance: performances quotidiennes pour chaque compte.
  • sales_pipeline_summary: information sur le pipeline de ventes de bout en bout.
  • business_summary: informations hautement agrégées pour le personnel dirigeant.

Ingérer des données brutes vers la couche Bronze

La couche bronze contient des données brutes, non validées. Les données ingérées dans la couche bronze présentent généralement les caractéristiques suivantes :

• Contient et maintient l'état brut de la source de données dans ses formats d'origine.
• Est ajouté de manière incrémentielle et évolue au fil du temps.
• Est destiné à la consommation par des charges de travail qui enrichissent des données pour les tables argent, et non à l’accès par les analystes et les data scientists.
• Sert de source unique de vérité, préservant la fidélité des données.
• Permet le retraitement et l'audit en conservant toutes les données historiques.
• Peut être une combinaison de transactions de streaming et de batch provenant de sources, y compris le stockage d'objets cloud (par exemple, S3, GCS, ADLS), les bus de messages (par exemple, Kafka, Kinesis, etc.), et les systèmes fédérés (par exemple, Lakehouse Federation).

Limiter le nettoyage ou la validation des données

Une validation minimale des données est effectuée dans la couche bronze. Pour éviter la perte de données, Databricks recommande de stocker la plupart des champs sous forme de chaîne, VARIANT ou binaire pour se protéger contre les modifications de schéma inattendues. Des colonnes de métadonnées peuvent être ajoutées, telles que la provenance ou la source des données (par exemple, _metadata.file_name).

Valider et dédupliquer les données dans la couche Silver

Le nettoyage et la validation des données sont effectués dans la couche silver.

Créez des tables Silver à partir de la couche Bronze

Pour construire la couche Silver, lisez les données d'une ou plusieurs tables bronze ou silver, et écrivez les données dans les tables silver.

Databricks ne recommande pas d'écrire directement dans les tables silver à partir de l'ingestion. Si vous écrivez directement à partir de l'ingestion, vous provoquerez des défaillances en raison de modifications de schéma ou d'enregistrements corrompus dans les sources de données. En supposant que toutes les sources sont en mode ajout uniquement, configurez la plupart des lectures du bronze en tant que lectures en streaming. Les lectures de batch doivent être réservées aux petits datasets (par exemple, les petites tables dimensionnelles).

La couche Silver représente les versions validées, nettoyées et enrichies des données. La couche Silver :

• Devrait toujours inclure au moins une représentation validée et non agrégée de chaque enregistrement. Si les représentations agrégées alimentent de nombreuses charges de travail en aval, ces représentations pourraient être dans la couche Silver, mais elles sont généralement dans la couche Gold.
• C'est là que vous effectuez le nettoyage de données, la déduplication et la normalisation.
• Améliore la qualité des données en corrigeant les erreurs et les incohérences.
• Structure les données dans un format plus consommable pour le traitement en aval.

Appliquer la qualité des données

Les Opérations suivantes sont effectuées dans les tables argent :

• application des schémas
• Gestion des valeurs nulles et manquantes
• Déduplication des données
• Résolution des problèmes de données désordonnées et à arrivée tardive.
• Contrôles et application de la qualité des données
• évolution des schémas
• Transtypage
• Jointures

Start la modélisation des données

Il est courant de start la modélisation des données dans la couche argentée, notamment en choisissant comment représenter les données fortement imbriquées ou semi-structurées :

• Utilisez le type de données VARIANT.
• Utilisez les chaînes JSON.
• Créez des structures, des maps et des tableaux.
• Aplatir le schéma ou normaliser les données en plusieurs tables.

Optimisez l'analytique avec la couche Gold

La couche Gold représente des vues très raffinées des données qui alimentent les analytiques en aval, les tableaux de bord, le ML et les applications. Les données de la couche Gold sont souvent fortement agrégées et filtrées pour des périodes de temps ou des régions géographiques spécifiques. Il contient des datasets sémantiquement pertinents qui correspondent aux fonctions et besoins métier.

La couche Gold :

• Comprend des données agrégées adaptées à l'analytique et aux rapports.
• S'aligne avec la logique métier et les exigences.
• Est optimisé pour les performances des requêtes et des tableaux de bord.

S'aligner sur la logique métier et les exigences

La couche Gold est l'endroit où vous modéliserez vos données pour les rapports et l'analytique en utilisant un modèle dimensionnel en établissant des relations et en définissant des mesures. Les analystes ayant accès aux données Gold devraient pouvoir trouver des données spécifiques à un domaine et répondre aux questions.

Étant donné que la couche Gold modélise un domaine d'activité, certains clients créent plusieurs couches Gold pour répondre à différents besoins métiers, tels que les ressources humaines, la finance et l'IT.

Créez des agrégats adaptés à l'analytique et aux rapports

Les organisations doivent souvent créer des fonctions d'agrégation pour des mesures telles que les moyennes, les comptes, les maximums et les minimums. Par exemple, si votre entreprise doit répondre à des questions sur les Ventes hebdomadaires totales, vous pourriez créer une vue matérialisée appelée weekly_sales qui pré-agrège ces données afin que les analystes et autres utilisateurs n'aient pas à recréer des vues matérialisées fréquemment utilisées.

CREATE OR REPLACE MATERIALIZED VIEW weekly_sales AS
SELECT week,
       prod_id,
       region,
       SUM(units) AS total_units,
       SUM(units * rate) AS total_sales
FROM orders
GROUP BY week, prod_id, region

Optimiser les performances des requêtes et des tableaux de bord

L'optimisation des tables de la couche Gold pour les performances est une bonne pratique car ces datasets sont fréquemment interrogés. De grandes quantités de données historiques sont généralement accédées dans la couche sliver et non matérialisées dans la couche Gold.

Contrôlez les coûts en ajustant la fréquence de l'ingestion de données

Contrôlez les coûts en déterminant la fréquence d’ingestion des données.

Fréquence d'ingestion des données	Coût	Latence	Exemples déclaratifs
Ingestion incrémentielle continue	Supérieur	Réduire	Table de streaming utilisant spark.readStream pour ingérer depuis un stockage cloud ou un bus de messages. - Le pipeline qui met à jour cette table de streaming s'exécute en continu. - Code Structured Streaming utilisant spark.readStream dans un notebook pour ingérer depuis un stockage cloud ou un bus de messages dans une table Delta. - Le Notebook est orchestré à l'aide d'un Job Databricks avec un déclencheur de Job continu.
Trigger : Ingestion incrémentale	Réduire	Supérieur	Table de streaming ingérant depuis le stockage cloud ou le bus de messages à l'aide de spark.readStream. - Le pipeline qui met à jour cette table de streaming est déclenché par le trigger planifié du Job ou un trigger d'arrivée de fichiers. - Code Structured Streaming dans un Notebook avec un Trigger Trigger.Available. - Ce Notebook est déclenché par le Trigger planifié du Job ou un Trigger d'arrivée de fichier.
Ingestion par batch avec ingestion incrémentielle manuelle	Réduire	Le plus élevé, en raison d'exécutions peu fréquentes.	Ingestion de table de streaming à partir du stockage cloud à l'aide de spark.read. - N'utilise pas le Structured Streaming. Utilisez plutôt des primitives comme l'écrasement de partition pour mettre à jour une partition entière en une seule fois. - Nécessite une architecture en amont étendue pour configurer le traitement incrémentiel, ce qui permet un coût similaire aux lectures/écritures Structured Streaming. - Nécessite également le partitionnement des données sources par un champ datetime, puis le traitement de tous les enregistrements de cette partition dans la cible.

Fréquence d'ingestion des données	Coût	Latence	Exemples déclaratifs
Ingestion incrémentielle continue	Supérieur	Réduire	Table de streaming utilisant spark.readStream pour ingérer depuis un stockage cloud ou un bus de messages. - Le pipeline qui met à jour cette table de streaming s'exécute en continu. - Code Structured Streaming utilisant spark.readStream dans un notebook pour ingérer depuis un stockage cloud ou un bus de messages dans une table Delta. - Le Notebook est orchestré à l'aide d'un Job Databricks avec un déclencheur de Job continu.
Trigger : Ingestion incrémentale	Réduire	Supérieur	Table de streaming ingérant depuis le stockage cloud ou le bus de messages à l'aide de spark.readStream. - Le pipeline qui met à jour cette table de streaming est déclenché par le trigger planifié du Job ou un trigger d'arrivée de fichiers. - Code Structured Streaming dans un Notebook avec un Trigger Trigger.Available. - Ce Notebook est déclenché par le Trigger planifié du Job ou un Trigger d'arrivée de fichier.
Ingestion par batch avec ingestion incrémentielle manuelle	Réduire	Le plus élevé, en raison d'exécutions peu fréquentes.	Ingestion de table de streaming à partir du stockage cloud à l'aide de spark.read. - N'utilise pas le Structured Streaming. Utilisez plutôt des primitives comme l'écrasement de partition pour mettre à jour une partition entière en une seule fois. - Nécessite une architecture en amont étendue pour configurer le traitement incrémentiel, ce qui permet un coût similaire aux lectures/écritures Structured Streaming. - Nécessite également le partitionnement des données sources par un champ datetime, puis le traitement de tous les enregistrements de cette partition dans la cible.