Streaming-Lakehouse Convergence
Главный тренд 2025-2026
Десятилетие data engineering знало две раздельные дисциплины: streaming (Kafka, Flink, низкая latency, event log) и batch lakehouse (Iceberg, Spark, дешёвое хранилище, аналитика). В 2025 году эти миры схлопываются. Kafka topic и Iceberg table становятся одним и тем же объектом в S3.
Эволюция архитектур:
2010-2020 — Lambda:
Streaming layer (Kafka + Storm/Flink) для скорости
Batch layer (HDFS + MapReduce/Spark) для точности
Дублирование кода и данных. Сложность 10x.
2020-2024 — Kappa + Lakehouse раздельно:
Streaming: Kafka → Flink → ClickHouse/Pinot
Batch: Spark → Iceberg/Delta
Два пайплайна, два склада. ETL между ними.
2025-2026 — Streaming Lakehouse (convergence):
Kafka topic = Iceberg table (один объект в S3)
Один pipeline для streaming и batch
Один storage layer
Один query engine (или federation)
Stream-Table duality
Концепция родом из Kafka Streams (2017): любой topic можно интерпретировать как stream of changes или как table state. В streaming lakehouse идея переходит на физический уровень — те же байты в S3 материализуют и log, и table.
Концепция:
Stream view: INSERT events ordered by time
Table view: latest state per key (или time-versioned)
Old approach:
Events в Kafka (binary log format)
+ ETL (Connect/Flink)
+ Iceberg table (Parquet с метаданными)
→ две физические копии данных
New approach (Tableflow, Iceberg Topics, Ursa):
Один write путь:
Producer → row-based WAL (S3) → background compaction → Parquet → Iceberg metadata
Два read пути:
Kafka consumer protocol (читает WAL + recent Parquet)
Iceberg query (Spark/Trino/StarRocks читают Parquet)
Result: zero copy, zero ETL, single source of truth
Apache Paimon: Flink-native LSM lakehouse
Paimon (graduated from incubator в 2024) — первый lake format, изначально спроектированный под streaming updates. Под капотом LSM-tree (как RocksDB), но SST-файлы это Parquet, а не custom binary.
Paimon архитектура:
- LSM-tree поверх Parquet/ORC файлов
- Primary key tables с CRUD (INSERT, UPDATE, DELETE, MERGE)
- Changelog production: каждое изменение видно как INSERT/UPDATE/DELETE event
- Streaming reads: continuous tail чтение с offset
- Native integration с Flink (sink + source)
- Multi-engine reads: Spark, Trino, StarRocks, Doris, Hive
LSM поверх Parquet — почему это важно:
- Iceberg/Delta: append-only friendly, upsert через MERGE INTO (дорого)
- Paimon: upsert — primary use case, oптимизирован для CDC и streaming
- Compaction merges old levels периодически (как RocksDB)
- Snapshot isolation через manifests (как Iceberg)
Use case sweet spot:
CDC из MySQL → Paimon table (Flink CDC connector)
Streaming aggregations с обновлениями (counts, sums, latest state)
Multi-engine reads без копирования
LSM-tree fundamentals
Iceberg streaming write V3
Iceberg V3 spec (финализирован в 2025) добавляет first-class streaming primitives, которых не хватало для convergence:
Iceberg V3 streaming features:
- Variant type для semi-structured data (JSON без schema)
- Row-level deletion vectors (instead of position deletes)
- Geometry type
- Default values для schema evolution
- Improved equality deletes для upsert
Flink Dynamic Iceberg Sink (2025):
- Schema evolution на лету (новые колонки автоматически)
- Automatic table creation на основе stream schema
- Multi-table sink: один Flink job → много Iceberg tables (по routing key)
- Exactly-once через 2PC commit с Iceberg snapshots
Throughput:
- 100K-1M events/sec в Iceberg table через Flink sink
- Commit interval 30 sec - 5 min (trade-off latency vs file count)
- Background compaction чистит мелкие файлы
Tableflow: Kafka↔Iceberg duality
Confluent Tableflow (GA на Current Bengaluru ‘25) — managed сервис, который превращает Kafka topic в Iceberg table без отдельного pipeline.
Tableflow архитектура:
Producer → Kafka topic → tiered storage (S3) →
background materialization → Iceberg table (тот же S3)
Schema из Schema Registry автоматически конвертируется в Iceberg schema
Compaction и snapshot expiration автоматические
Поддержка Iceberg + Delta Lake
Что получаешь:
- Producer пишет в Kafka API (familiar)
- Analytics читает Iceberg (через Snowflake/Spark/Trino)
- Flink читает stream view с low latency
- Один storage, нет ETL
Roadmap 2026:
- Upsert support (Kafka tombstones → Iceberg deletes)
- DLQ integration
- Bidirectional flow (Iceberg → Kafka)
- Azure и GCP versions
Аналоги:
- Redpanda Iceberg Topics (2025): встроено в брокер
- StreamNative Ursa (VLDB 2025 best industry paper): первый
lakehouse-native streaming engine, Kafka API + Iceberg storage
- AutoMQ: Kafka-compatible с object storage backend, Iceberg integration
Apache Hudi 1.0 streaming
Hudi 1.0 GA (январь 2025) — major релиз с фокусом на streaming-first lakehouse.
Hudi 1.0 streaming features:
- LSM-tree timeline для long-term retention (миллиарды commits)
- Non-blocking concurrency control (NBCC):
Multiple streaming jobs пишут в одну таблицу без блокировок
- Partial column updates (для CDC: меняется одна колонка → пишем одну колонку)
- Functional indexes (первый из big-3 ACID форматов с этим)
- DeltaStreamer: continuous Kafka → Hudi pipeline из коробки
Hudi 1.1 (ноябрь 2025):
- Engine-specific optimizations (Spark/Flink/Trino)
- Improved index management
- Better schema evolution
Когда Hudi:
- Upsert-heavy workloads (CDC из OLTP)
- Очень частые commits (десятки в секунду)
- Time-travel и incremental query как critical features
- Уже в экосистеме Hudi (миграция дорогая)
Real-time OLAP shift: lakehouse-native
Отдельная revolution — OLAP engines (ClickHouse, StarRocks, Pinot, Druid) учатся читать lakehouse напрямую, без копирования.
Раньше (2020-2024):
Lakehouse (Iceberg) → ETL → ClickHouse/Pinot local storage → query
Дублирование данных. Drift между копиями.
Сейчас (2025):
Lakehouse (Iceberg) ← query напрямую ← ClickHouse/StarRocks/Pinot
Single source of truth. OLAP engine — compute layer, не storage.
Конкретные примеры:
- StarRocks 4.0: first-class Iceberg support, optimized metadata parsing,
fast joins на Iceberg tables (Coinbase, Pinterest case studies)
- ClickHouse: Iceberg/Delta/Hudi external table support, query federation
- Pinot/StarTree: первый OLAP с low-latency индексами над Parquet в S3
- Apache Doris: Iceberg/Hudi integration с predicate pushdown
Trade-off:
- Local SSD (классический OLAP): 10-50ms p99
- Lakehouse-native: 100-500ms p99 (S3 latency)
- Compromise: cache горячих partitions локально, cold с S3
ClickHouse time-series modeling
Decision matrix: какой format когда
Decision flowchart:
→ У вас primarily Flink streaming с CDC?
→ Paimon (LSM-native, Flink-first)
→ У вас multi-engine аналитика (Spark + Trino + Snowflake)?
→ Iceberg (стандарт индустрии)
→ У вас Databricks как primary platform?
→ Delta + UniForm (читается как Iceberg)
→ У вас upsert-heavy CDC из OLTP?
→ Hudi или Paimon
→ У вас существующий Hudi stack?
→ Hudi 1.0/1.1 (миграция дорогая)
Cost vs latency trade-off
Convergence не бесплатна. Streaming в lakehouse приходит с compromises:
Latency spectrum:
Pure Kafka (in-broker): 1-10 ms $$$ (broker disks)
Kafka tiered storage: 1-100 ms $$ (warm S3, hot local)
Tableflow / Iceberg Topics: 1-30 sec $ (S3 only, compaction lag)
Iceberg streaming write: 30 sec - 5 min $ (Flink commit interval)
Pure Iceberg batch: hours $ (cheapest)
ClickHouse local: 10-100 ms $$$ (SSD)
ClickHouse + Iceberg: 100-500 ms $$ (S3 + cache)
Pure Iceberg + Trino: 1-30 sec $ (no cache)
Cost driver:
Streaming latency требует hot tier (memory, SSD)
Lakehouse latency дёшев (object storage)
Convergence пытается дать обе характеристики через tiering
Где compromise приемлем. Большинство analytics запросов толерантны к 30-секундной latency: BI dashboards, daily/hourly reports, ad-hoc analytics. Real-time на низком уровне нужен только для: feature serving (ML inference), fraud detection (sub-second), operational monitoring (sub-minute), live dashboards (custom). Для остального convergence через Iceberg/Paimon побеждает по стоимости.
Anti-pattern: streaming lakehouse как замена Kafka. Если ваш use case требует sub-second consumer latency (feature serving, OLTP-like), classic Kafka ещё впереди. Tableflow и аналоги — для analytical consumers, не для request-path. Используйте обе: Kafka для hot path, lakehouse view для analytics.
Production stack reference (2025-2026)
Modern streaming lakehouse stack:
Ingest:
- Producers → Kafka API (Confluent Cloud / Redpanda / AutoMQ)
- Schema Registry (Confluent / Apicurio)
- Tableflow / Iceberg Topics для materialization
Streaming compute:
- Flink 2.0 (disaggregated state, ForSt)
- Spark Structured Streaming (transformWithState)
- State в S3 (тот же bucket, что lakehouse)
Storage:
- Iceberg (general purpose) или Paimon (streaming-first)
- S3 / GCS / Azure Blob
- Catalog: AWS Glue / Polaris / Nessie / Snowflake Open Catalog
Query:
- OLAP: ClickHouse / StarRocks / Pinot (с Iceberg federation)
- SQL ad-hoc: Trino / Snowflake / DuckDB
- Notebook: Spark / DataFusion
Governance:
- Catalog с metadata (Polaris / Unity Catalog)
- Iceberg snapshots для audit
- Data contracts (ODCS) для schema enforcement
Cost:
- Storage: $0.023/GB/мес (S3 Standard) → $0.004 (S3 IA) → $0.001 (Glacier)
- Compute: pay-per-query (Trino/Snowflake) или dedicated (Flink/Spark)
- Network: cross-AZ free, cross-region paid
Kafka tiered storage