Ответ
Я придерживаюсь гибридного подхода, сочетающего принципы Data Lake и классического DWH, что часто называют архитектурой «озеро-хранилище» (Lakehouse).
1. Многослойная архитектура (Medallion Architecture):
s3://company-data-lake/
├── bronze/ (raw) # Сырые данные, зеркало источников. Формат: Parquet/JSON.
│ ├── kafka_orders/
│ └── postgres_snapshot/
├── silver/ (cleansed) # Очищенные, приведенные к типу, дедуплицированные данные.
│ ├── orders/ # Единая таблица заказов из всех источников.
│ └── customers/
└── gold/ (curated) # Бизнес-сущности, агрегаты, готовые для анализа.
├── marts/ # Data Marts (финансы, маркетинг, продажи).
│ ├── finance_daily_metrics/
│ └── customer_360/
└── dw/ # Core DWH в звездообразной схеме.
├── fact_sales/
└── dim_product/2. Ключевые принципы реализации:
- Идемпотентность: Все ETL/ELT-процессы пишутся так, чтобы повторный запуск давал идентичный результат. Использую
MERGEили полную перезапись партиций. - Схема на чтении (Schema-on-Read) в Bronze, схема на записи (Schema-on-Write) в Silver/Gold: В bronze сохраняю всё как есть. В silver применяю строгую схему (например, через Delta Lake или Apache Iceberg), что обеспечивает качество данных.
- Партиционирование и кластеризация: Данные в silver/gold партиционирую по дате (
dt=YYYY-MM-DD) и часто кластеризую по ключевым полям для запросов (например,customer_id). - Управление метаданными: Использую Data Catalog (AWS Glue, Hive Metastore) совместно с возможностями форматов Delta/Iceberg для управления версиями схемы, историей изменений и lineage.
- Разделение Compute и Storage: Хранилище (S3/HDFS) отделено от вычислительных движков (Spark, Trino, Redshift Spectrum). Это позволяет разным командам использовать одни данные через разные инструменты.
3. Инструменты: Для трансформаций (слои silver/gold) чаще всего использовал Apache Spark с фреймворком Delta Lake. Для витрин, требующих низкой задержки, — материализованные представления в ClickHouse или подмножество данных в PostgreSQL.