Ідеї та зустрічі про те, які ще процеси можна автоматизувати, виникають у бізнесі різного масштабу щодня. Але крім того, що багато часу може йти на створення моделі, потрібно витратити його на її оцінку та перевірку того, що отримуваний результат не є випадковим. Після впровадження будь-яку модель необхідно поставити на моніторинг та періодично перевіряти.
І це всі етапи, які потрібно пройти в будь-якій компанії, незалежно від її розміру. Якщо ми говоримо про масштаб та 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