Solutions aux défis des outils ETL
Votre outil d'ingestion sait déplacer des lignes. C'est sur la facture, le schéma et l'historique que les frictions commencent. Un article par symptôme, par outil, écrit pour l'ingénieur qui a la charge du pipeline.
Chaque plateforme d’ingestion de cette liste fait une chose très bien : elle extrait des lignes d’un système source et les dépose dans votre entrepôt de données avec très peu de configuration. Cette commodité est réelle, et c’est pour cela que tant d’équipes commencent par là.
Les frictions arrivent plus tard. La facture qui double après une mise à jour en masse, le schéma cible figé qu’il faut remodeler à la main avant que quiconque puisse l’utiliser, l’historique jamais conservé parce que le connecteur ne fait que refléter l’état courant. Rien de tout cela n’est un bug du connecteur. C’est ce qui arrive quand l’outil qui déplace les données est aussi censé assumer leur coût, leur structure et leur passé.
Cette série traite un symptôme à la fois, explique d’où il vient et montre ce qui change quand un entrepôt piloté par le modèle retire ces trois responsabilités au connecteur.
-
dbt
Le compromis dbt : prolifération du code, TCO caché et les arguments en faveur de la modélisation automatisée
dbt a apporté le génie logiciel au SQL, et les équipes ont raison de le vouloir. Le compromis est une couche de transformation qui s'alourdit en code, en coût et en calcul, au-dessus d'un outil d'ingestion qui reste un produit séparé. Un Data Vault généré retire toute cette couche de la base de code. Il n'a pas besoin de dbt, mais il peut se combiner avec lui.
Lire la suite → -
Azure Data Factory
Les limites d'Azure Data Factory : le coût caché des pipelines assemblés à la main et des transformations Spark
Azure Data Factory est une bonne couche de transport dans Azure et un mauvais endroit où loger un entrepôt de données. Utilisé comme suite de modélisation et de transformation, il apporte un canvas que personne ne sait lire, des releases qui échouent sur les templates ARM et des clusters Spark pour des chargements qui tiennent en une instruction SQL. Et chacun de ces pipelines n'existe que dans Azure.
Lire la suite → -
dbt
dbt vous laisse-t-il encore charger les données vous-même ?
dbt est un outil de transformation par conception. Il suppose que les données brutes sont déjà dans l'entrepôt, donc l'étape de chargement est un second produit avec une seconde facture, même maintenant que Fivetran et dbt Labs sont une seule entreprise. Une plateforme d'entrepôt qui ingère et modélise au même endroit comble la lacune sans second contrat.
Lire la suite → -
SSIS
Les limites de SSIS : porter les packages dans le cloud déplace la dette, pas le problème
Les parcs SSIS ont trois problèmes qu'une VM dans le cloud ne résout pas : un package par table que personne ne veut ouvrir, des releases que le DevOps n'atteint pas, et une conception qui s'arrête à SQL Server. L'Azure-SSIS Integration Runtime emmène les trois dans Azure intacts. Un modèle qui génère l'entrepôt les supprime à la place.
Lire la suite → -
dbt
Vos exécutions dbt font-elles discrètement grimper les coûts de calcul de l'entrepôt ?
dbt exécute tout dans l'entrepôt, donc un full refresh là où un chargement incrémental suffirait, ou une matérialisation en table qui se reconstruit chaque nuit, se traduit par des coûts de calcul, pas par une erreur. La logique incrémentale est optionnelle dans dbt. Dans un Data Vault généré, c'est la seule façon dont les chargements sont écrits.
Lire la suite → -
Azure Data Factory
Les Mapping Data Flows d'Azure Data Factory coûtent-ils plus cher que les données qu'ils déplacent ?
Les Mapping Data Flows tournent sur un cluster Spark managé qui met plusieurs minutes à démarrer et se facture à l'heure de vCore. Pour une grosse transformation nocturne, c'est un choix raisonnable. Pour quelques centaines de milliers de lignes, c'est un cluster démarré pour faire ce qu'une seule instruction SQL ferait à l'intérieur de l'entrepôt.
Lire la suite → -
dbt
Votre projet dbt compte-t-il plus de modèles que quiconque ne peut expliquer ?
ref() fait d'un nouveau modèle une décision d'une ligne, et un projet de centaines de fichiers SQL sans gouvernance claire en est le résultat. Changer une clé métier en amont revient alors à retrouver chaque modèle qui en a hérité. La solution ne consiste pas à ajouter des tests. C'est un modèle qui génère la structure au lieu de l'accumuler.
Lire la suite → -
SSIS
SSIS s'arrête-t-il là où commence votre entrepôt dans le cloud ?
SSIS a été conçu pour déplacer des données entre instances SQL Server on premises. Quand l'entrepôt part vers Fabric, Snowflake, Databricks ou BigQuery, les options sont de porter les packages sur un Azure-SSIS Integration Runtime, d'acheter des connecteurs tiers, ou de réécrire. Un modèle qui génère nativement pour la nouvelle plateforme est la quatrième option, et la seule qui n'emmène pas les packages avec elle.
Lire la suite → -
dbt
Votre facture dbt augmente-t-elle en licences, ou en ingénieurs ?
dbt Core est gratuit en licence et coûteux en exploitation. dbt Cloud est facile à exploiter et tarifé par développeur, plus l'usage. Dans les deux cas, la couche de transformation a un coût qui augmente avec la taille de l'équipe, et aucune des deux voies n'a été choisie pour cette raison.
Lire la suite → -
Azure Data Factory
Chaque release Azure Data Factory tourne-t-elle à la bataille de templates ARM ?
Sous l'éditeur visuel, une Azure Data Factory est du JSON : pipelines, datasets, linked services et le template ARM qui les déploie. Faire passer un changement de Dev à Prod implique des fichiers de paramètres, des paramètres globaux et un template qui échoue sur une seule incohérence de type. Les releases devraient être générées à partir d'un modèle, rollback inclus.
Lire la suite → -
Fivetran
Coûts et schémas Fivetran qui vous échappent ? Comment la modélisation automatisée supprime les points de friction de l'ingestion
L'ELT plug and play est rapide à démarrer et lent à contrôler. Deux choses s'érodent avec le temps : ce que le pipeline coûte, et qui décide de la structure des données. Une couche Data Vault automatisée vous rend les deux sans renoncer aux connecteurs qui fonctionnent.
Lire la suite → -
SSIS
SSIS est-il la seule partie de votre stack encore incapable de faire du CI/CD ?
Un fichier .dtsx est du XML qui se compare mal et se merge encore plus mal, si bien que deux ingénieurs sur un même package finissent par tout refaire. Les environnements résident dans des mappings de variables SSISDB maintenus à la main. Le DevOps moderne s'arrête au projet SSIS. Les releases devraient être générées à partir d'un modèle, par environnement, rollback inclus.
Lire la suite → -
Fivetran
Votre schéma Fivetran vous oblige-t-il à reconstruire le modèle après chaque chargement ?
Fivetran dépose chaque source dans son propre schéma standardisé. Les clés métier, les champs personnalisés et les structures héritées doivent ensuite être remodelés en SQL, un SQL qui casse quand le connecteur change. La solution n'est pas un meilleur script. C'est un modèle qui définit lui-même la structure.
Lire la suite → -
Azure Data Factory
Votre canvas Azure Data Factory est-il devenu trop grand pour ceux qui l'ont construit ?
Un pipeline en glisser-déposer est rapide à construire et lent à changer. Au-delà de quelques dizaines d'activités, le canvas devient la documentation, le câblage prend le pas sur la logique, et chaque nouvelle source est une copy activity de plus que personne ne veut toucher. La solution n'est pas un canvas plus ordonné. C'est un modèle qui génère les pipelines.
Lire la suite → -
Fivetran
Votre facture Fivetran bondit-elle chaque fois qu'une table source devient très active ?
Fivetran facture en fonction des Monthly Active Rows. Une mise à jour en masse ou une migration de schéma en amont touche à nouveau chaque ligne, et la facture suit. Les lignes n'ont jamais été le problème. Le problème, c'est de payer par ligne pour des données que vous retraitez ensuite vous-même.
Lire la suite → -
SSIS
Vos packages SSIS sont-ils plus nombreux que les gens capables de les comprendre ?
Des centaines de packages .dtsx, un par table, construits dans Visual Studio par celui qui avait le ticket, avec des control flows et des data flows qui ne s'ouvrent qu'un à la fois. Ajouter une colonne revient à ouvrir les packages un par un. La solution n'est pas un modèle de package. C'est un modèle qui génère les chargements, nativement sur SQL Server, Azure SQL ou Fabric.
Lire la suite →
Rien ici pour l'instant.