Original-URL des Artikels: https://www.golem.de/news/begriffe-architekturen-produkte-grosse-datenmengen-in-echtzeit-analysieren-1902-139024.html    Veröffentlicht: 04.02.2019 12:06    Kurz-URL: https://glm.io/139024

Begriffe, Architekturen, Produkte

Große Datenmengen in Echtzeit analysieren

Wer sich auch nur oberflächlich mit Big-Data und Echtzeit-Analyse beschäftigt, stößt schnell auf Begriffe und Lösungen, die sich nicht sofort erschließen. Warum brauche ich eine Nachrichten-Queue und was unterscheidet Apache Hadoop von Kafka? Welche Rolle spielt das in einer Kappa-Architektur?

Schieben wir im realen Leben Entscheidungen auf, droht uns der aufgetürmte Stapel an Problemen schnell zu erschlagen. In IT-unterstützten Abläufen sind Stapelverarbeitung und Batch-Betrieb hingegen immer noch an der Tagesordnung. Wären dabei nicht auch Entscheidungen in Echtzeit praxisnäher?

Für diese scheinbar naive Frage gibt es eine ganze Reihe komplexer, alles andere als naiver Antworten. Zum Teil ist das die Folge bestehender Programmierparadigmen und -praktiken, zum anderen Folge der verwendeten Infrastruktur zur Datenverwaltung. Doch hauptsächlich liegt es daran, dass Echtzeit einfach schwierig ist. Doch wer bereit ist, sich damit auseinanderzusetzen, und das ist mittlerweile deutlich einfacher geworden, kann davon profitieren.

Betrachten wir ein Beispiel aus dem Alltag des Einzelhandels. Der Online-Einkauf ist heute eine Selbstverständlichkeit. Doch wer würde als Kunde aktiv versuchen, eine Lösung zu finden, wenn der Bezahlvorgang scheitert? Viel eher bricht er den Bestellvorgang ab. Die meisten Einzelhändler würden dem Kunden dann gerne Hilfe anbieten, um ihn nicht zu verlieren.

Manche Händler betreiben ein Callcenter oder bieten Hilfe per E-Mail. Doch auch hier muss der Kunde aktiv werden. Viel besser wäre es doch, wenn der Händler die Bestellvorgänge, die Transaktionen, analysieren und solche Probleme in Echtzeit erkennen und den Kunden dann proaktiv kontaktieren könnte.

Nun gibt es bereits Analysewerkzeuge und datengetriebene Entscheidungsprozesse, die sich dafür anbieten und zunehmend Verbreitung finden. Die Vorstellung, durch die Analyse von Daten neue Erkenntnisse zu gewinnen, ist nicht neu. Jede Anwendung erzeugt Daten und es gibt eine Vielzahl von Werkzeugen für Datenanalysen. Wir könnten annehmen, dass etablierte Analyseprozesse zur Überwachung von Transaktionen unser Problem lösen könnten. Leider ist das nicht der Fall. Wir benötigen tatsächlich echtzeitfähige Analyseprozesse.

Datenanalyse und die Lambda-Architektur

Traditionell werden Datenanalysen auf einer Kopie der operativen Daten durchgeführt. Dafür gibt es gute Gründe, da sich die Anforderungen an eine Datenbank für den Alltagsbetrieb und die Analyse unterscheiden. Im Alltag sollen die ACID-Eigenschaften einen störungsfreien und sicheren Betrieb gewährleisten. Sie sorgen aber auch für mehr Aufwand in der Datenverarbeitung.

Deshalb wurden Datenbanksysteme entwickelt, die praktischer für die Datenanalyse sind. Sie werden häufig als Data Warehouses bezeichnet und verzichten zum Beispiel auf ACID-Eigenschaften. Außerdem folgen sie anderen Speicherkonzepten als klassische Datenbanken.

