Design und Implementierung eines On-Premise Cloud Native Lakehouse mit Anwendungsbeispiel

Einleitung

In diesem Blogbeitrag wird das Design und die Implementierung eines On-Premise Cloud Native Lakehouse, entwickelt von evoila, diskutiert. Das System ist Open Source und kann auf GitHub gefunden werden. Es wurde für den Anwendungsfall der Erdbebendatenanalyse erstellt, kann aber auch für andere Verwendungszwecke modifiziert werden. In diesem Blogbeitrag wird das Beispielanwendungssystem für Erdbebenüberwachung mit der Abkürzung EQMS bezeichnet.

Erdbeben, wie andere Naturkatastrophen, sind ein integraler Bestandteil unseres Planeten. Ihre Herkunft kann verschiedener Natur sein, aber meistens treten sie aufgrund der Bewegung von tektonischen Platten in der obersten Schicht der Erde auf. Die durch Erdbeben verursachten Schäden an Menschen und Infrastruktur sind manchmal enorm. Experten schätzen die jüngsten Erdbebenereignisse in der Türkei und Syrien im Jahr 2023 auf bis zu vier Milliarden Dollar, ganz zu schweigen von den Schäden an Menschenleben.

Aus diesem Grund ist die frühzeitige Erkennung solcher Ereignisse ein wichtiges Forschungsgebiet. Um Daten zuverlässig zu sammeln und zu analysieren, wird ein grundlegendes System benötigt, das mit zusätzlichen Funktionen aufgerüstet werden kann. Es muss wichtige Eigenschaften wie Skalierbarkeit und Echtzeitverarbeitung bieten und gleichzeitig hochgradig fehlertolerant sein.

Architektur

Für die zuverlässige Implementierung einer so kritischen Anwendung müssen von der Designphase an die richtigen Systemarchitekturen und -komponenten ausgewählt werden. Das System sollte fehlertolerant und skalierbar sein, während es auch unabhängig von der zugrundeliegenden Hardware oder Cloud-Infrastruktur verwendet werden kann. Nicht zuletzt aus diesem Grund fällt die Wahl der EQMS-Architektur auf das Mikroservice-Modell. In dieser Art von Architektur werden Anwendungen als kleine, unabhängige Container organisiert, die miteinander kommunizieren, um die Gesamtfunktionalität zu bieten. Diese Container können in einem Netzwerk verbunden werden, um ein größeres, verteiltes System zu erstellen. Die einzelnen Anwendungen sind innerhalb von Containern gekapselt. Zur Steuerung des Lebenszyklus und der Umgebung der Container wird die Container-Orchestrierungssoftware Kubernetes verwendet.

Das unten gezeigte Bild veranschaulicht die Struktur des EQMS. Alle Anwendungen laufen in einem Kubernetes-Cluster. Um Aktionen wie das Bereitstellen und Aktualisieren des Systems auf dem Cluster schnell und einfach zu handhaben, wird das EQMS mit dem Helm-Paketmanager in ein Helm-Chart verpackt.

Das EQMS kann in fünf Untergruppen unterteilt werden:

