Auf der Suche nach der idealen Big-Data-Architektur

von am 04.09.2013
0
Die Entscheidung für eine BigData-Architekur ist immer individuell.
Die Entscheidung für eine BigData-Architekur ist immer individuell.

Hadoop, In-Memory Analytics, Analytics Appliances – das Thema Big Data ist zumindest in Fachzeitschriften Mainstream geworden und findet mittlerweile sogar Eingang in die Tagespresse. Aber nicht alle Herausforderungen mit großen Datenmengen haben die Dimensionen, wie man sie bei den Googles, Amazons, Twitters und Ebays dieser Welt meistern muss. Schon Datenmengen mit einem Volumen von “nur” “wenigen” Terabytes an neuen Daten im Monat können schwer beherrschbar sein. Herausforderungen sind auch:

  • Velocity – Anwendungen, bei denen analytische Aussagen sehr schnell getroffen werden müssen.
  • Variety – Aufgabenstellungen, bei denen die zu verarbeitenden Daten wenig strukturiert sind oder im Laufe der Zeit weitgehende Strukturänderungen zu erwarten sind.

Welche der zahlreichen Lösungsansätze, die durch die Presse gehen, sind nun für den eigenen spezifischen Bedarf geeignet? Dieser Frage gehe ich in meinem Beitrag zum Big-Data-Seminar “Willkommen im Datenrausch” nach, das nach Frankfurt und München im November auch in Hamburg und Hannover stattfinden wird.

Ausgangspunkt für den Entwurf einer Big-Data-Architektur sollten zunächst die wesentlichen Business-Fragestellungen sein, die mit Big-Data-Mechanismen  verfolgt werden sollen.

Wie sehen nun meine Anforderungen genau aus?

In einem zweiten Schritt werden die Anforderungen und Randbedingungen eingegrenzt. Zwar ist es wahrscheinlich, dass zu Beginn des Weges nicht alle Anforderungen bekannt sind und dass sie sich mit der Zeit ändern und anpassen. Zum einen entwickelt sich der Markt weiter und damit auch die relevanten Fragestellungen. Zum anderen sammelt man während der Entwicklung und Nutzung der Lösung weitere Erkenntnisse und kann sie dadurch weiterentwickeln. Außerdem kommt der Appetit bekanntlich mit dem Essen – erste wertvolle Ergebnisse führen rasch zu weiteren Fragestellungen und vermitteln tiefere Erkenntnisse über die Zusammenhänge zwischen den zur Verfügung stehenden Daten und die daraus abzuleitenden Schlussfolgerungen.

Relevante Anforderungskategorien sind sicher die klassischen Größen Volume, Velocity und Variety, aber auch das Analyseszenario: befindet man sich im Stadium der explorativen Analyse, oder hat man bereits Analysemodelle erarbeitet, die nun möglichst effizient umgesetzt werden sollen?

Wie sehen desweiteren die Vorgaben zur Datenspeicherung aus? Die Speicherung möglichst aller in Frage kommender Daten bietet die besten Möglichkeiten für spätere Analysen, verursacht aber auch Kosten und stellt für die Verarbeitung einen großen Ballast dar. Diese und weitere Anforderungen stehen nicht selten im Widerspruch zueinander. Sie müssen sich für die eine oder andere Ausrichtung entscheiden, passend zur aktuellen Fragestellung und mit der wahrscheinlichen Ausrichtung einer künftigen Weiterentwicklung im Hinterkopf.

Von den Anforderungen zur Architektur

