Azure Data Factory: Wie Standard-Concurrency-Einstellungen Ihre Kosten heimlich verdoppeln

Zusammenfassung

In Azure Data Factory (ADF) führen unoptimierte Standardeinstellungen – insbesondere bei der Parallelisierung (Concurrency) und Triggern – häufig zu unbemerkt steigenden Kosten. Da ADF nach einem rein verbrauchsbasierten Abrechnungsmodell (Pay-as-you-go) arbeitet, können ineffiziente Ausführungen die Azure-Rechnung schnell verdoppeln. Durch gezielte Anpassungen der Pipeline-Konfiguration, der Batch-Größen in Schleifen und der Integration Runtimes lassen sich die Kosten jedoch um bis zu 45 % senken, ohne die Pipeline-Logik grundlegend ändern zu müssen.

Was ist passiert?

Zahlreiche Data Engineers und Cloud-Architekten berichten von plötzlichen Kostenexplosionen in ADF. Der Hauptgrund liegt darin, dass viele Standardeinstellungen von Azure auf maximale Performance statt auf Kosteneffizienz ausgelegt sind. Insbesondere wenn Pipeline-Ausführungen parallel getriggert werden oder ForEach-Schleifen mit der maximalen Parallelität von 50 arbeiten, kommt es zu Ressourcenengpässen (Resource Contention). Die zugrundeliegenden Datenquellen oder Runtimes geraten an ihre Limits, was zu verlängerten Wartezeiten (Queuing) oder wiederholten Ausführungen (Retries) führt, die voll abgerechnet werden.

Warum es wichtig ist

Das Pricing-Modell von ADF ist komplex:

Orchestration: Jede Aktivitätsausführung (Activity Run) kostet Geld.
Datenbewegung (Copy Activity): Wird über Data Integration Units (DIUs) pro Stunde abgerechnet.
Datenverarbeitung (Data Flows): Wird nach vCore-Stunden der Spark-Cluster abgerechnet.

Hohe Concurrency ohne ausreichende Compute-Leistung führt dazu, dass Aktivitäten im Status „Queued“ verbleiben oder fehlschlagen und neu gestartet werden müssen. Dies erhöht die Anzahl der Aktivitätsausführungen und die Compute-Dauer drastisch, was die Kosten in die Höhe treibt.

Beweise

Praktiker-Berichte und Fallstudien zeigen:

BitPeak-Analyse: Zeigt auf, dass inaktive Pipelines (ohne Trigger oder mit Null Ausführungen) sowie falsche Datenfluss-Konfigurationen und cross-regionale Datentransfers unerwartete Kosten verursachen.
Praxisberichte auf LinkedIn (Abhishek Agrawal): Dokumentieren Fälle, in denen unbegrenzte oder fehlerhafte Concurrency-Einstellungen in Triggern (z. B. Tumbling Window Trigger) Ausführungen duplizierten und die monatliche ADF-Rechnung verdoppelten.
Community-Diskussionen (Sai Prasath R u.a.): Thematisieren Engpässe bei der Warteschlangenverarbeitung (Queue Processing) auf Runtimes und zeigen auf, wie fehlende Concurrency-Limits zu Timeouts und teuren Retries führen.

Analyse

Das Kernproblem liegt in der Diskrepanz zwischen logischer Concurrency in der Pipeline und physikalischer Kapazität der Integration Runtime (IR) oder des Ziel-Sinks:

ForEach Loops: Standardmäßig laufen ForEach-Schleifen parallel. Ohne Anpassung versucht ADF bis zu 50 Iterationen gleichzeitig zu starten. Verkraftet die Ziel-Datenbank (z. B. eine Azure SQL mit niedriger Service-Stufe) diese Verbindungen nicht, blockieren sich die Abfragen gegenseitig. Die Ausführungszeit steigt linear an, obwohl die Netto-Datenmenge gleich bleibt.
Self-Hosted Integration Runtime (SHIR) Limits: Die Anzahl maximal gleichzeitiger Jobs auf einer SHIR wird basierend auf CPU/RAM auto-kalkuliert. Läuft die Runtime in ein Limit, werden weitere Pipeline-Schritte in ADF in die Warteschlange geschoben. Die Pipelines bleiben aktiv und blockieren Ressourcen.
Duplizierte Trigger-Ausführungen: Wenn Pipeline-Concurrency-Limits auf dem Standardwert verbleiben und Trigger überlappen, laufen mehrere Instanzen derselben Pipeline zeitgleich an und verarbeiten unter Umständen identische Daten mehrfach.

Praktische Erkenntnisse

Um Kostenfallen zu vermeiden und Pipelines zu optimieren, sollten folgende Maßnahmen umgesetzt werden:

Batch-Größen limitieren: Setzen Sie bei ForEach-Schleifen die Concurrency explizit herunter (z. B. batchCount auf 5 oder 10), um die Last auf Ziel-Datenbanken und Runtimes zu steuern.
Pipeline-Concurrency konfigurieren: Begrenzen Sie in den Pipeline-Einstellungen die Concurrency (z. B. auf 1 bei sequenziellen Workflows), damit nachfolgende Trigger-Events sauber warten (Status “Queued”), statt parallel dieselbe Logik zu starten.
Billing-Report nach Pipeline aktivieren: Gehen Sie in ADF Studio auf Monitor -> Factory Settings -> Show billing report by pipeline. Dadurch können Sie nach 24 Stunden in Azure Cost Management genau sehen, welche Pipeline welche Kosten verursacht.
Self-Hosted IRs skalieren: Erhöhen Sie die Anzahl der Knoten (Scale-out) auf bis zu 4, um Lasten besser zu verteilen, anstatt das Concurrency-Limit einer einzelnen überlasteten VM manuell zu erzwingen.
Data Flow TTL (Time-to-Live) nutzen: Vermeiden Sie das ständige Hoch- und Herunterfahren von Spark-Clustern bei sequenziellen Data Flows, indem Sie eine TTL von z. B. 10 Minuten einrichten, damit der Cluster für nachfolgende Aktivitäten warm bleibt.

Offene Fragen

Welche konkreten Auswirkungen haben die neuen Azure Integration Runtime-Preise auf grenzüberschreitende Datenbewegungen in Multi-Cloud-Szenarien?
Bietet Microsoft in Zukunft native Semaphore/Locking-Mechanismen an, um Pipeline-Ausführungen ohne manuelle Workarounds (wie Web-Aktivitäten oder Marker-Dateien) abzusichern?