Wykorzystanie Lookup Activity w Azure Data Factory
Już na początku mojej drogi związanej z pracą na chmurze Microsoft Azure spotkałem się z pewnym wyzwaniem. Problem na początku wydawał się banalny. Polegał na tym, w jaki sposób przekazać wartości z wiersza istniejącego na bazie do kolejnych części procesu ładowania danych, stworzonych w Azure Data Factory (dalej zwany ADF). Przeszukując dostępne dokumentacje dotyczące takiego zagadnienia dowiedziałem się, że najlepszym do tego elementem będzie Lookup Activity (dalej zwany LA).
Początkowo w implementacji tego rozwiązania nie było żadnych problemów. Podpięcie pod bazy testowe dawały pozytywne rezultaty, a wartości gładko przechodziły do kolejnych elementów. Proces działał bez problemów. Schody zaczęły się w momencie przejścia na system produkcyjny. Jak wiadomo jest tam dużo więcej danych i proces zaczął się kończyć niepowodzeniem. Wtedy wróciłem do dokumentacji LA i znalazłem poniższe informacje o jego ograniczeniach:
1. Lookup Activity zwraca maksymalnie 5000 rekordów, reszta jest pomijana, nie zwraca błędu przy przekroczeniu ograniczenia.
2. Lookup Activity obsługuje maksymalnie 4MB, przekroczenie wywołuje błąd elementu.
3. Lookup Activity może wykonywać się maksymalnie 24 godziny.
Ograniczenia Lookup Activity
Tak właśnie pojawił się problem. No bo jak inaczej ogarnąć taki temat niż za pomocą LA? Żaden inny element ADF nie spełniał moich wymagań. Wpadłem na pomysł, aby uruchamiać LA w pętli, dzięki której LA będzie zawsze spełniało wyżej wskazane ograniczenia. Poniżej prosty schemat wykonania zadania:
W pierwszym kroku (1) za pomocą LA wyciągamy z bazy ilość danych, które chcemy przeładować w danym procesie.
W Kroku 2 (2) wyznaczamy liczbę iteracji, które musimy wykonać w celu obsłużenia pełnej puli nowych rekordów. W tym celu dzielimy ilość uzyskaną w kroku 1 przez ustaloną liczbę, np. 1000. Liczba ta musi być poprawnie dobrana, aby żadne ograniczenie nie było osiągnięte. Przy większych rozmiarach rekordów, większej ilości kolumn, gdy w jednej z kolumn jest duży opis może dojść do przekroczenia ograniczenia dotyczącego 4MB danych. Zakładamy również, że będzie minimum jedna iteracja. Przykładowy kod poniżej.
@concat('WITH recordsCount as (
select(',activity('RecordFrom').output.firstRow.recordCount,'/1000) + 1 AS iterationCount) ,
SELECT 1 AS iterationCount
UNION ALL
SELECT iterationCount+1 FROM gen WHERE iterationCOunt+1<=select iterationCount from recordsCount)
)
SELECT * FROM gen OPTION (MAXRECURSION 1000)')
W kroku 3 (3) używamy pętli ForEach do której przekazujemy parametr Items, wyglądający następująco:
@activity('Set number Of Iteration').output.valueWewnątrz pętli używamy Lookup Activity, którego zapytanie konfigurujemy tak, aby ograniczyć ilość zwracanych rekordów według numeru iteracji i liczby, przez którą dzieliliśmy wszystkie rekordy (w przedstawianym przykładzie 1000). Z tego automatu stworzą nam się paczki danych według przedziałów: 1:1000, 1001:2000; 2001:3000, itd. Poniżej przedstawiam jedną z wielu implementacji startu i końca przedziału, które można użyć w tym przypadku.
start:
@add(mul(add(int(item().iterationCount),-1),1000),1)koniec:
@mul(int(item().iterationCount),1000)W taki oto sposób można poradzić sobie z ograniczeniami narzędzi w Azure. Jest to również przykład tego, jak rozbudowanym narzędziem jest Azure i na jak wiele pozwala. Ograniczenia, które napotykamy, nie tyle wymuszają całkowitą zmianę koncepcji rozwiązania, co dają możliwość podejścia do problemu w swój autorski sposób w obrębie założonych elementów Azure.
Karol Jurek
Senior BI Developer w BitPeak