Data Lake vs Data Warehouse

В 2018 году крупный ритейлер потратил $50M на построение Data Warehouse - и обнаружил, что ML-команда не может использовать сырые данные, потому что они уже трансформированы. А Data Science-команда накопила 40 TB в S3, которые никто не может прочитать, потому что нет схемы. Это история почти каждой крупной компании, пришедшей к выводу, что нужен третий путь.

• **Netflix** - Lakehouse на основе Apache Iceberg для рекомендаций и BI
• **Uber** - переход с Hadoop HDFS на S3 + Delta Lake, Medallion-подобная архитектура
• **Airbnb** - Data Warehouse (Hive→Druid) + Lake для ML; ввели Dataportal для governance
• **Databricks** - создатели Delta Lake и Medallion Architecture, описали паттерн в 2021

Data Lake: «складируй сейчас, думай потом»

В 2011 году аналитики Uber хотели изучить зависимость между погодой и количеством заказов. Данные о заказах лежали в PostgreSQL, данные о погоде - в CSV-файлах, логи приложения - в S3 в JSON. Никакой единой схемы. Традиционный Data Warehouse потребовал бы недели на проектирование схемы и ETL. Вместо этого всё сложили в одно место - так родилась идея **Data Lake**.

Data Lake хранит данные в **сыром виде** - любой формат (JSON, CSV, Parquet, Avro, видео, изображения), без предварительной схемы. Принцип **schema-on-read**: схема применяется в момент чтения, не записи. Физически это обычно S3 или HDFS с практически неограниченным масштабом.

• **Плюсы:** дёшево ($0.023/GB на S3), любой формат, сохраняет сырые данные навсегда - можно переобработать при изменении логики
• **Минусы:** без дисциплины превращается в «болото данных» (data swamp) - файлы без документации, дубли, устаревшие данные

**ACID-транзакций нет.** Если два процесса одновременно пишут в одну папку S3 - возможна гонка. Нет версионирования, нет rollback. Это фундаментальное ограничение классического Data Lake, которое решает Lakehouse.

Data Warehouse: порядок вместо гибкости

Netflix в 2012 году строил финансовую отчётность и аналитику продаж. Здесь нужны были точные цифры, согласованные данные, быстрые SQL-запросы. Data Lake с его «сложи и разберись потом» не подходил. Решением стал **Data Warehouse** - структурированное хранилище с заранее определённой схемой.

Data Warehouse применяет **schema-on-write**: перед загрузкой данные трансформируются через ETL-пайплайн и приводятся к жёсткой схеме (обычно Star Schema или Snowflake Schema). Результат - быстрые аналитические запросы, консистентность, простой SQL.

Основная схема организации в DWH - **Star Schema**: центральная Fact Table (метрики - продажи, клики) и окружающие Dimension Tables (описания - продукт, регион, время). Такая структура хорошо ложится на аналитические запросы с GROUP BY и JOIN.

Data Lakehouse: объединение двух миров

К 2019 году большинство компаний имели и Lake, и Warehouse - с дорогостоящей синхронизацией между ними. Данные дублировались, пайплайны ломались на стыке. Databricks предложила **Lakehouse**: хранение с ценой Data Lake + возможности Data Warehouse. Ключевое решение - **Delta Lake** (open-source формат таблиц поверх S3).

Delta Lake добавляет поверх Parquet-файлов на S3 транзакционный **transaction log** - JSON-файл с историей всех изменений. Это даёт ACID-транзакции на S3, версионирование (Time Travel), schema enforcement и schema evolution.

Конкуренты Delta Lake: **Apache Iceberg** (поддерживается Netflix, Apple; лучше SQL-engine-агностичность) и **Apache Hudi** (оптимизирован для incremental upserts - CDC из OLTP баз). Все три решают одну проблему - ACID на объектном хранилище.

Medallion Architecture: бронза, серебро, золото

Данные в Lakehouse нужно организовать. **Medallion Architecture** (паттерн Databricks, принят широко) делит хранилище на три слоя по степени обработки данных. Каждый слой строится поверх предыдущего.

Netflix использует похожую архитектуру: сырые события просмотров (Bronze) обогащаются данными о контенте и пользователях (Silver), превращаются в агрегаты для рекомендательной системы и BI (Gold). Uber называет свои слои Raw, Aggregated и Business - суть та же.

• **Bronze:** никогда не изменять источник - при ошибке в трансформации можно перезапустить Silver из Bronze
• **Silver:** идемпотентные трансформации - перезапуск не должен создавать дубли (MERGE INTO вместо INSERT)
• **Gold:** не хранить логику - только данные; бизнес-логика живёт в Silver→Gold трансформации

Data Lake, Warehouse, Lakehouse

• Data Lake: schema-on-read, любой формат, дёшево - но без дисциплины превращается в data swamp
• Data Warehouse: schema-on-write, структурированные таблицы, быстрый SQL - дорого и негибко для ML
• Lakehouse (Delta Lake/Iceberg): ACID на S3 через transaction log - объединяет дешевизну Lake и транзакционность Warehouse
• Medallion Architecture: Bronze (raw) → Silver (cleaned) → Gold (aggregated) - каждый слой перестраивается из предыдущего

Связанные темы

Data storage - фундамент для всей аналитики и обработки больших данных.

• Columnar Formats: Parquet, ORC — Форматы файлов, на которых строится Lakehouse
• Apache Spark — Основной движок обработки данных в Lakehouse

Вопросы для размышления

• В каких ситуациях стоит остановиться на классическом Data Warehouse вместо перехода на Lakehouse?
• Как принцип идемпотентности трансформаций в Silver-слое защищает от ошибок при повторных запусках?
• Чем архитектурно отличается Apache Iceberg от Delta Lake при одинаковом результирующем поведении?

Связанные уроки

• db-05-sql-basics