Ответ
Data Vault 2.0 — это методология моделирования данных, ориентированная на гибкость, аудируемость и параллельную загрузку. Строить её напрямую на голом HDFS (Hadoop Distributed File System) неэффективно из-за фундаментального несоответствия парадигм.
Основные причины из моего опыта проектирования DWH:
- Отсутствие управления транзакциями (ACID): HDFS изначально — это файловая система для больших данных, не поддерживающая UPDATE и DELETE на уровне записей. Data Vault же предполагает частые вставки (INSERT-ONLY) с сохранением истории, но также требует возможности помечать записи как неактивные, что сложно без поддержки транзакций.
- Проблемы с производительностью JOIN: Ключевые элементы Data Vault — Хабы (Hubs), Ссылки (Links) и Сателлиты (Satellites) — связаны между собой. Выполнение сложных JOIN между этими таблицами, хранящимися как простые файлы (например, Parquet) в HDFS, крайне ресурсоемко без специализированного движка запросов.
- Нет встроенной поддержки SQL: Нативная работа с HDFS требует использования MapReduce, Spark или Hive. Data Vault-запросы, особенно бизнес-видов (Business Vault), сложны и удобнее пишутся на SQL.
Практическая альтернатива: Мы строили Data Vault поверх Hive или, что лучше, Apache Spark SQL. Эти слои абстракции предоставляют SQL-интерфейс и более эффективное выполнение JOIN. В современных облачных стеках Data Vault эффективно реализуется в Snowflake или BigQuery, где есть встроенная поддержка временных таблиц и эффективное хранение исторических данных.
Кратко: HDFS — это хранилище, а не база данных. Data Vault требует СУБД или SQL-движка поверх него для практического использования.
