Kosten Ihre Azure Data Factory Mapping Data-Flows mehr als die Daten, die sie bewegen?
Mapping Data-Flows laufen auf einem verwalteten Spark-Cluster, der Minuten zum Starten braucht und pro vCore-Stunde abgerechnet wird. Für eine große nächtliche Transformation ist das vernünftig. Für ein paar Hunderttausend Zeilen ist es ein Cluster, der hochgefahren wird, um zu tun, was ein einziges SQL-Statement im Warehouse tun würde.
Die Data-Warehouse-Automationsplattform, der Datenteams aus vielen Branchen vertrauen
Kommt Ihnen das bekannt vor?
- Kleine nächtliche Transformationen tauchen als größte Position auf der Data Factory Rechnung auf.
- Jeder Data Flow Lauf wartet Minuten auf einen Cluster, bevor er irgendetwas tut.
- Die Integration Runtime hält einen warmen Cluster, um das Warten zu vermeiden, und jetzt wird er im Leerlauf abgerechnet.
- Dieselbe Transformation existiert als Data Flow und als Stored Procedure, weil jemand sie umgeschrieben hat, um Geld zu sparen.
Mapping Data-Flows sind die Art, wie Azure Data Factory Daten ohne Code transformiert, und unter dem Canvas läuft jeder davon auf einem verwalteten Spark-Cluster. Der Cluster startet, der Flow läuft, der Cluster stoppt, und die Rechnung ist pro vCore-Stunde. Für eine große Transformation ist das ein fairer Tausch. Für den typischen Warehouse-Ladevorgang ist es ein Cluster, der hochgefahren wird, um die Arbeit eines einzigen SQL-Statements zu erledigen.
Warum die Kosten schleichend steigen
- Jeder Ausführungslauf verursacht Cluster-Kosten. Der Start dauert Minuten, und diese Minuten werden abgerechnet, egal ob der Flow eine Million Zeilen verarbeitet oder zehntausend.
- Warmhalte-Strategien verlagern die Kosten nur, sie beseitigen sie nicht. Eine Time-to-Live auf der Integration Runtime vermeidet das Warten und rechnet stattdessen den Cluster im Leerlauf ab.
- Kleine, häufige Ladevorgänge machen die Mehrzahl aus. Die meisten Warehouse-Ladevorgänge sind klein und häufig, und das ist die schlechteste Form für eine Abrechnung pro Cluster.
- Die Daten sind bereits in einer Datenbank. Sie werden aus dem Warehouse nach Spark gelesen, transformiert und zurückgeschrieben, wo die Warehouse Engine die Arbeit an Ort und Stelle hätte erledigen können.
Nichts davon ist ein Fehler der Data-Flows. Spark ist für schwere Transformation bepreist. Standard-Warehouse-Ladevorgänge sind nicht schwer.
Wo die Transformation hingehört
- In die Engine, die die Daten hält. Fabric, Synapse, Azure SQL und SQL Server sind alle mengenbasierte Engines. Ein Delta-Load ist ein Statement, das sie gut ausführen.
- Inkrementell als Delta-Load, nicht als vollständiger Durchlauf. Ein generierter Vault-Load vergleicht gegen das, was bereits historisiert ist, und berührt nur, was sich geändert hat.
- Einmal pro Plattform generiert. Mengenbasiertes SQL, abgestimmt auf die Zielengine, nicht pro Flow getunt von dem, der ihn gebaut hat.
Was sich mit Datavault Builder ändert
Datavault Builder generiert mengenbasierte Delta-Loads für Hubs, Links und Satelliten, kompiliert für Fabric, Synapse, Azure SQL oder SQL Server, sodass Standardtransformationen im Warehouse laufen, ohne Cluster dazwischen.
- Keine Spark-Cluster für reguläre Ladevorgänge. Der Load ist ein Statement in der Engine, die die Daten bereits hält. Kein Start, keine Leerlaufzeit.
- Jeder Load ist ein Delta. Nur neue und geänderte Zeilen bewegen sich, die Kosten folgen also dem, wie viel sich die Quelle geändert hat, statt dem, wie groß sie ist.
- Historie wird in Satelliten verwaltet, nicht bei jedem Lauf neu berechnet. Stichtagsabfragen (As-Was) werden aus gespeicherten Änderungen beantwortet, nicht indem die Vergangenheit jede Nacht neu berechnet wird.
- Spark bleibt auf echte Spark-Umfänge beschränkt. Sehr große oder nicht relationale Transformationen können einen Cluster behalten. Sie sind die Ausnahme, und sie bestimmen nicht mehr den Preis von allem anderen.
- Compute-Kosten werden wieder planbar und kalkulierbar. Warehouse Kapazität ist etwas, das Sie reservieren und prognostizieren. Cluster Minuten pro Lauf sind es nicht.
Was zu entscheiden ist
Nehmen Sie die Mapping Data Flow Positionen aus der Azure Rechnung und sortieren Sie die Flows nach verarbeiteten Zeilen pro Lauf. Alles unterhalb des Punktes, an dem ein Cluster-Start mehr kostet als die Arbeit, ist ein Load, der als SQL generiert werden sollte.
Erleben Sie es live mit Ihren eigenen Datenquellen
Buchen Sie eine kostenlose Demo und bringen Sie den Connector mit, der Sie am meisten kostet, an Geld oder an Zeit.
In drei Schritten zu einer Pipeline, die Sie kontrollieren
-
Die Data-Flows nach verarbeiteten Zeilen auflisten
Die meisten sind klein. Ein Cluster pro Lauf für eine kleine Tabelle ist das Kostenproblem in einer Zeile.
-
Die Loads als SQL generieren
Datavault Builder kompiliert mengenbasierte Delta-Loads für Fabric, Synapse, Azure SQL oder SQL Server. Sie laufen dort, wo die Daten sind.
-
Spark für Spark Arbeit behalten
Wirklich große oder unstrukturierte Transformationen können auf einem Cluster bleiben. Die Standard-Warehouse-Ladevorgänge brauchen keinen.
Wie Datavault Builder die Reibungsverluste in der Ingestion beseitigt
-
Ingestion ist eingebaut
Batch-, Delta- und CDC-Ladevorgänge aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka, die als Micro-Batches ankommen. Dieselbe Plattform, die das Warehouse generiert, keine zweite Rechnung.
-
Ihr Schema, nicht das des Anbieters
Quelltabellen werden auf ein Data-Vault-2.0-Modell gemappt, das Sie entworfen haben. Eine neue Spalte oder eine umbenannte Tabelle ändert ein Mapping, keine Kette von Skripten nach dem Load.
-
Nur Deltas bewegen sich
Hubs, Links und Satelliten laden, was sich geändert hat. Vollständige Ladevorgänge bleiben im Staging, statt jede Nacht weiter unten neu verarbeitet zu werden.
-
Historie wird von Haus aus behalten
Jede Änderung wird so festgehalten, wie sie eintrifft. Historien- und Stichtagsabfragen funktionieren also auch dort, wo die Quelle ihre eigenen Zeilen überschreibt.
-
Code, den Sie nie von Hand schreiben
Laden, Historisierung und Lineage werden in Echtzeit aus dem Modell generiert und laufen nativ auf Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle oder PostgreSQL.
-
Eine Plattform, bis zu neun Tools weniger
Modellierung, ETL, CI/CD, Dokumentation und Lineage an einem Ort. Das ist es, was 14,7 Minuten von der Anforderung bis zur Produktion möglich macht.
Ausgezeichnet von BARC im Data Fabric Survey 26
Sprechen Sie mit unserem Experten
Zwanzig Minuten mit unserem Sales Director und eine ehrliche Antwort, ob das zu Ihrem Stack passt.
Matt Collett
Sales Director
Perfekt, wählen Sie einen passenden Termin:
Weitere Probleme in dieser Serie
-
Azure Data Factory Schwachstellen: Die versteckten Kosten von UI-Pipelines und Spark-Transformationen
Azure Data Factory ist eine solide Transportschicht innerhalb von Azure, eignet sich jedoch nicht für die Modellierung und Transformation eines Data Warehouse. Als All-in-One-Lösung führt es zu unübersichtlichen Pipeline-Diagrammen, fehleranfälligen ARM-Deployments und teuren Spark-Clustern für einfache SQL-Loads – und bindet die gesamte Logik unwiderruflich an Azure.
-
Wird jedes Azure Data Factory Release zu einem Kampf mit ARM-Templates?
Unter dem visuellen Editor ist eine Azure Data Factory JSON: Pipelines, Datasets, Linked Services und das ARM-Template, das sie deployt. Eine Änderung von Dev nach Prod zu bringen heißt Parameterdateien, globale Parameter und ein Template, das an einem einzigen Typkonflikt scheitert. Releases sollten aus einem Modell generiert werden, mit dem Rollback inklusive.
-
Ist Ihr Azure Data Factory Canvas dem Team entwachsen, das ihn aufgebaut hat?
Eine Drag-and-Drop-Pipeline ist schnell zusammengeklickt, aber nur langsam anzupassen. Ab ein paar Dutzend Aktivitäten wird das Canvas zur Dokumentation, die visuelle Verdrahtung ersetzt die Fachlogik, und jede neue Quelle ist eine weitere Copy-Aktivität, die niemand anfassen will. Die Lösung ist kein aufgeräumterer Canvas. Es ist ein Modell, das die Pipelines generiert.
Fragen und Antworten
- Es beseitigt das Warten, indem der Cluster warm gehalten wird, und rechnet den warmen Cluster ab. Die Kosten wandern vom Start in die Leerlaufzeit. Die Frage ist, warum ein Standard Warehouse-Ladevorgang überhaupt einen Cluster braucht.
- Nein. Sie laufen auf Spark-Clustern, die von der Azure Integration Runtime verwaltet werden, abgerechnet pro vCore-Stunde. Databricks ist ein separater Dienst mit eigener Preisgestaltung.
- Ja. Die Stored-Procedure- und Script-Aktivitäten tun genau das, und sie sind der faire Vergleich. Das Problem sind Mapping Data-Flows für Standard-Warehouse-Ladevorgänge, und dass die Prozeduren, die diese Aktivitäten aufrufen, weiterhin von Hand geschrieben und gepflegt werden, eine pro Tabelle. Ein generierter Load liefert die Ausführung in der Engine ohne die handgeschriebenen Prozeduren.
- Für mengenbasierte Loads relationaler Daten fast immer: Die Engine hält die Daten bereits und ist genau für diese Arbeit bepreist. Spark verdient seinen Platz bei sehr großen oder nicht relationalen Transformationen, die eine Minderheit der Warehouse-Ladevorgänge sind.