Azure Data Factory – wywoływanie przepływów z wykorzystaniem triggerów

Azure Data Factory jest w moim odczuciu jednym z najpowszechniej wykorzystywanych serwisów w chmurze Azure. Niezwykłe możliwości skalowania i prostota konfiguracji pozwala ładować, transformować oraz orkiestrować różnego rodzaju przepływy danych nawet w skali Big Data. Na swoim blogu poświęciłem już kilka artykułów temu narzędziu (znajdziecie je tutaj) jednakże nie powiedziałem jeszcze w jaki sposób możemy wywoływać nasze pipeline’y. Z tego też powodu postanowiłem napisać parę słów na temat tzw. Triggerów czyli wyzwalaczy dostępnych zarówno w tradycyjnym ADF jak i w ramach pipeline’ów dostępnych w ekosystemie Synapse – zapraszam do lektury.

Pierwszym triggerem o którym chciałbym powiedzieć jest wyzwalacz manualny pozwalający uruchomić wybrany pipeline na żądanie. Jest on dostępny m.in w interfejsie graficznym w edytorze Azure Data Factory po wybraniu Add Trigger -> Trigger Now:

Po wybraniu tej opcji zostaniemy poproszeni o wypełnienie wartości parametrów jeżeli takowe zostały zaimplementowane w wywoływanym pipeline, a następnie przepływ zostanie uruchomiony.
W logach będziemy mieli widoczną informację, iż było to wywołanie manualne:

Oprócz interfejsu graficznego mamy oczywiście możliwosć wywołania ręcznego triggera z poziomu kodu np. z poziomu Powershella:

Connect-AzAccount
$token = (Get-AzAccessToken).Token

$headers = @{
Authorization="Bearer $token"
}

Invoke-WebRequest -Method POST -Headers $headers "https://management.azure.com/subscriptions/29334896f-e4ed-49c7-a474-9f8c1c4a78c8/resourceGroups/seequalityRG/providers/Microsoft.DataFactory/factories/seequalityADF/pipelines/pipeline1/createRun?api-version=2018-06-01"

Po wykonaniu tego prostego skryptu dostaniemy informacje, że serwis przyjął żądanie wraz z identyfikatorem uruchomienia po którym możemy odszukać uruchomienie w logach ADF:

 

Podobny komunikat dostaniemy właściwie z każdego narzędzia wykorzystującego API ADF do uruchomienia pakietu.Wywoływania tego typu nie są obarczone żadnymi limitami dlatego też możemy je wykorzystywać do woli. W ramach ciekawostki warto tutaj wspomnieć o tym ,że zdarza się iż klient nie chce aby ktoś uruchamiał ADFa ręcznie dlatego też mając wiedzę, że wywołanie tego typu jest widoczne jako Manual trigger możemy skonfigurować alert w momencie wystąpienia takiego wywołania.

Innym rodzajem wywołania jest Schedule trigger czyli wywołanie według określonego harmonogramu czasowego. Jest to najpopularniejszy sposób i myślę, że nie wymaga przedstawienia jednak dla porządku to zrobię. Aby stworzyć taki trigger należy w ADF przejść na zakładkę Manage -> Triggers i wybrać New (w taki też sposób tworzymy każdy inny rodzaj triggerów):

Definiowanie samego harmonogramu jest raczej intuicyjne i sprowadza się do wybrania typu triggera, którym w tym wypadku jest Schedule, daty startowej czy między innymi strefy czasowej :

Niezwykle istotna jest opcja Recurrence, gdzie definiujemy co ile określonych jednostek czasu pipeline ma być uruchomiony. Na powyższym przykładzie widać, że pipeline będzie uruchamiany co 15 dni, a jednocześnie w sekcji Advanced recurrence options jestśmy w stanie zdefiniować dodatkowe godziny w jakich uruchomienie ma nastąpić.

Jeśli chodzi o jednostki czasu to mamy do wyboru:

• minuty

• godziny

• dni (wraz z wyszczególnieniem godzin)

• Tygodnie (wraz z wyszczególnieniem dni tygodnia oraz godzin)

• miesiące ( ze wskazaniem dni miesiąca lub dni tygodnia oraz godzin)

 

Możliwości jest zatem cała masa i myślę, że z całą pewnością zaspokaja to potrzeby większości wdrożeń.

Oprócz standardowych ustawień wylistowanych powyżej warto zwrócić uwagę, że mamy również możliwość zdefiniowania daty końcowej co bywa przydatne w niektórych scenariuszach biznesowych. Bardzo istotny jest fakt mówiący o tym, że schedule trigger może być przypisany do wielu różnych pipeline’ów w ramach pojedynczego projektu ADF i pojedynczy pipeline może być wywoływany przez wiele różnych triggerów – jest to zatem typowa relacja wiele do wielu.

Przechodząc dalej przechodzimy do tiggera o nazwie Tumbling Window. Jego podstawowa konfiguracja wygląda stosunkowo prosto:

Oznacza to po prostu wywołanie co 15 minut w nienachodzących na siebie okresach:

Gdy rozwiniemy zaawansowane opcje tego triggera zauważymy, że możliwości mamy nieco więcej:

Widzimy zatem, że mamy możliwe do ustawienia następujące opcje:

