Der Cloud Data Lake

Kapitel 4. Skalierbare Data Lakes

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Wenn du die Art und Weise änderst, wie du die Dinge betrachtest, ändern sich auch die Dinge, die du betrachtest.

Wayne Dyer

Nach der Lektüre der ersten drei Kapitel solltest du alles haben, was du brauchst, um deine Data-Lake-Architektur in der Cloud zum Laufen zu bringen, und das zu einem vernünftigen Kostenprofil für dein Unternehmen. Theoretisch hast du auch die erste Reihe von Anwendungsfällen und Szenarien erfolgreich in der Produktion eingesetzt. Dein Data Lake ist so erfolgreich, dass die Nachfrage nach weiteren Szenarien steigt, und du bist damit beschäftigt, die Bedürfnisse deiner neuen Kunden zu erfüllen. Dein Geschäft boomt, und dein Datenbestand wächst rasant. Wie man in der Wirtschaft sagt, ist es eine andere Herausforderung, von null auf eins zu kommen als von eins auf hundert oder von hundert auf tausend. Um sicherzustellen, dass dein Design skalierbar ist und auch dann noch funktioniert, wenn deine Daten und die Anwendungsfälle wachsen, ist es wichtig, die verschiedenen Faktoren zu kennen, die die Skalierung und Leistung deines Data Lakes beeinflussen. Entgegen der landläufigen Meinung sind Skalierung und Leistung nicht immer ein Kompromiss mit den Kosten, sondern gehen sehr wohl Hand in Hand. In diesem Kapitel werden wir uns diese Überlegungen genauer ansehen und Strategien vorstellen, mit denen du deinen Data Lake für die Skalierung und gleichzeitig für die Kostenoptimierung optimieren kannst. Zur Veranschaulichung unserer Strategien werden wir wieder das fiktive Unternehmen Klodars Corporation verwenden. In Kapitel 5 werden wir auf diesen Grundlagen aufbauen und uns auf die Leistung konzentrieren.

Ein kleiner Einblick in die Skalierbarkeit

Größenordnung und Leistung sind Begriffe, die du wahrscheinlich schon oft in Produktpräsentationen und Marketingmaterialien gesehen hast. Was bedeuten sie eigentlich und warum sind sie so wichtig? Um das besser zu verstehen, sollten wir uns zunächst die Definition von Skalierbarkeit ansehen. In Kapitel 5 werden wir uns mit den Leistungsaspekten befassen.

Was ist Skalierbarkeit?

Die beste Definition von Skalierbarkeit, die ich je gefunden habe, stammt aus dem Blog von Werner Vogels. Vogels war der CTO von Amazon, das eines der größten Hyperscale-Systeme der Welt betreibt. Laut seinem Blog lautet die Definition von Skalierbarkeit wie folgt:

Ein Dienst gilt als skalierbar, wenn sich die Leistung eines Systems proportional zu den hinzugefügten Ressourcen erhöht, wenn wir die Ressourcen erhöhen. Ein immer verfügbarer Dienst gilt als skalierbar, wenn das Hinzufügen von Ressourcen zur Erleichterung der Redundanz nicht zu Leistungseinbußen führt.

Das Konzept der Skalierung ist sehr wichtig, denn wenn dein Bedarf und deine Nutzung wachsen, ist es wichtig, eine Architektur zu haben, die deinen Kunden das gleiche Erlebnis ohne Leistungseinbußen garantiert. Um das besser zu veranschaulichen, werden wir die Prinzipien der Skalierung auf etwas anwenden, mit dem wir alle etwas anfangen können: Brötchen backen.

Maßstab in unserem täglichen Leben

Nehmen wir ein Beispiel für Skalierbarkeit in Aktion. Angenommen, du brauchst insgesamt fünf Minuten, um ein Erdnussbutter-Gelee-Sandwich für das Mittagessen einzupacken, was aus folgenden Schritten besteht (siehe Abbildung 4-1):

1. Toaste zwei Stücke Brot.

2. Bestreiche eine Seite mit Erdnussbutter.

3. Verteile das Gelee auf der anderen Seite.

4. Baue das Sandwich zusammen.

5. Tüte das Sandwich ein.

Abbildung 4-1. Schritte zur Herstellung eines Erdnussbutter-Gelee-Sandwichs

Das ist doch ganz einfach und kein Problem, oder? Nehmen wir an, du willst 100 Erdnussbutter-Gelee-Sandwiches machen. Der naheliegende nächste Schritt ist, mehr Leute zur Mithilfe einzuladen. Wenn die Herstellung eines Sandwiches fünf Minuten dauert und du ein fünfköpfiges Team hast, um die 100 Sandwiches zuzubereiten, ist es naheliegend, dass du insgesamt 100 Minuten brauchst, um diese 100 Sandwiches zuzubereiten, vorausgesetzt, die Arbeit ist gleichmäßig verteilt und jede Person macht 20 Sandwiches.

Hinweis

In diesem Beispiel wird die Leistung anhand des Ergebnisses in Form einer Arbeitseinheit (ein Sandwich) und der dafür benötigten Zeit (durchschnittliche Zeit für die Herstellung eines Sandwichs) gemessen. Skalierbarkeit bedeutet, wie viel von dieser durchschnittlichen Zeit erhalten bleibt, wenn die Arbeitseinheit zunimmt.

Die Realität kann jedoch sehr unterschiedlich sein, wenn es darum geht, wie du das mit fünf Personen umsetzen willst. Schauen wir uns mal zwei Ansätze an:

End-to-End-Ausführungsansatz

Bei diesem Ansatz folgt jede Person den Schritten, um ein einzelnes Sandwich zu machen, und fährt dann fort, das nächste Sandwich zu machen, bis sie fünf Sandwiches fertig hat. Dies ist in Abbildung 4-2 dargestellt.

Abbildung 4-2. End-to-End-Ausführung

Fließbandprinzip

Bei diesem Ansatz arbeitest du arbeitsteilig, indem du die Schritte auf verschiedene Personen verteilst: Die erste Person toastet das Brot, die zweite Person trägt Erdnussbutter auf, die dritte Person trägt die Marmelade auf und so weiter, wie in Abbildung 4-3 dargestellt.

Abbildung 4-3. Fließband

Wie du wahrscheinlich schon vermutet hast, ist die Fließbandmethode effizienter als die End-to-End-Ausführung. Aber was genau macht ihn effizienter? Um das zu verstehen, müssen wir zunächst die grundlegenden Konzepte verstehen, die die Skalierung beeinflussen:

Ressourcen

Die Materialien, die für die Herstellung des Sandwiches zur Verfügung stehen - in diesem Fall das Brot, die Erdnussbutter und das Gelee - sind die offensichtlichsten Ressourcen. Der Toaster und die Messer sind weitere Ressourcen, die für die Herstellung des Sandwiches benötigt werden.

Aufgabe

