Sicara devient Theodo Data & AI ! Nous sommes ravis de vous annoncer que Sicara évolue pour devenir l’entité Data & AI de Theodo.
Adopt
12Airflow
Gérer des flux de données fait partie des tâches du data engineer, notamment la préparation de données ou le lancement de constructions de modèles. Or, cette gestion est devenue complexe, montrant les limites des outils classiques d’orchestration comme CRON. En 2014, Airbnb a créé Airflow en réponse à cette complexité croissante. Airflow est un outil open-source en Python qui est aujourd'hui le standard du marché pour l’orchestration de tâches. Il permet la création, le déploiement et le suivi de workflows.
Airflow modélise les flux de données sous forme de graphe de tâches. Un ordonnanceur planifie l'exécution des tâches en fonction de leurs dépendances, et les Sensors permettent de conditionner le lancement d’une tâche à un événement. Une interface web offre une vue d'ensemble des graphes. La notion de tâche ne présuppose rien sur les traitements effectués à l’intérieur, ce qui laisse une grande flexibilité quant aux cas d’utilisation d’Airflow. C’est donc un outil complet, utilisable pour presque n’importe quel contexte d’automatisation des processus de traitement des données, ce qui explique son adoption massive aujourd’hui. De plus, certains services Cloud proposent une version managée, telle que Google Cloud Composer, afin de faciliter le déploiement des workflows.
Airflow souffre toutefois d’une documentation difficile à utiliser et souvent peu fournie, même si cet inconvénient est tempéré par la grande taille de sa communauté. Aussi, communiquer de la donnée temporaire entre deux tâches est impossible à réaliser nativement sur Airflow : il faut alors utiliser un service de sauvegarde de données externe. C’est l’une des différences conceptuelles clés entre Airflow (où chaque nœud du DAG de traitement est une opération) et une alternative comme Dagster (où chaque nœud représente un état de la donnée).
Le point de vue Theodo
Aujourd'hui, nous recommandons Airflow pour une orchestration de tâches hétérogènes. En effet, la grande taille de sa communauté permet de trouver une réponse à la plupart des questions qu’une équipe peut se poser, et sa flexibilité permet de répondre à quasiment n’importe quel cas d’usage.
Le point de vue MDN
Airflow est une solution d'orchestration puissante et flexible, avec une communauté active et des mises à jour régulières. Airflow est très évolutif, mais pour des équipes peu techniques ou des besoins simples, d'autres options peuvent mieux convenir. Son adoption exige une bonne maîtrise de Python, des concepts propres comme les Hooks et Operators, ainsi que des bases en programmation fonctionnelle.
13Dataflow
14dbt with unit testing
Avec la montée en puissance des pipelines de données, garantir la qualité des transformations est essentiel. dbt (Data Build Tool) offre une solution robuste pour automatiser les bonnes pratiques de développement SQL grâce à son système de tests unitaires permettant de valider les transformations tout en minimisant les erreurs en production. dbt est une plateforme open source pour la transformation de données dans les pipelines ETL/ELT. Elle propose deux versions : dbt Core (gratuit, utilisable en ligne de commande) et dbt Cloud (version payante avec des fonctionnalités avancées, comme un IDE intégré). dbt se connecte aux principales plateformes de données comme BigQuery, Snowflake, Redshift ou Databricks via des adaptateurs.
Son point fort réside dans la gestion des dépendances entre tables (via la déclaration de références et de sources), le refactoring via macros et l’intégration de la documentation. dbt permet aussi de définir des tests unitaires qui aident à valider le bon fonctionnement des requêtes SQL classiques. Grâce à cette fonctionnalité, il est possible de simuler des données avec des fichiers CSV, les seeds, et de comparer les résultats des transformations aux attentes. Cela permet de mettre en place et de maintenir dans la durée les bonnes pratiques de développement au cœur des requêtes SQL. C’est un facteur différenciant important par rapport à d’autres solutions comme Google DataFlow ou AWS Data Pipeline.
Toutefois, la création de ces tests unitaires vient avec quelques bémols à garder en tête :
- Multiplication des fichiers mock (CSV) pour assurer une couverture complète.
- Nécessité de maintenir la cohérence entre les tables mockées (IDs, relations entre tables).
- Gestion complexe des cas de test pour les opérations complexes (jointures, group by).
Le point de vue Theodo
Nous recommandons dbt pour des pipelines robustes et maintenables, grâce aux tests unitaires qui soutiennent le développement continu et limitent l'apparition de code legacy. Cependant, pour des traitements massifs ou des cas très spécifiques, des outils comme Apache Spark ou DataFlow peuvent être plus adaptés, bien que dbt se distingue par ses bonnes pratiques.
15Dremio
Dremio est un moteur d’exécution SQL innovant conçu pour optimiser la gestion des données en permettant aux organisations de tirer parti de leurs data lakes et autres sources de données.
Côté technique, Dremio optimise l'accès et l'analyse des données directement à partir de diverses sources en proposant une couche de virtualisation qui permet aux utilisateurs de requêter les données sans avoir besoin de les déplacer, tout en offrant la possibilité de combiner des sources provenant de différents environnements de production. Il se concentre sur l'accélération des requêtes sur les data lakes grâce à l'utilisation de technologies telles qu'Apache Arrow, ce qui améliore considérablement les performances et permet d'exécuter des requêtes sur des tables contenant des millions de lignes en moins d'une seconde.
De plus, Dremio intègre un catalogue de données doté de fonctionnalités de sécurité au niveau des lignes, permet de créer un wiki et de suivre le lineage des données. Enfin, Dremio offre la possibilité de créer des vues virtuelles personnalisables pour chaque utilisateur. Ces vues peuvent être mises en cache pour accélérer le traitement des requêtes.
Côté métier, Dremio permet d'effectuer de nombreuses actions via une interface graphique intuitive, sans recourir au SQL : ajout de colonnes via des règles métiers, agrégations, jointures et filtres de colonnes.
Le point de vue MDN
Si vous recherchez un outil qui vous permet de virtualiser les données sans impacter la source, tout en adoptant une approche orientée métier, Dremio est la solution idéale.
16Kestra
Automatiser et orchestrer des pipelines de données peut vite devenir complexe, surtout avec des outils traditionnels. Kestra est une solution open-source moderne qui simplifie ce processus et apporte flexibilité et scalabilité. La configuration des workflows dans Kestra se fait via des fichiers YAML, facilitant la définition des tâches, des dépendances et des conditions. L’absence de code complexe rend l’orchestration accessible à tous et permet de mutualiser un outil entre les équipes de développeurs et de data.
Kestra se distingue par son système de plus de 500 plugins qui permet d’étendre les capacités de la plateforme. On peut facilement intégrer des bases de données, interagir avec des services cloud tels que AWS S3, ou même lancer des commandes bash. L’outil permet le déclenchement de workflows en réponse à des événements : fichier déposé, modification dans une base de données, ou notification d’API, ce qui le rend idéal pour du temps réel. Grâce à son architecture distribuée, Kestra permet de gérer des milliers de tâches simultanément. Si votre volume de données explose, Kestra suit le rythme sans compromettre les performances.
L'outil offre également une interface claire et moderne pour surveiller l’exécution des workflows en temps réel : vous savez exactement où ça coince et pouvez redémarrer des tâches individuelles sans relancer tout un pipeline. Il est également possible d’utiliser l’API, et même de déployer l'outil via un simple docker-compose. Cependant, l'outil est encore jeune et l'écosystème pas encore très mature, mais les releases sont fréquentes.
Le point de vue MDN
À utiliser, ou en tout cas tester. Kestra est un très bon outil pour mutualiser l'utilisation avec plusieurs pôles au sein d'une entreprise sans avoir de dépendance à un langage particulier. Il se prend en main plus facilement qu'Airflow et permet d'exécuter tout type de code - même SQL - au travers de ses workflows.
17Lambda / Cloud Run Functions
AWS Lambda et Google Cloud Run Functions sont des services de serverless computing permettant d'exécuter du code en réponse à des événements, sans avoir à provisionner d'infrastructure sous-jacente. Ces solutions permettent aux développeurs de se concentrer sur la logique métier plutôt que sur la gestion des serveurs. Ces fonctions sont idéales pour les pipelines de transformation de données, en particulier lorsque les charges de travail sont intermittentes ou imprévisibles. Elles sont invoquées automatiquement en réponse à des événements tels que des requêtes HTTP, des modifications de bases de données ou des uploads de fichiers dans un stockage cloud.
L’un des principaux avantages des fonctions Lambda et Cloud Run Functions est leur tarification à la demande, facturant uniquement le temps d'exécution, ce qui réduit les coûts d'infrastructure. De plus, ces services offrent une grande scalabilité automatique, ajustant les ressources en fonction de la demande sans intervention manuelle. Ils simplifient également la maintenance grâce à des intégrations avec des outils de monitoring et logging pour surveiller les performances en temps réel et résoudre les problèmes de manière proactive.
Cependant, ces fonctions présentent quelques contraintes. Elles sont souvent limitées à quelques minutes d'exécution et peuvent rencontrer des difficultés à traiter des volumes de données importants en une seule exécution. De plus, le conteneur temporaire utilisé pour exécuter les fonctions entraîne des problèmes de latence dus au temps de démarrage.
Le point de vue Theodo
Chez Theodo, nous utilisons AWS Lambda et Google Cloud Run Functions pour exécuter des pipelines de transformation de données de manière efficace et scalable. Nous recommandons ces technologies pour des courtes tâches, autonomes et réactives, nécessitant une exécution à la demande et une gestion optimisée des coûts.
18Medaillon architecture
La medallion architecture est un framework introduit par Databricks pour structurer les flux de données dans les Data Lakes et mieux séparer les cycles de qualité de donnée. Cette structure consiste en trois couches successives de transformations :
- Bronze, pour l’ingestion des données brutes ;
- Silver, pour le nettoyage des données et leur mise en conformité ;
- Gold, pour l’agrégation et les transformations métier. Ce concept simple permet d’améliorer significativement la qualité d’une série de transformations de données, que ce soit dans une plateforme data ou dans un gros fichier Excel.
En garantissant le découplage des données brutes (bronze) et des données consommées (gold), elle permet de maintenir une forte évolutivité des flux de données. L’architecture en médaillon incite à limiter les responsabilités de chaque table, ce qui facilite la compréhension et la modification des règles de calcul, ou même la migration d’une source de données vers une autre.
Toutefois, dans une architecture en médaillon, la donnée est souvent dupliquée (donnée brute, nettoyée, filtrée…), ce qui peut engendrer des coûts non négligeables pour des organisations stockant des volumes de données déjà élevés. Certains flux peuvent être moins optimisés que s’ils se faisaient en une seule étape, et l’augmentation du nombre de tables et de dépendances peut rallonger les durées des workflows. On notera que ces coûts sont en général largement compensés par le gain en temps de main-d’œuvre.
Finalement, ce framework est devenu un standard de l’industrie, au même titre que le modèle staging / intermédiaire / datamart poussé par dbt.
Le point de vue Theodo
Nous recommandons chaudement l’utilisation de l’architecture en médaillon sur vos projets data, afin de garantir leur évolutivité et faciliter la collaboration. Chez Theodo, nous adaptons également ce framework en re-découpant chaque couche en plusieurs niveaux de qualité pour en tirer encore plus de bénéfices.
19Synapse
Azure Synapse Analytics est la plateforme analytique intégrée de Microsoft, qui vise à unifier l'analyse des données et le traitement des big data. Son interface épurée permet une prise en main rapide et facilite la gestion des données et des processus analytiques. Son intégration fluide avec les outils Microsoft comme Power BI facilite la visualisation des données.
Synapse offre des notebooks supportant PySpark, SQL et d’autres langages, permettant l’analyse de données complexes et une collaboration au sein d’une même interface. Le système d'orchestration intègre facilement ces notebooks et autres tâches, accélérant ainsi l'industrialisation et simplifiant la gestion des pipelines. La mise en place de triggers permet d’automatiser les tâches et les processus.
Synapse combine les capacités d’un datawarehouse traditionnel avec celles des systèmes de traitement de big data, permettant de stocker et d’analyser de vastes volumes de données structurées ou non structurées, tout en offrant des capacités d’analyse en temps réel et de traitement par batch. Il inclut également des fonctionnalités avancées de sécurité et de gestion des accès, garantissant la protection et la restriction des données aux personnes autorisées.
Synapse se démarque par sa scalabilité et son rapport coût-efficacité. Il permet de gérer des charges de travail croissantes sans compromettre les performances, et son modèle de tarification flexible offre une solution économique pour les entreprises cherchant à maximiser leur ROI dans l'analyse des données.
Le point de vue MDN
Azure Synapse Analytics est une solution puissante et complète pour les entreprises cherchant à unifier leurs efforts d'analyse de données, de traitement de big data et de création de pipelines. Elle est particulièrement recommandée si vous êtes dans l’écosystème Microsoft, avec lequel elle offre une forte intégration.
Trial
20Lambda architecture
Une architecture de données définit la manière dont les données sont collectées, transformées, stockées et exposées pour répondre aux divers besoins des entreprises, qu'ils soient à court ou à long terme, tout en respectant les exigences de gouvernance. Choisir la bonne architecture est essentiel pour répondre aux impératifs de haute disponibilité, de persistance, de stockage optimisé et de traitement efficace de volumes de données variés.
L'architecture Lambda est hybride, divisée en deux flux pour traiter les données en temps réel et par lots (batch).
- La Batch Layer se charge du traitement de gros volumes de données à intervalles réguliers. Elle assure une cohérence maximale et permet un accès fiable et durable aux données.
- La Speed Layer, quant à elle, traite les données en temps réel, garantissant une haute disponibilité avec un compromis sur la précision. La Batch Layer intervient pour consolider et corriger les données si nécessaire.
Chez nos clients, l'architecture Lambda a permis de fournir un accès en temps réel aux informations, tout en assurant une mise à jour quotidienne des données. Cette architecture répond aux besoins de gouvernance, de déduplication et de purge des données.
Le point de vue Theodo
Nous recommandons l’architecture de données Lambda lorsque des exigences de haute disponibilité et de traitement quotidien doivent être combinées. Sa mise en place représente un travail important et engendre des coûts de maintenance à considérer : il est crucial de s’assurer que le besoin est à la hauteur de l’investissement !
21Dagster
La gestion des flux de données est une tâche essentielle. Pour répondre à ce besoin, Elementl a introduit en 2018 Dagster, un outil innovant conçu pour orchestrer et superviser efficacement les pipelines de données. Dagster est une librairie Python open-source de gestion et d’orchestration de flux de données, conçue pour faciliter le développement, le déploiement et la surveillance de pipelines. Comme Airflow, son concurrent plus ancien de quatre ans, Dagster modélise les flux de données sous forme de graphe orienté acyclique (DAG). Cependant, alors qu’Airflow construit un graph où les nœuds représentent des opérations, Dagster construit un graphe où les nœuds représentent l’état de la donnée et les arcs les opérations. Ces nœuds sont appelés Assets.
Dagster permet de déclencher ces opérations selon plusieurs critères : une fréquence d'intervalle, un événement déclencheur (par exemple, l'arrivée d'un nouveau fichier dans un bucket), ou une demande explicite de l'utilisateur (via CLI ou l'interface web). Il offre également une interface web intuitive permettant de visualiser les flux de données, leur état, les exécutions et de nombreuses autres informations essentielles.
Côté écosystème et intégration, Dagster dispose aujourd'hui de connecteurs avec la plupart des librairies courantes (Snowflake, PostgreSQL, dbt, etc.) et peut être déployé sur Docker, Kubernetes, AWS, GCP, entre autres. Dagster semble apporter des solutions à plusieurs problèmes auxquels Airflow ne répond pas. Tout d'abord, il permet de passer facilement des données entre les opérations. Ensuite, il offre un environnement de test facile à mettre en place. Enfin, Dagster inclut un type-checking à l'exécution, garantissant ainsi la cohérence des données.
Airflow bénéficie d'une communauté plus vaste, avec davantage de ressources, tutoriels et exemples disponibles, ce qui peut rendre la transition vers Dagster complexe pour les utilisateurs habitués aux orchestrateurs traditionnels. L’approche orientée donnée de Dagster peut également rendre plus difficiles à visualiser les tâches qui ne produisent pas d’état de données dans l’interface utilisateur.
Le point de vue Theodo
Aujourd’hui, nous recommandons de préférer Airflow à Dagster pour une orchestration de tâches complexes. Cependant, pour des orchestrations plus simples et où l’approche orientée données (et non tâches) a du sens, Dagster offre une UI agréable, une implémentation rapide, et peut être une bonne option à tester.
Le point de vue MDN
Dagster change le paradigme des orchestrateurs en mettant les Assets au centre plutôt que les opérations et DAGs de transformations. L’interface moderne contient tous les éléments essentiels à la gestion d’une plateforme de données. J’apprécie énormément Dagster pour son UI extrêmement agréable et son intégration de premier niveau avec dbt.
22Popsink
Popsink est un outil ELT de nouvelle génération qui adopte une approche “CDC-first” (Change Data Capture), optimisée pour le temps réel. Cette solution s’aligne sur les principaux acteurs du marché en offrant une gestion flexible des sources de données (bases transactionnelles, outils SaaS, data warehouses…) et une intégration simplifiée vers diverses destinations, au-delà des data warehouses traditionnels comme BigQuery et Snowflake.
Parmi les atouts distinctifs de Popsink, on retrouve des fonctionnalités de capture incrémentale, une gestion évolutive des schémas sans breaking changes et des coûts extrêmement compétitifs. En effet, le traitement en temps réel consomme moins de ressources que les traitements par batch ou les rafraîchissements complets périodiques.
Le point de vue Theodo
Le temps réel reste un défi pour les équipes et plateformes data. Popsink est une alternative plug-and-play face aux technologies à forte maintenance ou aux SaaS onéreux. Si vos besoins correspondent aux connecteurs disponibles, n’hésitez pas à tester l’outil. Et en plus, c’est 100 % français. Pour nous, Popsink est déjà un outil indispensable, notamment pour les migrations du legacy vers le cloud.
23SSIS
Les solutions d'intégration de données traditionnelles comme SSIS, Talend et Informatica représentent des piliers de l’approche ETL, avec des déploiements importants dans les systèmes d’information de nombreuses organisations. Leur structure permet une extraction et transformation précises des données avant chargement, un modèle robuste bien adapté aux environnements où la manipulation de données doit être exécutée en interne pour des raisons de gouvernance ou de conformité.
Cependant, l'évolution rapide des architectures data, notamment l'essor des entrepôts de données cloud, a introduit un changement de paradigme avec l’approche ELT. Dans ce modèle, les données sont chargées directement dans l'entrepôt, où les transformations sont ensuite réalisées, généralement par des solutions modernes comme BigQuery, Snowflake ou Databricks. Cela réduit les mouvements de données, améliore l'efficacité et optimise les temps de traitement, particulièrement adapté aux environnements big data et cloud-native.
Bien que l’ETL classique avec SSIS, Talend et Informatica puisse sembler désuet, il reste pertinent. Ces solutions, bien implantées en tant que legacy dans de nombreux systèmes d’information, sont essentielles pour des workflows complexes et offrent une résilience difficile à égaler.
Le point de vue MDN
Il est donc conseillé de tester ces outils en contexte, malgré leurs limitations par rapport aux nouvelles solutions ELT. Placer ces outils en catégorie "Trial" encourage une approche de transition progressive : les équipes peuvent conserver ces solutions traditionnelles tout en envisageant une intégration parallèle des technologies ELT pour les cas d'usage nécessitant flexibilité et évolutivité.
Assess
24Snowflake Data Engineering
Au cours des dernières années, Snowflake a ajouté plusieurs fonctionnalités clés pour orchestrer des flux de transformation de données au sein même de la plateforme. Avec l’arrivée en 2019 des Tasks, et en 2022 des DAGs, il devient possible de créer des pipelines de commandes SQL orchestrées directement dans Snowflake. Plus besoin d’utiliser un orchestrateur externe, parfois coûteux et nécessitant une configuration supplémentaire pour accéder aux données dans Snowflake.
En 2022, Snowflake a également lancé Snowpark, une API permettant de traiter les données Snowflake à l’échelle depuis Python, Java et Scala. Avec une interface similaire à Spark, Snowpark dépasse les contraintes du SQL tout en profitant du calcul distribué sur les ressources Snowflake. Grâce aux Stored Procedures en Python, Java ou Scala, ces langages s’intègrent aussi aux DAGs Snowflake.
En 2023, l’arrivée du Logging et du Tracing depuis ces Stored Procedures a permis de monitorer les pipelines, une fonctionnalité essentielle pour garantir la stabilité d’un environnement de production.
Toutefois, développer un pipeline ETL nativement sur Snowflake présente certaines limitations, surtout en comparaison avec des outils ETL plus matures comme DBT ou Airflow.
- Maturité technique : l’API Snowpark est complexe à utiliser, évolue beaucoup, et la documentation reste limitée. Tester un ETL Snowflake de manière unitaire ou intégrale est difficile, et certains bugs dans une Stored Procedure peuvent être compliqués à investiguer.
- Contrôle de version et déploiement : bien que l’intégration Git soit désormais disponible pour le grand public, elle est récente. De plus, l’API Python pour la gestion des objets Snowflake, comme les Tasks et DAGs, est encore en phase de preview.
- Interfaçage externe : les ressources de calcul Snowflake ne sont pas directement connectées à Internet. Faire un appel API extérieur nécessite une configuration supplémentaire (Network Rule, Security Integration, External Access Integration). Ces requêtes passent par plusieurs éléments de réseau, rendant l’investigation des problèmes de latence complexe.
L’écosystème Snowflake est néanmoins en évolution rapide et pourrait devenir un service robuste pour le Data Engineering dans les années à venir.
Le point de vue Theodo
Aujourd’hui, notre recommandation est plutôt d’utiliser Snowflake comme un puissant moteur SQL et d’orchestrer ses transformations avec des services extérieurs plus matures (comme une stack DBT/Airflow). Dans les cas où l’industrialisation nécessaire est faible ou si l’on souhaite disposer d’une plateforme unique et cohérente, les outils ETL de Snowflake peuvent néanmoins être suffisants.
25Dataform
Dataform a été créé en 2018 en tant que framework open-source pour faciliter la création, l’exécution et l’orchestration de workflows SQL sur BigQuery, Snowflake, Redshift, et Synapse. Depuis son acquisition par Google Cloud en 2020, il a été optimisé et intégré dans BigQuery. À l’instar de dbt, Dataform permet de déclarer des sources, définir des transformations, des tests de data quality, et de documenter le tout dans une syntaxe proche du JSON. De plus, Dataform fournit un IDE intégré pour visualiser le lineage, compiler, tester et déployer son code en direct.
Dataform se distingue par son intégration native à l'écosystème Google Cloud, facilitant l'interaction avec d'autres services. L’outil est inclus gratuitement avec BigQuery, seuls les coûts de calcul étant facturés. Sa mise en place et sa gestion d’environnements sont extrêmement simples. Son templating en JavaScript permet de réduire la duplication de code avec beaucoup de flexibilité, même si ce langage est moins maîtrisé par les data engineers.
Ces fonctionnalités font de Dataform un concurrent sérieux à dbt, mais l’outil manque encore de maturité. L’expérience développeur est moins agréable en raison de l’impossibilité de tester en local et de la gestion réduite de Git dans l’IDE. Bien que la documentation soit fournie, elle reste difficile à prendre en main, et le support de la communauté est limité en comparaison. De plus, alors que dbt s’intègre dans de nombreuses technologies open source comme Elementary, Airflow ou Airbyte, Dataform manque d’outils similaires dans l’écosystème Google Cloud.
Le point de vue Theodo
Bien que Dataform offre une intégration solide avec l'écosystème Google Cloud, il présente des limitations par rapport à des alternatives plus matures comme dbt. La faiblesse de l'expérience développeur et l'écosystème réduit rendent Dataform moins attrayant pour des projets d’envergure ou évolutifs. À part pour des petites équipes travaillant avec BigQuery, nous préconisons donc de favoriser dbt pour sa complétude et son évolutivité.
26Polars
Polars est une bibliothèque open-source de Dataframes (transformation et analyse de données) écrite en Rust mais également disponible sur Python, passée en version majeure en 2024. Elle dépasse les limites calculatoires et mémoires de Pandas en permettant des calculs multithreads, des lazy evaluations et des calculs par batch, ce qui rend possible la gestion de volumes de données plus grands que la mémoire disponible.
En plus de ces capacités, Polars offre deux avantages principaux :
- Polars est par conception une librairie extrêmement efficace et rapide. L’adopter comme librairie de Dataframe par défaut dans ses équipes garantit une réduction des coûts liés aux calculs.
- Son API, plus proche du SQL/SparkSQL que celle de Pandas, permet d’investir dans une logique et des concepts mieux transposables à d’autres technologies.
Cependant, le principal frein à l’utilisation de Polars est sa nouveauté. Pandas est actuellement si dominant sur le processing in-memory que, pour des petits volumes de données, le gain de performance est marginal et le coût d’entrée, même léger, est perçu comme trop lourd. Pour des jeux de données plus importants, le marché tend à privilégier des technologies SQL comme DBT, en raison de leur universalité et des optimisations de performance qu'elles offrent. Cela est également vrai dans le domaine du Data et Analytics Engineering, où les puissances de calcul sont pensées pour exécuter du SQL.
Le point de vue Theodo
Chez Theodo Data & IA, nous pensons que Polars est un très bon outil d’analyse ad hoc pour les Data Scientists ou Analysts sur des volumes relativement faibles. Toutefois, dans l’ingénierie des pipelines de données, où Python est voué à disparaître au profit du SQL plus universel, nous ne voyons pas Polars devenir un équivalent de DBT.
Hold
27Glue ETL
Glue ETL est un service d’ETL (Extract, Transform, Load) entièrement managé par AWS, facilitant l’ingestion, le nettoyage et la transformation des données pour les rendre exploitables dans des environnements d’analyse ou d’intelligence artificielle. AWS Glue Data Catalog permet une mise en catalogue centralisée des données, simplifiant leur analyse et leur intégration avec d’autres services AWS tels que S3, Redshift ou Athena. Grâce à son moteur basé sur Apache Spark, Glue ETL offre une scalabilité élevée pour les traitements en batch.
Glue ETL contient des fonctionnalités d’orchestration (triggers, scheduling) qui restent moins flexibles que celles d’Airflow, que nous recommandons d’utiliser en complément. En effet, Glue ETL bénéficie d’une bonne compatibilité avec Airflow, et en utilisant Airflow comme orchestrateur et déclencheur des jobs Glue, il est possible de profiter de fonctionnalités d’alerting et de monitoring avancées. Les transformations de données sont définies dans des jobs via Glue, tirant parti de son intégration native avec les services AWS et de ses capacités d’exécution optimisées. Cette combinaison assure une gestion efficace et scalable des pipelines ETL, tout en améliorant la visibilité et le contrôle sur les processus de traitement des données.
Cependant, Glue ETL présente des limitations en termes de gouvernance et de suivi des transformations. La gestion du versioning des pipelines nécessite une configuration manuelle, et les interdépendances entre les traitements manquent de flexibilité. Enfin, comme souvent pour des services très managés, il est difficile d’avoir un workflow de développement simple et agréable, facilement exécutable en local.
Le point de vue Theodo
En raison de ses limitations en matière de gouvernance et de flexibilité dans la gestion des pipelines, nous ne recommandons pas l’utilisation de Glue ETL. Malgré sa compatibilité avec Airflow, les défis liés au versioning manuel et aux interdépendances rigides rendent son utilisation moins optimale. Nous recommandons d’évaluer ces aspects avant d’adopter Glue ETL ou de considérer ses alternatives.
28Spark
Spark est une solution open-source permettant de transformer de gros volumes de données en parallélisant les calculs. Avant 2009, la méthode standard de transformation de données dans l’écosystème Hadoop était "MapReduce". Spark a vu le jour en 2009 et s'est imposé comme plus rapide, évoluant ensuite pour devenir un système de calcul distribué indépendant de Hadoop.
La grande force de Spark réside dans son modèle d’exécution. Vous décrivez les transformations souhaitées sur vos données avec un DSL (domain-specific language), et lors de l’exécution, Spark se charge de construire un plan d’exécution optimisé pour ces transformations. Par exemple, Spark peut remonter un filtre situé en bas de la chaîne de transformations au début de l’exécution afin de ne charger que les données nécessaires.
Cependant, cette force est aussi sa faiblesse, car cela nécessite d’apprendre un DSL spécifique. Pour des optimisations plus poussées, il faut bien comprendre comment Spark construit son plan d’exécution.
C’est notamment le cas du mécanisme de shuffle, qui déplace les données entre les nœuds d’un cluster avant de les traiter. De plus, l’aspect distribué de Spark ne le rend pertinent que pour de gros volumes de données, là où lancer les transformations sur plusieurs machines en parallèle a du sens. Par exemple, le traitement d’un fichier CSV de quelques milliers de lignes peut prendre plusieurs minutes avec Spark, alors qu’il ne prendra que quelques secondes avec pandas.
Le point de vue Theodo
Nous recommandons de choisir Spark uniquement si vous avez un besoin de performance accru sur des transformations complexes impliquant de gros volumes de données (plusieurs téraoctets). Si ce n’est pas le cas, il vaut mieux utiliser le moteur de requête SQL de votre data warehouse, ce qui vous évitera d’avoir à monter en compétence sur une technologie complexe.