Big-Data-Verarbeitungs-Frameworks

Big-Data-Frameworks ermöglichen es Programmierern, Datensätze zu verarbeiten, die weit größer sind als die Kapazität einer einzelnen Maschine, indem sie Berechnungen als parallele Datenflüsse ausdrücken, die die Laufzeit verteilt und fehlertolerant gestaltet.

Definition

Ein Big-Data-Verarbeitungs-Framework ist ein System, das es einem Programmierer ermöglicht, eine Berechnung über einen sehr großen Datensatz als hochrangige Datenflussoperatoren auszudrücken, und das automatisch die Daten partitioniert, die parallele Ausführung über einen Cluster plant und Knotenausfälle toleriert.

Scope

Dieses Thema behandelt das Datenfluss-Programmiermodell für die clusterweite Datenverarbeitung: das MapReduce-Paradigma und seine Grenzen, speicherinterne Datenfluss-Engines, die auf resilienten verteilten Datensätzen basieren, sowie die vereinheitlichte Batch- und Stream-Verarbeitung mit Windowing, Ereigniszeit-Semantik und Exactly-Once-Garantien. Es wird behandelt, wie massive, möglicherweise unbegrenzte Daten partitioniert, parallel verarbeitet und nach Ausfällen wiederhergestellt werden.

Core questions

• Wie kann eine Berechnung über Daten, die zu groß für eine Maschine sind, parallel ausgedrückt und ausgeführt werden?
• Wie verbessern speicherinterne und Streaming-Engines das Batch-MapReduce?
• Wie werden Korrektheit, Latenz und Fehlertoleranz für unbegrenzte, ungeordnete Datenströme ausbalanciert?

Key theories

MapReduce

MapReduce drückt die Datenverarbeitung als einen Map-Schritt aus, der Datensätze in Schlüssel-Wert-Paare umwandelt, und einen Reduce-Schritt, der nach Schlüssel aggregiert, wobei die Laufzeit die Parallelisierung, das Daten-Shuffling und die erneute Ausführung fehlgeschlagener Aufgaben übernimmt.

Resiliente verteilte Datensätze

RDDs bieten eine fehlertolerante In-Memory-Abstraktion, deren Abstammung deterministischer Transformationen es ermöglicht, verlorene Partitionen neu zu berechnen, was iterative und interaktive Cluster-Berechnungen wesentlich schneller macht als disk-basiertes MapReduce.

Vereinheitlichter Batch- und Stream-Datenfluss

Moderne Engines behandeln Batch als Sonderfall des Streamings, indem sie Ereigniszeit-Windowing und Watermarks sowie konsistente Snapshots verwenden, um Exactly-Once-Ergebnisse über unbegrenzte, ungeordnete Daten zu liefern.

Clinical relevance

Diese Frameworks verarbeiten die Daten hinter Such-, Analyse-, Empfehlungs- und Machine-Learning-Pipelines, und Stream-Engines treiben Echtzeitüberwachungs- und ereignisgesteuerte Anwendungen an, was sie zu einer Kerninfrastruktur für datenintensive Berechnungen macht.

History

Googles MapReduce-Paper von 2004 (überarbeitet 2008) etablierte die clusterweite Datenverarbeitung; Sparks resiliente verteilte Datensätze (2012) ermöglichten schnelle speicherinterne und iterative Verarbeitung; und Systeme wie Flink und das Datenflussmodell (2015) vereinigten Batch- und Streaming-Verarbeitung mit starken Korrektheitsgarantien.

Debates

Batch versus Streaming als primäres Verarbeitungsmodell

Batch-Verarbeitung ist einfacher und leicht Exactly-Once zu gestalten, führt aber zu zusätzlicher Latenz, während Streaming geringe Latenz auf Kosten einer schwierigeren Korrektheit bei ungeordneten Daten bietet; vereinheitlichte Engines argumentieren, dass Streaming Batch subsumieren kann, obwohl Batch für große historische Aufgaben weiterhin üblich ist.

Key figures

• Jeffrey Dean
• Sanjay Ghemawat
• Matei Zaharia
• Tyler Akidau

Seminal works

• dean2008
• zaharia2012
• akidau2015

Frequently asked questions

Warum haben Spark und ähnliche Systeme das reine MapReduce für viele Workloads abgelöst?

MapReduce schreibt Zwischenergebnisse zwischen jedem Schritt auf die Festplatte, was für iterative Algorithmen langsam ist. In-Memory-Abstraktionen wie resiliente verteilte Datensätze halten Daten über Schritte hinweg im Speicher und berechnen bei Ausfall nur verlorene Partitionen neu, was zu großen Geschwindigkeitssteigerungen bei iterativen und interaktiven Analysen führt.