Comment Thrive Learning a doublé le rapport prix-performance des Dynamic Tables grâce à l’incrémentalisation personnalisée
Cet article a été rédigé par l’équipe de data engineering de Thrive Learning. Les opinions et expériences présentées sont les leurs.
Avant d’adopter Snowflake, Thrive exécutait son système analytique hérité à l’aide de jobs batch planifiés et de Streams de changements MongoDB, qui déclenchaient des actualisations selon un calendrier défini. Lors de sa migration vers Snowflake, l’équipe a immédiatement misé sur les Dynamic Tables pour répondre à une exigence essentielle : synchroniser et transformer en continu les données de la plateforme, dès leur modification, plutôt que de les traiter par batch avec un temps de retard.
Cette fraîcheur des données n’est pas un simple confort opérationnel : elle fait partie intégrante du produit. La suite Analyse de Thrive, qui permet aux clients d’explorer toutes leurs données de formation, est au cœur de la plateforme Thrive. Nous avons également constaté qu’une meilleure performance et des données plus fraîches renforcent directement la satisfaction client et la compétitivité de Thrive lors des appels d’offres. Les clients n’achètent pas l’analytique comme une ligne distincte, mais sa qualité détermine directement la capacité de Thrive à gagner et à conserver des contrats commerciaux. Plus récemment, ce même socle de données et de Dynamic Tables a servi de fondation au premier produit complémentaire payant de Thrive, Analyse with AI, qui ajoute une couche d’IA aux pipelines de données existants.
Dans cet article, nous expliquons comment les nouvelles fonctionnalités d’incrémentalisation personnalisée nous ont permis d’améliorer le rapport prix-performance avec les Dynamic Tables. Rob Howe, senior data engineer chez Thrive, a piloté ce projet. Il a identifié l’incrémentalisation personnalisée comme une réponse idéale à nos défis, puis a conçu, testé et déployé cette solution en production en seulement deux semaines.
Thrive Learning en bref
Thrive est une plateforme britannique d’apprentissage en entreprise (LMS/LXP) qui compte plus de 500 clients B2B dans des secteurs tels que l’industrie manufacturière, l’aviation, le commerce de détail et bien d’autres. L’équipe en charge de l’ingénierie des données et de l’IA s’appuie sur Snowflake pour exécuter sa plateforme d’analytique et ses produits d’intelligence artificielle. Elle utilise largement les Dynamic Tables pour transformer les données opérationnelles brutes en modèles de données. Ces modèles alimentent à la fois les tableaux de bord et rapports destinés aux clients, ainsi que l’assistant IA de Thrive.
La complexité de la déduplication fait grimper les coûts
RecordStore, l’un des principaux pipelines de Thrive, correspondait initialement exactement au cas d’usage pour lequel les Dynamic Tables ont été conçues : un pipeline Dynamic Tables simple, incrémental et automatiquement actualisé, sans surcoût significatif.
Les difficultés sont apparues lorsque l’équipe a dû l’enrichir avec des clés supplémentaires. Certains identifiants n’étaient pas disponibles de manière fiable en amont. Pour les retrouver, il fallait donc effectuer des jointures entre plusieurs sources, jusqu’à cinq, puis trois après optimisation. Ces jointures généraient des doublons et imposaient donc une déduplication. Face à cette complexité cumulée, Snowflake ne pouvait plus actualiser la table de manière incrémentale. Snowflake a alors basculé vers des actualisations complètes.
Pour réduire le coût des transformations, l’équipe a réparti les données entre deux flux : une « voie rapide » contenant les données récentes, actualisée toutes les six heures, et une « voie lente » contenant les données plus anciennes, actualisée chaque semaine. Cette approche a bien réduit le coût des transformations, mais l’opération UNION finale entre les deux flux a fortement accru celui de l’auto-clustering. L’équipe ne faisait que remplacer un coût par un autre. Au plus fort du problème, les coûts d’auto-clustering et de transformation de ce pipeline atteignaient plusieurs centaines de crédits par jour.
Chaque mesure corrective ne traitait qu’un symptôme. La cause véritable était le manque de fiabilité du Content ID en amont. Tant que ce problème persistait, l’équipe restait dans l’impasse.
Ajouter l’incrémentalisation personnalisée aux Dynamic Tables
L’équipe envisageait le modèle basé sur les Streams et Tasks Snowflake : traiter uniquement les lignes réellement modifiées, puis appliquer ces changements à l’aide d’une logique de fusion. Un pipeline de Streams et Tasks aurait parfaitement absorbé ce pic de complexité. Mais, comme l’ont souligné les ingénieurs de Thrive, il aurait aussi compliqué le contrôle du délai global d’actualisation dès lors que l’équipe aurait voulu proposer des données encore plus fraîches.
L’incrémentalisation personnalisée pour les Dynamic Tables (REFRESH_MODE = CUSTOM_INCREMENTAL) a permis de n’avoir aucun compromis à faire. L’équipe a écrit une logique REFRESH USING explicite, avec MERGE INTO SELF appliqué à CHANGES(). Elle a ainsi défini précisément ce que signifie « incrémental » pour ce pipeline : traiter uniquement le delta, le fusionner et ne rien modifier d’autre. Elle a obtenu le modèle d’exécution de Streams et Tasks recherché, tandis que Snowflake continuait à gérer la planification, les nouvelles tentatives, les garanties transactionnelles et le délai d’actualisation.
Deux résultats immédiats :
- Les transformations ont cessé de tout retraiter : chaque actualisation traite désormais uniquement les lignes modifiées, au lieu de relancer une actualisation complète en raison de la complexité des jointures et de la déduplication.
- L’auto-clustering a cessé de tourner inutilement : sans reconstruction complète ni opération UNION entre voies rapide et lente à maintenir, le coût du clustering est devenu presque nul.
« L’incrémentalisation personnalisée nous a permis d’obtenir le modèle d’exécution que nous recherchions, tout en laissant à Snowflake la gestion de l’ordonnancement, des nouvelles tentatives en cas d’échec et du délai d’actualisation (lag). Comme la logique est restée intégrée au DAG de dbt, le pipeline a conservé sa place dans le graphe de traçabilité des données, sans qu’il soit nécessaire de maintenir une couche d’orchestration distincte. »
Alex Tasioulis
Baisse des coûts de transformation et d’auto-clustering
| Poste de coût | Avant | Après | Réduction |
|---|---|---|---|
| Auto-clustering | ~150 crédits/jour | ~2 crédits/jour | ~99 % |
| Calcul de transformation | ~150 crédits/jour | ~5 crédits/jour | ~97 % |
À noter : Résultats basés sur les mesures internes de l’environnement de production de Thrive.
La latence d’actualisation du pipeline est également passée de plusieurs heures à quelques secondes, car chaque exécution analyse uniquement les sources qui ont réellement changé. Le pipeline évolue désormais en fonction du taux de variation des données, et non de leur volume total.
Grâce à l’incrémentalisation personnalisée, Thrive n’a plus à arbitrer entre les coûts de transformation et de clustering. L’équipe agit directement sur le comportement d’actualisation, tout en conservant une maîtrise de la latence qu’un pipeline Streams et Tasks développé sur mesure ne lui aurait pas offerte. L’équipe prévoit de réutiliser ce modèle chaque fois qu’une transformation ne peut pas être exprimée clairement sous forme de SELECT incrémental.
Une traçabilité intacte dans dbt
Pour Thrive, l’incrémentalisation personnalisée présentait un autre avantage par rapport à l’alternative fondée sur les Streams et Tasks : la gouvernance. Thrive gère ses transformations dans dbt. Pour l’équipe, savoir précisément quels modèles en alimentent d’autres est essentiel pour comprendre, tester et documenter la plateforme.
Les Streams et Tasks résident en dehors de dbt. Transférer cette logique vers un pipeline Streams et Tasks développé sur mesure aurait entièrement exclu ces objets du DAG dbt. La traçabilité aurait été rompue et l’équipe aurait dû les gérer et les surveiller dans un système distinct, en marge de la plateforme.
Les Dynamic Tables à incrémentalisation personnalisée restent des Dynamic Tables. Même si dbt ne prend pas encore en charge nativement l’incrémentalisation personnalisée, l’équipe les a intégrées à une matérialisation dbt personnalisée afin qu’elles restent des nœuds à part entière du projet dbt. Le pipeline conserve sa place dans le graphe de traçabilité et se gère avec les mêmes workflows, tests et documents que le reste, sans couche d’orchestration distincte à maintenir.
Des données moins coûteuses et plus fraîches pour les futurs cas d’usage de l’IA agentique
L’équipe applique désormais le même modèle à d’autres pipelines confrontés à une complexité similaire de jointure et de déduplication. Elle anticipe des gains comparables : des coûts réduits et des données plus fraîches dans l’ensemble de l’environnement analytique de Thrive. Au-delà des économies directes, l’IA agentique de Thrive exploite déjà ces données. En les rendant moins coûteuses et disponibles en quasi-temps réel, Thrive pourra prendre en charge encore plus de cas d’usage de l’IA agentique et dispose d’une base solide pour développer davantage les capacités d’IA de sa plateforme.
