Datenmodellierung in einer Datenproduktwelt

Sie sehen die Einführung von Datenprodukten oft als Lösung an. Aber allein die Erklärung, dass es sich um Datenprodukte handelt, bringt ihnen nicht die Antworten, die sie suchen. In diesem Blog tauchen wir ein in das tatsächliche Problem und wie Organisationen an einer Lösung arbeiten können.

Zentrale Datenlager stoßen beim Wachsen an ihre Grenzen

Ein DWH beginnt in der Regel klein. Es hat eine Faktentabelle und ein paar Dimensionstabellen. Es dient wenigen Berichten. Und das Leben ist gut. Wenn jedoch neue Berichte hinzugefügt werden, wächst auch das DWH. Neue Dimensionen und Fakten werden hinzugefügt. Einige Umgestaltungen sind notwendig, weil sich herausstellt, dass die Realität komplexer ist als anfangs angenommen. Und die IT-Landschaft hat sich verändert, sodass wir einige Pipelines neu schreiben müssen. Änderungen am DWH dauern immer länger. Bis zu dem Punkt, an dem das Geschäft die Geduld verliert.

Hier sind einige Anzeichen dafür, dass Ihr DWH ins Stocken gerät:

• Die Einarbeitung eines neuen Ingenieurs dauert 3–6 Monate

• Die Person, die das Lager ursprünglich entworfen hat, ist gegangen, und niemand versteht wirklich einige der getroffenen Designentscheidungen

• Niemand wagt es, bestehende Pipelines zu berühren, weil er Angst hat, etwas kaputt zu machen

• Das Hinzufügen eines neuen Elements dauert Monate voller Diskussionen, bevor die Entwicklung überhaupt begonnen hat

• Die meiste Modellierung erfolgt NACH dem DWH, in PowerBI oder Tableau oder in Excel-Tabellen auf Sharepoint.

Klingt bekannt? Nun, dann bin ich mir sicher, dass Sie auch die folgenden Ausreden gehört haben, die nie zu wirklichen Veränderungen führten.

Oberflächliche Lösungen lösen die zugrunde liegende Komplexität nicht

Ich habe viele schwachsinnige Gründe gehört, warum DWH langsam sind. Lassen Sie uns zuerst diese Mythen entkräften:

• Wir müssen zu neuer, glänzender Technik X migrieren, weil der derzeitige Stack seine Grenzen erreicht hat. Dies ist manchmal an der Oberfläche wahr. Aber wenn Sie hinter die Kulissen schauen, sind DWH-Jobs oft schreckliche Schichten über Schichten von Lösungen und Patches, die grundlegende einfache Dinge tun und zu aufgeblähten Ausführungen führen. Diese Komplexität entsteht durch das Hinzufügen neuer Elemente und das Ändern von Elementen im Laufe der Zeit.

• Wir müssen es von Grund auf neu schreiben. Das vorherige Team (nie ich) hat versagt, gute DWH-Prinzipien zu befolgen: Faktentabellen haben die falsche Granularität, Dimensionen sind zu fragmentiert, die Datenqualität ist schlecht, … Warum ist das ein schwachsinniger Grund? Weil jeder dies als Grund angibt. Wenn die Fehlerquote beim Entwerfen eines guten DWH so hoch ist, liegt es vielleicht nicht am vorherigen Team, sondern an der Komplexität, große Datenlager zu bauen.

• Wir müssen einen Data Vault hinzufügen: Es ist wahr, dass Kimball-Stern-Schemata von Natur aus denormalisiert sind. Und während Ihr Datenlager wächst, bedeutet das Hinzufügen einer Quelle, viele Faktentabellen und Dimensionstabellen zu berühren. Aber Data Vaulting, obwohl es seine Vorzüge hat, fügt wirklich nur eine weitere Schicht von Komplexität hinzu. Und Sie benötigen ein Team von hyper-spezialisierten Experten, um mit dieser Komplexität umzugehen. Selbst wenn Sie erfolgreich sind, was ich noch nie im wirklichen Leben gesehen habe, wird dieses Team sofort zum Engpass beim Wachsen des DWH.

