Сучасні компанії можуть мати «ідеально працюючі» дата-пайплайни, регулярні batch-запуски й красиві звіти — і водночас втрачати мільйони через затримку в лічені хвилини. На каналі Confluent Developer пояснюють, як застарілі підходи до обробки даних перетворюють бізнес-обіцянки на ризик, і чому індустрія масово переходить до потокової обробки та подієвої архітектури.
Коли 59 хвилин затримки руйнують бізнес-модель
Уявімо онлайн-рітейлера, який побудував бренд на обіцянці «доставка наступного дня». Логістика відпрацьована, платформа виглядає надійною — але в архітектурі ховається один елемент, який не відповідає реальності бізнесу: legacy batch-оновлення.
Сценарій простий:
- о 9:01 продається останній смартфон вартістю $1000;
- система продажів і система інвентаризації — різні, синхронізуються щогодини;
- до 10:00 сайт продовжує «думати», що товар є в наявності, й приймає сотні чи тисячі замовлень;
- кожне замовлення — це не лише $1000 потенційного повернення, а й обіцянка доставки наступного дня, яку виконати вже неможливо.
О 10:00 batch-джоб нарешті оновлює інвентар, і система «бачить правду». Далі — каскад проблем: скасування замовлень, термінове перенаправлення поставок з інших складів, додаткові витрати, компенсації, втрата довіри до ключової обіцянки бренду. Визначальна перевага («доставка наступного дня») перетворюється на зобов’язання, яке компанія системно порушує.
Показово, що все це не наслідок краху інфраструктури чи кібератаки. Джерело проблеми — розрив між очікуванням клієнта (операція в реальному часі) та реальним станом системи (дані відстають на 59 хвилин).
Подібні збої масштабуються разом із навантаженням. Показовий приклад — скандал навколо продажу квитків на Taylor Swift Eras Tour через Ticketmaster: мільйони користувачів, «історично безпрецедентний» попит, розсинхронізація інвентарю місць у кошиках і при оплаті, перевантаження системи, зупинка передпродажу, політичний та юридичний шлейф. Точні технічні причини там різні й не зводяться лише до batch-процесів, але кейс демонструє, як «невелика» невідповідність даних реальності стає критичною на великому масштабі.
Чому batch-процеси більше не відповідають реальності
Batch-оновлення історично були нормою в дата-інженерії. Walmart роками працював на batch-інвентаризації, перш ніж перейти до архітектури реального часу на основі event streaming. Щоб зрозуміти, чому цей перехід стає масовим, варто подивитися на бізнес без програмного коду.
Події як природна модель бізнесу
У фізичному магазині поведінка клієнта — це послідовність подій у реальному часі:
- людина бачить товар на полиці;
- бере його й кладе до візка;
- підходить до каси й оплачує.
Кожна з цих дій — подія, що вже відбулася, і вона миттєво змінює стан системи: товар зник із полиці, зменшився залишок на складі, гроші надійшли в касу.
Проблеми починаються, коли до цих природних подій додають штучні обмеження, яких у реальному бізнес-процесі немає. Наприклад, уявімо абсурдне правило: «класти товар у візок можна лише раз на годину, рівно на початку години». Люди знаходять потрібний товар, але змушені чекати. На «Х-ту хвилину» всі одночасно тягнуться до одних і тих самих позицій — конфлікти гарантовані. Це аналог того, що робить batch-процес: реальні події відбуваються постійно, але система обробляє їх «порціями» в задані моменти часу.
Це обмеження існує лише в софті й не має жодного сенсу в бізнес-домені. Воно з’явилося як компроміс епохи, коли:
- софт лише доповнював роботу людей;
- клієнт бачив фізичний товар і міг сам перевірити наявність;
- у разі розбіжності «екран vs полиця» люди довіряли очам, а не базі даних.
У цифровому світі все навпаки:
- клієнт взаємодіє тільки з програмою;
- фізичного товару перед очима немає;
- якщо інтерфейс показує одне, а реальність інша — користувач не має способу це виявити до моменту збою.
Те, що працювало в «людиноцентричному» середовищі, ламається в «софт-центричному». Batch-джоби, які колись були ефективним компромісом, стають джерелом системних ризиків.
Потокова обробка та Shift-Left Analytics: нова роль дата-інженера
Відповіддю на ці виклики стає перехід від накопичення даних у batch до їхньої організації в потоки подій і обробки в момент надходження. Це основа stream processing та подієвої архітектури (event-driven architecture), які реалізуються, зокрема, за допомогою Apache Kafka, Apache Flink та подібних платформ.
Як працює потокова модель
У сценарії з онлайн-рітейлером це виглядає так:
- о 9:01 відбувається продаж останнього гаджета;
- генерується подія
product_soldі публікується в стрім; - система інвентаризації підписана на ці події й одразу оновлює залишки;
- коли кількість товару стає нульовою, формується подія
product_sold_out; - сайт, підписаний на цей стрім, миттєво припиняє приймати замовлення на товар, якого вже немає.
Замість годинної затримки — затримка в межах сотень мілісекунд. Ключовий момент: система не ускладнилася штучними обхідними шляхами, вона просто почала моделювати реальні події бізнесу в реальному часі.
Shift-Left Analytics: аналітика «зсувається вліво»
Традиційно дата-інженери будували batch-пайплайни, які:
- забирали операційні дані;
- очищували, валідували, трансформували їх;
- складали в аналітичні таблиці для прийняття рішень.
З появою потокових платформ ці операції «зсуваються вліво» — ближче до джерела даних. Цей підхід отримав назву Shift-Left Analytics (або просто Shift Left) і означає:
- очищення, валідація та трансформація виконуються безпосередньо в стрімах;
- критичні перетворення відбуваються ще до того, як дані потрапляють у сховища чи data lake.
Це дає три ключові переваги:
-
Мінімальна затримка
Дані стають доступними одразу, без очікування «вікон» batch-обробки. -
Вища надійність
У разі збою процес продовжується з останнього обробленого елемента, а не з нуля для всього батчу. -
Менше дублювання
Замість повторювати однакову логіку очищення й трансформації в різних batch-джобах, створюються повторно використовувані потокові «data products», які можуть споживати як аналітичні, так і операційні системи.
На цьому тлі змінюється й професійний профіль. Класичний дата-інженер, який будував batch-пайплайни для аналітики, еволюціонує в data stream engineer — фахівця, що створює реальні потокові дата-продукти для всього ландшафту систем, включно з операційними.
Від batch до стрімів: вирівнювання системи з реальністю
Головний зсув, який відбувається сьогодні в інженерії даних, — це відмова від штучних часових обмежень на користь моделювання реальних подій бізнесу.
Batch-процеси історично йшли «проти течії» реального часу: вони накопичували події, щоб обробити їх пізніше, коли це зручно інфраструктурі. Потокова обробка, навпаки, пливе разом із подіями, синхронізуючи стан системи з тим, що відбувається «тут і зараз».
У світі, де все більше рішень приймається автоматично, а системи штучного інтелекту залежать від актуальних даних, значення реального часу лише зростатиме. Batch-обробка навряд чи зникне повністю, але її роль змінюється: вона перестає бути «основним способом життя» для даних і поступається місцем потоковим підходам.
При цьому трансформується не стільки професія, скільки інструментарій і мислення. Дата-інженери, які вміють працювати з подієвими стрімами, стають ключовими гравцями в побудові систем, що не просто «працюють», а відповідають реальності бізнесу в кожен момент часу.
Джерело
The Hidden Cost of Batch Processing | Modern Data Engineering Pipelines — Confluent Developer