Veröffentlicht am

Big Data Training mit minimaler Infrastruktur

Infrastruktur Big-Data Training

Welches ist die minimal benötigte Infrastruktur, um sich mit Big-Data-Technologien vertraut zu machen. Dieser Artikel gibt Antworten in Form eines FAQ und berücksichtigt insbesondere den Aspekt des verteilten Rechnens und der horizontalen Skalierbarkeit. 

Q: Laufen Big-Data-Tools auf Raspberry Pi?

A: Ja, das funktioniert und eignet sich bestens zum Kennenlernen der Big Data Technologien. Das Bild oben zeigt ein Raspberry Pi Cluster für eine Stream Analytics Pipeline mit den folgenden Komponenten:

Big-Data-Cluster mit Raspberry Pi

16 Raspberry Pi Model 3B mit 16 GB SD-Karten, und zwar

Zusätzlich 1 Raspberry Pi Model 4 mit 4GB und 16 GB SD-Karte für

SELRES_0.35861486414680643SELRES_0.26042752953760684Siehe auch: Big Data Streaming mit Raspberry Pi

 

Q: Geht es auch mit mehr Nodes?

A: Die Big Data Tools sind auf auf horizontale Skalierung, also scale-out, ausgerichtet. Je größer die Rechenlast ist, also je mehr Daten verarbeitet werden müssen, umso mehr Rechner – also Nodes –  werden ins Cluster aufgenommen.

In der oben beschriebenen Pipeline ist dies sinnvoll für Apache Kafka, Apache Spark, Apache Cassandra und je nach Zweck der Pipeline auch für Redis. Da können auch Hunderte von Nodes im Einsatz sein. Ob das für eine Trainingsumgebung mit Raspberry Pi noch sinnvoll ist, sei dahingestellt.

Apache ZooKeeper ist ein Koordinations Service für verteilte Systeme. Als solcher sollte er auf mehreren Nodes deployed werden, drei bis fünf werden meistens reichen.

Für die Monitoring-Tools Prometheus, Grafana Kafdrop reicht ein Node.

 

Q: Geht es auch mit weniger Nodes?

A: Hier stellt sich die Frage, was mit dem Trainings-Cluster erreicht werden soll. Geht es darum, beispielsweise Apache Kafka oder Apache Spark als verteilte Systeme kennen zu lernen, dann würde ich mindestens drei Nodes aufsetzen. Denn so lässt sich der Ausfall eines Nodes gerade noch simulieren.

Geht es darum, das Zusammenspiel von zwei dieser Komponenten, beispielsweise Apache Kafka oder Apache Spark, zu erproben, dann würde ich mit mindestens sechs Nodes arbeiten wollen. Angesichts dessen, dass all diese Systeme auch im Single-Node-Modus laufen, könnte die Trainingsumgebung weiter verkleinert werden. Mit weniger als fünf Nodes sehe ich kein lehrreiches Experiment mehr, um die Eigenschaften der verteilten Systeme kennen zu lernen.

 

Q: Würde sich auch VirtualBox oder eine andere Virtualisierung eignen?

A: Diese Frage ist positiv zu beantworten. Aber: Für die Anzahl der gleichzeitig laufenden virtuellen Maschinen gelten dieselben Überlegungen wie für die minimal notwendige Anzahl Raspberry Pi (siehe oben). Mindestens fünf virtuelle Maschinen sollten gleichzeitig auf dem Host-System laufen können. Auf einem guten Laptop ist das machbar.

Ich habe die Grenze auf meinem Win-10-Laptop mit 16 GB RAM und VirtualBox ausgetestet. Dazu habe ich alle nicht notwendigen Windows-Programme geschlossen und eine VM nach der anderen gestartet. Auf den VMs lief lediglich Ubuntu 18.04  für Server. Weitere Vorsichtsmaßnahmen habe ich keine getroffen.

Beim Starten der zehnten VM wurde der Bildschirm schwarz. Der Mauszeiger war noch zu sehen und reagierte. Es gelang mir dann, im Dunkeln tappend, einige der VMs zu schließen. Das System hat sich erholt, das Bild kehrte zurück. Das spricht doch sehr für die Robustheit der VirtualBox, die ja kostenlos erhältlich ist. Das Minimum von 5 VMs läuft auf meinem Laptop gut, auch mit gestarteten Big-Data Services.

