Apache Zeppelin: Notebook mit Interpreter-Isolation, cron-Planung und einer erstaunlich kurzen README

Zeppelins Interpreter-Architektur und die Prozess-Isolation

Apache Zeppelin ist ein webbasiertes Notebook für interaktive Datenanalytik. Die Projektbeschreibung nennt als Zweck datengetriebene, interaktive und kollaborative Dokumente, geschrieben in SQL, Scala und weiteren Sprachen. Das Repository ist in Java geschrieben, wird unter der Apache Software Foundation entwickelt und steht unter Apache 2.0. Der Standard-Branch heißt master.

Der architektonische Kern ist die im README als Kernfunktion genannte Interpreter-Architektur mit Prozess-Isolation. Das ist mehr als ein Detail: Ein abstürzender oder speicherhungriger Interpreter nimmt damit nicht zwangsläufig den Notebook-Server mit, und verschiedene Sprachen lassen sich im selben Notebook mischen, ohne dass sie sich einen Laufzeitkontext teilen. Für den Betrieb heißt das aber auch, dass Ressourcenbudgets pro Interpreter und nicht pro Notebook gedacht werden müssen. Wie diese Isolation konkret umgesetzt ist, ob über eigene JVMs, Container oder beides, sagt das README nicht.

Positiv formuliert: Die Isolation erlaubt es, einem Python-Interpreter andere Speichergrenzen zu geben als einem Spark-Interpreter. Negativ formuliert: Sie vervielfacht die Zahl der Prozesse, die überwacht werden müssen, sobald mehrere Nutzer parallel arbeiten.

Mehr als zwanzig Interpreter in Zeppelin: Spark, Flink, Python, SQL, Shell

Das README bewirbt Mehrsprachigkeit mit Spark, Flink, Python, SQL, Shell und pauschal mehr als zwanzig Interpretern. Diese Aufzählung ist der eigentliche Grund, Zeppelin gegenüber einem sprachspezifischen Notebook zu betrachten: Ein Notebook kann eine Spark-Abfrage, ein anschließendes Python-Stück und ein Shell-Kommando in einer Datei verbinden, ohne dass man für jeden Schritt ein eigenes Werkzeug öffnet.

Die Liste ist zugleich die Stelle, an der man selbst nachprüfen muss. Das README nennt keine Versionen, also nicht, welche Spark-Version der mitgelieferte Spark-Interpreter anspricht oder welche Python-Version vorausgesetzt wird. Für eine Evaluierung heißt das: Die erste Frage gilt nicht dem Notebook-Editor, sondern der Interpreter-Matrix in der Dokumentation unter zeppelin.apache.org/docs/latest/index.html. Passt die dort gelistete Engine-Version nicht zur eigenen Umgebung, hilft auch die beste Oberfläche nicht.

Auffällig an der Formulierung des README ist die Reihenfolge. SQL und Scala stehen in der Projektbeschreibung vorn, Python erst in der Funktionsliste. Das passt zur Herkunft des Projekts aus dem Big-Data-Umfeld und ist ein Hinweis darauf, für wen die Voreinstellungen gedacht sind.

Dynamische Formulare und cron-Planung im Zeppelin-Notebook

Zwei Kernfunktionen heben Zeppelin von einem reinen Analyse-Notizbuch ab. Die erste sind dynamische Formulare: Eingabeelemente, die direkt im Notebook liegen und deren Werte in den Code hineingereicht werden. Ein Notebook wird damit zu einem kleinen Werkzeug, das ein Kollege ausfüllen kann, ohne Code zu lesen oder zu verändern.

Die zweite ist die Notebook-Planung per cron. Damit verschiebt sich die Rolle des Notebooks vom explorativen Protokoll zum wiederkehrenden Auftrag. Genau diese Verschiebung sollte man bewusst mitdenken, denn aus einem geplanten Notebook wird schnell ein Produktionsjob mit allen Konsequenzen: Es braucht eine Fehlerbehandlung, eine Benachrichtigung bei Fehlschlag und eine Antwort auf die Frage, was passiert, wenn ein geplantes Notebook zur selben Zeit von einem Nutzer manuell ausgeführt wird. Das README nennt die Funktion, äußert sich zu keinem dieser Punkte.

Hinzu kommen eingebaute Visualisierung und Echtzeitzusammenarbeit im Editor. Wie die Zusammenarbeit auf Paragraphen-Ebene aufgelöst wird, ist im README nicht beschrieben.

Zeppelin-Deployment von lokal bis YARN

Das README nennt vier Deployment-Varianten: lokal, Docker, Kubernetes und YARN. Diese Bandbreite ist ungewöhnlich und erklärt die Verbreitung des Projekts in Unternehmen, die bereits eine Cluster-Plattform betreiben.

