Qu’est-ce que l’architecture de médaillon dans un lakehouse ?

L’architecture de 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 créer 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é lorsque les données passent par plusieurs couches de validations et de transformations avant d’être stockées dans une disposition optimisée pour une analytique efficace. Les termes bronze (brut), argent (validé) et or (enrichi) décrivent la qualité des données dans chacune de ces couches.

Il est important de noter que cette architecture de médaillon ne remplace pas d’autres techniques de modélisation dimensionnel. Les schémas et les tables au sein de chaque couche peuvent prendre diverses formes et avoir divers degrés de normalisation en fonction de la fréquence et de la nature des mises à jour des données et des cas d’usage en aval pour les données.

Les organisations peuvent tirer profit de Databricks Lakehouse pour créer et gérer des jeux de données validés accessibles dans toute l’entreprise. L’adoption d’un état d’esprit organisationnel axé sur la création d’un modèle data-as-products est une étape clé dans la création d’un data lakehouse.

Ingérer des données brutes dans la couche bronze

La couche bronze contient des données non validées. Les données ingérées dans la couche bronze sont généralement les suivantes :

  • Conserve l’état brut de la source de données.
  • Est ajouté de façon incrémentielle et augmente au fil du temps.
  • Il peut s’agir de n’importe quelle combinaison de transactions de diffusion en continu et de lots.

La conservation de l’historique complet et non traité de chaque jeu de données dans un format de stockage efficace permet de recréer n’importe quel état d’un système de données donné.

Des métadonnées supplémentaires (telles que les noms de fichiers sources ou l’enregistrement de l’heure où les données ont été traitées) peuvent être ajoutées aux données à l’ingestion pour une détection améliorée, une description de l’état du jeu de données source et des performances optimisées dans les applications en aval.

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

Rappelez-vous que si la couche bronze contient l’ensemble de l’historique des données dans un état presque brut, la couche argent représente une version validée et enrichie de nos données qui peut être approuvée pour l’analytique en aval.

Bien que Databricks croit fortement à la vision du lakehouse piloté par des tables bronze, argent et or, la simple implémentation d’une couche argent de manière efficace déverrouillera immédiatement de nombreux avantages potentiels du lakehouse.

Pour tout pipeline de données, la couche argent peut contenir plusieurs tables.

Stimuler l’analyse avec la couche or

Ces données or sont souvent très affinées et agrégées. Elles comprennent des données qui alimentent l’analyse, le Machine Learning et les applications de production. Bien que toutes les tables du lakehouse doivent servir un objectif important, les tables or représentent des données qui ont été transformées en connaissances, plutôt que de simples informations.

Les analystes s’appuient en grande partie sur des tables or pour leurs responsabilités principales et les données partagées avec un client sont rarement stockées en dehors de ce niveau.

Les mises à jour apportées à ces tables sont effectuées dans le cadre des charges de travail de production planifiées de manière régulière, ce qui aide à contrôler les coûts et permet d’établir des contrats de niveau de service (SLA) d’actualisation des données.

Bien que le lakehouse n’ait pas les mêmes problèmes d’interblocage que celui que vous pouvez rencontrer dans un entrepôt de données d’entreprise, les tables d’or sont souvent stockées dans un conteneur de stockage distinct pour éviter les limites cloud sur les demandes de données.

En général, étant donné que les agrégations, les jointures et le filtrage sont gérés avant que les données soient écrites dans la couche or, les utilisateurs doivent voir des performances de requête à faible latence sur les données dans des tables d’or.