• Es liegt an dem Geschäft. Sie haben die Anforderungen geändert: Ich habe Neuigkeiten für Sie. Das Geschäft wird seine Anforderungen IMMER ändern. Das ist eine Tatsache des Lebens. Ingenieure werden Bugs schreiben. Systeme werden ausfallen. Analysten werden wichtige Einblicke verpassen. Das Geschäft wird seine Meinung ändern. Diese Komplexität wird in jedem System vorhanden sein. Ihre Lösung muss widerstandsfähig gegen diese Art von Komplexität sein.

Sehen Sie das gemeinsame Muster? Komplexität. Woher kommt diese Komplexität wirklich?

Die Wurzel des Problems ist, dass das Geschäft komplexer ist als die zentralisierte Natur eines DWH

In einem Datenlager ist es wichtig, sich auf konforme Dimensionen zu einigen. Wenn wir also von einem Kunden sprechen, ist das der gleiche Kunde über verschiedene Faktentabellen hinweg. Das ist, wo ein Großteil der Wiederverwendung herkommt. Aber die geschäftliche Realität ist oft komplexer als das. Wenn Sie in einer Organisation mit einer angemessenen Größe arbeiten, wird Ihnen klar, dass das Geschäft von Natur aus föderiert ist. Hier sind einige Diskussionen aus dem wirklichen Leben, die ich miterlebt habe:

• Eine Supermarktkette, die sich nicht einig ist, was ein Kassenzettel ist

• Eine Fluggesellschaft, die Schwierigkeiten hat zu definieren, was ein Flug ist

• Ein Zugunternehmen, das unterschiedliche Definitionen von einem Zug hat

• Eine große Bildungseinrichtung, die darüber streitet, was eine Schule ist

• Ein Energiekonzern mit 3 Definitionen von Kunde

Jede dieser Diskussionen dauerte Monate und sah oft nie eine klare Lösung. Was für eine Abteilung offensichtlich wahr ist, muss nicht unbedingt für eine andere Abteilung zutreffen. Nehmen Sie das Zugbeispiel. Der Verkauf könnte zwei Züge verkaufen, um von A nach B für zwei verschiedene Kunden zu fahren. Aber der Betrieb kann es zu einem physischen Zug machen. Das Geschäft verkaufte 2 Züge, aber betrieb 1 Zug.

Die Komplexität, diese Nuancen zu verstehen und sie angemessen im DWH zu modellieren, unter Berücksichtigung von 100 ähnlichen Nuancen, führt dazu, dass die DWH-Entwicklung irgendwann ins Stocken gerät. Es gibt nicht eine einzige Person oder ein Team, das all diese Komplexität im Kopf behalten kann.

Die einzige nachhaltige Lösung ist es also, das Datenlager irgendwie zu föderieren. Aber es ist schwierig, ein DWH über mehrere Teams aufzuteilen, da es eine enge Verbindung zwischen seinen verschiedenen Komponenten gibt.

Datenprodukte zur Rettung

Warten Sie, ein Datenlager zu föderieren? Das kann ich tun. Ich habe den ganzen Hype um das Daten-Mesh gehört. Lassen Sie uns einfach eine Reihe von föderierten Datenprodukten erstellen, damit wir den zentralen Engpass beseitigen. Mission erfüllt, oder?

Nun, wir haben noch keine Modellierung vorgenommen. Allein zu erklären, dass Sie Datenprodukte haben, hat uns nicht näher an eine Lösung gebracht.

Modellierungsfallen von Datenprodukten

Ein klassischer Fehler ist, dass wir überhaupt keine Datenmodellierung durchführen. Die sogenannten "source aligned data products" sind nur eine Kopie der Quelle, und Dashboards werden direkt auf diese Quellen gebaut. Herzlichen Glückwunsch, wir sind jetzt "agil", weil das Geschäft machen kann, was es will, wie es will.

