Le but de l'article n'est pas de parler de ce mouvement fort intéressant qu'est le devops, mais plus de montrer l'analogie avec le (dur) métier de data engineer. Merci à Patrick Allain et Cécile Hui Bon Hoa pour vos analyses !

Premièrement, le RETEX que l'on peut faire est que, par nature, le data engineer est un devops : le tuning d'un job spark, disons, nécessite des optimisations pour ne pas mettre le cluster à genoux localement (par la seule présence du nouveau job en provoquant un plantage net) et globalement (en allouant le minimum possible pour que le job aille vite, afin que le cluster ait la possibilité d'accueillir de nombreux autres jobs). C'est donc une MEP par essais et erreurs, sur la base d'essais fréquents jusqu'à ce que le job termine sans lever d'out of memory exception, et dans des conditions raisonnables de temps.

Deuxièmement, un data lake, c'est fondamentalement des sources de données qu'on met au même endroit, et qui ont leur vie propre. Donc, ça implique un besoin de réactivité accru pour impacter les changements des sources. Mathématiquement, c'est imparable : si vous avez 30 sources de données, que chacune réalise une modification structurante par 3 mois, vous vous retrouvez avec 4 * 30 = 120 changements structurants par an, soit une moyenne de 10 changements par mois à prendre en compte coté data engineers. Donc, la demande des data engineers est la stabilité des sources. Et coté sources, elles souhaitent avoir la liberté de modifier leurs données et leurs méta données à leur guise, en ayant le moins de friction possible avec l'équipe data lake. Celle-ci se matérialise concrètement par la question de la reprise de données, qui n'est pas du tout transparente pour les sources. Prenons un exemple simple : une équipe de ventes voit son cadre métier changer, intégrant des ventes d'un nouveau type. Pas de problème dans les données, seul le volume change. Coup de fil d'un analyste paniqué qui voit son modèle s'écrouler, et appelle l'équipe des data scientists, qui repasse la balle aux data engineers suivant cette grande loi de l'entreprise : c'est toujours le dernier chaînon de la chaîne des responsabilités qui est le premier à devoir rendre des comptes. Et là, une analyse montre qu'une équipe source a brisé un invariant métier sans évidemment prévenir personne. Malaise coté data lake, qui repasse la patate chaude à l'équipe source, qui bien sûr va expliquer que c'est un besoin métier super important, et qu'elle n'a fait que son travail, et que de toute façon, c'est son scope métier, sa donnée, et qu'elle fait ce qu'elle veut ! Zut alors ! Et vous l'aurez compris : c'est exactement le mur de la confusion !

 

Ce qui amène à une première analogie : dev = application source et ops = data engineers qui gèrent l'infrastructure du data lake. Les ops ne sont pas responsables de la partie applicative, ils décident d'ajouter une application si celle ci ne met pas en péril la stabilité du système. De même pour un lake, si une source est intégrée, personne n'a le temps de vérifier exactement que chaque donnée exportée est correcte : pas la source qui a a priori confiance en son travail, et pas l'équipe lake car elle n'a pas le temps de rentrer dans le détail applicatif fin de chaque source, sauf dans le cas précis d'avoir une ou deux personnes dédiées, ce qui n'a jamais été vu de mémoire. Par contre, la position du data lake en tant qu'outil central implique qu'il est, d'une manière ou d'une autre, responsable de la qualité de la donnée qu'il contient. Sa criticité le rend responsable, et le prive de la facilité de se cacher derrière l'équipe source. Enfin, son budget, plombé par son infrastucture, le rend responsable parce qu'on estime que si on paie cher, on a une qualité irréprochable.

Dans le contexte du DEVOPS, la quadrature du cercle se résoud en gardant son CALMS :

  • Culture différente qui implique tous les acteurs d'un projet. A ce titre, la conséquence la plus évidente pour le big data est d'arrêter de séparer les équipes sources et lake, en estimant que la source doit garder sa vie et que le lake n'est qu'une sangsue qui vient se greffer sans gêner son hôte. Non, le lake est un projet d'entreprise, son rôle est de garantir la tuyauterie, et le rôle de l'équipe source est de garantir la donnée. Donc, il faut impliquer l'équipe source en ne lui fournissant que les infrastructures et conseils techniques pour verser ses données dans le lake. Par exemple, en la formant à SQOOP ou Kafka, en écrivant un connecteur pour elle, et en l'aidant techniquement à verser ses données. Pas plus. La source reste responsable de sa donnée, c'est elle qui la fabrique. L'équipe lake la garantit dans le temps et fournit son historisation, c'est tout.
  • Automatisation : alors, à ma connaissance, l'automatisation du versement de la donnée est chose aisée, à condition que la structure de celle ci ne change pas. Pas d'automatisation de la gestion de la méta donnée encore, celle ci relevant encore d'un savoir intellectuel et d'une réflexion aboutie (mettre NULL par défaut n'est pas une réflexion aboutie).
  • Lean : c'est bien l'ensemble du flux qui est concerné, donc tout le trajet du versement. De même, ce n'est pas parce que le lake dispose d'une capacité disque énorme qu'il ne faut pas se poser la question de l'usage de telle source de données, et la dégager au besoin. Si le mandat du lake est d'archiver, pas de problème. S'il est de centraliser de la donnée pour le métier, supprimer un flux devrait être aussi simple et peu coûteux que de supprimer une table sur une application.
  • Mesure : alors, parlons de la mesure de la qualité de la donnée. L'invariant d'un lake est aussi de fournir de la donnée utile au métier. Passons sur les éléments évidents de fréquence, de volume attendu, et que sais je encore. La qualité de la donnée se mesure en termes de respect statistique des contrats implicites de la donnée (comme en programmation par contrat). Par exemple : tel champ de telle table est non nul, quelle est la proportion de lignes qui le vérifie ? 100% ? Parfait. Combien d'éléments de la table ventes correspondent encore aux éléments de la facturation en vertu de la clé fonctionnelle truc - chose ? 92% ? Mais 100% depuis 2004, date de MEP de tel système ? OK, on comprend. C'est expliqué mais pas terrible.
  • Partage (Share) : le lake n'est pas la chasse gardée d'une équipe de spécialistes du big data, payée en moyenne 10k€ de plus que leurs collègues, tout ça parce qu'ils connaissent spark et hadoop. Le lake est une infrastructure dont le rôle est de collecter, distribuer et utiliser de la donnée pour offrir à une entreprise une vision plus transverse et plus utile que chaque source prise isolément. Sans source, pas de lake. Sans lake, une souffrance sans nom des équipes sources pour partager leur donnée. Le partage implique donc de prévenir le lake quand les invariants des sources changent, d'aider les sources à monter en compétence technique sur le big data, à avoir une meilleure quantité et surtout qualité de la donnée.

Conclusion

Elle sera courte, l'article tenant déjà du pavé. Le devops est une source d'inspiration sur la mise en place d'un lake. C'est toujours une catastrophe si les équipes sources et lake sont séparées, la source estimant que le lake n'a pas à lire leurs données et à leur faire des retours au détriment de leur liberté métier et technique, et le lake estimant que la source change tous les matins d'idée et de structure. Cette idée n'a aucun sens, et il faut que le lake fasse grandir la source pour qu'elle soit la plus à même de verser elle même sa donnée.

 

 

 

Comments are closed.

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