Über Medaillon: Wie man Daten für Self-Service-Daten-Teams strukturiert
07.10.2024
•
Kristof Martens
Seit Jahren verlassen sich Datenplattformen – insbesondere Datenseen und Lakehouses – auf die Medaillonarchitektur.
Dieses gestufte System kategorisiert Daten in drei Schichten: Bronze, Silber und Gold (oder roh, sauber und master, mit einigen Variationen). Die Idee ist einfach: Wenn Daten durch diese Schichten gelangen, steigt ihre Qualität und Nutzbarkeit.
In diesem Beitrag werden wir untersuchen, worum es bei der Medaillon-Architektur geht, wie sie sich auf Selbstbedienungs-Daten-Teams auswirkt und wie Sie Ihre Daten organisieren können, um die Herausforderungen dieses Ansatzes mit Selbstbedienung im Hinterkopf zu überwinden, unter Verwendung des Open-Source Data Product Portal.
Die Medaillon-Architektur

Die Medaillon-Architektur organisiert Daten in drei distincten Ebenen:
Bronze: Dies sind rohe Daten, die direkt aus Quellsystemen (Datenbanken, APIs, Dienste usw.) ohne jegliche Transformation extrahiert werden. Die Extraktion folgt gängigen Mustern wie vollständigen Tabellendumps, Delta-Extraktionen (nur Änderungen zwischen Zeiträumen) oder Change Data Capture (die alle Änderungen an einer Datenquelle widerspiegeln). Daten in der Bronze-Schicht werden typischerweise als CSV- oder Parquet/ORC-Dateien gespeichert, organisiert nach Extraktionsdatum, zusammen mit Metadaten, die helfen, den aktuellen Zustand der Quelldaten wiederherzustellen.
Silber: Diese Schicht konzentriert sich auf Schema-Überprüfung, Datentypkorrekturen und das Herausfiltern von Inkonsistenzen. Nach der Extraktion werden die Daten in der Silber-Schicht transformiert, rekonstruiert und bereinigt. Während die Daten verfeinert sind, spiegelt die Datenstruktur in der Regel immer noch das Quellsystem wider. Diese Phase gewährleistet konsistente, qualitativ hochwertige Daten, die für die weitere Nutzung bereit sind. Dateningenieure übernehmen in der Regel diesen Prozess.
Gold: Dies ist die geschäftsbereite Schicht, in der Analysten, Data Scientists und andere Interessengruppen Daten kombinieren und aggregieren, um hochschätzbare Datensätze zu erstellen. Diese Datensätze unterstützen Geschäftsprozesse wie Dashboards, APIs oder Machine Learning-Modelle.
Medaillon-Architektur und Selbstbedienungs-Daten-Teams
Die Medaillon-Architektur bringt einige klare Vorteile, insbesondere bei der Aufrechterhaltung von Struktur und Ordnung. Da Daten um ein gestuftes System organisiert sind, ist es relativ einfach, Datenquellen zu entdecken. Allerdings müssen nicht alle Daten auf Ihrer Plattform teilbar gemacht werden, d.h. Experimentier- und Zwischenverarbeitungsdaten, auch Daten, die aus Quellsystemen extrahiert werden, sind oft nicht in einem teilbaren Zustand. Wenn alle Daten in einer ähnlichen Datenstruktur erzwungen werden, macht dies Ihre Datenstruktur zu starr und in vielen Fällen zu komplex. Gleichzeitig müssen Datenarchitekten streng kontrollieren, wie und wo Daten gespeichert werden, um das typische Daten-Sumpf-Szenario zu vermeiden, in dem Daten verstreut, unorganisiert und das Eigentum unklar ist.
Die Medaillon-Architektur wurde definiert, als zentrale Daten-Teams die Norm waren und Selbstbedienungs-Datenproduktteams noch nicht berücksichtigt wurden.
Die strenge Kontrolle, die Datenarchitekten über die Struktur der Datenplattform behalten müssen, kann den Prozess verlangsamen. Jedes Mal, wenn ein Team einen neuen Datensatz erstellen oder teilen möchte, muss es Datenarchitekten einbeziehen, um zu bestimmen, wo er gespeichert werden sollte. Diese Reibung schränkt die Agilität ein, behindert die Selbstbedienungsfähigkeiten und überlastet Datenarchitekten mit Anfragen. Dies wird besonders deutlich, wenn eine Organisation ihre Dateninitiativen skalieren möchte und sich in Richtung einer Selbstbedienungs-Datenplattform oder eines Datenprodukt-Denkens bewegt.
Umstellung auf einen Datenprodukt-Denkansatz
Für Unternehmen, die daran arbeiten, Selbstbedienungs-Datenproduktteams zu ermöglichen, an vielen Anwendungsfällen parallel zu arbeiten, ist die Annahme eines Datenprodukt-Denkens entscheidend.

