Big Data North America 2016: Big Data à la Apache

Inhaltsverzeichnis

Neben den traditionell technischen Themen wurden viele Anwendungsszenarien präsentiert, zum Beispiel aus den Bereichen Smart Meter, Aktienmarkt, Clickstream-Analysen und Indoor Tracking. Diese Entwicklung deutet darauf hin, dass die unter der Apache Software Foundation entwickelten Projekte für viele Unternehmen mittlerweile wichtiger Bestandteil ihrer Software geworden sind. Technische Highlights waren Self-Service, asynchrone Kopplung, Apache Spark in allen Varianten, HDFS (Hadoop Distributed File System) und Apache Hadoop als Basis, Data Security, Deployment und Betrieb sowie die Zusammenarbeit von ODPi und Apache.

Self-Service – Big-Data-Services werden durch Endnutzer selbst definiert

Bei einigen Power-Usern von Big-Data-Infrastruktur hat sich gezeigt, dass der Aufwand für die Einrichtung weiterer Services relativ hoch ist, die Anwender gleichzeitig aber für unternehmenskritische Fragestellungen schnell Lösungen benötigen. Daher werden vermehrt Portale eingerichtet, in denen sich User die Services selbst "zusammenklicken" können.

Bei LinkedIn zum Beispiel wurde ein Self-Service-Portal für Apache Kafka installiert. Nach einer initialen Schema-Überprüfung lassen sich damit Queues automatisiert und schnell einrichten. Auch ein Monitoring der Queues wird direkt mit aufgesetzt: So wissen die User, wie lange Nachrichten in der Queue bleiben, und Administratoren können erkennen, welche Queue wie viel Performance braucht und welche Latenz erzeugt. Bei dem gerade geprüften System ist allerdings die Abrechnung der Services noch nicht geklärt.

Bei eBay gibt es andere Anforderungen, vor allem im Hinblick auf eine flexible Auswertung von Daten. Daher wurde ein Self-Service-Portal für Spark implementiert. Hierbei ergaben sich Herausforderungen bezüglich Skalierbarkeit, optimaler Nutzung von Hardware und Speicherverbrauch. Ausgewählte Data Scientists bei eBay können das System nutzen, und die Ausweitung ist geplant.

Asynchrone Kopplung – Trennung von Data Ingestion und Weiterverarbeitung

Asynchrone Annahme von Daten (Ingestion) und damit Queueing sind essenzielle Bestandteile vieler
großer Big-Data-Systeme. In der überwiegenden Anzahl von Fällen kommt dabei das Messaging-System Kafka zum Einsatz, das allerdings statuslos arbeitet und nicht mit Zuständen umgehen kann. Ein Vortrag aus dem Hause LinkedIn verglich daher Systeme, die das können: zum einen das eigene Samza, das den lokalen Zustand in einer RocksDB abspeichert, zum anderen Apache Flink, das einen integrierten Ansatz (Streaming, Verarbeitung, Auswertung) verfolgt, der nach Meinung von LinkedIn mit einigen Nachteilen wie schwierigerem Wiederaufsetzen abgestürzter Knoten erkauft wird.

Alternativ bietet Spark Streaming an. Die Technik war die auf der Konferenz am häufigsten genannte, besonders im Bereich Datenauswertungen, mit zahlreichen Vorträgen zu den Themen Analysen, Performance und zur Zusammenarbeit mit vielen anderen Techniken.

Die Spark-Welt dreht sich derzeit schnell weiter. So konnten etwa Holden Karau von IBM und Ion Stoica von Databricks erste Ideen für Spark 2.0 präsentieren. Bei Spark wird sich demzufolge einiges verändern beziehungsweise vereinheitlichen. Es lässt sich zukünftig offenbar noch einfacher mit SQL oder sogenannten Datasets arbeiten, vorstellbar als Mischung aus SQL und funktionaler Programmierung. Das allerdings funktioniert nur richtig elegant in Scala. Bei Java fehlen die entsprechenden Ausdrucksmöglichkeiten, weshalb es im Spark-Kontext etwas stiefmütterlich behandelt wird.

Wann genau Spark 2.0 erscheinen wird, ist noch nicht klar. Stoica vermutete ein Release in den nächsten Monaten. Mittlerweile ist schon mal eine Preview verfügbar.

Apache Hadoop und HDFS – stabiler Basisservice

Hadoop und HDFS bilden das Rückgrat fast jeder großen Big-Data-Infrastruktur. Dennoch liegt das letzte Major Release von Hadoop rund drei Jahre zurück.

Auf Mailinglisten gibt es viele Diskussionen, wie Hadoop 3 aussehen und wann es erscheinen könnte. Sicher ist, dass dabei ordentlich aufgeräumt wird: Hadoop 3 wird nur noch mit JDK 8 laufen, es wird eine richtige Classpath-Isolation geben, und endlich sollen alle Shell-Skripte neu geschrieben und dokumentiert werden. Außerdem ist man dabei, viele Konfigurationsparameter zu vereinheitlichen. Schließlich wird die Möglichkeit bestehen, mit mehr als zwei Standby NameNodes eine offenbar noch bessere Ausfallsicherheit zu erzeugen. Hadoop-Committer Akira Ajisaka erklärte außerdem, wie das Erasure Coding in Hadoop 3 funktioniert und was man davon erwarten kann.

Laut einem gemeinsamen Vortrag von LinkedIn und Intel können Nutzer des aktuellen Hadoop-Release demnächst vom Reed-Solomon-basierten Erasure Coding profitieren. Dabei werden Daten nicht mehr, wie bisher bei HDFS üblich, lediglich dreimal repliziert, sondern mittels Bitvektor-Operationen Parities berechnet. So ergeben sich bei einem Storage-Overhead-Faktor von nur noch 1,5 teilweise (in Abhängigkeit von der Anzahl der Server) sogar höhere Ausfallsicherheiten als bei klassischer Replikation. Nach Aussage der Entwickler führt das nur zu geringfügig längeren Laufzeiten, da in den meisten von ihnen untersuchten Fälle sowieso nur ein einziges Replikat in der Berechnung benötigt wurde. Ob das tatsächlich in allen Fällen zutrifft, wird die Praxis zeigen.