Die Reihe von Schritten, die befolgt werden, um das Ergebnis zu produzieren - in diesem Fall die fünf Schritte, die für die Herstellung des Sandwichs erforderlich sind.

Arbeiterinnen und Arbeiter

Die Komponenten, die die eigentliche Arbeit verrichten - in diesem Fall die Menschen, die die Aufgabe ausführen, das Sandwich zu machen.

Ausgabe

Das Ergebnis der Arbeit, das signalisiert, dass die Arbeit abgeschlossen ist - in diesem Fall das Sandwich.

Die Arbeiter nutzen die Ressourcen, um die Aufgabe auszuführen, die den Output produziert. Wie effektiv diese zusammenkommen, beeinflusst die Leistung und Skalierbarkeit des Prozesses. Tabelle 4-1 zeigt, wie der Fließbandansatz effizienter wird als der End-to-End-Ausführungsansatz.

Tabelle 4-1. Vergleich der Ansätze

Bereich	End-to-End-Ausführungsansatz	Fließbandprinzip
Kampf um Ressourcen	Am Ende konkurrieren alle Beschäftigten um dieselben Ressourcen (Toaster, Erdnussbutter usw.).	Der Streit ist minimal, da die verschiedenen Arbeitnehmer unterschiedliche Ressourcen benötigen.
Flexibilität bei der Zuordnung von Arbeitern zu Threads	Gering - da die Beschäftigten alle Aufgaben ausführen, ist die Zuteilung für alle Aufgaben gleich.	Wenn für einige Aufgaben mehr Arbeitskräfte benötigt werden als für andere, ist ein schneller Wechsel möglich.
Auswirkungen des Hinzufügens/Entfernens von Ressourcen	Je nachdem, wo der Engpass im System liegt, macht das Hinzufügen von Ressourcen vielleicht keinen großen Unterschied. Wenn du jedoch die richtigen Ressourcen hinzufügst, kann die Ausführung beschleunigt werden. Wenn du zum Beispiel fünf Toaster anstelle eines Toasters hast, können die Arbeiter das Brot schneller toasten.	Die Flexibilität der Ressourcenzuweisung ermöglicht eine Leistungssteigerung, wenn mehr Ressourcen zur Verfügung stehen.

Beachte auch, dass bei der End-to-End-Ausführung einige Sandwiches weniger Zeit benötigen als andere. Wenn zum Beispiel fünf Personen nach dem Toaster greifen und eine Person ihn bekommt, ist dieses Sandwich schneller fertig als die anderen, die warten müssen, bis der Toaster fertig ist. Wenn du also die Leistung messen würdest, würdest du sehen, dass die Zeit für die Zubereitung eines Sandwiches am 50. Perzentil akzeptabel sein könnte, aber die Zeit am 75. und 99.

Daraus kann man schließen, dass die Fließbandmethode skalierbarer ist als die End-to-End-Ausführung der Sandwichherstellung. Während die Vorteile dieser Skalierbarkeit an einem normalen Tag nicht auffallen, wenn du zum Beispiel drei oder vier Sandwiches verpackst, wird der Unterschied erst richtig sichtbar, wenn die zu erledigende Arbeit drastisch zunimmt, zum Beispiel wenn du 3.000 oder 4.000 Sandwiches machst.

Skalierbarkeit in Data Lake Architekturen

Wie wir in den vorangegangenen Kapiteln gesehen haben ( ), stehen uns in Data Lake-Architekturen Ressourcen aus der Cloud zur Verfügung: Rechen-, Speicher- und Netzwerkressourcen. Darüber hinaus gibt es zwei Schlüsselfaktoren, die wir besitzen und kontrollieren können, um die uns zur Verfügung stehenden Ressourcen bestmöglich zu nutzen: den Verarbeitungsauftrag, d.h. den Code, den wir schreiben, und die Daten selbst, d.h. die Art und Weise, wie wir sie für die Verarbeitung speichern und organisieren können. Dies wird in Abbildung 4-4 veranschaulicht.

Abbildung 4-4. Ressourcen des Data Lake

Die wichtigsten Ressourcen, die uns in einer Cloud Data Lake-Architektur zur Verfügung stehen, sind die folgenden:

Rechenressource

Die Rechenressourcen, die dir aus der Cloud zur Verfügung stehen, sind in erster Linie CPU-Kerne und Speicher für deine Datenverarbeitung. Außerdem läuft auf diesen Kernen Software, vor allem die Software, die du im Falle von IaaS installierst, und die Software, die dir im Falle von PaaS und SaaS zur Verfügung steht, um die Nutzung der CPU- und Speicherressourcen zu manipulieren und zu optimieren. Um eine skalierbare Lösung aufzubauen, ist es wichtig zu verstehen, wie das funktioniert. Cloud-Provider bieten Funktionen wie Autoscaling an, d.h. wenn der Rechenbedarf deiner Lösung steigt, können deine Cloud-Services automatisch mehr Rechenleistung hinzufügen, ohne dass du die Ressourcen verwalten musst. Darüber hinaus gibt es serverlose Komponenten wie Googles BigQuery, die die Aspekte der Rechenleistung und Speicherung vollständig vom Nutzer abstrahieren, so dass sich der Nutzer ausschließlich auf seine Kerngeschäftsszenarien konzentrieren kann. Serverlose Komponenten sind in der Regel teurer als abstimmbare IaaS, bieten aber integrierte Optimierungen und Einstellungen, mit denen du dich auf deine Kernszenarien konzentrieren kannst.

Ressourcen für die Vernetzung

Stell dir deine Netzwerkressourcen als ein metaphorisches Kabel vor, das Daten hin- und herschicken kann. Dies wird auf der Netzwerkhardware implementiert oder, in anderen Fällen, als softwaredefiniertes Netzwerk.

Ressourcen für die Speicherung

Cloud-Data-Lake-Speichersysteme bieten ein elastisches, verteiltes Speichersystem, das dir Platz zum Speichern von Daten bietet (auf Festplatten, Flash-Speicher und Bandlaufwerken, je nachdem, mit welcher Datenebene du arbeitest), zusammen mit Rechenleistung zur Durchführung von Speichertransaktionen und Netzwerkleistung zur Übertragung von Daten über die Leitung zu anderen Ressourcen innerhalb und außerhalb deines Cloud-Providers.

Dies sind die wichtigsten Teile, die du kontrollierst:

• Der Code, den du schreibst

• Die Art und Weise, wie deine Daten gespeichert und organisiert sind, was einen großen Einfluss darauf hat, wie effektiv die Ressourcen genutzt werden

• Wie skalierbar und leistungsfähig deine Lösung ist

Im nächsten Abschnitt werfen wir einen genaueren Blick darauf, wie die Big Data-Verarbeitung in einer Data-Lake-Architektur funktioniert und welche Faktoren die Skalierbarkeit und Leistung deiner Data-Lake-Lösung beeinflussen.

