Le conseil précédent avait pour but de rappeler la responsabilité d’un job sur son propre environnement de travail, ce que l’on oublie assez facilement lorsqu’on code. Nous allons maintenant voir comment et pourquoi il faut découper ses traitements, simple, mais tellement évident et efficace en pratique.
Conseil N°5 : Restreindre vos jobs à une petite taille et leur donner un rôle bien précis
Nous pourrions être tentés de faire un job qui fait tout. Celui-ci va enchaîner un ensemble d’opérations jusqu’à obtenir le résultat souhaité : intégrer de la donnée externe, valider le contenu des données, effectuer des agrégats, des calculs et enfin rendre disponible son résultat pour un autre usage.
Soyons clair: cette pratique est absolument à proscrire ! Des dizaines d’années de bonnes pratiques (nous nous référons encore à Ralph Kimball) ne nous contrediront pas.
Le découpage des jobs en “petits” traitements a trois objectifs :
- Faciliter la maintenance du job : découper vos traitements en plusieurs jobs vous aidera à garantir un niveau de qualité et de compréhension du rôle du job en ayant recours à moins de documentation. Moins un job réalise d’opérations, plus il est facile à comprendre et donc à faire évoluer sans régression (Never forget: “Keep It Simple and Stupid”).
- Etre efficace en cas d’incidents : il vous sera plus facile de diagnostiquer l’origine d’un incident avec un pipeline de petits jobs plutôt qu’avec un gros job monolithique. De plus, vous allez pouvoir reprendre l’exécution d’un pipeline de traitements en cas d’échec sans ré-exécuter l’enchaînement des opérations depuis le début.
- Pouvoir paralléliser les actions qui peuvent l’être : en confiant à la technologie adaptée vos jobs (Hadoop, Celery…), vous pourrez exécuter en même temps les opérations sans dépendance entre elles afin de gagner sur le temps d’exécution du pipeline complet.
Il existe un modèle de découpage des jobs en rôle éprouvé qu’il faut continuer à suivre :
- des jobs d’intégration de données dans une zone de “staging”
- des jobs de contrôle de l’intégrité et de la qualité des données
- des jobs d’enrichissement, d’analyse et d’agrégation
- des jobs d’exposition des données pour leur usage suivant
Gardez en tête que cette structuration vous aidera à concevoir des pipelines de data où vous pourrez, éventuellement, ré-utiliser des jobs pour des objectifs différents. Sur nos plateformes, nous utilisons par exemple un même job d’export de fichiers vers des destinations externes (Amazon S3, SFTP, GCS…) dans plusieurs pipelines.
Conclusion:
Que pensez-vous de ce conseil ? Ces pratiques, simples à retenir, datent en fait de plusieurs dizaines d’années en arrière, lorsque les ressources informatiques étaient rares et chères. C’est d’ailleurs utilisables très souvent en développement, pas uniquement en Data. N’hésitez pas à laisser des commentaires et venez discuter avec nos experts, qui se feront un plaisir de vous accueillir dans nos locaux rue du Sentier à Paris.
____________________________________________
Pour relire le conseil N°4 c’est par ici
Pour relire le conseil N°3 c’est par ici
Pour relire le conseil N°2 c’est par ici
Pour relire le conseil N°1 c’est par ici
Pour postuler directement et joindre notre équipe de Data Engineer, c’est par ici.
