Großen Organisationen fehlt es nicht an Daten, sondern am Zugang zu ihnen. Jede Einheit zieht ihre Berichte aus ihrer eigenen Datenbank, das Analyseteam muss für jede neue Frage Genehmigungen und Exporte von mehreren Datenverantwortlichen einholen, und wenn zwei Berichte unterschiedliche Zahlen für dieselbe Kennzahl zeigen, vergehen Wochen mit der Ursachensuche. Das klassische Data Warehouse hat einen Teil davon gelöst, doch bei halbstrukturierten Daten, Sensorereignissen, Bildern und Texten oder bei Machine-Learning-Workloads werden seine starre Struktur und seine Kosten zum Hindernis.
Mit dem Einzug von KI in Unternehmen hat sich die Bedeutung vervielfacht. Modelle brauchen historische, vielfältige Daten bekannter Qualität und müssen auf die Rohdaten zugreifen können, nicht nur auf Berichtszusammenfassungen. Anforderungen an Audit und Rechenschaft verlangen zudem, dass eine Organisation sagen kann, aus welcher Quelle, über welche Transformation und zu welchem Zeitpunkt eine Zahl in einem Bericht entstanden ist. Ein richtig aufgebauter Data Lake erfüllt beide Anforderungen: breiten Zugang für Analyse und Modellierung und klare Datenherkunft für Vertrauen.
Ein moderner Data Lake wird in der Regel als mehrere aufeinanderfolgende Zonen konzipiert. Die Rohzone bewahrt die Daten genau so, wie sie aus der Quelle eingetroffen sind, ob per Batch-Ladevorgang oder Event-Stream. Die bereinigte Zone baut die Daten mit explizitem Schema, Standardtypen und Referenzschlüsseln wie der goldenen Partner-ID neu auf. Die kuratierte Zone erstellt themenorientierte Datenmodelle, etwa Kunde, Transaktion oder Feld, zur Nutzung durch Analytik, Dashboards und Modelle. Daneben verzeichnet ein Datenkatalog Datensätze, Verantwortliche, Qualität und Herkunft, und eine Zugriffsschicht setzt Berechtigungen rollenbasiert durch.
Die erste praktische Überlegung betrifft Verantwortung und Qualität. Jeder Datensatz im Lake muss einen namentlich benannten Verantwortlichen im Fachbereich haben, der für Definition, Qualität und Lebenszyklus zuständig ist. Qualitätsregeln wie Vollständigkeit, Eindeutigkeit und zulässige Wertebereiche sollten bei jedem Ladevorgang automatisch laufen, und das Ergebnis sollte im Katalog veröffentlicht werden. Kommt beispielsweise die tägliche Transaktionslieferung plötzlich nur mit halbem Volumen an, sollte das System Alarm schlagen, bevor die Dashboards aktualisiert werden, statt Führungskräfte am Morgen eine falsche Zahl entdecken zu lassen.
Die zweite Überlegung betrifft die Verbindung zu den Partner-Stammdaten und zu Events. Ein Lake, der Daten unter den lokalen Kennungen der einzelnen Systeme speichert, hat die Fragmentierung lediglich an einem Ort gesammelt. Echter Wert entsteht, wenn in der bereinigten Zone jeder Datensatz mit der gemeinsamen Kennung für Person, Produkt oder Ort verknüpft ist. Die Befüllung des Lake über die Event-Plattform statt durch direkte Extraktion aus operativen Datenbanken entlastet zudem diese Systeme und verbessert die Datenaktualität von über Nacht auf nahezu Echtzeit, was die Einsatzmöglichkeiten des Lake verändert.
Die dritte Überlegung betrifft die Nutzung. Ein Data Lake, den nur das Datenteam nutzt, ist gescheitert. Die Bereitstellungsschicht muss Dashboards und Berichte für Führungskräfte, interaktive Abfragen für Analysten und programmatischen Zugriff für Data Scientists und Modelle bieten, alles auf Basis einer gemeinsamen Definition der Kennzahlen. Eine semantische Schicht, die die offizielle Definition jeder Kennzahl hält, verhindert, dass dasselbe Konzept an verschiedenen Stellen unterschiedlich berechnet wird, und beseitigt den Streit darüber, welcher Bericht die richtige Zahl hat, an der Wurzel.
Die typischen Fallstricke sind bekannt. Erstens: der Datensumpf, also alles ohne Katalog, Verantwortliche oder Qualitätsregeln abzulegen, bis niemand mehr weiß, was wo liegt und wem man vertrauen kann. Zweitens: den Lake als IT-Projekt ohne konkreten geschäftlichen Anwendungsfall aufzubauen, was nach einem Jahr mit einer Masse an Daten und keinen Konsumenten endet. Drittens: die Zugriffskontrolle auf Spalten- und Zeilenebene zu vernachlässigen, wodurch der Lake zur größten Schwachstelle der Organisation für den Abfluss sensibler Daten wird. Viertens: Speicher- und Verarbeitungskosten zu ignorieren, die ohne Aufbewahrungsrichtlinie grenzenlos wachsen.
Bei Niadad ist die Plattform Darya der Enterprise Data Lake: Roh-, bereinigte und kuratierte Zonen, ein Datenkatalog mit Verantwortlichen und Herkunft, automatisierte Qualitätsregeln und eine Anbindung an die Event-Plattform für eine Befüllung nahezu in Echtzeit. Binesh ist die Business-Intelligence-Schicht, die auf Darya Dashboards, Berichte und interaktive Analysen mit gemeinsamen Kennzahldefinitionen bereitstellt. Beide werden im Smart-Agriculture-Projekt von Niadad eingesetzt, um Sensorwerte, Wetterdaten und agronomische Aufzeichnungen zusammenzuführen, und dieselbe Architektur findet sich in den Banken- und Stadtprojekten von Niadad wieder.
Ein Data Lake wird zum Vermögenswert, wenn er drei Dinge zugleich hat: Governance, eine Verknüpfung mit einer gemeinsamen Identität und echte Konsumenten. Ohne Governance ist er ein Sumpf, ohne gemeinsame Identität ein Lager der Fragmentierung, ohne Konsumenten ein Kostenfaktor. Mit allen dreien ist er das Fundament, auf dem Analytik, KI und Rechenschaftsfähigkeit der Organisation aufbauen.