В предыдущих уроках мы разобрались, что такое batch и streaming, как они устроены, какие архитектурные шаблоны их соединяют. Теперь главное — научиться выбирать между ними в каждой конкретной задаче. Это самый частый вопрос на собеседовании DE и в повседневной работе: «BI-отчёт — batch или stream? Алерт о платеже — batch или stream? Recommendations — batch или stream?» Этот урок собирает чек-листы и матрицу решений.
Главный критерий: бизнес-латентность
Базовый вопрос, на который отвечать первым: какая допустимая задержка от события до того, как результат полезен пользователю? Это бизнес-требование, а не техническое.
- CFO смотрит финансовый отчёт раз в день утром. Латентность — до 24 часов. Batch.
- Антифрод должен отклонить подозрительный платёж до его проведения. Латентность — секунды. Streaming.
- Маркетинг хочет видеть DAU не позже, чем через 10 минут после полуночи. Латентность — минуты. Streaming или micro-batch.
- Менеджер хочет видеть свежий отчёт по выручке к 09:00 каждого дня. Латентность — до 9 часов. Batch.
Бизнес-латентность диктует архитектуру, а не наоборот. Если латентность можно обеспечить batch-ом — выбирай batch. Streaming имеет операционную стоимость, которую не имеет смысла платить просто так.
Самая частая ошибка — выбирать streaming потому, что «это круто и современно». Streaming-инфраструктура (Kafka + Flink + операционная поддержка 24/7) — это дорого. Прежде чем выбирать streaming, реально проверь, что бизнес не примет батч.
Матрица решений по сценариям
Каждый сценарий имеет естественный шаблон. Латентность диктует выбор.
Кейс 1: BI-отчёт CFO
Сценарий: финансовый директор каждое утро в 09:00 открывает дашборд и видит выручку за вчера, агрегированную по сегментам и регионам.
Латентность: до суток. Этого требует бизнес, не больше и не меньше.
Источники: операционные базы продаж (Postgres), CRM (Salesforce), биллинг (Stripe). Все они штатно поддерживают ежедневную выгрузку.
Решение: batch. Каждую ночь в 04:00 — выгрузка из источников через Fivetran/Airbyte. К 05:00 dbt пересчитывает витрины. К 09:00 дашборд свеж.
Почему не streaming: финансы не считают деньги в реальном времени. Ночной batch стабильнее, проще, дешевле в поддержке. Streaming тут — overkill.
Кейс 2: Антифрод
Сценарий: пользователь нажал «оплатить», система должна за секунды решить: пропускать платёж или отклонить как подозрительный.
Латентность: 100-500 миллисекунд. Платёж нельзя задерживать на минуты — пользователь уйдёт.
Источники: события платежей в Kafka, история транзакций в feature store, ML-модель в inference-сервисе.
Решение: streaming. События платежей идут через Kafka, Flink/Kafka Streams обогащают их фичами из feature store, ML-модель скорит каждое событие, результат отправляется обратно в платёжную систему за миллисекунды.
Почему не batch: за время одного batch-окна тысячи фродовых платежей успеют пройти. Это прямой финансовый ущерб.
Kafka как backbone антифрод-системы: события платежей в append-only логеКейс 3: ML feature engineering для тренировки модели
Сценарий: ML-команда раз в неделю тренирует новую версию модели рекомендаций. Им нужен датасет фич за последний год — пользовательские агрегаты, исторические покупки, демографические данные.
Латентность: до недели. Тренировка не нуждается в realtime-данных.
Источники: всё, что есть в DWH: события, заказы, профили.
Решение: batch. Большой Spark/dbt job, который раз в неделю собирает фичи в DWH или feature store offline-режима. Никаких требований к свежести нет.
Почему не streaming: тренировка ML — это тяжёлый job на гигантских объёмах. Streaming для месячных окон неэффективен. Batch на нагретом кластере справится в десятки раз быстрее и дешевле.
Кейс 4: Realtime recommendations
Сценарий: пользователь зашёл на главную, система должна показать персональные рекомендации, учитывая, что он смотрел 30 секунд назад.
Латентность: 50-200 миллисекунд на запрос рекомендации.
Источники: события взаимодействия в Kafka, профиль пользователя в Redis/feature store, ML-модель в inference-сервисе.
Решение: streaming для online feature store (Redis с pre-computed embeddings) + realtime-inference. Streaming-job обновляет фичи в Redis по событиям пользователя, frontend запрашивает рекомендации синхронно.
Почему не batch: рекомендации, рассчитанные ночью, проигнорируют последние действия пользователя. Streaming критичен для свежести.
Кейс 5: Reverse ETL
Сценарий: lifetime value клиентов считается в DWH через dbt-модели. Менеджеры хотят видеть его в Salesforce при общении с клиентом.
Латентность: зависит. Может быть «раз в час» или «раз в день» — нет жёстких требований к секундам.
Источники: DWH (Snowflake), цель — Salesforce.
Решение: чаще batch. Hightouch/Census каждый час читает витрину LTV и синхронизирует в Salesforce. Streaming тут возможен (когда LTV-модель обновилась -> push в Salesforce), но обычно избыточен.
Почему не streaming: бизнес-сценарий редко требует мгновенного обновления — менеджер видит LTV в моменте звонка, и часовой свежести достаточно.
Кейс 6: Streaming ETL
Сценарий: события клика идут в Kafka, нужно их обогатить geo-данными (по IP), отфильтровать ботов и положить в DWH для downstream-аналитики.
Латентность: минуты — данные нужны быстро, но не миллисекунды.
Источники: Kafka топик clicks, lookup-таблица IP->geo.
Решение: streaming. Flink/Spark Structured Streaming читает Kafka, обогащает событие, фильтрует, пишет в DWH micro-batch’ами по 1-5 минут. Это и есть streaming ETL.
Почему не batch: ждать ночи для попадания событий в DWH — теряем оперативность. Bot-detection и обогащение легко делается на лету.
Spark Structured Streaming: micro-batch-обработка событий из Kafka в DWHГибрид: когда нужны оба
Большинство компаний используют и то, и то, но для разных сценариев:
- Streaming для операционных: фрод, алерты, realtime metrics, recommendations.
- Batch для аналитики, отчётов, ML-обучения, биллинга.
- Streaming ETL как мост между источниками и DWH.
Эти контуры не дублируют логику (как в Lambda), а решают разные задачи. Команда поддерживает оба, но каждый job живёт в естественной для него парадигме.
Хороший DE умеет защищать выбор архитектуры через бизнес-латентность, а не через моду. Если бизнес говорит «нам нужен realtime», уточняй: «какая допустимая задержка от события до результата?» Часто оказывается, что 15 минут устраивает — это micro-batch или дешёвый streaming с большим окном, не нужно строить полноценный Flink-кластер.
Чек-лист для выбора
Когда тебе приходит новая задача, пройди по чек-листу:
Airflow для оркестрации batch-задач в гибридном стеке- Какая бизнес-латентность? Сутки, часы, минуты, секунды?
- Если сутки/часы -> batch. Cron + Spark/dbt.
- Если минуты -> micro-batch или streaming с большим окном.
- Если секунды -> streaming. Kafka + Flink/Spark Streaming.
- Какой объём данных? Если десятки терабайт исторических — для backfill используй batch даже в streaming-first архитектуре.
- Какая зрелость команды? Streaming требует операционной поддержки 24/7 — есть ли возможность?
- Какие источники? Если данные приходят раз в сутки batch-выгрузкой — streaming сверху ничего не даст.
Применение этого чек-листа — обычная инженерная гигиена. Это и есть «думать как DE».
Попробуй сам
Возьми сервис, которым пользуешься (мессенджер, банк, маркетплейс) и составь mental map: какие там сценарии работают на batch, какие на streaming. Push-уведомление о подозрительном входе — streaming. Месячная выписка по счёту — batch. Изменение баланса в приложении — streaming (по крайней мере на UI). Подсчёт месячного бонуса по программе лояльности — batch. Привыкай классифицировать сценарии — это базовый навык DE.