Contexte et objectifs initiaux
Il y a onze ans, les auteurs du Dataflow Model ont publié un article qui proposait un modèle unifié pour le traitement continu des données. Le modèle introduisait quatre concepts majeurs – windowing, triggers, watermarks et retractions – afin de permettre aux systèmes de choisir librement entre correctness, latence et coût, que ce soit en mode batch ou streaming. L’hypothèse de base était que les flux de données seraient unbounded et désordonnés, rendant inutile l’attente d’une complétude des jeux de données.
Éléments qui ont bien vieilli
Trois piliers du modèle se sont avérés robustes. Premièrement, la primauté du temps d’événement (event time) a été adoptée par la plupart des moteurs modernes (Flink, Spark Structured Streaming), car elle sépare la logique métier de la variabilité du temps d’ingestion. Deuxièmement, l’idée que l’attente de complétude est futile a conduit à l’usage généralisé des watermarks, qui indiquent jusqu’où le système peut considérer les données comme « stable ». Troisièmement, la cohérence forte – garantir que chaque mise à jour du flux se reflète de façon déterministe – reste un critère de conception pour les systèmes qui ne peuvent tolérer les incohérences temporaires, notamment dans les applications financières.
Limites et erreurs d’interprétation
Le papier a toutefois surestimé l’importance de windowing et triggers. Leur sémantique était imbriquée avec des préoccupations opérationnelles (gestion de l’état, planification des tâches), ce qui a complexifié les API et découragé les développeurs. Les triggers, conçus comme un mécanisme finement réglable pour déclencher des calculs, se sont révélés over‑engineered : les utilisateurs finaux n’ont jamais eu besoin de définir des points de déclenchement aussi granulaire, préférant des modèles plus simples basés sur le temps ou le volume de données. Enfin, le cadre initial séparait les streams des tables, alors que les travaux ultérieurs ont montré qu’ils sont deux vues d’un même objet, différant uniquement par leurs accès (lecture continue vs requête ponctuelle).
Évolution vers les pratiques actuelles
Les concepts du Dataflow Model ont migré vers le playbook des bases de données. Les systèmes modernes utilisent SQL comme langage d’expression, complété par incremental view maintenance et materialized views dotées de freshness contracts – des garanties explicites sur la fraîcheur des résultats. Cette évolution reflète la scission du principe de completeness en deux formes : les watermarks, qui laissent les flux visibles en continu, et le snapshot‑consistent refresh, qui actualise les vues à des points de cohérence définis. Le second a gagné en popularité car il impose moins de contraintes aux utilisateurs, qui n’ont plus à gérer les watermarks eux‑mêmes. Parallèlement, la demande de faible latence s’est bifurquée le long des lignes traditionnelles OLTP/OLAP : les applications transactionnelles exigent des réponses en millisecondes, tandis que les workloads analytiques acceptent des rafraîchissements plus doux, souvent mesurés en secondes ou minutes. Cette différenciation a permis aux systèmes de « push harder » uniquement lorsque le cas d’usage le justifie, tout en conservant une architecture simple pour la majorité des requêtes analytiques.
