Почему Data Vault не стоит строить на HDFS?

Data Vault на HDFS: почему это не лучшее решение

Data Vault — это методология моделирования данных, разработанная Дэном Линстедом для обеспечения гибкости, масштабируемости и аудита в хранилищах данных. HDFS (Hadoop Distributed File System) — это распределённая файловая система, предназначенная для хранения больших объёмов данных с высокой отказоустойчивостью. Однако их сочетание не является оптимальным решением.

Причина 1: Отсутствие прямого обновления данных

Data Vault требует частых обновлений в таблицах (изменение статусов, обновление ссылок). HDFS работает по принципу WORM (Write Once Read Many) — данные один раз записываются и многократно читаются. Обновление в HDFS означает переписать весь файл, что невероятно дорого:

# В SQL-базе (например, PostgreSQL)
UPDATE hub_customer SET dw_status = 'ACTIVE' WHERE customer_id = 123;

# На HDFS требуется полная переработка файла
# 1. Прочитать весь файл
# 2. Изменить строку
# 3. Переписать весь файл обратно
# Это работает часами для больших датасетов

Причина 2: Необходимость транзакций и ACID

Data Vault полагается на ACID гарантии для обеспечения целостности данных. HDFS не обеспечивает полных ACID свойств. При одновременных записях могут возникнуть проблемы:

-- Нужны гарантии
BEGIN TRANSACTION;
  INSERT INTO link_customer_order (customer_id, order_id, dw_load_date) VALUES (1, 100, NOW());
  UPDATE hub_customer SET dw_status_id = 1 WHERE customer_id = 1;
COMMIT;

-- HDFS не может гарантировать, что обе операции выполнятся или обе откатятся

Причина 3: Высокие задержки при SELECT операциях

Data Vault использует много JOINов между Hub, Link и Satellite таблицами. MapReduce (традиционный способ работы с HDFS) медленнее при множественных соединениях:

-- Типичный запрос Data Vault
SELECT 
    h.customer_id,
    s_customer.customer_name,
    l.order_id,
    s_order.order_date
FROM hub_customer h
JOIN link_customer_order l ON h.customer_id = l.customer_id
JOIN satellite_customer s_customer ON h.customer_id = s_customer.customer_id
JOIN satellite_order s_order ON l.order_id = s_order.order_id
WHERE h.dw_load_date >= '2024-01-01';

-- MapReduce обработает это медленнее, чем MPP БД (Vertica, Redshift)

Причина 4: Сложность управления версионированием

Data Vault требует отслеживания версий данных (dw_load_date, dw_end_date). На HDFS это создаёт огромное количество маленьких файлов, что приводит к проблемам:

• NameNode переполняется из-за обилия inodes
• Операции замедляются при работе с миллионами маленьких файлов
• Сложность восстановления данных при необходимости

Причина 5: Отсутствие встроенного управления индексами

Data Vault выигрывает от индексов для быстрого поиска по customer_id, order_id и т.д. HDFS не поддерживает индексы в традиционном смысле:

-- В SQL базе создаём индекс
CREATE INDEX idx_hub_customer_id ON hub_customer(customer_id);

-- На HDFS нужно использовать доп. слои (HBase, Druid)
-- Это усложняет архитектуру

Рекомендуемые альтернативы

Для Data Vault оптимальны:

1. Реляционные БД: PostgreSQL, Oracle, SQL Server

   • Полная поддержка ACID
   • Быстрые UPDATE операции
   • Встроены индексы

2. MPP базы данных: Redshift, Snowflake, BigQuery

   • Высокая производительность SELECT
   • Масштабируемость
   • Простота сложных JOIN операций

3. Гибридный подход: HDFS для Raw Data, Data Vault на SQL БД

   • Raw зоне хранятся оригинальные данные на HDFS
   • Data Vault строится на быстрой SQL БД

# Типичный pipeline
# Stage 1: Сырые данные -> HDFS (дешево)
df = spark.read.csv('s3://raw-data/customers.csv')
df.write.mode('overwrite').parquet('hdfs://raw/customers')

# Stage 2: Трансформация и загрузка в DV -> Redshift
df_processed = spark.read.parquet('hdfs://raw/customers')
df_processed.write.format('jdbc').option('url', 'redshift-url').save()

Вывод

Data Vault на HDFS неэффективен из-за отсутствия обновлений, слабой поддержки ACID, больших задержек при JOIN операциях и сложности управления версионированием. Правильнее использовать SQL или MPP базы для Data Vault и оставить HDFS для хранения сырых данных.