Azure Data Factory – Copy Data Wizard

Technologie chmurowe to bez wątpienia temat niezwykle istotny dla każdego kto jest związany z branżą IT. Bez względu na to czy jesteś developerem, administratorem czy też managerem powinieneś być na bieżąco z najnowszymi trendami panującymi na rynku. W projekcie w który aktualnie jestem zaangażowany prym wiedzie polityka cloud first dlatego też coraz więcej produktów chmury Azure związanych z przetwarzaniem danych wchodzi w użycie. Stąd też postanowiłem napisać na blogu kilka artykułów poświęconych usługom chmury Microsoftu. Na samym początku postanowiłem wziąć na warsztat Azure Data Factory czyli usługę dedykowaną do przerzucania, transformowania oraz orkiestracji danych. Dziś zrobimy sobie krótki wstęp oraz powiemy sobie czym jest Copy Data Wizard, ale spodziewajcie się kontynuacji tej serii (zachęcam do subskrypcji).

Azure Data Factory jest usługą dostępną w ramach subskrypcji Azure. Nie jest to usługa darmowa i jesteśmy rozliczani za jej rzeczywiste użycie tzn. płacimy tylko za te zasoby które rzeczywiście używamy. Nie będę zbyt wiele pisał o pricingu, umowach licencyjnych i SLA, a skupię się wyłącznie na aspektach technicznych – zainteresowanych odsyłam do dokumentacji gdzie znajdziecie te wszystkie informacje (Pricing, SLA).

Pierwszą rzeczą na jaką możecie natrafić szukając informacji na temat Data Factory jest to, że istnieją dwie wersje tego narzędzia oznaczone kolejno v1 oraz v2. V1 jak możecie się domyślać jest to pierwsza implementacja narzędzia wprowadzona w 2014 roku, która pozwalała stworzyć podstawowe przepływy, ale w gruncie rzeczy była bardzo ograniczona w możliwościach. Wersja druga czyli v2 pojawiła się w 2017 roku i była to usługa zdecydowanie bardziej rozbudowana i bogata w możliwości. Nie będę rozpisywał poszczególnych różnic między wersjami bo szkoda na to miejsca i czasu ale warto pamiętać, że obecnie V2 to ta wersja, która jest aktualizowana i to właśnie ją powinniście wybierać w swoich projektach. O V1 warto pamiętać w ramach ciekawostki lub całkowicie wymazać z pamięci 🙂

Podstawowy schemat działania Data Factory wygląda następująco:

Mamy zatem źródła danych, które mogą znajdować się zarówno w naszej infrastrukturze on-premises jak i w chmurze. Z tych właśnie źródeł możemy pobierać interesujące nas dane, dostosować do naszych potrzeb i umieścić w miejscu docelowym takim jak np. baza danych SQL, BLOB Storage czy chociażby Azure Synapse. Powyższa grafika może nieco przypominać procesy ETL (Extract Transform Load) gdzie narzędzie transformuje dane zgodnie z naszymi potrzebami jednak warto zauważyć, że szczególnie uwypuklona jest tutaj rola dwóch kroków, a mianowicie Ingest (pobranie danych ze źródła) i Publish (opublikowanie danych w miejscu docelowym). W moim odczuciu to właśnie te dwa kroki bardzo dobrze obrazują większość przypadków w których ADF będzie dla nas użyteczny. Chodzi tutaj o podejście ELT czyli ekstrakcja (na obrazku widoczna jako Ingest), ładowanie (Publish) danych i ich transformowanie w miejscu docelowym. Jest to bardzo ciekawe podejście, które wykorzystuje możliwości transformowania danych wbudowane w narzędzia do których dane ładujemy jak np. oparte o technologię MPP (Massive Parallel Processing) Azure Synapse. Jeśli jednak nasza architektura przewiduje konieczność transformowania danych w ADF to również jest to możliwe dzięki komponentom takim jak Data flows.

Scenariuszy jest całkiem sporo i przedstawione wyżej podejścia z całą pewnością nie wyczerpują możliwości narzędzia. Warto wzmianki jest to, że jeśli z poziomu Data Factory chcielibyśmy uruchamiać np. procedury składowane w SQLu, kawałki kodu napisane w ramach Azure Functions czy np. skrypt powershellowy w Azure Automation to nie ma tutaj najmniejszego problemu. Siłą ADF jest integracja z innymi usługami Azure i możliwość orkiestracji zadań. Właśnie w ramach tego narzędzia jesteśmy w stanie stworzyć przepływ zadań angażując jedno lub wiele usług chmury.

