Проектирование DWH
Data Vault, Kimball и гибрид. От модели до первой вертикали в проде.
Собираю хранилище с нуля или проектирую замену тому, что уже разъехалось. Начинаю с бизнес-требований: какие отчёты нужны регулятору, какие вопросы задаёт продукт, какая freshness ожидается. Только потом иду в модель.
Выбираю методологию под задачу. Data Vault 2.0 — там, где важна auditability и данные приходят из десятков источников. Kimball — где отчётность стабильная и BI-tool критичен. Гибрид — если аудит нужен только на ядре, а mart’ы удобнее в Kimball.
Проектирую слои: raw, staging, core, mart, semantic. Пишу контракты загрузки для каждого источника. Собираю с командой первую вертикаль до отчёта, чтобы к концу второго месяца показать регулятору или бизнесу что-то работающее.
- Для кого
- Банки и финтех, где DWH только строится или переезжает с legacy Oracle / Teradata на современный стек.
- Решаем
- Отчётность собирается из десятка витрин с разной логикой. Регулятор просит происхождение данных — некому и негде показать. Новые источники подключаются два месяца вместо двух недель. Между слоями DWH проваливаются вычисления.
- Результат
- Логическая и физическая модель данных, документация архитектуры и методологии, контракты загрузки для приоритетных источников, работающая первая вертикаль до отчёта, план внедрения на 6 месяцев.
- Формат
- Удалённо. Опционально — рабочие сессии на площадке раз в 2–3 недели.
- Длительность
- 6–12 недель до первой вертикали в проде.