Event time, processing time и watermarks¶

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

Версии в источниках: Kafka/Connect/Streams 4.1, Debezium 3.3, Flink 1.20.3, Spark 4.0.1 и Airflow 3.1 либо явно названная система. Непроверенные вопросы и ограничения runtime — в журнале (архив рабочего проекта).

Механизм¶

Event time задаётся событием/бизнес-контрактом, processing time — часами runtime. Ingestion time — ещё один timestamp, не синоним обоих. Watermark — оценка event-time progress по policy, не доказательство отсутствия более ранних событий.

flowchart TB
  Event[Event timestamp] --> Validate[Clock and schema checks]
  Validate --> Progress[Per-input progress]
  Progress --> Watermark[Combined watermark and idleness]
  Watermark --> Timer[Event-time timer]
  Late[Late event] --> Policy[Correct quarantine or drop with evidence]

Пошаговое объяснение¶

Timestamp extraction → per-input progress → watermark combination → event-time timers/window emission. Минимум активных inputs защищает от слишком раннего закрытия при медленном input; idle partition может остановить progress. Idleness исключает простаивающий input, поэтому возобновившиеся старые события могут стать late.

Failure scenarios и recovery¶

Clock skew/future timestamp способен преждевременно продвинуть watermark и изменить late-data outcome. Validating timestamp bounds и quarantine нужны до state update. Spark4 multiple-watermark policy и Flink1.20 watermark propagation не приравниваются; processing-time window после replay сформируется иначе.

Trade-offs и эксплуатация¶

Меньший out-of-orderness buffer уменьшает ожидание, увеличивая долю late corrections; больший увеличивает state/retention. Нельзя определить policy только по красивой latency без distribution задержек и требований полноты.

Практический пример¶

Flink HOP example и Spark stream используют event_time. Bounded sample не доказывает поведение idle live Kafka inputs.

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

Смешивать source/state/sink boundaries, скрывать failed records и неопределённый исход timeout; применять retry без identity/version и retention contract. Конкретные ограничения разобраны выше.

Вопросы на собеседовании¶

Watermark10:05 означает, что event10:04 не придёт? Нет, это выбранный progress contract.

Processing time воспроизводим при replay? Обычно нет, время повторного исполнения другое.

Практические упражнения¶

Для двух inputs с разным lag задайте watermark/idleness и разберите возобновление источника с поздним событием.