Veröffentlicht am

Big Data Training in der Laptop-Cloud mit VirtualBox

Benötigt man mehr Infrastruktur als ein gutes Laptop 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: Wie kann man eine Cloud-Umgebung auf dem Laptop simulieren?

A: Big Data Computing ist verteiltes Rechnen. Es ist also wichtig, dass auf dem Laptop mehrere Server simuliert werden. Man baut ein virtuelles Rechnernetz auf. Statt von einem Server, spricht man von einem Node.

Um ein virtuelles Rechnernetz aufzubauen, hat man die Wahl zwischen mehreren virtuellen Maschinen, zum Beispiel mit VirtualBox oder Docker.

Save permalink

Q: Docker oder virtuelle Maschinen – welche Option eignet sich besser für die ersten Schritte?

A: Wer BigData Technologien von Grund auf kennen lernen möchte, ist besser bedient, zuerst die Installation auf einem Server kennen zu lernen. Eine Trainings-Umgebung mit Rasperry-Pi haben wir ja schon vorgestellt. Wir können denselben Lerneffekt erzielen, indem wir beispielsweise mit VirtualBox arbeiten.

Dazu installieren wir das VirtualBox Host System und innerhalb des Hostsystems bauen wir so viele virtuelle Maschinen auf, wie das Laptop verkraftet. 

Wer das Zusammenspiel der Big-Data-Komponenten begriffen hat, wird dann eine Docker-Umgebung aufbauen können.

Q: Wie muss das Laptop ausgestattet sein?

Ich habe mit einem Laptop mit 16 GB RAM und ca. 40 GB freiem Festplattenplatz getestet. Ich denke, dass jeder Big-Data-Interessierte ein ähnlich ausgestattetes Laptop besitzt. Damit konnte ich ein kleines Cluster, also Rechnernetz, aufbauen und einige Trainingseinheiten entwerfen. 

Auch relativ komplexe Berechnungen sind möglich, halt nicht mit großen Datenmengen.

Die wichtigsten Eigenschaften der Big-Data-Tools lernt man auch so kennen. Es geht ja nicht zuletzt auch um einen Paradigmenwechsel hin zum verteilten Rechnen. 

Q: Wie viele virtuelle Nodes sind möglich?

Diese Frage ist natürlich zentral. Ich habe auf meinem Laptop sämtliche Prozesse gestoppt, die für das Experiment nicht unbedingt nötig sind, beispielsweise Browser-Tabs geschlossen und Musik ausgeschaltet.

Dann habe ich virtuelle Maschinen (VM) gestartet – eine nach der anderen. Das System wurde ab der fünften oder sechsten VM etwas langsamer. Bei der zehnten VM wurde der Bildschirm schwarz, die Maus funktionierte noch. Ich habe dann wie im Dunkeln getappt und an dies Stellen geklickt, wo ich meinte, dass sich doch ein Button zum Schließen einer VM befand. Nachdem ich eine oder VM so schließen konnte, hat sich das System erholt. VirtualBox ist schon robust. 

Bei diesem Experiment habe ich in den einzelnen Virtuellen Maschinen außer dem Betriebssystem keine weitere Software gestartet. 

Je nach Auslastung des Host-Systems sollten drei bis fünf Virtuelle Maschinen möglich sein, in denen auch Big-Data-Software läuft. Damit kann man gut ein Training durchführen.

Q: Wie greift man auf die einzelnen Nodes zu?

Diese virtuellen Maschinen müssen untereinander vernetzt sein. Das habe ich in einem anderen Blog Post beschrieben.

Um vom Host-System, also von der Ebene-Laptop aus darauf zuzugreifen, arbeitet man mit Port-Forwarding

Ist das Cluster so eingerichtet, dann greift man mit normalen SSH-Tools zu, ich mag MobaXTerm. Diese Tools haben ja (fast) alle ein Web UI. Darauf greift man normal mit dem Browser zu. Einziger klitzekleiner Nachteil: Man muss die Ports verwenden, die man im Port-Forwarding definiert hat. 

