Micro-batch Processing¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Уровень: execution model обработки потока. Проверка источников: 2026-11-02.

1. Назначение и решаемая проблема¶

Micro-batch обрабатывает непрерывный input конечными порциями, объединяя события в вычислительный run. Он полезен, когда amortized batch overhead, SQL transformations и простое управление ресурсами важнее минимальной record-at-a-time задержки.

Это не обязательно Lambda и не «обычный batch, который иногда запускают». Continuous query имеет durable progress, bounded input range каждой порции и state между runs.

2. Принцип работы¶

На trigger фиксируется диапазон input positions. Engine выполняет transformations и state updates, записывает sink результат и progress по своему recovery protocol. Следующая порция продолжает с этой границы.

Интервал trigger не является гарантированной latency: к ожиданию добавляются backlog, scheduling, processing, checkpoint и sink visibility. При перегрузке порции могут запускаться последовательно без ожидаемой паузы.

3. Архитектурная схема¶

flowchart TB
    L["Durable input log"] --> T["Trigger и offset range"]
    T --> B["Micro-batch N"]
    S["Checkpointed state"] --> B
    B --> W["Sink commit protocol"]
    W --> V["Visible output"]
    B --> C["Progress / checkpoint"]
    C --> S

4. Walkthrough движения данных¶

Query обнаруживает новые source positions и формирует batch_id с input range.
Записи парсятся, dedup-ятся по contract и обогащаются выбранной версией reference data.
Stateful aggregation обновляет state; event-time windows определяются timestamps и watermark policy, а не временем запуска trigger.
Sink принимает результат порции. Если это пользовательский SQL upsert, приложению нужен собственный duplicate-safe protocol.
Engine фиксирует progress так, как предусмотрено конкретной реализацией. Схема не утверждает, что sink и checkpoint всегда одна transaction.
После crash возможно повторное выполнение порции; её output должен остаться корректным. Изменение query identity/checkpoint namespace меняет scope batch_id.

5. Технологии реализации¶

Spark Structured Streaming 4.0.1 — конкретная реализация. Flink может получать input порциями, но его checkpoint interval не превращает весь runtime в Spark micro-batch model. Airflow schedule с independent jobs — ещё другая модель, без автоматического continuous-query state contract.

FACT: Spark 4.0.1 описывает micro-batch как default processing mode, а guarantees sink различаются. API guide. Continuous Processing не надо считать тем же режимом.

6. Консистентность и гарантии обработки¶

FACT: в Spark 4.0.1 Kafka sink отмечен как at-least-once; foreachBatch guarantees зависят от реализации и по умолчанию допускают повторные writes. Таблица sinks и foreachBatch.

INFERENCE: для SQL sink можно atomically записать query identity + batch_id и effect в одной DB transaction, либо делать идемпотентный upsert по event/business revision. Dedup одним batch_id без identity query и контролируемого lifecycle checkpoints опасен.

Window finality зависит от late-event contract. Успешный trigger не означает, что будущая коррекция уже невозможна.

7. Отказы и восстановление¶

Сбой	Recovery	Риск
Crash до sink commit	Повтор input range	Частичные writes должны rollback-иться либо быть safe
Sink commit есть, progress нет	Повтор batch	Без idempotency duplicate effect
Checkpoint удалён	Новый query/rebuild plan	Старые batch IDs могут пересечься
Накопился backlog	Увеличить capacity или admission/rate policy	Снижение trigger interval само не ускорит работу

Рестарт с несовместимым state/query change нужно проверять по версии Spark; нельзя считать любой старый checkpoint переносимым.

8. Масштабирование и узкие места¶

Важны scheduling overhead, shuffle/skew, state store size, source fetch limits и sink batch size. Слишком маленькая порция тратит время на управление; слишком большая увеличивает tail latency и retry cost.

Rate limits защищают sink, но рост backlog должен быть видимым. Capacity planning включает drain time после outage. Отдельный historical backfill не должен создавать uncontrolled burst в production sink.

9. Преимущества и недостатки¶

Плюсы: удобство SQL/batch APIs, amortization, контролируемые порции и воспроизводимый input scope. Минусы: trigger/scheduling delay, большие spikes sink writes и повтор whole batch при failure.

Выбор micro-batch должен следовать freshness budget и возможностям state/sink; обещание «streaming всегда быстрее» здесь не помогает.

10. Альтернативные решения¶

Record-at-a-time processing подходит для более жёсткой reaction latency и сложной continuous state machine. Scheduled batch проще для крупных независимых периодов. Kappa может использовать micro-batch и historical source; Lambda может иметь micro-batch speed layer.

11. Реальные примеры и границы подтверждения¶

FACT: Uber Kappa material 2020 года описывает trigger-based incremental чтение Hive и повторное использование Spark streaming logic. Это подтверждённый пример порционного backfill, не proof guarantees любого Spark sink. Uber.

UNKNOWN: точные версии и современные настройки Uber не установлены; учебная схема не копирует production setup.

12. Применение в FinTech и iGaming¶

FinTech: оперативные reporting/feature updates, если бизнес допускает задержку порции. Синхронное authorizing decision не следует ждать от периодически обновляемой витрины без freshness contract.

iGaming: player activity aggregation и near-real-time dashboards; live bet acceptance требует отдельного анализа latency/ordering. Окно активности по event time не равно длительности micro-batch.

13. Типичные ошибки проектирования¶

Обещать latency, равную trigger interval.
Считать foreachBatch автоматически exactly-once.
Использовать batch_id без стабильной query identity.
Удалять checkpoint как обычный способ «исправить lag».
Обрабатывать late corrections как новые независимые ставки.

14. Вопросы технического интервью с ответами¶

Почему небольшая порция бывает медленнее? Scheduling и commit overhead могут доминировать над полезным вычислением.

Как не продублировать SQL effect? Один atomic boundary для dedup identity и effect либо корректный idempotent upsert; это контракт sink, не label движка.

Чем checkpoint отличается от input archive? Он хранит progress/state для recovery; если input за нужными offsets удалён, archive может понадобиться отдельно.

15. Практическое упражнение¶

HYPOTHETICAL: batch содержит e1/e2, sink commit успешен, process падает до progress commit. Спроектируйте SQL sink identity и обработку повтора.

Ожидается один effect для e1/e2, а новый query generation не должен ошибочно пропустить новый batch с таким же числовым batch_id. Дополнительно объясните, почему позднее событие предыдущего event-time окна не обязано попасть в output текущего trigger.

Дополнительные источники¶

Spark 4.0.1 guide; Uber Kappa.