Batch vs Stream: коли що

Навіщо взагалі вибирати

Будь-яка система даних балансує між свіжістю (latency), вартістю, складністю підтримки і надійністю.
Batch - періодичні «порції» даних з високою пропускною здатністю і низькою вартістю за запис.
Stream - безперервна обробка подій з мінімальною затримкою і станом в пам'яті/локальних сторах.

Коротко про моделі

Batch

Джерело: файли/таблиці/снапшоти.
Тригер: розклад (година/день) або умова (новий паркет-файл).
Сильні сторони: простота, детермінізм, повний контекст даних, дешеві великі перерахунки.
Слабкі: немає «онлайну», висока латентність, «вікна» без сигналів реального часу.

Stream

Джерело: брокери (Kafka/NATS/Pulsar), CDC, черги.
Тригер: подія.
Сильні: низька затримка, реактивність, природна інтеграція з продуктом.
Слабкі: складність часу (event vs processing), порядок/дублі, стан, експлуатація.

Рішення: матриця вибору

Правило 80/20: якщо SLA дозволяє хвилинні/годинні затримки і немає реактивних фіч - беріть batch. Якщо критична реакція «тут і зараз» або потрібні живі вітрини - stream (часто + додатковий нічний batch для вивірки).

Типові сценарії

• Щоденна звітність, білінг періодами, ML-тренінг, великі джоїни, дедуплікація «всім набором».
• Медальйон-модель (bronze/silver/gold) з глибокими валідаціями.
• Масові бектести і перезбірка вітрин.

• Антифрод/моніторинг, алерти SRE, real-time баланс/місії, рекомендації «зараз».
• Інтеграції «подія-як-факт» (EDC), оновлення матеріалізованих уявлень (CQRS).
• Мікросервіси: нотифікації, вебхуки, реакції на бізнес-події.

• Потік формує операційні вітрини і сигнали; нічний batch робить вивірку, звід і дешеві історичні перерахунки.

Архітектури

Lambda (Stream + Batch)

Stream для інкременту та онлайну; Batch для повноти і корекцій.
Плюси: гнучкість і SLA. Мінуси: подвійна логіка, дублювання коду.

Kappa (все — Stream + Replay)

Єдиний лог як джерело істини; batch-перерахунки = replay.
Плюси: одна кодова база, єдина семантика. Мінуси: складніше експлуатація, вимоги до зберігання логу.

Hybrid-Pragmatic

Потокова «операційка» + періодичні batch-джоби для важких джоїнів/ML/корекцій.
На практиці - найпоширеніший варіант.

Час, порядок, вікна (для Stream)

Спирайтеся на event time, не на processing time.
Керуйте watermark і'allowed _ lateness'; підтримуйте retractions/upserts для пізніх подій.
Партіонуйте по ключах агрегатів, плануйте «гарячі ключі».

Надійність і семантика ефектів

Batch

Транзакції БД або атомарна заміна партій/таблиць.
Ідемпотентність - через deterministic-обчислення і overwrite/insert-overwrite.

Stream

At-least-once + ідемпотентні sinks (upsert/merge, версії агрегатів).
Транзакційний «прочитав-записав-зафіксував позицію» для EOS за ефектом.
Таблиці дедупа по'event _ id '/' operation _ id'.

Сховища та формати

Batch

Data Lake (Parquet/Delta/Iceberg), OLAP (ClickHouse/BigQuery), об'єктне сховище.
ACID-таблиці для atomic replace, time travel.

Stream

Логи/теми в брокерах, state stores (RocksDB/embedded), KV/Redis, OLTP для проекцій.
Реєстр схем (Avro/JSON/Proto), режими сумісності.

Вартість і SLO

Batch: оплачуєте «пачками» - вигідно при великих обсягах, але затримка ≥ розкладу.
Stream: постійні рантайм-ресурси, пікова вартість при високому QPS; зате SLA в секундах.
Вважайте p95/p99 latency, наскрізний лаг, вартість в у.о./подія і TCO підтримки.

Тестування

Загальне: golden-набори, property-based інваріанти, генерація брудних входів.
Batch: детермінованість, ідемпотентні перезапуски, порівняння склепінь «до/після».
Stream: out-of-order/дублікати, fault-injection між ефектом і фіксацією офсету, replay-тести.

Обсервабіліті

Batch: тривалість джоб, частка фейлів/ретраїв, свіжість вітрин, скан-cost.
Stream: лаг за часом/повідомленнями, watermark, late-rate, розмір state/частота checkpoint, DLQ-ставка.
Скрізь: 'trace _ id','event _ id', версії схем/конвеєрів.

Безпека та дані

PII/PCI - мінімізувати, шифрувати at-rest/in-flight, мітити поля в схемах ('x-pii').
Для Stream - захист state/checkpoint'ів, ACL на топіки.
GDPR/право на забуття: в Stream - крипто-стирання/редакція в проекціях; в Batch - перерахунок партій.

Перехідні стратегії

Batch → Stream: почніть з публікації подій (Outbox/CDC), підніміть невелику вітрину real-time, не чіпаючи існуючий звід.
Stream → Batch: додайте щоденні зведення для звітності/вивірки і зниження навантаження на потокові sinks.

Анти-патерни

«Все в Stream» заради моди: дорого і складно без реальної потреби.
«Один гігантський нічний batch» при вимогах <5 хвилин.
Використання processing time для бізнес-метрик.
Сирі CDC як публічні події: жорстка зв'язність, біль при еволюції.
Немає ідемпотентності в sinks → подвійні ефекти на рестартах.

Чек-лист вибору

• SLO свіжості: скільки секунд/хвилин/годин допустимо?
• Стабільність входів: чи є out-of-order/дублікати?
• Чи потрібні онлайнові реакції/вітрини?
• Вартість: рантайм 24/7 vs «вікно за розкладом».
• Спосіб корекцій: retract/upsert або нічний перерахунок.
• Команда і операційна зрілість (обсервабіліті, on-call).
• Вимоги до «рівно одного ефекту».
• Політики PII/ретенції/право на забуття.

Референс-патерни

• Stream: EDC → проекції (KV/Redis, OLTP) для UI, ідемпотентні upsert.
• Batch: nightly звід в OLAP, reconciliation, ML-фічі.

• Stream: session-вікна, CEP-правила, алерти <1-5 с.
• Batch: перенавчання моделей, офлайн-валідація.

• Stream: тригери, сегменти в реальному часі.
• Batch: скоринги, LTV-моделі, звіти.

FAQ

Чи можна отримати «майже real-time» на batch?
Так: мікробатчі/тригерні джоби (кожні 1-5 хвилин) - компроміс, але без складнощів вікон/late-events.

Чи потрібен Lambda-підхід скрізь?
Ні, ні. Якщо потік закриває всі завдання і ви вмієте робити replay - Kappa простіше в довгу. Інакше - гібрид.

Як рахувати вартість?
Підсумовуйте compute + storage + ops. Для Stream додайте ціну простою «24/7» і аварійних ночей; для Batch - ціну «прострочення» даних.

Підсумок

Вибирайте Batch, коли важливі низька вартість, простота і періодичні склепіння; Stream - коли критична реактивність і свіжість. На практиці перемагає гібрид: потік - для онлайну і сигналів, батч - для повноти і дешевих історичних перерахунків. Головне - задати SLO, забезпечити ідемпотентність/спостережуваність і заздалегідь спроектувати шлях корекцій.