Automatyczne testy regresji – rozwiązanie „szyte na miarę” – cz. 1 – jak generujemy ekstrakty

17.06.2024 |  Paweł Krakowczyk

Tech Data Science Automatyzacja Testy Hurtownia danych DWH

Z artykułu dowiesz się

  • Jaki związek mają testy regresji z kryzysem finansowym lat 2007-2009 
  • Dlaczego raportujemy wskaźniki LCR i NSFR
  • Jak wygląda raportowanie wskaźników w naszym banku
  • Jak powstają raporty.

Odpowiedź na kryzys lat 2007-2009

„Rosnąca niepewność na rynkach finansowych, kryzys lat 2007-2009, który w wielu krajach nadal nie przeminął, zmusza do zreformowania dotychczasowych metod pomiaru ryzyka finansowego. Jednym z istotnych jego elementów jest ryzyko płynności, które znacząco wpływa na sytuację zarówno samych banków, jak i całego systemu finansowego. Choć samo ryzyko płynności nie było sensu stricte mierzone wg pierwszych i drugich wytycznych Komitetu Bazylejskiego (tzw. Bazylea I i Bazylea II), upadek Lehman Brothers oraz związane z nim konsekwencje skłoniły regulatorów do podjęcia tego tematu. 
(…)
Komitet Bazylejski, widząc zagrożenie, jakie powstało dla całego systemu bankowego w okresie ostatniego kryzysu, wprowadził w trzecim etapie regulacji wskaźniki LCR oraz NSFR.
(…)
Pierwszy z nich, wskaźnik LCR, wyraża procentową wartość pokrycia płynnymi aktywami o określonej przepisami szczególnymi wysokiej płynności, kwoty możliwych odpływów netto. Konieczność osiągnięcia wymaganego poziomu 100% dla tego wskaźnika zmusza de facto banki do utrzymywania wysokiej jakości aktywów na poziomie pozwalającym w sytuacji kryzysowej na pokrycie przez 30 dni potrzeb związanych z możliwym odpływem środków z danej instytucji.

(…)
Drugi ze wskaźników zaproponowanych przez Komitet Bazylejski – wskaźnik stabilnego finansowania NSFR – wyraża relację funduszy własnych i obcych stabilnych do aktywów niepłynnych i aktywów o ograniczonej płynności (przy założeniu sytuacji kryzysowej).”

Żródło: Studia Ekonomiczne. Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach ISSN 2083-8611 Nr 325 · 2017

Jak przygotować bank na zmiany

Zagrożenie, które powstało w sektorze bankowym po ostatnim kryzysie w latach 2007-2009 zaniepokoiło Komitet Bazylejski. W odpowiedzi na kryzys wprowadzono obowiązek raportowania wskaźników LCR i NSFR.

Warto wiedzieć

  • LCR (liquidity coverage ratio) – relacja aktywów płynnych do wypływów netto
  • NSFR (net stable funding ratio) – relacja funduszy własnych i obcych stabilnych do aktywów niepłynnych i o ograniczonej płynności, obliczany przy założeniu wystąpienia sytuacji kryzysowej.

Dlaczego wprowadzenie zmian zgodnych z projektem Bazylea IV było trudne dla banku

System raportujący LCR oraz NSFR cały czas rozwija się. Prace nad projektem Bazylea IV były planowane na kilka miesięcy. W Hurtowni danych jeden wspólny mechanizm generuje zestaw ekstraktów z danymi. Na tej podstawie przygotowywane są odpowiednie raporty, m.in. LCR i NSFR. Zmiany w jednym raporcie mogą więc negatywnie wpłynąć na pozostałe. 

Jak pracować nad projektem Bazylea IV, aby maksymalnie zminimalizować wpływ na istniejące już raporty

Wydawało się, że naturalnym rozwiązaniem będzie powołanie odrębnego środowiska w banku, przeznaczonego tylko dla projektu Bazylea IV. Na nim prowadzone byłyby prace: 

  • developerskie, zarówno po stronie dostawcy, jak i wsparcia IT
  • testowe, po stronie biznesu
  • produkcyjne, pod pełne testy biznesu na danych produkcyjnych (nie zamaskowanych).

