Jak zbudować funkcjonalną i wydajną infrastrukturę analityczną w firmie fintechowej?

Jak zbudować funkcjonalną i wydajną infrastrukturę analityczną w firmie fintechowej?

12 marca 2018

Aby odpowiedzieć na tytułowe pytanie, w pierwszej kolejności warto zastanowić się, jakie zadania ma realizować zespół analityczny. W FinAi analitycy odpowiadają nie tylko za przegląd przeszłych zdarzeń na platformie czy blogu i wyciąganie z nich wniosków. Przede wszystkim są odpowiedzialni za wdrożenie usług stanowiących integralną część procesu, przez który przechodzi każdy klient platformy – od samego początku jego działania na produkcji.

Łącznie tworzy to całkiem pokaźną listę zadań obejmującą między innymi:

  • opracowanie rozwiązań biometrycznych weryfikujących tożsamość klientów w procesie elektronicznym;
  • wdrożenie reguł przeciwdziałających próbom wyłudzeń (silnik antyfraudowy) – czyli co nam nie gra i co wolimy sprawdzić dwa razy;
  • analizę efektywności procesu pod względem user experience – gdzie klienci najczęściej przerywają proces, gdzie spędzają/tracą najwięcej czasu;
  • proces wyboru ofert kredytów – jak klienci sortują oferty, które oglądają, co decyduje o ostatecznej decyzji;
  • badanie kosztów konwersji i pozyskania klienta – ile pieniędzy musieliśmy wydać na kampanię marketingową, aby użytkownik założył u nas konto, a ile, żeby wziął kredyt za naszym pośrednictwem;
  • monitoring efektywności komponentów platformy – czasy odpowiedzi, downtime’y itp.,  zarówno usług wdrożonych przez naszych deweloperów, jak i API dostawców zewnętrznych;
  • profilowanie klientów pod względem marketingowym – jakie cechy wyekstrahowane z ciasteczka pozwalają wskazać grupy ludzi o największej oczekiwanej konwersji;
  • skuteczność silnika decyzyjnego i jakości pracy back-office – z jakich powodów przekierowujemy klientów na dodatkowe sprawdzenia manualne, ile nas to kosztuje i czy to, co robimy, jest naprawdę optymalne.

Jak widać, zakres zainteresowań mamy rozległy, więc chociażby z tego powodu powinniśmy podejść do pracy z namysłem. Tu z pomocą przychodzi metoda eliminacji odpowiadająca na pytanie: jak nie chcielibyśmy podchodzić do tematu. A na pewno nie tak, jak dzieje się to w większości dużych korporacji, w tym finansowych.

Jak wygląda praca analityka w takiej firmie jak FinAi?

Po lżejszych lub cięższych bojach (bądźmy poważni, najczęściej bardzo ciężkich) udaje się wreszcie dostać dostęp do interesujących tabel w hurtowni danych. Z zastanych tam danych próbujemy wyciągnąć jak najwięcej wniosków, ale biorąc pod uwagę, że tabela była projektowana wieki temu – najczęściej pod kątem innych zastosowań niż zadanie powierzone biednemu analitykowi – przypomina to wyciskanie wody z kamienia. Oczywiście jeśli analityk jest ambitny i zależy mu na dostarczeniu rezultatów wysokiej jakości, zorientuje się, że jego źródło danych wymaga kilku usprawnień. Zgłosi więc formalny change request do działu IT, który, jeśli nie wystąpiło chociaż jedno z wielu możliwych uchybień formalnych pozwalających na zlikwidowanie problemu u źródła, ochoczo umieści to zadanie na końcu wielomiesięcznej kolejki zadań wdrożeniowych.

Mimo że smutna sytuacja opisana powyżej raczej nam nie grozi, gdyż nasze „swetry” (lokalne określenie deweloperów) są całkiem kooperatywne, postanowiliśmy ugryźć temat inaczej. Najprostszym rozwiązaniem jest możliwie duże uniezależnienie się od informatyków, czyli zostanie właścicielem hurtowni danych. W FinAi podeszliśmy do tego poważnie, co oznacza, że zespół analityczny bierze aktywny udział nie tylko w projektowaniu struktury hurtowni, ale także zajmuje się pozyskiwaniem danych na dużo wcześniejszym etapie – w momencie ich generowania przez usługi aplikacji.

