Data Lakes, Data Hubs, Federation: Was führt zum Erfolg?

Daten-Silos können in Unternehmen zu Stolpersteinen werden. Unterschiedliche Systeme und fragmentierte oder inkompatible Daten machen die Integration der Daten und damit die Zusammenführung der Datensilos zu einer großen Herausforderung. 

Eine „Zauberformel“ gibt es nicht. Neue, innovative und erfolgversprechende Lösungsansätze aber, wie virtuelle Datenbanken, Data Lakes und Data Hubs erleichtern dieses Vorhaben. Jedes Unternehmen wird prüfen müssen, welcher der drei Ansätze die beste Lösung für die individuellen Herausforderungen ist. Wer aber deren Unterschiede und Gemeinsamkeiten kennt, der wird Vor- und Nachteile besser abwägen können, das passende System wählen und damit für sein Unternehmen die richtige Entscheidung treffen.

Drei Ansätze – ein Ziel

Eine virtuelle Datenbank nimmt zahlreiche Anfragen an und gibt vor, eine große Datenbank zu sein, die viele unterschiedliche Datenbestände in Silos umfasst. Tatsächlich stellt dieses System eine Anfrage in Echtzeit beim Backend-System (live, Produktion oder Warehouse) und wandelt die Daten dafür in ein allgemeines Format um. Man spricht auch von einer „Federated“-Datenbank, die Subsysteme werden als „Federates“ bezeichnet.

Data Lake ist ein Begriff aus der Hadoop Community und definiert im weitesten Sinne die Verlagerung der Daten aus getrennten Silos in ein System (Hadoop/HDFS). Dazu müssen die Daten nicht harmonisiert, indiziert, durchsuchbar oder einfach verwendbar gemacht werden. Data Lakes bieten zumindest den Vorteil, dass nicht bei jedem Datensatzzugriff eine Verbindung zu einem Live-Produktionssystem hergestellt werden muss.

Ein Data Hub ist ein Hub-and-Spoke-Ansatz für die Datenintegration, bei dem die Daten physisch in ein neues System gelangen und erneut indiziert werden. Vom Data Lake unterscheidet sich ein Data Hub darin, dass dieses System Funktionen wie Discovery, Indizierung und Analytik unterstützt.

Ein entscheidender Unterschied zwischen diesen Ansätzen ist die Frage, ob bzw. wie und wann genau eine Bewegung, Harmonisierung und Indizierung der Daten erfolgt.

Datenbewegung

Sowohl Hubs als auch Lakes bewegen Daten, die aus Silos stammen, auf andere Festplatten kopiert und von anderen Servern oder anderer Software verarbeitet werden. Da Festplattenspeicher heute kostengünstig zur Verfügung steht, sind sowohl die operativen als auch organisatorischen Vorteile immens, wenn nicht bei jeder Suchanfrage auf Produktionsserver zugegriffen werden muss. Virtuelle Datenbanken hingegen greifen bei jeder Abfrage auf das Quellsystem zu. Die Daten werden also nicht bewegt und bleiben in den Silos.

Datenharmonisierung

Sowohl Hubs als auch Federations harmonisieren Daten, die in unterschiedlichen Formaten mit verschiedenen Feldnamen und Schemata in verschiedenen Silos gespeichert werden. Sie müssen aber zumindest ähnlich aussehen, um als Gruppe verarbeitet werden zu können. Die Harmonisierung lässt sich in drei Kategorien unterteilen:

