Dans ce chapitre, nous avons introduit le concept des lacs de données, fait un état des lieux des travaux de recherche mais aussi industriels sur le sujet, donné notre définition des lacs de données et précisé les enjeux qu’ils représentaient.
Nous avons établi notre point de vue, basé sur des analyses fines et poussées des divers documents et travaux sur le sujet, mais aussi étayé à partir de constatations faites avec des collaborations industrielles, sur ce concept.
Nous avons proposé de considérer les lacs de données comme un nouveau composant du système d’information, qui comprend déjà le système décisionnel. Nous avons par ailleurs positionné les lacs de données vis-à-vis des systèmes décisionnels pour justifier ce positionnement.
Partant de cette hypothèse, nous avons appliqué aux lacs de données, une démarche d’urbanisation pour démontrer que les lacs de données sont bien un concept d’architecture, et non une implémentation spécifique (Apache Hadoop).
Nous avons établi quelles sont, selon notre point de vue, ses fonctionnalités, en mettant l’accent sur la constitution et gestion du catalogue des méta-données et sur l’aspect gouvernance des données.
Après avoir énoncé que le lac des données EST un concept d’architecture, notre sujet de question- nement se pose sur les éléments qui peuvent influencer sa conception et peut-être remettre en cause certains postulats d’architecture.
Notre intérêt s’est porté sur l’étude de la relation donnée-traitement, et un facteur potentiellement in- fluant, appelé, gravité des données. Après avoir défini ce que nous entendons par gravité des données, nous étudions dans le chapitre suivant, au travers d’un cas d’usage industriel, l’influence de ce facteur sur l’architecture des lacs de données.
Influence de la gravité des données
dans l’architecture des lacs de
données
Dans le contexte industriel, les architectes d’information ont en charge la gouvernance, la conception et l’outillage technologique de ces lacs de données. L’architecture d’information qu’ils doivent mettre en place doit prendre en compte conjointement des contraintes fonctionnelles mais aussi non fonctionnelles. De par l’important volume de données à traiter, la diversité des formats de ces données mais aussi leur coût considéré comme peu élevé, la technologie de type Apache Hadoop s’est imposée comme référente, quasi unique, occultant les discussions sur l’impact des contraintes non fonctionnelles sur ce choix. Cette technologie comme solution unique pour les lacs de données est désormais remise en cause [66][49] par le monde industriel et des architectures hybrides, avec introduction de technologies complémentaires à Apache Hadoop, sont désormais envisagées.
Notre intérêt académique se porte sur les facteurs pouvant influencer cette hybridation technologique mais aussi applicative dans les lacs de données, sous l’influence des données massives.
La relation donnée-traitement à l’intérieur du lac de données a retenu notre attention car aucune contrainte non fonctionnelle liée à cette relation ne semble affecter l’architecture des lacs de données et aucune littérature scientifique ou industrielle n’y porte une grande attention, encore.
En vue de mieux appréhender cette relation donnée-traitement, nous nous sommes intéressés aux travaux l’étudiant dans un contexte non lié aux lacs de données. Nous avons découvert les travaux de MacCrory [46] qui introduisent la notion de gravité des données et étudient sous cet angle la relation donnée- traitement.
Nous émettons l’hypothèse que cette notion de gravité des données [45] peut être considérée comme une contrainte non fonctionnelle si elle est étudiée dans un cadre de conception d’architecture.
Partant de cette idée, un des objectifs de nos recherches en cours consiste à compléter la définition de [45] afin d’étudier son impact sur les architectures des lacs de données et d’en évaluer son intérêt. Nous vérifions nos hypothèses au travers la réalisation d’une étude d’architecture d’un cas réel de lac de
Figure5.1: Formule de MacCrory sur la gravité des données
données en milieu industriel.
5.1
La gravité des données
Les travaux de McCrory [45] s’attachent à établir une analogie entre la gravité des données et la gravité au sens physique. Pour cela il étudie la relation donnée-traitement, et, par un parallèle de raisonnement avec l’attraction physique, définit une force d’attraction entre les données et les traitements. La translation de la formule physique, dans le cadre des données est indiquée dans la figure
5.1.
La loi de la gravité stipule que l’attraction entre les objets est directement proportionnelle à leur masse. Pour établir son analogie, il émet l’hypothèse que la masse des données est liée à leur volumétrie. Il "invente" alors le terme de gravité des données pour décrire le phénomène dans lequel le nombre (ou la quantité) et la vitesse à laquelle les services, les applications, et même les clients sont attirés par les données, augmentent à mesure que la masse des données augmente.
À mesure que les données s’accumulent (leur volume augmentant on construit une masse), il est supposé que des services et des applications supplémentaires peuvent être attirés par ces données.
Le phénomène de gravitation peut alors être appliqué : les données voient leur gravité augmenter et devenir de plus en plus importantes, elles vont alors attirer les traitements à elles.
en définissant quels sont les facteurs à y inclure. Pour MacCrory[45] c’est le facteur "volume" qui est le plus influant dans la gravité des données. Il ouvre cependant la porte à d’autres paramètres pouvant influencer cette gravité tels que la sensibilité, le trafic du réseau, le coût, etc.
Dans un premier temps c’est le facteur "volume" qui a retenu notre attention car nous étudions l’impact des données massives sur le système d’information et en particulier les lacs de données.
En étudiant les travaux de Walker-Alrehamy [3], qui s’appuient eux aussi sur ceux de (McCrory, 2010), un autre facteur semble lui aussi influencer la relation donnée-traitement, le facteur "sensibilité". Le cadre de leurs travaux est un lac de données fonctionnellement dédié aux données personnelles.
L’évaluation de la gravité des données, au travers de la masse des données (peu importante dans ce cas d’étude) n’est pas le paramètre le plus influent, mais celui de la sensibilité des données. Ce facteur va « peser » plus dans l’évaluation de la gravité des données, que celui du volume. Leur lac de données dédié aux données personnelles va avoir une sensibilité si forte, qu’il va attirer à lui les traitements devant manipuler les données qu’il contient. Les données ne seront donc pas déplacées vers les traitements. Pour Walker-Alrehamy [3] la sensibilité est un des facteurs rentrant en compte dans la gravité des données. Ces différents travaux [3] [46] montrent que le volume et la sensibilité des données, que l’on inclut dans la gravité des données, peuvent influencer la relation donnée-traitement. Les architectures des lacs de données existantes sont basées sur l’acquisition de données, sur lesquelles les traitements d’exploration et d’analyse (par exemple) vont s’appliquer. Il n’est pas envisagé que les traitements des lacs de données se déplacent vers les données produites. Notre hypothèse est que si on prend en compte la gravité des données, le traitement des données du lac peut, selon le cas, potentiellement se déplacer où résident les données et non pas le contraire.
En architecture d’information, les paramètres qui composent cette gravité définie par [46], tels que le volume et la sensibilité, sont considérés comme des éléments de contraintes non fonctionnelles. Cela nous amène à considérer la gravité des données comme étant une contrainte non fonctionnelle, à évaluer lors de la conception des lacs de données.
C’est là, notre première proposition de ce chapitre : considérer la gravité des données comme une contrainte non fonctionnelle.