• Delay – opóźnienie zanim okno ruszy,
• Max concurrency – ile okien równolegle może być uruchomionych – 0 oznacza uruchamianie sekwencyjne jak wyżej,
• Retry policy: count – ilość powtórzeń w przypadku wystąpienia błędu,
• Retry policy: interval in seconds – przerwa w sekundach pomiędzy poszczególnymi próbami.

Nic zatem nie stoi na przeszkodzie żeby nasz harmonogram na siebie nachodził:

lub żeby poszczególne bloki ładowań nie były ze sobą styczne:

Dzięki możliwym do implementacji takim kombinacjom jesteśmy w stanie zaimplementować naprawdę skomplikowaną logikę. Tumbling window jest szczególnie przydatny w przypadku gdy mamy ładowania pseudo-streamingowe gdzie mikrobatchami ładujemy mniejsze porcje danych ale robimy to ciągle. Ten rodzaj wywołania może być przypisany tylko do jednego pipeline’a. Jeśli chcielibyśmy wprowadzić nieco zależności pomiędzy wywołaniami to oczywiście jesteśmy to w stanie zrobić ustawiając je w sekcji Add dependency:

Poszczególne zależności między triggerami mogą być bardzo złożone i zachęcam do zapoznania się z przykładami dostępnymi w dokumentacji (link).

Kolejny rodzaj triggera to Event Trigger. Jest to wyzwalacz polegający na tym, że w momencie wystąpienia określonego wydarzenia takiego jak np. stworzenie elementu lub jego usunięcie na określonym Storage Account odpalony będzie pipeline.W ADF ten typ widoczny jest pod dwoma różnymi nazwami, a mianowicie:

• Storage Events
• Custom Events

Pierwszy z nich odnosi się do wydarzenia związanego z utworzeniem lub usunięciem określonego bloba z kontenera Storage Account. Drugi nieco bardziej uniwersalny pozwala podpiąć się pod Event Grid, który po wyłapaniu określonego wydarzenia jest w stanie uruchomić nasz pipeline.

Spójrzmy na okno konfiguracyjne wyzwalacza typu Storage Event:

Jak możecie zauważyć na powyższym zrzucie ekranowym jedyne co musimy ustawić w tego typu wyzwalaczu to wskazać Storage Account oraz kontener w którym mają pojawiać interesujące nas dane. Jeśli istnieje taka potrzeba możliwe jest filtrowanie obiektów/kontenerów oraz wybranie czy trigger ma się odpalać w momencie gdy elementy zostaną stworzone lub usunięte czy też w obu tych przypadkach. Ważną opcją jest również możliwość ignorowania “pustych” elementów czyli takich, których rozmiar wynosi 0 bajtów, które mogą się pojawić jako część nieudanego procesu wrzucenia danych na storage lub też z innych przyczyn.

Spróbujmy sobie coś takiego przetestować. Utworzyłem trigger zgodnie z definicją przedstawioną na powyższym zrzucie. Następnie stworzyłem pipeline w którym mam jedynie przypisanie wartości do zmiennej (nie interesuje mnie czynność przerzucania danych, a jedynie przetestowanie działania triggera) do którego podpiąłem stworzony wyzwalacz:

Całość zapisałem i opublikowałem. Teoretycznie trigger powinien już działać dlatego też nie pozostało mi nic innego jak wrzucić coś na storage.

Do uploadu plików użyłem portalu funkcjonalności dostępnej na portalu widocznej na poniższym zrzucie:

W różnych odstępach czasu wrzuciłem trzy pliki:

Zaglądając w logi zauważyłem, że zgodnie z oczekiwaniami pipeline został odpalony trzykrotnie – czyli dokładnie tyle razy ile wystąpiło zdarzenia pojawienia się pliku:

Jak zapewne zauważyliście tego typu trigger jest bardzo prosty w użyciu i znacznie rozszerza nasze możliwości jeśli chodzi o uruchamianie różnego rodzaju przepływów. Event Trigger również może być przypisany do więcej niż jednego pipeline’a jednak zalecam tutaj ostrożność. Zamiast przypisywać Storage Event trigger do wielu elementów warto rozważyć stworzenie pipeline’a typu master, który będzie orkiestrował określony proces zamiast nadmiernie komplikować cały proces.

Oparcie uruchomienia o zdarzenia na Storage Account to nie jedyna możliwość oparcia uruchomienia o wydarzenie – dodatkowo w preview (na moment pisania artykułu) jest opcja podpięcia Event Grida, który może odpalić ADF w przypadku wystąpienia właściwie dowolnego zdarzenia. Sam Event Grid nie jest tematem niniejszego wpisu dlatego też odsyłam do dokumentacji, a sam w przyszłości pewnie coś na jego temat napiszę.

To by było na tyle jeśli chodzi o triggery w Azure Data Factory. Mam nadzieję, że artykuł przedstawił Wam ogrom możliwości wbudowanych w ADF jeśli chodzi o wywoływanie konkretnych przepływów. Pamiętajmy, że oprócz tradycyjnych uruchomień na podstawie prostego harmonogramu mamy również ruchome Tumbling Window z bogatymi opcjami zależności oraz cały szereg możliwości odpalenia ADF w zależności od wystąpienia określonego zdarzenia. Jeśli to nadal będzie dla nas mało to pozostaje API i możliwość wywoływania z kodu, które też nie powinno nikomu sprawić problemu. Pozdrawiam!