Поток против пачки: когда streaming оправдан, а когда ночной batch честнее
Прежде чем выбирать архитектуру обработки данных, стоит честно посчитать стоимость задержки - и понять, платит ли за неё бизнес.
Когда заходит разговор об архитектуре обработки данных, довольно быстро появляется слово "стриминг". Звучит современно, ассоциируется с серьёзными системами, и инженеры нередко тяготеют к нему по умолчанию.
Я не против потоковой обработки. Но я видел достаточно проектов, где streaming выбирали не потому, что бизнес платит за низкую задержку, а потому что это казалось правильным архитектурным решением. Разница существенная.
В чём реально отличие
Batch-обработка - это накопление событий за период и их совместная обработка. Ночной пересчёт отчётов, утренняя выгрузка в аналитическую систему, еженедельный расчёт показателей - классические примеры. Простая операционная модель, предсказуемая нагрузка, понятное поведение при сбоях.
Потоковая обработка - это обработка каждого события по мере поступления, с минимальной задержкой. Данные движутся непрерывно, система реагирует в реальном времени или близко к нему.
Технически второй подход сложнее: нужно думать о порядке событий, о том, что делать с опоздавшими данными, о состоянии системы между событиями, о гарантиях доставки. Оперировать такой системой дороже и сложнее - а когда бизнесу нужен поток, а когда хватает каждые 15 минут - это уже вопрос бизнес-стороны, не только архитектуры.
Главный вопрос: кто платит за задержку
Перед выбором архитектуры я обычно задаю один вопрос: что конкретно в бизнесе происходит плохого, если данные появляются с задержкой в час? В четыре часа? Утром следующего дня?
Если ответ - "аналитик получит отчёт не утром, а к обеду" - задержка не стоит денег. Batch вполне справится, и нет смысла платить сложностью за скорость, которая никому не нужна.
Если ответ - "мы не успеем среагировать на мошенническую транзакцию" или "клиент получит неверный баланс в момент платежа" - задержка стоит реальных денег. Здесь streaming оправдан, и сложность инфраструктуры оплачивается конкретной бизнес-ценностью.
Проблема в том, что этот вопрос задают редко. Вместо него обсуждают технологии. Аргумент о том, что быстрые вычисления над данными что-то меняют в бизнесе, - ключевое слово именно «что-то меняют»: ещё нужно понять, что именно.
Когда batch - честный выбор
Большинство аналитических задач в средних компаниях не требуют данных в реальном времени. Финансовые отчёты, метрики продаж, операционные показатели, маркетинговая аналитика - всё это работает на данных с задержкой в несколько часов, и это нормально.
Batch здесь не "устаревший" подход. Это подход с более простой операционной моделью, более предсказуемой нагрузкой и более понятным поведением при сбоях. Если система упала ночью и не отработала - это заметно и понятно. Если стриминговый пайплайн тихо начал терять события - это можно не заметить долго.
Правило простое: если данные с задержкой в несколько часов не ломают бизнес-процесс - batch честнее и дешевле в обслуживании.
Когда streaming оправдан
Streaming имеет смысл там, где задержка создаёт реальную проблему для бизнеса или клиента.
Несколько признаков того, что задержка действительно стоит денег:
- решение нужно принять до следующего действия пользователя или системы;
- событие теряет ценность, если обработать его позже чем через несколько минут;
- накопление событий без обработки создаёт риск - финансовый, операционный или репутационный;
- пользователь видит последствия задержки и реагирует на это.
Антифрод, управление остатками в реальном времени, мониторинг производственных линий, персонализация в момент сессии - здесь streaming решает конкретную задачу.
Гибридный подход часто честнее, чем выбор одного
На практике многие системы используют оба подхода в зависимости от задачи. Транзакции обрабатываются в реальном времени для проверки и исполнения, но агрегаты и отчёты строятся пакетно - потому что их не нужно видеть немедленно.
Это не архитектурная непоследовательность. Это разумное распределение сложности по тем задачам, где она оправдана.
Практический фильтр
Перед выбором архитектуры обработки данных стоит ответить на четыре вопроса:
- Что конкретно ломается в бизнес-процессе, если данные приходят с задержкой в час?
- Кто - сотрудник или клиент - страдает от этой задержки, и как именно?
- Есть ли у команды опыт эксплуатации потоковых систем - или это будет первый раз?
- Какова полная стоимость владения потоковой системой по сравнению с batch, включая людей и инциденты?
Если на первые два вопроса нет конкретного ответа - выбор архитектуры преждевременен. Сначала нужно понять, за что платит бизнес.