Die vier Varianten sind aber keine Geschmacksfrage, sondern ziehen unterschiedliche Betriebsmodelle nach sich. Lokal heißt ein Notebook-Server mit Interpretern auf einer Maschine, geeignet für einen einzelnen Analysten. Docker und Kubernetes trennen Server und Interpreter deutlicher und verlangen eine Entscheidung, wo der Zustand der Notebooks liegt. YARN bindet Zeppelin in einen Hadoop-Cluster ein und damit an dessen Ressourcenverwaltung.

Welche Artefakte es für diese Varianten gibt, ob es fertige Images oder Helm-Charts sind und welche Konfigurationsschlüssel dabei eine Rolle spielen, steht nicht im README, sondern in der Dokumentation. Wer zwischen den Varianten wählt, sollte die Entscheidung an der Frage festmachen, wer die Interpreter-Prozesse bezahlt und wer sie neu startet, wenn sie hängen.

Zeppelin installieren: zwei Dokumentationslinks statt Befehle

Die Installationsanleitung des README ist kurz und besteht aus zwei Verweisen. Für das Binärpaket verweist das Projekt auf /docs/latest/quickstart/install.html, für den Bau aus dem Quellcode auf /docs/latest/setup/basics/how_to_build.html. Beide Pfade liegen unter zeppelin.apache.org/docs/latest/.

Im README selbst finden sich keine Befehle, keine Paketnamen und keine Systemanforderungen. Es gibt keine Version, keine Angabe zum benötigten JDK und keine Ports. Für jemanden, der Zeppelin nur ausprobieren will, ist das ein Umweg; für jemanden, der es in eine fixe Umgebung einbauen will, ist es ein Risiko, weil die Installationsbeschreibung hinter einem Link liegt, der sich mit jeder Dokumentationsversion verschieben kann.

Zumindest die Anlaufstellen für Unterstützung sind im README direkt verlinkt: die Nutzer- und Entwickler-Mailinglisten über die Community-Seite, der Issue-Tracker liegt bei Apache Jira unter dem Projekt ZEPPELIN, und die Lizenzdatei liegt als LICENSE im Repository. Die README verweist außerdem auf einen Beitragsleitfaden. Antwortzeiten auf Mailinglisten oder Release-Takte nennt sie nicht, und im vorliegenden Material sind keine Releases verzeichnet.

Wo Zeppelin die falsche Wahl ist, und der Unterschied zu Jupyter

Die auffälligste Grenze dieses Projekts ist seine Dokumentationslage im Repository selbst. Wer eine Entscheidung treffen will, findet im README eine Funktionsliste und vier Links, aber keine belastbaren Angaben zu Versionen, Ressourcenbedarf oder Konfigurationsschlüsseln. Jede Evaluierung führt deshalb über die Dokumentationsseite, und damit über eine Quelle, die sich unabhängig vom Repository-Code bewegen kann. Wer Zeppelin einführt, sollte die gelesene Doku-Version festhalten, weil /docs/latest/ immer die neueste meint.

Die naheliegende Alternative ist Jupyter. Der Unterschied liegt im Ansatz, nicht in der Qualität. Jupyter setzt auf ein Kernel-Protokoll, speichert Notebooks als eigene Dateiformate und hat sein Ökosystem rund um diese Datei gebaut; Erweiterungen, Versionierung und Konvertierung knüpfen daran an. Zeppelin bindet Sprachen über hauseigene Interpreter an, bringt dynamische Formulare und cron-Planung von sich aus mit und zielt mit YARN und Spark auf Cluster-Umgebungen. Wer Notebooks als versionierte Analyseartefakte behandelt, fährt mit Jupyter und seinem Dateiformat besser. Wer ein Cluster-Team mit gemischten Sprachen und wiederkehrenden Aufträgen ausstatten will, findet bei Zeppelin die passenderen Voreinstellungen, trägt aber die undokumentierten Teile der Konfiguration selbst.

Redaktionelles Fazit

Zeppelin lohnt sich für Teams, die SQL- und Spark-nahe Analytik in einem geteilten, im Browser bedienbaren Dokument abbilden wollen und dabei eine Planung per cron sowie Eingabeformulare ohne Zusatzwerkzeug brauchen. Wer eine einzelne Sprache, ein lokales Skript oder ein reproduzierbares Pipeline-Artefakt sucht, bekommt mit einem reinen Jupyter-Setup und Versionierung der Notebook-Datei weniger bewegliche Teile. Wer Zeppelin evaluiert, sollte zuerst drei Punkte auf der eigenen Infrastruktur prüfen: ob der Interpreter für die eigene Engine in der gewünschten Version im vorhandenen Zeppelin-Paket enthalten ist, wie die Prozess-Isolation unter Last skaliert, und ob die auf /docs/latest/quickstart/install.html beschriebene Binärinstallation mit dem eigenen JDK und dem gewählten Deployment-Ziel (lokal, Docker, Kubernetes oder YARN) zusammenpasst. Die README selbst beantwortet keine dieser Fragen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository