Zastosowanie Control-M w korporacyjnej hurtowni danych

18.03.2019 | Paweł Moliński

Hurtownia danych CDW Control-M DWH

Wstęp

Korporacyjna hurtownia danych w ING Banku Śląskim to organizm niezwykle złożony: ponad 560 głównych i blisko 3.5 tys. pomocniczych procesów ETL (zaimplementowanych w IBM InfoSphere DataStage oraz Oracle Warehouse Builder), ponad 350 faktów i 150 wymiarów, 1.5 tys. ekstraktów docierających do hurtowni każdego dnia z kilkudziesięciu różnych, heterogenicznych systemów działających w organizacji. Ponadto, setki ekstraktów wysyłanych do innych systemów i setki raportów generowanych w oparciu o zgromadzone w hurtowni dane.

Wszystko to powoduje, że zarządzanie procesem ładowania hurtowni musi odbywać się w sposób niezwykle zorganizowany, uwzględniający zależności pomiędzy poszczególnymi, pojedynczymi procesami ETL, jak również pomiędzy całymi obszarami zintegrowanych danych. W ING Banku Śląskim wybrano do tego celu BMC Control-M, jedno z wiodących narzędzi klasy Workload Automation.

Dlaczego Control-M?

Wybór Control-M to oczywiście decyzja globalna dla całej organizacji, nie tylko dla hurtowni danych. Nie znaczy to oczywiście, że hurtownia nie czerpie z tego rozwiązania wszystkiego, co najlepsze – wprost przeciwnie: elastyczność i duże możliwości konfiguracyjne pozwalają na realizację szeregu skomplikowanych operacji, nie tylko związanych z głównym przetwarzaniem hurtowni, ale również wielu innych zadań realizowanych w ramach prac utrzymaniowych, takich jak odtwarzanie i zaciemnianie ekstraktów i danych, przetwarzanie Data Martów itp.

Główne cechy narzędzia Control-M, wykorzystywane w hurtowni danych, to:

  • możliwość dynamicznego budowania głównego flow przetwarzania, w oparciu o parametryzację zdefiniowaną bezpośrednio na hurtowni danych; do tego celu wykorzystywane są narzędzia cli.exe oraz emdef.exe, dostępne w aplikacji klienckiej (więcej o automatyzacji tego procesu w jednym z kolejnych rozdziałów), oraz skrypty Python i PowerShell;
  • możliwość wykorzystania AAPI (ang. Automation API) do automatyzacji i monitoringu zadań, m.in. do automatycznego restartowania job-ów zakończonych błędami, obsługiwanymi w sposób systemowy, monitorowania logów z przetwarzania poszczególnych job-ów, sterowania przebiegiem job-ów (zatrzymanie, wznowienie, itp.) z poziomu aplikacji i skryptów wspierających przetwarzanie hurtowni itp.;
  • możliwość udostępniania predefiniowanych, specyficznych przetwarzań użytkownikom biznesowym, jako tzw. usług self-service, dzięki czemu pewne z zadań biznesowych mogą być realizowane bez zaangażowania zespołu hurtowni danych, w oparciu o parametryzację dostarczoną bezpośrednio przez biznes.

Struktura przetwarzania

Jak już wspomniano na wstępie, struktura hurtowni danych jest niezwykle złożona i rozbudowana. Nie wszystkie procesy ETL hurtowni podlegają wywołaniu z poziomu flow Control-M, co spowodowane jest głównie względami praktycznymi - mniejsza liczba job-ów to bardziej przejrzysta struktura, łatwiejsza do modyfikacji, utrzymania i monitorowania. Z technicznego punktu widzenia, wygląda to następująco:

  • główne procesy ETL, zasilające fakty i wymiary (czyli tzw. „gwiazdy”) wywoływane są bezpośrednio z poziomu głównego flow Control-M, w ramach kroku (folderu typu SMART) grupującego MAIN. Folder ten jest przebudowywany codziennie (w razie potrzeby) w sposób automatyczny, co zostanie dokładniej opisane w kolejnym rozdziale;
  • procesy pomocnicze, poprzedzające (np. załadowanie do hurtowni zawartości zewnętrznych słowników biznesowych, kursów walut), jak i kończące (np. przestawienie parametryzacji ładowania na kolejny dzień biznesowy) główne przetwarzanie hurtowni wywoływane są w ramach głównego flow, w ramach kroków (folderów typu SMART) grupujących – odpowiednio – PRE i POST. Są to kroki statyczne – ich struktura jest niezmienna, i nie podlega automatycznej przebudowie;
  • ładowanie danych ekstraktów do warstwy Stage realizowane jest poza Control-M, w ramach ładowania faktów i wymiarów, poprzez wewnętrzne mechanizmy zaimplementowane bezpośrednio na hurtowni danych. Ładowanie danych z ekstraktów uruchamiane jest on demand w momencie, gdy Control-M rozpoczyna przetwarzanie job-a zasilającego dany fakt lub wymiar.