1. Skąd wziąć dane?

Sprawa wydaje się oczywista – najlepiej sięgnąć do baz danych mikroserwisów składających się na naszą platformę, a skoro już działamy w Azure, ewentualnie zasilić się informacjami logowanymi do Application Insights. W tym momencie jednak pojawia się kilka „ale”. Po pierwsze mikroserwisy przechowują tylko takie dane, które są niezbędne do funkcjonowania aplikacji, a nie do jej analizowania. Ponadto Application Insights, mimo że odkłada wiele ciekawych informacji, zdecydowanie nie pokrywa całości naszego obszaru zainteresowań, a poza tym część metryk wylicza niepoprawnie.

Aby uniknąć tych problemów, zdecydowaliśmy się na przesyłanie danych z procesu za pomocą eventów. Analitycy, we współpracy z informatykami, zakodowali zdarzenia przekazujące informacje o wszelkich zdarzeniach w naszym procesie, generowanych przez:

  • użytkownika np. przejście do kolejnego okna procesu kredytowego, wprowadzenie danych o dochodach, posortowanie ofert kredytowych,
  • serwisy zewnętrzne np. wynik sprawdzenia w biurach informacji kredytowych,
  • modele FinAi – wynik automatycznego porównania zdjęcia z dowodu osobistego i selfie,
  • a także działania naszych mikroserwisów – automatyczne wykonanie selfie przez aplikację mobilną.

Tak, trzeba się przy tym napracować, ale dzięki temu zyskujemy niemal pełną kontrolę nad zakresem i poziomem granulacji danych, które potem chcemy analizować.

2. Jak zebrać dane? 

Zbieranie eventów generowanych przez poszczególne serwisy odbywa się w kilku etapach. Pierwszą warstwą jest klient publiczny – Azure Function zbierający zdarzenia, które następnie przekazywane są do Event Huba – usługi publisher/subscriber sygnowanej przez Microsoft do przetwarzania danych telemetrycznych w dużej skali. Takie wykorzystanie funkcjonalności, jakie daje Azure, pozwala na odkładanie w hubie dużej liczby jednocześnie generowanych zdarzeń, bez ryzyka przeciążenia ani co gorsza utraty informacji.

Dopiero za nim znajduje się Event Processor – autorska aplikacja FinAi – który przetwarza zdarzenia na informacje pożądane z analitycznego punktu widzenia. Architektura Event Processora została oparta o niedeterministyczne maszyny stanu i służy rozpoznawaniu wzorców w strumieniu przychodzących zdarzeń. W projektowaniu aplikacji wzorowaliśmy się na Pattern API wykorzystanym w Apache Flink. To tutaj odbywa się przetwarzanie pojedynczych zdarzeń do informacji, które wykorzystamy nie tylko do ewaluacji platformy w przyszłości, ale także do wysyłania zdarzeń będących elementami silnika decyzyjnego procesu, takich jak liczba nieudanych prób logowania do danego konta w określonym przedziale czasu czy złożenie kilku eventów bazowych składających się na jedną informację istotną dla procesu.

3. Co chcemy osiągnąć?

Kolejnym etapem jest przesłanie tak przeprocesowanych zdarzeń do hurtowni. Tu oczywiście należy sobie odpowiedzieć na pytanie, co jest dla nas ważniejsze – pełna elastyczność i możliwość przeprowadzania wszelkich analiz, jakie kiedykolwiek przyjdą nam do głowy, czy raczej zbudowanie struktury zoptymalizowanej pod raporty i metryki, które przemyśleliśmy z wyprzedzeniem.

Pierwsze podejście wiąże się z utrzymaniem stosunkowo płaskiej, niskoprzetworzonej struktury danych, złożonej z dużej liczby stosunkowo prostych tabel – skoro nie wiemy, co i na jakim poziomie granulacji może nam się przydać, musimy przechowywać dane w takiej właśnie formie. Poza wspomnianą już elastycznością to podejście ma same wady. Opracowanie relatywnie prostego zestawienia wiąże się z wykonaniem zapytania łączącego kilkanaście tabel. Dodatkowo niski poziom agregacji czy wręcz jej brak skutkuje ogromną liczbą rekordów. Oba te czynniki będą znacznie obniżać szybkość wykonywania zapytania, a sama jego złożoność zwiększa ryzyko popełnienia błędu.

