Fail fast pour le big data
Article succinct pour expliquer pourquoi une application big data doit tester son code encore et encore. Le principe est simple : vous certifiez les traitements, et laissez à la source la responsabilité de corriger SA donnée.
Tester son code en big data
En général, Spark étant du code comme un autre, on peut le tester avec du JUnit en général, avec Hadoop Unit en particulier. Sur le principe, il suffit de fabriquer deux types de contextes : un local de test, un global pour les différents environnements. Le local va lire des données locales, par exemple des fichiers csv ad hoc ou des données préparées en général. Cependant, le vrai intérêt est de prouver que le code marche à condition que la donnée soit la bonne. Autrement dit, avec une bonne stratégie de tests, et un effort constant, la méthode avec Spark délègue aux données sources la responsabilité des plantages. Bien sûr, Spark n'est qu'un outil et vous pouvez tout à fait avoir des équipes qui, prises par des délais saugrenus, vont réaliser des tests uniquement sur les cas passants simples (en supposant déjà des tests, ce qui n'est pas donné à tout le monde). Mais à ma connaissance, il est le mieux placé pour arriver à un niveau de tests qui dédouanera l'équipe un maximum, donc la soulagera d'autant.
Pourquoi votre code doit planter le plus tôt possible
Couplez ce constat avec la notion de Fail Fast, c'est à dire l'idée que le système remonte immédiatement que ce qu'il est en train de faire comporte une erreur.
En fait, quand on lit de la donnée, il se pose la question de savoir que faire de ce qui est "faux mais pas trop", c'est à dire ce qui ne provoque pas un plantage du traitement, mais qui va fournir un résultat faux. En substance, la JVM continuer à tourner, le résultat produit "a l'air bon" selon la technique de "à vue de nez, c'est pas déconnant". Par exemple, quand on a 100 millions de ventes sur un site marchand, le fait qu'il manque le montant sur 0.1% des ventes ne va pas changer considérablement a priori la moyenne des ventes. Elle est fausse, en effet, mais "pas de beaucoup". La solution la plus commune reste le fichier de rejet que l'on dégaine pour se couvrir en cas de bug de production critique qui cherche un coupable. Cette solution est affreusement naïve, car elle va donner lieu à un ping pong infini entre l'application source qui vous dira que ça ne lui pose aucun problème à elle, et vous qui allez répéter que ce ne sont pas vos données, donc pas votre problème. Or, la question de la qualité de la donnée incombe à la source. Point. La solution du fail fast est un moyen efficace mais sévère d'impliquer les équipes qui fournissent la donnée (source dans la suite).
Pour ne pas laisser ces questions sans solution, il y a eu des réflexions méthodologiques, notamment chez Microsoft autour de SQL Server avec la notion de Data Quality Services. Sungard avait eu la même réflexion en créant un moteur de règles pour la vérification de ses données comptables. Est ce un projet coûteux ? Pas nécessairement au moyen de produits spécifiques, car finalement une règle qui lève une anomalie et un requête sont la même chose. Pourquoi charger la source au maximum ? Parce que, pour un data engineer, une analyse multi sources, sur de gros volumes de données est impossible ou très coûteux. Il faut donc réduire au maximum les sources d'erreurs qui entrent dans le lake, avec des données qui, prises isolément, sont certifiées correctes par la source.
Conclusion
Le but d'un data engineer est de déplacer la donnée au mieux, sans la dégrader. Ce n'est pas d'être expert dans chaque application source, et ce n'est pas non plus de devenir la voiture balai des bugs que vos collègues n'ont pas résolu parce qu'ils n'avaient pas le temps. Par conséquent :
- testez beaucoup pour que votre code soit bon, de sorte à pouvoir dire "tel bug vient de la donnée, on a testé ce cas".
- dans le code, appliquez sans vergogne le fail fast. Vous aurez un message explicite qu'il vous sera facile de renvoyer à l'application source pour rectification.
- même si, en l'état, le code dépend peu de telle donnée, vous pouvez partir du principe que demain ça sera le cas, et que ce qui passait inaperçu et indolore sera source de bugs et de plantages ensuite. Pas de pitié pour les équipes sources, la data est publique à présent. A eux de la gérer au mieux, à vous de la trimbaler.
-
Categories
-
Articles
- avril 2018
- mars 2018
- février 2018
- janvier 2018
- décembre 2017
- octobre 2017
- juin 2017
- mai 2017
- avril 2017
- mars 2017
- février 2017
- décembre 2016
- novembre 2016
- septembre 2016
- août 2016
- juillet 2016
- juin 2016
- avril 2016
- février 2016
- janvier 2016
- décembre 2015
- octobre 2015
- septembre 2015
- août 2015
- juin 2015
- mai 2015
- avril 2015
- mars 2015
- février 2015
- janvier 2015
- décembre 2014
- novembre 2014
- septembre 2014
- août 2014
- juillet 2014
- juin 2014
- mai 2014
- avril 2014
- mars 2014
- janvier 2014
- décembre 2013
- août 2013
- juillet 2013
- juin 2013
- mai 2013
- février 2013
- janvier 2013
- décembre 2012
- novembre 2012
- septembre 2012
- août 2012
- juillet 2012
- juin 2012
- mai 2012
- février 2012
- janvier 2012
- décembre 2011
- novembre 2011
-
Meta