Die Faktoren zu verstehen und zu lernen, die zur Skalierung des Systems beitragen, ist aus zwei Gründen wichtig:

• Die Datenverkehrsmuster im Data Lake sind in den meisten Fällen sehr variabel und sprunghaft, so dass die Skalierung nach oben und unten eine Schlüsselfunktion ist, die in deiner Data-Lake-Architektur berücksichtigt werden muss.

• Wenn du die Engpässe kennst, weißt du, welche Ressourcen auf- oder abgebaut werden müssen. Andernfalls läufst du Gefahr, die falschen Ressourcen hinzuzufügen, ohne die Skalierbarkeit der Lösung zu verbessern.

Warum muss ich mir Sorgen um die Skalierbarkeit machen? Meine Lösung läuft heute einwandfrei.

Apropos 10-faches Wachstum: Ich erlebe oft, dass Kunden den Wert und die Möglichkeiten unterschätzen, die eine Data-Lake-Architektur freisetzen kann, und ihre Zeit und ihre Bemühungen auf die kurzfristigen Maximalwerte optimieren. Wenn du an diese Aussagen denkst - "Ich muss jetzt nur mein Data Warehouse verlagern; andere Daten sind noch nicht wichtig" oder "Meine erste Priorität ist es, alles, was wir tun, in die Cloud zu verlagern; um den Rest kümmere ich mich später" oder "Ich habe einen Zeitrahmen von einem Jahr, um meine Daten in die Cloud zu verlagern; ich kann es mir nicht leisten, über etwas anderes als meine aktuellen Arbeitslasten nachzudenken" - dann lass mich dir ein paar Dinge versichern:

• Wie bei jeder Softwareentwicklung hilft es dir, an zukünftige Szenarien zu denken, um zu vermeiden, dass du deine Lösungen komplett umgestalten musst, wenn neue Szenarien aktiviert werden.

• Dein Design zukunftssicher zu machen, ist nicht so schwer, wie du denkst. Es geht mehr um Fleiß als um Anstrengung, was dir zum Erfolg verhelfen wird.

• Laut einer Studie des Weltwirtschaftsforums wird erwartet, dass die digitale Transformation die Weltwirtschaft bis 2025 um 100 Billionen Dollar wachsen lässt, wobei mindestens zwei Drittel dieses Wachstums durch plattformbasierte Interaktionen erzielt werden. Es ist nur eine Frage der Zeit, bis sich diese Szenarien entfalten.

Interna von Data Lake Verarbeitungssystemen

Wie in Abbildung 4-4 zu sehen ist, sind die wichtigsten Vorgänge bei der Verarbeitung von Big Data die folgenden:

Ingest

Rohdaten aus verschiedenen Quellen in eine Data Lake Speicherung bringen

Vorbereitung

Aufbereitung der Rohdaten, um angereicherte Daten zu generieren, indem bei Bedarf ein Schema angewendet, fehlerhafte Daten entfernt oder korrigiert und Datenformate optimiert werden

Kuratieren

Generierung von kuratierten Daten mit hoher Wertdichte durch Aggregation, Filterung und andere Verarbeitungen von angereicherten Daten

Verzehre

Die Nutzung deiner Daten durch Dashboards, Abfragen oder datenwissenschaftliche Untersuchungen, um nur einige zu nennen, und die Verwendung dieser Erkenntnisse, um das Verhalten deiner Anwendung zu ändern, was ebenfalls unter die Nutzung fällt

In diesem Kapitel konzentrieren wir uns auf den häufigsten Anwendungsfall des Big Data Lake, nämlich die Batch-Verarbeitung. Bei der Stapelverarbeitung werden die Daten in regelmäßigen Abständen über Datenkopien in den Data Lake eingespeist. Diese Rohdaten werden aufbereitet und angereichert und dann mit ELT/ETL-Verarbeitungsmaschinen weiter kuratiert. Apache Spark und Apache Hadoop sind die gebräuchlichsten Verarbeitungssysteme für die Vorbereitungs- und Aufbereitungsphase. Diese Spark-Aufträge werden zeitgesteuert ausgeführt, nachdem die Dateneingabe oder -kopie abgeschlossen ist.

Es gibt auch andere Anwendungsfälle, wie Echtzeitverarbeitungs-Engines, bei denen Daten kontinuierlich in den Data Lake eingespeist und weiter aufbereitet und kuratiert werden. Die Skalierungsprinzipien, die wir bei der Batch-Verarbeitung erörtern, gelten zwar weitgehend auch für Echtzeit-Verarbeitungspipelines, aber aufgrund der kontinuierlichen Verarbeitung gibt es zusätzliche Einschränkungen für das Design. Wir werden in diesem Buch nicht näher auf die nicht stapelverarbeitenden Systeme eingehen, da die häufigsten Anwendungsfälle mit der Stapelverarbeitung zu tun haben. In diesem Kapitel werden wir auch nicht tiefer in die Anwendungsfälle für BI-Abfragen und Data Science eintauchen. Es gibt zahlreiche Ressourcen zu Abfragemustern und Data Science.

Wir werden uns die beiden spezifischen Aspekte der Big Data-Verarbeitung ansehen, die einzigartig für die Cloud Data Lake-Architektur sind:

Daten kopieren

Dabei werden die Daten unverändert von einem System in ein anderes verschoben, z. B. durch das Einlesen von Daten aus externen Quellen in den Data Lake und das Kopieren von Daten von einem Speichersystem in ein anderes innerhalb des Cloud-Dienstes, wie z. B. das Laden von Daten aus einem Data Lake in ein Data Warehouse. Dies ist die gängigste Form des Ingestion, die in Big-Data-Verarbeitungssystemen verwendet wird.

ETL/ELT-Verarbeitung

Dies beinhaltet einen Eingabe- und einen Ausgabedatensatz, wobei die Eingabedaten gelesen und durch Filterung, Aggregation und andere Operationen umgewandelt werden, um die Ausgabedatensätze zu erzeugen. Die Erzeugung von Daten in den angereicherten und kuratierten Datensätzen fällt in diese Kategorie. Hadoop und Spark sind die beliebtesten Verarbeitungsmaschinen, wobei Spark hier führend ist, da es Batch-, Echtzeit- und Streaming-Operationen mit derselben Architektur unterstützt. Dies sind die gängigsten Arten der Datenvorbereitung und Datenkuratierung bei der Big Data-Verarbeitung.

Interna der Datenkopie