Najlepiej poznać narzędzie poprzez praktykę dlatego też po tym krótki wstępie przejdźmy do portalu Azure gdzie stworzymy sobie naszego pierwszego ADFa. Po zalogowaniu najprościej dotrzemy do interesującego nas zasobu wyszukując Data Factories:

W otwartym oknie będziemy widzieć wszystkie instancje data factory jakie stworzyliśmy i do jakich mamy dostęp. Na ten moment możemy kliknąć Add aby dodać całkowicie nowy przepływ :

Wstępna konfiguracja Data Factory nie odbiega od standardu tworzenia usług w Azure i sprowadza się do podania:

subskrypcji,
Resource Group czyli logicznego kontenera na zasoby w ramach chmury,
regionu Azure,
nazwy,
wersji – tutaj zapominamy, że mamy jakikolwiek wybór i wybieramy V2:

W dalszym kroku mamy konfigurację systemu kontroli wersji, którą jest w tym wypadku GIT. Do wyboru możemy tutaj podać konto Azure Devops lub GitHub i powinniśmy to zrobić zawsze bez wyjątku aby mieć wgląd w historie i w sensowny sposób zarządzać zmianami. Na ten moment ja jednak ten krok pominę i zaznaczę opcję Configure Git later:

Kolejny kroku czyli Networking pozwala nam wybrać metodę dostępu do Data Factory gdzie dostęp może być dla wszystkich (public endpoint) lub dla wybranego endpointa – na ten moment zostawiam domyślny wybór czyli dostęp dla wszystkich (co oczywiście w środowiskach produkcyjnych rzadko bywa optymalnym wyborem):

Przechodząc dalej mamy Tagi czyli zestaw nazwa + wartość które możemy przypisać praktycznie do każdego zasobu w ramach Azure. Warto w ramach organizacji mieć jakąś politykę nadawania tagów tak aby w późniejszym czasie łatwo identyfikować poszczególne zasoby (często tagi będą wymuszone poprzez politykę wewnątrz subskrypcji):

Ostatni ekran to podsumowanie naszych ustawień gdzie dodatkowo nasze wybory poddane zostaną walidacji i zgodności z politykami:

Jeśli wszystko poszło dobrze to po kilku chwilach powinniśmy mieć gotową instancję Data Factory – możemy kliknąć Go to Resource aby przejść do usługi:

Główne okno naszej usługi pozwala prześledzić ostatnie wykonania, utylizacje zasobów oraz ustawić właściwości związane z ADF. Póki co przejdźmy do tworzenia przepływu czyli klikamy znajdujący się w centralnej części ekranu Author & Monitor:

W tym miejscu przełączyliśmy się do narzędzia dostępnego przez przeglądarkę do tworzenia przepływów Data Factory. Znajdziemy tutaj zbiór linków do różnych funkcji narzędzia oraz dostęp do tutoriali przygotowanych przez Microsoft. Nie poświęcając temu zbyt wielkiej uwagi przejdziemy do panelu gdzie będziemy mogli stworzyć nowy przepływ – po lewej stronie klikamy ikonę ołówka nazwaną Author:

To właśnie w tym miejscu spędzimy najwięcej czasiu. Na zakładce Author możemy zauważyć kilka dostępnych opcji zarówno na pasku zadań jak i w sekcji nazwanej Factory Resources:

W dalszej części artykułu opowiemy sobie o tym czym są poszczególne elementy, na ten moment klikamy ikonę plusa i z menu wybieramy Copy Data Tool. Jest to nic innego jak pewnego rodzaju kreator pozwalający stworzyć prosty przepływ pomiędzy źródłem, a miejscem docelowym. Narzędzie to pozwoli nam wystartować z ADF i w swojej funkcjonalności przypomina nieco Import/Export Wizard generujący paczki Integration Services.

Po wybraniu tej opcji naszym oczom ukaże się wspomniany wcześniej kreator. W pierwszym oknie musimy nadać nazwę dla naszego pipeline’a, ewentualny opis oraz to czy przepływ ma być uruchomiony jednokrotnie czy wielokrotnie bazując na harmonogramie (pamiętajmy prz tym, że wszystko co zdefiniujemy w kreatorze będzie mogło być zmienione w późniejszym czasie):

Po przejściu dalej mamy możliwość zdefiniowania połączenia. Połączenie do określonego serwisu czy też pliku płaskiego w nomenklaturze ADF nosi nazwę Linked Service i warto o tym pamiętać bo to właśnie tym pojęciem będziemy się posługiwać w dalszej przygodzie z ADF. Na ten moment nie mamy zdefiniowanego żadnego połączenia dlatego wybieramy Create new connection:

