Les nouveaux data pipelines Cloud : les principes de l'ELT et beaucoup de SQL !

 

Les nouveaux data pipelines Cloud :   Les principes de l'ELT et beaucoup de SQL ! Pendant des années, les ETL comme BODS, DataStage, Informatica, Ab Initio ou encore Talend ont fait la pluie et le beau temps dans le domaine de la construction de data pipelines.  Il y avait alors une fenêtre d’opportunité : Les contraintes matérielles et les performances limitées des Data Warehouse "on-premises " suggéraient qu'on déporte les transformations sur des serveurs tiers, d'où un moindre succès des ELT (on pense à Oracle Data Integrator, ODI).  Les entreprises souhaitaient démocratiser la création des data pipelines avec des outils orientés métier. Mais les architectures Cloud ont changé la donne, notamment en raison de la puissance des Data Warehouse Cloud. Assiste-t-on à  une renaissance massive, mais "boostée" au SQL, des principes qui étaient à l'œuvre dans les ELT ? Si oui, comment s'inscrire dans cette dynamique ? Pourquoi les entreprises abandonnent la logique ETL dans le Cloud ?   Les ETL historiques ont révolutionné le monde des données, mais leur conception repose sur des paradigmes qui présentent désormais des limites : L'optimisation des chaînes ETL, la parallélisation des process n'est pas forcément très simple, intuitive et dépend essentiellement de l'outil.  Les workflows que l’on dessine fonctionnent bien avec des systèmes relativement "statiques ". Or, à l’ère de l'entreprise "data-driven", les systèmes sont inflationnistes.  Les spécialistes de tel ou tel ETL se font rares (et c'est pareil pour le ELT), ce qui est problématique pour la maintenance ! D’autant que tout le monde y a été de son « tuning » dans les ETL, avec d’innombrables imbrications qui créent de l’opacité. Aller vers nouveaux outils de data pipeline : allier la puissance et le SQL  ! La puissance à bas prix     Les transformations se font au sein du Data Warehouse comme avec les anciens ELT, mais cette fois ci dans le Cloud : les performances natives des DWH Cloud (BigQuery, Snowflake, Redshift) sont quasi illimitées, ce qui booste les performances de ces outils (Matillion, dbt, Airbyte, Fivetran, etc.).  Ces outils de data pipeline sont plus accessibles en termes de coûts : ils s’appuient souvent sur des modules open source (on pense à dbt).  Le SQL comme pivot technique   Les transformations SQL encapsulées dans ces outils de data pipelines sont ouvertes, modularisées et prévues pour collaborer : versioning, modèles réemployables, etc.   Le SQL (ou ses dialectes), qui constitue le socle technique de ces outils de data pipeline, est maîtrisé par l’essentiel des équipes informatiques, ce qui en temps de pénurie de " talents " n’est pas neutre ! Migrer ses jobs ETL vers un outils de data pipeline Cloud, « challenging » ?   Par exemple, imaginez une entreprise (comme nous en connaissons) qui a accumulé plus de 10.000 jobs ETL, construits sur plusieurs années avec des transformations complexes comme des jointures, des agrégations ou encore des règles métiers spécifiques... Migrer ses jobs ETL vers un outil de data pipeline Cloud nécessite une refonte complète de leur exécution, notamment lorsqu’il s’agit d’adopter une approche SQL.   L’automatisation s’impose. 80 % de l’effort = reprendre le contrôle sur son système en place. Comment ? Opérer un inventaire exhaustif et automatisé du système source avec {openAudit}   Par une analyse des processus internes via un data lineage physique, au champ, dans la base de données en source, dans l’ETL : analyse des vues, des vues imbriquées et des autres scripts associés à l'alimentation des flux. Par une analyse des usages de l’information, via une analyse des logs des bases d’audit, pour la consommation et l’injection des données. Par une analyse des impacts dans les outils de data visualisation qui sont associés à la base de données en source, pour entrevoir la complexité afférente (règles de calcul) et pour pouvoir faire du data lineage réellement de bout en bout. Par une analyse de l’ordonnancement des tâches, afin de le lier au data lineage et aux usages des données. Optimiser le scope de ce qu’il y a à migrer en croisant les usages avec le data lineage avec {openAudit}    Pour réduire l’effort de migration en identifiant les branches vivantes et les branches mortes à décommissionner en amont. Pour définir une roadmap par métier, par type de flux, etc.   La migration : passer par le SQL, forcément ! Conversion des logiques de l’ETL en source, en SQL, avec {openAudit}   Ordonnancement des transformations élémentaires : {openAudit} détecte les sources, les cibles, les filtres et les logiques de transformation de l’ensemble des jobs et sous-jobs de l’ETL en source, et isole les transformations qui seront portées dans l'outil en cible. Conversion en SQL : ces transformations de l’ETL sont converties en requêtes SQL par {openAudit}, étape par étape. Points de contrôle : chaque étape SQL correspond à une étape du job en source, ce qui permet à {openAudit} d’introduire de vrais points de contrôle (ce qui n’existe pas dans les ETL). Conversion des logiques ETL vers la logique de l'outil de data pipeline dans des modèles ouverts avec {openAudit} et tests:   Les transformations SQL sont directement intégrées dans des modèles de l'outil cible.   Le SQL généré peut être ajusté par {openAudit} pour s’adapter à la syntaxe cible. Puis, ajout des modèles dans la configuration des projets, définition des dépendances entre modèles, etc. Les modèles sont testés pour vérifier leur fonctionnement. Les données peuvent être testées pour garantir leur intégrité. CONCLUSION   L’abandon des ETL historiques n’est pas seulement une question de modernisation technique. C’est une opportunité stratégique pour les entreprises de repenser leurs pipelines de données, en les rendant plus performants, scalables et économiques (modèle open source). Les outils de data pipelines modernes, plus ouverts, associés aux DWH Cloud puissants, incarnent cette nouvelle ère. En adoptant ces principes, les entreprises peuvent s’appuyer sur des architectures allégées, mais robustes. La transition peut sembler complexe, mais avec les bonnes stratégies et les bons outils, il est possible de tourner la page et de construire les pipelines de données du futur.