Azure Data Factory (Teil 3)

Data Flows

Im letzten Beitrag zur Azure Data Factory habe ich über die ein oder anderen Komponenten der ADF berichtet. Da ich den letzten Beitrag mit den DataFlows beendet habe, werde ich in dem jetzigen genau dort anknüpfen und etwas mehr ins Detail gehen.  

Data Flow Arten

Beim Anlegen eines Data Flows erscheint ein neues Fenster am rechten Rand des Bildschirms. In diesem Fenster wird man dazu aufgefordert eine Entscheidung zu treffen, ob man Mapping oder Wrangling Data Flows verwenden möchte. Hier stellt sich dann jedoch die Frage wo die Unterschiede liegen und für welchen Verwendungszweck sich welche Art besser eignet.

Mapping Data Flow

Bei den Mapping Data Flows liegt der Fokus auf der visuellen Transformation und der Logik der Daten. Die ADF übersetzt diese Transformationen im Hintergrund in Code, der aus Performance- gründen auf Azure Databricks Clustern ausgeführt wird. Dieses Prozedere ähnelt sehr stark der Erstellung von Data Flows in SSIS.

Wrangling Data Flow

Die Wrangling Data Flows werden verwendet, um die zugrunde liegenden Daten zu untersuchen und aufzubereiten. Der Fokus liegt dabei auf der Modellierung und Logik der Daten. Die Benutzer-oberfläche ähnelt sehr stark der des Power Query Editors. Hier werden die Transformationen in M-Code (Mashup) übersetzt und in einer Spark-Umgebung ausgeführt.

Abwägungssache

 

Alles in allem ist es auch eine Geschmacksfrage. Wenn man die beiden Arten der Data Flows genauer miteinander vergleicht, sieht man schnell einige Parallelen zwischen ihnen. Beispielsweise benutzen beide Arten die selben Quell- und Zielstrukturen (Azure Blob-Storage, Data Lake Storage…). Auch bei der Transformation der Daten werden sowohl bei Mapping- als auch bei Wrangling Data Flows Spalten umbenannt, Datensätze zusammengefügt etc.

Nun ist es neben der eigens präferierten Vorgehensweise so, dass es natürlich auch Szenarien gibt, bei denen es sich anbietet, sich gezielt zu entscheiden. Falls man unsicher sein sollte für welche Art man sich entscheiden soll, kann man diese Entscheidung auch vom eigentlichen Vorhaben abhängig machen. 

Möchte man Fakten- und Dimensionstabellen beladen, bietet es sich an, die Mapping Data Flows zu verwenden. In diesem Fall sind sowohl das Quell- als auch das Ziel-Schema der Beladung bekannt. Zusätzlich hat man die Möglichkeit, sich der Funktionalität der Slowly Changing Dimension zu bedienen.

Möchte man hingegen ein neues Dataset erstellen und ist sich nicht ganz sicher, ob alle benötigten Daten vorhanden sind, bieten sich die Wrangling Data Flows an. Diese geben einen schnelleren und einfacheren Überblick über die zugrunde liegenden Daten.

Beispiel: Mapping Data Flow

So viel zur Theorie. Nun werde ich einen kleinen Einblick in das Innere der Mapping Data Flows gewähren. In diesem Beispiel werde ich zeigen, wie wir zuvor angelegte Datasets verwenden um Daten aus einer Flat-File im .csv-Format in die Datenbank zu laden. 

Bildschirmfoto Blogbeitrag ADF
zum Vergrößern bitte klicken

Wie Ihr in dem Bild sehen könnt, habe ich bereits einen Data Flow erstellt. Auf der linken Seite habe ich die beiden bereits erzeugten Datasets mit nummerierten Badges versehen. Das Dataset mit der Ziffer 1 beinhaltet die Struktur bzw. die Daten unserer csv-Datei. Das darunterliegende Dataset beinhaltet die Struktur unserer Datenbanktabelle mit dem Namen Tag. Dieses benötigen wir später um die Daten in unsere Datenbank zu schreiben. Die Punkte 3 und 4 zeigen uns die Data Flow Quelle. In diesem Beispiel bedienen wir uns an dem Dataset DS_FF_YoutubeTrending, welches auf einer csv-Datei basiert. Im durch die Nummer 4 gekennzeichneten Bereich sehen wir „Bedienoberfläche“ unserer angelegten Quelle. An dieser Stelle benennen wir unsere Quelle und geben an, von welchem Typ unsere Quelle sein soll. In diesem Fall ist es ein Dataset. Des Weiteren stehen allerdings auch XML, Excel und Delta zur Verfügung. Kommen wir zu den Menüpunkten in unserer Source.

weitere Einstellungen

Nr 5
zum Vergrößern bitte klicken

Wie ihr sehen könnt, zeigt der Reiter „Projection“ uns die Spaltennamen aus unserem Dataset. Die Spaltennamen sind weder praktisch noch optisch ansprechend. Aus diesem Grund bediene ich mich im nächsten Schritt an der Liste der Transformation (6) und wähle die Select-Transformation (7) aus. „

die SELECT-Transformation

Konfigurationseinstellungen
zum Vergrößern bitte klicken

Die Select Transformation (7) bietet uns die Möglichkeit, die eingehenden Spalten anders zu benennen, zu duplizieren und das Duplikat unter einem anderen Namen im weiteren Verlauf des Data Flows mitzunehmen oder vorhandene Spalten zu löschen (8).

SELECT-Tranformation und SPALTEN LÖSCHEN
zum Vergrößern bitte klicken

Spalten umbenennen

Im unteren Bild kann man unter dem Reiter Inspect das Resultat der Umbenennung, des Hinzufügens oder Löschens von Spalten einsehen(9).

zum Vergrößern bitte klicken

Die Umbenennung von Spalten ist insofern praktisch, weil man bei identischer Benennung von Input- und Zielspalten im Ziel-Dataset (11) unter dem Reiter Mapping (12) von der Möglichkeit des Automappings (13) profitiert. Das Ziel unseres Data Flows ist die SNKTag (10), welche durch das zu Beginn gezeigte zweite Dataset direkt auf unsere Tabelle in der Datenbank verweist. Hier sieht man, dass die Spalte TagID nicht zugeordnet wird. Zugegebenermaßen wäre dies auch durch eine manuelle Zuordnung nicht möglich, bot sich jedoch für dieses Beispiel prima an. Die Ursache dafür liegt ganz einfach darin, dass unsere Quelle diese Spalte gar nicht beinhaltet. 

Abschlussarbeiten
zum Vergrößern bitte klicken

Was erwartet euch im nächsten Beitrag?

In meinem dritten Teil über die Azure Data Factory bin ich näher auf die Data Flows und deren Arten bzw. Anwendungsmöglichkeiten eingegangen. Im nächsten Teil der Blog-reihe über die Azure Data Factory werde ich genauer auf die Benutzung der Mapping Data Flows und die übrigen Transformationsmöglichkeiten eingehen, die Funktionsweise der dort verwendeten Komponenten näher erläutern und eventuell auch auf den ein oder anderen besonderen Kniff eingehen. Bis dahin eine angenehme Zeit und bleibt gesund. 

PS: Gerne dürft Ihr uns eure Fragen, Themenvorschläge oder sonstige Anregungen zukommen lassen.

Teilen:

Share on xing
Share on email
Kevin Taxweiler

Kevin Taxweiler

Kevin Taxweiler kann auf einen Bachelor in Informatik zurückgreifen. Dazu hat er erfolgreich die Zertifizierung zum Microsoft Certified Solution Expert (MCSE) mit dem SQL Server 2016/Power BI abgelegt.

Schreiben Sie einen Kommentar

Blog abonnieren:
Loading

Weitere Beiträge: