Gérer

Les data platforms modernes offrent désormais la possibilité  de créer des infrastructures hautement évolutives grâce à des composants serverless fonctionnant sur un modèle pay as you go. Des services  tels que BigQuery sur Google Cloud Platform (GCP) ou Synapse Analytics sur Microsoft Azure permettent de traiter et d'analyser des données à la demande,  sans gérer la complexité des  infrastructures sous-jacentes. 

Les plateformes serverless apportent une scalabilité accrue, s'adaptant automati quement aux fluctuations  de la demande. Elles réduisent  les coûts initiaux en éliminant  le besoin d'investissements  importants en matériel ou en  licences logicielles, ce qui est  particulièrement avantageux  pour les Petites ou Moyennes  Entreprises (PME) souhaitant  lancer rapidement leur data platform. De plus, elles simplifient la gestion  opérationnelle grâce à des outils comme PyAirbyte ou DLT (outils open source  d'extraction de données),  exécutés sur Cloud Run (service de déploiement de  conteneurs managé par GCP),  qui automatisent les processus  d'intégration de données. 

Cependant, ces solutions  présentent des défis : 

• Les coûts peuvent augmenter de manière imprévue avec l'accrois sement des volumes de données, rendant indispensable la mise en place d'une stratégie FinOps pour maîtriser les  dépenses opérationnelles. 

• La dépendance vis-à-vis  d'un fournisseur cloud peut limiter la flexibilité en cas de besoin de migration ou de renégo ciation contractuelle. 

• Les services serverless  offrent moins de contrôle  sur l'infrastructure,  ce qui peut restreindre les possibilités d'optimisation avancées.

LE POINT DE VUE THEODO 

Nous recommandons  aux PME souhaitant  développer leur data plateforme de se tourner vers  des solutions cloud  serverless pour leur flexibilité et leur  rapidité de mise en œuvre. Toutefois,  il est essentiel d'accompagner cette adoption par  une stratégie FinOps et une gouvernance  des données rigoureuses pour  maîtriser les coûts  et garantir la sécurité  et la qualité des données. 

Développer des plateformes  data nécessite de provisionner  et de gérer des ressources  essentielles telles que  des bases de données,  des clusters de calcul,  des pipelines de traitement  de données, et des environne ments de déploiement.  Traditionnellement, ces tâches étaient effectuées  manuellement, ce qui augmentait le risque d'erreurs humaines et limitait  la capacité à redéployer  rapidement une infrastructure  en cas de besoin. 

L’Infrastructure as Code (IaC)  est une approche moderne  permettant de créer, gérer et  automatiser les ressources  d’infrastructure d’un projet  Data Engineering. En définissant l’infrastructure  sous forme de code, celle-ci peut être versionnée  et auditée. Cette pratique  réduit le risque d'erreur,  tout en offrant la possibilité  de répliquer des environnements de manière fiable, et de  les faire évoluer facilement au gré des besoins du projet. 

L’IaC est devenue une norme  dans les projets Data Engineering car elle permet  de définir les services de  stockage, les environnements  de traitement des données,  et l'infrastructure scalable pour  le déploiement des pipelines  et des systèmes analytiques.  Cela assure une maîtrise  complète des composants,  de leur sécurité, et surtout  une évolutivité et une résilience accrues. 

Cette approche requiert  la maîtrise d'outils tels que Terraform ou AWS CloudFormation, ainsi que l’adoption de bonnes  pratiques associées. Le code d’infrastructure  doit être maintenu avec  le même niveau de rigueur  et de qualité que le code  applicatif traditionnel, afin de garantir une fiabilité  et une sécurité maximales.

LE POINT DE VUE THEODO 

Nous recommandons l'adoption généralisée  de l'IaC pour tous  les projets de Data  Engineering. Cette  approche assure une  gestion d'infrastructure  plus agile, scalable  et efficiente, permet  des déploiements  rapides et une meilleure cohérence. L'IaC renforce également la sécurité  et l'évolutivité des environnements, des aspects cruciaux  pour le succès de ces plateformes.

Développé par astral (les créateurs du linter ruff),  uv est un gestionnaire  de projets et de packages  Python open source conçu  pour accélérer et simplifier  l'outillage Python. 

Au-delà de cette simplification, uv améliore  l’expérience de développeur  sur de nombreux points. Tout  d’abord, uv est installable  et utilisable directement  avec une seule commande,  sans besoin préalable d’installer Rust ou Python. 

Ce dernier peut être installé  avec uv en une seule commande, comme avec  pyenv. La création d’environnement virtuel  est très similaire à poetry,  sa résolution de dépendances  étant optimisée pour être plus  rapide.

Grâce à cette rapidité,  la commande uv run revérifie  et recalcule les dépendances  à chaque lancement de commande python,  ce qui limite les erreurs lors de la mise à jour d'une dépendance par un autre membre d'équipe. Il devient  donc moins intéressant  d'utiliser l'ancien standard  d'activation d'environnement  virtuel avec pyenv local. 

Ainsi, dans un flux classique  de développement, uv  accélère les flux et simplifie  l’écosystème en proposant  d’être le seul prérequis  à l’utilisation de Python avec  des environnements virtuels.  Cela permet de faciliter le lancement du projet  à des non-initiés. Enfin,  alors que pyenv n'était pas  officiellement compatible  avec Windows, uv l'est  nativement, ce qui permet  d’uniformiser l'outillage sur toutes les plateformes.

LE POINT DE VUE THEODO 

Chez Theodo, nous recommandons chaudement l’utilisation de uv pour des flux de développement classiques en Python au vu de sa qualité, complétude, simplicité et de sa fréquence de mise  à jour. Si vous utilisez  des fonctionnalités  de poetry / pyenv  encore indisponibles  sur uv, nous recommandons de créer une issue  sur le repository GitHub du projet pour le faire évoluer.

Avec l'augmentation exponentielle des volumes  de données et la complexité des écosystèmes data, les Data Contracts se sont  imposés comme un outil  crucial pour améliorer la gouvernance et la gestion des jeux de données. Ces contrats permettent  de formaliser les attentes  autour de la structure,  des types et des contraintes des données à travers des  équipes variées, contribuant  à une documentation claire  et partagée. 

Les Data Contracts ne se limitent pas à décrire  des interfaces d'échange,  mais s'étendent à la qualité  des jeux de données. Ils définissent de manière  précise ce qu'est un dataset  en termes de précision, complétude, cohérence  et évolution. Par exemple, un batch de traitement peut, grâce aux Data Contracts, comprendre exactement  la nature des données attendues et ainsi optimiser la fiabilité et la reproductibilité des processus. 

Le standard Open Data Contract permet d'établir des  spécifications claires, facilitant  la collaboration inter-équipes  et réduisant les incertitudes  sur la signification et l'utilisation des données. Ces contrats sont également essentiels dans le cadre d'une architecture Data Mesh, car ils favorisent la découverte et l'accessibilité des données  dans le SI de manière standardisée, facilitant  ainsi la responsabilisation  des domaines de données. 

Dans nos projets, nous avons  vu des gains significatifs  en qualité des données et  en réduction des incidents liés à des erreurs d'interprétation  entre équipes. Des outils  simples comme Pydantic se sont révélés utiles pour la définition et la validation des schémas.

LE POINT DE VUE THEODO 

Les Data Contracts  sont un pilier essentiel  pour garantir la qualité et la compréhension des données, surtout dans des environnements  complexes et distribués. Nous  recommandons leur adoption, en particulier dans  les contextes de Data  Mesh, pour améliorer  la standardisation,  la découverte des données et la collaboration  inter-équipes.

Elementary est une solution  innovante et open-source qui répond à un besoin crucial  en data engineering : assurer  la fiabilité des données.  Avec la montée en puissance  de dbt ces dernières années,  un manque s’est fait sentir  autour du suivi et de la qualité  des données. Elementary comble ce vide en offrant  un système de surveillance  et d’amélioration de la qualité  des données, éliminant  ainsi les risques de données  incohérentes ou incomplètes. 

Avant Elementary, la gestion  de la qualité des données  reposait sur des scripts  personnalisés ou des outils  dédiés comme Great Expectations, souvent complexes et coûteux. Elementary simplifie ce processus grâce à son  intégration native avec dbt,  offrant un moyen efficace  de faciliter la mise en place  de contrôles de qualité dans les flux ETL (Extract,  Transform, Load). Là où dbt manque d’une interface  pour visualiser l’évolution  des données dans le temps,  Elementary se distingue par  une couche d’historisation  et de visualisation avec un  tableau de bord intuitif, facile  à installer et à déployer.  Une simple commande  planifiée permet de générer  des rapports automatisés,  ce qui rend le processus  transparent et accessible  aux data analysts, analytics  engineers et aux métiers. 

En outre, Elementary propose  des fonctionnalités avancées  telles que la détection d’anomalies, qui ajoutent une  dimension supplémentaire  à la surveillance des données,  bien que ces fonctionnalités  puissent nécessiter des  ajustements en fonction  des cas d’usage spécifiques.

LE POINT DE VUE THEODO 

Theodo recommande  Elementary pour sa  simplicité d’intégration, surtout pour les entreprises qui utilisent déjà dbt et cherchent  à renforcer la qualité  de leurs données. Sa  communauté active permet un accès rapide au support et  à des fonctionnalités constamment enrichies. Cependant, en tant que techno logie émergente, elle  évolue rapidement, ce qui peut représenter un défi d’adaptation pour certaines entreprises.

Les données représentent depuis longtemps un atout stratégique essentiel pour les entreprises. Toutefois, la complexité croissante des systèmes d'information et des processus métiers complique souvent la collaboration entre équipes métiers et techniques. L'Event Storming, une méthode collaborative et visuelle issue du Domain-Driven Design, s'avère particulièrement utile pour concevoir une modélisation des données adaptée aux besoins métiers et aux exigences analytiques. 

L'atelier d'Event Storming est structuré pour favoriser une compréhension commune du système. Il débute par la collecte des événements métiers clés, chaque participant contribuant en plaçant des notes adhésives sur un mur pour représenter ces événements  chronologiquement. Cette phase  est suivie par l'identification  des acteurs, des commandes  et des agrégats, ce qui permet  de construire une vue d'ensemble du domaine. Cette approche interactive  facilite la communication et met en lumière les zones  de complexité ou d'incertitude. 

Bien que rarement utilisé dans  l’analyse de données, il aide  à cartographier les événements  métiers pour identifier les données  nécessaires à l'analyse et à la prise de décision. Cette  exploration présente plusieurs  avantages spécifiques pour  la modélisation des données : 

• Identification des besoins  en données grâce à une compréhension accrue des flux métiers.
• Alignement des parties prenantes grâce à un langage commun est essentiel dans les projets complexes.
• Détection des anomalies dans les processus existants, favorisant ainsi l'optimisation opérationnelle.

Cependant, cette méthode peut être moins adaptée aux environnements simples, où une approche comme le Design Thinking pourrait être plus appropriée. Elle nécessite également une préparation soignée et un facilitateur expérimenté pour maximiser son efficacité.

L'utilisation de données de production en préproduction ou en développement est courante dans les projets data. Cela permet de simuler des conditions réelles et d'améliorer la qualité des tests et des développements. Les équipes peuvent ainsi évaluer la performance des applications, ce qui facilite les ajustements avant déploiement. Cette pratique présente ainsi un avantage majeur : elle améliore la fiabilité des développements en identifiant rapidement les bugs et en prenant des décisions basées sur des données concrètes.

Cependant, cette technique soulève de sérieux problèmes de sécurité et d'isolation. Si les environnements hors production ne sont pas correctement isolés du réseau de production, il existe un risque de compromission de la production. En plus de cela, l'accès direct à des données sensibles sans protection adéquate est en violation des régulations telles que le RGPD et des normes comme ISO 27001 ou SOC2. Pour être conforme, il est notamment impératif de protéger la confidentialité des données via des techniques d'anonymisation.

Ces pratiques, particulièrement complexes, nécessitent de peser les risques et de choisir un niveau de sécurité adapté en fonction des spécificités du projet. Une alternative courante est l'utilisation de données synthétiques qui ne pose aucun problème de sécurité ou d’isolation en évitant l'accès aux données de production sensibles. Cependant, cette méthode présente des limites en termes de représentativité des scénarios réels et peut être chronophage à mettre en place, réduisant ainsi son efficacité.

Le point de vue Theodo

Chez Theodo, nous pensons fermement que les données de production sensibles n'ont pas leur place dans les environnements de développement. Face à l’absence d’outil idéal pour l’anonymisation, nous expérimentons actuellement avec succès des modèles de génération de données synthétiques (GenAI) qui nous permettent d’itérer rapidement tout en maintenant un haut niveau de sécurité et d’isolation des données sensibles.

Sifflet est une plateforme d'observabilité des données lancée en 2021. Elle aide les organisations à surveiller et améliorer la qualité, la fiabilité et la traçabilité de leurs données à travers leurs pipelines. En offrant des indicateurs clés tels que le nombre de valeurs nulles, le volume des tables ou l'unicité des identifiants, Sifflet garantit une gouvernance de données robuste et fiableu.

Ce qui distingue Sifflet, c'est sa simplicité d'utilisation grâce à son interface no-code. La création de règles de contrôle de qualité est intuitive, et les notifications en cas de non-conformité sont instantanées via e-mail, Teams ou Slack. La plateforme rend les données plus accessibles grâce à son catalogue et à la visualisation du data lineage. Elle s'intègre avec une multitude de solutions, y compris les data warehouses, data lakes, outils de BI, solutions ELT/ETL et orchestrateurs de données.

Cependant, Sifflet reste un outil très récent et présente quelques limitations. Certains outils comme Dagster ou Google Chat ne sont pas encore supportés. L'utilisation de "Monitors As Code" peut rendre le débogage complexe en raison du format YAML. Avec un grand nombre de tables, la création de règles peut devenir fastidieuse. Les options de monitoring sont limitées, restreignant la personnalisation des visualisations. Enfin, le coût de la solution, communiqué uniquement sur demande, peut être un obstacle. Des alternatives comme Monte Carlo ou Elementary méritent d'être considérées.

Le point de vue Theodo

Nous recommandons Sifflet pour sa facilité d'utilisation, surtout pour les organisations avec une faible appétence “tech”, une plateforme data peu complexe mais des contraintes fortes sur la qualité des données. Son coût élevé et ses fonctionnalités limitées peuvent être un frein à son adoption.

SQLFluff est un linter et formateur SQL open-source conçu pour améliorer la qualité du code en appliquant des normes de codage cohérentes et en détectant les erreurs potentielles, indépendamment du dialecte SQL utilisé. Avant l'arrivée de SQLFluff, l'analyse statique du code SQL était souvent négligée, les développeurs se reposant sur des revues manuelles pour assurer la cohérence et la qualité, ce qui était inefficace et sujet aux erreurs. SQLFluff comble cette lacune en offrant un outil automatisé capable de linting et de formatage, facilitant ainsi la collaboration et la maintenabilité du code SQL.

Les principaux avantages de SQLFluff résident dans sa grande flexibilité pour s'adapter aux normes spécifiques d'un projet et son support pour de multiples dialectes SQL. Sa fonctionnalité d'auto-correction peut accélérer le développement en corrigeant automatiquement les problèmes de style et de syntaxe.

Cependant, SQLFluff présente certaines limitations. L'utilisation de l'auto-correction peut parfois introduire des modifications qui cassent le code SQL, surtout dans des constructions complexes ou non standards. De plus, lors du linting de fichiers volumineux ou d'un grand nombre de fichiers, l'outil peut devenir lent, affectant ainsi la productivité. La configuration initiale peut être complexe, avec des conflits possibles entre différentes règles nécessitant une personnalisation approfondie.

Le point de vue Theodo

Nous conseillons l'utilisation de SQLFluff car disposer d'un linter est essentiel pour la qualité du code SQL. Cependant, il faut être conscient de ses limitations. Utilisez l'auto-correction avec prudence et optimisez le linting pour les grands fichiers. Une configuration soignée est cruciale pour en tirer le meilleur parti.

Great Expectations est un framework open source en Python dédié à l’évaluation et à la surveillance de la qualité des données. Son intégration avec la plupart des outils du marché est simple et rapide, grâce à sa compatibilité avec de nombreuses sources de données et outils d'orchestration. De plus, la communauté contribue activement au développement de packages proposant des vérifications qualité préétablies.

Great Expectations peut se connecter aux principales technologies de bases de données (PostgreSQL, BigQuery, etc.) et de stockage (AWS S3, Google Cloud Storage, etc.). Il propose un système de logging et d'alerting pour les résultats des contrôles de qualité, offrant une meilleure visibilité sur l'état de la qualité des données.

Cependant, Great Expectations présente plusieurs limites importantes. Sa courbe d'apprentissage est abrupte en raison de concepts complexes à assimiler. La création de checks de qualité personnalisés est souvent ardue et peu intuitive, d'autant que la documentation reste insuffisante pour faciliter la prise en main. Par ailleurs, l'outil manque de fonctionnalités pour les contrôles inter-tables, réduisant significativement son champ d'application. Enfin, l'expérience utilisateur des rapports de qualité est perfectible, ce qui rend le suivi de l'évolution de la qualité complexe sur le long terme.

Le point de vue Theodo

Nous ne recommandons pas l’utilisation de Great Expectations en raison de ses limitations qui compliquent son adoption et son utilisation à grande échelle. Pour évaluer et surveiller la qualité des données, nous recommandons d'envisager des alternatives comme Elementary, en particulier si votre pipeline repose sur dbt.

Kibana est un outil de monitoring principalement utilisé pour analyser et visualiser des logs et des métriques. Il fait partie intégrante de la suite Elastic Stack (anciennement ELK Stack), au même titre qu’Elasticsearch et Logstash. Kibana permet de créer des graphiques, des tableaux de bord interactifs et des rapports basés sur les données indexées dans Elasticsearch, offrant ainsi une interface puissante pour explorer et analyser des logs en temps réel.

Kibana est donc efficace pour la gestion des logs, et il est tentant de vouloir l’utiliser pour faire du suivi de qualité de données. Cependant, cela présente des limitations :

• Variété limitée de graphiques : Kibana propose un nombre restreint de visualisations. Pour des tableaux de bord plus parlants et personnalisés, il peut être nécessaire de recourir à des outils tiers.
• Absence de prétraitement des données : Kibana ne permet pas de manipuler les données ou de réaliser des agrégations avancées sans passer par des transformations externes.
• Montée en compétences : L'apprentissage de Vega, du Kibana Query Language (KQL), ainsi que l'absence de support pour SQL, peut représenter un obstacle pour les utilisateurs novices.

Pour un suivi plus efficace de la qualité des données, des alternatives comme Elementary, qui visualise automatiquement les tests dbt, ou Sifflet avec ses dashboards prêts à l’emploi, peuvent être plus adaptées. Pour des besoins spécifiques, un tableau de bord personnalisé avec un outil de BI est aussi une option à envisager.

Le point de vue Theodo

Il y a quelques années, nous avons utilisé Kibana en tant qu’outil de suivi de la qualité des données. Si cet outil était efficace pour des métriques simples, il a montré ses limites en termes de flexibilité face à des besoins plus complexes. Nous recommandons donc Kibana uniquement pour l’analyse et la visualisation des logs applicatifs.