Kommentar von Christopher Keller, IT-Novum In 5 Schritten vom Data Warehouse zum Echtzeitdaten-Streaming

Anbieter zum Thema

it-novum GmbH

INFOMOTION GmbH

QUNIS GmbH

Früher konzentrierte sich das Data Warehousing hauptsächlich auf die Analyse der Vergangenheit. Es ging darum, historische Daten auszuwerten und langfristige Geschäftsprozesse zu managen. Die Aktualität der Daten spielte dabei eher eine untergeordnete Rolle. Heute ist das anders: Unternehmen streben immer mehr danach, das „Jetzt“ zu steuern. Doch warum ist das notwendig?

Echtzeit-Daten-Streaming ist zum Beispiel erforderlich, wenn es darum geht, das Verhalten von Websitebesuchern direkt beeinflussen zu können. Aber auch in der Produktion und in der Logistik sind Echtzeit-Daten unverzichtbar. Nur mithilfe dieser sind die Verantwortlichen in der Lage, beispielsweise den Zustand und die Funktionsweise von Maschinen zu überwachen, Prozesse zu steuern und Verkehrsströme zu optimieren.

Die folgenden fünf Schritte erläutern, wie Unternehmen sich von der klassischen Data-Warehouse-Architektur zum Echtzeit-Daten-Streaming entwickeln können.

1. Klassische Data-Warehouse-Prozesse anerkennen

Im ersten Schritt gilt es, die bewährte Leistungsfähigkeit des Data Warehouse bei historischen und strategischen Analysen sowie als Hauptquelle für Unternehmensberichte anzuerkennen. Das Data Warehouse verarbeitet Daten in großen Batches und extrahiert Daten meist zu Randzeiten aus Quellsystemen, um die Systembelastung zu minimieren. Das gilt in der Regel auch für das Staging. Für retrospektive Analyse-Aufgaben und ETL-Jobs ist die klassische Data-Warehouse-Architektur also keineswegs unzureichend oder optimierungsbedürftig. Hier können auch Tools für typische Batchverarbeitung sehr großer Datenbestände – beispielsweise Open Source-Lösungen wie Hadoop – weiterhin zum Einsatz kommen. Entscheidend ist, zu erkennen, wo dieser Ansatz an seine Grenzen stößt.

2. Einzelne Use Cases streamen

Der nächste Schritt zur Einführung einer umfassenden Echtzeit-Daten-Streaming-Architektur besteht darin, zunächst nur für einen spezifischen Anwendungsfall die Streaming-Fähigkeit zu entwickeln. So lassen sich Echtzeit-Reports für diesen spezifischen Use Case erstellen, zum Beispiel zur aktuellen Artikelverfügbarkeit in einem Ladengeschäft. Während für alle anderen Daten und Reports der ETL-Prozess mit herkömmlichem Staging und nächtlicher Batch-Verarbeitung weiterläuft, können beispielsweise die Daten zur Artikelverfügbarkeit in kurzen Intervallen von etwa fünf Minuten oder 30 Sekunden ins Data Warehouse geladen werden. In diesem Teil des ETL-Prozesses wird auch eine Change-Data-Capture-Funktion (CDC) aktiviert. Ein mögliches Open-Source-ETL-Tool für die Datenintegration ist Pentaho DI. Im Vergleich zum Echtzeit-Streaming ist dieses Microbatching zeit- oder mengengesteuert, dennoch sind die Daten aktueller als bei traditionellen Reports. Allerdings kann dieses sukzessive Vorgehen zu einer Inkonsistenz in den Daten führen, wodurch der Druck steigt, auch andere Daten schneller ins Data Warehouse zu laden, um weitere Use Cases zu beschleunigen.

3. Eine skalierbare Streaming-Umgebung schaffen

Um eine größere Anzahl von Use Cases nahezu in Echtzeit mit Daten arbeiten zu lassen, sind in einer klassischen Data-Warehouse-Architektur umfassende Optimierungen der gesamten ETL-Prozesse erforderlich. Dazu gilt es, auch Teile des Data Warehouse an kürzere Ladezyklen anzupassen, was wiederum die Anzahl an ETL-Strecken erhöht. Dabei ist es essenziell, performance-optimierte ETL-Prozesse zu implementieren, um die Datenquellsysteme nicht zu überlasten. Ein grundlegendes Problem bei dieser modifizierten Architektur besteht darin, dass das Streaming mit herkömmlichen SQL-Datenbanken nicht optimal funktioniert, weil diese nicht für das Streaming konzipiert wurden. Wenn also die Anzahl der ETL-Jobs steigt und auf dieselben Tabellen zugreift, können langfristig Inkonsistenzen auftreten. Es bedarf daher einer umfassenderen Überarbeitung der Architektur, um eine effiziente und zuverlässige Streaming-Umgebung zu schaffen.