In diesem Ansatz können Teams, die an einem Datenprodukt mit einem klaren Ziel arbeiten, neue Datenoutputs erstellen, die auf Daten basieren, die von anderen Teams produziert wurden. Jedes Team arbeitet im Rahmen seines eigenen Datenprodukts, was Autonomie und Flexibilität ermöglicht.
Teams arbeiten im Rahmen eines Datenprodukts mit einem klaren Ziel und erstellen Datenoutputs zum Teilen, basierend auf Daten anderer Datenprodukte.
Diese Arbeitsweise ermöglicht es Organisationen, Dateninitiativen über mehrere Teams hinweg zu skalieren, während sie mehr Kontrolle und Transparenz darüber erhalten, wer welche Daten verwendet, wie sie verwendet werden und welche Daten daraus abgeleitet werden. Letztendlich stärkt Datenprodukt-Denken die Governance und erleichtert es sowohl technischen als auch geschäftlichen Interessengruppen, den Datenfluss und die Nutzung in der Organisation zu verfolgen.
Datenorganisation für Selbstbedienungs-Datenprodukt-Denken
Bei der Ermöglichung von Selbstbedienung für Datenproduktteams bietet die traditionelle Medaillon-Struktur nicht immer die erforderliche Flexibilität.
Wenn es um Datenprodukte geht, schlagen wir die folgenden Konzepte für das Datenmanagement vor. Ein Datenprodukt hat:
Eingabedaten: Ausgabedaten von anderen Datenprodukten, die als Eingabe für dieses Datenprodukt verwendet werden. Personen, die am Datenprodukt arbeiten, erhalten Lesezugriff auf die Eingabedaten.
Private Daten: Daten, die privat für das Datenprodukt sind und niemals außerhalb des Rahmens des Datenprodukts geteilt werden. Private Daten geben Teams die Flexibilität und Sicherheitsgarantien, die sie benötigen, um an Datenprodukten zu arbeiten. Personen, die am Datenprodukt arbeiten, haben volle Lese- und Schreibrechte auf private Daten.
Ausgabedaten: Datenassets, die im Rahmen des Datenprodukts vom Datenproduktteam erstellt werden, um sie mit anderen Datenprodukten zu teilen. Diese Datenoutputs müssen zur Teilung registriert werden, damit andere Datenprodukte Lesezugriff anfordern können. Datenprodukte können mehrere Datenoutputs zur Teilung registrieren. Personen, die am Datenprodukt arbeiten, erhalten Lese- und Schreibzugang zu den Ausgabedaten nach der Registrierung.

Daten können Dateien sein, die auf Buckets, Datenbanken, Schemata oder Tabellen in Datenlagern oder Lakehouses gespeichert sind. Wie Daten gespeichert und registriert werden, hängt von der Speichertechnologie (d.h. AWS, Azure, Databricks, Snowflake) ab, mit der Sie arbeiten, aber die Konzepte bleiben gültig.
Je nach Ihren Bedürfnissen schlagen wir vor, zwei Hauptmuster der Datenorganisation zu berücksichtigen, die jeweils eigene Vor- und Nachteile hinsichtlich Flexibilität, Governance und Kontrolle bieten.
Datenprodukt-ausgerichtete Organisation
In diesem Modell werden Daten direkt um einzelne Datenprodukte organisiert. Teams können einen spezifischen Speicherort, ein Schema, eine Datenbank oder eine Tabelle für die von ihrem Datenprodukt erzeugten Datenoutputs festlegen. Ein gängiger Ansatz ist, sicherzustellen, dass diese Speicherorte, Datenbanken, Schemata ordentlich mit dem Namen des Datenprodukts vorangestellt werden. Dieser Ansatz ermöglicht es Teams, ihre Datenoutputs unabhängig zu registrieren, ohne Genehmigung von Datenarchitekten zu benötigen. Es ähnelt auch der Goldschicht in der Medaillon-Architektur, in der neue aggregierte Daten aus anderen Datenquellen erstellt werden.

