Par Andrew Tan
L'exécution planifiée qui était autrefois suffisante
Pendant la majeure partie de la dernière décennie, le workflow analytique ressemblait à ceci :
Extraire les données de vos sources. Les charger dans un entrepôt. Écrire des modèles SQL dans dbt. Les programmer pour s'exécuter toutes les quelques heures. Construire des tableaux de bord par-dessus. Lorsque l'entreprise demande pourquoi les chiffres semblent incorrects, vous vérifiez le badge de fraîcheur et découvrez que le travail a échoué il y a six heures.
Ce n'était pas parfait, mais c'était prévisible. Le contrat entre l'analytique et l'ingénierie était clair : les modèles sont construits dans l'entrepôt, selon un calendrier, en SQL. dbt a rendu ce contrat élégant. Modèles sous contrôle de version, tests automatisés, graphiques de dépendance, documentation générée à partir du code. Pour l'analytique par lots, c'était un véritable bond en avant.
Puis l'entreprise a commencé à demander des données plus fraîches. Pas fraîches du lendemain. Pas fraîches toutes les heures. Fraîches en temps réel. Le genre de fraîcheur où un client met à jour son profil et le moteur de recommandation en est informé avant qu'il ne quitte la page.
Et soudainement, l'exécution planifiée ne suffit plus.
Pourquoi le succès de dbt a créé un écart d'exécution
L'idée centrale de dbt était de séparer la logique des modèles de l'infrastructure d'exécution. Vous écrivez le SQL. dbt gère le DAG, les tests, la documentation, la stratégie de matérialisation. Le calcul réel s'exécute où vous le pointez — Snowflake, BigQuery, Redshift, Databricks. dbt s'en fiche. C'est un compilateur et un orchestrateur pour les modèles SQL, pas un runtime.
Cette séparation était géniale pour les charges de travail par lots. Cela signifiait que les ingénieurs en analytique pouvaient posséder la logique de modélisation sans gérer les clusters, les stratégies de partitionnement ou l'optimisation de la mémoire. L'entrepôt gérait tout cela. L'ingénieur en analytique se concentrait sur la sémantique : que signifie ce modèle, comment est-il testé, qui en dépend.
Mais cette séparation suppose quelque chose d'important : que la couche d'exécution peut gérer la charge de travail que vous lui imposez. Et pour les tâches planifiées par lots contre un entrepôt moderne, c'est vrai. Pour le traitement en temps réel contre les données en streaming, ce n'est pas le cas.
L'écart n'est pas dans le SQL. Le SQL de dbt est toujours du SQL. L'écart réside dans tout ce qui se passe entre l'événement et le résultat du modèle :
- SLA de fraîcheur. Un modèle dbt s'exécutant toutes les quinze minutes est toujours en retard de quinze minutes. Dans un contexte de streaming, quinze minutes est une tâche par lots déguisée.
- Événements hors séquence. Les données en streaming arrivent en retard, dupliquées ou hors séquence. Un modèle SQL qui suppose une entrée ordonnée produit des résultats incorrects sans avertissement.
- Opérations avec état. Les fonctions de fenêtre, la sessionisation, la déduplication — celles-ci nécessitent de maintenir un état à travers les événements. Les stratégies de matérialisation de dbt (table, incrémental, éphémère) n'ont pas été conçues pour la gestion de l'état en temps d'événement.
- Jointures opérationnelles. Joindre un flux de commandes à une table de dimension changeant lentement en temps réel est un problème différent de joindre deux tables d'entrepôt sur
customer_id. La dimension peut changer en cours de requête. Le flux n'attend pas.
Ce ne sont pas des cas limites. Ce sont les caractéristiques définissant le traitement de flux. Et dbt, par conception, délègue toutes ces tâches à la couche d'exécution.
Ce que les fournisseurs vendent réellement
Si vous avez assisté à une conférence sur les données l'année dernière, vous avez vu le changement de marketing. Confluent pousse la modélisation native dbt sur Flink. Fivetran a lancé dbt Wizard avec génération de modèles assistée par IA. Snowflake a annoncé les Tables Dynamiques, BigQuery a des Vues Matérialisées, Databricks mise sur Delta Live Tables.
Le message est cohérent : vous pouvez conserver votre workflow dbt et simplement... le rendre en temps réel. Le SQL reste le même. Le DAG reste le même. La seule chose qui change est la vitesse.
C'est à peu près à moitié vrai.
Oui, vous pouvez exécuter du SQL sur des données en streaming. Flink SQL, Spark Structured Streaming, et une liste croissante de processeurs de flux prennent en charge une syntaxe SQL qui semble familière. Oui, vous pouvez mettre ces fichiers SQL sous contrôle de version et construire des DAGs. Certains outils prennent même en charge les tests et la documentation à la manière de dbt.
Ce qu'ils ne vous disent pas, c'est que l'autre moitié du problème — la moitié runtime — ne disparaît pas. Elle change simplement de forme.
Lorsque vous passez de l'exécution par lots planifiée au streaming continu, vous héritez d'un nouvel ensemble de préoccupations que dbt n'a jamais eu à résoudre :
| Hypothèse par lots | Réalité du streaming |
|---|---|
| Les données sont complètes lorsque le travail commence | Les données ne sont jamais complètes ; les arrivées tardives sont normales |
| Les échecs sont détectés à la fin de l'exécution | Les échecs doivent être détectés et gérés par événement |
| Les changements de schéma se produisent entre les exécutions | Les changements de schéma se produisent en cours de flux |
| Le retraitement signifie relancer un travail | Le retraitement signifie rembobiner un flux et rejouer |
| Le coût est proportionnel au volume de données | Le coût est proportionnel au temps de fonctionnement de l'infrastructure |
Le SQL peut sembler le même. Mais le système qui l'exécute résout un ensemble de problèmes entièrement différent.
La question de la responsabilité que personne ne veut aborder
C'est là que cela devient organisationnel. dbt a créé une frontière claire : les ingénieurs en analytique possèdent les modèles, les ingénieurs de plateforme possèdent l'entrepôt. Lorsqu'un modèle échoue, c'est généralement un problème SQL ou un problème de qualité des données. Lorsque l'entrepôt est lent, c'est un problème de plateforme. La séparation des préoccupations correspondait parfaitement à une séparation des équipes.
Le streaming brise cette frontière.
Lorsqu'un pipeline en temps réel échoue, est-ce un problème SQL ou un problème d'infrastructure ? Si les événements arrivent hors séquence, l'ingénieur en analytique réécrit-il la logique de fenêtre, ou l'ingénieur de plateforme reconfigure-t-il les paramètres de watermark du processeur de flux ? Si un événement arrivant tardivement corrompt une vue matérialisée, qui le répare — la personne qui a écrit le SQL ou la personne qui gère le checkpointing ?
J'ai vu des équipes gérer cela de trois manières, et une seule d'entre elles fonctionne :
Option 1 : Les ingénieurs en analytique apprennent le traitement de flux. Ils deviennent compétents en checkpointing, backpressure, temps d'événement vs. temps de traitement, et sémantique exactly-once. Cela fonctionne pour les petites équipes avec des personnes expérimentées. Cela ne se généralise pas.
Option 2 : Les ingénieurs de plateforme possèdent tout ce qui est en aval de Kafka. Les ingénieurs en analytique écrivent des spécifications SQL, et l'équipe de plateforme les implémente dans Flink ou Spark. Cela préserve la séparation mais crée une couche de traduction. Les spécifications SQL sont ambiguës quant au comportement en temps d'événement. L'équipe de plateforme fait des suppositions. Ces suppositions deviennent des bugs six mois plus tard.
Option 3 : Séparer la logique de modélisation de la responsabilité d'exécution. Les ingénieurs en analytique possèdent ce que signifie le modèle — la logique métier, les tests, la sémantique. Les ingénieurs de plateforme possèdent comment il s'exécute — le moteur d'exécution, le backend d'état, la récupération en cas d'échec. Les deux parties s'accordent sur un contrat : le modèle attend une entrée ordonnée dans une latence bornée, et le runtime garantit ce contrat ou affiche une erreur claire.
Cette troisième option est plus difficile à mettre en place. Elle nécessite que les deux équipes s'accordent sur les interfaces et les modes d'échec à l'avance. Mais c'est la seule qui se généralise sans transformer vos ingénieurs en analytique en spécialistes des systèmes distribués ou votre équipe de plateforme en devins.
Ce que "dbt en temps réel" exige réellement
Si votre équipe est sérieuse à propos du déplacement des modèles de style dbt dans des pipelines en temps réel, voici ce dont vous avez réellement besoin — pas ce qui est dans la présentation marketing :
Un runtime qui comprend le temps d'événement. Pas seulement le temps de traitement. Le différence entre "quand cela est arrivé" et "quand cela s'est produit" est la différence entre des résultats corrects et des résultats subtilement incorrects qui semblent corrects sur un tableau de bord.
Gestion explicite de l'état. Le fenêtrage, la déduplication et la sessionisation nécessitent tous un état. Cet état doit être checkpointé, récupérable et interrogeable pour le débogage. Si vous ne pouvez pas inspecter ce que le système pensait à 14h47 mardi dernier, vous ne pouvez pas déboguer un incident de production.
Évolution du schéma avec des dents. Ajouter une colonne est facile. Gérer un changement de type, un renommage ou un changement sémantique dans la signification d'une colonne est difficile. Votre pipeline doit détecter ces changements, décider s'ils sont sûrs, et soit s'adapter, soit s'arrêter avec une erreur claire.
Relecture et remplissage en tant qu'opérations de première classe. En batch, le retraitement consiste à relancer un travail. En streaming, c'est rembobiner un journal et rejouer les événements à travers la même logique. Si votre pipeline en temps réel ne peut pas rejouer exactement, vous ne pouvez pas récupérer des bugs, vous ne pouvez pas tester les changements contre des données historiques, et vous ne pouvez pas prouver la conformité.
Visibilité des coûts par charge de travail. Les coûts par lots sont faciles à raisonner : ce travail a traité autant de données et a pris autant de temps. Les coûts de streaming sont continus : le travail est toujours en cours, consommant toujours des ressources, et le coût ne corrèle pas clairement avec la sortie commerciale. Vous avez besoin de télémétrie qui relie les dépenses d'infrastructure au comportement du pipeline.
Aucune de ces fonctionnalités n'est une fonctionnalité SQL. Ce sont des fonctionnalités runtime. Et elles font la différence entre une démo qui fonctionne pendant dix minutes et un système qui fonctionne pendant dix mois.
Le pitch honnête
dbt a changé la façon dont les équipes analytiques travaillent. Il a apporté des pratiques d'ingénierie logicielle — contrôle de version, tests, documentation — à une discipline qui en avait grandement besoin. Cette contribution est réelle et durable.
Mais dbt a été conçu pour un monde où les données se déplacent par lots, les entrepôts sont le centre de gravité, et "frais" signifie "mis à jour cette heure-ci". L'industrie se dirige vers un monde où les données se déplacent en continu, les modèles sont appliqués en vol, et "frais" signifie "mis à jour cette milliseconde".
Cela ne rend pas dbt obsolète. Cela rend dbt incomplet pour un ensemble croissant de cas d'utilisation.
Les fournisseurs vendant "dbt en temps réel" répondent à une demande réelle. Mais ce qu'ils vendent est généralement une interface SQL sur un processeur de flux, pas une solution aux problèmes runtime que le traitement de flux introduit. Le SQL est la partie facile. La gestion de l'état, la récupération en cas d'échec, l'évolution du schéma et l'observabilité opérationnelle sont les parties difficiles. Et ces parties difficiles ne disparaissent pas simplement parce que le SQL semble familier.
Si vous évaluez l'un de ces outils, ne demandez pas "Peut-il exécuter mes modèles dbt plus rapidement ?" Demandez "Que se passe-t-il lorsqu'un nœud redémarre en milieu de fenêtre ?" "Comment puis-je rejouer les données de mardi dernier à travers un modèle que j'ai changé hier ?" "Que fait le système lorsque le schéma change à 2h du matin ?"
Les réponses à ces questions vous diront si vous achetez un outil par lots plus rapide ou un véritable runtime de streaming.
Où nous nous situons
Chez layline.io, nous avons construit un runtime qui gère à la fois le batch et le streaming dans le même pipeline. Pas deux systèmes séparés avec une façade SQL sur chacun. Un système où la même équipe peut construire des chargements d'entrepôt programmés et un traitement d'événements en temps réel sans changer d'outils, de contextes ou de modèles mentaux.
Les ingénieurs en analytique conservent la propriété des sémantiques des modèles. L'équipe de plateforme conserve la propriété de l'infrastructure d'exécution. Mais les deux parties travaillent dans le même environnement, avec la même observabilité, et les mêmes garanties autour de la relecture, de la récupération de l'état et de l'évolution du schéma.
dbt a enseigné à l'industrie que la logique de modélisation mérite de la rigueur. Nous construisons sur cette idée — et ajoutons la rigueur runtime que les données en temps réel exigent.
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.
