Azure Data Factory – wprowadzenie do usługi

Azure Data Factory wykorzystywany jest jako narzędzie do automatycznej integracji danych znajdujących się wewnątrz chmury, sieci lokalnych lub wszelkiego rodzaju środowisk hybrydowych. Zanim przejdę do omówienia samej usługi zastanówmy się przez chwilę nad problemem załadowania danych, rozsianych w wielu niezależnych miejscach,  do jednej bazy danych.

ETL – Extract, Transform and Load

Azure Data Factory ściśle powiązane jest z popularnymi. zwłaszcza w hurtowniach danych (data warehouses), procesami ETL (Extract, Transform, Load). Dane mogą być pobierane (Extract) z kilku źródeł. Z najpopularniejszych można wymienić: wszelkiego rodzaju bazy danych (te relacyjne i te nierelacyjne), pliki z danymi (np. o rozszerzeniach *.json, *.xml), udostępnione za pośrednictwem serwera FTP, API REST’owe czy strumienie danych IoT.

Następnie skompletowane dane mogą być poddane wstępnej obróbce (Transform) poprzez wykorzystanie wszelkiego rodzaju kalkulacji, przetworzeń czy choćby konwersji. Ponadto dokonuje się tutaj agregacji wszystkich zgromadzonych danych, tak aby można było stworzyć jeden spójny strumień.

Na sam koniec przetworzone dane zostają załadowane (Load) do docelowego (niekoniecznie jednego) pojemnika. Przykładowy proces ETL został przedstawiony na poniższym schemacie:

Przykładowy proces ETL
Przykładowy proces ETL

Azure Data Factory

Data Factory wykorzystywane jest podczas realizacji naprawdę dużych przepływów, zwłaszcza w przypadku, gdy poruszamy się w środowisku Big Data. Rekordy z danymi mogą być transportowane pomiędzy wybranymi komponentami Azure’owymi, takimi jak np.: Blob Storage, SQL Data Warehouse czy choćby Azure SQL Database. Jak wspomniałem powyżej, możliwa jest współpraca z usługami, działającymi nie tylko w chmurze, a w środowisku hybrydowym, mianowicie w trybie on-premises environment.

Z pośród najpopularniejszych serwisów transformujących dane można wymienić usługi HDInsight czy Azure Data Lake Analytics. Ideą Azure Data Factory jest automatyzacja dowolnego procesu ETL, poprzez stworzenie tzw. potoku (pipeline), odpowiedzialnego za załadowanie, przetworzenie i dostarczenie danych do przeznaczonego pojemnika. Potoki mogą być uruchamiane w dowolnym momencie jak i zgodnie z pewnym, wcześniej zaplanowanym harmonogramem.

Przygotowanie danych

Zanim przejdziemy do konfiguracji potoków proponuję przygotować sobie jakieś dwa, dowolne, kontenery na dane (źródłowe i docelowe). W moim przypadku będzie to zwykła relacyjna baza danych (np. SQL Server) oraz Azure Storage Account – a dokładniej Azure Blob Storage. Magazyn danych posłuży mi jako źródło z danymi. Proponuję wgrać do niego dowolny plik *.csv z danymi (posłużę się tutaj przykładowym plikiem dostępnym pod następującym adesem).

Uwaga jeśli zdecydowałeś się skorzystać z zamieszczonego powyżej pliku grades.csv musisz wprowadzić małą poprawkę do zbioru. W wierszu 10 dla studenta Andrew Airpump należy dopisać przecinek po wartości 49.0 dla 5 kolumny (Test1) – małe niedopatrzenie ze strony autora zbioru 🙂 Zbiór można również nieco oczyścić usuwając wszystkie spacje.

W przypadku SQL Servera proponuję stworzyć pustą bazę danych, a następnie dodać tabelę na dane. Jeśli zdecydujesz się skorzystać z wspomnianego przeze mnie pliku *.csv, możesz skorzystać z poniższego skryptu *.sql generującego odpowiednią tabelę w bazie danych:

Tworzymy pierwsze potoki do kopiowania danych

Teraz możemy zabrać się za Azure Data Factory. Dodajemy nowy komponent podając nazwę, region oraz grupę zasobów. Na dzień dzisiejszy proponuję wybrać wersję V1 (V2 jest na razie tylko w stanie preview). Gdy usługa będzie już w gotowa klikamy w nią, a następnie z wszystkich dostępnych akcji, wybieramy Copy Data (Preview). W przeglądarce zostanie otwarta nowa zakładka z kreatorem potoków Azure Data Factory.