Eines dieser Systeme ist Hadoop. Im Gegensatz zu typischen Data Warehouses unterstützt es nicht nur relationale Datenstrukturen, sondern auch unstrukturierte und semi-strukturierte Daten wie XML, JSON, Dokument- und Bildformate. Doch wie andere Data-Warehouse-Systeme wurde auch Hadoop nicht für Echtzeit-Aufgaben konzipiert, sondern setzt auf die Stapelverarbeitung von Daten.

Ganz gleich ob klassisches Data Warehouse oder Hadoop: Um Anwendungsdaten zu analysieren, müssen sie zuerst aus der eigentlichen operativen Datenbank übertragen werden. Dieser Prozess erfordert einiges an Verarbeitung, die als ETL (Extract, Transform, Load) bezeichnet wird. In sogenannten ETL-Pipelines durchlaufen die Daten eine Reihe von Verarbeitungsschritten, einen zumeist zeitintensiven Vorgang.

Das führte zur Einführung der Lambda-Architektur. Diese hybride Architektur kombiniert drei Bestandteile: Das Batch Layer führt eine umfassende Analyse der gesamten Datenmenge per Stapelverarbeitung durch. Das Speed Layer zielt auf die sofortige, schnelle Verarbeitung neu eingetroffener Daten, wobei die Analyseergebnisse häufig nur angenähert sind. Dem einheitlichen Zugriff auf die Analyseergebnisse dient das Serving Layer.

Das Problem mit der Lambda-Architektur besteht laut dem Big-Data-Entwickler Dean Wampler darin, dass "ohne ein Werkzeug [..], das zur Implementierung von Batch- und Streaming-Jobs verwendet werden kann, die Logik zweimal implementiert werden muss: einmal mit den Tools für den Batch-Layer und dann noch einmal für den Speed-Layer. Auch der Serving-Layer erfordert in der Regel benutzerdefinierte Tools für die Integration der beiden Datenquellen."

Das bedeutet viel Komplexität, schlechte Reaktionszeiten und hohe Betreuungskosten. Deshalb wird die Lambda-Architektur von vielen als ein reines Übergangsmodell betrachtet. Um auf unser Ausgangsproblem zurückzukommen: Nicht durch die Lambda-Architektur ist es großen Händlern gelungen, die Zahl der abgebrochenen Onlinebestellungen um 80 Prozent zu reduzieren, das gelang nur durch Echtzeit-Analysen.



Die Verarbeitung unbeschränkter Mengen und die Kappa-Architektur

Dean Wampler vertritt in seinem Artikel Fast Data Architectures for Streaming Applications die Auffassung, die Datenverarbeitung müsse anders betrachtet werden und argumentiert wie folgt: "Wenn alles als Datenstrom betrachtet wird, entweder in Form einer beschränkten Menge (wie bei der Stapelverarbeitung) oder unbeschränkt, dann können Batch- und Speed-Layer nicht nur mit derselben Infrastruktur vereinheitlicht werden, sondern die Batch-Verarbeitung wird dann einfach zum Teil der Datenstrom-Verarbeitung."

Dadurch ist eine modifizierte Architektur namens Kappa entstanden. Sie ist nicht nur eine schnelle Datenarchitektur, sondern fokussiert auch eine neue Denkweise: Denn wenn alles ein Datenstrom ist, haben wir ein neues Paradigma. Und neue Paradigmen ziehen oft eigene Definitionen nach sich, auch hier.

Tyler Akidau, Softwareentwickler bei Google und eng an der Entwicklung der Streaming-Engine und des Streaming-Modells von Google beteiligt, hat sich für die Verwendung der Begriffe beschränkter (Bounded) und unbeschränkter (Unbounded) Datenmengen und Verarbeitung ausgesprochen, um die Begrifflichkeiten zu klären und den Begriff Streaming beziehungsweise Datenstrom zu ersetzen: "Unbounded Data: Eine stetig wachsende, im Grunde unendliche Datenmenge. Diese Datenmengen werden häufig als Datenströme bezeichnet. Die Begriffe 'Datenströme' oder 'Batch' sind jedoch problematisch, wenn es um Datenmengen geht, weil [..] sie implizit von der Verwendung einer bestimmten Art von Verarbeitung und Interpretation dieser Datenmengen ausgehen."

