Как мы перестали писать SQL руками и автоматизировали Data Vault 2.0 на основе метаданных
<img src="https://habrastorage.org/getpro/habr/upload_files/969/2b7/2a6/9692b72a69b5fecba745d35d9654fcb4.png" /><p>Привет, Хабр! Меня зовут Алексей Миронов, я главный разработчик отдела разработки хранилищ данныз в «Газпром ЦПС». Сегодня я расскажу о своем опыте внедрения Data Vault в компании.</p><p>Методология Data Vault 2.0 на бумаге выглядит безупречно, особенно если ваша команда живёт по Agile. Разделение данных на Хабы, Линки и Сателлиты позволяет расширять хранилище инкрементально. Появился новый источник или изменилась бизнес-логика? Просто достраиваем новые блоки рядом, не ломая старые сущности и не переписывая половину DWH, как это часто бывает в классической архитектуре Кимбалла.</p><p>Кроме того, Data Vault даёт чёткие правила игры: стандарты генерации объектов, расчёта хэш-ключей и версионирования истории здесь прописаны до нас. Это полностью убирает «творчество» отдельных инженеров — вся команда пишет код в едином стандарте.</p><p>Но когда дело доходит до практики, начинаются сложности. Ручное проектирование однотипных таблиц быстро превращается в ад. В этой статье я расскажу, как мы наступили на все классические грабли ручного Data Vault и как написали собственный гибкий фреймворк автоматизации.</p><p><strong>Ожидания vs Реальность: с какими болями мы столкнулись</strong></p><p>К проекту мы решили подойти основательно. Подготовку начали с теории: специально купили легендарную книгу Дэна Линстеда «Building a Scalable Data Warehouse with Data Vault 2.0» в оригинале. Честно прочитали (признаюсь, местами сильно по диагонали) и, вооружившись академическими знаниями, бесстрашно ринулись в бой с реальными данными.</p><p>На бумаге всё выглядело гладко, но как только книжная теория столкнулась с продакшен-выгрузками, мы моментально упёрлись в классические проблемы роста:</p> <a href="https://habr.com/ru/articles/1079926/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1079926#habracut">Читать далее</a>