Takie rozwiązanie, pomimo spełnienia głównej potrzeby biznesowej, jest drogie i w perspektywie czasu narażone również na inne ryzyka.

Od autora

Zanim postaram się opisać przedstawione powyżej rozwiązanie na czele kolejnych proponowanych rozwiązań, przedstawię zarys działania systemu, aby lepiej wyjaśnić nasze decyzje projektowe.

Jak wygląda raportowanie wskaźników w banku

Wskaźniki krótkoterminowy LCR (Liquidity Coverage Ratio) oraz długoterminowy NSFR (Net Stable Funding Ratio) są raportowane do:

  • Zarządu Banku (LCR)
  • NBP (Narodowy Bank Polski)
  • EBA (European Banking Authority).

LCR raportowany jest codziennie do Zarządu Banku, a co miesiąc - do regulatora. Proces raportowy LCR jest zautomatyzowany, a raporty NSFR generujemy na żądanie. Te dwa procesy działają jednak na podobnej zasadzie.

Proces raportowy możemy podzielić na trzy etapy:

  • Pierwszy – przygotowanie ekstraktów na Hurtowni danych oraz ich dystrybucja na serwer aplikacyjny – wsparcie IT
  • Drugi – wczytanie ekstraktów do aplikacji oraz przygotowanie raportów – po stronie dostawcy
  • Trzeci – weryfikacja raportów oraz wysyłka - biznes


Rys. 1. Schemat logiczny

Na rysunku 1 przedstawiamy ogólnie, jak wygląda proces tworzenia danych źródłowych. Wyniki z Hurtowni danych są wykorzystywane na 2 sposoby:

  1. Do tabel wynikowych – udostępniamy je w BI operacyjnym, w celach kontrolnych
  2. Jako pliki płaskie – tzw. ekstrakty są przesyłane wewnętrznymi procesami transferowymi do miejsca docelowego na serwerach aplikacyjnych, skąd są wczytywane przez aplikacje.


Rys. 2. Transfer przepływu danych 

Rysunek 2 bardziej szczegółowo przedstawia, w jaki sposób dane są przetwarzane na potrzeby raportowania:

  1. Schematy hurtowni danych – tutaj znajdują się dane źródłowe, wczytywane za pomocą procesów ETL na DWH za dzień poprzedni (datę -1). Procesy są ułożone w tzw. drzewo zależności, według którego są kolejno uruchamiane. Podobnie zdefiniowany jest proces, który generuje ekstrakty aplikacyjne. Czas jego uruchomienia zależy m.in. od zakończenia procesów zależnych ETL, które są odpowiedzialne za załadowanie wymaganego obszaru danych raportowych w hurtowni danych.
  2. Schemat aplikacyjny – w tym miejscu znajduje się część aplikacyjna, odpowiedzialna za transformację danych do przygotowanego i uzgodnionego z dostawcą formatu (tzw. mappingu) oraz zapisanie ich w formie plików płaskich (tzw. ekstraktów). To po prostu zwykły proces, który uruchamia się automatycznie w trybie dziennym, po załadowaniu w hurtowni wymaganych danych – tzn. wykonaniu wszystkich procesów zależnych.
  3. Pliki płaskie – inaczej ekstrakty. To właśnie w tej formie dane trafiają wewnętrznymi transferami bankowymi w odpowiednie miejsce na serwerach aplikacyjnych. Transfery odbywają się z ustaloną wcześniej częstotliwością – obecnie jest to 30 minut.
  4. Przetwarzanie w aplikacji – po stronie aplikacji działa mechanizm, który automatycznie weryfikuje, czy pojawił się już komplet ekstraktów za poprzedni dzień. Po wczytaniu ich do aplikacji uruchamia się szereg procesów i powstają gotowe raporty. W tym miejscu kończy się automatyczne przygotowanie raportów LCR. Procesy są na tyle powtarzalne, że mogły zostać w pełni zautomatyzowane, a rolą użytkownika biznesowego jest weryfikacja gotowych raportów.
  5. Wysyłka do NBP – jest wymogiem regulacyjnym. Chociaż sama aplikacja nie wysyła raportów automatycznie, jest taka możliwość w aplikacji – a dokładniej, w części obsługiwanej przez użytkownika biznesowego. Raport LCR jest również analizowany codziennie przez Zarząd Banku.


Rys. 3. Proces generowania ekstraktów na DWH

Proces przygotowania ekstraktów dla aplikacji możemy prześledzić na rysunku 3. Jako wsparcie IT zapewniamy odpowiednie mapowanie danych, które:

  • odpowiada na potrzeby biznesowe
  • jest uzgodnione z dostawcą i zintegrowane z jego aplikacją. 

Wszelkie zmiany po stronie ekstraktów muszą działać z aplikacją, do której te ekstrakty są wczytywane. Często zmiana biznesowa wymaga synchronizacji po stronie hurtowni danych oraz po stronie aplikacji (aktualizacja aplikacji). Za mapowanie danych odpowiedzialne są koleżanki analityczki, które bardzo dokładnie znają każdy aspekt złożonego procesu wytwarzania ekstraktów. Analityczki:

  • odczytują potrzeby biznesowe i przekładają je na konkretne zmiany
  • rozdzielają zadania w zespole i koordynują prace wytwórcze (często nad kilkoma równoległymi zmianami) 
  • wprowadzają konieczne zmiany z dostawcą.

Proces wytwórczy ekstraktów w liczbach

  • 142 zadania (tzw. joby) – uruchamiane sekwencyjnie wg zdefiniowanego drzewa zależności realizujące zdekomponowane kolejne zadania procesu wytwórczego ekstraktów, np.

INSERT INTO TABELA_1 SELECT FROM WIDOK_1; COMMIT;

  • 259 widoków użytych do przygotowania ekstraktów, w tym 52 nowe widoki utworzone na potrzeby samego projektu Bazylea IV
  • 162 tabele użyte do przygotowania ekstraktów, w tym 9 nowych tabel utworzonych na potrzeby projektu Bazylea IV
  • od 8 do 4306 linii kodu liczą sobie widoki (od 70 do 225999 znaków)
  • od kilkudziesięciu minut do kilku godzin może trwać proces generacji ekstraktów (w zależności od typu ekstraktów oraz chwilowego obciążenia hurtowni danych)
  • od 1 sekundy do 1 godziny 43 minut 34 sekund wynosi średni czas wykonywania pojedynczego zadania
  • 8 ekstraktów to wynik procesu
  • od 3 do 1 600 427 rekordów mogą zawierać ekstrakty (w sumie ~ 7 milionów rekordów!)
  • 2.77 GB (346 MB spakowane) ważą miesięczne ekstrakty NSFR3, 1.21 GB (113 MB spakowane) ważą dzienne ekstrakty LCR.

Podsumowanie

Proces, który generuje ekstrakty jest dobrze skalowalny. Za pomocą parametrów konfiguracyjnych decydujemy m.in. o liczbie jednocześnie uruchomionych zadań i maksymalnej liczbie wątków. Poszczególne zadania są uruchamiane według odpowiedniej hierarchii – każde zadanie może wystartować dopiero w momencie, kiedy zakończą się wszystkie zależne, wcześniejsze zadania. Widoki są najczęściej modyfikowaną częścią procesu, zwykle podlegają rozszerzeniu o nowe pola, warunki, unie – co powoduje, że muszą być ciągle monitorowane pod kątem czasu ich wykonania. Jeżeli zajdzie potrzeba, zadania są dekomponowane w celu optymalizacji czasu ich wykonania. Przyjęte rozwiązanie pozwala bardzo elastycznie rozwijać proces tworzący ekstrakty dla aplikacji.

W kolejnej części

Proces testów regresji danych, widoczny na rysunku 3, szczegółowo omawiamy w kolejnym artykule. Przedstawiamy w nim wdrożenie projektu Bazylea IV w naszym banku i odpowiadamy na pytania:

  • dlaczego takie zadanie w ogóle powstało?
  • na jakie potrzeby biznesowe odpowiadało?
  • z jakimi problemami zmierzyliśmy się w projekcie Bazylea IV?
  • dlaczego wybraliśmy takie, a nie inne rozwiązanie „szyte na miarę”?