• Datenerfassung: Um Erdbebendaten aus verschiedenen Quellen wie der USGS-Rest-API zu extrahieren, wird die ETL-Software Apache NiFi verwendet. Von NiFi erfasste Daten werden an die Streaming-Plattform Kafka weitergeleitet. Kafka dient als Puffer zwischen Datenerfassung und Hauptspeicher und ist hochverfügbar.
• Datenspeicherung: Die abgerufenen Daten müssen nun dauerhaft gespeichert werden. Zu diesem Zweck wird der S3-kompatible Objektspeicher MinIO verwendet. Auf ihm können unstrukturierte Daten gespeichert und für die weitere Verarbeitung vorbereitet werden.
• Datenvorbereitung: Mit Apache Spark können die Rohdaten nun über die Delta-Lake-Speicherschicht in eine Delta-Tabelle geschrieben werden. Dazu wird ein in Python geschriebenes Spark-Skript verwendet. Die Delta-Tabelle bietet dem MinIO-Objektspeicher Funktionen wie ACID-Konformität und Zeitreisen. Der Hive Metastore speichert das Tabellenschema für Zugriffe.
• Visualisierung: Für aussagekräftige Analysen und Prognosen muss ein intuitives Dashboard mit den wichtigsten Daten existieren. Apache Superset bietet eine Vielzahl von Visualisierungswerkzeugen. Die Daten für die Charts werden aus der Delta-Tabelle im MinIO-Objektspeicher mit Trino abgerufen. Die Abfrage-Engine Trino bietet die Fähigkeit, erhöhte Abfrageraten zu bewältigen.
• Continuous Delivery: Bei der Aktualisierung des Systems können Änderungen automatisch mit der Software ArgoCD auf den Cluster angewendet werden. Dies vereinfacht das Management und spart Zeit.

Hands-On

In diesem Abschnitt wird das zuvor vorgestellte Open-Source-EQMS auf einem Kubernetes-Cluster bereitgestellt. Es kann unter diesem GitHub Repository gefunden werden. 

Anforderungen

Um diesen Prozess durchzuführen, wird ein Kubernetes-Cluster mit mindestens 16 Gigabyte RAM benötigt. Zusätzlich werden mindestens zwei CPU-Kerne (2000 mC) benötigt.

Es wird auch vorausgesetzt, dass ein Kubernetes-Cluster bereits erstellt wurde und über ausreichende Berechtigungen verfügt. Hierfür kann entweder ein lokaler Cluster, wie Minikube, oder ein Cluster eines Cloud-Anbieters wie GCP, AWS oder Azure verwendet werden.

Zusätzlich muss das Kommandozeilen-Tool kubectl auf dem Computer installiert sein, um den Kubernetes-Cluster verwalten zu können.

1. ArgoCD im Cluster einrichten

Der erste Schritt besteht darin, ArgoCD zu implementieren. Dazu können Sie den offiziellen Anweisungen der Betreiber folgen, die auf der ArgoCD-Website zu finden sind.

Erstellen Sie den “argocd”-Namensraum:

kubectl create namespace argocd

kubectl apply  n argocd  f https://raw.githubusercontent.com/argoproj/argo cd/stable/manifests/install.yaml

2. Anwenden der ArgoCD-Application

Jetzt kann das eigentliche EQMS-System implementiert werden. Dazu wird das Manifest der ArgoCD-Anwendung auf den Cluster angewendet, das ArgoCD dann verwendet, um das EQMS einzurichten. Laden Sie die YAML-Datei von dieser URL herunter. Setzen Sie die Werte beider Storage-Class-Parameter auf den Namen Ihrer Speicherklasse, die Sie verwenden werden. Ihre auf Ihrem Cluster verfügbaren Speicherklassen können mit folgendem Befehl gefunden werden:

kubectl get storageclass

Wenn die Speicherklasse als “default” gekennzeichnet ist, kann das Manifest unverändert übernommen werden.

Wenden Sie dann die konfigurierte YAML-Datei mit dem folgenden Befehl auf Ihren Cluster an:

kubectl apply -n argocd -f <path/my-starter.yaml>

3. Sammeln Sie das ArgoCD-Passwort

Um sich später in die ArgoCD-Web-Schnittstelle einzuloggen, muss das Passwort extrahiert werden, welches in einer Kubernetes-Secret-Ressource gespeichert ist. Dazu können Sie eine dieser Optionen verwenden:

Option 1 (wenn Linux genutzt wird)

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d > decoded_password.txt

Option 2 (manuell wenn ein anderes OS genutzt wird)

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}"

