Pomysły i spotkania dotyczące tego, jakie inne procesy można zautomatyzować, pojawiają się w biznesach różnej wielkości codziennie. Jednak oprócz tego, że wiele czasu może zająć stworzenie modelu, należy poświęcić go na jego ocenę oraz sprawdzenie, czy uzyskiwany wynik nie jest przypadkowy. Po wdrożeniu każdy model należy monitorować i okresowo weryfikować.
To są etapy, które muszą przejść w każdej firmie, niezależnie od jej wielkości. Jeśli mówimy o skali i legacy Sberbanku, liczba delikatnych ustawień wzrasta wielokrotnie. Do końca 2019 roku w Sberbanku było używanych już ponad 2000 modeli. Samo opracowanie modelu to za mało, konieczna jest integracja z systemami przemysłowymi, opracowanie hurtowni danych do budowy modeli oraz zapewnienie kontroli nad jego działaniem w klastrze.
Nasz zespół opracowuje platformę Sber.DS. Umożliwia ona rozwiązywanie problemów związanych z uczeniem maszynowym, przyspiesza proces weryfikacji hipotez, zasadniczo upraszcza proces opracowywania i walidacji modeli, a także kontroluje wyniki działania modelu w PROM.
Aby nie zawieść Twoich oczekiwań, pragnę z góry powiedzieć, że ten post jest wprowadzeniem, a poniżej opowiadam o tym, co właściwie znajduje się w systemie platformy Sber.DS. Historię cyklu życia modelu od stworzenia do wdrożenia przedstawimy oddzielnie.
Sber.DS składa się z kilku komponentów, z których kluczowe to biblioteka, system tworzenia i system wykonawczy modeli.
Biblioteka kontroluje cykl życia modelu od momentu pomysłu na jego opracowanie do wdrożenia w PROM, monitorowania i wycofania z eksploatacji. Wiele możliwości biblioteki jest podyktowanych zasadami regulatora, na przykład sprawozdawczością i przechowywaniem zbiorów treningowych i walidacyjnych. W praktyce jest to rejestr wszystkich naszych modeli.
System opracowania jest przeznaczony do wizualnego tworzenia modeli i metod weryfikacji. Opracowane modele przechodzą wstępną walidację i są przekazywane do systemu wykonawczego w celu pełnienia swoich funkcji biznesowych. W systemie wykonawczym model może być monitorowany w celu okresowego uruchamiania metod walidacyjnych dla kontroli jego działania.
System posiada kilka typów węzłów. Niektóre są przeznaczone do łączenia z różnymi źródłami danych, inne - do transformacji danych źródłowych i ich wzbogacania (adnotacji). Istnieje wiele węzłów do budowania różnych modeli oraz węzłów do ich walidacji. Programista może ładować dane z dowolnych źródeł, przekształcać je, filtrować, wizualizować dane pośrednie i dzielić je na części.
Platforma zawiera również gotowe moduły, które można przeciągać na obszar roboczy. Wszystkie działania są realizowane za pomocą wizualnego interfejsu. Faktycznie można rozwiązać zadanie bez jednego wiersza kodu.
Jeśli wbudowane możliwości są niewystarczające, system daje możliwość szybkiego tworzenia własnych modułów. Wprowadziliśmy tryb zintegrowanego rozwoju oparty na dla tych, którzy tworzą nowe moduły "od podstaw".
Architektura Sber.DS oparta jest na mikrousługach. Istnieje wiele opinie na temat tego, czym są mikrousługi. Niektórzy uważają, że wystarczy podzielić monolityczny kod na części, jednak w dalszym ciągu korzystają z tej samej bazy danych. Nasza mikrousługa musi komunikować się z inną mikrousługą wyłącznie za pośrednictwem REST API. Żadne obejścia bezpośredniego dostępu do bazy danych.
Staramy się, aby usługi nie stawały się zbyt duże i nieporęczne: jedna instancja nie powinna zużywać więcej niż 4-8 gigabajtów pamięci RAM i musi zapewniać możliwość poziomej skalowalności zapytań poprzez uruchamianie nowych instancji. Każda usługa komunikuje się z innymi tylko za pośrednictwem REST API (). Zespół odpowiedzialny za usługę zobowiązuje się do zachowania wstecznej kompatybilności API do ostatniego klienta, który z niego korzysta.
Rdzeń aplikacji napisany jest w Javie z użyciem Spring Framework. Rozwiązanie zostało pierwotnie zaprojektowane do szybkiego wdrażania w infrastrukturze chmurowej, dlatego aplikacja zbudowana jest z użyciem systemu konteneryzacji (). Platforma nieustannie się rozwija, zarówno pod względem rozbudowy funkcjonalności biznesowej (dodawane są nowe konektory, AutoML), jak i efektywności technologicznej.
Jedną z „cech” naszej platformy jest to, że możemy uruchamiać kod opracowany w interfejsie graficznym na dowolnym systemie wykonawczym modeli Sberbanku. Obecnie są już dwa: jeden na Hadoopie, drugi — na OpenShift (Docker). Na tym nie zamierzamy poprzestawać i tworzymy moduły integracyjne do uruchamiania kodu na dowolnej infrastrukturze, w tym on-premise oraz w chmurze. W zakresie możliwości efektywnego wbudowania w ekosystem Sberbanku planujemy również wspierać współpracę z istniejącymi środowiskami wykonawczymi. W przyszłości rozwiązanie może być elastycznie wbudowane „z pudełka” w dowolny krajobraz każdej organizacji.
Ci, którzy kiedykolwiek próbowali wspierać rozwiązanie uruchamiające Python na Hadoopie w PROM, wiedzą, że nie wystarczy przygotować i dostarczyć środowisko Pythona na każdą datanodę. Ogromna liczba bibliotek C/C++ do uczenia maszynowego, które wykorzystują moduły Pythona, nie pozwoli na spokojny odpoczynek. Należy pamiętać o aktualizacji pakietów przy dodawaniu nowych bibliotek lub serwerów, zachowując zgodność wsteczną z już wdrożonym kodem modeli.
Istnieje kilka podejść do tego, jak to robić. Na przykład, można z wyprzedzeniem przygotować kilka często używanych bibliotek i wdrożyć je w PROM. W dystrybucji Hadoop od Cloudera zazwyczaj używa się do tego . Obecnie w Hadoopie pojawia się również możliwość uruchamiania -kontenerów. W niektórych prostych przypadkach można dostarczyć kod wraz z pakietem .
Bank bardzo poważnie podchodzi do bezpieczeństwa uruchamiania zewnętrznego kodu, dlatego maksymalnie wykorzystujemy nowe możliwości jądra Linuksa, gdzie proces uruchomiony w izolowanym środowisku , można ograniczyć, na przykład, dostęp do sieci i lokalnego dysku, co znacznie zmniejsza możliwości szkodliwego kodu. Obszary danych każdego działu są chronione i dostępne tylko dla właścicieli tych danych. Platforma gwarantuje, że dane z jednego obszaru mogą trafić do innego obszaru tylko poprzez proces publikacji danych z kontrolą na wszystkich etapach, od dostępu do źródeł po umiejscowienie danych w docelowej witrynie.
W tym roku planujemy zakończyć MVP uruchamiania modeli napisanych w Pythonie/R/Java na Hadoop. Postawiliśmy sobie ambitne zadanie nauczenia się uruchamiania dowolnego środowiska użytkownika na Hadoop, aby nie ograniczać użytkowników naszej platformy.
Co więcej, jak się okazało, wielu specjalistów DS doskonale zna matematykę i statystykę, tworzy świetne modele, ale nie radzi sobie z transformacjami dużych danych, więc potrzebują pomocy naszych inżynierów danych w przygotowywaniu zbiorów danych do szkolenia. Postanowiliśmy pomóc kolegom i stworzyć wygodne moduły do typowych transformacji i przygotowywania cech dla modeli w silniku Spark. To pozwoli więcej czasu poświęcić na rozwój modeli, bez czekania, aż inżynierowie danych przygotują nowy zestaw danych.
W naszej firmie pracują ludzie z wiedzą w różnych dziedzinach: Linux i DevOps, Hadoop i Spark, Java i Spring, Scala i Akka, OpenShift i Kubernetes. W następnej edycji opowiemy o bibliotece modeli, o tym, w jaki sposób modele przechodzą przez cykl życia w firmie, jak odbywa się walidacja i wdrożenie.
Źródło: habr.com
