Azure Data Factory Schwachstellen: Die versteckten Kosten von UI-Pipelines und Spark-Transformationen

Azure Data Factory ist der Standard in Azure-Umgebungen und überzeugt dort in seiner Kernrolle als Transportschicht: Copy-Aktivitäten, Event-Trigger und reine Dateitransfers zwischen Cloud-Diensten. Die Reibungsverluste beginnen, wenn ADF auch als Modellierungs- und Transformationsschicht zweckentfremdet wird. Diese Probleme zeigen sich an drei wesentlichen Schwachstellen, die in dieser Reihe jeweils detailliert analysiert werden.

Drei Hürden, eine gemeinsame Ursache

• Die unübersichtliche Canvas-Oberfläche. Hunderte manuell verbundene Aktivitäten, die für jede Quelle kopiert werden und am Ende nur noch von den ursprünglichen Entwicklern nachvollzogen werden können. Siehe den Artikel über visuelle Pipelines im großen Maßstab.
• Das fehleranfällige Release-Management. Komplexe ARM-Templates, separate Parameterdateien pro Umgebung und Deployments, die an einem einzigen Typkonflikt scheitern. Siehe den Artikel über JSON-Deployments.
• Die hohen Spark-Kosten. Mapping Data Flows starten für jeden Lauf einen verwalteten Cluster – selbst für Transformationen, die innerhalb des Data Warehouse mit einem simplen SQL-Statement effizienter ausgeführt würden. Siehe den Artikel über die Kosten von Mapping Data Flows.

Alle drei Hürden haben denselben Ursprung: Die Architektur des Data Warehouse wird als kleinteilige Pipeline-Konfiguration in einem Cloud-Dienst fest verdrahtet, anstatt aus einem zentralen Fachmodell automatisiert generiert zu werden.

Die vierte Hürde: Vendor-Lock-in verhindert den Cloud-Wechsel

Eine ADF-Pipeline ist eine proprietäre Azure-Ressource. Es gibt keine Möglichkeit, diese Pipelines auf AWS oder GCP auszuführen, und auch Fabric Data Factory bindet Sie auf identische Weise an Microsoft Azure. Solange Ihre gesamte IT-Landschaft dauerhaft auf Azure basiert, mag das unbemerkt bleiben. Zum massiven Problem wird dies jedoch, sobald eine Unternehmensfusion, eine strategische Beschaffungsentscheidung oder eine Multi-Cloud-Vorgabe einen Wechsel erfordert: Da die Transformationslogik fest mit der Cloud-Infrastruktur verschmolzen ist, müsste das gesamte Data Warehouse von Grund auf neu implementiert werden. Bei einem modellgetriebenen Data Warehouse existiert dieser Vendor-Lock-in nicht: Der generierte SQL-Code läuft nativ dort, wo Ihre Zieldatenbank betrieben wird.

Was sich mit Datavault Builder ändert

Datavault Builder bildet das Data Warehouse in einem zentralen visuellen Modell ab und generiert daraus automatisch sämtliche Ladevorgänge für Staging, Data Vault und Data Marts – inklusive Deployment-Skripten, Rollback-Routinen, Dokumentation und Lineage, vollständig nativ für Fabric, Synapse, Azure SQL und SQL Server.

• Sie modellieren das Fachliche, den Rest generiert die Datavault-Builder-Plattform. Definieren Sie Entitäten, fachliche Schlüssel und Beziehungen einmalig im Modell; alle physischen Tabellenstrukturen und ETL-Loads werden daraus automatisch abgeleitet. Das Anbinden einer neuen Quelle erfordert lediglich ein Mapping statt einer weiteren Kette kopierter Aktivitäten. Auf dem ADF-Canvas verbleiben lediglich reine Dateibewegungen und ein Auslöser.
• Vollautomatisierte Releases inklusive Rollback. Umgebungsspezifische Deployment-Skripte werden direkt aus dem Modell generiert und vor der Ausführung auditiert. Keine manuell gepflegten ARM-Templates mehr.
• Nativer ELT-Pushdown statt teurer Cluster. Alle Transformationen laufen als mengenbasiertes Delta-SQL direkt auf der Ziel-Datenbank. Keine separaten Spark-Instanzen für reguläre Data-Warehouse-Loads.
• Portables Modell ohne Vendor-Lock-in. Heute Microsoft Fabric, morgen eine andere Plattform – das Datenmodell bleibt unverändert. Ein Technologiewechsel bedeutet lediglich das Umschalten des Codegenerators, nicht das Neuschreiben der Pipelines.
• ADF fokussiert sich auf seine Stärken. Dateitransfers und externe Events laufen weiterhin zuverlässig über Azure Data Factory, während die Datenmodellierung und Lade-Orchestrierung in der Datavault-Builder-Plattform verbleiben.

Wo Sie am besten anfangen

Analysieren Sie Ihre bestehende Umgebung anhand von zwei konkreten Metriken: Erstens: die Anzahl der Aktivitäten in Ihrer größten ADF-Pipeline, die lediglich existieren, um Quelldaten durchzuschleifen, Tabellen abzugleichen oder Prozeduren aufzurufen. Diese manuelle Verdrahtung sollte ein visuelles Modell automatisch erzeugen. Zweitens: die Kosten für Mapping Data Flows auf Ihrer Azure-Monatsrechnung. Diese Spark-Kosten lassen sich durch nativen SQL-Pushdown im Data Warehouse drastisch senken. An diesen beiden Punkten liegt in der Praxis das größte Optimierungspotenzial.