4. Daten kontinuierlich, oder zumindest eventbasiert verarbeiten

Die immer komplexer werdenden Business-Anforderungen an die Streaming-Fähigkeiten eines Data Warehouse steigen durch neue Arten von Datenquellen noch weiter. Um beispielsweise Click-Stream-Daten von Websitebesuchern oder Maschinendaten aus dem Internet der Dinge (IoT) in Echtzeit zu verarbeiten, erfordert es eine teilweise kontinuierliche, zumindest aber eventbasierte Verarbeitung. Zugleich führt die wachsende Zahl an ETL-Strecken dazu, dass sich die Last auf die Quellsysteme des Unternehmens deutlich erhöht, besonders wenn mehrere dieser Strecken gleichzeitig geladen werden müssen. In solch einem stark auf Streaming ausgerichteten Szenario wird das bisherige Staging nicht mehr stattfinden. Denn hinzu kommen dann womöglich noch weitere Synchronisationsanforderungen, die über die Aktualität der Daten im Data Warehouse hinausgehen. Jedoch ist das vertikale Skalieren der ETL-Strecken keine nachhaltige Lösung, da die Governance einer solch komplexen Architektur irgendwann nicht mehr zu bewältigen wäre. Hier muss eine ganzheitlichere und umfassendere Lösung her, um die Streaming-Fähigkeiten des Data Warehouse zu erweitern und die damit verbundenen Herausforderungen zu bewältigen.

5. Eine Event-Streaming-Architektur etablieren

Eine zukunftsfähige Strategie, um ein Data Warehouse vollständig zum Echtzeit-Daten-Streaming zu entwickeln, besteht darin, eine Event-Streaming-Lösung wie Kafka einzusetzen. Eine solche Architektur ersetzt das herkömmliche Staging durch einen Kafka-Cluster als Storage Layer. Daten werden nur im EL-Verfahren geladen, während die Transformation später von Tools wie Pentaho durchgeführt werden kann. Dazu organisiert die Lösung die Daten in Topics, die wie Briefkästen funktionieren, in die sich Nachrichten einwerfen lassen. Producer-Applikationen schreiben beziehungsweise werfen Events hinein, während Consumer-Applikationen diese Events lesen und verarbeiten. Das gestattet eine vollständige Entkopplung von Producern und Consumern in Echtzeit. Dieses Read-once-/Write-many-Prinzip trägt erfolgreich zur Skalierbarkeit bei. Obendrein ermöglicht diese Architektur eine Trennung zwischen taktisch-operativem Reporting in nahezu Echtzeit und klassisch-analytischem Reporting. Event-Nachrichten, die von Consumer-Applikationen nicht sofort benötigt werden, lassen sich immer noch als Batches laden. In vielen Fällen bietet sich für dieses Szenario die Verwendung der Confluent-Plattform, einer Kafka-Plattform mit Enterprise-Funktionalitäten, an.

Fazit: Auf Kurs mit Open Source

Letztlich überwinden Unternehmen mit einer umfassenden eventbasierten Architektur dauerhaft die Beschränkungen eines klassischen Data Warehouse in Bezug auf Streaming und Echtzeit-Daten. Besonders empfehlenswert auf dem geschilderten Weg ist der Einsatz von Open-Source-Lösungen. Beim Vergleich mit Closed-Source-Lösungen ist nicht der geringere Preis der entscheidende Vorteil, sondern die weit höhere Agilität und Flexibilität. Open-Source-Lösungen sind sehr häufig „best of breed“ im Markt, bieten ein breites Spektrum an Plug-ins und lassen sich bei Bedarf individuell erweitern. Zudem spricht das höhere Sicherheitsniveau für Open Source, denn Einsicht in den Quellcode zu haben, stellt ein großes Sicherheitsplus dar. Somit steht Unternehmen der Wandel vom klassischem Data Warehouse zum Echtzeit-Daten-Streaming nichts mehr im Weg.

(ID:49615962)