Zaczynamy od podania nazwy oraz opcjonalnego opisu potoku. Następnie deklarujemy, czy potok powinien zostać uruchomiony jednorazowo, czy według ustawionego harmonogramu. W przypadku pojedynczego uruchomienia, należy skonfigurować tzw. expiration time – przed upłynięciem którego potok powinien się zakończyć. Jeżeli czas ten zostanie przekroczony, potok zostanie automatycznie przerwany. W przypadku harmonogramu dodatkowo definiujemy szczegółowe reguły, według których potok będzie uruchamiany, np. raz w miesiącu:

Definicja nowego potoku w usłudze Azure Data Factory
Definicja nowego potoku w usłudze Azure Data Factory

 

Na razie zdecydujemy się na potok jednorazowy (Run once now). Następnie przechodzimy do wyboru źródła danych.

Konfiguracja źródła danych wejściowych oraz kontenera na dane wyjściowe

Klikamy w Azure Blob Storage, a następnie wpisujemy nazwę połączenia, wskazujemy subskrypcję oraz konto magazynu danych. Teraz wskazujemy na interesujący nas kontener, a później plik *.csv lub cały folder (jeśli takowym dysponujemy). Rekursywne kopiowanie plików dostępne jest tylko w przypadku, gdy dane będą pobierane z folderu. Binary copy na razie zostawiamy odznaczone, nie chcemy, żeby pliki były traktowane binarne, z pomięciem schemy charakterystycznej dla plików *.csv. Pomijamy również jakiekolwiek ustawienia dotyczące kompresji danych.

Następnie przesłany plik zostanie przeanalizowany pod kątem formatu i struktury. Jest to plik *.csv, w którym kolumny porozdzielane są za pomocą przecinków, natomiast wiersze za pomocą znaku nowej linii oraz powrotu karetki (\n\r). Zaznaczamy opcję, wskazującą pierwszy wiersz danych jako nazwy kolumn (The first data row contains column names). Poniżej znajduje się jeszcze okno poglądu (preview) załadowanych danych. Można tutaj sprawdzić czy dane zostały posegregowane prawidłowo oraz czy wykorzystana schema jest poprawna:

Konfiguracja źródła danych wejściowych
Konfiguracja źródła danych wejściowych

 

Przechodzimy do konfiguracji wyjścia potoku. W naszym przypadku wybieramy Azure SQL Database. Następnie wprowadzamy wszystkie dane, niezbędne do nawiązania połączenia z bazą. Jeżeli uruchomiłeś na bazie skrypt *.sql podany przeze mnie powyżej spośród wszystkich dostępnych tabel powinieneś być w stanie wybrać tabelę dbo.Grades. Kliknąć w strzałkę, znajdującą się po prawej stronie, możesz podejrzeć dostępne już na tabeli dane (o ile tam są) oraz schemę tabeli. Teraz zajmiemy się konfiguracją mapowania.

Mapowanie danych

Można tutaj zdecydować, czy wszystkie pola z pliku źródłowego mają być przeniesione do bazy danych. Dodatkowo możesz podejrzeć na jakie typy, w bazie danych, będą mapowane poszczególne kolumny z pliku *.csv. Ustawienia powtarzalności danych (Repeatability settings) proponuję na razie pozostawić bez zmian (none):

Konfiguracja mapowania danych
Konfiguracja mapowania danych

 

Na samym końcu pozostaje jeszcze kilka ustawień związanych z przerywaniem potoku w sytuacji, gdy spotkamy się z pierwszym niepoprawnym wierszem lub konfiguracja pracy w trybie równoległym – ile wykorzystać jednostek itp. W zakładce podsumowanie znajdziesz szczegółowy opis skonfigurowanego przez Ciebie potoku kopiowania danych z jednego miejsca do drugiego. Mam nadzieję, że po zakończonym deployment’cie spotkasz się z rezultatem podobnym do mojego:

Podsumowanie wykonanego potoku
Podsumowanie wykonanego potoku

 

Proponuję teraz połączyć się z bazą danych i podejrzeć zawartość tabeli dbo.Grades. Jeśli wszystko zostało wykonane poprawnie, powinieneś ujrzeć dane, znajdujące się wcześniej w pliku *.csv.

Myślę, że na dzisiaj już wystarczy 🙂 Był to pierwszy artykuł rozpoczynający przygotowaną przeze mnie mini serię dotyczącą Azure Data Factory. Wierzę, że najbliższym czasie Microsoft wypuści nową wersję V2, dostępną na razie tylko w fazie preview.