Ist Ihr Azure Data Factory Canvas dem Team entwachsen, das ihn aufgebaut hat?

Azure Data Factory ist das Standard-Integrationstool in jeder Azure-Landschaft, und für eine Handvoll Aktivitäten ist es genau richtig: Copy-Aktivität ziehen, auf eine Quelle richten, fertig. Die Probleme beginnen, wenn derselbe Ansatz für das ganze Warehouse verwendet wird und der Canvas Hunderte Aktivitäten hält, die nur die Leute lesen können, die sie gebaut haben.

Warum das Canvas nicht mehr skaliert

• Das Canvas ist die Dokumentation. Hinter einer Pipeline steht kein Modell, nur die Verknüpfungen. Was eine Pipeline tut, ist das, was ihre Bausteine und Pfeile tun, und das muss Baustein für Baustein gelesen werden.
• Jede Quelle ist eine Kopie der letzten. Für eine neue Tabelle duplizieren Sie eine Kette aus Copy-Aktivitäten, Lookups und Stored-Procedure-Aufrufen und bearbeiten anschließend jeden Schritt. Dass die Kopien mit der Zeit auseinanderlaufen, ist sicher.
• Änderungen werden von Hand in einer UI gemacht. Ein falsch gesetzter Abhängigkeitspfeil oder eine falsche Dataset-Referenz sieht korrekt aus, bis es läuft.
• Teamarbeit endet in komplexen JSON-Merges. Zwei Personen, die eine Pipeline in zwei Branches bearbeiten, treffen sich in einem Merge von generiertem Pipeline-JSON, und das reviewt niemand mit Zuversicht.

Das ist kein Designfehler von ADF. Ein Canvas ist das richtige Werkzeug, um ein paar Dinge zu orchestrieren, und das falsche, um ein Datenmodell auszudrücken.

Wo Orchestrierung und Logik hingehören

• In ein zentrales Modell statt auf ein Canvas. Business-Keys, Beziehungen und Attribute sollten einmal deklariert werden, und die Pipelines, die sie laden, aus dieser Deklaration abgeleitet werden.
• Generierter Code schützt vor Code-Drift. Wenn alle Staging- und Vault-Loads aus demselben Generator kommt, gibt es keine Version pro Quelle, die synchron zu halten wäre.
• Die Orchestrierung gehört zu den Loads. Datavault Builder führt Loads gebündelt als Jobs aus, in der richtigen Abhängigkeitsreihenfolge, mit Logging und Neustart. Für ADF bleiben Dateitransfers, Events und ein Trigger.

Was sich mit Datavault Builder ändert

Datavault Builder hält das Warehouse in einem visuellen Modell und generiert daraus die Staging, Historisierungs- und Auslieferungs-Loads, nativ auf Fabric, Synapse, Azure SQL oder SQL Server.

• Sie modellieren das Fachliche, den Rest baut die Plattform. Beschreiben Sie Entitäten, Schlüssel und Beziehungen einmal; Hubs, Links, Satelliten und sämtliche Loads werden daraus generiert. Es gibt keinen Canvas, der mit der Realität synchron zu halten wäre.
• Eine neue Quelle ist ein Mapping. Landing-Tabelle auf das Modell mappen und neu generieren. Keine Kette aus Aktivitäten, die zu kopieren und anzupassen wäre.
• Das Modell ist lesbar. Geschäftskonzepte, Schlüssel und Lineage sind an einem Ort sichtbar, für Fachanwender genauso wie für Engineers.
• Änderungen werden als Modelländerungen reviewt. Git und Gitflow-Unterstützung mit generierten Deployment- und Rollback-Skripten, statt eines Merge von Pipeline-JSON.
• ADF konzentriert sich auf seine Kernstärke. Dateitransfers und Events können weiterhin über ADF laufen, und es kann einen Datavault-Builder-Job auslösen. Die Orchestrierung der Loads selbst bleibt in der Plattform.

Was zu entscheiden ist

Öffnen Sie Ihre größte Orchestrierungspipeline und zählen Sie die Aktivitäten, die nur existieren, um pro Quelle zu kopieren, nachzuschlagen oder eine Stored Procedure aufzurufen. Diese Zahl ist der Teil des Canvas, den ein Modell generieren sollte.