Jak już wspomniałem we wstępie ADF świetnie integruje się z całą masą różnych źródeł i serwisów. Od tych najbardziej oczywistych jak BLOB Storage, aż po takie jak MySQL czy też Amazon Redshift. W naszej demonstracji wybrałem Azure Data Lake Storage Gen2 (ADLS):

Konfiguracja połączenia do Data Lake Storage to dosyć ciekawy temat ponieważ mamy mnóstwo możliwości uwierzytelnienia itp. Jak widzicie na poniższym zrzucie mamy tutaj dosyć dużo opcji do skonfigurowania:

Nazwa i opis raczej nie wymagają komentarza i są dosyć oczywiste. Dalej mamy obiekt o nazwie Integration Runtime. Jak sama nazwa wskazuje jest to środowisko uruchomieniowe dla ADF czyli innymi słowy jest to infrastruktura obliczeniowa, która wykona stworzone przez nas zadania. O IR zdążymy sobie jeszcze z całą pewnością powiedzieć, na ten moment zostawiłem AutoResolveIntegrationRuntime. Dalej mamy metodę uwierzytelnienia do ADLS. Dostępne są trzy opcje tj:

Access Key,
Service Principal,
Managed Identity.

Myślę, że w tym wypadku wszystko zależy od konkretnego scenariusza jednak w typowym podejściu najlepiej i chyba najprościej użyć Managed Identity, co oznacza nic innego jak to, że nasza instancja ADF otrzyma swój identyfikator, któremu możemy nadać uprawnienia w ramach innych usług. Po wybraniu Managed Identity odrazu możecie zobaczyć dwa obiekty tj.:

Managed Identity Name,
Managed Identity Object Id

Używając tych informacji można później nadać dostęp np. w Data Lake Storage. Poniżej możecie zobaczyć okno Storage Explorer gdzie wyszukałem właśnie Managed Identity ADFa:

Wracając do okna z konfiguracją połączenia możemy wskazać konto Data Lake Storage używając subskryocji do której mamy dostęp lub wskazując bezpośrednio URL powiązany z określonym kontenerem w ramach ADLS. W sekcji Test Connection możemy wskazać jak chcemy przetestować połączenie tzn. czy do całej usługi czy do konkretnego kontenera. Ja nadałem dostęp do okeślonego kontenera dlatego wybrałem To file path, a następnie podałem nazwę kontenera czyli seequality i po kliknięciu Test connection wygląda, że wszystko się powiodło:

Przechodząc dalej do sekcji Dataset wskazujemy plik lub kontener znajdujący się na ADLS – jeśli ADF ma dostęp tylko do określonego kontenera to wpisujemy go w sekcji File or Folder, a następnie klikamy Browse gdzie wskażemy konkretny plik:

Następnie mamy kilka dodatkowych opcji do skonfigurowania – jedynymi które zmodyfikujemy w ramach opisywanego scenariusza jest Max concurrent connections czyli maksymalna liczba połączeń jakie ADF może nawiązać z ADLS gdzie wskazałem 1 oraz odznaczyłem opcję Recursively aby nie przeglądać podfolderów (co nie ma znaczenia przy wskazaniu pojedynczego pliku ale mimo wszystko to zrobiłem):

Po przejściu dalej musimy wskazać format pliku do którego się łączymy – tutaj pomocna może okazać się opcja Detect text format, która automatycznie rozpozna typ pliku:

W dolnej części okna mamy podgląd, który będzie obrazował to czy nasze ustawienia są poprawne. Większość opcji nie powinno tutaj sprawićnikomu problemu więc przejdźmy dalej gdzie będziemy definiować kolejny Linked Service, który w tym przypadku będzie pełnił rolę miejsca docelowego. W naszym scenariuszu będziemy ładować dane do SQL Pool w ramach Azure Synapse Analitycs:

Konfiguracja połączenia do Synapse również nie jest bardzo skomplikowana, a jedyna różnica jest taka, że część rzeczy możemy wziąć z Azure Key Vault czyli usługi do bezpiecznego przechowywania wszelkiego rodzaju informacji uwierzytelniających itp. Na ten moment w celu uproszczenia pominąłem tę usługę i podobnie jak w poprzednim przypadku jako metodę uwierzytelnienia wybrałem Managed Identity:

