Temps réel ou batch ? Choisir la bonne architecture de données
Le streaming n’est pas automatiquement meilleur que le batch. Une manière pratique de décider à quel point vos données doivent être fraîches, et d’éviter de payer une latence que vous n’utilisez jamais.
Le temps réel exerce une attraction gravitationnelle. Cela sonne moderne, cela fait une belle démo, et personne ne s’est jamais fait critiquer en réunion pour vouloir des données plus rapidement. Mais les architectures de streaming coûtent plus cher à construire, plus cher à exploiter et considérablement plus cher à opérer, et une grande partie de l’infrastructure de streaming dans le monde livre des données en quelques secondes à des décisions prises une fois par jour.
Partez de la décision, pas de la technologie
La seule question qui compte est : à quel point ces données peuvent-elles être périmées avant que la décision qu’elles alimentent ne se dégrade ? Répondez-y honnêtement, cas d’usage par cas d’usage, et l’architecture se choisit généralement d’elle-même. Un contrôle antifraude exige des millisecondes. Un rapport de revenus quotidien n’a besoin de rien de plus rapide que quotidien. La plupart des choses se situent quelque part de raisonnable entre les deux.
Personne ne s’est jamais fait critiquer pour avoir demandé des données plus rapidement, c’est précisément pourquoi on dépense tant d’argent pour une latence qu’aucune décision n’utilise jamais.
Ce que le temps réel coûte réellement
Le streaming n’est pas seulement un outil différent ; c’est un engagement opérationnel différent. L’état, l’ordonnancement, le traitement exactement-une-fois, les backfills, la relecture et l’astreinte 24/7 : tout cela devient votre problème dès l’instant où « du jour au lendemain » ne suffit plus. Ce coût peut valoir entièrement la peine d’être payé. Il devrait être une décision, pas un réglage par défaut.
- Pour chaque jeu de données, nommez la décision qu’il sert et la fraîcheur que cette décision exige.
- Optez par défaut pour le batch, sauf si une vraie décision a réellement besoin de données plus fraîches.
- Réservez le streaming aux cas où la péremption dégrade mesurablement le résultat.
- Envisagez le micro-batch ou le traitement incrémental comme un juste milieu pragmatique.
- Concevez de sorte qu’un pipeline batch puisse être promu en streaming plus tard sans réécriture.
Le juste milieu pragmatique
Le choix est rarement aussi tranché qu’il n’y paraît. Le micro-batch et le traitement incrémental offrent un « suffisamment frais » pour de nombreux cas d’usage, à une fraction du poids opérationnel du véritable streaming. L’outillage lakehouse moderne permet de commencer en batch et de resserrer la latence plus tard, à condition de l’avoir conçu ainsi dès le départ.
Lorsque nous concevons une plateforme de données, nous notons chaque flux selon la fraîcheur que ses décisions exigent réellement, nous dépensons le budget de complexité uniquement là où il est rentable, et nous gardons l’architecture capable de passer du batch vers le temps réel à mesure que de vrais besoins émergent, non par réflexe.
