Sber.DS — платформа, която позволява създаването и внедряването на модели дори без код

Идеите и срещите относно това какви допълнителни процеси могат да се автоматизират, възникват ежедневно в бизнеси с различен мащаб. Но освен времето, необходимо за създаването на модел, трябва да се отдели време и за оценката му и проверката дали полученият резултат не е случайност. След внедряването, всяка модел трябва да бъде подложен на мониторинг и периодично проверяван.

Тези са етапите, които всяка компания, независимо от размера си, трябва да премине. Когато става въпрос за мащаба и наследството на Сбербанк, броят на фини настройки нараства значително. Към края на 2019 година в Сбер вече са използвани над 2000 модела. Не е достатъчно просто да разработиш модел, необходимо е да се интегрираш с промишлените системи, да разработиш витрини на данни за построяване на модели и да осигуриш контрол на работата му в клъстери.

Нашият екип разработва платформата Sber.DS. Тя позволява решаване на задачи свързани с машинно обучение, ускорява процеса на проверка на хипотези, в общи линии опростява процеса на разработка и валидиране на модели, както и контролира резултатите от работата на моделите в ПРОМ.

За да не разочаровам вашите очаквания, искам предварително да кажа, че този пост е въведен и под рубриката за начало ще разкажа какво всъщност е под капака на платформата Sber.DS. Историята за жизнения цикъл на модела от създаването до внедряването ще бъде разказана отделно.

Sber.DS се състои от няколко компонента, основните от които са библиотека, система за разработка и система за изпълнение на модели.

Библиотеката контролира жизнения цикъл на модела от момента на появата на идеята за разработка до внедряването в ПРОМ, мониторинг и извеждане от експлоатация. Много от възможностите на библиотеката са продиктувани от правилата на регулатора, например отчетност и съхранение на обучителни и валидиращи проби. По същество, това е регистър на всичките ни модели.

Системата за разработка е предназначена за визуална разработка на модели и валидиращи методики. Разработените модели преминават първоначална валидизация и се предават на системата за изпълнение, за да извършват своите бизнес функции. Също така в системата за изпълнение, моделът може да бъде настроен на монитор с цел периодично стартиране на валидиращи методики за контрол на неговата работа.

В системата има няколко типа възли. Някои са предназначени за свързване с различни източници на данни, а други — за трансформиранеи на изходните данни и тяхното обогатяване (маркиране). Има множество възли за изграждане на различни модели и възли за тяхната валидация. Разработчикът може да зарежда данни от всякакви източници, да преобразува, филтрира, визуализира междинни данни и да ги разделя на части.

Платформата съдържа и готови модули, които могат да се плъзгат и пускат в проектното пространство. Всички действия се извършват с помощта на визуализиран интерфейс. Всъщност задачата може да бъде решена без един ред код.

Ако вградените възможности не са достатъчни, системата предоставя възможност за бързо създаване на собствени модули. Направихме режим на интегрирано разработване на базата на Jupyter Kernel Gateway за тези, които създават нови модули "от нулата".

Архитектурата на Sber.DS е изградена на микросервизи. Има много мнения за това какво представляват микросервисите. Някои смятат, че е достатъчно да се раздели монолитния код на части, но те все пак използват една и съща база данни. При нас микросервизът трябва да комуникира с друг микросервиз само през REST API. Никакви заобиколни пътища за достъп до базата данни директно.

Стремим се услугите да не стават много големи и тромави: един экземпляр не трябва да консумира повече от 4-8 гигабайта оперативна памет и е задължително да осигурява възможност за хоризонтално мащабиране на заявките чрез стартиране на нови экземпляри. Всеки сервис комуникира с другите само през REST API (Open API). Екипът, отговорен за услугата, е задължен да запазва обратно съвместимостта на API до последния клиент, който я използва.

Ядрото на приложението е написано на Java, използвайки Spring Framework. Решението първоначално е проектирано за бързо разгръщане в облачна инфраструктура, затова приложението е изградено с използване на система за контейнеризация Red Hat OpenShift (Kubernetes). Платформата постоянно се развива, както в аспектите на разширяване на бизнес функционалността (нови конектори, AutoML), така и в посока на технологичната ефективност.

Една от „функциите“ на нашата платформа е, че можем да стартираме код, разработен в визуален интерфейс, на всяка система за изпълнение на модели на Сбербанк. В момента те са две: една на Hadoop, а другата — на OpenShift (Docker). Не спираме дотук и създаваме интеграционни модули за стартиране на код на всяка инфраструктура, включително on-premise и в облак. Що се отнася до възможностите за ефективно интегриране в екосистемата на Сбербанк, планираме също да поддържаме работа с наличните среди за изпълнение. В дългосрочен план решението може гъвкаво да се вгражда

Тези, които някога са се опитвали да поддържат решение, което стартира Python на Hadoop в ПРОМ, знаят, че не е достатъчно да подготвите и доставите потребителска среда на Python на всяка дата нода. Огромно количество C/C++ библиотеки за машинно обучение, които използват Python модули, няма да ви позволят да почивате спокойно. Трябва да не забравяте да обновявате пакетите при добавяне на нови библиотеки или сървъри, запазвайки обратно съвместимост с вече внедрените кодове на моделите.

Има няколко подхода за това как да го направите. Например, предварително да подготвите няколко често използвани библиотеки и да ги внедрите в ПРОМ. В дистрибуцията на Hadoop от Cloudera се използва обикновено parcel. Освен това в Hadoop сега се появява възможност за стартиране на docker-контейнери. В някои прости случаи можете да доставите кода заедно с пакета python.eggs.

Банката подхожда много сериозно към сигурността на стартирането на външен код, затова максимално използваме новите възможности на ядрото на Linux, където процесът, стартиран в изолирана среда Linux namespace, може да бъде ограничен, например, в достъпа до мрежата и локалния диск, което значително намалява възможностите на злонамерен код. Областите с данни на всеки отдел са защитени и достъпни само за собствениците на тези данни. Платформата гарантира, че данните от една област могат да преминат в друга област само през процес на публикуване на данни с контрол на всички етапи от достъпа до източниците до приземяването на данните в целевия витрина.

Тази година планираме да завършим MVP за стартиране на модели, написани на Python/R/Java в Hadoop. Поставили сме си амбициозна задача да научим как да стартираме всяка потребителска среда в Hadoop, за да не ограничаваме нашите платформи потребители по никакъв начин.

Освен това, както се оказа, много специалисти по данни отлично разбират математиката и статистиката, създават страхотни модели, но не разбират много добре трансформациите на големи данни и се нуждаят от помощ от нашите инженери по данни за подготовка на обучителни набори. Решихме да помогнем на колегите и да създадем удобни модули за стандартна трансформация и подготовка на функции за модели в Spark. Това ще ни позволи да отделим повече време за разработка на модели и да не чакаме инженерите по данни да подготвят нов набор от данни.

При нас работят хора с познания в различни области: Linux и DevOps, Hadoop и Spark, Java и Spring, Scala и Akka, OpenShift и Kubernetes. В следващия път ще разкажем за библиотеката с модели, как моделът преминава през жизнения цикъл в компанията, как се случва валидация и внедряване.

Източник: habr.com