Naturalnym rozwiązaniem wydaje się ugryzienie tematu z drugiej strony. Poświęcamy więc dużo czasu na wymyślenie:

  • jakie informacje i w jakich przekrojach chcemy regularnie analizować,
  • co raportować poszczególnym zespołom w ramach firmy, a co bankom, które sprzedają kredyty za pośrednictwem naszej platformy.

Tak, one też będą chciały wiedzieć, jak prezentują się na tle konkurencji, czym wygrywają, a czym przegrywają wyścig o klienta. Na tej podstawie możliwe jest opracowanie docelowej struktury hurtowni z taką prezentacją danych, która umożliwi wydajne jej odpytywanie, tzn. pojedynczy raport powstaje w wyniku kwerendy bazującej na maksymalnie dwóch, trzech tabelach, nie licząc słowników. Poza zwiększoną wydajnością zyskujemy bazę danych o kontrolowanej strukturze (bez tysiąca tabel), jak i liczności. Na etapie projektowania hurtowni należy koniecznie pamiętać o najbardziej prawdopodobnych kierunkach rozwoju czy zwykłych modyfikacjach procesu, których na pewno będzie dużo, szczególnie zaraz po uruchomieniu produkcyjnym. Chodzi o to, aby wdrożenie tego typu zmian nie skutkowało koniecznością modyfikacji logiki hurtowni czy jej znaczących obszarów.

4. Jak przesłać dane?

Jakie następstwa ma powyższy wybór? Przede wszystkim przenosi istotną część przetwarzania informacji ze zdarzeń wysyłanych przez event procesor do ETL-a. W tej części przetwarzania danych skupiają się największe wyzwania – nie tylko łączenie i agregacja informacji z eventów do rekordów tabel analitycznych, ale także kwestie wydajnościowe oraz kompletności i zgodności danych. Między innymi z tych względów ETL został podzielony na dwie fazy. W pierwszej zdarzenia, reprezentowane jako pojedyncze rekordy, trafiają do kilku tabel, specyficznych dla typów eventów. Dopiero z nich, w znacznie bardziej złożonym procesie, następuje przetworzenie eventów w rekordy analityczne.

To rozwiązanie ma wiele zalet. Po pierwsze umożliwia relatywnie szybkie przesyłanie danych z Event Huba do hurtowni i przeniesienie do niej najbardziej złożonego etapu ETL. Ponadto odłożenie w hurtowni danych surowych, nienadających się z opisanych wcześniej powodów wydajnościowych do bezpośredniego wykorzystania w analityce, umożliwia łatwe ponowne zasilenie tabel analitycznych w razie wystąpienia błędów przetwarzania, a także wsteczną modyfikację danych analitycznych, jeśli okazałoby się, że jednak nie uwzględniliśmy w nich istotnych informacji.

A gdzie tu miejsce na analitykę, data science i modelowanie?

Ono zaczyna się dopiero wtedy, gdy skutecznie przebrniemy przez proces opisany powyżej. Jesteśmy przekonani, że nie da się prowadzić firmy opartej na danych. FinAi natomiast jest takim przedsięwzięciem, że od początku jego istnienia musimy zadbać o to, by gromadzić wszelkie możliwe informacje i przetwarzać je do formy pozwalającej na ich bezpośrednie wykorzystanie w analityce i podejmowanie decyzji. A fakt, że zespół data science jest właścicielem danych niemal od momentu ich wygenerowania przez pojedynczy mikroserwis, pozwala na rozwiązanie głównego problemu, z jakim borykają się analitycy – braku informacji. U nas nie ma miejsca na takie sytuacje – jeśli czegoś nam brakuje, natychmiast pozyskujemy dane z procesu i przesyłamy je do środowiska analitycznego.
 
 Autor: Marcin Orzechowski, 
Unia Europejska
Location icon Facebook icon Twitter icon Google+ icon LinkedIn icon Technology icon Business icon Marketing icon Phone icon Mail icon User icon Tag icon Bubble icon Arrow right icon Arrow left icon Calendar PR Contact