Es gibt viele Möglichkeiten, Daten zu kopieren. Cloud-Provider und ISVs bieten PaaS an, die Daten auf optimierte Weise von einem System in ein anderes kopieren. Du kannst auch Tools und Software Development Kits (SDKs) nutzen, um Daten zu kopieren, z. B. über das Portal des Cloud-Providers, um Daten hoch- oder herunterzuladen. In diesem Abschnitt werden wir uns die Interna eines Kopierauftrags ansehen, bei dem Daten von einer Quelle gelesen und als solche in das Ziel kopiert werden. Bitte beachte, dass du dieses einfache Szenario zum Kopieren von Daten in der Praxis auch auf fortgeschrittenere Themen ausweiten kannst, z. B. das Kopieren eines sich ständig ändernden Datensatzes oder das regelmäßige Bereinigen von Datensätzen, um gesetzliche Anforderungen wie GDPR zu erfüllen. Um die Skalierbarkeit zu verstehen, werden wir uns auf den einfachen Kopiervorgang konzentrieren.

Komponenten einer Datenkopierlösung

Die sehr vereinfachten Komponenten, die an der Datenkopie beteiligt sind, werden in Abbildung 4-5 dargestellt.

Abbildung 4-5. Interna der Datenkopie

Das Datenkopierwerkzeug hat zwei Hauptkomponenten in vereinfachter Form:

Datenkopie-Orchestrator

Er kennt die zu erledigende Arbeit (z. B. wie viele Dateien von der Quelle kopiert werden müssen) und nutzt die verfügbaren Rechenressourcen, um den Kopierauftrag auf verschiedene Worker zu verteilen. Der Orchestrator behält auch den Status des Kopierauftrags selbst bei, d. h. er weiß, welche Daten bereits kopiert wurden und welche noch nicht.

Datenkopierer

Recheneinheiten, die Arbeit vom Orchestrator annehmen und die Kopiervorgänge von der Quelle zum Ziel durchführen.

Es gibt eine Konfiguration, die die Anzahl der Datenkopierer festlegt, die du für den Kopierauftrag bereitstellen kannst. Dies ist ein Regler, den du nach oben oder unten drehen kannst, um die Anzahl der Arbeiter zu konfigurieren, die du brauchst, entweder direkt, indem du die maximale Anzahl der Arbeiter festlegst, oder indem du einen Proxy-Wert angibst, den der Datenkopie-Orchestrator als konfigurierbaren Wert definiert hat.

Die Ressourcenauslastung eines Datenkopierauftrags verstehen

Die Engpässe, die die Skalierbarkeit und Leistung deiner Datenkopie beeinträchtigen, sind folgende:

Die Anzahl und Größe der Dateien/Objekte, die kopiert werden müssen

Die Granularität des Datenkopierauftrags liegt auf der Datei-/Objektebene in deinem Speichersystem. Eine große Datei kann in Stücke zerlegt werden, um eine parallele Kopie zu erstellen, aber du kannst nicht mehrere Dateien in einem einzigen Kopierauftrag zusammenfassen. Wenn du viele kleine Dateien zu kopieren hast, musst du damit rechnen, dass dies sehr lange dauert, weil der Auflistungsvorgang für den Operator länger dauern könnte und die kleinen Dateien dazu führen, dass in einer einzelnen Kopierarbeitseinheit nur eine geringe Datenmenge übertragen wird, wodurch deine verfügbare Bandbreitenressource nicht optimal genutzt wird.

Berechne die Kapazität deines Datenkopierers

Wenn du dein Datenkopierprogramm so konfigurierst, dass es über genügend Rechenressourcen verfügt, kannst du mehr Worker starten und effektiv viele Kopiervorgänge gleichzeitig durchführen. Wenn du hingegen nicht genügend Rechenressourcen hast, wird die Anzahl der verfügbaren Worker zu einem Engpass in deinem System.

Verfügbare Netzwerkkapazität für die Kopie

Die Höhe der Netzwerkkapazität steuert die Pipe, die für die Datenübertragung verwendet wird, insbesondere für das Kopieren von Daten über die Cloud-Grenze. Stelle sicher, dass du über ein Netzwerk mit hoher Bandbreite verfügst. Wenn du Daten zwischen Cloud-Diensten desselben Anbieters kopierst oder überträgst, musst du dein Netzwerk nicht bereitstellen oder nutzen; die Cloud-Dienste verfügen über ein eigenes Netzwerk, um dies zu bewerkstelligen.

Regionsübergreifende Datenkopie

Wenn du Datenkopien über Regionen hinweg erstellst, müssen sie eine längere Strecke über das Netzwerk zurücklegen, wodurch die Datenkopie viel langsamer wird und in manchen Fällen sogar eine Zeitüberschreitung auftreten kann, was dazu führt, dass die Aufträge fehlschlagen.

ELT/ETL-Verarbeitung Interna

Wenn du eine Auffrischung brauchst, wie Big Data Analytics Engines funktionieren, empfehle ich dir, "Big Data Analytics Engines" noch einmal zu lesen , insbesondere den Abschnitt über Spark in "Apache Spark".

ELT/ETL-Prozesse arbeiten in erster Linie mit unstrukturierten, strukturierten oder semistrukturierten Daten, wenden bei Bedarf ein Schema an und transformieren diese Daten durch Filterung, Aggregation und andere Verarbeitungen, um strukturierte Daten in einem Tabellenformat zu erzeugen. Apache Hadoop und Apache Spark sind die gängigsten Verarbeitungsmaschinen, die in diese Kategorie fallen. In diesem Abschnitt werden wir einen genaueren Blick auf das Innenleben von Apache Spark werfen, aber die Konzepte gelten weitgehend auch für Apache Hadoop, wenn auch mit feinen Nuancen. Apache Hadoop kann zwar in der Cloud betrieben werden, wurde aber für den Betrieb in den Räumlichkeiten auf HDFS entwickelt. Apache Spark ist viel näher an der Cloud-Architektur. Außerdem ist Apache Spark aufgrund seiner Konsistenz bei Batch-, Streaming- und interaktiven Datenpipelines die de facto-Verarbeitungs-Engine, weshalb wir uns in diesem Abschnitt auf Spark konzentrieren werden.

Du würdest einen Apache Spark-Auftrag in einem Cluster ausführen, den du auf folgende Weise erstellen kannst:

• Stelle IaaS Rechenressourcen bereit und installiere die Apache Spark-Distribution, entweder von Open Source Apache Spark oder von einem ISV wie Cloudera.

• Bei Anbietern wie Databricks oder Cloud-Providern wie Amazon EMR oder Azure Synapse Analytics erhältst du einen Cluster, auf dem Spark bereits installiert ist und den du sofort nutzen kannst.

Apache Spark nutzt eine verteilte Rechenarchitektur ( ), bei der es einen zentralen Controller/Koordinator, auch Treiber genannt, gibt, der die Ausführung orchestriert, und mehrere Executors oder Worker Units, die eine bestimmte Aufgabe ausführen, die zur Anwendung beiträgt. In Analogie zum Hausbau kannst du dir den Apache Spark-Treiber als Generalunternehmer und die Executors als Facharbeiter wie Klempner und Elektriker vorstellen. Wir werden nun einige wichtige Konzepte erläutern, die für Apache Spark grundlegend sind.

