Optimiser la partie DevOps et l’architecture, c’est bien. Optimiser également les workflows Data, c’est mieux.
Bien que cet article soit moins dense que les précédents, il est, à mon sens, le plus important de toute la série. D’expérience, les workflows entraînent souvent beaucoup de pertes. Contrairement à l’architecture ou à la partie DevOps, nous avons généralement la main dessus, ce qui nous permet d’avoir un impact direct et rapide.
Une architecture et une infrastructure ne se changent pas du jour au lendemain, alors qu’un workflow peut se stopper sur une erreur de MEP.
Calculer le strict nécessaire et optimiser
Une technique toute simple pour économiser la mémoire dans vos workflows, c’est de bien cadrer le besoin et d’y répondre de manière précise.
Par exemple, si vous devez calculer le chiffre d’affaires pour la France, il est inutile de récupérer toutes les données mondiales pour ensuite filtrer sur la France. Autant appliquer le filtre dès le départ.
Pour être plus clair : quand on va acheter une pomme au producteur local (on est dans un article sur l’écologie, quand même !), on ne va pas ramener tout le bac de pommes à la caisse pour n’en donner qu’une.
Les workflows, c’est pareil.
Dans la continuité de cette logique : si vous avez besoin d’utiliser ces mêmes données ailleurs, inutile de tout recalculer. Liez les workflows ou appuyez-vous sur l’existant.
Trouver la récurrence nécessaire
Dans la même veine que cadrer le besoin avant de dev, l’une des méthodes pour ne pas gaspiller de ressources, c’est de répondre juste au besoin.
Vous n’iriez pas lancer un job en streaming pour un besoin hebdomadaire, si ?
Il en va de même pour les batchs : pourquoi les exécuter quotidiennement pour alimenter un Dashboard mensuel ?
Bref, ne faites pas d’excès de zèle.
« Qui peut le plus, peut le moins » ne doit pas s’appliquer ici 😉
Supprimer les workflows inutiles
Faire fonctionner des clusters et de la puissance de calcul pour ne pas se servir de ce qui est produit, c’est un peu comme cuisiner pour ensuite jeter la nourriture à la poubelle.
Prenez du recul et n’hésitez pas à questionner la justification des workflows, afin de ne pas avoir des workflows inutiles qui tournent et que personne ne connaît.
En cas de doute (après de multiples vérifications), vous pouvez simplement mettre le workflow en veille et attendre qu’une personne vous réclame le flux.
C’est brutal, mais cela peut répondre à notre questionnement.
Petit tips : de nombreuses BDD permettent de voir l’utilisation des tables.
Vous pouvez regarder si la/les tables finales d’un flux sont interrogées, et à quelle récurrence.
Cela peut vous permettre de limiter vos interrogations et d’éviter de commettre des erreurs.
⚠️ Attention aux environnements de préprod, prod et dev !
On a souvent des flux qui tournent dans le vide et qui sont oubliés.
Exécuter les workflows en dehors des heures de pointe
Les datacenters ont des tailles adaptées pour répondre à des pics d’utilisation.
Lancer des flux en dehors de ces pics peut à la fois :
- les rendre plus rapides,
- et éviter la création de futurs déchets électroniques liés à l’achat de clusters.
Finalement, les fameux workflows BI qui tournent à 2 h du mat sont une bonne option.
Par exemple, parlons raclette !
Nous sommes 12 personnes à vouloir en manger une (qui ne voudrait pas ?) :
– Soit on achète 2 appareils pour manger tous ensemble en même temps,
– Soit 6 personnes mangent à 19h, et les 6 autres à 20h.
Dans le deuxième cas, on consomme autant d’énergie, mais on économise sur l’achat du matériel avec un seul appareil au lieu de deux.
Le stade ultime de l’optimisation ?
Louer l’appareil en question, afin d’en optimiser l’utilisation grâce au fait qu’il soit partagé.
(Je fais référence au cloud public, pour ceux qui seraient distraits.)
Documenter son flux 🥲
Ça fait mal de le dire, mais la documentation est utile.
Dans la même logique que l’utilité de la Data Gouvernance décrite dans le dernier article, documenter vos flux (et maintenir la doc à jour) permet de :
- donner à toutes et tous une vision globale des workflows,
- faciliter l’ensemble des axes d’optimisation décrits ci-dessus,
- laisser une trace à vos successeurs,
- prendre du recul sur son workflow au moment de l’écriture,
- et plein d’autres avantages.
Pour que la doc ait une véritable utilité, il est impératif de suivre les procédures de l’entreprise et d’écrire la documentation dans la zone prévue à cet effet.
Une documentation inaccessible et inconnue est inutile.
Conclusion
À présent, nous avons vu comment optimiser les workflows.
Je rappelle vraiment que c’est le point de départ sur lequel vous pouvez agir en tant que Data Engineer, et économiser beaucoup à votre entreprise/client grâce à votre recul et votre regard neuf — dans le cas d’un nouvel arrivant.
Comme toujours, la base est de consommer et d’utiliser uniquement ce qui est utile : ni trop, ni pas assez.
Finalement, le Green IT, ne serait-ce pas la même philosophie que la RGPD ?
Consommer uniquement ce qu’il faut, et le tracer correctement.
Dans les prochains articles, nous allons zoomer de plus en plus sur les développements, notamment en optimisant vos requêtes SQL et votre code Spark.