Der entscheidende Unterschied zwischen diesen beiden Arten von Datenmengen ist aber tatsächlich ihre (mathematische) Beschränktheit. Deshalb ist es sinnvoll, Begriffe zu verwenden, die diesen Unterschied auch einfangen. Im weiteren Artikelverlauf wird deswegen der Begriff Unbounded Data (englisch für Unbegrenzte Datenmenge) für unendliche Datenmengen beziehungsweise Datenströme verwendet. Der Begriff Bounded Data (Begrenzte Datenmenge) steht hingegen für endliche Datenmengen wie sie innerhalb von Stapelprozessen typisch sind.

Die englische Bezeichnung Unbounded Data processing beschreibt die kontinuierliche Datenverarbeitung eben solcher unbeschränkter Datenmengen. Die weniger sperrige Bezeichnung Streaming beziehungsweise Streamen, um eine solche Verarbeitung von Datenströmen vor allem im Englischen zu bezeichnen, ist zwar häufig praktisch, sie führt aber je nach Kontext zu Missverständnissen über die Art der Datenmengen und den Umgang mit ihnen. Im Deutschen zum Beispiel ist Streamen oft ein Synonym für das Senden und Empfangen von Video-Datenströmen. Im Englischen hingegen kann Streaming sowohl den Umfang der Datenmengen als auch deren Transport und die Verarbeitung durch Anwendungen bezeichnen.

Für die Verarbeitung von Unbounded Data wurden und werden häufig immer noch die verfügbaren und bekannten Konzepte zur Stapelverarbeitung und zum Batchbetrieb genutzt. Die genutzten Anwendungen werden dabei einfach immer wieder aufgerufen. Umgekehrt kann ein gut geplantes System für das Unbounded Data Processing eben mehr, als nur Batch-Jobs von Bounded Data abzuarbeiten.

Nachrichten-Queues

Wie das gehen kann, erklärt Dean Wampler ebenfalls: "Datenströme erreichen das System über Socket-Verbindungen von anderen Servern sowohl innerhalb der Arbeitsumgebung als auch von außerhalb, wie Telemetriedaten von IoT-Geräten, Feeds aus Sozialen Netzwerken wie zum Beispiel über Twitters Firehose-Dienst et cetera. Diese Datenströme werden in einen verteilten Kafka-Cluster eingespeist, um sie für eine bestimmte Zeitspanne skalierbar und robust zu speichern. Kafka ist das Rückgrat der Architektur".

Die Daten gelangen also über die Infrastruktur einer Nachrichten-Queue in die Verarbeitungspipeline. Die Queue dient als ein Eingangslager und Verteilzentrum für ein System des Unbounded Data Processing.

Was als nächstes passiert, ist kompliziert. Wampler hält die Lösung mit Kafka-Clustern dennoch für die derzeit beste: "Für die Stream-Verarbeitung mit geringen Latenzen ist es der robusteste Mechanismus, die Daten mit Hilfe von [Kafka] in die entsprechenden Verarbeitungsmechanismen einzuspeisen. Und derzeit buhlen eine ganze Reihe von entsprechenden Lösungen um Aufmerksamkeit."

Doch bevor wir auf diese Lösungen zu sprechen kommen, sollten wir noch einen kurzen Blick auf die Nachrichten-Queues werfen. Systeme wie Kafka sind nicht neu. Die IBM MQ Series und verschiedene Implementierungen der Java-JMS-Spezifikation, wie zum Beispiel Apache Camel oder RabbitMQ, existieren bereits seit längerem. Sie sind gut bekannt und wir können sie als die Vorläufer für das Unbounded Data Processing sehen.