Komponenten einer Apache Spark-Anwendung

Datenentwickler schreiben Spark-Code und übermitteln diesen Code an einen Spark-Cluster, um dann die Ergebnisse zurückzubekommen, wenn die Ausführung abgeschlossen ist. Hinter dem Bildschirm wird der Nutzercode als Spark-Anwendung ausgeführt und ist in die folgenden Komponenten unterteilt:

Treiber

Der Treiber ist der zentrale Koordinator des Spark-Prozesses und ist die einzige Komponente, die den Benutzercode versteht. Der Treiber hat zwei Hauptkomponenten: Er definiert die Aufteilung der Aufträge, Aufgaben und Executors, die für die Ausführung des Programms benötigt werden, und koordiniert die Zuweisung dieser in die verschiedenen verfügbaren Teile des Spark-Clusters. Der Clustermanager hilft dem Treiber, die Ressourcen zu finden.

Vollstrecker

Die Executors sind die Komponenten, die die Berechnungen tatsächlich durchführen. Der Treiber kommuniziert den Code und den Datensatz, den der Executor bearbeiten muss.

Aufträge, Etappen und Aufgaben

Eine Apache Spark-Anwendung wird intern in einen Ausführungsplan innerhalb deines Spark-Clusters übersetzt. Dieser Ausführungsplan wird als gerichteter azyklischer Graph (DAG) mit einer Reihe von Knoten dargestellt, die Aufträge darstellen, die wiederum aus Phasen bestehen, die voneinander abhängig sein können. Diese Phasen werden dann in Tasks unterteilt, die die eigentlichen Ausführungseinheiten darstellen, in denen die Arbeit erledigt wird. Dies wird in Abbildung 4-6 dargestellt. Die Anzahl der Executors, die einer Aufgabe zugewiesen werden, hängt von der Menge der Daten ab, die verarbeitet werden müssen.

Abbildung 4-6. Interna von Spark-Aufträgen

Die Ressourcenauslastung eines Spark-Auftrags verstehen

Wie du sehen kannst, tragen zwei Faktoren zur Ressourcenauslastung eines Spark-Codes bei:

Der Code

Die Komplexität der auszuführenden Operationen

Die Daten

Die Menge und Organisation der Daten, die ausgewertet werden müssen

Diese Engpässe beeinträchtigen die Skalierbarkeit deiner Datenkopie:

Cluster-Formfaktor und Speicher

Die Menge an Rechen- und Arbeitsspeicher, die du für deinen Spark-Auftrag bereitstellst, hat einen großen Einfluss auf die Leistung des Auftrags. Wenn du eine rechenintensive Anwendung mit vielen Datenumwandlungen hast, würde eine Erhöhung der Anzahl der Rechenkerne für mehr Executors sorgen, um die Aufgaben zu erledigen, was zu einer allgemeinen Verbesserung des Auftrags führt. Ähnlich verhält es sich bei komplexen Transformationen: Wenn du mehr Speicher zur Verfügung hast, können die temporären Datensätze (RDDs) im Speicher persistiert werden, wodurch die Abrufzeiten aus langsameren persistenten Speicherlösungen wie dem Objektspeicher minimiert werden. Die Anbieter von Apache Spark bieten auch Caches an, die dabei helfen, häufig verwendete Datensätze im Speicher zu speichern.

Die Anzahl und Größe der Dateien/Objekte, die bearbeitet werden müssen

Die Granularität der Auftragsausführung liegt auf der Datei-/Objektebene in deinem Speichersystem. Ähnlich wie beim Auftrag zum Kopieren von Daten kannst du bei vielen kleinen Dateien, die gelesen werden müssen, um deinen Apache Spark-Auftrag auszuführen, damit rechnen, dass dies sehr lange dauert, weil die Listing-Operation beim Treiber länger dauert und der Overhead beim Lesen einer Datei (d. h. die Zugriffsprüfung und andere Metadaten) nur einen geringen Ertrag in Bezug auf die tatsächlich gelesenen oder geschriebenen Daten bringt. Wenn du hingegen die Anzahl der Spark-Executors erhöhst, kannst du die Schreibvorgänge viel schneller parallelisieren und die Aufgabe schneller erledigen. Das ist ein gesunder Konflikt, denn während die Schreibvorgänge teurer sind und durch das Schreiben vieler kleiner Dateien optimiert werden können, werden die nachfolgenden Lesevorgänge teuer. Um diese nachgelagerten Auswirkungen zu minimieren, bietet Apache Spark Verdichtungsprogramme, mit denen diese kleinen Dateien nach Abschluss des Auftrags zu einer großen Datei zusammengefasst werden können.

Datenorganisation

Die Verarbeitung in Apache Spark beinhaltet im Wesentlichen viele Filterungen oder selektive Datenabfragen für Lesevorgänge. Wenn du deine Daten so organisierst, dass sie schneller abgerufen werden können, kann das einen großen Unterschied in deiner Arbeitsleistung ausmachen. Spaltenförmige Datenformate wie Parquet bieten hier einen großen Vorteil; wir werden uns das im nächsten Abschnitt genauer ansehen. Darüber hinaus hilft eine effektive Partitionierung deiner Daten, so dass Dateien/Objekte mit ähnlichem Inhalt zusammen organisiert werden, bei der Optimierung für einen schnellen Zugriff, wodurch weniger Rechenressourcen benötigt werden und somit die Skalierbarkeit deiner Lösung verbessert wird.

Netzwerkkapazität und regionale Grenzen

Wie beim Szenario der Datenkopie wirken sich die Netzwerkkapazität und die regionsübergreifenden Grenzen stark auf deine Leistung und Skalierbarkeit aus.

Ein Hinweis auf andere interaktive Abfragen

Apache Spark ist eine Open-Source-Technologie die sich weitgehend auf Batch-, interaktive und Echtzeit-Interaktionen mit dem Data Lake konzentriert. Cloud Data Warehouses bieten andere interaktive Abfragetechnologien, die für bestimmte Datenformate optimiert sind. Diese Formate sind proprietär, und sowohl die Rechen- als auch die Speichersysteme sind für diese Formate optimiert. In diesem Buch gehen wir nicht näher auf sie ein. Sie folgen jedoch konzeptionell auf hohem Niveau dem Modell der Spark-Interna.

Überlegungen zu skalierbaren Data Lake Lösungen

Ich möchte mit einem großen Disclaimer beginnen: gibt es keinen 12-Schritte-Prozess, den du bis ins kleinste Detail befolgen kannst, um deinen Data Lake leistungsfähig, zuverlässig oder skalierbar zu machen. Es gibt jedoch einige Faktoren, die zur Skalierbarkeit und Leistung deiner Lösung beitragen und auf die du dich verlassen kannst, um eine robuste Implementierung deines Data Lakes zu erreichen. Betrachte diese Faktoren als Stellschrauben, an denen du drehen kannst, um zu verstehen, was genau deine optimale Leistung ausmacht.