• Unterschiedliche Namen sind am einfachsten zu bewältigen, wenn verschiedene Silos einen identischen Wert mit identischer Bedeutung haben, aber einen anderen Namen verwenden. Beispiel: „PERSON.Vorname“ und „IDENTITÄT.VORNAME“ in zwei verschiedenen relationalen Datenbanktabellen, die aber die gleiche Art von Daten enthalten.
• Unterschiedliche Strukturen gestalten sich schwieriger, wenn sich die Anzahl und Kombination der Felder von Silo zu Silo unterscheiden. Beispiel: „verfügbare Kisten“ in einem System kann der Gesamtzahl der Kisten im Lager entsprechen, zu der der Wert aus einem Feld namens „jede_Kiste zählen“ hinzugerechnet wird, um die Gesamtzahl der Artikel zu ermitteln, was in einem anderen System dem Feld „alle_Artikel“ entspricht (ohne Berücksichtigung, ob der Artikel in einer Kiste verpackt ist oder nicht). Hinzu kommt: Das eine System kann den verfügbaren Bestand als noch nicht zur Erfüllung offener Bestellungen ausweisen, während im anderen System der gesamte physische Bestand unabhängig von offenen Bestellungen angegeben wird.
• Semantische Unterschiede sind die größte Herausforderung. Das eine System kann z. B. drei Statusangaben für Patienten verwenden, ein anderes fünf. Diese Statusangaben überschneiden sich oft und lassen sich nur schwer gegenseitig zuweisen. Beispiel: ({Geplant, Nachbetreuung notwendig, Inaktiv} gegenüber {Aufnahme, Geplant, Nur Telemedizin, Entlassen}).

Progressive Harmonisierung für mehr Agilität

Alle genannten Ansätze schaffen Datenharmonisierung. Letztlich müssen gut strukturierte, dokumentierte APIs oder Datenexporte (oder Berichte) kohärente Daten in einer festgelegten Form liefern. Diese Harmonisierung sollte agil und progressiv sein. Meist werden die Hauptanforderungen frühzeitig erkannt, Datenelemente als „kritisch“ definiert und zuerst harmonisiert. Im Lauf der Zeit kommen weitere Anforderungen hinzu, die zur Harmonisierung von immer mehr Daten, einer sogenannten „Teilharmonisierung“ führt. Wird mit der Zeit die zu harmonisierende Teilmenge erhöht, erfolgt eine „progressive“ Harmonisierung.

Das Marklogic-System z.B. indiziert sowohl Daten im Rohformat als auch jene Daten, die von Quellsystemen in harmonisierter Form stammen. Damit können einige Suchen und Verarbeitungen im Data-Lake-Stil erfolgen, wichtige Daten aber werden indiziert und stehen in harmonisierter Form für den Zugriff zur Verfügung.

Indizierung

Der entscheidende Unterschied zwischen den vorgestellten Ansätzen ist die Art und Weise, wie die Indizierung der Daten erfolgt. Eine Indizierung erlaubt schnelle Suchabfragen und Analysen jedes indizierten Feldes, wobei Indexe auf Festplatten geschrieben und den Datenfeldern übergeordnet werden. Deshalb entscheidet die Art und Weise, wie Daten bewegt und harmonisiert werden, über deren Indizierungsformen.

• Virtuelle (Federated) Datenbanken haben keine Indizierung oder getrennte Datenspeicherung, die indiziert werden könnte. Deshalb bleibt nur das Vertrauen darauf, dass die unterschiedlichen Silos und Quellsysteme eine geeignete Indizierung bieten. Das sogenannte Map-Verfahren ordnet jede Anfrage jedem Quellsystem zu und führt diese bei allen Quellsystemen aus.
• Data Lakes nehmen eine Indizierung nur in äußerst geringem Umfang vor. Wird ein Index angelegt, geschieht dies durch die Integration zusätzlicher Komponenten, um Teile getrennt zu indizieren, wie z.B. kleinere Data Marts, SOLR-Textindexe, HBase-Tabellen mit Indexen usw.
• Data Hubs bewegen alle Daten an eine Stelle, harmonisieren diese ganz oder teilweise und indizieren sie dann in harmonisierter Form. Das ist ideal, weil sich die besten Indexe nur auf Grundlage von harmonisierten Daten erstellen lassen.

Für Entwickler ist es zweifelslos eine große Herausforderung, Daten zu aggregieren, zu finden und zu analysieren, wenn diese unterschiedlich benannt oder grundlegend anders strukturiert sind, semantische Unterschiede aufweisen oder nicht indiziert sind. Der dafür notwendige Workaround muss umsichtig gewählt werden, denn es besteht die Gefahr, am Ende eine Unmenge an Codes zu haben, die über viele Berichte, Batch-Prozesse und ETL-Jobs verteilt sind und nur schwer in den Griff zu bekommen sind.

