Windowing, late events и stateful processing¶
Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.
Версии в источниках: Kafka/Connect/Streams 4.1, Debezium 3.3, Flink 1.20.3, Spark 4.0.1 и Airflow 3.1 либо явно названная система. Непроверенные вопросы и ограничения runtime — в журнале (архив рабочего проекта).
Механизм¶
Tumbling windows не пересекаются, sliding/HOP включают событие в несколько ranges, session windows зависят от gaps и могут merge. Keyed state хранит aggregates/timers по business key; state lifetime должен учитывать watermark, allowed lateness, corrections и sink contract.
flowchart TB
Event --> Key[Key and windows]
Key --> State[Aggregate and timers]
State --> Emit[Result with revision]
Late[Allowed late event] --> State
Emit --> Upsert[Versioned sink replacement]
State --> Cleanup[Safe cleanup horizon]
Пошаговое объяснение¶
Событие адресуется key и window(s) → aggregate update → watermark/timer emits result → late-within-policy event обновляет/retracts прежний результат → cleanup удаляет state. Emission не всегда final: нужно различать append facts и upsert changelog.
Failure scenarios и recovery¶
После cleanup слишком поздний event требует side output/quarantine/recompute или явного drop accounting. Blind sum новых aggregate snapshots в ClickHouse завышает результат. Sink key=(tenant,window_start,window_end,metric,generation), revision monotonic в согласованной lineage.
Trade-offs и эксплуатация¶
Sliding windows увеличивают state/work относительно tumbling. Incremental aggregation хранит меньше state, чем все events, но некоторые функции/joins требуют существенной истории. Session merge делает stable result identity/corrections сложнее.
Практический пример¶
Real-time analytics сохраняет revisions и latest selection вместо additive sum snapshot. Antifraud задаёт policy stale/missing features.
Типичные ошибки проектирования¶
Смешивать source/state/sink boundaries, скрывать failed records и неопределённый исход timeout; применять retry без identity/version и retention contract. Конкретные ограничения разобраны выше.
Вопросы на собеседовании¶
Почему update stream нельзя писать как append sum? Новая snapshot заменяет прежнюю, не добавляет независимый факт.
TTL state равно allowed lateness? Нет, механизмы и time basis могут отличаться.
Практические упражнения¶
Для events t=1,7,12 и late t=3 рассчитайте tumbling10s и HOP(size10s,slide5s), затем укажите correction messages и ключи.