Der Lage­rung gro­ßer Men­gen unstruk­tu­rier­ter Daten bei­spiels­weise im Azure Blob Sto­rage, der auf­grund sei­ner hohen Ska­lier­bar­keit und kos­ten­ef­fi­zi­en­ten Spei­che­rungs­mög­lich­keit eine beliebte Mög­lich­keit in der Azure Cloud Umge­bung bie­tet, folgt häu­fig die Bela­dung des Azure Data Warehou­ses, jetzt Azure Syn­apse Ana­ly­tics. Eine kom­for­ta­ble Mög­lich­keit bie­tet hier die Ver­wen­dung der Azure Data Factory.

Die Azure Data Fac­tory kann über­sicht­lich ETL und ELT Vor­gänge ent­we­der durch Ver­wen­dung eigens geschrie­be­nen SQL-Codes, oder ohne Code durch Aus­wahl der pas­sen­den Ein­stel­lun­gen und per Drag und Drop erstel­len. Dadurch ist sie ers­ter Anlauf­punkt, wenn Daten im Syn­apse Ana­ly­tics inte­griert wer­den sol­len. Zum Daten­trans­fer wer­den hier als eine Mög­lich­keit Pipe­lines erstellt, die einen Rah­men für die jewei­li­gen gewünsch­ten Akti­vi­tä­ten dar­stel­len. Eine Pipe­line besteht aus einer oder meh­re­ren Acti­vi­ties, die defi­nie­ren, wie die Daten trans­for­miert wer­den sol­len, von einem ein­fa­chen Copy-Job bis hin zu kom­ple­xen Transformationen.

Bei­spiel­haft sol­len fol­gend die Daten einer Datei aus dem Azure Blob Sto­rage in Azure Syn­apse Ana­ly­tics ver­scho­ben wer­den, dabei wer­den die ein­zel­nen Schritte beschrie­ben und im Zuge des Kopie­rens auf die Vor­teile des Ladens mit Poly­Base eingegangen.

Zunächst wird auf dem Start­bild­schirm der Data Fac­tory Create Pipe­line aus­ge­wählt.

Es wird eine neue Pipe­line mit Namen pipeline1 ange­legt. Unter Acti­vi­ties – Move & Trans­form kann die Funk­tion Copy Data aus­ge­wählt und in das Fens­ter gezo­gen werden.

Unter den Rei­tern Source  und Sink wird der Input- (bei­spiels­weise aus dem Azure Blob Sto­rage) und der Out­put-Daten­satz (Ziel­da­ten­satz im Syn­apse Ana­ly­tics) definiert. 

Die Zuord­nung der Spal­ten erfolgt über den Rei­ter Map­ping. Auto­ma­tisch erfolgt das Map­ping über die Spal­ten­na­men, bei Bedarf kann auch eine expli­zite Spal­ten­zu­wei­sung ange­ge­ben werden.

Unter dem Sink Rei­ter ste­hen drei ver­schie­dene Copy-Metho­den zur Ver­fü­gung. Poly­Base, Copy com­mand (Pre­view) und Bulk insert. Bulk insert ist stan­dard­mä­ßig aus­ge­wählt, die ande­ren bei­den Metho­den sind jedoch wesent­lich per­for­man­ter. Im Fol­gen­den wird ins­be­son­dere auf die Vor­teile des Kopie­rens mit Poly­Base eingegangen.

Poly­Base ist die per­for­man­teste und am Bes­ten ska­lier­bare Bela­de­me­thode. Der Durch­satz kann im Ver­gleich zur Bulk-Insert Methode erheb­lich gestei­gert wer­den. Poly­Base kann Daten aus rela­tio­na­len Daten­ban­ken (wie bei­spiels­weise die Syn­apse) mit Daten aus nicht-rela­tio­na­len Daten­ban­ken (Hadoop, Blob Sto­rage, Data Lake Sto­rage) auf Abfrage-Level mit Stan­dard-T-SQL ver­ei­nen. Um Kopie­ren mit Poly­Base aus­füh­ren zu kön­nen, müs­sen einige Eigen­schaf­ten erfüllt werden.