Zusammenfassung der Unterschiede

Es gibt drei Kriterien, in denen sich die Ansätze voneinander unterscheiden:

Tabelle: Überblick über die 3 Ansätze Virtuelle Datenbank, Data Lake und Data Hub.

Welche Auswirkungen ergeben sich in der Praxis?

1. Ansatz: Virtuelle / Federated-Datenbanken

Virtuelle / Federated-Datenbanken müssen sich bei Abfragen auf die Quellsysteme verlassen, werden also durch die Kapazitäten und Verfügbarkeit dieser Quellsysteme beschränkt.

Kleinster gemeinsamer Nenner: Wenn nur ein Quellsystem oder ein Silo eine Abfrage nicht unterstützt, kann auch das Gesamtsystem die Abfrage nicht unterstützen. (Bsp. Abfrage sucht oder ordnet in einem bestimmten Feld, sucht Geodaten bzw. Koordinaten, führt eine Textsuche durch und umfasst benutzerdefinierte Relevanzbewertungen). Deshalb verschlechtert jedes neu hinzugefügte System auch eher die Gesamtkapazität der Federation, als dass es sie verbessert.

Erneutes Mapping von Abfragen: Die virtuelle Federated-Datenbank hat den Nachteil, dass jede Abfrage an das Gesamtsystem in viele verschiedene Abfragen oder Anfragen umgewandelt wird – und zwar eine pro Federated-Silo oder Subsystem. Das sorgt für zusätzliche Entwicklungsarbeit und bindet das Federated-System eng an die Silos.

Echtzeitdaten: Hier liegt der klare Vorteil von virtuellen Datenbanken. Es werden weder Mechanismen zum Erkennen von Änderungen benötigt, noch müssen diese implementiert werden, falls sie fehlen. Wenn also verschiedene Quellen und Silos nicht herausfinden können, was sich innerhalb einer Stunde, eines Tages oder nach einem bestimmten Zeitplan geändert hat, so ist das ein grundlegendes Problem im Unternehmen, das dringend einer Lösung bedarf. Federated-Systeme fragen immer Live-Daten ab und arbeiten somit immer in Echtzeit, auch wenn Veränderungen im Quellsystem nicht erkannt werden können.

Operative Isolation: Federated-Systeme fallen aus, wenn ein Federate-Mitglied ausfällt oder sie erfordern einen komplexen Code und komplexe Benutzerinteraktionen für Teilabfragen in einem Degraded-Zustand. Oft haben Live-Quellsysteme nicht die Kapazität für minimale Echtzeitabfragen und weniger wichtige Batch-Prozesse, sodass die virtuelle Federated-Datenbank erfolgskritische, vorgeschaltete Systeme zum Erliegen bringt oder zumindest empfindlich treffen kann.

Die folgende Grafik veranschaulicht die bedarfsorientierte Harmonisierung bei einer Federation.

Bild 1: Die bedarfsorientierte Harmonisierung bei einer Federation.

Virtuelle (Federated-) Datenbanken nehmen die gesamte Harmonisierung in Echtzeit vor. Dadurch ermöglichen sie für Geschäftsprozesse zwar Web Services in Echtzeit, sind in der Regel aber nicht skalierbar, um Batch-Verarbeitungen oder Analytics zu unterstützen. Demnach können einige Geschäftsabläufe mit einer Federated-Datenbank betrieben werden. Es muss aber genau darauf geachtet werden, die Systeme nicht zu überlasten.

Fazit – Selbst wenn Abfrageprozesse geschickt auf zehn verschiedene Systeme verteilt werden, bleiben es weiterhin zehn Systeme, die involviert sind. Von einer guten Lösung kann deshalb nicht gesprochen werden.

2. Ansatz: Data Lakes

