Проекты хранилища данных (DWH) в банках — одни из самых критичных корпоративных инвестиций: регуляторные отчёты, расчёты рисков, customer 360 и аналитика эффективности — всё питается с этого слоя. Однако большинство провалов связано не с выбором технологии, а с нехваткой архитектурной дисциплины. Пять ключевых решений из практики крупных банковских DWH-проектов.
1. Интеграция источников: batch или CDC?
Классическая ночная загрузка из core-banking в DWH до сих пор распространена. Но когда регулятор требует отчётности чаще раза в сутки (BDDK делает это для ряда отчётов), CDC (Change Data Capture) становится обязательной. Решения на Debezium/Kafka передают изменения без нагрузки на core.
2. Историческая модель: SCD Type 2 — не везде
Slowly Changing Dimension Type 2 (сохранение истории) нужен не каждому измерению. Для адреса клиента Type 2 обязателен; для категории продукта достаточно Type 1 (перезапись). Массовое применение Type 2 раздувает хранилище в 3-4 раза и бьёт по производительности запросов. По каждому измерению решение принимается исходя из бизнес-потребности.
3. Разделение регуляторного и аналитического слоя
Для отчётов BDDK, TCMB, MASAK данные должны быть неизменяемыми: через год отчёт с теми же параметрами должен воспроизводиться один в один. Поэтому регуляторный слой изолируется от аналитического. Наш рекомендуемый шаблон — хранить регуляторную snapshot-версию фактов рядом с текущей аналитической.
4. Производительность: partitioning и clustered columnstore
На DWH на базе SQL Server и Azure Synapse партиционирование по дате + clustered columnstore сокращают время запроса до 90%, особенно на фактах с 50M+ записей. Если эту конфигурацию не заложить с самого начала, её добавление потом требует тяжёлых перезагрузок и downtime.
5. Доступ и разрешения: RLS плюс маскирование
Такие чувствительные данные, как ИНН клиента и остатки по счетам, должны жить в DWH — но не всем разработчикам и аналитикам их видно. Для соответствия KVKK нужны одновременно row-level security (руководитель филиала видит только клиентов своего филиала) и column-level masking (аналитик видит ИНН в виде хэша).
