Ідэі і сустрэчы аб тым, якія яшчэ працэсы можна аўтаматызаваць, узнікаюць у бізнэсе рознага маштабу штодня. Але апроч таго, што шмат часу можа сыходзіць на стварэнне мадэлі, трэба выдаткаваць яго на яе адзнаку і праверку таго, што атрымоўваны вынік не з'яўляецца выпадковым. Пасля ўкаранення любую мадэль неабходна паставіць на маніторынг і перыядычна правяраць.
І гэта ўсе этапы, якія неабходна прайсці ў любой кампаніі, не залежна ад яе памеру. Калі мы гаворым аб маштабе і legacy Ашчадбанка, колькасць тонкіх налад узрастае ў разы. Да канца 2019 года ў Сберы выкарыстоўвалася ўжо больш за 2000 мадэляў. Нядосыць проста распрацаваць мадэль, неабходна інтэгравацца з прамысловымі сістэмамі, распрацаваць вітрыны дадзеных для пабудовы мадэляў, забяспечыць кантроль яе працы на кластары.
Наша каманда распрацоўвае платформу Sber.DS. Яна дазваляе рашаць задачы машыннага навучання, паскарае працэс праверкі гіпотэз, у прынцыпе спрашчае працэс распрацоўкі і валідацыі мадэляў, а таксама кантралюе вынік працы мадэлі ў ПРАМ.
Каб не падмануць вашых чаканняў, хачу загадзя сказаць, што гэты пост – уступны, і пад катам для пачатку расказана аб тым, што ў прынцыпе пад капотам платформы Sber.DS. Гісторыю аб жыццёвым цыкле мадэлі ад стварэння да ўкаранення мы раскажам асобна.
Sber.DS складаецца з некалькіх кампанентаў, ключавымі з якіх з'яўляюцца бібліятэка, сістэма распрацоўкі і сістэма выканання мадэляў.
Бібліятэка кантралюе жыццёвы цыкл мадэлі з моманту з'яўлення ідэі яе распрацаваць да ўкаранення ў ПРАМ, пастаноўкі на маніторынг і вываду з эксплуатацыі. Многія магчымасці бібліятэкі прадыктаваны правіламі рэгулятара, напрыклад, справаздачнасць і захоўванне навучальных і валідацыйных выбарак. Па факце гэта рэестр усіх нашых мадэляў.
Сістэма распрацоўкі прызначаная для візуальнай распрацоўкі мадэляў і валідацыйных методык. Распрацаваныя мадэлі праходзяць першасную валідацыю і пастаўляюцца ў сістэму выканання для выканання сваіх бізнэс функцый. Таксама ў сістэме выканання мадэль можа быць пастаўлена на манітор з мэтай перыядычнага запуску валідацыйных методык для кантролю яе працы.
У сістэме ёсць некалькі тыпаў вузлоў. Адны прызначаны для падлучэння да розных крыніц дадзеных, іншыя - для трансфармацыі зыходных дадзеных і іх узбагачэння (разметкі). Ёсць мноства вузлоў для пабудовы розных мадэляў і вузлоў для іх валідацыі. Распрацоўнік можа загружаць дадзеныя з любых крыніц, пераўтвараць, фільтраваць, візуалізаваць прамежкавыя дадзеныя, разбіваць іх на часткі.
Таксама платформа змяшчае ўжо гатовыя модулі, якія можна перацягваць на праектную вобласць. Усе дзеянні вырабляюцца з выкарыстаннем візуалізаванага інтэрфейсу. Фактычна можна вырашыць задачу без адзінага радка кода.
Калі ўбудаваных магчымасцяў не хапае, то сістэма дае магчымасць для хуткага стварэння сваіх уласных модуляў. Мы зрабілі рэжым інтэграванай распрацоўкі на аснове для тых, хто стварае новыя модулі "з нуля".
Архітэктура Sber.DS пабудавана на мікрасэрвісах. Ёсць шмат меркаванняў аб тым, што такое мікрасэрвісы. Некаторыя лічаць, што дастаткова падзяліць маналітны код на часткі, але пры гэтым яны ўсё роўна ходзяць у адну і тую ж базу дадзеных. У нас мікрасэрвіс павінен мець зносіны з іншым мікрасэрвісам толькі па REST API. Ніякіх абыходных шляхоў доступу да базы даных напрамую.
Мы стараемся, каб сэрвісы не станавіліся вельмі вялікімі і непаваротлівымі: адзін асобнік не павінен спажываць больш за 4-8 гігабайт аператыўнай памяці і абавязаны забяспечваць магчымасць гарызантальнага маштабавання запытаў запускам новых экзэмпляраў. Кожны сэрвіс мае зносіны з іншымі толькі па REST API (). Каманда, адказная за сэрвіс, павінна захоўваць зваротную сумяшчальнасць API да апошняга кліента, які ім карыстаецца.
Ядро прыкладання напісана на Java з выкарыстаннем Spring Framework. Рашэнне першапачаткова праектавалася для хуткага разгортвання ў хмарнай інфраструктуры, таму прыкладанне пабудавана з выкарыстаннем сістэмы кантэйнерызацыі (). Платформа пастаянна развіваецца, як у частцы нарошчвання бізнес функцыяналу (дадаюцца новыя канектары, AutoML), так і ў частцы тэхналагічнай эфектыўнасці.
Адна з "фішак" нашай платформы складаецца ў тым, што мы можам запускаць код, распрацаваны ў візуальным інтэрфейсе, на любой сістэме выканання мадэляў Ашчадбанка. Цяпер іх ужо дзве: адна на Hadoop, іншая – на OpenShift (Docker). Мы на гэтым не спыняемся і ствараем інтэграцыйныя модулі для запуску кода на любой інфраструктуры, у тым ліку on-premise і ў воблаку. У частцы магчымасцяў эфектыўнага ўбудавання ў экасістэму Ашчадбанка, мы таксама плануем падтрымаць працу з наяўнымі асяроддзямі выканання. У даляглядзе рашэнне можа быць гнутка ўбудавана са скрынкі у любы ландшафт любой арганізацыі.
Тыя, хто калі-небудзь спрабаваў падтрымліваць рашэнне, якое запускае Python на Hadoop у ПРАМ, ведаюць, што мала падрыхтаваць і даставіць карыстацкі environment пітона на кожную датаноду. Вялікая колькасць C/C++ бібліятэк для машыннага навучання, якія выкарыстоўваюць Python модулі, не дазволяць вам адпачываць спакойна. Трэба не забываць абнаўляць пакеты пры даданні новых бібліятэк ці сервераў, захоўваючы зваротную сумяшчальнасць з ужо ўкаранёным кодам мадэляў.
Ёсць некалькі падыходаў да таго, як гэта рабіць. Напрыклад, загадзя падрыхтаваць некалькі часта выкарыстоўваных бібліятэк і ўкараніць іх у ПРАМ. У дыстрыбутыве Hadoop ад Cloudera для гэтага звычайна выкарыстоўваюць . Таксама зараз у Hadoop з'яўляецца магчымасць запуску -кантэйнераў. У некаторых простых выпадках можна даставіць код разам з пакетам. .
Банк вельмі сур'ёзна падыходзіць да бяспекі запуску іншага кода, таму мы па максімуме выкарыстоўваем новыя магчымасці ядра Linux, дзе працэсу, запушчанаму ў ізаляцыйным асяроддзі , можна абмежаваць, напрыклад, доступ да сеткі і лакальнай кружэлцы, што значна змяншае магчымасці шкоднаснага кода. Галіне дадзеных кожнага дэпартамента абаронены і даступныя толькі ўладальнікам гэтых дадзеных. Платформа гарантуе, што дадзеныя з адной вобласці могуць патрапіць у іншую вобласць, толькі праз працэс публікацыі дадзеных з кантролем на ўсіх этапах ад доступу да крыніц да прызямлення дадзеных у мэтавую вітрыну.
У гэтым годзе мы плануем завяршыць MVP запуску мадэляў, напісаных на Python/R/Java на Hadoop. Мы паставілі для сябе амбіцыйную задачу навучыцца запускаць любы карыстацкі environment на Hadoop, каб ні ў чым не абмяжоўваць карыстальнікаў нашай платформы.
Акрамя таго, як аказалася, многія DS-спецыялісты выдатна ведаюць матэматыку і статыстыку, робяць класныя мадэлі, але не вельмі добра разбіраюцца ў трансфармацыях вялікіх дадзеных, і ім патрабуецца дапамога нашых data-інжынераў для падрыхтоўкі навучальных выбарак. Мы вырашылі дапамагчы калегам і стварыць зручныя модулі для тыпавой трансфармацыі і падрыхтоўкі фіч для мадэляў на Spark-рухавічку. Гэта дазволіць больш чакай надаваць распрацоўцы мадэляў і не чакаць, пакуль дата-інжынеры падрыхтуюць новы dataset.
У нас працуюць людзі з ведамі ў розных галінах: Linux і DevOps, Hadoop і Spark, Java і Spring, Scala і Akka, OpenShift і Kubernetes. У наступным разе мы раскажам пра бібліятэку мадэляў, пра тое, як мадэль праходзіць па жыццёвым цыкле ўнутры кампаніі, як адбываецца валідацыя і ўкараненне.
Крыніца: habr.com