Архитектура Lakehouse

Эволюция: от хранилища к озеру и обратно

Традиционная архитектура данных прошла три поколения. Каждое решало проблемы предыдущего — и создавало новые.

Data Warehouse (поколение 1)

Data Warehouse — это структурированное хранилище с жёсткой схемой, оптимизированное для аналитических запросов. Классические примеры: Teradata, Oracle DWH, Amazon Redshift.

Преимущества: ACID-транзакции, SQL-доступ, строгая типизация, быстрые аналитические запросы.

Проблемы: дорогое проприетарное хранилище, невозможность работать с неструктурированными данными (логи, JSON, изображения), жёсткая привязка к вендору, сложная масштабируемость.

Data Lake (поколение 2)

Data Lake — дешёвое объектное хранилище (S3, GCS, ADLS) для данных любого формата. “Складываем всё, разберёмся потом.”

Преимущества: дешёвое хранилище, любые форматы данных, горизонтальная масштабируемость, открытые форматы (Parquet, ORC, Avro).

Проблемы: нет ACID-транзакций (concurrent writes ломают данные), нет контроля схемы (schema-on-read = хаос), нет time travel, “data swamp” — данные есть, но найти и использовать их невозможно.

Data Lake проблема:
Writer A:  read -> modify -> write ──┐
Writer B:  read -> modify -> write ──┘──> CONFLICT! Потеря данных
                                         Нет изоляции транзакций

Lakehouse (поколение 3)

Lakehouse = объектное хранилище (дешёвое, масштабируемое) + метаданный слой (ACID, схема, time travel). Это не новый продукт — это архитектурный паттерн, реализуемый через lakehouse-форматы: Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon.

Медальонная архитектура (Medallion Architecture)

Стандартный паттерн организации данных в Lakehouse — трёхуровневая медальонная архитектура: Bronze -> Silver -> Gold.

Bronze (сырые данные)

Bronze-слой — точная копия данных из источника. Никакой трансформации, никакой валидации. Append-only запись.

# Bronze: загрузка сырых JSON-событий
raw_events = (
    spark.readStream
    .format("kafka")
    .option("subscribe", "user_events")
    .load()
)

# Сохраняем как есть -- включая metadata Kafka
raw_events.writeStream \
    .format("delta") \
    .option("checkpointLocation", "/checkpoints/bronze") \
    .start("/data/bronze/user_events")

Гарантии Bronze: полнота данных (ничего не потеряно), возможность повторной обработки (re-processing), append-only для аудита.

Silver (валидированные данные)

Silver-слой — очищенные, типизированные, дедуплицированные данные. Здесь применяется schema enforcement и бизнес-логика очистки.

# Silver: валидация и очистка
from pyspark.sql.functions import from_json, col, sha2, concat

bronze = spark.readStream.format("delta").load("/data/bronze/user_events")

silver = (
    bronze
    .select(from_json(col("value").cast("string"), schema).alias("data"))
    .select("data.*")
    # Валидация: отбрасываем записи без user_id
    .filter(col("user_id").isNotNull())
    # Дедупликация по бизнес-ключу
    .dropDuplicates(["event_id"])
    # Типизация
    .withColumn("amount", col("amount").cast("double"))
)

silver.writeStream \
    .format("delta") \
    .option("checkpointLocation", "/checkpoints/silver") \
    .start("/data/silver/user_events")

Гарантии Silver: валидная схема, уникальные записи, корректные типы.

Gold (бизнес-агрегаты)

Gold-слой — агрегированные метрики и бизнес-таблицы, готовые для дашбордов и аналитики. Часто включает joins с dimension-таблицами.

# Gold: бизнес-агрегаты
silver = spark.read.format("delta").load("/data/silver/user_events")
customers = spark.read.format("delta").load("/data/silver/customers")

# Join + агрегация
gold_metrics = (
    silver
    .join(customers, "user_id")
    .groupBy("region", "event_type")
    .agg(
        count("*").alias("event_count"),
        sum("amount").alias("total_amount"),
        avg("amount").alias("avg_amount")
    )
)

gold_metrics.write \
    .format("delta") \
    .mode("overwrite") \
    .save("/data/gold/regional_metrics")

Гарантии Gold: бизнес-метрики, enriched data (joins с dimensions), готовые для BI-инструментов.

Что решают Lakehouse-форматы

Все четыре формата (Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon) решают одну фундаментальную проблему: ACID-транзакции поверх объектного хранилища. Но делают это по-разному:

В следующих уроках мы подробно разберём каждый формат: архитектуру, ключевые возможности, практические примеры, anti-patterns и сценарии использования.

Что дальше?

В следующем уроке мы глубоко разберём Delta Lake — самый популярный lakehouse-формат, разработанный Databricks. Вы узнаете, как работает transaction log, time travel и новые возможности Spark 4.0: UniForm и Coordinated Commits.