Pomysły i spotkania na temat tego, jakie inne procesy można zautomatyzować, pojawiają się codziennie w firmach różnej wielkości. Ale oprócz tego, że na stworzenie modelu można poświęcić dużo czasu, trzeba go poświęcić na jego ocenę i sprawdzenie, czy wynik nie jest przypadkowy. Po wdrożeniu każdy model musi być monitorowany i okresowo sprawdzany.
A to już wszystkie etapy, przez które trzeba przejść w każdej firmie, niezależnie od jej wielkości. Jeśli mówimy o skali i dziedzictwie Sbierbanku, liczba dopracowań rośnie wykładniczo. Do końca 2019 roku Sbierbank korzystał już z ponad 2000 modeli. Nie wystarczy tylko opracować model, konieczna jest integracja z systemami przemysłowymi, opracowanie data martów do budowy modeli i zapewnienie kontroli jego działania na klastrze.
Nasz zespół rozwija platformę Sber.DS. Pozwala rozwiązywać problemy uczenia maszynowego, przyspiesza proces testowania hipotez, w zasadzie upraszcza proces tworzenia i walidacji modeli, a także kontroluje wynik modelu w PROM.
Aby nie zawieść Waszych oczekiwań, z góry chcę powiedzieć, że ten post jest wprowadzający, a pod skrótem na początek opowiedziane jest to, co w zasadzie kryje się pod maską platformy Sber.DS. O cyklu życia modelu od stworzenia do wdrożenia opowiemy osobno.
Sber.DS składa się z kilku komponentów, z których kluczowe to biblioteka, system programistyczny i system wykonywania modeli.
Biblioteka kontroluje cykl życia modelu od momentu pojawienia się pomysłu na jego opracowanie, aż po jego wdrożenie w PROM, monitorowanie i wycofanie z eksploatacji. Wiele funkcji biblioteki jest podyktowanych zasadami regulatora, na przykład raportowanie i przechowywanie próbek treningowych i walidacyjnych. W rzeczywistości jest to rejestr wszystkich naszych modeli.
System deweloperski przeznaczony jest do wizualnego opracowywania modeli i metod walidacji. Opracowane modele przechodzą pierwotną walidację i są dostarczane do systemu wykonawczego w celu realizacji swoich funkcji biznesowych. Również w systemie wykonawczym model można umieścić na monitorze w celu okresowego uruchamiania metod walidacyjnych w celu kontroli jego działania.
W systemie występuje kilka rodzajów węzłów. Niektóre służą do łączenia się z różnymi źródłami danych, inne do przekształcania danych źródłowych i wzbogacania ich (znaczników). Istnieje wiele węzłów do budowania różnych modeli i węzłów do ich walidacji. Programista może ładować dane z dowolnych źródeł, przekształcać, filtrować, wizualizować dane pośrednie, dzielić je na części.
Platforma zawiera również gotowe moduły, które można przeciągnąć na obszar projektu. Wszystkie czynności wykonywane są za pomocą wizualizowanego interfejsu. W rzeczywistości możesz rozwiązać problem bez jednej linii kodu.
Jeśli wbudowane możliwości to za mało, system zapewnia możliwość szybkiego tworzenia własnych modułów. Zrobiliśmy zintegrowany tryb programowania oparty na dla tych, którzy tworzą nowe moduły od podstaw.
Architektura Sber.DS jest zbudowana na mikroserwisach. Istnieje wiele opinii na temat tego, czym są mikroserwisy. Niektórym wydaje się, że wystarczy rozbić monolityczny kod na części, ale i tak trafiają do tej samej bazy danych. Nasz mikroserwis musi komunikować się z innym mikroserwisem wyłącznie poprzez REST API. Brak obejść dla bezpośredniego dostępu do bazy danych.
Staramy się, aby usługi nie stawały się bardzo duże i powolne: pojedyncza instancja nie powinna zużywać więcej niż 4-8 gigabajtów pamięci RAM i powinna mieć możliwość poziomego skalowania żądań poprzez uruchamianie nowych instancji. Każda usługa komunikuje się z innymi tylko poprzez REST API (). Zespół odpowiedzialny za usługę jest zobowiązany do zachowania kompatybilności wstecznej API do ostatniego klienta, który z niego korzysta.
Rdzeń aplikacji jest napisany w Javie z wykorzystaniem Spring Framework. Rozwiązanie zostało pierwotnie zaprojektowane z myślą o szybkim wdrożeniu w infrastrukturze chmurowej, dlatego aplikacja jest budowana z wykorzystaniem systemu konteneryzacji (). Platforma stale ewoluuje, zarówno pod względem zwiększania funkcjonalności biznesowej (dodawane są nowe konektory, AutoML), jak i pod względem wydajności technologicznej.
Jednym z „chipów” naszej platformy jest to, że możemy uruchomić kod opracowany w interfejsie wizualnym na dowolnym systemie wykonywania modeli Sbierbanku. Teraz jest ich już dwóch: jeden na Hadoopie, drugi na OpenShift (Docker). Nie poprzestajemy na tym i tworzymy moduły integracyjne do uruchamiania kodu na dowolnej infrastrukturze, w tym on-premise iw chmurze. W zakresie możliwości efektywnej integracji z ekosystemem Sbierbanku planujemy również wsparcie pracy z istniejącymi środowiskami wykonawczymi. W przyszłości rozwiązanie będzie można elastycznie integrować „od razu po wyjęciu z pudełka” z dowolnym krajobrazem dowolnej organizacji.
Ci, którzy kiedykolwiek próbowali utrzymać rozwiązanie, które uruchamia Python na Hadoop w PROM, wiedzą, że nie wystarczy przygotować i dostarczyć niestandardowe środowisko Pythona do każdego węzła danych. Ogromna ilość bibliotek C/C++ do uczenia maszynowego wykorzystujących moduły Pythona nie pozwoli Ci spocząć w spokoju. Nie wolno nam zapominać o aktualizacji pakietów przy dodawaniu nowych bibliotek czy serwerów, przy zachowaniu kompatybilności wstecznej z już zaimplementowanym kodem modelu.
Istnieje kilka podejść, jak to zrobić. Na przykład przygotuj wcześniej kilka często używanych bibliotek i zaimplementuj je w PROM. Zwykle używa dystrybucji Cloudera Hadoop . Również teraz w Hadoop pojawiła się możliwość biegania - pojemniki. W niektórych prostych przypadkach istnieje możliwość dostarczenia kodu wraz z przesyłką .
Bank bardzo poważnie traktuje bezpieczeństwo uruchamiania kodu stron trzecich, dlatego w pełni wykorzystujemy nowe funkcje jądra Linuksa, w których proces działający w odizolowanym środowisku , możesz ograniczyć np. dostęp do sieci i dysku lokalnego, co znacznie ogranicza możliwość złośliwego kodu. Obszary danych każdego działu są chronione i dostępne tylko dla właścicieli tych danych. Platforma zapewnia, że dane z jednej domeny mogą dostać się do innej domeny tylko poprzez proces publikowania danych z kontrolą na wszystkich etapach, od dostępu do źródeł do lądowania danych w docelowej marcie.
W tym roku planujemy ukończyć MVP uruchomionych modeli napisanych w Python/R/Java na Hadoop. Postawiliśmy sobie ambitne zadanie nauczenia się uruchamiania dowolnego środowiska użytkownika na Hadoop, tak aby w żaden sposób nie ograniczać użytkowników naszej platformy.
Ponadto, jak się okazało, wielu specjalistów DS jest świetnych w matematyce i statystyce, robi fajne modele, ale nie bardzo orientuje się w transformacjach big data i potrzebuje pomocy naszych inżynierów danych do przygotowania próbek szkoleniowych. Postanowiliśmy pomóc naszym kolegom i stworzyć wygodne moduły do typowej transformacji i przygotowania funkcjonalności do modeli na silniku Spark. Dzięki temu więcej czasu będzie można poświęcić na tworzenie modeli, zamiast czekać, aż inżynierowie danych przygotują nowy zbiór danych.
Mamy ludzi z wiedzą z różnych dziedzin: Linux i DevOps, Hadoop i Spark, Java i Spring, Scala i Akka, OpenShift i Kubernetes. Następnym razem porozmawiamy o bibliotece modeli, o tym, jak model przechodzi przez cykl życia w firmie, jak przebiega walidacja i wdrożenie.
Źródło: www.habr.com