DWH для банка: build vs buy

Вопрос «строить или купить» для DWH — один из самых дорогостоящих решений в IT-архитектуре банка. Ошибка стоит $1-5M и 2-4 года времени.

Когда покупать готовое решение

Небольшие и средние банки (до $1B активов)

Затраты на build сложно оправдать. Готовые решения (Teradata, Snowflake, Oracle DWH) дают 80% нужной функциональности без риска.

Когда нет внутренней команды данных

DWH на самописной архитектуре без команды — это технический долг. Если нет архитектора данных и 3-5 инженеров — покупайте.

Жёсткие сроки

Пилот DWH на готовом решении — 3-6 месяцев. Собственная разработка — 12-24 месяца.

Когда строить

Крупные банки с уникальными требованиями

Специфическая регуляторная отчётность, сложная интеграция с legacy-системами, требования к производительности, которые не покрывают коробочные решения.

Стратегия импортозамещения (актуально для РФ)

Переход на отечественные СУБД (Postgres Pro, ClickHouse) требует кастомной разработки.

Когда данные — ключевое конкурентное преимущество

Если аналитика и ML — core бизнеса, а не вспомогательная функция.

Гибридный подход (рекомендую чаще всего)

1. Operational DWH — готовое решение для регуляторной отчётности

2. Analytical Layer — собственная разработка на ClickHouse/BigQuery для ML

3. Data Catalog — открытый OpenMetadata/DataHub

Такой подход даёт скорость запуска + гибкость для аналитических задач.

Типичные ошибки

• Недооценка затрат на ETL (обычно 40-60% бюджета проекта)
• Выбор вендора по функциям, а не по TCO на 5 лет
• Игнорирование data governance с самого начала
• Нет ownership внутри — DWH превращается в свалку данных

Обсуждал десятки DWH-проектов. Если нужен взгляд на вашу ситуацию — напишите.