Słowem uzupełnienia wspomnę, że aby dodać Managed Identity naszego ADFa do Synapse wystarczy wykonać poniższe polecenie będąc zalogowanym do Synapse po użytkowniku AD (nie może to być SQL Authentication bo dodawanie dostępu dla użytkowników AD jest możliwe tylko jeśli jesteśmy zalogowani po AD). Dodatkowo dodałem mojego użytkownika do roli db_owner aby mógł wykonywać dowolne operacje na bazie:

CREATE USER [seequality01] 
FROM  EXTERNAL PROVIDER  WITH DEFAULT_SCHEMA=[dbo]
GO

sp_addrolemember @rolename = 'db_owner', @membername = 'seequality01'

W powyższym zapytaniu seequality01 to oczywiście nazwa mojego Data Factory, a co za tym idzie Managed Identity.

Przechodząc dalej mamy możliwość wygenerowania tabeli docelowej lub wybranie istniejącej:

Dla celów testowych stworzyłem wcześniej tabelę docelową o nazwie dbo.stage_FactInternetSales. Kolejne okno umożliwia nam przejrzenie mapowania, które automatycznie jest tworzone po nazwie kolumny:

Ciekawe możliwości daje nam opcja Pre-copy script gdzie możemy napisać kawałek kodu w TSQL, który zostanie wykonany przed załadowaniem danych. Może to być np. TRUNCATE TABLE aby wyczyścić dane.

Powoli zbliżamy się do końca konfiguracji w ramach naszego kreatora. Okno Settings pozwala na kilka dodatkowych ustawień. W przyszłości być może omówimy je szczegółowo natomiast na ten moment warto zwrócić uwagę przede wszystkim na:

Copy method – czyli metoda ładowania danych gdzie możemy użyć mechanizmów dostępnych w ramach Polybase, komendy Copy Into lub też Bulk Insert (o tym z całą pewnością pojawią się w najbliższym czasie wpisy na blogu ponieważ są to bardzo ciekawe i dosyć obszerne tematy). Dla prostoty i przejrzystości wybrałem Bulk insert chociaż prawdopodobnie w większości przypadków polecam wybrać Copy.
Data Integration Unit – czyli tak naprawdę moc ADFa, należy temu ustawieniu zawsze się przyjrzeć bo jak widzicie na poniższym zrzucie rachunek jaki do nas trafi jest w dużej mierze zależny od DIU. W moim przypadku ustawiłem najniższą wartość czyli 2.
Degree of parallelism – ile równoległych wątków będzie ładować dane – w moim przypadku będzie to tylko 1.

Na ten moment ustawienia są takie, a nie inne ale pamiętajmy, że wszystko może zostać zmienione czy też parametryzowane w późniejszym czasie.

Dalej mamy jedynie okno podsumowania oraz próbę uruchomienia pipeline’a:

Jak widać wszystko zakończyło się sukcesem. W celu sprawdzenia możemy zalogować się do Synapse i spróbować odpytać naszą tabelę. Do tego celu użyłem edytora zapytań dostępnego z poziomu portalu Azure:

Po uruchomieniu przepływu możemy zobaczyć, że dane rzeczywiście zostały załadowane:

Po przejściu do Data Factory możemy zobaczyć, że w wyniku naszych działań powstał:

przepływ (Pipeline) o nazwie CopyPipeline zawierający jedno zadanie (Activity) kopiujące dane (Copy data)
dwa zestawy danych (Datasets) odzwierciedlające strukturę ładowanego pliku oraz tabeli docelowej

Po zaznaczeniu Copy Activity w dolnej części ekranu możemy zobaczyć jego właściwości, które są zgodne z tym co ustawiliśmy w kreatorze:

O wywoływaniu przepływów postaram się nieco więcej napisać w przyszłości jeżelijednak chcielibyśmy uruchomić nasz przepływ w trybie debugowania to zawsze możemy to zrobić wybierając z paska zadań opcję Debug. W przypadku zwykłego uruchomienia lub przypisania harmonogramu pozostaje nam opcje Add Triger.

Tutaj może pojawić się pytanie gdzie znajdują się nasze połączenia do Data Lake Storage oraz do Synapse. Otóż aby się do nich dostać musimy przejść na zakładkę Manage i tam znajdują się nasze Linked services, które możemy w razie potrzeby edytować i dostosowywać.

Oczywiście to dopiero początek możliwości Azure Data Factory o którym postaram się napisać jeszcze nie raz. Na ten moment polecam potestować narzędzie ponieważ posiada ono mńostwo bardzo fajnych i przydatnych funcjonalności. Do usłyszenia!