Das ist schlecht, weil jede Änderung in der Quelle irgendein Dashboard brechen kann. Es gibt null Wiederverwendbarkeit von Logik, und die gesamte Arbeit muss in PowerBI erledigt werden.

Die nächste Iteration sieht typischerweise die Erstellung tatsächlicher, auf Quellen ausgerichteter Datenprodukte vor, die als Schnittstelle zu Quelldaten dienen. Auf diesen Datenprodukten können Sie Datenmärkte erstellen, die speziell für jedes Dashboard entwickelt wurden. Dies ist ein großer Schritt nach vorne für viele Unternehmen. Denn es gibt eine Trennung von der Quelle zum Dashboard. Aber es gibt immer noch nicht viel Raum für Wiederverwendung. Wenn die Anzahl der Dashboards zunimmt, muss dieselbe Logik immer wieder umgesetzt werden.

Lassen Sie uns dann eine wiederverwendbare Schicht hinzufügen!

Oops, zurück zu Punkt eins. Wenn sich Ihre Datenlandschaft entwickelt, wird es zum Engpass, alles über ein zentrales Datenlager zu schieben.

Erstellen Sie eine dezentrale Landschaft von Datenprodukten

Der Schlüssel besteht darin, wiederverwendbare Datenprodukte zu erstellen, ohne zentrale Engpässe zu haben. Für jeden Anwendungsfall können Sie entscheiden, ob Sie ein Datenprodukt wiederverwenden möchten oder nicht.

Ein Customer360 ist ein großartiges Beispiel für ein wiederverwendbares Datenprodukt.

Es gibt viele Nuancen, wie Datenprodukte gestaltet werden können. Die klugen Köpfe von Thoughtworks haben kürzlich einen Blog zu genau diesem Thema veröffentlicht, der sehr lesenswert ist: https://martinfowler.com/articles/designing-data-products.html

Visualisieren Sie Ihre Datenproduktlandschaft

Einer der Hauptnachteile eines wachsenden Datenlagers ist, dass alles von allem abhängt und es sehr schwierig ist zu verstehen, welche Änderungen welche Datenmärkte beeinflussen.

Sie möchten diesen gleichen Fehler in der Welt der Datenprodukte vermeiden. Sie möchten einen guten Überblick darüber haben, welche Datenprodukte erstellt werden, wer die Eigentümer sind, welchen Status sie haben und wie sie voneinander abhängen.

In seiner einfachsten Form können Sie dies tun, indem Sie eine gute Confluence-Seite aktuell halten. Stellen Sie sicher, dass Sie geschäftliche Begriffe verwenden, damit Geschäftspersonen sich ebenfalls in dieser Landschaft zurechtfinden können.

Wir haben ein Open-Source-Tool entwickelt, um genau das zu tun. Das Data Product Portal schafft Transparenz über alle Datenprodukte in Ihrer Landschaft, unabhängig von der verwendeten Technologie. Neben der Visualisierung Ihrer Datenprodukte kann es auch Datenprodukte automatisieren: Erstellen Sie Datenprodukte nach einem bestimmten Template, verwalten Sie den Zugriff zwischen Datenprodukten, fügen Sie Benutzer zu Datenprodukten hinzu, stellen Sie Werkzeuge wie Snowflake oder Databricks bereit, …

Schließen Sie sich uns beim Aufbau des Data Product Portals an! Besuchen Sie unsere Produktseite; überprüfen Sie unser offenes Repo und werden Sie unser nächster Star ️auf Github; beteiligen Sie sich an der Gemeinschaftsdebatte auf unserem Slack.

Überwachen und entwickeln Sie Ihre Datenproduktlandschaft weiter

Ihre geschäftlichen Bedürfnisse werden sich im Laufe der Zeit ändern. Sie müssen sich also ebenfalls anpassen. Eine modulare Architektur ermöglicht es Ihnen, dies zu tun. Es ist wichtig, weiterhin Möglichkeiten zur Wiederverwendung und zur Optimierung zu identifizieren. Bauen Sie keine komplexen Artefakte für ein einzelnes Dashboard. Abstracten Sie gemeinsame Logik in separaten Datenprodukten nur, wenn Sie die Notwendigkeit sehen.