Wenn du über historische Daten aus den vergangenen Jahren oder von deiner analogen On-Premises-Implementierung verfügst, kannst du diese als Anhaltspunkt für deine Spitzenwerte verwenden. Aber keine Sorge, wenn diese Daten nicht zur Verfügung stehen - du kannst auch einen skalierten PoC durchführen, d.h. eine Kopie deines Workloads in einer simulierten Umgebung, um die verschiedenen Faktoren zu verstehen, die sich auf deine Leistung auswirken, damit du sehen kannst, wie sie sich mit zunehmender Last auf deinem System erhöhen. Nimm deinen komplexesten Auftrag oder deinen größten Datensatz, um deinen PoC auf dem Data Lake laufen zu lassen, und verdopple die Komplexität oder den Datenumfang oder beides, um die Auswirkungen auf deine Ressourcen zu analysieren.

In diesem Abschnitt gehen wir auf einige der wichtigsten Faktoren ein, die die Größe und Leistung deines Systems beeinflussen.

Wähle die richtigen Cloud-Angebote

Wie wir in den vorangegangenen Abschnitten dieses Kapitels gesehen haben, hast du eine große Auswahl an Cloud-Angeboten, wenn es um deine Big-Data-Lösungen geht. Du kannst entscheiden, ob du deine Big-Data-Lösung mit IaaS, PaaS oder SaaS entweder bei einem Cloud-Provider, bei mehreren Cloud-Providern (Multicloud-Lösung) oder mit einer Mischung aus On-Premises- und Cloud-Umgebungen (Hybrid-Cloud-Lösung) und in einer oder mehreren Regionen betreiben willst. Werfen wir einen Blick darauf, wie sich einige dieser Optionen auf die Gesamtleistung und Skalierbarkeit deiner Lösung auswirken.

Hybride und Multicloud-Lösungen

Die meisten Unternehmen nutzen heute einen Multicloud-Ansatz, bei dem sie in Architekturen investieren, die zwei oder mehr Cloud-Provider umfassen. Die meisten Unternehmen haben auch hybride Cloud-Architekturen, bei denen sie sowohl in private Clouds und lokale Systeme als auch in öffentliche Cloud-Provider investieren.

Es gibt viele Gründe, die für eine Multi-Cloud- oder Hybrid-Cloud-Architektur sprechen:

• Phasenweise Migration einer On-Premises-Plattform in die Cloud

• Nutzung der Cloud für neuere Szenarien und Rückführung der Erkenntnisse auf die alte Plattform vor Ort aus Gründen der Abwärtskompatibilität

• Minimierung der Bindung an einen einzigen Cloud-Provider, d.h. nicht alles auf eine Karte zu setzen

• Fusionen und Übernahmen, bei denen verschiedene Teile des Unternehmens ihre Infrastruktur in unterschiedlichen Clouds betreiben

• Spezifische Anforderungen wie Datenschutz oder Compliance, die erfordern, dass ein Teil der Datenbestände vor Ort und nicht in der Cloud bleibt

• Data-Mesh-Architektur, bei der Teams oder Geschäftsbereiche innerhalb der Organisation die Cloud-Provider flexibel auswählen können

Eine Multicloud-Architektur hat auch Vorteile:

• Flexible Wahlmöglichkeiten für die Geschäftsbereiche

• Geringere Kosten - einigeDienste können bei einem Cloud-Dienst günstiger sein als bei anderen

Wenn es jedoch um Leistung und Skalierung sowie um die Kosten der Lösung geht, gibt es einige Fallen, in die du bei einer Multi-Cloud- oder Hybrid-Cloud-Architektur tappen kannst:

• Die Betriebskosten für die Verwaltung mehrerer Clouds könnten ein zusätzlicher Aufwand oder versteckte Kosten sein, die du vielleicht übersehen hast. Du könntest mehrere Softwareanwendungen für die Cloud-Verwaltung nutzen, was deine Kosten in die Höhe treiben könnte.

• Das Verschieben von Daten aus der Cloud ist in Bezug auf die Leistungnicht optimal und außerdem teuer. Wenn du ein Szenario hast, in dem du Daten zwischen verschiedenen Cloud-Lösungen hin- und herschiebst, würde das die Gesamtleistung und damit die Skalierbarkeit der Lösung beeinträchtigen.

• Auch wenn die grundlegenden Konzepte bei den Diensten verschiedener Cloud-Provider ähnlich sind, so sind doch umfassende Kenntnisse über die Feinheiten und bewährten Methoden für die Umsetzung erforderlich. Ein Mangel an diesen Kenntnissen könnte dazu führen, dass du keine optimale Lösung für alle deine Umgebungen hast.

• Wenn du Szenarien hast, in denen du sichere Direktverbindungen mit niedriger Latenz zur Cloud benötigst, musst du spezielle Funktionen wie ExpressRoute von Azure oder AWS Direct Connect bereitstellen. Du müsstest mehrere Lösungen bereitstellen, um Daten von deinen lokalen Systemen zu übertragen, was sowohl deine Kosten als auch deine Datentransfers erhöhen würde.

Wenn du eine Hybrid- oder Multi-Cloud-Lösung brauchst, solltest du auf die Datenübertragungen achten und idealerweise sicherstellen, dass die Datenübertragungen zwischen diesen verschiedenen Umgebungen minimal und sorgfältig durchdacht sind.

IaaS versus PaaS versus SaaS-Lösungen

Deine Big Data-Lösung kann aus einer Mischung von IaaS-, PaaS- und SaaS-Lösungen bestehen. Hier sind die Unterschiede zwischen den Optionen für ein Szenario zum Betrieb eines Spark-Notebooks für deine Datenwissenschaftler:

IaaS-Lösung

Bei dieser Lösung stellst du zunächst Ressourcen für virtuelle Maschinen (VM) beim Cloud-Provider bereit, installierst dann die Software-Distribution - entweder von der Open Source Apache Foundation oder von einem ISV wie Cloudera - und aktivierst den Notebook-Zugang für deine Datenwissenschaftler. Du hast die durchgängige Kontrolle über die Lösung, brauchst aber auch die entsprechenden Fähigkeiten, um die Leistung und Skalierung zu optimieren. Unternehmen verfolgen diesen Ansatz in der Regel dann, wenn sie über Ingenieure verfügen, die die Open-Source-Software auf ihre Bedürfnisse abstimmen können, indem sie darauf aufbauen, und wenn sie ihre eigene Version der Open-Source-Tools wie Apache Hadoop oder Apache Spark haben.

PaaS-Lösung