Q: Funktioniert VirtualBox mit allen Prozessoren?

A: VirtualBox funktioniert mit gängigen Intel-Prozessoren, allgemeiner mit AMD-Prozessoren. Neuere Mac-Produkte verbauen den ARM-basierten M1-Prozessor. VirtualBox funktioniert dort nicht. Natürlich gibt es eine Alternative mit Parallels – einer ARM-basierten Virtualisierung. Ist die virtuelle Maschine mit Linux installiert, dann funktioniert das weitere  Aufsetzen des Clusters für beide Virtualisierungssoftwaren identisch.

Q: Sind auch Cloud-Angebote sinnvoll einsetzbar?

A: Cloud-Dienstleister bieten ja out-of-the Box Big Data Lösungen als SaaS (Software as a Service) an. Das ist an sich eine wunderbare Sache. Doch wird man damit die Technologien nicht in gleichem Maße kennenlernen, wie wenn man sie selbst aufbaut.

Doch die Cloud kennt ja verschiedene Ausprägungen – als IaaS, also Infrastructure as a Service, können wir in der Cloud virtuelle Maschinen beziehen. Mit minimalen Ressourcen sind sie gut erschwinglich. Dort installieren wir mit ein paar Mausklicks Ubuntu Server und können anschließend dieselben Trainingseinheiten durchführen, wie mit VirtualBox oder Raspberry Pi. Die Kosten sollte man im Auge behalten und die VMs jeweils stoppen, wenn man sie nicht benötigt.


Q: Wie sieht es aus mit Docker und Kubernetes?

A: Eine berechtigte Frage: viele der Big Data Tools sind Cloud-Native, also für Kubernetes gebaut. Andere Tools werden von ihren Communities gerade Kubernetes-tauglich gemacht. Aus meiner Sicht stellt Kubernetes eine zusätzliche Schicht dar, für die ein Verständnis aufgebaut werden muss.

Ich empfehle darum, Kubernetes separat von den “klassischen” Big Data Tools kennen zu lernen. Dieses nimmt dann die Rolle eines Cluster Managers dar, den viele der Tools von Haus aus in der einen oder anderen Form mitbringen. Docker nimmt man im Rahmen der Big-Data-Thematik weniger wahr und die Nachricht, dass Kubernetes Docker in kublets nicht mehr unterstützt, hat zusätzlich für Verunsicherung gesorgt. Wer mit Docker Compose ein Docker File erstellen möchte, muss sowieso zuerst die Zusammenhänge kennen. So gesehen ist Docker ein zusätzlicher Schritt wenn es um die Einarbeitung in die genannten Big-Data-Tools geht.


Fazit

Big Data Analyse und Verarbeitung bedeutet zwangsläufig, dass die Rechenlast auf mehrere Server verteilt werden muss. Will man diese Technologien kennen lernen, dann benötigt man eine verteilte Umgebung, also ein Cluster. Für den Trainingsbetrieb gibt es mehrere Alternativen: 


  • VirtualBox setzt ein gut ausgestattetes Laptop voraus und ist abgesehen davon kostenlos. 
  • IaaS in der Cloud ist ebenfalls eine gute Variante – die Kosten müssen im Auge behalten werden. 
  • Mit Raspberry Pi kann ebenfalls ein Cluster aufgebaut werden. Die anfängliche Investition wird sich auszahlen, wenn das Training länger dauert. Und zudem können diese Kleincomputer später für andere Projekte eingesetzt werden.

Das Ergebnis: eine minimale und bestens geeignete Trainingsumgebung, um Hands-On die einzelnen Tools zu deployen, zu hinterfragen und zu optimieren. 

Die Latenz ist erstaunlich gering und das Cluster läuft erfreulich stabil.

  • Abonniere für Insights zu Data Engineering und Analytics.
  • EBook Tutorial: Cluster aus virtuellen Maschinen
  • Ebook: Apache ZooKeeper
  • Ebook: Realtime Streaming Pipelines
  • LSM-Trees: Log Structured Merge Trees
    LSM-Trees: Log Structured Merge Trees
  • Aufbau einer Enterprise Search
  • Zeit Stream Analytics
  • B-Tree-Index in Datenbanken
  • Ordering Guarantee in Apache Kafka
  • CAP Theorem
  • MapReduce Funktionale Programmierung
  • Konzepte des HDFS
  • Optimistisches Concurrency Control
