Best-Practices

Diese Seite fasst die empfohlenen Best-Practices für die Entwicklung und den Betrieb von Daten-Pipelines mit STACKIT Workflows zusammen. Die Einhaltung dieser Richtlinien hilft dabei, Wartbarkeit, Reproduzierbarkeit und eine effiziente Ausführung zu gewährleisten.

Development-Workflow (DEV → QA → PROD)

Ein strukturierter Development-Workflow ist für die zuverlässige Bereitstellung von Pipelines unerlässlich.

• Dedizierte Git-Branches

  • Verwalten Sie einen Branch pro Umgebung (dev, qa, prod) in Ihrem DAG-Repository.
  • Definieren Sie eine klare Merge-Strategie (z. B. Feature-Branches → dev → qa → prod), um sicherzustellen, dass getestete Änderungen nach oben fließen.
  • Airflow-Instanzen können im STACKIT Portal so konfiguriert werden, dass sie beim Erstellen oder Aktualisieren einer Workflow-Instanz automatisch aus dem richtigen Branch ziehen.

• DEV

  • Prototyping von DAGs, Spark-Jobs und Notebooks.
  • Verwenden Sie kleine Datensätze oder synthetische Testdaten.
  • Erwarten Sie häufige Änderungen und Experimente.

• QA / STAGING

  • Testen von End-to-End-Workflows mit realistischen Eingabedaten.
  • Validieren Sie XComs, Parameter, SLAs und die Fehlerbehandlung.
  • Überprüfen Sie Sicherheit, Berechtigungen und Integrationen.

• PROD

  • Veröffentlichen Sie nur getestete und geprüfte DAGs.
  • Setzen Sie Monitoring, Alerting und Logging ein.
  • Gewährleisten Sie die Reproduzierbarkeit durch fixierte Image-Versionen (siehe unten).

Installieren fehlender Pakete

Manchmal erfordert ein DAG oder eine Aufgabe zusätzliche Python-Pakete.

• Installieren Sie Pakete niemals in der DAG-Definition selbst

  • Beispiel: os.system("pip install ...") im DAG-Code → Bad Practice.
  • Verursacht Overhead bei jedem DAG-Parse und Instabilität im Scheduler.

• Die Installation innerhalb von Tasks ist möglich, aber langsam

  • Beispiel: pip install ... innerhalb eines Operators.
  • Dies lädt Abhängigkeiten bei jedem Durchlauf neu herunter und installiert sie → nicht reproduzierbar.

• Best Practice: Erstellen Sie ein benutzerdefiniertes Docker-Image

  • Erweitern Sie das offizielle STACKIT Spark-Image (schwarzit-xx-sit-dp-customer-artifactory-docker-local.jfrog.io/stackit-spark) um Ihre eigenen Abhängigkeiten, pushen Sie es in Ihre eigene Container Registry und beantragen Sie über ein Support-Ticket, dass Ihre Registry-Zugangsdaten als Secret zum Airflow-Cluster hinzugefügt werden.
  • Verwenden Sie dieses Image konsistent über DEV/QA/PROD hinweg.

---

Fixieren von Image-Versionen

Um die Reproduzierbarkeit zu gewährleisten und unerwartetes Verhalten zu verhindern:

• Fixieren Sie Image-Versionen (Pinning) in Ihren DAGs immer.
• Vermeiden Sie die Verwendung von :latest-Tags in der Produktion.

Trennung von Business-Logik und Steuerungslogik

Als Best Practice empfehlen wir, die Orchestrierungslogik (DAGs) von der Business-Logik (in der Datenbank ausgeführte SQL, Daten verarbeitende Python-Skripte != DAG / Task-Definition, Spark-Logik usw.) zu trennen. Dies erleichtert das Testen und die Wartung Ihres Codes, da Business-Logik-Funktionen unabhängig von Airflow getestet werden können, zum Beispiel im Service STACKIT Notebooks. Um Business- von Orchestrierungslogik zu trennen, verschieben Sie die Business-Logik in separate Python-Dateien (z. B. compute_stats.py oder kpi_revenue.sql im folgenden Beispiel), die keine Verweise auf Airflow oder DAGs enthalten.