Data Lakes hingegen stellen sich mit ihrem Ansatz anders dar.

Operative Isolation: Data Lakes sind besser als Ferderated Systeme, da sie eine operative Isolation bieten, indem die Daten in eine separate Infrastruktur bewegt werden.

Abfrage: Data Lakes nehmen weder eine Indizierung noch eine Harmonisierung der Daten vor. Auch sind die Indexe des Quellsystems nicht im Data Lake verfügbar. Folglich bietet ein Data Lake per se noch schlechtere Abfragekapazitäten als eine virtuelle Federated-Datenbank.

Batch-Verarbeitung: Data Lakes (Hadoop-Systeme im Allgemeinen) brillieren logischerweise bei der Batch-Verarbeitung und Predictive Analytics. Wenn also jeder Datensatz um jeden Preis geladen und verarbeitet wird, ist keine intelligente Abfragefunktion nötig. Es kann um die fehlende Indizierung „herumgearbeitet“ werden.

Vereinfachung und Verwaltbarkeit: Weil in einem Data Lake Daten in verschiedenen Formaten vorliegen, wird eine komplexe Logik für jeden Batch-Prozess, ETL- oder Analyse-Job benötigt. Dieser Code gerät allerdings schnell außer Kontrolle, wird unpassend oder veraltet und wird damit zur Belastung.

Bild 2: Data Lakes bringen zusätzliche ETL-Aufgaben mit sich.

Data Lakes erfordern Batch Analytics, um mit einer Brute-Force-Methode Daten während der Analyse oder beim Egress zu verarbeiten. Gleiches gilt für die Batch-Verarbeitung von ETL-Jobs, um unterschiedliche Datenformate in ein neues Formular zu laden. Sie eignen sich generell besser für die Datenanalytik oder für aufschlussreiche Einblicke in die Echtzeitverarbeitung. Ein Data Lake ermöglicht einen „Blick auf das Unternehmen“. Wegen der analytischen Betrachtungsweise bzw. der Batch-Natur können keine operativen Geschäftsprozesse unterstützt werden.

Fazit – Data Lakes bringen zusätzliche ETL-Aufgaben mit sich, so dass die Daten harmonisiert und in einen Data Hub bewegt werden, ohne dass aber die transaktionale Echtzeitkapazität zur Verfügung steht, die der eigentliche Geschäftsbetrieb erfordert.

3. Ansatz: Data Hubs

Data Hubs als dritter Ansatz stellt sich als die beste der drei Lösungsmöglichkeiten dar.

Abfrage: Data Hubs pflegen eigene Indexe und bauen diese über harmonisierte Daten auf. Zur Erinnerung: Die Harmonisierung kann ein progressiver, agiler Prozess sein. Wächst also der Umfang der harmonisierten Daten, wird die Indizierung leistungsstärker. Andere Systeme hingegen müssen als Standard bei der Indizierung und Abfrage mindestens einen „kleinsten gemeinsamen Nenner“ aufweisen. Abfragen werden bei einer Federation nur unterstützt, wenn sie auch vom leistungsschwächsten System oder von Datenquellen ohne Harmonisierung und Indizierung in dieser Federation unterstützt werden. Denn analytische oder Reporting-Prozesse können bei einem Data Lake nur dann unterstützt werden, wenn der Code mit den chaotischsten, am wenigsten kompatiblen Datenquellen im Lake zurechtkommt. Bei einem Data Hub kann die Abfragefunktionalität selbst die Leistung des besten Systems übertreffen, weil die Indexe auf harmonisierten Daten basieren.

Operative Isolation: Wie bei einem Data Lake bewegt ein Data Hub Daten auf separate Festplatten und in eine gesonderte Infrastruktur. Laden und Management erfolgen demnach isoliert von den Quellsystemen.

Batch-Verarbeitung: Bei einem Hub können bei Bedarf viele Datensätze abgefragt und verarbeitet werden. Im Gegensatz zu einem Data Lake erlauben Data Hubs indexgesteuerte Abfragen, um die für jeglichen Zweck verarbeitete Datenmenge zu begrenzen. Dies ermöglicht auch schnelle Suchabfragen und Datenkombinationen bei Batch-Jobs ohne „Sub-Batch“, um relevante, zugehörige Datensätze zu finden.

