Watermarks

Comment décider qu'une fenêtre temporelle est « complète » quand les évènements arrivent dans le désordre et qu'on ne peut jamais être absolument certain qu'il n'en arrive plus.

Problème

Dans un flux event-time, l'ordre de réception ne reflète pas l'ordre d'origine : un message AS4 retardé par un access point en panne peut arriver 10 minutes après un message émis 5 secondes plus tard ailleurs. Quand fermer une fenêtre [09:00, 10:00] ? Si on attend trop, la latence devient inacceptable. Si on ferme trop tôt, on perd des données. Le mécanisme de watermark résout ce dilemme en fournissant une estimation continue du « jusqu'où on a vu tout ce qu'il y avait à voir ».

Forces

• Heuristique vs perfection — il n'existe pas de watermark parfaite pour des flux distribués réels.
• Trade-off latence/complétude : watermark conservatrice = latence ↑, completeness ↑.
• Source-aware : Kafka offre une watermark naturelle (per-partition timestamps) ; HTTP push ne le fait pas.
• Skew par clé : différents partenaires ont différents retards typiques.
• Pannes : un consommer mort fait stagner la watermark sur sa partition.

Solution

Une watermark W(t) est une estimation : « tous les évènements de timestamp ≤ W(t) sont normalement arrivés à l'instant t ». Les stratégies courantes : strict (W = max(ts) - X minutes — Flink BoundedOutOfOrderness), percentile (W = 99e percentile des arrivées récentes), per-source (chaque partition Kafka émet sa propre watermark, le système prend le min). Quand W(t) dépasse la fin d'une fenêtre, la fenêtre est fermée et l'agrégat émis. Les évènements ultérieurs (late data) sont gérés par allowed lateness (rééémettre les mises à jour) ou side output (envoyer dans une queue dédiée pour reprocessing). Google Dataflow et Apache Beam exposent une API WindowFn.assignWindows + Trigger pour découpler ces préoccupations.

Structure

Event stream (event-time, processing-time):
  (09:00, 09:01)  ●
  (09:02, 09:02)  ●
  (09:05, 09:08)  ●  ◄── 3 min late
  (09:06, 09:06)  ●
  (08:58, 09:10)  ●  ◄── 12 min late (very out of order)
  (09:10, 09:11)  ●

Window [09:00, 09:05)
  Strategy "max(ts) - 2min":
    At PT=09:08, max event-time seen = 09:05
    Watermark = 09:05 - 2min = 09:03
    Window not yet closed (watermark < 09:05)
  At PT=09:11, max event-time seen = 09:10
    Watermark = 09:10 - 2min = 09:08
    Window CLOSED, emit aggregate of {09:00, 09:02}
    Late event 08:58 arriving at 09:10:
      → drop, or side-output to late_events topic, or
      → if allowed lateness 5min: update aggregate to include 08:58

Implémentation EDI

En EDI, le source-aware watermarking est presque toujours la bonne approche. (1) Hub PEPPOL multi-access-points : chaque AP a sa propre cadence, on calcule une watermark par AP source et la watermark globale = min. Si un AP est en panne, sa watermark stagne et bloque les fenêtres aval — c'est voulu, car on ne veut pas clôturer un rapport DRR sans avoir reçu les données de tous les APs. (2) Reporting fiscal (DRR, ZATCA, CFDI) : watermark conservatrice avec lag de 24h minimum pour absorber les pannes de partenaires ; rapport émis à J+1 avec allowed lateness de 7 jours pour permettre les redéliveries lentes. (3) Anomaly detection : watermark agressive (lag de 30s) pour réagir vite ; les late events vont dans un side output pour reprocessing batch. Ne jamais utiliser processing-time pour ces cas critiques — un replay produit des watermarks différentes du run original.

Anti-patterns

• Watermark sur processing-time pour rapport fiscal — replay incohérent garanti.
• Watermark globale unique (max sur toutes les partitions) — un consumer mort la fait stagner pour tout le job.
• Lag trop court — fenêtres fermées prématurément, données perdues sans alerte.
• Pas de side output sur late data — perdues silencieusement, sous-déclaration fiscale possible.
• Allowed lateness illimitée — state RocksDB qui ne se libère jamais.

Patterns liés

• Tumbling Window — ce que les watermarks ferment.
• Sliding Window — idem.
• Session Window — idem.
• Exactly-Once Semantics — souvent combiné aux watermarks pour reporting exact.

Sources

• Akidau T. et al. — The Dataflow Model, VLDB 2015. La source canonique sur watermarks. research.google
• Akidau T. — The world beyond batch: Streaming 102, O'Reilly 2015. oreilly.com
• Apache Flink — Generating Watermarks. nightlies.apache.org
• Apache Beam — Programming Guide: Watermarks and late data. beam.apache.org
• Akidau, Chernyak, Lax — Streaming Systems, O'Reilly 2018, chap. 2-3.