Konzeptionell unterscheidet sich Kafka nicht großartig von ihnen. Der Unterschied ist laut Jay Kreps, einem der Kafka-Erschaffer, die Skalierbarkeit von Kafka: "Wir kommen mit Billiarden von Nachrichten zurecht. Zeitgemäße, cloudbasierte Systeme sind einfach besser darin, solche technischen Möglichkeiten existierten früher nicht. Wir profitieren davon, etwas später angefangen zu haben."

Aber Kafka ist nicht die einzige Möglichkeit. Wer bereits eine Nachrichten-Queue betreibt, kann auch diese eventuell als Eingangspunkt für eine Datenverarbeitungs-Pipeline nutzen. Wer cloudbasierte Anwendungen aufbaut, kann bei den großen Cloud-Anbietern auf deren Kafka-Alternativen zurückgreifen: AWS Kinesis, Azure Stream Analytics und Google Cloud Dataflow. Außerdem gibt es mit Apache Pulsar ein Open-Source-Projekt, das sich als Kafka-Alternative positioniert.

Ohne näher auf die einzelnen Lösungen der Cloud-Anbieter einzugehen oder einen detaillierten Vergleich mit Kafka anzustellen, müssen wir jedoch einen Punkt hervorheben, der für alle Lösungen von Cloud-Anbietern gilt: Werden bereits Cloud-Lösungen eines Anbieters genutzt, erfolgt die Einbindung der Nachrichten-Queue meist nahtlos. Aber diese strategische Entscheidung bedeutet auch, sich stark an einen Anbieter zu binden.

Als weiterer wichtiger Punkt ist zu nennen, dass die Grenzen zwischen Nachrichten-Queue und Streaming nicht ganz eindeutig sind. Nachrichten-Queues sind mehr ein Verkehrsleitsystem, das eingehende Daten verpackt und zu ihren Zielorten bringt. Je nach Lösung können sie die Daten auch verarbeiten und umwandeln.

Zum Beispiel kann Kafka nicht nur Analyseprozesse befüllen, sondern selbst als Basis für operative Anwendungen dienen. Es unterstützt eine Reihe von Verarbeitungsmechanismen und auch SQL für Datenabfragen. Damit können Entwickler per SQL-Abfrage gezielt relevante Datenmengen auswählen und damit weiter arbeiten. Es ist sogar möglich, Daten in Kafka dauerhaft zu speichern und es als Plattform für Microservices zu nutzen.



Streaming-Systeme

Dennoch sind Nachrichten-Queues in der Praxis nur ein spezieller Teil in Lambda- und Kappa-Architekturen: Sie speisen kontinuierlich Daten in die kontinuierlich laufenden Fachanwendungen ein. Im Englischen werden diese Art von Anwendungen beziehungsweise deren Plattformen zumeist als Streaming Engine bezeichnet. Mittlerweile ist eine Vielzahl von Streaming Engines verfügbar. Ein Vergleich dieser Lösungen in Hinsicht auf Architektur, Einsatzzwecke, verfügbare Dienstleister und vieles andere ist nicht trivial.

Derzeit stammen die beliebtesten Engines in diesem Bereich von Apache und sind Open-Source-Projekte: Apex, Beam, Flink, Samza, Storm und Spark. Ihre Verbreitung spricht Bände für die steigende Annahme und Bedeutung des Unbounded Data Processing. Aber zu viele Optionen sind nicht immer gut: Für welche soll ich mich entscheiden und was kann ich damit anfangen? Besprechen wir kurz die verschiedenen Möglichkeiten.

Zunächst einmal bieten nicht alle Engines im gleichen Maße oder auf gleiche Weise Hilfe bei der Implementierung für Unternehmen. Flink und Spark verfügen über einen quelloffenen Kern, der mit proprietären Ergänzungen erweitert werden kann. Hinter diesen Erweiterungen stehen Anbieter, die Support bereitstellen, in diesem Fall Data Artisans beziehungsweise Databricks. Diese bieten unter anderem kommerzielle Produkte und Dienstleistungen auf der Basis von Flink und Spark.

