Внутренний источник данных в банке — это любой источник информации, который находится внутри банковской организации и генерирует данные самостоятельно. Эти данные хранятся исключительно внутри банка.
Внутренние данные выделяются уникальностью, бесплатностью (сформированы внутри банка или куплены ранее), и высоким качеством, они хранятся в структурированном виде. При всем этом они могут приносить бизнесу пользу, если придумать как можно применить их в новых задачах. Подключение таких источников позволяет обогащать имеющиеся базы, улучшать качество существующих моделей машинного обучения и создавать новые.
Как их искать, зачем и куда подключать, как они могут быть полезны и какую подготовительную работу мы проводим, прежде чем подключить, расскажем в статье.
Краткая вводная
Альфа-Банк существует уже не один десяток лет, при этом успешно функционирует и активно применяет новейшие технологии для сбора и использования данных. За это время мы создали множество внутренних систем, которые позволяют нам эффективно хранить и обрабатывать информацию. К примеру, с появлением мобильного-банкинга нашим клиентам стал открыт доступ к банковским услугам в любое время и в любом месте. Это привело к значительному увеличению объема данных, которые мы можем накапливать во внутренних базах данных и хранилищах. Теперь мы можем получать информацию о действиях клиентов в приложении, их местоположении, общении с нашей службой поддержки и реакции на наши рекламные кампании. Всё это помогает нам лучше понимать наших клиентов, предлагая им персонализированные услуги.
Все это побуждает проводить регулярные исследования данных и оценку их применимости.
Для исследований нам нужна продвинутая аналитика, которая использует Большие данные (Big Data) и Машинное обучение (Machine Learning), чтобы выявлять закономерности и причины произошедших событий, и на основе них прогнозировать будущие результаты. Используя эти инструменты, Data science-специалисты (DS-ы) отвечают на самые сложные вопросы бизнеса: как увеличить доходы, снизить риски и улучшить обслуживание клиентов, что в итоге способствует устойчивому развитию и сохранению конкурентоспособности банка.
Data science-специалисты анализируют данные и разбираются в бизнес-контексте проблемы, генерируют гипотезы их решений и, как следствие, способствуют трансформации бизнеса.
Это было бы невозможно без основного ресурса — данных.
DS-ы определяют необходимый набор данных, который наиболее интересен при решении конкретного кейса. К примеру, это могут быть данные для улучшения кредитных рисковых моделей, кредитных моделей МСП (Малое и Среднее Предпринимательство), моделей склонности, моделей привлечения и прогноза и прочих моделей.
Определив потребность в данных, Data Science-специалисты приходят к нам в Управление развития источников данных с запросом на поиск и подключение нового источника данных.
Наше управление осуществляет контроль за всеми источниками, используемыми в интересах продвинутой аналитики (и не только), проводит поиск и тестирование новых данных, а также проводит организацию репликации данных из внутренних систем банка.
«Типов» данных всего два
Все источники данных по природе происхождения условно можно разделить на два «типа» — внешние и внутренние.
Внешний источник данных — источник, созданный и расположенный за рамками организации. Это может быть организация-партнер, база данных, сервис или любой другой источник, который предоставляет данные, необходимые для работы или принятия решений внутри организации. Для Банка в качестве внешнего источника может выступать Бюро кредитных историй, телеком оператор, специальные информационно-аналитические сервисы, операторы фискальных данных, гео-сервисы и многие другие.
Внутренний источник данных — это любая система банка, задействованная в бизнес-процессах, в работе которой формируются новые данные, исключительно силами самого Банка. В качестве внутреннего источника могут выступать различные системы и ресурсы, задействованные в бизнес-процессах, в работе которых формируются новые данные. Они используются для мониторинга финансовых показателей, анализа клиентской активности, оценки рисков, разработки новых продуктов и услуг, а также для принятия стратегических решений и многого другого. К таким данным могут относиться клиентские данные, информация о транзакциях и действиях клиента в приложении, на сайте или отделении Банка, финансовая отчетность, кредитные рейтинги и т. д.
Об использовании потенциала внутренних источников мы и поговорим.
В Банке есть сотни различных внутренних систем, некоторые более современные, некоторые менее современные. Лучшие инструменты Data Science могут работать исключительно с источниками определенной степени зрелости, поэтому для возможности использования систем, которые не соответствуют требованиям, необходимо организовать репликацию в Hadoop.
Платформа Hadoop зарекомендовала себя на рынке как одно из лучших и дешевых решений для сбора, хранения и обработки огромных объемов данных. Одно из её больших преимуществ это то, что Hadoop совместим с большим количеством систем, поддерживает почти все форматы хранения данных, что облегчает интеграцию данных из различных источников в единое хранилище. Он широко применяется для анализа данных, машинного обучения, обработки журналов и других задач, связанных с большими объемами данных.
Загрузка данных из различных внутренних источников, имеющих свою специфическую структуру и подходы к хранению данных в Hadoop Datalake, позволяет объединить и структурировать данные из разных источников, обеспечивая доступность данных для дальнейшего улучшения качества существующих моделей машинного обучения и создания новых.
Теперь, когда у вас есть контекст, мы расскажем, как реплицируются внутренние источники, чем они могут быть полезны для целей продвинутой аналитики и какую «подготовительную» работу мы проводим.
Мы — это Метёлкин Иван, руководитель направления развития внутренних источников данных Департамента продвинутой аналитики Альфа-Банка, и Котова Полина, старший эксперт направления развития внутренних источников данных.
«Типов» запросов всего два
На практике чаще всего мы имеем дело с двумя видами запросов от наших внутренних заказчиков:
Загрузка данных из конкретного внутреннего источника. Заказчик точно определяет систему, данные для решения задачи, таблицы и нужный набор атрибутов.
Поиск данных во внутренних ресурсах Банка, когда система-источник неизвестна, но понятны общие требования к набору данных. С учетом этого, изначально необходимо определить источник, проанализировать доступные данные и согласовать этот набор данных с заказчиком.
Рассмотрим детальнее второй вариант.
Представим, что к нам приходят DS-ы с неким запросом: «Данные нужны, но откуда их брать не знаем». С наскока задачу не решить, поэтому мы, опираясь на наш опыт, «прогоняем» заказчика по алгоритму, который состоит из пяти этапов:
Проводим интервьюирование заказчика данных и формируем бизнес-требования.
Оцениваем рентабельность подключения.
Проводим поиск источника в корпоративных системах, определяем владельца.
Анализируем атрибуты системы, подтверждаем соответствие требованиям заказчика.
Организовываем технические работы по репликации.
Пройдемся по некоторым важным этапам.
Интервью и бизнес-требования
Перед тем как приступить к работам над загрузкой данных из источника, нам необходимо провести интервьюирование заказчика. Схема интервью следующая:
Получаем запрос на поиск и загрузку данных.
Детальнее узнаем о задаче, которая стоит перед Data science-специалистом.
Уточняем логику работы модели, потенциал ее применения.
Совместно с заказчиком формируем видение конечного результата.
В процессе интервью мы задаем типовые вопросы, например:
Какая бизнес-задача решается? В каком процессе и модели будут применяться данные?
Какие данные необходимы для репликации: перечень необходимых таблиц, их количество, глубина, периодичность загрузки, наполнение таблиц и прочее?
Информация об использовании дополнительных инструментов: требуется обычная или полная репликация данных, нужна витрина, нужен парсинг, любые дополнительные требования к преобразованиям?
В какие сроки планируется разработка модели?
Понятен ли приблизительный финансовый эффект от применимости данных источника? Какова логика расчета фин. эффекта?
Но для чего мы вообще все это делаем? Давайте разберемся.
Вся полученная в ходе интервьюирования заказчика информация ложится в основу бизнес-требований к подключению. В свою очередь, точно сформулированные бизнес-требования влияют на успешность интеграции, ее сроки, качество и т.д.
Так, бизнес-требования позволяют определить основную цель при подключении данных, обосновать ее необходимость, обозначить приоритетность задачи и потенциальный финансовый эффект от ее реализации.
Оценка рентабельности подключения
Учитывая, что источников много, а размер команды и объём ресурсов ограничен, необходимо решить вопрос приоритета загрузки внутренних источников. При этом мы руководствуемся достаточно простым правилом — чем больше финансовый эффект от данных, тем быстрее их надо загружать.
Поэтому, после того как мы провели интервью и собрали все вводные об источнике, необходимо оценить финансовый эффект от его использования.
Есть 2 метода оценки.
№1. Получить у источника пробную выгрузку с обезличенными данными. Иногда на них получается построить небольшую пилотную модель, на которой можно посчитать финансовое влияние.
№2. Сделать предполагаемую оценку на основе экспертных данных (это более распространенный случай). Покажем, как это работает на примерах.
Пример 1. Есть категория клиентов, которые очень часто любят ходить в отделения и консультироваться с сотрудниками Банка. Чаще всего клиенты просят совершить простые операции, которые можно сделать самостоятельно в мобильном приложении или в мобильном банке. При этом, совершая операции самостоятельно, клиенты будут экономить собственное время и силы, а нагрузка на персонал отделений значительно снизится.
Модель выявляет таких клиентов и делает им смс-рассылку или пуш-уведомления с инструкциями о том, что многие действия можно сделать самостоятельно.
Финансовый эффект по этой задаче можно оценить так:
Мы знаем среднюю заработную плату сотрудника в отделениях и можем понять сколько стоит минута сотрудника и сколько минут необходимо для решения вопроса клиента.
Предполагаем, что после рассылки уведомлений клиентам, 10% из них перестанут ходить в отделения и научатся выполнять операции с помощью мобильного приложения.
Перемножив эти 10% клиентов на среднее время операции в отделении, получим прогнозный фин. эффект исходя из сэкономленного времени сотрудников
Такой подход позволяет в условиях неопределенности установить экспертную оценку потенциального фин. эффекта от применения данных. Полученные цифры не дают точного понимания рентабельности подключения, но их можно использовать для проведения приоритизации бэклога работ по загрузке источников.
В дальнейшем, после разработки, проведения пилота и внедрения модели в бой, сформулированная ранее оценка уточняется.
Пример 2. Для модели антифрода карточных транзакций потенциальный фин. эффект может быть оценен по следующей логике.
Если модель словила фрод и не пропустила его (определила мошеннические действия и заблокировала транзакцию), то сумма этой транзакции записывается в сохраненные деньги. Тогда годовой фин. эффект рассчитывается путем перемножения количества транзакций, средней суммы фродовой транзакции и количества месяцев в году.
Например:
Количество транзакций: 11 тыс.
Средняя сумма фродовой транзакции: 3,4 тыс.
Количество месяцев в году: 12
Фин. эффект = 11 тыс. х 3,4 тыс. х 12 ≈ 450 млн. ₽ в год.
В перспективе будет проводиться расчет ltv сохранённых клиентов (фрод не пропустили —> клиент не ушёл —> за год он сгенерировал N прибыли).
Поиск: источника, владельца, атрибутов
Иногда заказчик приходит к нам уже с точным пониманием того, какие именно данные ему нужны, в какой системе и таблицах они расположены, и что представители системы уже готовы к предстоящей интеграции.
Например, Департамент взыскания просроченной задолженности заинтересован в разработке модели, которая позволит увеличить объемы сборов. С этой задачей коллеги обращаются к Data science-специалистам, передавая всю необходимую информацию о доступных данных и их расположении. И, используя эти вводные, DS-ы, определяя для него recovery rate (RR), работают над моделью по улучшению процесса взыскания.
Но чаще всего, к нам приходят с задачами поиска необходимых данных в системах Банка для тестирования каких-либо гипотез. А это уже исследовательская задача.
После проведения интервью с заказчиком и формулирования бизнес-требований к подключению, мы приступаем к процессу поиска. Учитывая, что удобный инструмент для поиска находится в стадии разработки, а только описание всех систем Банка и их содержимого потребует больше трех лет, мы пользуемся набором из следующих инструментов:
Архитектурный комплекс документации.
Внутренние инструменты, в которых хранится описание баз данных, например, такие как Open Meta Data.
Эти инструменты также позволяют определить Владельца системы и ее представителей.
Под владельцем мы понимаем сотрудника, который инициировал создание системы или был определен в качестве несущего ответственность за корректное функционирование системы. В нашем процессе Владелец играет важную роль. К нему мы приходим с запросами и проводим ряд встреч, в ходе которых требуется понять, подходят ли данные для наших целей или нет.
Чтобы в дальнейшем перейти к интеграции нам также желательно получить пример выгрузки данных для проведения анализа атрибутного состава.
Анализ данных источника и подтверждение соответствия требованиям заказчика
Особое внимание уделяется анализу данных.
Данный этап — ключевой и его результаты позволяют принять решение о новом подключении источника данных к целевому хранилищу.
При игнорировании данного этапа работ или его некачественном выполнении есть риск потратить время и силы на источник, который в дальнейшем не будет пользоваться спросом и не принесет пользу для Продвинутой аналитики.
Мы проводим анализ информации из нового источника в 2 этапа:
Первичный.
Детальный анализ.
При проведении первичного анализа основное внимание уделяется общей структуре данных: количеству атрибутов и их бизнес смыслу историчности данных, частоте обновления данных, объёму и качеству.
Далее мы переходим к более детальной проработке источника. Совместно с заказчиком рассматриваем доступные данные на предмет их соответствия запросу. При необходимости договариваемся с источником о предоставлении пилотной выгрузки данных для построения пилотной модели на них и тестирования сформулированных гипотез.
Если данные подтверждают свою эффективность применения в моделях, мы переходим к промышленной интеграции с внутренним источником.
Анализ технической возможности подключения источника
Параллельно с анализом данных источника мы проверяем — возможно ли технически сделать с ним интеграцию в Hаdoop. Ведь система может оказаться достаточно старой или в ней вообще может отсутствовать модуль, отвечающий за передачу данных или их выгрузку. Или объем канала передачи данных может оказаться слишком узким.
Для дальнейшей интеграции также важно собрать следующую техническую информацию:
Типы серверов и сред баз данных.
Какая доступность у системы источника.
Протокол передачи данных.
Защита канала связи.
Тип аутентификации и авторизации.
и прочее.
Дополнительно, чтобы убедиться, что всё будет корректно работать, организовываем ряд рабочих встреч с техническими экспертам источника данных и Hadoop, на которых оцениваем источник по следующим параметрам:
Проверяем, совместимы ли форматы данных источника с Hadoop. Например, Hadoop может обрабатывать структурированные (SQL) и полуструктурированные данные (JSON, XML).
Выбор метода интеграции. Ещё до начала работ мы рассматриваем различные методы интеграции данных с Hadoop, и выбираем оптимальный. Например, часто используются такие инструменты как ETL (Extract, Transform, Load), использование фреймворков для обработки данных (Apache Spark) и прямой доступ к данным с использованием API.
Оценка масштабируемости и производительности. Необходимо провести оценку объёмов передаваемых данных и понять, смогут ли выдержать наши каналы связи требуемый трафик, и хватит ли нам места на дисках на ближайшие пару лет.
После анализа этих пунктов мы понимаем возможна интеграция или нет. Если возможна, нужно ли проводить какие-либо дополнительные работы на стороне источника или заказывать железо. Проводим экспресс-оценку затрат, которая также будет приниматься во внимание при принятии финального решения о интеграции.
А более подробные технические детали интеграции с Hadoop мы расскажем в следующей статье.
Вывод
В заключение можно подвести следующие итоги:
В Банке есть много внутренних источников, многие из них могут дать хорошие финансовые эффекты, но для этого нужен хороший анализ и тестирование.
Прежде чем принять решение об интеграции внутренних источников данных, мы проводим подготовку, четко определяем цели использования источника и какую выгоду Банк может получить от его использования.
Обязательно убеждаемся в том, что интеграция с Hadoop будет рентабельна, т.е. доходы от источника превысят все трудозатраты и расходы.
Не стоит недооценивать данные, которые компания генерирует самостоятельно. Именно внутренние источники хранят уникальную информацию, они способны помочь лучше понять клиента и завоевать его лояльность. А применяя к этим ресурсам методы и инструменты продвинутой аналитики, можно эффективно влиять на большинство процессов организации.