Veröffentlicht am Schreib einen Kommentar

Garantierte Reihenfolge in Apache Kafka

Kafka Ordering Guarantee

Garantierte Reihenfolge in Apache Kafka

Event Hubs wie Apache Kafka geben eine Ordering Guarantee und versprechen damit, dass die Events in derselben Reihenfolge gelesen werden, wie sie in die Queue geschrieben wurde. Dieser Blog-Post beleuchtet die Details und zeigt die Einschränkungen der garantierten Reihenfolge in Event Hubs im Real-Time Big Data.

1 Reihenfolge in Topics

Sei es als Message Queue, sei es als Event Hub Apache Kafka ist sehr beliebt. Apache Kafka kommt in Realtime Big Data Stream Processing Systemen zum Einsatz. Als verteiltes System ist Kafka jedoch sehr komplex. Das folgende Bild verdeutlicht die Grundidee:

High-Level-Betrachung eines Kafka-Topics
Das Producer-API sendet Events auf ein Topic. Das Consumer API liest Events von einem Topic. Ein Topic hat die Datenstruktur einer Queue, die Events haben eine Offsetnummer.

Der Producer schreibt laufend Nachrichten auf eine Topic, also eine Message Queue. Der Consumer holt diese bei Bedarf dort ab.

Zusammen mit der Aussage der Ordering Guarantee, also der garantierten Reihenfolge, suggeriert das Bild, dass der Consumer die Nachrichten in genau der Reihenfolge erhält, wie der Producer sie schreibt. Eine Queue, also Wartschlange, befolgt ja das FIFO-Prinzip – first in first out.

Das folgende Video geht mit einem simplen Test dieser Behauptung nach. Bald stellen wir fest, dass sie einen Trugschluss birgt.

Im ersten Durchlauf des Versuchs sendet der Producer die Events im Abstand von einer Sekunde an das Topic. Der Consumer erhält – wie erwartet – die Events in derselben Reihenfolge, in der der Producer sie versendet hat.

Im zweiten Durchlauf sendet der Producer die Events ohne Wartezeit und der Consumer erhält sie in einer abweichenden Reihenfolge.

Die Erklärung für das Phänomen ist einfach und basiert auf der Tatsache, dass das Topic eine verteilte Message Queue darstellt. Es wurde ja zu Beginn des Experiments mit fünf Partitionen definiert. Der Befehl im Video lautet ja:

kafka-topics.sh --create --topic nugget02 --partitions 5  --replication-factor 2 --bootstrap-server kafka-1:9092

Für das Experiment ist die Angabe –partitions 5 ausschlaggebend. Der Effekt des Experiments ist vergleichbar, wenn das Topic mit 2 oder mehr Partitionen definiert wird.

Apache Kafka ist ein komplexes System. Um das einfache API für den jeweiligen Anwendungsfall korrekt einzusetzen, benötigt man ein solides Verständnis des unterliegenden Systems.

2 Topics und Partitionen

Als Big-Data-System ist Apache Kafka ein verteiltes System. Die Daten der Topics werden also auf mehrere Broker verteilt, so dass insgesamt sehr große Datenmengen gehandhabt werden können. Je mehr Partitionen ein Topic umfasst, umso mehr Events kann das Topic enthalten.

Bei den Überlegungen zur Partitionierung ist zu berücksichtigen, dass eine Partition nicht über mehrere Festplatten hinweg gehalten werden kann. Der Festplattenplatz beschränkt also die Größe einer einzelnen Partition. Apache Pulsar ist ein Event-Hub, der diese Beschränkung nicht aufweist.

Bei der Entscheidung, wie viele Partitionen für ein Topic definiert werden sollen, spielt auch die Anzahl der vorhandenen Kafka-Broker eine Rolle. Die Partitionen sollten ja auf unterschiedliche Broker verteilt werden, um mehr Events halten zu können. Im Code oben wurden weder retention.ms noch retention.bytes definiert. Die Retention Time bestimmt die Dauer, während der ein Event in der Message Queue verbleibt, bevor es von Kafka automatisch gelöscht wird. Analog bestimmt die retention.bytes wie gross eine Partition maximal werden kann, bevor Kafka, die ältesten Events löscht, um diese Maximalgröße nicht zu überschreiten.

