Einführung von Flink SQL

Hintergrund der Einführung von Flink SQL

• Im Azar Matching Dev Team gab es unter den verwalteten Flink-basierten Apps eine schwere Legacy-App, die 96 CPUs nutzte.
• Diese App implementierte mehrere Funktionen in einer monolithischen Struktur, was die Wartung erschwerte.
• Als im Zuge von Infrastrukturarbeiten die Ausführungs-Nodes geändert wurden, trat das Problem auf, dass die App nicht mehr ordnungsgemäß funktionierte.
• Es musste entschieden werden, ob man sie trotz der hohen operativen Belastung weiter warten oder durch eine andere Methode ersetzen sollte.

Verfügbare Optionen

• Wichtige Funktionen der bestehenden App waren bereits in einer neuen Flink-App umgesetzt.
• Es wurde überlegt, wie sich der Teil für bedingte Event-Veröffentlichung und Logikausführung ersetzen lässt.
  1. Implementierung als eine Flink-App
     • Vorteil: einfacher Betrieb
     • Nachteil: hohe Wahrscheinlichkeit, dass die App groß wird, und wenn ein Teil ausfällt, werden andere Funktionen leicht mit beeinträchtigt
  2. Implementierung als mehrere Flink-Apps
     • Vorteil: unabhängig verwaltbar
     • Nachteil: mehr Aufwand, wenn die Anzahl der Apps zunimmt
  3. Nutzung von Flink SQL
     • Vorteil: Logik kann per Query definiert werden, nur ein Cluster muss verwaltet werden
     • Nachteil: komplexe Logik ist schwer auszudrücken, und ohne Erfahrung im Cluster-Management ist es schwierig

Gründe für die Wahl von Flink SQL und Vergleich mit Alternativtechnologien

• Vor der Einführung von Flink SQL wurden ksqlDB und Spark Structured Streaming geprüft.
• Gründe für die Wahl von Flink SQL:
  1. High Availability
     • Über Checkpoint und Savepoint lässt sich der App-Zustand stabil speichern und wiederherstellen.
     • Der JobManager kann im HA-Modus konfiguriert werden.
  2. Unterstützung fortgeschrittener Streaming-Funktionen
     • Verschiedene Streaming-Verarbeitungsfunktionen werden über SQL-Syntax unterstützt.
     • Unterstützt werden unter anderem Windows, Joins, Event-Time-Verarbeitung und Watermarks.
  3. Erweiterbarkeit über UDFs und Custom Connector
     • Benutzerdefinierte Funktionen sowie die Anbindung an verschiedene Datenquellen und Sinks sind möglich.

vs ksqlDB

• Es ist zwar in die Confluent-Plattform integriert, aber bei Stateful-Streaming-Verarbeitung arbeitet HA ineffizient.

vs Spark Structured Streaming

• Auf Basis der Spark-SQL-Engine implementiert, UDFs und Custom Sinks können erstellt werden.
• Da es in Micro-Batches arbeitet, kann es für Echtzeitverarbeitung nachteilig sein.

Aufbau der Cluster-Umgebung und Art der Query-Bereitstellung

Lokal einfach testen

• Es wird vorgestellt, wie man lokal einen Flink Cluster startet und SQL-Queries einreicht.

Cluster-Architektur in der Produktionsumgebung

• Aufbau eines Flink-SQL-Clusters auf Kubernetes
• Vergleich von Application mode und Session mode

Query-Bereitstellung mit dem GitOps-Ansatz

• Mit GitHub Actions werden Query-Deployments und das Stoppen von Jobs umgesetzt.

Wichtige Operations-Fälle und Troubleshooting-Erfahrungen

Wenn JobManager oder TaskManager ausfallen

• Beim JobManager kann die Arbeit dank HA-Konfiguration auch im Fehlerfall fortgesetzt werden.
• Beim TaskManager werden Aufgaben im Fehlerfall neu verteilt und laufen weiter.

Wenn eine Query fehlschlägt

• Tritt auf bei fehlerhaften eingehenden Daten oder bei unzureichenden Computing-Ressourcen.
• Einstellungen zum Ignorieren von JSON-Formatfehlern sowie Standardwerte sind möglich.

Wenn beim Neustart des Clusters einige Jobs fehlschlagen

• Timeout- und Retry-Einstellungen müssen angepasst werden.

Wenn man eine Bedingung in einer Query ändern und erneut bereitstellen möchte

• Nur bei einfachen Änderungen ist eine Wiederherstellung des Zustands per Savepoint möglich.

Wichtige Monitoring-Punkte

• Kennzahlen wie numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used usw. prüfen

Zum Schluss

• Durch die Einführung von Flink SQL wurden Produktivität und Betriebseffizienz verbessert.
• Hohe Stabilität, außerdem ist die Umsetzung eines GitOps-Controller-Patterns geplant.

[flgkselql98]

Verteilte Systeme wie Flink müssen für HA typischerweise 2–3 Racks vorhalten; durch die Anbindung an Kubernetes scheint HA hier sichergestellt worden zu sein. Allerdings muss man sich am Ende doch auch Gedanken über die Ressourcen der Kubernetes-Worker-Nodes machen. Da frage ich mich, ob dafür Nodes konfiguriert wurden, auf denen nur Flink läuft (bei hoher Flink-Last dürfte es wohl Probleme geben, wenn ein Worker-Node ausfällt).
Aus dieser Perspektive: Welche Vorteile hat der Einsatz von Kubernetes?

Wenn man in Flink außerdem Window-Funktionen verwendet, bleiben die Daten in dieser Zeit im Speicher, sodass SQL-Joins funktionieren. Unter Trade-off-Gesichtspunkten frage ich mich daher, ob Flink wirklich eine gute Wahl ist. Wenn ein immer größer werdendes SQL + Job mit der Zeit abstürzt, ist das schon eine enorme Sache ...

Ich überlege ebenfalls, wie man in Situationen, in denen bereits an der obersten Data Source Joins notwendig sind, das auf Application-Ebene herunterziehen und verarbeiten könnte, statt Flink zu verwenden.