Bei dieser Lösung stellst du die Cluster bei dem Cloud-Provider bereit, der dir die richtige Softwareumgebung bietet (und auch die Updates verwaltet). Du kannst die benötigten Ressourcen in Bezug auf CPU, Arbeitsspeicher und Speicherung festlegen, ohne die Funktionsweise von Big-Data-Verarbeitungsmaschinen verstehen zu müssen. Die meisten Unternehmen verfolgen diesen Ansatz.

SaaS-Lösung

Bei dieser Lösung abonnierst du eine SaaS-Lösung, z. B. ein Data Warehouse und einen Notebook-Dienst, verbindest sie und kannst sie sofort nutzen. Diese Lösung eignet sich zwar hervorragend für den Einstieg, aber die Skalierbarkeit und Leistung wird durch die Skalierbarkeit der SaaS-Lösung selbst begrenzt. SaaS-Lösungen werden immer besser. Deshalb musst du dir darüber im Klaren sein, wie stark du skalieren musst, und dies mit dem SaaS-Anbieter abklären und durch einen PoC bestätigen.

Die Übersicht in Tabelle 4-2 hilft dir, die beste Wahl zu treffen.

Tabelle 4-2. Vergleich von IaaS-, PaaS- und SaaS-Lösungen

Art der Dienstleistung	Erste Schritte	Flexibilität bei der Anpassung der Lösung	Kontrolle über Ressourcen
IaaS	Hoher Aufwand: Software, Updates usw. müssen verwaltet werden.	Hohe Flexibilität: Du besitzt den Software-Stack	Hohe Kontrolle: Du hast die Kontrolle über die Details der Infrastruktur des Dienstes
PaaS	Hoher Aufwand: geringer als IaaS	Mittlere Flexibilität: soweit der PaaS-Dienstleister die Kontrollen offenlegt	Mittlere Kontrolle: höher als bei IaaS-Lösungen; niedriger als bei SaaS-Lösungen
SaaS	Geringer Aufwand: Du kannst fast sofort mit deinem Geschäftsproblem loslegen	Geringe Flexibilität: Benutzerfreundlichkeit kommt von begrenzter Flexibilität; nutze Erweiterungsmodelle, um auf der SaaS aufzubauen	Geringe Kontrolle: SaaS-Lösungen sind in der Regel mandantenfähig (Ressourcen werden von verschiedenen Kunden gemeinsam genutzt), und die Details auf Ressourcenebene sind für den Kunden nicht sichtbar.

Cloud-Angebote für Klodars Corporation

Die Klodars Corporation plante die Implementierung von als hybride Lösung, bei der die Legacy-Komponente vor Ort und die Datenanalyse-Komponenten in der Cloud ausgeführt werden. Das Unternehmen entschied sich für eine PaaS-Lösung für den Big Data-Cluster und die Speicherung im Data Lake, auf der Apache Spark läuft, und nutzte eine SaaS-Lösung für das Data Warehouse und die Dashboarding-Komponente. Klodars wusste, wie sich die Netzwerkressourcen zwischen seiner On-Premises-Lösung und dem Cloud-Provider auf die Leistung seiner Lösung auswirken und plante mit dem Cloud-Provider die richtige Kapazität ein. Außerdem führte Klodars einen PoC der Datenverarbeitungslast eines seiner daten- und rechenintensiven Szenarien - Produktempfehlungen und Umsatzprognosen - durch und stellte sicher, dass es einen Big Data-Cluster mit den richtigen Ressourcen ausgewählt hatte.

Klodars segmentierte auch seine Cluster - einen für Vertriebsszenarien, einen für Marketingszenarien und einen für Produktszenarien - um sicherzustellen, dass eine Spitzenauslastung in einem Cluster nicht die Leistung der anderen beeinträchtigte. Um die gemeinsame Nutzung von Daten und Erkenntnissen zu fördern, hatten die Data Scientists für ihre explorativen Analysen Zugang zu allen Daten aus Produkt, Vertrieb und Marketing. Klodars richtete jedoch auch separate Cluster für die Datenwissenschaftler ein und legte ein Limit für die Ressourcen fest, damit es keine ungewollten Aufträge gab, die Ressourcen in Anspruch nehmen konnten. Einen Überblick über diese Implementierung findest du in Abbildung 4-7.

Abbildung 4-7. Implementierung des Data Lake bei Klodars Corporation

Planen für Spitzenkapazitäten

Unabhängig davon, für welche Art von Lösung du dich entscheidest, sind die Kapazitätsplanung und das Verständnis für den Erwerb zusätzlicher Kapazitäten bei zusätzlichem Bedarf der Schlüssel zu einer Cloud Data Lake-Lösung. Bei der Kapazitätsplanung geht es darum, den Bedarf im Laufe der Zeit vorherzusagen, sicherzustellen, dass du mit den richtigen Ressourcen ausgestattet bist, um den Bedarf zu decken, und die richtigen Geschäftsentscheidungen zu treffen, wenn dies nicht der Fall ist.

Der allererste Schritt besteht darin, die Nachfrage zu prognostizieren. Dies kann auf folgende Weise geschehen:

• Verstehe deinen Geschäftsbedarf und die SLAs, die du deinen Kunden anbieten musst. Wenn zum Beispiel der letzte Datenstapel um 22 Uhr eintrifft und du deinen Kunden versprichst, dass sie bis 8 Uhr morgens ein aktualisiertes Dashboard sehen, dann hast du ein Zeitfenster von 10 Stunden, um deine Daten zu verarbeiten, oder vielleicht 8 Stunden, wenn du einen Puffer lassen möchtest.

• Verstehe deine Ressourcenauslastung in der Cloud. Die meisten Cloud-Provider bieten Überwachungs- und Beobachtungslösungen an, die du nutzen kannst, um zu verstehen, wie viele Ressourcen du nutzt. Wenn du zum Beispiel einen Cluster mit 4 virtuellen CPUs (vCPUs) und 1 GB Arbeitsspeicher hast und feststellst, dass deine Arbeitslast insgesamt 80 % der CPU und 20 % des Arbeitsspeichers ausnutzt, dann weißt du, dass du zu einer anderen SKU oder einem anderen Clustertyp wechseln kannst, der eine höhere CPU und weniger Arbeitsspeicher hat, oder du kannst den Arbeitsspeicher nutzen, um einige Ergebnisse mit Optimierungen zwischenzuspeichern, damit du die CPU weniger belastest.