Topic Partitonen
Topics werden partitioniert. Die Events werden auf die einzelnen Partitionen verteilt.

3 Partitionen und Reihenfolge

Topics in Event Hubs sind ja (unbeschränkte) unbounded Datasets. Das bedeutet nicht, dass sie selbst unendlich groß werden – denn der Platz auf der Harddisk ist ja immer beschränkt und auch die Anzahl der Broker ist beschränkt. ‘Unbeschränkt’ bedeutet in dem Fall, dass die Event Queue theoretisch unendlich lang laufen kann – ältere Events werden ja gelöscht, wie oben beschrieben. Bei passender Konfiguration und Pflege wird eine unbeschränkte Laufzeit erreicht.

Jede Topic Partition ist eine Queue, also eine Warteschlange, die nach dem FIFO-Prinzip funktioniert. Damit ist ja die Reihenfolge gegeben: die Events werden in derselben Reihenfolge aus der Queue gelesen, in der sie in die Queue geschrieben wurden.

In einer verteilten Queue verteilt der Producer die Events auf die einzelnen Partitionen. Ein Event wird in genau einer Partition gespeichert. Innerhalb einer Partition werden also die Events in genau derjenigen Reihenfolge aufbewahrt, in der sie geschrieben wurden.

In unserem Experiment werden die Events also auf fünf Partitionen verteilt. Welches Event in welcher Partition landen wird, ist nicht vorhersehbar.

Doch warum stimmt die Reihenfolge im ersten Durchlauf des Experiments und im zweiten Durchlauf nicht mehr?

Der Unterschied war die Geschwindigkeit, in der der Producer die Events auf die Topic-Partitionen schickte. Um den Effekt zu verstehen, schauen wir den Partitioner genauer an.

4 Der Partitioner

Das Kafka-Partitioner API ist einfach bedienbar. Der Python Code im Experiment sah wie folgt aus:

producer = KafkaProducer(bootstrap_servers='kafka-1')
....
producer.send(topic="nugget02", value=data)

Damit wurde das Default-Verhalten von Kafka aufgerufen. Dieses setzt Vieles voraus, was vielleicht gar nicht gewünscht ist. Auch die Wahl des Partitioners.

Es stehen mehrere Partitioner-Algorithmen zur Auswahl.

Der Partitioner definiert einen Buffer für jede Partition, auf die er schreiben soll. Die eintreffenden Events verteilt er nach dem gewählten Algorithmus auf die Partitionen. Beim Round-Robin-Partitioner beispielsweise, werden die Events der Reihe nach auf die einzelnen Buffer verteilt.

Ist ein Buffer voll oder ist eine gewisse Zeit verstrichen, dann werden die Events an die jeweilige Partition gesendet. Beide Parameter können konfiguriert werden.

Dieser Timeout ist natürlich viel kürzer als die eine Sekunde, die wir im ersten Durchlauf des Experiments definiert hatten. Somit wird jedes Event einzeln an die jeweilige Partition gesandt. Im zweiten Durchlauf des Experimants wurden dann mehrere Events gleichzeitig an die Partition gesandt.

Das ist nur ein Teil der Erklärung für die abweichende Reihenfolge, in der der Consumer in den beiden Durchläufen die Events geliefert bekam. Der zweite Teil der Erklärung ist beim Consumer zu suchen.

Dieser pollt die einzelnen Partitionen in einer bestimmten (ebenfalls konfigurierbaren) Frequenz und erhält jeweils höchstens so viele Events geliefert, wie im vorgesehenen Buffer Platz finden (auch diese Parameter in konfigurierbar).

Im ersten Durchlauf des Experiments trafen die Events so langsam in den Partitionen ein, dass sie einzeln ausgeliefert wurden und so die scheinbar richtige Reihenfolge einhalten konnten. Im zweiten Durchlauf des Experiments war das nicht mehr der Fall und die globale Reihenfolge der Events geriet beim Consumer durcheinander.

Kafka Partitioner
Der Round-Robin-Partitioner verteilt die Events abwechslungsweise auf die Partitionen. Ist der Buffer voll, oder ist eine konfigurierte Zeitspanne verstrichen, dann werden die Events aus dem Buffer auf die Partition geflushed.

5 Partition beeinflussen

Bei all diesen Betrachtungen dürfen wir eins nicht außer Acht lassen: Auch beim Consumer wird es sich meistens um ein verteiltes System handeln, beispielsweise um Apache Spark, oder ein anderes Tool zur Real-Time Analyse von Kafka-Topics.

Sollte für diese Verarbeitung oder Analyse der Daten die Reihenfolge eine Rolle spielen, dann wird sich die Analyse-Komponente in ihrer Rolle als Consumer darum kümmern. So wird Apache Spark für Real-Time Analysen die Events in Zeitfenster einteilen und auswerten (siehe Zeit im Big Data Stream Processing).

Verlangt unser Use Case, dass gewisse Events in der richtigen Reihenfolge aus der Queue gelesen werden, dann haben wir bei Apache Kafka die folgenden Möglichkeiten:

5.1 Beim Senden der Events die Partition angeben

Diese Variante sollte mit Bedacht angewendet werden. Immerhin gibt es eine ganze Reihe verschiedener Partitioner-Algorithmen, die genau für diesen Zweck geschrieben wurden.

5.2 Mit nur einer Partition arbeiten

Damit sind wir auf der sicheren Seite: Wo nichts aufgeteilt wird, gerät nichts durcheinander. Doch wir verlieren die Möglichkeit, die Daten auf mehrere Broker zu verteilen und damit die Menge insgesamt zu skalieren.

5.3 Mit Keys arbeiten

Im Code-Beispiel oben, enthielt der Send-Befehl nur ein Value um die Variable zu benennen, in der die zu sendenden Daten hinterlegt sind. Der Send-Befehl kann auch einen Key enthalten. Dabei handelt es sich nicht um einen Primary-Key, sondern lediglich um ein Merkmal, das den Value indentifiziert.

Der Primary-Key könnte beispielsweise eine Konto-Nummer sein. Der zugehörende Value könnte die Veränderungen auf dem Konto enthalten. Für jede Veränderung auf dem Konto wird ein Event ins Topic geschrieben. So können wir die Veränderungen nachverfolgen – immerhin haben sie alle denselben Key, werden in dieselbe Partition geschrieben und erscheinen demnach in der historischen Reihenfolge.

Der Partitioner serialisiert zuerst den Key und bildet danach einen Hash-Wert bilden, dessen Ergebnis die Partition bezeichnet. Damit erwirken wir, dass alle Events mit demselben Key auf ein und dieselbe Partition geschrieben werden und das unter Einhaltung der Reihenfolge ihres Eintreffens. Eine Partition kann für mehrere Keys zuständig sein.

Damit erreichen wir eine sinnvolle Reihenfolge in Bezug auf ein Kriterium: Beispielsweise in Bezug auf die Messdaten eines einzelnen Sensors, wenn die SensorID als Kafka-Key dient.

Die Gefahr besteht, dass die Partitionen ungleichmäßig ausgelastet werden und damit die Consumer der nachfolgenden Komponente (z.B. Apache Spark) ungleichmäßig ausgelastet werden.

Mit Keys arbeiten ist auch sinnvoll, wenn zusätzlich die Topic Partitionen compacted werden. Bei der Compaction bleibt jeweils das jüngste Element eines Keys erhalten und die älteren werden gelöscht. Eine sinnvolle Art Daten mit relativ wenigen unterschiedlichen Keys in Topics zu verwalten.

6 Fazit

Apache Kafka gibt eine Ordering Guarantee ab. Gleich wie andere verteilte Event-Hubs kann diese Garantie nur in Bezug auf eine Partition abgegeben werden.

Durch die Wahl eines Keys kann die Reihenfolge der Events im Topic in Bezug auf den Key garantiert werden.

  • Abonniere für Insights zu Data Engineering und Analytics.
  • EBook Tutorial: Cluster aus virtuellen Maschinen
  • Ebook: Apache ZooKeeper
  • Ebook: Realtime Streaming Pipelines
  • LSM-Trees: Log Structured Merge Trees
    LSM-Trees: Log Structured Merge Trees
  • Aufbau einer Enterprise Search
  • Zeit Stream Analytics
  • B-Tree-Index in Datenbanken
  • Ordering Guarantee in Apache Kafka
  • CAP Theorem
  • MapReduce Funktionale Programmierung
  • Konzepte des HDFS
  • Optimistisches Concurrency Control

