Sber.DS е платформа која ви овозможува да креирате и имплементирате модели дури и без код

Секојдневно се појавуваат идеи и состаноци за тоа кои други процеси може да се автоматизираат во бизниси од различни големини. Но, покрај тоа што може да се потроши многу време за креирање на модел, треба да потрошите и на негова евалуација и проверка дали добиениот резултат не е случаен. По имплементацијата, секој модел мора да се следи и периодично да се проверува.

И тоа се сите фази кои треба да се завршат во секоја компанија, без разлика на нејзината големина. Ако зборуваме за обемот и наследството на Сбербанк, бројот на фино подесување значително се зголемува. До крајот на 2019 година, Сбер веќе користеше повеќе од 2000 модели. Не е доволно едноставно да се развие модел, потребно е да се интегрира со индустриски системи, да се развијат податоци за модели за градење и да се обезбеди контрола на неговата работа на кластерот.

Нашиот тим ја развива платформата Sber.DS. Ви овозможува да решавате проблеми со машинското учење, го забрзува процесот на тестирање хипотези, во принцип го поедноставува процесот на развивање и потврдување модели, а исто така го контролира резултатот од моделот во PROM.

За да не ги измамам вашите очекувања, сакам однапред да кажам дека овој пост е воведен, а под сечењето, за почеток, зборуваме за тоа што, во принцип, е под хаубата на платформата Sber.DS. Одделно ќе ја раскажеме приказната за животниот циклус на моделот од создавање до имплементација.

Sber.DS се состои од неколку компоненти, од кои клучни се библиотеката, системот за развој и системот за извршување на моделот.

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

Системот за развој е дизајниран за визуелен развој на модели и техники за валидација. Развиените модели се подложуваат на почетна валидација и се доставуваат до системот за извршување за да ги извршуваат нивните деловни функции. Исто така, во системот на траење, моделот може да се постави на монитор со цел периодично да се активираат техники за валидација за следење на неговата работа.

Постојат неколку типови на јазли во системот. Некои се дизајнирани да се поврзат со различни извори на податоци, други се дизајнирани да ги трансформираат изворните податоци и да ги збогатат (означување). Постојат многу јазли за градење различни модели и јазли за нивна валидација. Програмерот може да вчита податоци од кој било извор, да трансформира, филтрира, визуелизира средно податоци и да ги раздели на делови.

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

Ако вградените можности не се доволни, системот обезбедува можност брзо да креирате сопствени модули. Направивме интегриран режим на развој врз основа на Портата на кернелот Јупитер за оние кои создаваат нови модули од нула.

Архитектурата на Sber.DS е изградена на микросервис. Има многу мислења за тоа што се микросервиси. Некои луѓе мислат дека е доволно да се подели монолитниот код на делови, но во исто време тие сепак одат во истата база на податоци. Нашиот микросервис мора да комуницира со друг микросервис само преку REST API. Нема решенија за директен пристап до базата на податоци.

Се обидуваме да обезбедиме услугите да не станат многу големи и несмасни: еден пример не треба да троши повеќе од 4-8 гигабајти RAM меморија и мора да обезбеди можност за хоризонтално размерување на барањата со лансирање нови примероци. Секоја услуга комуницира со другите само преку REST API (Отворете API). Од тимот одговорен за услугата се бара да го одржува API-то наназад компатибилно до последниот клиент што го користи.

Јадрото на апликацијата е напишано во Java со помош на Spring Framework. Решението првично беше дизајнирано за брзо распоредување во инфраструктурата на облакот, така што апликацијата беше изградена користејќи систем за контејнеризација Red Hat OpenShift (Кубернети). Платформата постојано се развива, како во однос на зголемување на деловната функционалност (се додаваат нови конектори, AutoML) така и во однос на технолошката ефикасност.

Една од карактеристиките на нашата платформа е тоа што можеме да извршиме код развиен во визуелен интерфејс на кој било систем за извршување на моделот на Сбербанк. Сега веќе има два од нив: еден на Hadoop, другиот на OpenShift (Docker). Не застануваме тука и создаваме модули за интеграција за да го извршуваме кодот на која било инфраструктура, вклучително и во просториите и во облакот. Во однос на можностите за ефективна интеграција во екосистемот на Сбербанк, планираме и да ја поддржиме работата со постоечките средини за извршување. Во иднина, решението може флексибилно да се интегрира „надвор од кутијата“ во кој било пејзаж на која било организација.

Оние кои некогаш се обиделе да поддржат решение што работи на Python на Hadoop во PROM, знаат дека не е доволно да се подготви и испорача корисничка околина на Python до секоја податочна јазла. Огромниот број C/C++ библиотеки за машинско учење кои користат модули на Python нема да ви дозволат да бидете мирни. Мора да запомниме да ги ажурираме пакетите кога додаваме нови библиотеки или сервери, додека одржуваме компатибилност наназад со веќе имплементираниот код на моделот.

Постојат неколку пристапи за тоа како да го направите ова. На пример, однапред подгответе неколку често користени библиотеки и имплементирајте ги во PROM. Во Hadoop дистрибуцијата на Cloudera, тие обично користат парцела. Исто така сега во Hadoop е можно да се трча докер- контејнери. Во некои едноставни случаи, можно е да се достави кодот заедно со пакетот питон.јајца.

Банката многу сериозно ја сфаќа безбедноста при извршувањето на кодот од трета страна, така што максимално ги користиме новите функции на кернелот на Linux, каде што процес работи во изолирана средина Линукс именски простор, можете да го ограничите, на пример, пристапот до мрежата и локалниот диск, што значително ги намалува можностите на малициозен код. Областите на податоци на секој оддел се заштитени и достапни само за сопствениците на овие податоци. Платформата осигурува дека податоците од една област можат да стигнат до друга област само преку процес на објавување податоци со контрола во сите фази од пристап до извори до слетување на податоците во целниот излог.

Оваа година планираме да го завршиме MVP на лансирање модели напишани во Python/R/Java на Hadoop. Си поставивме амбициозна задача да научиме како да управуваме со која било прилагодена околина на Hadoop, за да не ги ограничиме корисниците на нашата платформа на кој било начин.

Покрај тоа, како што се испостави, многу специјалисти за DS се одлични во математиката и статистиката, прават кул модели, но не се многу добро упатени во трансформациите на големи податоци и им треба помош од нашите инженери за податоци за да подготват примероци за обука. Решивме да им помогнеме на нашите колеги и да создадеме погодни модули за стандардна трансформација и подготовка на карактеристики за модели на моторот Spark. Ова ќе ви овозможи да потрошите повеќе време за развој на модели и да не чекате инженерите за податоци да подготват нова база на податоци.

Вработуваме луѓе со знаење во различни области: Linux и DevOps, Hadoop и Spark, Java и Spring, Scala и Akka, OpenShift и Kubernetes. Следниот пат ќе зборуваме за библиотеката на модели, како моделот минува низ животниот циклус во компанијата, како се случува валидацијата и имплементацијата.

Извор: www.habr.com