Продвинутый анализ данных и системы принятия решений

Тэги
технологии
Продвинутый анализ данных и системы принятия решений

Вернёмся на несколько лет назад, в 2017 год. В банке единая кредитная система и несколько разрозненных. Анализ данных ведется раздельно в каждой из них. Ежедневно приходит более 2 тыс. заявок на кредит, около 75% из них обрабатывается вручную. Решение принимается до 3 суток. Необходимо увеличивать поток клиентов, но это будет возможно только при увеличении штата сотрудников. И однажды снова наступит предельный максимум. Стало понятно, что необходима автоматизация. И не только этой, но и многих других систем. В банке началась глобальная программа цифровой трансформации

Была поставлена задача – увеличить поток заявок до 4 тыс., уменьшить участие андеррайтера в решении до 25%, сократить время принятия решения в автоматическом режиме до 15 минут.

Для начала кредитный конвейер был разделен на три системы: розничный кредитный конвейер (фронт+workflow оформления кредита), бэк-офис (обслуживание выданных кредитов), система принятия решений (далее СПР) (должна была заменить работу андеррайтеров). В качестве ядра СПР был выбран SAS Real Time Decision Manager (RTDM) + MS SQL в качестве операционной базы.

С увеличением количества систем и клиентов в банке начало расти количество данных, интересных с точки зрения клиентской аналитики. Обрабатывать данные по-отдельности было неэффективно, и было принято решение объединить данные для анализа в едином месте. Так появилась первая «инкарнация» аналитического хранилища DataLab. Она представляла из себя базу данных Oracle, в которую сливались данные из нескольких источников при помощи ETL инструмента SAS Data Integration (SAS DI). ETL включает в себя извлечение данных из внешних источников, преобразование согласно требованиям, загрузка обработанной информации.

Для принятия верных решений по заявкам потребовалось больше данных о клиентах. О нынешних клиентах банка вся информация была под рукой, но нам нужны были новые клиенты. Была внедрена система CreditRegistry – специализированное решение, которое умеет общаться с различными источниками данных и преобразовывать их ответы в единый формат для внутренних потребителей. Мы стали получать кредитные истории из Базы Кредитных Историй, скоринги операторов сотовой связи, фрод-скоринг, данные о работодателях, информацию от службы судебных приставов, Google Analytics (мы хотели понять предпочтения).

Клиентов всё больше, данные растут, способы анализа варьируются. Появилась геоаналитика (для оценки недвижимости), текстовая аналитика (для определения вида сканируемого документа и его качества), затем графовая аналитика (для построения графов связей, чтобы определять замешанность в мошеннических сделках). Были развернуты инструменты анализа данных SAS EM, SAS EG, R, Python. Таким образом, данные в Datalab и инструменты анализа позволили автоматизировать банковские процессы: расчет предодобренных предложений, сбор просроченной задолженности и т.п.

Поток заявок кредитного конвейера был уже 8 тыс. заявок в день – в 4 раза больше, чем в начале. Стали применять математические модели в процессе принятия решения по кредитной заявке. В первую очередь, вероятность того, будет ли человек своевременно отдавать кредит. По каждой заявке в Datalab готовилось до 10 математических моделей. Сформировалось два принципиально разных профиля нагрузки:

  1. принятие решений – процесс занимает 1,5 - 2 минуты (ожидаются ответы источников, работает стратегия), параллельно обрабатывается до 30 заявок на одном сервере
  2. применение моделей – процесс занимает 0,2 секунды, но вызовов в 10 раз больше

Было принято решение разделить СПР на две системы: принятие решений (СПР) и применение моделей (СПМ). Обе системы – SAS RTDM, однако настройки параметров, влияющих на производительность, уникальные для каждой. Тюнинг производительности длился около трех месяцев.

Данных стало еще больше, появились регулярные загрузки из новых источников, росло количество аналитиков. Все это привело к тому, что базы данных Oracle стало не хватать. Было принято важное решение переехать на Hadoop. Для того, чтобы сделать этот переход наиболее безболезненным для пользователей, в качестве sql-движка был выбран Impala. ETL инструмент оставили тот же, SAS DI. Это позволило увеличить объемы хранимой информации в десятки раз и производительность аналитической системы.  