Das resultierende Zeichenfolge muss nun von base64 in Text umgewandelt werden. Dafür können verschiedene Werkzeuge verwendet werden, und detaillierte Anleitungen finden sich im Internet. Wenn das System nur zu Testzwecken verwendet wird, kann auch eine Website wie base64decode.org verwendet werden.

4. Einrichtung der Port-Weiterleitungen für ArgoCD und Superset

Nun werden zwei Port-Weiterleitungen erstellt, um ArgoCD und Superset über die Web-Schnittstelle zugänglich zu machen. Öffnen Sie für jeden der Befehle ein neues Terminal, da sie blockierend sind.

kubectl port-forward svc/argocd-server -n argocd 8080:443
kubectl port-forward svc/superset-lb -n default 8088:8088

5. Sammeln der externen Adressen für MinIO und Nifi

Um auf die Web-UIs von Nifi und MinIO zuzugreifen, können die externen Serveradressen der Load Balancer Services mit dem folgenden Befehl angezeigt werden:

kubectl get svc nifi-lb -n eqms-nifi -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
kubectl get svc minio-console-lb -n eqms-minio -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

6. Zugriff auf die Web-UIs

Nun können die Web-Oberflächen der verschiedenen Anwendungen erreicht werden, indem Sie die folgenden Adressen in Ihren Webbrowser eingeben:

Das System wird automatisch einmal pro Stunde Daten von der earthquake Rest-API abrufen.

HINWEIS: Web-Oberflächen wie die von Superset können erst genutzt werden, wenn die automatische Initialisierung (wie der ‘superset-dashboard-init’ Job) abgeschlossen ist!

Vorschau der EQMS-Anwendungen

In diesem Abschnitt werden die Schnittstellen der Anwendungen, die später verwendet werden, gezeigt und kurz erläutert.

Beginnend mit der Apache NiFi-Oberfläche. Hier können Prozessoren per Drag-and-Drop hinzugefügt oder entfernt werden, die darauf ausgelegt sind, Daten zu manipulieren und an andere Anwendungen weiterzuleiten.

Beispielsweise der Datenfluss innerhalb der API-Prozessorgruppe “API_USGS”, die zyklisch Daten von der USGS-API mit dem Prozessor “FetchAPI_USGS” abruft und an den Kafka-Broker sendet, wo sie gepuffert werden, bevor sie im MinIO-Objektspeicher gespeichert wird.

Nachdem die GeoJson-Daten mit Spark in die Delta-Tabelle eingefügt wurden, können sie durch Superset visualisiert werden. Zu diesem Zweck verwendet Superset die SQL-Engine Trino, um die Daten so effizient wie möglich aus der Tabelle abzufragen.

Fazit

In diesem Blogbeitrag haben wir ein On-Premise-Lakehouse vorgestellt, das als Erdbebenüberwachungssystem konzipiert ist und in der Lage ist, seismische Daten zu sammeln, zu speichern und zu visualisieren. Die Erdbebenanalyse bleibt ein dauerhaftes und wichtiges Feld, wobei die moderne Datenverarbeitung eine zentrale Rolle bei der Weiterentwicklung unseres Verständnisses spielt. Darüber hinaus ist das zugrundeliegende System für diese Erdbebenüberwachung Open Source und kann als solide Grundlage für Projekte in verschiedenen Bereichen dienen. Mit bewährten Anwendungen, die nahtlos integriert sind, funktioniert es zuverlässig und effizient. Dank seiner modularen Architektur kann es leicht erweitert werden.

Wir haben uns auch mit der zugrunde liegenden Mikroservice-Architektur des Systems befasst, die in Verbindung mit Kubernetes Skalierbarkeit und Fehlertoleranz bietet. Im anschließenden praktischen Teil haben wir eine Schritt-für-Schritt-Anleitung für die Einrichtung und das Experimentieren mit dem EQMS-System auf einem Kubernetes-Cluster bereitgestellt. Das System kann erweitert und verteilt werden als Grundlage für neue Software.