Zunächst müs­sen die Quell­da­ten in einem Poly­Base-kom­pa­ti­blen For­mat vor­lie­gen. Dar­un­ter fällt das Parquet‑, das ORC- oder das Text­for­mat mit Trenn­zei­chen. Dar­über hin­aus muss der User über die Berech­ti­gung Con­trol für die Ziel­da­ten­bank ver­fü­gen. Daten­zei­len dür­fen nicht grö­ßer als 1MB sein und die Ziel- und Bela­de­ta­belle müs­sen gleich viele Spal­ten haben. Zusätz­lich erweist sich ein Load mit CTAS (Create Table As Sel­ect) als per­for­man­ter als ein INSERT INTO. Bei einer Bela­dung mit der Data Fac­tory ist aller­dings INSERT INTO die stan­dard­mä­ßige Form. Ein CTAS kann bei­spiels­weise durch das Erstel­len einer Stored Pro­ce­dure aus­ge­wählt wer­den. Soll­ten ins­be­son­dere die Anfor­de­run­gen an die Größe der Tabelle nicht ein­ge­hal­ten wer­den kön­nen, emp­fiehlt es sich, die Tabelle in meh­rere Teil­ta­bel­len (ver­ti­kal) zu tren­nen, zu kopie­ren und anschlie­ßend wie­der zusam­men zu mergen.

Soll­ten Vor­ga­ben nicht erfüllt wer­den kön­nen, besteht dar­über hin­aus die Mög­lich­keit, die Daten mit Hilfe des gestaf­fel­ten Kopie­rens mit Poly­Base zu kopie­ren. Die­ser Vor­gang bringt die Quell­da­ten auto­ma­tisch in ein kom­pa­ti­bles For­mat, spei­chert die Daten im Blob Sto­rage zwi­schen und lädt sie anschlie­ßend nach Syn­apse. Der zusätz­li­che Schritt des Zwi­schen­spei­cherns ver­lang­samt den Pro­zess aller­dings. Der Vor­gang des gestaf­fel­ten Kopie­rens ermög­licht es zudem, auch on-pre­mise Daten mit ein­zu­bin­den. Hier wer­den die Daten durch Poly­Base auto­ma­tisch in einem Azure Sto­rage Account zwi­schen­ge­spei­chert und anschlie­ßend in die Syn­apse gela­den. Wer­den die Bedin­gun­gen für Poly­Base nicht erfüllt und kein gestaf­fel­tes Kopie­ren gewählt, wird auto­ma­tisch zu Bulk-insert gewechselt.

Wesent­li­cher Grund für die per­for­man­tere Bela­dung mit Poly­Base ist das Umge­hen des Con­trol Nodes  und somit die Mög­lich­keit, die Daten direkt auf die com­pute nodes zu brin­gen ohne einen vor­he­ri­gen Ver­teil­me­cha­nis­mus abar­bei­ten zu müs­sen. Die Daten wer­den so direkt an die Ver­ar­bei­tung gegeben.

Im Fol­gen­den wird exem­pla­risch eine Daten­quelle mit Poly­Base und zum Ver­gleich mit dem stan­dard­mä­ßi­gen BULK INSERT vom Azure Blob Sto­rage in die Syn­apse ver­scho­ben. Die gewählte Syn­apse hat 400 Data­Ware­house­U­nits (DWUs) zur Ver­fü­gung und läuft auf einer compute-node.

Der erste Daten­satz ent­hält eine Mil­lio­nen Daten­sätze und 40 Spal­ten und hat eine Gesamt­größe von 230MB. Der zweite Daten­satz  hat 45 Mil­lio­nen Daten­sätze, 7 Spal­ten und eine Gesamt­größe von drei GB. Im ers­ten Fall wurde eine csv Datei ver­scho­ben, der zweite Fall ver­schiebt 10 csv Files aus einem gemein­sa­men Unter­ord­ner. In bei­den Fäl­len wird genau eine Tabelle in der Syn­apse neu ange­legt und beladen.

Zunächst zeigt sich, dass kleine Dateien mit Poly­Base wesent­lich schnel­ler ver­scho­ben wer­den kön­nen als mit Bulk Insert. Zen­tra­ler noch zeigt sich, dass eine starke Auf­sto­ckung der Anzahl an Daten­sät­zen für Poly­Base kei­nen Unter­schied macht, inso­fern die Daten sinn­voll getrennt abge­legt wer­den. Wird bei­spiels­weise ein Daten­satz mit Spark sepa­riert nach Par­ti­tio­nen in dem Blob Sto­rage abge­legt und als Quell­ord­ner eines Copy-Jobs für Poly­Base ange­ge­ben, macht es kei­nen Unter­schied, ob 1 Mil­lio­nen Daten­sätze, 50 oder 100 Mil­lio­nen Daten­sätze ver­scho­ben werden.

Somit zeigt sich, dass beim Ver­schie­ben von Daten unbe­dingt auf Poly­Base zurück­zu­grei­fen ist und im Zwei­fel der Auf­wand einer Aufbereitung in ein kom­pa­ti­bles For­mat loh­nens­wert ist, da durch diese Art des Daten­trans­fers starke Per­for­mance­ver­bes­se­run­gen erreicht wer­den kön­nen. Unter Zuhil­fe­nahme der Azure Data Fac­tory lässt sich der Vor­gang ein­fach und über­sicht­lich aufbauen.