Q: Wie könnte man die Komponenten einer Stream Analytics Pipeline auf die Nodes verteilen?

Je nachdem, welche Komponente, oder welches Zusammenspiel mehrere Komponenten man gerade kennen lernen möchte, wird man anders verfahren.

Grundsätzlich kann man alle Software auf allen zur Verfügung stehenden Nodes installieren und dann jeweils nur diejenigen Komponenten starten, die man gerade untersuchen möchte. 

Die Big Data Tools skalieren ja horizontal, das heißt, dass die Anzahl der Nodes verändert werden kann, ohne das System ausschalten zu müssen. Das tönt natürlich verlockend, doch hat in der Praxis auch Randbedingungen, die erfüllt sein müssen. 

Bei Apache Kafka beispielsweise ist es denkbar, die Anzahl laufender Broker zu variieren, je nachdem, welche Ressourcen für die aktuelle Trainingseinheit gerade benötigt werden. Im Trainingsbetrieb wird man sehr schnell merken, dass es wichtig ist, sich gut zu überlegen, wie man ein Kafka-Topic definiert, wenn man plant, die Anzahl Broker zu reduzieren, und verlangt, dass das Topic danach noch zur Verfügung steht.

Bei Apache Spark wiederum, dürfen der Cluster Manager und der Driver nicht ausfallen und müssen speziell abgesichert werden.

Solche Zusammenhänge aufzuzeigen, machen aus meiner Sicht ein gutes Big-Data-Training aus.

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. VirtualBox ist eine gute Alternative. Der vermeintliche Nachteil der beschränkten Ressourcen wird zum Vorteil, weil die Robustheit und Skalierbarkeit der Tools zwangsläufig im Training thematisiert werden. 

Bild von alan9187 auf Pixabay

Buchempfehlung

Trainings-Cluster
Veröffentlicht am Schreiben Sie einen Kommentar

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. Als Quizzlet enthält das Video auch Fragen und Antworten. (Ihre Antworten sind völlig anonym und werden nicht gesammelt.)

Nach dem Quiz folgt eine Seite mit einem Nugget zum schürfen.

Im Webshop erhältlich:

Credits:

Apache Kafka: https://kafka.apache.org

Apache Spark: https://spark.apache.org

Redis: https://redis.io

Prometheus: https://prometheus.io

Grafana: https://grafana.com

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 Schreiben Sie einen Kommentar

Garantierte Reihenfolge in Apache Kafka

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

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.

Das folgende Video geht mit einem simplen Test dieser Behauptung nach. Bald stellen wir fest, dass sie einen Trugschluss birgt. Als Quizzlet enthält das Video auch Fragen und Antworten. (Ihre Antworten sind völlig anonym und werden nicht gesammelt.)

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.

Nach dem Quiz folgt eine Seite mit einem Nugget zum schürfen.

Credits:

Apache Kafka: https://kafka.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 Schreiben Sie einen Kommentar

Leader-Election am Beispiel von Apache ZooKeeper

Big 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 unterbrochen mit einigen Quiz-Fragen und Antworten. (Ihre Antworten sind völlig anonym und werden nicht gesammelt.)

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

Nach dem Quiz folgt eine Seite mit einem Nugget zum schürfen.

Credits:

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 Training mit minimaler Infrastruktur

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:

Stream Analytics Pipeline mit Raspberry Pi
Stream Analytics Pipeline mit Raspberry Pi

3 x Apache ZooKeeper 

4 x Apache Kafka

5 x Apache Spark

3 x Apache Cassandra

1 x Prometheus, Grafana, Kafdrop

Zusammen 16 Raspberry Pi Model 3B mit 16 GB

1 x Redis

1 x Apache Zeppelin

und ein Router

Gemeinsam auf 1 Raspberry Pi Mode 4B mit Minimum 2GB RAM. Siehe 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: 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.

Fortsetzung folgt …

Bild von Noupload auf Pixabay