[easy-social-share]

Credits:

(c) Video und Quiz: Tirsus GmbH / Ursula Deriu

Veröffentlicht am Schreib einen Kommentar

Apache Spark Streaming mit Window Operation

Streaming Window Spark

Apache Spark Streaming mit Window Operation

Die APIs für Big Data Stream Analytics werden immer einfacher. Real-Time Analysen sind sogar mit SQL möglich. Dabei kommen Window Operationen zum Einsatz. Mit den DataFrames von Apache Spark Structured Streaming sind diese schnell geschrieben.

Der Umstand, dass Analysen relativ einfach zu erstellen sind, lässt gerne die enorme Komplexität dieser verteilten Systeme vergessen. Besondere Herausforderungen besprechen wir im Artikel Realtime Big Data Stream Processing. Der Big Data Nugget #03 soll einen Eindruck vermitteln: Dabei kam das Raspberry Pi Cluster erfolgreich zum Einsatz. Faszinierend ist, dass dieselbe Pipeline bis auf mehrere hundert Nodes skalieren kann. Für das Video wurde die Pipeline wie folgt aufgebaut:

Apache Kafka dient als Event Hub, Apache Spark nimmt die Analyse vor und speichert die Ergebnisse in Redis. Dort werden sie von einem Python Skript abgeholt und visualisiert. Das Monitoring erfolgt mit Prometheus und Grafana.

Der folgende Big Data Nugget thematisiert die Timestamps, die in diesem Event von den einzelnen Systemen gesetzt werden. Die Analyse wird mit Apache Spark Structured Streaming erstellt.

Credits:

(c) Video und Quiz: Tirsus GmbH / Ursula Deriu

Abonniere für Insights zu Data Engineering und Analytics.
  • EBook Tutorial: Cluster aus virtuellen Maschinen
  • Ebook: Apache ZooKeeper
  • Ebook: Realtime Streaming Pipelines
  • LSM-Trees: Log Structured Merge Trees
    LSM-Trees: Log Structured Merge Trees
  • Aufbau einer Enterprise Search
  • Zeit Stream Analytics
  • B-Tree-Index in Datenbanken
  • Ordering Guarantee in Apache Kafka
  • CAP Theorem
  • MapReduce Funktionale Programmierung
  • Konzepte des HDFS
  • Optimistisches Concurrency Control
Veröffentlicht am Schreib einen Kommentar

Leader-Election am Beispiel von Apache ZooKeeper

Leader Election Apache Zookeeper

Leader-Election am Beispiel von Apache ZooKeeperBig Data Nugget #01

Apache ZooKeeper ist ein kampferprobter Koordinationsdienst für verteilte Computer-Systeme. ZooKeeper wird in unterschiedlichsten Systemen eingesetzt. Als Dienst für Dienste tritt er nicht offen in Erscheinung und ist Vielen unbekannt. ZooKeeper kommt in Systemen zum Einsatz, die im Artikel Realtime Big Data Stream Processing beschrieben werden.

Der Big Data Nugget #1 befasst sich mit ZooKeeper und greift den Aspekt der Leader-Election in einem Peer-to-Peer System heraus. Alle Rechner im Verbund, also alle Nodes im Cluster, sind gleich berechtigt und doch muss einer davon die Rolle des Leaders übernehmen. Hauptaufgabe des Leaders ist es, die Konsistenz der Daten zu gewährleisten. In ZooKeeper kommt dabei das Zab-Protokoll zum Einsatz. Das Quiz befasst sich mit den wichtigsten Eigenschaften der Leader-Election bei ZooKeeper. In Bezug auf diese Funktion kann das Zab-Protokoll mit dem Paxos Protokoll verglichen werden. Das Kurzvideo zeigt eine Einleitung und Demo von ZooKeeper.


Die Idee hinter Apache ZooKeeper ist bestechend einfach und bestens geeignet, um Konzepte des verteilten Rechnens kennen zu lernen.

Koordination-Verteilte-Systeme-ZooKeeper

Dieses eBooklet erläutert den Einsatz und die Funktionsweise von Apache Zookeeper auf konzeptioneller Ebene und zeigt so eindrücklich Wege auf, wie verteilte Systeme koordiniert werden können.

Zur ausführlichen Beschreibung

