Команди даних часто починають із простих batch-процесів, а згодом змушені нашвидкуруч додавати стрімінг, коли бізнесу раптом потрібні «реальні» реальні часи. На каналі Confluent Developer пояснюють, як із цього еволюціонують три ключові архітектури — Lambda, Kappa та Data Streaming Platform — і чому варто прагнути до уніфікації, а не до нарощування латок.
Базова модель: «джерело → трансформація → сховище»
Щоб порівнювати архітектури, зручно звести будь-який пайплайн до простої схеми:
- Джерела (sources) — звідки надходять дані: бази даних, Kafka-топіки, логи, зовнішні системи.
- Трансформації (transform) — бізнес-логіка: фільтрація, агрегація, дедуплікація, збагачення тощо.
- Сховища (sinks) — куди потрапляють оброблені дані: data lake, аналітичні вітрини, дашборди, інші топіки для downstream-сервісів.
Ця модель не робить різниці між batch і streaming: у будь-якому випадку ми маємо спрямований граф із джерелами, обчисленнями та приймачами. Відмінність — лише в тому, чи дані приходять порціями, чи безперервним потоком.
Lambda: коли до batch «прикручують» стрімінг
Типовий стартовий сценарій:
- Batch-пайплайн
- Джерела даних.
- Трансформації у Spark, Snowflake чи іншому batch-рушії.
- Один або кілька sinks (сховище, BI-дашборди).
- Оркестратор (Airflow, Dagster, Argo Workflows), який вирішує, коли запускати які джоби.
Поки все обмежується звітами раз на день/тиждень — система працює, бізнес задоволений.
-
Запит на real-time
Коли з’являється вимога до дашбордів у реальному часі, повністю переробляти архітектуру зазвичай ніхто не готовий. Команди обирають «прагматичний» шлях — додати другий пайплайн: -
Піднімається Kafka-топік.
- Додаються стрімінгові джоби (Apache Flink, Spark Streaming, кастомні сервіси).
- Дані безперервно течуть у real-time-сервіси та дашборди.
- З’являється serving layer, який поєднує історичні batch-дані з «швидким» шаром.
Так народжується Lambda-архітектура:
– Batch-шар — довгострокова історія.
– Speed-шар — реальні часи та дельти.
Операційна ціна Lambda
Lambda працює й використовується великими компаніями, але має суттєвий мінус — подвоєння всього:
- Два пайплайни.
- Дві технологічні стеки (Spark/Snowflake vs Flink/кастомні стріми).
- Часто — дві команди (big data vs streaming).
- Бізнес-логіка дублюється: один раз у batch, другий — у стрімінгу.
Як наслідок, типова ситуація: показники в real-time-дашборді не збігаються з тижневим звітом. Щоб з’ясувати причину, доводиться:
- Перевіряти обидва пайплайни.
- Зважати на різні семантики виконання, помилки та edge cases у кожному рушії.
- Вручну «зводити» дані до консистентного стану.
Формула «eventual consistency» у Lambda на практиці часто означає «неконсистентно, доки хтось не виправить руками».
Kappa: «batch — це просто обмежений стрім»
Альтернатива Lambda спирається на просту ідею: batch — це окремий випадок стрімінгу.
- Необмежений стрім (unbounded): є початок, немає кінця — класичний потік подій.
- Обмежений стрім (bounded): є початок і кінець — по суті, batch.
Якщо обчислювальний рушій уміє працювати і з bounded, і з unbounded потоками, немає потреби розділяти batch і streaming. Можна використовувати один рушій для всього.
Як виглядає Kappa-архітектура
У Kappa все розглядається як стрім:
- Бази даних підключаються через CDC-конектори (наприклад, Debezium).
- Логи збираються агентами.
- Зовнішні системи — через власні конектори.
- Усе це потрапляє в єдиний стрім у брокері на кшталт Apache Kafka.
Далі:
- Один стрімінговий рушій (наприклад, Flink) виконує всі трансформації.
- Результати відправляються:
- у downstream-сервіси та інші стрімінгові клієнти;
- у lakehouse у вигляді таблиць у відкритих форматах (Iceberg, Delta Lake тощо).
Ключові наслідки:
- Один кодовий базис.
- Один технологічний стек і, відповідно, одна команда компетенцій.
- Уся бізнес-логіка в одному місці — єдине джерело правди для правил обробки.
Це різко зменшує як архітектурну, так і операційну складність.
Типові заперечення проти Kappa — і як їх знімають
-
«Не можемо тримати терабайти в брокері»
Раніше це було серйозним обмеженням: дані зберігалися на локальних дисках брокерів.
З появою tiered storage (наприклад, у Kafka через KIP-405, реалізований у 2023 році) довгострокове зберігання можна винести в дешеве object storage, а брокер тримає лише «гарячі» дані. -
«Як аналітикам запитувати дані в стрімі?»
Сучасні рушії (Flink SQL, Spark Structured Streaming) дозволяють писати SQL-запити безпосередньо до стрімів, у тому числі з ноутбуків. Аналітикам не обов’язково писати код — вони працюють із потоками як із таблицями. -
«Ми хочемо використовувати Snowflake/Trino/улюблений BI-інструмент»
Багато аналітичних систем не вміють нативно читати Kafka. Повний реплей стріму для отримання потрібного зрізу може бути повільним.
Це підводить до наступного кроку еволюції — Data Streaming Platform, яка поєднує стрімінг і табличне подання даних.
Data Streaming Platform: уніфікований стрім плюс таблиці
Практична реалізація Kappa-ідей у вигляді платформи спирається на дві концепції: shift left та матеріалізація стріму в таблиці.
Shift left: якість, схеми й контракти — якнайближче до джерела
У типовій стрімінговій системі багато клієнтів читають один і той самий стрім і виконують схожі трансформації. Класичний приклад — дедуплікація:
- Кожен сервіс окремо видаляє дублікати.
- Обчислювальні витрати дублюються.
- Логіка розмазана по багатьох місцях.
Підхід shift left пропонує:
- Перенести дедуплікацію (і будь-які інші базові трансформації) максимально вгору за течією — ближче до джерела.
- Виконати її один раз і вже потім роздавати всім клієнтам очищений, уніфікований стрім.
Це стосується не лише обчислень:
- Керування схемами.
- Data governance.
- Data contracts між продюсерами та консюмерами.
Усе це зсувається «вліво», у стрім. У результаті:
- Дані очищуються й нормалізуються до того, як потрапити в будь-яке сховище.
- Клієнти отримують куровані набори даних, які легко знаходити й споживати.
Стрім як таблиця: Apache Iceberg, Delta Lake, TableFlow
Другий крок — зробити стрім доступним як таблицю:
- Потік синкується в відкритий табличний формат (Apache Iceberg, Delta Lake).
- Інструменти на кшталт TableFlow автоматизують цей процес: стрім «матеріалізується» у вигляді таблиці в object storage.
У підсумку:
- Той самий набір даних:
- доступний як реальний стрім для Flink та мікросервісів;
- одночасно доступний як високопродуктивна таблиця для Snowflake, Spark, Trino та інших SQL-рушіїв.
Що дає Data Streaming Platform
Поєднання shift left і табличної матеріалізації формує Data Streaming Platform:
- Один стрім даних живить:
- real-time застосунки;
- аналітичні системи та BI.
- Немає потреби будувати окремі пайплайни під кожен інструмент чи команду.
- Команди можуть:
- обирати будь-яке object storage;
- використовувати улюблений query engine;
- працювати з одними й тими самими, узгодженими даними.
Це фактично дає переваги Lambda (і batch, і streaming, і гнучкі аналітичні інструменти) без її операційної складності, завдяки уніфікованому стрімінговому ядру.
Як обирати архітектуру
Зіставлення трьох підходів виглядає так:
- Lambda
- Природний результат, коли до існуючого batch додають стрімінг.
-
Працює, але створює подвійну інфраструктуру й складні розслідування інцидентів.
-
Kappa
- Уніфікує обробку в одному стрімінговому рушії.
-
Зменшує дублювання логіки й стеків, але потребує продуманого підходу до зберігання історії та інтеграції з аналітичними інструментами.
-
Data Streaming Platform
- Розвиває Kappa, додаючи:
- shift left для якості та governance;
- матеріалізацію стрімів у відкриті табличні формати.
- Дає єдине джерело даних для real-time і аналітики, зберігаючи гнучкість вибору інструментів.
Для нових систем логічна стратегія — орієнтуватися на уніфікацію навколо стрімінгової платформи. Це зменшує витрати, спрощує підтримку й дозволяє командам зосередитися на цінності даних, а не на «сантехніці» пайплайнів.
Джерело
Lambda vs Kappa vs Data Streaming Platform — Which One Wins? | Modern Data Engineering Pipelines