Si la définition de "big data" passe par la variété, c'est un concept bien plus riche que "plusieurs sources de données". Panorama dans cet article.

La variété n'est pas seulement avoir des données de plusieurs types, puisque n'importe quelle source de données contient plusieurs entités. D'après cet article, ce serait son niveau de structuration. Et bien non, pas d'accord, en tous cas pas seulement. Il s'agit aussi de la difficulté structurelle de relier les données ensemble. Par exemple, un de nos ex clients était suffisamment riche pour se payer trois CRM répartis dans ses agences en France. Chaque CRM avait sa propre structure, et unitairement, la donnée était parfaitement compréhensible. Cela pose évidemment la question de regrouper ces données, qui sont unitairement structurées, avec une structure globale et partagée :

Une fois le modèle choisi, il reste tout le travail, au cas par cas, qui consiste à intégrer les données reçues pour les faire "coller" au modèle commun choisi:

Donnez moi mon ID!

Un retour d'expérience vaut mieux qu'un long discours. Il fut un temps lointain, très lointain, dans une mission lointaine, très lointaine, où un spécialiste de marketing automobile travaillait à la question suivante: dans son SI, il y avait plusieurs applications, avec des informations clients dans chacune. Il mit en place un data lake et donc, se posa la question de trouver ses clients et leurs voitures dans plusieurs sources de données. C'est finalement assez simple: chaque client a un ID local dans un premier temps, on calcule un ID global, et on change tous les ID locaux en les remplaçant par les ID globaux. Et donc... Quand deux personnes sont elles les mêmes, avec les informations dont on dispose? Si vous n'avez ni date de naissance, ni numéro de sécurité sociale, quand décider que deux "Marcel Martin" sont les mêmes? Autre exemple, en 2009, les plaques passèrent d'un format français à européen, mais les véhicules ne changèrent pas de possesseur. Question: quand peut on dire que deux véhicules sont en fait les mêmes? Pas par la plaque manifestement! La variété en fait pose aussi la question des règles métier, voire d'heuristiques, qui permettent d'attribuer un ID unique à une entité qui n'apparait pas de manière unique dans un SI. 

Quand les méta données changent

Vous avez plusieurs sources de données, et bien évidemment, vous les intégrez sur une base régulière, disons tous les jours. Puis, un beau jour, ou peut être une nuit, près d'un lake, vous apprenez que l'application "clients" change sa structure de données. Vous avez passé un temps colossal sur l'attribution des ID avec les noms, prénoms et adresses, et ils intègrent à présent les numéro de sécurité sociale. Vous allez avoir plusieurs questions à régler:

  • d'abord, modifier vos méta données pour que le nouveau champ soit visible (s'il est ajouté) ou remplacé (s'il est supprimé). Vous avez deux solutions. La mise à jour incrémentale consiste à migrer la donnée quand elle est accédée la première fois, et à sauver la donnée sous le nouveau format à la première insertion ou mise à jour. Intéressant sur le papier, mais d'une complexité énorme dans le code. Parce que, vous vous doutez bien que les mises à jour sont d'autant plus nombreuses que vous avez de sources. Vous pouvez réaliser un travail de migration d'un coup, avec une indisponibilité temporaire le temps de changer les données. Cela reste un problème d'ingénierie classique, pas de souci. La vraie difficulté réside dans tout le code qui appelle la donnée, et qui doit être changé pour tenir compte du nouveau format. Parce que, comme une API, une méta donnée est un contrat fort qui vous lie aux applications qui utilisent vos données. Ne pensez pas qu'une solution "magique" d'introspection sur les données soit la solution ultime. Vous allez développer un couteux et inutile moteur d'interprétation de vos données, alors que souvent, le métier attend des champs précis.
  • ensuite, garantir la cohérence de la donnée avec l'ancien modèle. Si l'ID que vous avez attribué est incohérent avec l'ID de la sécurité sociale, vous allez mettre à jour des utilisateurs différents. Par exemple, sur la base du nom, Martin Durant de numéro de sécurité sociale 1 81 00 et Martin Durant de numéro de sécurité sociale 1 79 08 sont la même personne. Sur le numéro de sécurité sociale, c'est manifeste que ce sont deux personnes différentes. Un beau jour, le premier se plaint que son numéro de sécurité sociale n'est pas le bon, et vous faites la mise à jour. Patatras, vous assimilez le premier au second, et c'est le drame, vous perdez un citoyen Français de votre base de données...

A ce sujet là, un client a mis en place un dictionnaire des données. Il a constaté rapidement qu'il y avait une demande forte pour avoir l'information sur les méta données, mais que les personnes chargées de la mise à jour trouvaient la tache pénible, et finalement, bâclaient le travail. Si vous avez en effet une nouvelle table avec 500 champs, vous allez être assez succinct pour commenter chaque champ.

Les workflows

Sur la variété encore plus qu'en temps normal, de nombreuses sources de données disparates sont intégrées à un rythme supposé régulier. Ce sont donc des workflows qui vont ordonnancer ce petit monde. C'est une d'autant meilleure idée qu'il y a des dépendances évidentes si vous voulez réconcilier vos données de manière régulière les unes avec les autres. Or, vous pouvez dépendre d'un prestataire extérieur pour une source, et comme personne n'est infaillible... Vous aurez à réaliser un suivi approfondi des flux entrants, des jobs de retravail de la donnée, et bien évidemment, du suivi des méta données.

Conclusion

Un lake n'est pas un dépotoir! La variété est un travail constant pour bien gérer ce qui rentre comme donnée. Par exemple, si une source vous déverse deux tables relationnelles, c'est bien à l'application source de prendre à sa charge les jointures! La donnée arrive propre, pour que ce qui reste à la charge de l'équipe soit simplement la réconciliation des données. Pas de travail de nettoyage, pas de travail de mise à jour des méta données, uniquement croiser les informations.

 

 

Comments are closed.

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