Après avoir vu, dans l’article « Le DevOps, le fondement d’une politique plus verte », comment rendre la partie DevOps plus écologique, nous allons zoomer un peu plus sur la Data pour voir comment réduire notre impact via l’architecture.
La Data Gouvernance
La Data Gouvernance est née avec la croissance des projets Data et l’augmentation des volumes de données. En effet, on peut facilement aujourd’hui avoir plusieurs projets traités par plusieurs équipes. Le rôle de la Data Gouvernance sera de normaliser le stockage des données, afin que ces deux équipes aient la même norme, et que les données soient facilement trouvables, utilisables et documentées.
Mais quel est le rapport avec la baisse de l’utilisation de la mémoire et du stockage, me direz-vous ?
Le fait de bien documenter et normaliser la donnée va permettre, en plus d’avoir une meilleure cohérence pour le projet final, d’éviter les doublons.
Et nous parlons ici aussi bien de :
- Réaliser plusieurs fois le même calcul, comme recalculer deux fois le bénéfice d’une entreprise au lieu de réutiliser le travail déjà effectué par une autre équipe, représente une perte de temps et de ressources. Mutualiser ces calculs permet non seulement d’optimiser la consommation de ressources, mais aussi d’améliorer la qualité, en évitant les divergences de modes de calcul.
- Ingérer plusieurs fois les mêmes données, comme récupérer une liste de pays depuis une source open data alors qu’elle est déjà disponible et normalisée dans le Datalake de l’entreprise, entraîne une duplication inutile. Utiliser les données existantes permet d’optimiser les ressources et d’assurer la cohérence des informations.
Et je ne parle pas de tous les métiers fonctionnels qui vont extraire vos données pour refaire les calculs sur leur fichier Excel ou Google Sheets (mais ouf ! La Data Gouvernance est aussi là pour aider à l’acculturation de la Data !). Cette acculturation peut d’ailleurs représenter un gros gain de qualité de donnée (et donc de calcul), dans le cas où les métiers sont les générateurs de votre data.
Le fait qu’ils prennent conscience que les données saisies dans leurs outils sont exploitées de votre côté, et qu’elles doivent donc être rigoureusement renseignées en respectant les bonnes pratiques, peut vous faire gagner un temps considérable et réduire la charge de traitement en aval.
Le choix des outils
Le choix des technologies et des outils utilisés peut avoir un impact considérable sur la consommation des ressources.
Les solutions open source permettent souvent une personnalisation et une optimisation accrues, ce qui peut avoir un impact écologique positif, car on peut paramétrer l’outil exactement selon les besoins du projet.
À l’inverse, les outils propriétaires sont souvent conçus pour maximiser l’efficacité à court terme, mais leur coût écologique peut être plus élevé sur le long terme, en raison des licences et des infrastructures spécifiques qu’ils imposent.
Il est essentiel de consommer uniquement les ressources nécessaires et de limiter les consommations inutiles liées à des surcouches non exploitées, tout en privilégiant une base normalisée pour répondre aux besoins les plus larges.
⚠️ Attention cependant : un outil open source peut être plus compliqué à prendre en main. Il faut donc s’assurer de bien maîtriser le produit avant de choisir cette solution et pouvoir en tirer tous les avantages.
Deltalake
L’architecture classique du Datalake fonctionnant main dans la main avec le Datawarehouse est révolue !
Aujourd’hui, les Deltalake ont fait leur apparition. Cette nouvelle façon de penser transforme les données de notre Datalake en Dataframe (pour faire très court). Cette organisation, doublée d’une architecture en médaillons, permet de diminuer la duplication des données, car il n’y a plus besoin d’ingérer les données du Datalake vers le Datawarehouse.
Si vous avez bien suivi jusque-là, il y a un double effet positif :
- diminution des doublons et des transferts de données,
- mutualisation des puissances de calcul, car on se trouve sur une seule techno.
Cependant, il y aura un gros travail de data gouvernance pour ne pas se mélanger les pinceaux entre les différentes zones et ne pas avoir de projets obscurs, tels qu’un Dashboard branché sur la zone bronze…
Format adapté dans le stockage
Une optimisation possible dans l’architecture est l’utilisation du bon format pour la bonne utilisation.
Par exemple, dans l’analytics, on utilise beaucoup de CSV. Ce format est apprécié car simple, lisible et exploitable directement dans Excel (mais utiliser ce type d’outil pour des flux data n’est absolument pas une bonne pratique !).
Cependant, ce n’est pas le format le plus optimisé pour nos SI dans le traitement analytique.
À l’inverse, le Parquet, lui, n’est pas lisible directement, ne sera pas exploitable dans Excel, mais il prend nettement moins d’espace et aura un temps de traitement plus rapide.
Certes, à petite échelle, c’est négligeable. Mais sur de gros SI avec une forte volumétrie, vous verrez la différence.
En conclusion, il ne faut pas toujours privilégier la simplicité. Lors du stockage des données, il est important de réfléchir à leur usage et de se demander si leur format est le plus adapté à nos besoins et à leur contenu.
Cycle de vie et méthode de stockage
Certaines données ont une durée de vie courte, tandis que d’autres sont destinées à être stockées à long terme.
Lorsqu’on parle de stockage, il est donc crucial de choisir la bonne solution en fonction de cette durée.
- Pour des données éphémères (comme des logs ou des données transitoires), utiliser un stockage à faible coût et faible consommation peut faire toute la différence.
- Pour des données critiques à conserver plusieurs années, il vaut mieux privilégier un stockage plus durable et fiable.
Un bon exemple : ne pas garder sur des disques SSD haute performance des données que vous n’utilisez qu’une fois de temps en temps, mais plutôt les stocker sur des systèmes plus adaptés comme des disques HDD ou du cold storage dans le cloud.
Les fournisseurs cloud proposent aujourd’hui des solutions de stockage adaptées à différents niveaux d’accès (besoin immédiat, archivage, etc.). Il est vraiment important de gérer le cycle de vie de la donnée pour l’optimiser.
Aussi, lorsqu’on parle de cycle de vie, on parle également de suppression.
Il est important d’avoir une véritable politique de suppression de la donnée, pour ne pas se surcharger inutilement. Au moment de son ingestion, pensez à réfléchir à sa durée de validité et aux besoins d’accès.
Dans le cas de données utilisées sur du court terme, une politique de suppression adaptée et pensée en amont évite d’utiliser des ressources pour les stocker sur du long terme.
CI/CD et environnement
Bien que tester, c’est douter, il est convenu qu’il faut faire des tests unitaires et des tests d’intégration.
Cependant, attention à l’excès de zèle qui pourrait conduire à sur-tester des fonctions ou des données.
Il est important de toujours réfléchir à l’utilité et à la valeur ajoutée du test. Non seulement ce n’est pas toujours passionnant à développer, mais cela peut également entraîner une surconsommation de calculs inutiles.
Aussi, parmi les bonnes pratiques : avoir un environnement de dev et de recette, avec des données réduites mais représentatives de celles en production.
Il est inutile d’avoir 2 millions de lignes (sauf pour de brefs tests de charge) pour tester un flux parce qu’on a rajouté une colonne.
Après un article sur le DevOps et un sur l’architecture data, il sera temps, dans le prochain article, d’aller un peu plus dans le concret en voyant comment optimiser et être green dans les workflows 🌱
