Der folgende Blogbeitrag beschreibt einen POC, welcher im Rahmen eines Kundenprojekts zur effizienten und individuellen Lösung einer JupyterHub-Umgebung erarbeitet wurde.
Problemstellung:
Im Rahmen eines Kundenprojekts erarbeitete ich einen POC zur Etablierung eines JupyterHubs on Hadoop. Der Gesamtumfang des Projektes stellt ein Cluster zur Verarbeitung und Analyse großer Datenmengen dar. Die Hauptbenutzer sind Data Engineers und Scientists. Zur Programmentwicklung steht innerhalb des Clusters eine JupyterHub-Lösung mit Zugriff auf Apache Hadoop und Spark bereit.
Aktuelle Situation:
Die aktuell bereitgestellte JupyterHub-Umgebung arbeitet im Hintergrund innerhalb von Docker Containern. Dabei wird nach der Anmeldung des Benutzers eine SingleUser Image innerhalb eines Docker Containers gestartet. Die Schnittstelle zum Hadoop Cluster wird über einen HDFS-Mountpoint (HDFS-Gateway) realisiert, sowie den Datenzugriff zu gewährleisten. Des Weiteren kann mittels SparkMagic und Apache Livy, über JupyterHub auf Apache Spark zugriffen werden.
Die Hauptproblematiken, die bei dieser Umgebung auftraten, waren zum einen die Limitierung der Anzahl möglicher Benutzerberechtigungen über das HDFS-Gateway. Zum anderen ein historisch gewachsener Bug, welcher das Spawnen des Docker Containers verhindert, sollten zu viele Dateien im HDFS Ordner vorhanden sein.
POC Lösungsansatz:
Im Nachfolgenden wird der Rahmen und Aufbau des POC beschrieben. Hierbei gehe ich noch einmal detaillierter auf JupyterHub selbst ein.
Die Graphik zeigt einen Teilausschnitt der JupyterLab-Oberfläche. Zum einen sieht man 3 Abschnitte. Diese sind Notebook, Console und Others. Notebooks und Console unterscheidet dabei die Funktionalität. Notebooks dienen wie der Namen schon erahnen lässt zur Dokumentation und Erklärung von live lauffähigem Code. Innerhalb des Notebooks können zudem verschiedene Kernel zur Ausführung des Codes ausgewählt werden. Beispiele wäre Python, Julia, oder R. Die Console, ist die klassische Console, wie z.B. eine Power Shell. In dieser können ausschließlich Befehle abgesetzt werden. Unter Others findet man Zusatztools, wie Diagramme, Text Files, Terminal oder etc. Zusammengefasst sind diese Hilfsmittel zur Unterstützung innerhalb der Jupyterlab-Oberfläche.
JupyterHub ist heutzutage die Lösung im Data Science Umfeld für eine sichere, interaktive Multiuser-Notebook-Umgebung. Dabei wird der Zugriff via Browser auf ein Hadoop Cluster ermöglicht, ohne eine lokale Installation betreiben zu müssen. Bei JupyterHub spricht man auch von einem Multi-User-Server, inklusive Proxy. Die Benutzer starten jeweils eine sogenannte SingleUser Session. Das bedeutet, jeder Benutzer erhält seine eigene Umgebung, die in seinem eigenen Yarn Container läuft. Der dadurch entstehende Vorteil ergibt sich daraus, dass die Last auf einem einzelnen Knoten reduziert und die Ressourcennutzung dynamisch mit der Anzahl der Benutzer skaliert werden kann.
Eines der wichtigsten Tools zur Massendatenverarbeitung ist Apache Spark. Durch die Integration von JupyterHub im Hadoop Cluster, kann Spark nativ und ohne zusätzlichen Overhead angesprochen werden. Benutzer können somit direkt mit Spark interagieren.
Als Userinterface steht den Benutzern JupyterLab (Nachfolger von JupyterNotebooks) bereit.
Zur beispielhaften Veranschaulichung wurde bereits die oben dargestellte Graphik beschrieben. JupyterLab bietet eine grafische Benutzeroberfläche, welche sich mit Komponenten wie einem Terminal, LaTex, Drawio, oder sogar einem Monitor für Sparkjobs erweitern lässt. Die Erweiterungen können über Labextensions, bzw. Notebookextensions integriert werden. Des Weiteren ist JupyterHub ein opensource System und verfügt über ein großes Ökosystem von Plugins. Neben den Erweiterungen lassen sich auch unzählige Sprachen wie z.B., Python, Julia und R integrieren.
JupyterHub on Hadoop ist keine Standardlösung und muss individuell in das vorhandene Cluster integriert werden. Alle Komponenten stammen aus aktiven Entwicklungsständen. Ein großes Feature, welches zusätzlich im Rahmen dieses POCs implementiert wurden, waren benutzerindividuelle Conda-Umgebungen. Zum einen konnten vorinstallierte Conda-Umgebungen, wie Scikit Learn, Pytorch, Seaborn, oder Tensorflow bereitgestellt werden. Durch die Labextension Conda Package Manager, war es den Benutzern zudem möglich, eine individuelle Conda-Umgebung im laufenden Yarn Container aufzusetzen und zu verwenden. Dieses Feature bietet den großen Vorteil der Flexibilität. Für alle Zugriffe auf Daten und Funktionen, konnten klar strukturierte ACL-Gruppen (Access Control Lists) vergeben werden.
Die Graphik zeigt einen Teilausschnitt des Conda Packages Manager. Links sieht man die bereits vorhandenen Conda Environments. Im rechten Teil können die Packages innerhalb der jeweiligen Environment verwaltet werden. Zudem lässt sich wie beschrieben über dieses Menü eine neue individuelle Environment hinzufügen und verwalten.
Kurzbeschreibung – Was ist Hadoop
Apache Hadoop ist eine verteilte Big Data Plattform, die von Google basierend auf dem Map-Reduce Algorithmus entwickelt wurde, um rechenintensive Prozesse bis zu mehreren Petabytes zu erledigen. Durch die verteilte Architektur von Hadoop, ist das System in der Lage durch Parallelisierung extrem große Datenmengen sehr performant in einem Cluster zu verarbeiten. Dabei besteht Hadoop aus verschiedenen Komponenten die wichtigsten sind, das HDFS, YARN, sowie Map-Reduce. Apache Yarn fungiert als Ressourcen-Management und Job Scheduling innerhalb des Hadoop Clusters. Ein Yarn Container repräsentiert dabei eine Menge von Ressourcen, i.d.R. RAM in einem „insolierten Raum“ und einer fest definierten Aufgabe.
Kurzbeschreibung – Was ist Spark
Apache Spark ist ein Allzweck-Tool zur Datenverarbeitung. Eine sogenannte Data Processing Engine. Data Engineers und Scientists setzen Spark ein, um äußerst schnelle Datenabfragen (Queries) auf große Datenmengen im Terabyte-Bereich ausführen zu können.
Mit Spark können Daten transformiert, fusioniert und auch sehr mathematische Analysen unterzogen werden.Typische Anwendungsszenarien sind interaktive Datenabfragen aus verteilten Datenbeständen und die Verarbeitung von fließenden Daten (Streaming) von z.B. Sensoren.
JupyterHub on Hadoop – Die Architektur
Die Nachfolgende Abbildung zeigt vereinfacht die Architektur eines Hadoop Clusters mit zwei Workern und einem JupyterHub-Knoten.
Aufbau und Vorgehensweise:
Die Benutzer authentifizieren sich auf dem JupyterHub-Knoten. Dieser ist über eine Webadresse und Proxy zugänglich. Anschließend wird für jeden Benutzer ein eigener Yarn Container auf einem im Cluster verteilten Worker gestartet. Die Anmeldung wird i.d.R. über LDAP authentifiziert. Durch zugewiesene ACL-Gruppen sind alle Zugriffe auf Daten und Funktionen klar administrativ kontrollierbar. Jeder Yarn Container hat eine eindeutige ID und befindet sich immer auf einem einzigen Knoten.
Fazit:
Der POC JupyterHub on Hadoop konnte durch die Realisierung die bestehenden Probleme lösen. Durch das Spawnen der SingleUser Sessions innerhalb eines Yarn Containers, muss keine Schnittstelle zum Hadoop, oder Spark geschaffen werden. Des Weiteren war es vorher nicht möglich ACL-Gruppen für die Berechtigung über das HDFS-Gateway zu setzen. Durch das vermeiden jeglicher Schnittstellen konnte auf das HDFS-Gateway sogar verzichtet werden. Der historische Bug im gewaschenen Dockerfile wurde ebenfalls aufgelöst. Die Anzahl der Dateien im berechtigten HDFS Ordner spielt für das Spawnen mit dem Yarn Container keine Rolle.
Im Rahmen dieses POC wurde eine effiziente und lösungsorientierte JupyterHub-Umgebung geschaffen, die die vorhandenen Probleme löst und zudem weitere Vorteile, sowie Arbeitserleichterungen mit sich bringt.