В корпоративных высоконагруженных системах промышленная эксплуатация напоминает военные действия: что бы там ни происходило вокруг, боевая галера должна продолжать плыть. Каждый должен знать свое место и задачу и работать как единый слаженный механизм под шквалом звонков с передовых линий фронт-офиса. В России в ИТ жаргоне крепко укоренилось выражение «в БОЮ» или «поставить на БОЙ» - в отличие от более нейтрального английского «PRODUCTION». 

Тем временем данных становилось всё больше, а пользовательские процессы начали бороться за ресурсы с промышленными. Было принято сложное архитектурное решение сделать два кластера Hadoop, разнести их по разным центрам обработки данных (ЦОД) и каждому назначить свою роль. Так появились Lab-контур (песочница для экспериментов) и ETL-контур (место загрузки данных), между которыми происходит репликация данных из ETL-контура в LAB, что обеспечивает наличие актуальных данных даже в случае выхода из строя одного из ЦОДов. А найти решение для резервной копии петабайта данных не так-то просто!

Кроме того, для точного управления ресурсами пользователей был внедрена система контейнеризации, которая позволила изолировать рабочие среды аналитиков, и минимизировать взаимное влияние их сессий друг на друга.

Тем временем, команда становилась более зрелой, процессы жизненного цикла ПО усложнились, стало больше стендов для повышения качества: разработка (DEV), внутреннее тестирование командами банка, интеграционное тестирование, приемо-сдаточный стенд – регресс, нагрузочное тестирование, hot-fix. Релизный цикл все сокращался, доработок выводилось все больше, и время работы администраторов катастрофически росло. Командой была разработана и внедрена концепция DevOps, что отнюдь не тривиальное решение применительно к продуктам SAS. Это позволило на порядок сократить работу администраторов и уменьшить количество ошибок в настройке и установке.

После того, как разобрались с автоматизацией жизненного цикла ПО, пришло время заняться жизненным циклом моделей и автоматизацией процесса работы с ними. Было выбрано решение SAS ModelRiskManagement, внедрена не только сама «коробка», но и автоматизированы процессы вывода моделей на ПРОМ-контур (SAS и Python). Также был разработан механизм автоматического переобучения моделей. Сейчас идет оптимизация всех процессов с этим связанных. Очень важным шагом стала интеграция с системой контейнеризации для запуска Python моделей в пром-эксплуатацию.

Итого, сейчас поток заявок более 43 тыс. в сутки, 20 ТВ данных обрабатывается ежедневно, хранится более Петабайта данных, хранилище содержит более 4 тыс. объектов.

Но мы знаем, куда стремиться!


Авторы

Игорь Демидов, Начальник управления развития систем потоковой обработки данных, Газпромбанк

Елена Колесникова, Начальник управления инструментов и сервисов анализа данных, Газпромбанк

Другие статьи по теме

18 Октября, 2021

Газировка за улыбку: как биометрия меняет жизнь банковских клиентов

Что такое биометрия, как ее используют банки и что нас ждет в будущем с единой биометрической системой

Читать

7 Октября, 2021

Система быстрых платежей: как она развивается в России

История и современные тенденции первого в стране централизованного финансового сервиса.

Читать

26 Апреля, 2021

Внедрение искусственного интеллекта в банки. Как ИИ помогает сотрудникам?

Газпромбанк совместно с ЦРТ и Мегафоном провел онлайн-митап про AI и внедрение этой технологии в банки

Читать

24 Марта, 2021

Цифровые аватары в бизнесе и творчестве

Как инновационные разработки входят в нашу жизнь

Читать

10 Декабря, 2020

Работа внутренних систем ускорена в 50 раз

Газпромбанк запустил платформу на базе Tarantool Data Grid

Читать

16 Ноября, 2020

Искусственный интеллект: противостояние

Газпромбанк выходит на мировую арену и бросает вызов Bank of America!

Читать