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.