Le problème qui sera le sujet de l'article est le suivant : vous êtes le métier sur une application de big data qui utilise un data lake. Celui-ci récupère ses contenus depuis une vingtaine de sources, disons. Vous lancez une requête pour voir de la donnée, et ça ne ressemble à rien. A qui la faute ? A qui la charge de la correction ?

Data as a contract

En programmation par contrat, ou même sans dépasser le simple bon sens, on a plusieurs vérifications : pré conditions, invariants, et post conditions. Au début du programme, ou d'une partie de code : est ce que les pré conditions nécessaires sont remplies ? Au milieu : est ce que quand je promets pour la bonne marche du programme un élément, reste t'il vrai ? Et à la fin : est ce que le résultat promis est bien conforme au résultat calculé ? Par exemple, quand je calcule la somme des éléments d'une liste d'entiers, j'attends une liste d'entiers non vide (pré condition), la variable sum vaut la somme des éléments déjà parcourus, et si tout s'est bien passé, on peut tester sur autant d'exemples qu'on veut que la somme calculée est bien la somme attendue. La même qualité est valable pour de la donnée, et pas seulement pour du code :

  • Dans les pré conditions,  le classique souci de l'encodage, cette éternelle tarte à la crème des fichiers qu'on déplace, et donc aussi des tables externes en Hive. Je ne m'étends pas sur ce sujet, trivial quant à l'analyse, mais pénalisant sur les conséquences. Il pose une première question organisationnelle : l'équipe qui maintient la source doit elle fournir des données à l'équipe lake dans l'encodage qu'elle émet d'habitude, et laisser les data engineers se débrouiller, ou est ce que le fait que le lake soit central implique t'il de laisser choisir l'équipe qui le porte ?
  • Dans les invariants : en particulier avec le big data et la notion de schema on read, cela veut dire que le schéma que l'on plaque sur la donnée est le bon.  Sur toutes les tables ou fichiers, et à tout moment. Je vous entends ricaner d'ici en me rappelant que c'est toujours le cas. En fait, pas du tout. Imaginez que vous rajoutez un champ calculé dans un CSV à compter de telle date, disons le 1/1/2010. Mais voilà qu'au 1/1/2015, vous n'avez plus besoin de la donnée, et vous arrêtez de la calculer. Parce que le client s'oppose à une reprise, pour des questions de temps, vous feintez en supprimant de vos méta données la dernière colonne. Le 1/1/2017, vous ajoutez une autre colonne, et donc, une nouvelle colonne. PATATRAS : si vous requêtez vos vieilles données, disons celles de 2010, vous avez l'ancienne colonne qui est interprétée comme de la nouvelle ! L'invariant le plus problématique, c'est de garantir que les méta données collent tout le temps aux données.
  • Dans les post conditions, c'est aussi un dilemme, illustré avec le fameux "shit in, shit out" : l'équipe du data lake s'engage à ce que la qualité de la donnée ne soit pas dégradée par le traitement, c'est à dire que si la donnée se révèle pourrie en entrée, la responsabilité de la correction ne sera pas portée par l'équipe. La pratique n'est pas celle ci, en tous cas pas sur les cas client dont j'ai connaissance : l'équipe source n'a pas d'extra de budget pour gérer l'arrivée du data lake, donc toutes les corrections sont portées par l'équipe data lake, qui va consommer "en sous marin" du temps aux équipes sources ou aux métiers liés pour comprendre la correction à apporter. La loi semble toujours celle ci : la correction est à la charge de l'équipe qui a le budget. Corollaire évident : la masse de code dupliquée au niveau global puisqu'il reste probable que l'équipe source ait à faire aussi la correction...

La notion de qualité logicielle s'applique de manière plus générale à la donnée. La donnée est du code comme un autre. 

Non mais d'accord, mais qui corrige mon bug ?

Je propose donc ceci :

  • l'équipe source est la seule à fixer les modalités d'export : elle fournit la donnée à ses conditions, à sa fréquence, avec ses méta données. Point. Elle est non seulement la mieux placée pour le faire, et elle a de plus le budget pour maintenir le code. L'équipe data lake va s'adapter, même si l'équipe source change dans la foulée les modalités d'échange de la donnée. Par exemple, alors que les data engineers croient encore que l'utf-8 est le seul encodage possible, il devra mettre en place de quoi accueillir de l'us-ascii et autres éléments dignes du musée du logiciel.
  • l'équipe data lake n'est responsable que de la transformation de la donnée. Si la source envoie des données fausses, la correction incombe à la seule équipe source. Ceci parce qu'elle en est garante, et parce que son budget fait qu'elle doit le faire. Elle peut payer pour déléguer la correction dans le data lake client. C'est le point le plus problématique parce que l'équipe source a sa propre feuille de route, n'a pas connaissance toujours du bug en question (ou est convaincue que ce n'est pas un bug...), et va avoir une latence énorme sur l'équipe big data, à qui en général on colle une forte pression et des objectifs délirants du fait du budget mis sur la table pour le faire marcher. Il faut qu'elle soit claire dans sa communication : elle est comme le tuyau qui amène l'eau, elle ne gère pas la qualité de l'eau, mais elle s'engage à ne pas dégrader celle ci dans le transport.
  • l'équipe big data assume de garantir l'historisation des données et des méta données. En conséquence, elle garantit toujours que les méta données collent aux données, y compris à des dates antédiluviennes. Le problème d'invariant est réglé par l'équipe big data, parce que la seule responsabilité de l'équipe source est de garantir, à un moment donné, que les méta données et les données soient cohérentes. Toute la subtilité est "à un moment donné". Le rôle de l'équipe big data est de passer d'une vérité "à un moment donné" à une vérité vraie tout le temps. Pour cela, si une source ajoute une colonne, l'équipe le répercute et fait la reprise pour avoir une valeur par défaut sur toutes les dates précédentes.
 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.