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

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

И това са всички етапи, които трябва да бъдат изпълнени във всяка компания, независимо от нейния размер. Ако говорим за мащаба и наследството на Сбербанк, броят на фините настройки се увеличава значително. До края на 2019 г. Sber вече е използвал повече от 2000 модела. Не е достатъчно просто да се разработи модел; необходимо е да се интегрира с индустриални системи, да се разработят витрини за данни за изграждане на модели и да се осигури контрол върху работата му в клъстера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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