Graficzną reprezentację głównego flow przetwarzania hurtowni przedstawia poniższy rysunek.

Cykl przetwarzania hurtowni wygląda więc następująco:

  • O konkretnej godzinie w porze nocnej uruchamiane jest przetwarzanie – jako pierwszy startuje krok PRE, grupujący procesy odpowiedzialne za czynności, które muszą zostać wykonane przed rozpoczęciem przetwarzania kroku MAIN, m.in. wspomniane wcześniej przeniesienie danych ze słowników biznesowych do słowników hurtowni danych. Wyzwolenie zasilania następuje na podstawie kalendarzy zdefiniowanych w Control-M;
  • po zakończeniu kroku PRE wywoływany jest krok MAIN, agregujący wszystkie główne procesy hurtowni, odpowiedzialne za załadowanie danych do faktów i wymiarów hurtowni. W ramach procesów ETL w tym kroku wywoływane jest również ładowanie ekstraktów dostarczonych do hurtowni przez systemy źródłowe – jak wspomniano wcześniej ładowanie to inicjowane jest przez wewnętrzne mechanizmy hurtowni, i nie posiada dedykowanych do tego celu job-ów w Control-M;
  • po zakończeniu przetwarzania kroku MAIN wywoływany jest krok POST, przygotowujący hurtownię pod kolejny cykl ładowania w kolejnym dniu.

W kroku PRE zawarte są dwie dodatkowe funkcjonalności, istotne z punktu widzenia użytkowników biznesowych i zespołu wsparcia hurtowni:

  • wysyłanie informacji mailowej do wszystkich użytkowników biznesowych, będących bezpośrednimi beneficjentami zgromadzonych w hurtowni danych, o rozpoczęciu przetwarzania (ładowania) danych za dany dzień;
  • możliwość tymczasowego wstrzymania rozpoczęcia przetwarzania, poprzez ustawienie odpowiedniej flagi w tabelach parametrycznych hurtowni (jest to szczególnie istotne wtedy, gdy z pewnych względów – biznesowych lub technicznych – rozpoczęcie ładowania powinno zostać opóźnione w czasie). Zrealizowano to poprzez dodanie job-a (jako pierwszego w folderze PRE), wywołującego się w pętli, do momentu, gdy wartość flagi zostanie ponownie przestawiona na wartość „odblokuj przetwarzanie”.

Automatyczna budowa przepływów

Jak wspomniano wcześniej, hurtownia danych to organizm złożony, ale nie tylko – również żywy, podlegający nieustannej zmianie. Każdego tygodnia na środowisko produkcyjne wdrażanych jest od kilkunastu do kilkudziesięciu zmian, obejmujących zarówno modyfikacje istniejących procesów ETL, jak również procesy zupełnie nowe, zasilające nowo utworzone struktury danych.

Wszystko to powoduje, że utrzymywanie statycznego flow w Control-M jest praktycznie niemożliwe – wymagałoby to bowiem cotygodniowych modyfikacji przepływów, ręcznego dodawania nowych zależności, usuwania zależności już nieaktualnych itd. Dlatego też w hurtowni danych wdrożony został mechanizm automatycznej przebudowy przepływów, działający na niezależnym serwerze pomocniczym. Mechanizm ten został zaimplementowany w PowerShell-u i Pythonie, uruchamiany jest codziennie w sposób automatyczny (w godzinach wieczornych), a sposób jego działania jest (w dużym uproszczeniu) następujący:

  • wyliczenie sumy kontrolnej wg aktualnego stanu parametryzacji procesów ETL na hurtowni. Jeśli suma ta jest identyczna jak suma kontrolna zapamiętana w tabelach parametrycznych hurtowni, to oznacza, że nic się nie zmieniło, i przebudowa flow nie jest konieczna – następuje przerwanie algorytmu przebudowy;
  • eksport aktualnej definicji przepływu, z wykorzystaniem narzędzia emdef.exe:
      
    emdef.exe exportdeffolder -USERNAME %s -PASSWORD %s -HOST %s -ARG_FILE %s -OUT_FILE %s

    O ile trzy pierwsze parametry wywołania nie wymagają komentarza, o tyle dwa kolejne nie koniecznie muszą być aż tak oczywiste. Parametr ARG_FILE wskazuje na plik XML zawierający definicję nazwy folderu, który należy wyeksportować:
      
    <terms>
 <term>
   <param name="FOLDER_NAME" op="EQ" value="FOLDER_NAME_TO_EXPORT" />
 </term>
