Od ubiegłego roku nasza firma zaczęła organizować hackatony. Pierwszy taki konkurs był bardzo udany, o czym pisaliśmy w . Drugi hackaton odbył się w lutym 2019 roku i był nie mniej udany. O celach utrzymania tego ostatniego nie tak dawno temu organizator.
Uczestnicy otrzymali dość ciekawe zadanie z pełną swobodą w wyborze stosu technologicznego do jego realizacji. Konieczne było wdrożenie platformy decyzyjnej umożliwiającej wygodne wdrażanie funkcji scoringowych klientów, która mogłaby współpracować z szybkim przepływem aplikacji, wytrzymywać duże obciążenia, a sam system był łatwo skalowalny.
Zadanie nie jest trywialne i można je rozwiązać na wiele sposobów, o czym przekonaliśmy się podczas pokazu końcowych prezentacji projektów uczestników. Na hackatonie wzięło udział 6 5-osobowych zespołów, wszyscy uczestnicy mieli dobre projekty, ale nasza platforma okazała się najbardziej konkurencyjna. Mamy bardzo ciekawy projekt, o którym chciałbym opowiedzieć w tym artykule.
Nasze rozwiązanie to platforma oparta na architekturze Serverless wewnątrz Kubernetes, która skraca czas potrzebny na wprowadzenie nowych funkcji na produkcję. Umożliwia analitykom pisanie kodu w dogodnym dla nich środowisku i wdrażanie go do produkcji bez udziału inżynierów i programistów.
Co jest punktowane
Tinkoff.ru, podobnie jak wiele nowoczesnych firm, ma scoring klienta. Scoring to system oceny klientów oparty na statystycznych metodach analizy danych.
Klient zwraca się do nas przykładowo z prośbą o udzielenie mu pożyczki lub otwarcie u nas indywidualnego konta przedsiębiorcy. Jeśli planujemy udzielić mu pożyczki, to musimy ocenić jego wypłacalność, a jeśli rachunek prowadzi indywidualny przedsiębiorca, to musimy mieć pewność, że klient nie będzie przeprowadzał oszukańczych transakcji.
Podstawą do podejmowania takich decyzji są modele matematyczne, które analizują zarówno dane z samej aplikacji, jak i dane z naszego magazynu. Oprócz scoringu, podobne metody statystyczne można wykorzystać także w usłudze generowania indywidualnych rekomendacji nowych produktów dla naszych klientów.
Metoda takiej oceny może przyjmować różnorodne dane wejściowe. A w pewnym momencie możemy dodać do wejścia nowy parametr, który na podstawie wyników analizy danych historycznych zwiększy współczynnik konwersji korzystania z usługi.
Dysponujemy ogromną ilością danych na temat relacji z klientami, a ilość tych informacji stale rośnie. Aby scoring działał, przetwarzanie danych wymaga również reguł (lub modeli matematycznych), które pozwalają szybko zdecydować, komu zatwierdzić wniosek, komu odmówić, a komu zaoferować jeszcze kilka produktów, oceniając ich potencjalne zainteresowanie.
Do postawionego zadania wykorzystujemy już wyspecjalizowany system decyzyjny , który w oparciu o zasady ustalone przez analityków, technologów i programistów decyduje o zatwierdzeniu lub odrzuceniu danego produktu bankowego klientowi.
Na rynku dostępnych jest wiele gotowych rozwiązań, zarówno modeli scoringowych, jak i samych systemów decyzyjnych. W naszej firmie stosujemy jeden z takich systemów. Ale biznes się rozwija, dywersyfikuje, zwiększa się zarówno liczba klientów, jak i liczba oferowanych produktów, a wraz z tym pojawiają się pomysły, jak usprawnić dotychczasowy proces decyzyjny. Z pewnością osoby pracujące z istniejącym systemem mają wiele pomysłów, jak uczynić go prostszym, lepszym, wygodniejszym, ale czasami pomysły z zewnątrz się przydadzą. Celem Nowego Hackathonu było zbieranie dobrych pomysłów.
Zadanie
Hackaton odbył się 23 lutego. Uczestnikom zaproponowano zadanie bojowe: opracować system podejmowania decyzji, który musiał spełniać szereg warunków.
Powiedziano nam, jak funkcjonuje istniejący system, jakie trudności pojawiają się w trakcie jego działania, a także jakie cele biznesowe ma realizować rozwijana platforma. System musi charakteryzować się krótkim czasem wprowadzenia na rynek w celu opracowania reguł, aby działający kod analityków jak najszybciej trafił do produkcji. A w przypadku napływu wniosków czas na podjęcie decyzji powinien być jak najkrótszy. Tworzony system musi także posiadać możliwości cross-sellingu, aby dać klientowi możliwość zakupu innych produktów firmy, jeśli zostaną one przez nas zatwierdzone i będą potencjalnie zainteresowane ze strony klienta.
Wiadomo, że nie da się z dnia na dzień napisać gotowego projektu, który z pewnością trafi do produkcji, a pokrycie całego systemu jest dość trudne, dlatego poproszono nas o wdrożenie chociaż jego części. Ustalono szereg wymagań, jakie musi spełniać prototyp. Można było spróbować zarówno uwzględnić wszystkie wymagania w całości, jak i szczegółowo pracować nad poszczególnymi sekcjami rozwijanej platformy.
Jeśli chodzi o technologię, wszyscy uczestnicy otrzymali pełną swobodę wyboru. Można było zastosować dowolne koncepcje i technologie: strumieniowanie danych, uczenie maszynowe, pozyskiwanie zdarzeń, big data i inne.
Nasze rozwiązanie
Po krótkiej burzy mózgów zdecydowaliśmy, że rozwiązanie FaaS będzie idealne do wykonania zadania.
Dla tego rozwiązania konieczne było znalezienie odpowiedniego frameworku Serverless, który zaimplementowałby reguły tworzonego systemu decyzyjnego. Ponieważ Tinkoff aktywnie wykorzystuje Kubernetes do zarządzania infrastrukturą, przyjrzeliśmy się kilku gotowym rozwiązaniom opartym na nim, o czym opowiem więcej później.
Aby znaleźć najskuteczniejsze rozwiązanie, spojrzeliśmy na powstający produkt oczami jego użytkowników. Głównymi użytkownikami naszego systemu są analitycy zaangażowani w rozwój reguł. Reguły muszą zostać wdrożone na serwerze lub, jak w naszym przypadku, wdrożone w chmurze, aby móc później podejmować decyzje. Z punktu widzenia analityka przepływ pracy wygląda następująco:
- Analityk pisze skrypt, regułę lub model ML na podstawie danych z hurtowni. W ramach hackathonu zdecydowaliśmy się skorzystać z Mongodb, ale wybór systemu przechowywania danych nie jest tutaj istotny.
- Po przetestowaniu opracowanych reguł na danych historycznych analityk przesyła swój kod do panelu administracyjnego.
- Aby zapewnić wersjonowanie, cały kod trafi do repozytoriów Git.
- Poprzez panel administracyjny możliwe będzie wdrożenie kodu w chmurze jako osobnego funkcjonalnego modułu Serverless.
Wstępne dane od klientów muszą przejść przez wyspecjalizowaną usługę Enrichment, mającą na celu wzbogacenie wstępnego żądania o dane z hurtowni. Istotne było wdrożenie tej usługi w taki sposób, aby współpracowała z jednym repozytorium (z którego analityk pobiera dane przy opracowywaniu reguł) w celu zachowania jednolitej struktury danych.
Jeszcze przed hackatonem zdecydowaliśmy się na framework Serverless, z którego skorzystamy. Obecnie na rynku dostępnych jest całkiem sporo technologii realizujących to podejście. Najpopularniejsze rozwiązania w ramach architektury Kubernetes to Fission, Open FaaS i Kubeless. Są nawet .
Po rozważeniu wszystkich za i przeciw dokonaliśmy wyboru . Ta platforma bezserwerowa jest dość łatwa w zarządzaniu i spełnia wymagania zadania.
Aby pracować z Fission, musisz zrozumieć dwa podstawowe pojęcia: funkcję i środowisko. Funkcja to fragment kodu napisany w jednym z języków, dla których istnieje środowisko Fission. obejmuje Python, JS, Go, JVM i wiele innych popularnych języków i technologii.
Fission może również wykonywać funkcje podzielone na kilka plików, spakowanych w archiwum. Działanie Fission w klastrze Kubernetes zapewniają wyspecjalizowane pody, którymi zarządza sam framework. Aby móc współdziałać z zasobnikami klastra, każda funkcja musi mieć przypisaną własną trasę, do której można przekazać parametry GET lub treść żądania w przypadku żądania POST.
W rezultacie planowaliśmy uzyskać rozwiązanie, które umożliwiłoby analitykom wdrażanie opracowanych skryptów reguł bez udziału inżynierów i programistów. Opisane podejście eliminuje także potrzebę przepisywania przez programistów kodu analityka na inny język. Na przykład dla obecnego systemu decyzyjnego, z którego korzystamy, musimy pisać reguły w wysoce wyspecjalizowanych technologiach i językach, których zakres jest bardzo ograniczony, a ponadto istnieje silna zależność od serwera aplikacji, ponieważ wszystkie projekty regulaminów bankowych są wdrażane w jednym środowisku. W rezultacie, aby wdrożyć nowe reguły, konieczne jest wydanie całego systemu.
W proponowanym przez nas rozwiązaniu nie ma potrzeby publikowania reguł, kod można łatwo wdrożyć jednym kliknięciem. Ponadto zarządzanie infrastrukturą w Kubernetesie pozwala nie myśleć o obciążeniu i skalowaniu; takie problemy rozwiązuje się od razu po wyjęciu z pudełka. Natomiast zastosowanie jednej hurtowni danych eliminuje konieczność porównywania danych w czasie rzeczywistym z danymi historycznymi, co upraszcza pracę analityka.
Co mamy
Ponieważ na hackaton przyszliśmy z gotowym rozwiązaniem (w naszych fantazjach), wystarczyło, że wszystkie nasze myśli zamieniliśmy na linijki kodu.
Kluczem do sukcesu każdego hackatonu jest przygotowanie i dobrze napisany plan. Dlatego pierwszą rzeczą, którą zrobiliśmy, było podjęcie decyzji, z jakich modułów będzie składać się architektura naszego systemu i z jakich technologii skorzystamy.
Architektura naszego projektu wyglądała następująco:
Diagram ten przedstawia dwa punkty wejścia, analityka (głównego użytkownika naszego systemu) i klienta.
Proces pracy jest zorganizowany w ten sposób. Analityk opracowuje funkcję reguł i funkcję wzbogacania danych dla swojego modelu, przechowuje swój kod w repozytorium Git i wdraża swój model w chmurze za pośrednictwem aplikacji administratora. Zastanówmy się, jak zostanie wywołana wdrożona funkcja i podejmijmy decyzje dotyczące żądań przychodzących od klientów:
- Klient wypełnia formularz znajdujący się na stronie internetowej i przesyła swoje żądanie do administratora. Wniosek, co do którego należy podjąć decyzję, trafia na wejście do systemu i jest rejestrowany w bazie danych w oryginalnej postaci.
- Następnie surowe żądanie jest wysyłane do wzbogacenia, jeśli zajdzie taka potrzeba. Wstępne żądanie możesz uzupełnić danymi zarówno z usług zewnętrznych, jak i z magazynu. Wynikowe wzbogacone zapytanie jest również przechowywane w bazie danych.
- Uruchamiana jest funkcja analityczna, która pobiera wzbogacone zapytanie jako dane wejściowe i generuje rozwiązanie, które jest również zapisywane w pamięci.
Zdecydowaliśmy się na wykorzystanie MongoDB jako magazynu w naszym systemie ze względu na zorientowane na dokumenty przechowywanie danych w formie dokumentów JSON, ponieważ usługi wzbogacania, w tym pierwotne żądanie, agregowały wszystkie dane poprzez kontrolery REST.
Mieliśmy więc XNUMX godziny na wdrożenie platformy. Całkiem pomyślnie rozdzieliliśmy role, każdy członek zespołu miał swój własny obszar odpowiedzialności w naszym projekcie:
- Front-endowe panele administracyjne do pracy analityka, za pomocą których mógł pobierać reguły z systemu kontroli wersji pisanych skryptów, wybierać opcje wzbogacania danych wejściowych oraz edytować skrypty reguł online.
- Administrator backendu, w tym REST API na froncie i integracja z VCS.
- Konfiguracja infrastruktury w Google Cloud i rozwój usługi wzbogacania danych źródłowych.
- Moduł umożliwiający integrację aplikacji administracyjnej ze frameworkiem Serverless w celu późniejszego wdrażania reguł.
- Skrypty reguł testowania wydajności całego systemu i agregacji analityki na temat przychodzących aplikacji (podjętych decyzji) w celu ostatecznej demonstracji.
Zacznijmy po kolei.
Nasz frontend został napisany w Angular 7 z wykorzystaniem bankowego UI Kit. Ostateczna wersja panelu administracyjnego wyglądała następująco:
Ponieważ czasu było mało, staraliśmy się wdrożyć tylko najważniejsze funkcjonalności. Aby wdrożyć funkcję w klastrze Kubernetes, należało wybrać zdarzenie (usługę, dla której należy wdrożyć regułę w chmurze) oraz kod funkcji realizującej logikę decyzyjną. Dla każdego wdrożenia reguły dla wybranej usługi zapisywaliśmy log tego zdarzenia. W panelu administracyjnym możesz zobaczyć logi wszystkich zdarzeń.
Cały kod funkcji przechowywany był w zdalnym repozytorium Git, co również należało ustawić w panelu administracyjnym. Aby dokonać wersji kodu, wszystkie funkcje zostały zapisane w różnych gałęziach repozytorium. Panel administracyjny zapewnia także możliwość modyfikacji pisanych skryptów, dzięki czemu przed wdrożeniem funkcji na produkcję można nie tylko sprawdzić napisany kod, ale także wprowadzić niezbędne zmiany.
Oprócz funkcji reguł zaimplementowaliśmy także możliwość stopniowego wzbogacania danych źródłowych za pomocą funkcji Wzbogacanie, których kodem były także skrypty, w których możliwe było przejście do hurtowni danych, wywołanie usług zewnętrznych i wykonanie wstępnych obliczeń . Aby zademonstrować nasze rozwiązanie, obliczyliśmy znak zodiaku klienta, który opuścił zapytanie i określiliśmy jego operatora komórkowego, korzystając z usługi REST innej firmy.
Backend platformy został napisany w Javie i zaimplementowany jako aplikacja Spring Boot. Początkowo planowaliśmy używać Postgres do przechowywania danych administracyjnych, ale w ramach hackatonu postanowiliśmy ograniczyć się do prostego H2, aby zaoszczędzić czas. Na backendzie zaimplementowano integrację z Bitbucket w celu wersjonowania funkcji wzbogacania zapytań i skryptów reguł. Do integracji ze zdalnymi repozytoriami Git wykorzystaliśmy , który jest rodzajem opakowania poleceń CLI, umożliwiającym wykonanie dowolnych instrukcji git przy użyciu wygodnego interfejsu oprogramowania. Mieliśmy więc dwa osobne repozytoria funkcji i reguł wzbogacania, a wszystkie skrypty podzielono na katalogi. Za pośrednictwem interfejsu użytkownika można było wybrać najnowsze zatwierdzenie skryptu dowolnej gałęzi repozytorium. Podczas wprowadzania zmian w kodzie poprzez panel administracyjny, w zdalnych repozytoriach tworzone były zatwierdzenia zmienionego kodu.
Aby zrealizować nasz pomysł potrzebowaliśmy odpowiedniej infrastruktury. Zdecydowaliśmy się na wdrożenie naszego klastra Kubernetes w chmurze. Nasz wybór padł na Google Cloud Platform. Framework bezserwerowy Fission został zainstalowany na klastrze Kubernetes, który wdrożyliśmy w Gcloud. Początkowo usługa wzbogacania danych źródłowych była wdrażana jako oddzielna aplikacja Java umieszczona w Podu wewnątrz klastra k8s. Jednak po wstępnej demonstracji naszego projektu w trakcie hackatonu polecono nam uelastycznić usługę Enrichment, aby zapewnić możliwość wyboru sposobu wzbogacania surowych danych przychodzących aplikacji. Nie mieliśmy innego wyjścia, jak tylko uczynić usługę wzbogacania również bezserwerową.
Do pracy z Fission użyliśmy interfejsu CLI Fission, który musi być zainstalowany na interfejsie CLI Kubernetes. Wdrażanie funkcji w klastrze k8s jest dość proste; wystarczy przypisać wewnętrzną trasę i wejście do funkcji, aby umożliwić ruch przychodzący, jeśli potrzebny jest dostęp poza klastrem. Wdrożenie jednej funkcji zwykle nie zajmuje więcej niż 10 sekund.
Końcowa prezentacja projektu i podsumowanie
Aby zademonstrować działanie naszego systemu, umieściliśmy na zdalnym serwerze prosty formularz, w którym można złożyć wniosek o jeden z produktów banku. Aby złożyć wniosek, należało podać swoje inicjały, datę urodzenia i numer telefonu.
Dane z formularza klienta trafiały do administratora, który jednocześnie wysyłał zapytania o wszystkie dostępne reguły, uprzednio wzbogacając dane zgodnie z określonymi warunkami i zapisując je we wspólnym magazynie. Łącznie wdrożyliśmy trzy funkcje podejmujące decyzje dotyczące przychodzących wniosków oraz 4 usługi wzbogacania danych. Po złożeniu wniosku Klient otrzymał naszą decyzję:
Oprócz odmowy lub akceptacji klient otrzymał także listę innych produktów, o które zapytania wysłaliśmy równolegle. W ten sposób zademonstrowaliśmy możliwość sprzedaży krzyżowej na naszej platformie.
W sumie dostępne były 3 fikcyjne produkty bankowe:
- Kredyt.
- Zabawka
- Hipoteka.
Podczas demonstracji wdrożyliśmy przygotowane funkcje i skrypty wzbogacające dla każdej usługi.
Każda reguła wymagała własnego zestawu danych wejściowych. Aby więc zatwierdzić kredyt hipoteczny, obliczyliśmy znak zodiaku klienta i połączyliśmy go z logiką kalendarza księżycowego. Aby zatwierdzić zabawkę, sprawdziliśmy, czy klient osiągnął pełnoletność, a aby udzielić pożyczki, wysłaliśmy wniosek do zewnętrznego otwartego serwisu w celu ustalenia operatora komórkowego i podjęto decyzję.
Staraliśmy się, aby nasza demonstracja była ciekawa i interaktywna, każdy obecny mógł przejść do naszego formularza i sprawdzić dostępność naszych fikcyjnych usług dla nich. A na sam koniec prezentacji zaprezentowaliśmy analitykę otrzymanych wniosków, która pokazała ile osób skorzystało z naszych usług, ilość zatwierdzeń i odmów.
Aby zbierać statystyki online, dodatkowo wdrożyliśmy narzędzie BI o otwartym kodzie źródłowym i przykręciłem go do naszego magazynu. Metabase umożliwia budowanie ekranów z analityką na interesujących nas danych, wystarczy zarejestrować połączenie z bazą danych, wybrać tabele (w naszym przypadku zbiory danych, ponieważ korzystaliśmy z MongoDB) i określić interesujące nas pola .
W rezultacie otrzymaliśmy dobry prototyp platformy decyzyjnej, a podczas demonstracji każdy słuchacz mógł osobiście sprawdzić jej działanie. Ciekawe rozwiązanie, gotowy prototyp i udana demonstracja pozwoliły nam zwyciężyć, pomimo silnej konkurencji ze strony innych zespołów. Jestem pewien, że na temat projektu każdego zespołu można również napisać ciekawy artykuł.
Źródło: www.habr.com