Für die Wahl einer geeigneten Architektur bietet sich die sogenannte Lambda-Architektur als Orientierungshilfe an. Ausgehend von der Anforderung, eine Beinahe-Echtzeit-Analyse auch für große Datenmengen zu ermöglichen, schlägt die Lambda-Architektur eine inkrementelle Berechnung der Analysefunktion vor. Dabei erfolgt im sogenannten Batch Layer eine tiefe und exakte Analyse, wobei ein gewisser Zeitversatz vom Eintreffen neuer Daten bis zu ihrer exakten Berücksichtigung im Auswertungsergebnis in Kauf genommen wird. Im sogenannten Speed Layer erfolgt dagegen eine zeitnahe Analyse neuer Daten mit speziell dafür geeigneten Mechanismen aber reduzierten Anforderungen hinsichtlich Genauigkeit oder Tiefe der Analyse. Diese Beinahe-Echtzeit-Ergebnisse werden direkt mit den Batch Layer-Ergebnissen kombiniert, bevor die zugrundeliegenden Daten schließlich auch in die Auswertung des Batch Layers einfließen (“eventual accuracy”).

Die Lambda-Architektur als Rahmen zeigt die Auflösung des Trade-offs zwischen Durchsatz und Verarbeitungslatenz.

Die Lambda-Architektur – Auflösung des Trade-Offs zwischen Durchsatz und Verarbeitungslatenz

Eine Architektur – viele Lösungen

Die eigentliche Big-Data-Architektur für einen spezifischen Anwendungsfall ergibt sich nun durch die Kombination verschiedener, für den jeweiligen Bedarf geeigneter Lösungsbausteine. Dazu zählen klassische Data Warehouses als Plattform für OLAP-Verarbeitung  aber auch Ansätze, die besonders für den Umgang mit alternativen Datenkategorien und -Quellen geeignet sind und die keine strukturierte Datenspeicherung oder eventuell sogar überhaupt keine Datenspeicherung erfordern: beispielsweise die Verarbeitung mit Map/Reduce-Implementierungen aus dem Hadoop-Ökosystem, die die explorative und automatisierte Analyse großer Datenmengen im Batch-Modus unterstützen.

Einen weiteren Lösungsansatz stellen Stream Processing und Complex Event Processing (CEP) dar, die in einem Strom aus vielen Einzel-Ereignissen Mustererkennung und regelbasierte Verarbeitung sowie Filterung, Korrelation und Aggregation der Ereignisse unterstützen. Die Ergebnisse der Analyse mit Map/Reduce oder CEP fließen häufig zur weiteren Verarbeitung in klassische operative Datenbanken oder dispositive Data Warehouses ein.

Weitere Lösungsbausteine für Big-Data-Aufgabenstellungen sind

  • In Memory-Verarbeitung, die von den geringeren Zugriffs-Latenzen, der höheren Bandbreite und der besseren Vorhersagbarkeit von Hauptspeicherbausteinen im Vergleich zu Festplatten profitiert.
  • Analytics Appliances, vorgefertigten Hardware-Software-Kombinationen, die ein schnelles Setup, hohe Skalierbarkeit und durch parallele Abfragebearbeitung hohe Performance bieten, aber vergleichsweise teuer sind.

Fazit: Individuell kombinieren

Insgesamt steht für Big-Data-Problemstellungen eine Vielzahl von Produkten und Lösungen bereit, und die Herausforderung des Big Data-Architekten besteht unter anderem darin, eine passende Kombination zusammenstellen, die die jeweiligen Anforderungen effizient umsetzt.

Dabei stellt die Unternehmensarchitektur eine wichtige Randbedingung dar, insbesondere die zu unterstützenden Businessprozesse sowie die Informationsarchitektur, die Aspekte wie Informationshoheit, Datencharakteristika wie Langlebigkeit, dispositiven vs. operativen Charakter sowie die Schutzcharakteristik der Daten abbildet.

Für den iterativen Prozess mit Data Mining, Visualisierung und Automatisierung zeigt unsere Erfahrung, dass es sich auszahlt, eine auf interdisziplinärer Zusammenarbeit beruhende Vorgehensweise mit kurzen Feedbackzyklen zu etablieren, in einem Team mit Fachexperten, Analyse-Spezialisten, Visualisierungs-Spezialisten und Entwicklern. Auf diese Weise können die jeweiligen Skills am effizientesten zur Lösungsfindung kombiniert werden.

Einen Kommentar hinterlassen

Ihre E-Mail-Adresse wird weder veröffentlicht noch weitergegeben. Pflichtfelder sind mit einem * markiert.