Credits Video: ZooKeeper: https://zookeeper.apache.org  Kostenlose gemafreie Musik von musicfox: https://www.musicfox.com SSH mit MobaXterm: https://mobaxterm.mobatek.net/(c) Video und Quiz: Tirsus GmbH / Ursula Deriu

Veröffentlicht am

Big Data Streaming mit Raspberry Pi

Big Data Taining Raspberry Pi

Big Data Streaming mit Raspberry Pi

Schon erstaunlich, dass Big Data Technologien auch auf Winzlingen wie Raspberry Pi funktionieren. 

Nachdem ich immer mit gut ausgestatteten Rechnern gearbeitet habe, reizte mich das Experiment, die Big-Data Software mit unter Minimalbedingungen zum Laufen zu bringen. 

Das Ergebnis ist verblüffend – die Latenz ist viel geringer, als ursprünglich vermutet.

Und so funktioniert das erste Experiment

Ein simpler Generator schreibt in einer Endlosschleife einen String in ein Apache Kafka Topic. Dieses wird von Apache Spark analysiert und zwar werden die Events pro Minute gezählt. Spark die Ergebnisse in Apache Cassandra einem Wide Column Store und auch in Redis, einer In-Memory Datenbank. Mit Hilfe von Apache Zeppelin werden mit wenigen Klicks übersichtliche Auswertungen visualisiert.

Dazu gehören diese Open Source Tools

Mit dabei ist auch die Überwachung: Prometheus und Grafana sind ein bewährtes Gespann und monitoren Kafka, Zookeeper und Redis. Spark bringt ein eigenes – und seit Spark 3 sehr übersichtliches – Monitoring mit.

 

Das Failover-Verhalten kann mit der Trainingsumgebung gut überprüft und optimiert werden. Der Netzwerkstecker wird herausgezogen und bald zeigen die Monitoring-Tools das Fehlen des Nodes an.

Dieses Trainings-Cluster läuft auf 16 Raspberry Pi. Dazu verwendete ich Model 3 B mit je 1GB RAM und 4 Cores. 16 GB SD-Karten sind ausreichend für viele Experimente. Ein zusätzliches Raspi wurde als Router für dieses Netzwerk aufgesetzt und es bot sich an, Redis auch dort laufen zu lassen.

Die Visualisierung der Auswertung mit Apache Zeppelin wollte auf Model 3B nicht laufen – Antwortzeiten von mehr als 30 Minuten sind halt nicht gerade prickelnd.

Ein Raspberry Pi Model 4B schaffte Abhilfe. 2GB RAM reichen für einfachere Analysen ganz gut. Ich habe 8GB RAM beschafft und so laufen Zeppelin, Redis und der Router problemlos auf einem Gerät.

Das nächste Experiment

Ich habe bisher erfolglos versucht, in dieser Pipeline eine Backpressure zu provozieren. Ein Generator, der auf demselben Node läuft wie auch der Router, und ungebremst kleine Events in die Pipeline pumpt, schafft es nicht, einen Rückstau zu verursachen. Vielleicht wird es klappen mit mehreren Generatoren oder auch mit einer viel komplexeren Auswertung.

Fazit

Die untersuchte Big Data Software lässt nicht nur ein Scale-Up zu sondern auch ein Scale-Down. Auf minimal ausgestatteten Single-Board Computern wie Raspberry Pi funktioniert die Software einwandfrei und erstaunlich schnell. Gerade auf dieser Minimal-Infrastruktur werden die Grenzen der verarbeitbaren Datenmengen relativ schnell erreicht. So ist es möglich, das Verhalten der Pipeline unter “Extrembedingungen” kennen zu lernen und zu tunen.

  • Abonniere für Insights zu Data Engineering und Analytics.
  • EBook Tutorial: Cluster aus virtuellen Maschinen
  • Ebook: Apache ZooKeeper
  • Ebook: Realtime Streaming Pipelines
  • LSM-Trees: Log Structured Merge Trees
    LSM-Trees: Log Structured Merge Trees
  • Aufbau einer Enterprise Search
  • Zeit Stream Analytics
  • B-Tree-Index in Datenbanken
  • Ordering Guarantee in Apache Kafka
  • CAP Theorem
  • MapReduce Funktionale Programmierung
  • Konzepte des HDFS
  • Optimistisches Concurrency Control