Bei anderen Streaming Engines stehen keine Unternehmen dahinter, die den Support gewährleisten, erprobte fertige Lösungen anbieten und die Entwicklung vorantreiben. Darunter fällt mittlerweile Apache Apex, das einst von dem mittlerweile geschlossenen Unternehmen Data Torrent betreut wurde. Doch dazu gehören auch Apache Storm und Apache Samza. Storm ist älter und ausgereifter als Samza, und es wird von dem Unternehmen Hortonworks unterstützt.

Aber Hortonworks Kerngeschäft liegt nicht im Streaming, und wer als Unternehmen Unterstützung von Hortonworks will, muss anscheinend den gesamten Hortonworks-Stack nutzen. Es ist unklar, ob Hortonworks die Unterstützung für Storm ausbauen will, aber derzeit deutet nichts darauf hin.

Apache Beam unterscheidet sich von den bisher genannten dadurch, dass es eine Spezifikation ist, keine implementierte Engine an sich. Dahinter steht die Idee eines abstrakten Streaming-Konzeptes und einer einheitlichen API für die verschiedenen Streaming Engines. Beam wird vor allem von Google unterstützt - mit der Absicht, dass Streaming-Prozesse ohne viel Aufwand zu Googles Dataflow übertragen werden können. Flink unterstützt die Spezifikation vollständig, Spark nur teilweise.

Wie unterscheiden sich schließlich Flink und Spark? Flink wird vor allem als Integrationszentrale für echtzeitfähige, zustandsbehaftete Unternehmensanwendungen genutzt. Spark wird eher für Data-Science- und Analyse-Anwendungen genutzt, für Popularität sorgt hier die Integration von Python, Machine Learning und Jupyter Notebook.

Ein weiterer Unterschied ist, dass die Flink-basierte Plattform von Data Artisan nicht als cloudbasierte Lösung verfügbar ist, während Databricks' Angebot mit einer Cloud-only-Lösung wirbt. Doch auch hier gibt es Überschneidungen und Grauzonen. Für weitergehende Vergleiche bieten sich der Bericht von Bloor (PDF) an.

Ein neues Paradigma

Unabhängig von der konkreten Plattform-Wahl sollte die wichtigste Erkenntnis sein, dass die Echtzeitverarbeitung ein anderes Paradigma im Umgang mit Daten erfordert. Im Laufe der Zeit erhielten Streaming-Plattformen zusätzliche Fähigkeiten wie die SQL-Unterstützung, um Entwicklern den Umgang mit Datenströmen zu vereinfachen und eine höhere Abstraktion zu bieten. Wer aber dieses Paradigma mit der darauf basierenden Kappa-Architektur meistern und davon profitieren will, der muss Zeit investieren und die erforderliche Infrastruktur aufbauen.

Die Stream-basierte Verarbeitung von Daten eröffnet Wege in der Softwareentwicklung und der Datenanalyse, um geschäftliche Bedürfnisse zu erfüllen, und es lohnt sich, echtzeitfähige Anwendungen und Werkzeuge zu entwickeln.

 (anag)


Verwandte Artikel:
Streamingdienst: Spotify-Backend läuft künftig in der Google Cloud   
(24.02.2016, https://glm.io/119361 )
Data Management: Wie Hauptspeicherdatenbanken arbeiten   
(15.10.2014, https://glm.io/109813 )
Data Artisans: Alibaba kauft Berliner Startup für 90 Millionen Euro   
(08.01.2019, https://glm.io/138587 )
Sicherheit: Libreoffice schließt Lücke, Openoffice bleibt verwundbar   
(04.02.2019, https://glm.io/139163 )
Webapplikationen: Sicherheitslücke in jQuery-Plugin wird aktiv ausgenutzt   
(23.10.2018, https://glm.io/137254 )

© 1997–2019 Golem.de, https://www.golem.de/