Im Laufe der Zeit können Sie hoffentlich auch fortschrittlichere Datenprodukte erstellen:

• Sie können von einfachen Dashboards zu KI-Anwendungsfällen übergehen. Dies erfordert, dass Sie fortschrittlichere Technologien einbeziehen. Aber die Grundlagen sollten dieselben bleiben. Stellen Sie sicher, dass Sie eine gemeinsame Speicherschicht haben, die Open Table Formats wie Iceberg verwendet.

• Sobald Sie bereit sind, geschäftskritische Anwendungsfälle zu liefern, können Sie anfangen, über durchsetzbare Datenverträge und SLAs nachzudenken.

• Wenn Sie möchten, dass alle im Geschäft in der Lage sind, Datenprodukte zu erstellen, müssen Sie Ihre Plattform viel selbstständiger gestalten.

Es ist wichtig, sich daran zu erinnern, dass Sie nicht versuchen, all diese Komplexität auf einmal zu bewältigen. Sie müssen im Laufe der Zeit wachsen.

Haben wir die ursprünglichen Probleme mit einem DWH gelöst?

Wenn wir zurückblicken, auf das, was wir am Anfang gesagt haben, sehen wir, wo wir stehen. Sehen wir uns zuerst die Ausreden an:

• Migration zu einer neuen Technologie: Das ist etwas, was Sie von Fall zu Fall tun können. Es ist nicht notwendig, ein großes Migrationsprojekt durchzuführen. Natürlich ist es wichtig, dass Sie die Anzahl der unterstützten Technologien etwas einschränken.

• Von Grund auf neu schreiben: Noch einmal, dies kann von Fall zu Fall entschieden werden. Einige Ihrer Datenprodukte werden sich als schreckliche Drachen herausstellen. Aber das sollte einen viel geringeren Einfluss auf die gesamte Landschaft haben

• Der Bedarf an einem Datenvault: Wenn Sie in einem bestimmten Teil der Organisation einen besonderen Bedarf dafür haben, hält Sie niemand davon ab, einen Datenvault als internes Modell innerhalb eines Datenprodukts zu modellieren. Das ist tatsächlich ein guter Hybridansatz, wenn Sie von der Datenlagerung zu Datenprodukten migrieren. Ich vermute jedoch, dass der Bedarf zusammen mit dem Bedürfnis, alles zu zentralisieren, verschwinden wird.

• Das Geschäft ändert die Anforderungen: Natürlich können wir uns auch ändern. Noch besser, einige Datenprodukte sollten im Besitz und unter der Verwaltung des Geschäfts sein und können die Änderungen selbst vornehmen.

Und was ist mit der tatsächlichen Komplexität: „Die Wurzel des Problems ist, dass das Geschäft komplexer ist als die zentralisierte Natur eines DWH“. Haben wir diese Komplexität beseitigt? Nun, ja und nein. Wir versuchen nicht, alles an einem Ort zu lösen. Stattdessen kann jede Domäne und jedes Datenprodukt explizit angeben, was ihre Definitionen eines bestimmten Objekts sind. Es ist entscheidend, dass es für den Verbraucher transparent gemacht wird. Einfach jede Abteilung zu lassen, was sie will, ist nicht die Antwort. Dieser Ansatz erfordert eine gute Governance und enge Abstimmung zwischen den Parteien.

Fazit

• Zentrale Datenlager stoßen beim Wachsen an ihre Grenzen. Oberflächliche Lösungen lösen die zugrunde liegende Komplexität nicht. Die Wurzel des Problems ist, dass das Geschäft komplexer ist als die zentralisierte Natur eines DWH.

• Datenprodukte zur Rettung: Erstellen Sie eine dezentrale Datenproduktlandschaft, visualisieren Sie Ihre Datenproduktlandschaft, überwachen und entwickeln Sie Ihre Datenproduktlandschaft weiter.