Azure Data Factory – Integration Runtimes

In diesem Beitrag geht es um die Azure Data Factory Integration Runtimes (IR), welche für die Mapping Data Flows verwendet werden, um Datentransformationen auszuführen. Wie bereits im vorherigen Blogpost erwähnt, wird für die Ausführung der Data Flows ADF Spark verwendet, welches in virtuellen Maschinen (VM) läuft. Daher muss ich mir als User keinerlei Gedanken darüber machen, wie diese VMs aufgesetzt werden, sondern ich muss lediglich bestimmen, was für eine VM für meinen Data Flow verwendet werden soll. Und genau das ist im Prinzip eine IR – eine Definition einer virtuellen Maschine, in der die folgenden Fragen beantwortet werden:
  • In welcher Region sollen sich die VMs dieser IR befinden?
  • Für welchen Zweck sollen sie optimiert sein?
  • Wie viele (virtuelle) Kerne sollen sie haben?
  • Wie lange soll eine VM nach ihrer Ausführung weiter existieren (TTL, dazu später mehr)?

Integration Runtimes Übersicht

Eine Übersicht aller IR kann auf der Benutzeroberfläche der ADF unter dem Menüpunkt Connections > Integration Runtimes angezeigt werden. Folglich können diese von dort aus auch angelegt werden:

Die Integration Runtime mit dem Namen „AutoResolveIntegrationRuntime“ist immer verfügbar und kann dynamisch beim Aufrufen eines Data Flows konfiguriert werden kann. Ein Beispiel dafür wird später zu sehen sein. Jede selbst definierte IR hat festgelegte Einstellungen, die – mit Ausnahme der Beschreibung & der Region – nachträglich nicht mehr geändert werden können.

Neue Integration Runtime anlegen

Über den New-Button lässt sich eine neue IR erstellen. Daraufhin öffnet sich auf der rechten Seite ein Overlay, in dem man die Art der IR auswählen muss. Dort wählt man Azure, Self-Hosted aus und im nächsten Dialog Azure.

Anmerkung: Azure bietet zwar  die Möglichkeit, eigene On-Premise (Self Hosted) Server an die ADF anzubinden, allerdings können diese nicht verwendet werden, um Data Flows auszuführen. Sie werden  benötigt, wenn auf Ressourcen zugegriffen werden muss, die in einem privaten Netzwerk liegen, die von Azure aus nicht erreicht werden können.

Hat man alles richtig gemacht, sollte folgendes Fenster sichtbar sein:

Einstellungssache

Während Name und Description selbsterklärend sein sollten, sind die unteren vier Optionen die interessanten. Sie spiegeln die Antworten wider, die ich zu Beginn dieses Beitrages aufgelistet habe:

  • Region: Bestimmt die Region, in der VMs dieser IR erstellt werden sollen. Ist der Standardwert Auto Resolve gesetzt, werden VMs in derselben Region erstellt, in der auch die ADF liegt.
  • Compute type: Gibt an, worauf die VMs dieser IR optimiert werden sollen:
  • Compute Optimized vCore-hour am preiswertesten.
  • Memory Optimized eignet sich für große Datenmengen, sodass Spark mehr Daten im Arbeitsspeicher cachen kann. Da dafür entsprechend mehr RAM benötigt wird, sind diese mit ca. 0,29€ pro vCore-hour am teuersten.
  • Der Standardwert General purpose ist eine Mischung aus den beiden oberen Optionen und sollte in den meisten Fällen ausreichend sein. Mit ca. 0,23€ pro vCore-hour liegt ihr Preis zwischen den beiden anderen.
  • Core count: Definiert die Anzahl der Kerne, welche der VM zur Verfügung stehen. Hier können zwischen acht und 272 Kerne ausgewählt werden. Hier bekommt der oben verwendete Begriff vCore-hour Bedeutung. Anhand diesem lassen sich die ungefähren Kosten für die Ausführung des Data Flows errechnen:

        Anzahl Kerne (vCore) * Computetype Preis * Laufzeit der VM in Stunden

Anmerkung: Je nachdem, was der Data Flow macht, können natürlich noch weitere Kosten für andere Azure-Dienste wie Datenbanken, Storage etc. anfallen.