Allerdings wird es schwieriger, relevante Datenquellen zu entdecken, wenn Daten über verschiedene Datenprodukte verteilt sind. Es erhöht Ihre Abhängigkeit von guten Praktiken und Werkzeugen der Daten-Governance, z.B. Datenkataloge. Dies ist jedoch schwer zu vermeiden, selbst mit einer Medaillon-Architektur, aufgrund einer schnell wachsenden Anzahl von Datenprodukten.
Dieser Ansatz funktioniert am besten für geschäftsorientierte Datenproduktteams, wo Geschwindigkeit, Agilität und Eigentum Prioritäten sind. Teams können schnell arbeiten und Ergebnisse produzieren, ohne auf Datenarchitekten angewiesen zu sein, um ihre Daten zu organisieren.
Quellanpassungsorganisation
Eine quellenorientierte Datenorganisation ist um das System strukturiert, aus dem die Daten extrahiert werden, anstatt sich an spezifischen Datenprodukten auszurichten. In den meisten Fällen ist es nicht notwendig, die rohen, unverarbeiteten Daten (Bronzeschicht) aus diesen Quellsystemen zu teilen. Stattdessen liegt der Fokus darauf, die gereinigten, hochwertigen Daten (Silberschicht) für die Teilung verfügbar zu machen. Hier können Datenproduktteams die Datenqualität, Service-Level-Agreements (SLAs) und formelle Datenverträge garantieren.

Im Gegensatz zu einer datengebundenen Struktur ist eine quellenorientierte Struktur besser geeignet für datentechnisch fokussierte Teams, die Aufgaben wie ETL (Extrahieren, Transformieren, Laden) durchführen. Diese Teams sind dafür verantwortlich, Daten aus verschiedenen Quellsystemen zu extrahieren, zu reinigen und vorzubereiten, um zuverlässige Datenassets für andere Teams oder Datenprodukte bereitzustellen. Sie verfügen über spezialisierte Datenengineering-Kompetenzen, die geschäftsorientierten Teams oft fehlen.
Infolge dieser engen Zusammenarbeit ist es für Datenarchitekten in der Regel kein Problem, bei der Organisation zu helfen, wie Daten gespeichert werden müssen. Der quellenorientierte Ansatz spiegelt die Struktur der Silberschicht wider und bietet eine konsistentere Art der Datenorganisation über die Plattform hinweg, wodurch hohe Qualitätsstandards und Governance sichergestellt werden.
Wie das Data Product Portal eine Selbstbedienungs-Datenorganisation unterstützt
In diesem Blogbeitrag haben wir die Medaillon-Architektur und wie sie zum De-facto-Standard für die Organisation von Daten in Ihrer Datenplattform wurde, diskutiert. Wir haben über die Notwendigkeit von mehr Selbstbedienung für Organisationen gesprochen, die ihre Dateninitiativen skalieren möchten, und warum die Medaillon-Architektur möglicherweise nicht ideal dafür ist. Wir haben auch einen alternativen Ansatz zur Strukturierung Ihrer Daten vorgeschlagen, der diese Probleme für Selbstbedienungs-Daten-Teams angehen würde.
Um einen datenproduktorientierten Ansatz zu implementieren und Teams dabei zu unterstützen, Datenprodukte auf eine Selbstbedienungsweise zu erstellen und zu teilen, haben wir das Open-Source Data Product Portal erstellt. Es hilft, Selbstbedienungs-Dateninitiativen in der gesamten Organisation zu skalieren, ohne Kontrolle oder Governance zu opfern.

In der kommenden Version (v0.2.0) wird das Data Product Portal sowohl quellenorientierte als auch datenproduktorientierte Ansätze zur Registrierung von Datenoutputs für die Teilung unterstützen. In einem datenproduktorientierten Modell sind Datenoutputs sofort im Rahmen dieses Datenprodukts verfügbar. In einem quellenorientierten Modell müssen Datenarchitekten die Outputs überprüfen, bevor sie für die Teilung verfügbar gemacht werden können.
Schließen Sie sich uns an, um das Data Product Portal zu entwickeln! Besuchen Sie unsere Produktseite; sehen Sie sich unser offenes Repository an und werden Sie unser nächster Star ️auf Github; beteiligen Sie sich an der Community-Diskussion in unserem Slack.
Latest
Portable by design: Rethinking data platforms in the age of digital sovereignty
Build a portable, EU-compliant data platform and avoid vendor lock-in—discover our cloud-neutral stack in this deep-dive blog.
Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten
Kann ein europäischer Cloud-Anbieter wie Ionos AWS oder Azure ersetzen? Wir testen es – und finden überraschende Vorteile in Bezug auf Kosten, Kontrolle und Unabhängigkeit.
Vermeide schlechte Daten von Anfang an
Das Erfassen aller Daten ohne Qualitätsprüfungen führt zu wiederkehrenden Problemen. Priorisieren Sie die Datenqualität von Anfang an, um nachgelagerte Probleme zu vermeiden.