Vereinfachung und Verwaltung: Da die Daten in einem Data Hub zumindest teilharmonisiert sind, kann für alle Daten ein gemeinsamer Code verwendet werden. Beim Aufbau eines Inventars kann der harmonisierte Datenbestand z. B. ein harmonisiertes Feld „verfügbare Einheiten“ unabhängig davon aufzeigen, aus welchen inkompatiblen Quellsystemen die Daten stammen („alle Artikel“ und „verfügbare Kisten“). Die harmonisierten Felder werden indiziert und vereinheitlicht, was den Zugriff auf die Bestandsinformationen erheblich vereinfacht.

Discovery und Exploration: Ad-hoc- oder unerwartete Analysen kann ein Data Hub einfach unterstützten. Mittels der Datenbewegung an eine zentrale Stelle und der Harmonisierung der wichtigen Datenelemente, wird diese komplexe Aufgabe während des Bewegens und Indizierens erledigt. Das vereinfacht Abfragen, Interaktion, Filter und Drill-down der Daten bei Bedarf.

Erneutes Mapping von Abfragen: Data Hubs vermeiden ein erneutes Mapping von Abfragen bei jedem Quellsystem, indem die Daten zuerst harmonisiert werden und der dann einheitliche Datenbestand indiziert wird. Die Harmonisierung wird die Ist-Kosten der Entwicklung deutlich senken, da nicht mit einem System gearbeitet werden kann, das Daten aus allen Quellen in einem anderen Format liefert. Alle Ansätze müssen irgendwann harmonisieren. Data Hubs ermöglicht simple, einheitliche Abfragen durch Indizieren und Speichern nach erfolgter Harmonisierung.

Bild 3: In vielen Projekten überzeugen Data Hubs, da mit ihnen eine leistungsstarke Datenharmonisierung gelingt.

Fazit – Data Hubs sind der leistungsstärkste Ansatz bei der Datenharmonisierung. Sie verfügen über indizierte Daten in einer vereinheitlichten Form, so dass sie Web Services, Echtzeitanwendungen, Batch-Verarbeitung und auch Analytics ermöglichen. Vor allem operative Geschäftsprozesse werden wegen der Echtzeit-Services effizient unterstützt.

Expertenmeinung

Jedes Unternehmen muss für sich abwägen, welcher Weg der jeweils beste ist. In den meisten Fällen werden die Vorteile eines Data Hubs jedoch überwiegen, weil damit eine leistungsstarke Datenharmonisierung gelingt. Dafür bieten MarkLogic Server flexible Lösungen, denn sie unterstützen sowohl virtuelle Datenbanken als auch Data Lakes. Deren Stärke wird aber vor allem bei Data Hubs offensichtlich, denn in diesem Bereich verfügen sie über eine Reihe an Funktionen, die reibungslose Geschäftsprozesse sicherstellen.

So kommt ein Universal-Index für die Speicherung und Indizierung der Daten zum Einsatz, die Daten lassen sich zudem hochgradig (horizontal) skalieren. Darüber hinaus können mit flexiblen Services nach Industriestandard beliebige Datentransformationen durchgeführt werden, damit alle Clients und APIs die integrierten Daten im richtigen Format erhalten. Bei der Textsuche werden alle Wörter gemäß der individuellen Datenbankkonfiguration indiziert und auch die Abfrage von Geodaten bietet allein in der vorkonfigurierten Fassung eine Fülle an Abfragemöglichkeiten. Schließlich können auch die Big-Data-Kosten besser in Griff bekommen werden, da ältere oder weniger wichtige Daten in billige Speicherlösungen verschoben werden. Ein wichtiger Pluspunkt ist auch die extrem hohe Datensicherheit des MarkLogic-Systems.

Frank Sommerer, Geschäftsführer von its people