Alle angezeigten Kosten beziehen sich auf den Stand von Mai. 2020, die aktuellen Kosten können in der Data Pipeline Pricing Übersicht entnommen werden.

  •          Time to live: Mit der TTL-Option wird eingestellt, wie lange eine VM dieser IR nach ihrer Ausführung warm bleiben sollIst dieser Wert größer als 0, wird die VM nicht sofort heruntergefahren, sodass diese für weitere Data Flows verwendet werden kann.

Aufrufen eines Data Flows

Ein Data Flow kann von einer Pipeline aus über die Data Flow Activity aufgerufen werden. In den Einstellungen der Activity muss neben dem auszuführenden Data Flow auch die IR ausgewählt werden, die verwendet werden soll – hier kommt die AutoResolveIntegrationRuntime ins Spiel.

Wird diese ausgewählt, können Compute type und Core count dynamisch eingestellt werden. Es können Pipeline Expressions verwendet werden oder die Einstellungen können beispielsweise über eine Lookup-Activity aus einer Datenbank geladen werden.

Wählt man eine eigens definierte IR aus, lassen sich diese
Einstellungen nicht mehr anpassen. Doch wieso sollte man dann überhaupt eigene
IR definieren, wenn die wichtigsten Einstellungen auch hier vorgenommen werden
können 🤔?

 

Hier kommt die TTL-Einstellung ins Spiel, die es bei der AutoResolveIntegrationRuntime
nicht gibt.

"Time to Live" - Einstellung

Mit der Time to Live Einstellung wird definiert, wie lange eine VM einer IR nach Durchführung eines Data Flows warm – also am Leben – bleiben soll. Auf den ersten Blick sieht diese Funktion kontraproduktiv aus, denn solange die VM hochgefahren ist, produziert sie Kosten. Doch so unnütz ist diese Funktion nicht – sonst hätte sie Microsoft wohl nicht implementiert 🤯.

Soll ein Data Flow ausgeführt werden, schaut die ADF als allererstes, ob es bereits eine warme, untätige VM im Pool gibt, die zur Ausführung des Data Flows verwendet kann und mit den Einstellungen der IR übereinstimmt. Ist dies der Fall, muss lediglich ein neues Spark-Cluster bereitgestellt werden, was zwischen einer bis zwei Minuten dauert.

Wird keine warme IR in diesem Pool gefunden, muss natürlich vorerst eine neue VM erstellt werden. Zwar produziert das Hochfahren einer VM keine Kosten, allerdings dauert dies im Durchschnitt etwa fünf Minuten. Hinzu kommt noch die Zeit, die benötigt wird, um das Spark-Cluster zur Verfügung zu stellen. Es dauert also zwischen sechs und sieben Minuten, bis der Data Flow letztendlich verarbeitet werden kann.

Führt ein ETL-Prozess also mehrere Data Flows sequenziell aus, lässt sich die Gesamtlaufzeit durch Verwendung der TTL-Einstellung bemerklich verringern 🥳.

Schlusswort

Zusammenfassend lässt sich mit Hilfe von Integration Runtimes auf eine einfache Art bestimmen, mit welcher Hardware ein Data Flow ausgeführt werden soll. Um die eigentliche Bereitstellung der virtuellen Maschinen und deren Spark Cluster muss man sich als Entwickler jedoch keinerlei Gedanken machen. So lässt sich die Hardware, die zur Ausführung eines Data Flows verwendet werden soll, ohne große Probleme hoch- bzw. runterskalieren, indem dem Data Flow einfach
eine andere Integration Runtime zugeteilt wird.

 

Nachdem ich in diesem Beitrag auf die Integration Runtimes eingegangen bin, werde ich im nächsten Beitrag auf die Interaktive Data Flow Entwicklung eingehen und zeigen, welche Möglichkeiten zum Debugging und Testen die Data Factory ebendieser bereitstellt. 

Teilen:

Share on xing
Share on email
Christopher Münch

Christopher Münch

Christopher Münch hat in seiner Ausbildung erfolgreich einen Bachelor in Informatik abgelegt. Zudem verfügt er über langjährige Erfahrung im Umgang mit dem .NET Framework, der Programmiersprache C# und den Business Intelligence Umgebungen rund um den Microsoft SQL Server.

Schreiben Sie einen Kommentar