Финансовые хранилища данных устарели?

Финансовые хранилища данных устарели! Нашему банку нужно большое хранилище! Мы ищем хранилище с современной архитектурой!

Что стоит за этими тезисами? Понимание или его отсутствие? Трезвый расчет или зомбирование недобросовестных маркетологов?

Предлагаю разобраться.

Ответьте всего на три вопроса:

1. Кто будет внутренним заказчиком ХД?
2. Какие задачи оно будет решать?
3. Какие данные для решения задач необходимы?

Если внутренний заказчик хранилища:

• финансовая служба с задачей планирования, расчета финрезультата или аллокации расходов,
• бухгалтерия с регуляторной отчетностью,
• казначейство с расчетом трансфертных цен,
• или иное подразделение банка с задачами, которые требуют структурированных данных из внутренних источников банка (АБС, CRM и проч.),

то вашему банку необходимо финансовое ХД (Data Warehouse) на базе реляционной СУБД и специализированные отраслевые приложения для него.

Если заказчик хранилища:

• розничный блок с задачей тонкого сегментирования клиентской базы,
• служба комплаенс-контроля с антифродом,
• риск-департамент с прогнозированием рисков,
• или другая служба, которой необходим доступ к неструктурированным и слабоструктурированным данным, собранным из внешних источников (торговые площадки, соцсети БД и проч.)

вашему банку нужны озеро данных (DataLake) на платформе Hadoop, статистические пакеты, нейросети и другие ML-инструменты.

Чтобы разные подразделения могли решать задачи на основе неструктурированных, слабоструктурированных и структурированных данные из внешних и внутренних источников, банку необходимо озеро-хранилище данных (LakeHouse).

Современный рынок предлагает простую формулу ответа на этот вопрос:

LakeHouse = Data Warehouse + DataLake

Выводы:

1. БОЛЬШОЕ СОВРЕМЕННОЕ ХД состоит из двух частей: Data Warehouse и DataLake.
2. Для создания Data Warehouse и DataLake пока используют разные (в смысле независимые друг от друга) технологии и инструменты.
3. Data Warehouse и DataLake могут обмениваться данными или существовать автономно, решая свой круг задач.
4. Если перед банком сегодня не стоят задачи, решение которых требует больших данных, разумно ограничиться разворачиванием финансового ХД и нужных приложений. Позднее можно реализовать вторую часть решения. И наоборот.
5. Строить БОЛЬШОЕ ХД можно и нужно по частям. Порядок разворачивания компонентов зависит от состава заказчиков, их задач и внутренних приоритетов банка.

Ну и последнее:

• Банки хотят решать на основе данных разные задачи.
• Кому-то для этого нужны большие данные, кому-то данные стандартизованного формата из учетных систем банка.
• Финансовые ХД – не устарели, а озера данных – не панацея. Каждая технология решает свои задачи. Их противопоставление – уловка недобросовестных маркетологов. Обе отлично существуют вместе и по отдельности.
• Хранилище – не та платформа, которую следует внедрять «на вырост». Подходите к его созданию рачительно, расширяя состав компонентов по мере появления новых задач.