Par Andrew Tan
J'étais à une conférence l'année dernière lorsqu'un architecte de données — Fortune 500, grande équipe, budget conséquent — m'a pris à part pour me raconter une histoire que j'ai entendue trop de fois maintenant.
Ils ont passé 14 mois à migrer vers Kafka. Embauché une nouvelle équipe. Mis en place une nouvelle infrastructure. Créé une toute nouvelle rotation d'astreinte. Le tout.
Six mois après le lancement, ils ont discrètement déplacé la moitié des pipelines vers le traitement par lots.
Kafka n'a pas cassé. Cela fonctionnait bien. Le problème était plus bête que ça : personne n'utilisait les données en temps réel. Les tableaux de bord étaient toujours consultés à 9 heures du matin. Les rapports étaient toujours exécutés chaque semaine. Les modèles de Machine Learning étaient toujours réentraînés pendant la nuit. Ils avaient construit une voiture de Formule 1 pour aller à l'épicerie.
La conférence qui a lancé mille migrations
Voici comment cela commence généralement. Quelqu'un de l'équipe regarde une conférence — probablement à une vitesse de 2x sur YouTube — où un ingénieur de FAANG décrit leur pipeline en temps réel. Des milliards d'événements par seconde. Latence en dessous de la milliseconde. Tableaux de bord se mettant à jour comme dans Matrix.
Cet ingénieur revient au bureau inspiré. "Nous devrions faire cela." L'équipe acquiesce. Le CTO adore le mot "temps réel" dans la feuille de route trimestrielle. Un epic Jira est né.
Ce que personne ne demande : est-ce que quelqu'un dans ce bâtiment a réellement besoin de données plus rapidement qu'il ne les obtient aujourd'hui ?
Pas "ce serait bien". Pas "ça semble plus moderne". Est-ce qu'une personne spécifique, prenant une décision spécifique, obtient des résultats mesurablement pires parce que les données ont une heure de retard au lieu d'une seconde ?
Neuf fois sur dix, la réponse honnête est non. Et la seule fois où c'est oui, c'est généralement un seul pipeline — pas toute la plateforme.
La liste de courses
Avant de migrer quoi que ce soit, faites une liste. Je suis sérieux — ouvrez une feuille de calcul. Pour chaque pipeline, répondez à trois questions :
Qui consomme ces données ? Un nom. Une équipe. Un système. Si vous ne pouvez pas nommer le consommateur, le pipeline pourrait ne pas avoir besoin d'exister du tout, encore moins en temps réel.
Que font-ils avec, et quand ? Si la réponse est "ils consultent un tableau de bord chaque matin" ou "cela alimente un rapport le vendredi", le streaming ne changera pas le résultat. Vous rendez simplement la plomberie plus coûteuse pour la même eau.
Qu'est-ce qui casse si ces données ont 1 heure de retard ? 1 jour de retard ? C'est la seule question qui sépare réellement le traitement par lots du streaming. Si la réponse aux deux est "rien, vraiment", vous avez une charge de travail par lots déguisée en streaming.
La plupart des équipes découvrent que 80% de leurs pipelines sont parfaitement adaptés au traitement par lots. Les 20% restants sont là où les choses deviennent intéressantes.
Où la vitesse compte vraiment
Certaines données se gâtent réellement. Comme le lait, pas le vin.
La détection de fraude est l'exemple évident. Une transaction par carte de crédit signalée cinq minutes après coup n'est pas une détection de fraude — c'est une notification de fraude. L'argent est déjà parti. Si votre pipeline de fraude fonctionne par lots, vous écrivez des lettres d'excuses au lieu de bloquer les portes.
Notre solution de détection de fraude gère le scoring en temps réel avec une latence inférieure à 100 ms.
Les alertes opérationnelles — si votre capteur IoT vous indique qu'une turbine surchauffe, cette information a une durée de vie mesurée en secondes. Un travail par lots horaire ici n'est pas seulement lent. C'est négligent.
Les prix et les stocks sur des marchés compétitifs. Si votre concurrent met à jour les prix toutes les 30 secondes et que vous le faites toutes les 6 heures, vous ne rivalisez pas. Vous regardez.
Les flux d'événements multi-consommateurs où l'économie se compose. Un sujet Kafka alimentant trois systèmes en aval peut être moins cher que trois travaux par lots distincts tirant de la même base de données. Le streaming se justifie ici non pas par la vitesse, mais par l'élégance architecturale.
Le schéma : dans chaque cas, il y a un coût spécifique et mesurable au retard. Pas un sentiment vague. Un chiffre.
Les coûts que personne ne met dans l'epic Jira
L'infrastructure de streaming a un modèle de tarification qui semble génial sur la diapositive du fournisseur et terrible sur les résultats réels du troisième trimestre.
Elle fonctionne 24/7. Votre travail par lots fonctionne pendant 4 heures et dort. Votre travail de streaming fonctionne toute la journée, toute la nuit, les week-ends, les jours fériés. Même si le volume total de données est identique, la facture de calcul ne l'est pas. Une équipe que je connais est passée d'une configuration par lots à 2 000 $/mois à une configuration de streaming à 11 000 $/mois — traitant les mêmes données, les livrant au même endroit, consommées au même rythme.
Le débogage passe de l'archéologie à la physique quantique. Lorsqu'un travail par lots échoue, vous obtenez une trace de pile, un mauvais enregistrement, et un chemin de réexécution clair. Lorsqu'un travail de streaming produit une sortie incorrecte, il peut ne pas "échouer" du tout. Il alimente simplement silencieusement des données erronées en aval jusqu'à ce que quelqu'un remarque que le tableau de bord des revenus semble étrange trois jours plus tard.
Les changements de schéma deviennent une négociation diplomatique. En traitement par lots, vous versionnez votre code, testez sur des données historiques, et poussez. En streaming, changer un champ signifie coordonner chaque producteur et consommateur simultanément sur un système en direct. Si vous vous trompez dans l'ordre, vous déboguez une corruption de données à 2 heures du matin.
La taxe d'astreinte est réelle. Le décalage du consommateur, le déséquilibre des partitions, les basculements de courtier — ce ne sont pas des cas rares, ce sont des mardis. Si votre équipe est déjà surchargée, le streaming ne résout pas le problème. Il le multiplie.
Un cadre qui aide vraiment
Voici ce que je recommanderais. Cela prend environ deux heures avec les bonnes personnes dans la salle.
Étape 1 : Nommez les décisions. Pour chaque pipeline, identifiez la décision commerciale spécifique qu'il soutient. Pas "analytique" — la décision réelle. "Approuver ou refuser cette transaction." "Réapprovisionner ce SKU." "Alerter l'équipe de maintenance." Si vous ne pouvez pas la nommer, le traitement par lots est suffisant.
Étape 2 : Chronométrez les décisions. À quelle fréquence cette décision est-elle prise ? Chaque seconde ? Chaque heure ? Chaque lundi ? Faites correspondre la cadence du pipeline à la cadence de décision. Une livraison en dessous de la seconde pour une décision quotidienne est un gaspillage.
Étape 3 : Évaluez le retard. Quel est le coût d'un retard d'une heure, en dollars ? C'est la question la plus difficile et la plus importante. Si la réponse est "nous ne savons pas" ou "probablement rien", vous n'avez pas de cas d'utilisation pour le streaming. Vous avez un souhait de streaming.
Étape 4 : Commencez par un seul. Choisissez le pipeline avec le coût de retard le plus clair. Migrez-le. Faites-le fonctionner en parallèle avec la version par lots pour un cycle complet. Comparez. Corrigez ce qui casse. Ensuite décidez si vous devez étendre.
Les équipes qui font cela correctement finissent généralement avec 2-3 pipelines de streaming et 15 par lots. Les équipes qui sautent cette étape finissent avec 18 pipelines de streaming, une équipe d'opérations épuisée, et une migration discrète vers le traitement par lots six mois plus tard.
Ce n'est pas l'un ou l'autre
Voici ce que la plupart des fournisseurs de streaming ne vous diront pas : les meilleures architectures de données sont ennuyeuses. Elles ne sont pas toutes en streaming ou toutes par lots. Elles sont un mélange, choisi pipeline par pipeline, basé sur ce que les données doivent réellement faire.
Le traitement par lots pour les rapports. Le traitement par lots pour l'entraînement de Machine Learning. Le traitement par lots pour tout ce où "quotidien" est suffisamment rapide et où la simplicité vous fait économiser 8 000 $ par mois en frais d'opérations.
Le streaming pour la fraude. Le streaming pour les alertes opérationnelles. Le streaming pour les quelques pipelines où le retard a un coût en dollars.
C'est exactement pourquoi nous avons construit layline.io de la façon dont nous l'avons fait. Il gère à la fois le traitement par lots et le streaming sur la même plateforme — mêmes Workflows, mêmes outils, même équipe. Vous n'avez pas à choisir un monde et abandonner l'autre. Vous commencez avec ce que vous avez, ajoutez le temps réel là où il est rentable, et gardez le traitement par lots là où cela a du sens. Pas de remplacement complet. Pas de choix entre l'un ou l'autre.
Le schéma d'architecture ne gagnera pas de conférences. Mais l'équipe rentre chez elle à 17 heures et la rotation d'astreinte dort réellement la nuit.
C'est le genre d'ennui qui évolue.
Si vous évaluez quels pipelines doivent être en temps réel et lesquels sont parfaitement adaptés au traitement par lots, layline.io vous permet d'exécuter les deux sur une seule plateforme — afin que vous puissiez valider le cas commercial avant de vous engager dans l'infrastructure. Contactez-nous pour discuter de votre architecture spécifique.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère à la fois les charges de travail par lots et en temps réel à grande échelle.