• Plane für Nachfragespitzen und Spitzenauslastungen. Der große Vorteil des Wechsels in die Cloud ist die Elastizität, die die Cloud bietet. Gleichzeitig ist es immer besser, einen genauen Plan zu haben, wie du deine Ressourcen bei Bedarfsspitzen skalierst. Ein Beispiel: Deine Workloads werden heute von einem Cluster mit vier vCPUs und 1 GB Speicher unterstützt. Wie sieht dein Plan aus, wenn du mit einem plötzlichen Anstieg der Last rechnest, sei es, weil gerade Haushaltsschluss ist, wenn du Finanzdienstleistungen anbietest, oder weil du dich auf die Feiertagsnachfrage vorbereitest, wenn du im Einzelhandel tätig bist? Würdest du die Ressourcen auf deinen bestehenden Clustern erhöhen oder sind deine Aufträge so segmentiert, dass du bei Bedarf zusätzliche Cluster hinzufügen würdest? Wenn du in dieser Zeit mehr Daten von deinen On-Premises-Systemen einbringen musst, hast du dann auch einen entsprechenden Anstieg der Netzwerkkapazität eingeplant?

  Du kannst eine von zwei Skalierungsstrategien anwenden : horizontale Skalierung oder vertikale Skalierung. Bei derhorizontalen Skalierung, die auch als Skalierung nach außen bezeichnet wird, wird eine Skalierungseinheit (z. B. eine VM oder ein Cluster) ausgewählt und weitere Skalierungseinheiten hinzugefügt. Deine Anwendung muss diese Skalierungseinheit ebenfalls kennen. Bei der vertikalen Skalierung, die auch als Aufwärtsskalierung bezeichnet wird, bleibt die Skalierungseinheit unverändert und es werden bei Bedarf weitere Ressourcen (z. B. CPUs oder Speicher) hinzugefügt. Beide Strategien funktionieren gut, solange du dir über die Auswirkungen auf deine Geschäftsanforderungen, deine SLAs und deine technische Umsetzung im Klaren bist.

In Tabelle 4-3 siehst du eine Reihe von Faktoren, die du bei der Überwachung und Auswertung für die Kapazitätsplanung berücksichtigen musst. Sieh dir auch die verfügbaren Reservierungsmodelle an, mit denen kritische Produktions-Workloads ohne Beeinträchtigung anderer Workloads ausgeführt werden können.

Tabelle 4-3. Faktoren, die bei der Kapazitätsplanung zu berücksichtigen sind

Komponente	Zu berücksichtigende Faktoren
IaaS-Datenverarbeitung	vCPU (Kerne), Speicher, SKUs (Art der VM), verfügbares Caching, Festplattengröße (GB/TB) und Transaktionen (TPS)
PaaS Rechenleistung	Clustergröße, vCPU (Core), sofern verfügbar, und abrechenbare Einheiten, die vom PaaS-Anbieter veröffentlicht werden
Speicherung	Datengröße (TB/PB), Transaktionen (TPS) und Ebene der Speicherung (Flash, Festplatten, Bandlaufwerke in der Reihenfolge hohe bis niedrige Leistung), je nach Leistung
Datenlager	SKUs-Watch für Datenverarbeitung, Speicherung und Transaktionen
Networking	Ingress und Egress, Tier (Standard/Premium) und Gateways mit privaten Netzen

Um den Kapazitätsbedarf bestmöglich einschätzen zu können, empfehle ich dir, einen skalierten PoC durchzuführen, der die Arbeitslast repräsentiert, die du hast. Für den PoC musst du die Verteilung der Datensätze berücksichtigen, die deine Produktionsauslastung am besten repräsentiert. Wenn du eine On-Premises-Implementierung betreibst, ist es eine gute Methode, einen bestehenden Workload in der Cloud laufen zu lassen. Wenn du die Autoskalierungsfunktionen deines Clusters oder die serverlosen Angebote deines Cloud-Providers nutzt, werden viele dieser Aufgaben automatisch für dich erledigt.

Datenformate und Auftragsprofil

Das von dir gewählte Datenformat spielt eine entscheidende Rolle für die Leistung und Skalierbarkeit deines Data Lakes. Dies wird oft ignoriert, weil dies bei strukturierten Datenspeichern (Datenbanken oder Data Warehouses) als selbstverständlich vorausgesetzt wurde. Die Daten wurden in einem Format gespeichert, das für die Transaktionsmuster des Datenbank-/Data-Warehouse-Dienstes optimal war. Angesichts der unzähligen Datenverarbeitungsanwendungen, die auf der Speicherung im Data Lake laufen, und der Annahme, dass dieselben Daten in mehreren Engines verwendet werden können, liegt es nun an den Big-Data-Architekten und den Entwicklern, das richtige Format für ihre Szenarien auszuwählen. Das Beste daran ist jedoch, dass du, sobald du das optimale Format gefunden hast, feststellen wirst, dass deine Lösung eine hohe Leistung und Skalierbarkeit bietet und gleichzeitig die Kosten für deine Gesamtlösung senkt. Angesichts des Aufschwungs des Data Lake House und der Allgegenwart von Technologien wie Apache Spark für Batch-, Streaming- und interaktive Datenverarbeitung werden Apache Parquet und darauf basierende Formate wie Delta Lake und Apache Iceberg als optimale Formate für die Data-Lake-Lösung weithin angenommen. Darauf gehen wir in Kapitel 6 näher ein.

Ein weiterer Aspekt, der sich auf deine Skalierbarkeit auswirkt, ist der Aufbau deines Big Data-Verarbeitungsauftrags. In der Regel kann der Auftrag in verschiedene Phasen der Datenaufnahme und -verarbeitung unterteilt werden. Aber nicht alle Phasen sind gleich. Nehmen wir an, dein Auftrag umfasst die folgenden Schritte:

1. Lies einen Datensatz, der 150 Millionen Datensätze enthält.

2. Filtere das auf die 50 Millionen Datensätze, die dich interessieren.

3. Wende Transformationen auf die 50 Millionen Datensätze an, um einen Ausgabedatensatz zu erstellen.

Wenn dein Eingabedatensatz aus mehreren kleinen Dateien besteht, wäre das der Langpol für deinen gesamten Auftrag. Indem du eine neue Phase in deinen Auftrag einfügst, in der du die vielen kleinen Dateien zu einer kleinen Anzahl größerer Dateien verdichtest, kannst du deine Lösung skalierbarer machen.

Zusammenfassung

In diesem Abschnitt haben wir uns eingehend mit der Skalierbarkeit der Cloud Data Lake-Architektur befasst und untersucht, wie eng die Skalierbarkeit mit der Leistung verbunden ist. Wir haben eine Big-Data-Architektur mit einem disaggregierten Rechen- und Speichermodell mit einer kolokalen, eng gekoppelten Architektur verglichen und die Auswirkungen dieser Disaggregation auf die Skalierung untersucht. Wir haben auch die verschiedenen Überlegungen für die Cloud-Data-Lake-Architektur untersucht, die sich auf die Skalierung auswirken: die Auswahl der richtigen Cloud-Angebote, die Planung der Kapazitäten und die Abstimmung der Datenformate und der Datenorganisation auf die Abfragemuster. Dies sind Überlegungen, die du verstehen musst, um deine Data-Lake-Implementierung effektiv auf eine 10-fache Skalierung abzustimmen. In Kapitel 5 werden wir auf diesen grundlegenden Konzepten der Skalierung aufbauen, um die Leistung zu optimieren.