</terms>

    przy czym w tym przypadku eksportowany jest folder główny (czyli aplikacja wg nomenklatury nazewniczej Control-M), zawierający SMART Foldery-y PRE, MAIN oraz POST.
    Parametr OUT_FILE wskazuje z kolei lokalizację pliku XML, do którego zapisana ma zostać wyeksportowana definicja flow;
  • wyznaczenie nowej postaci flow z wykorzystaniem algorytmu tranzytywnego domknięcia grafu zależności. Algorytm ten ma na celu eliminację zbędnych zależności pomiędzy poszczególnymi job-ami, czyli – w uproszczeniu – optymalizację przepływu;
  • import nowej definicji flow do Control-M, z wykorzystaniem wspomnianego już narzędzia emdef.exe, lecz z nieco odmienioną składnią (znaczenie poszczególnych przełączników polecenia można znaleźć w dokumentacji Control-M):
      
    emdef.exe deffolder -USERNAME xxx -PASSWORD xxx -HOST xxx -SRC_FILE xxx /a /o /v /t
  • synchronizacja nowej definicji Flow z bazą CTM, z wykorzystaniem narzędzia cli.exe:
      
    cli.exe -USERNAME xxx -PASSWORD xxx -HOST xxx -t xxx -FOLDER_UPLOAD controlmname rootfolder
  • wyliczenie nowej sumy kontrolnej dla flow i aktualizacja jej wartości w tabelach parametrycznych hurtowni.

Po zakończeniu działania algorytmu w Control-M mamy już nową definicję przepływu, odzwierciedlającą najbardziej aktualny stan parametryzacji hurtowni danych, a w tabelach parametrycznych hurtowni – aktualną wartość sumy kontrolnej dla tego flow.

Automation API

Bardzo ciekawym, i zarazem szeroko wykorzystywanym w obszarze hurtowni danych rozwiązaniem jest Control-M Automation API (AAPI), pozwalające na komunikację z instancją Control-M za pośrednictwem REST API. Główne obszary, w których wykorzystywany jest ten interfejs, to:

  • automatyczny restart job-ów Control-M, które zakończyły się błędem (czyli znajdują się w statusie „Ended Not OK”), ale błąd ten można obsłużyć systemowo. W takim przypadku wykorzystywana jest możliwość wykonania operacji Rerun na pojedynczych job-ach. Po analizie przyczyny błędów, czyli dynamicznej analizie logów kolejnych job-ów, pobranych za pomocą polecenia (wszystkie przykłady w PowerShell-u):
      
    $jobLog = Invoke-RestMethod -Method Get -Uri "${lEndPoint}/run/job/${lCMJobId}/log"  -Headers $script:glbHeaders
    dla tych job-ów, dla których istnieje taka możliwość , wykonywana jest operacja Rerun:
      
    $rerun_job = Invoke-RestMethod -Method Post -Uri "$endPoint/run/job/${lJobId}/rerun" -Headers $script:glbHeaders
  • uruchamianie wybranych job-ów na żądanie, co pozwala na wykonanie ich w przypadku zajścia określonych zdarzeń biznesowych, lub – po prostu – na żądanie operatora, np. osoby z zespołu wsparcia hurtowni danych. Wykorzystywana jest wówczas komenda:
      
    $job_order = Invoke-RestMethod -Method Post -Uri ${lEndPoint}/run/order -Body (ConvertTo-Json $job_data) -ContentType "application/json" -Headers $script:glbHeaders
    pozwalająca na zamówienie (ang. order) wykonania określonego job-a (lub folderu/SMART folderu, zawierającego większą liczbę job-ów), a następnie weryfikację statusu jego wykonania przy pomocy polecenia:
      
    $lRunStatus = Invoke-RestMethod -Method Get -Uri "${lEndPoint}/run/status/${lRunId}" -Headers $script:glbHeaders
  • pobranie listy job-ów procesowanych aktualnie na serwerze w ramach określonej aplikacji, subaplikacji, folderu oraz podfolderu, np:
      
    $lCMJobs = Invoke-RestMethod -Method Get -Uri "${lEndPoint}/run/jobs/status?application=APPNAME&subApplication=SUBAPPNAME&folder=FOLDERNAME/SUBFOLDERNAME&limit=2000" -Headers $script:glbHeaders
  • wykonywanie na wybranych job-ach operacji Hold/Free/Set To OK, np.:
      
    $hold_job = Invoke-RestMethod -Method Post -Uri "${lEndPoint}/run/job/${lCMJobId}/hold" -Headers $script:glbHeaders

Przedstawione przykłady to jedynie niewielki podzbiór możliwości AAPI, które daje ponadto możliwość m.in. automatycznego deploymentu wybranych job-ów, generowania raportów itp.

Podsumowanie

Niniejszy artykuł to jedynie zgrubny zarys zastosowania Control-M w przetwarzaniu korporacyjnej hurtowni danych w ING Banku Śląskim. Dynamika rozwoju hurtowni oraz wciąż zwiększający się zakres przetwarzanych danych dają niemal stuprocentową gwarancję, iż w najbliższym okresie czasu zakres zastosowania Control-M ulegać może jedynie zwiększaniu. Planowana jest m.in. próba realizacji deploymentu job-ów poprzez AAPI, co zastąpić ma aktualnie używany sposób importu job-ów (z użyciem narzędzi cli.exe oraz emdef.exe) podczas automatycznej przebudowy flow w Control-M. Ale to już temat na osobny artykuł.