Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!!








télécharger 28.75 Kb.
titreAu risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!!
date de publication03.02.2018
taille28.75 Kb.
typeDocumentos
ar.21-bal.com > documents > Documentos
Big data : soyons un peu réalistes…
Par Claude Marson
Contrairement à ce que veulent faire croire les tenants du « yakafokon », la mise en œuvre d’un projet de « big data » est avant tout un projet technique, qui nécessite de disposer de compétences diverses, que l’on ira chercher dans d’autres domaines, celui de la qualité des données, des frameworks d’interfaçage, de la gestion de fichiers adossée à des architectures de clusters, voire de l’algorithmique de parallélisation des traitements. C’est tout sauf simple et ce genre de projet s’apparente plus à un montage de datawarehouse, voire d’une SOA, des sujets dont on nous avait promis monts et merveilles et qui, soit n’existent pas (SOA), soit ne s’appliquent qu’à des domaines très restreints (datawarehoue/datamart).

Au risque de refroidir les ardeurs de quelques DSI, le temps semble venu de se remettre les idées en place !!!

Personne ne le nie, l’avenir appartient aux « big data » et à leur capacité de nous connecter à tout ce qui bouge sur la planète. A nous les liens temps réel vers les réseaux sociaux pour importer l’ « humeur » des internautes. A nous les connexions vers les sites métiers pour remplir nos bases de données des informations professionnels qui feront la différence vis-à-vis de nos concurrents. Tout le monde est d’accord là dessus, l’avenir s’annonce radieux.

Sauf, qu’on a oublié que mettre en œuvre ces fameuses « big data » s’avère être une opération extrêmement délicate. Comme si tout le monde avait perdu de vue que la planète est un sacré capharnaüm et que toute tentative de fédération – car c’est bien de cela qu’il s’agit – se heurtera inévitablement à des contraintes techniques, très difficiles, sinon impossibles à surmonter.

Alors plutôt que de nous bercer de rêves inaccessibles, voyons les choses un peu plus concrètement, au ras de nos machines…et de nos compétences.

Quatre problèmes distincts
Les « big data » sont fondées sur deux grandes idées : la diversité des sources de données - on pourrait presque parler d’éclatement de ces sources – et leur volumétrie. On ne parle plus ici de giga, voire de terra octets, mais bien de penta et de zetta octets. Autrement dit, des volumes de données tels, que le plus puissant des SGBD relationnels, partirait inévitablement « en vrille », dés lors qu’il leur serait confronté.

Les projets estampillés « big data » se heurtent inévitablement à quatre natures de problèmes: la production des données et leur importation, leur qualité et représentativité, leur gestion logique et stockage dans des structures adéquates et les traitements en aval de ces infrastructures.


Quatre natures de difficultés à connotation très techniques
Les cercles vertueux d’importation des données
Dés lors que l’on veut constituer un entrepôt « big data », il faut l’alimenter avec des données de production ou issues des univers nouveaux qui leur sont propres. Et c’est là que se situe le premier écueil.

Les deux grandes différences avec un entrepôt traditionnel étant par ailleurs que les données ne sont pas nécessairement structurées, au sens où on l’entend dans une base de données et qu’il n’est pas obligatoire de les organiser selon des dimensions.

La première tâche que devra assurer le chef de projet « big data » sera donc d’importer les données nécessaires à son socle, données qui lui viendront d’horizons et de formats très différents.

Tout le monde fait comme si le problème était résolu. Erreur.

Les données susceptibles de peupler ces entrepôts « big data » viennent en fait de sept « cercles vertueux » et le moins que l’on puisse dire, c’est que pour au moins deux d’entre eux, la tâche ne sera pas simple.

Au niveau 0, il s’agit de données parfaitement structurées, issues de bases de production ou de nomenclatures, au sens où on l’entend dans une architecture MDM (Master Data Management). Autrement dit les données patrimoniales sur lesquelles l’entreprise fonde son activité. De ce point de vue, pas de problème. On est en terrain connu, les données sont cadrées, protégées et référencées dans un annuaire, qui en fournit une description sémantique non ambiguë.

Au niveau 1, on trouve des données issues d’applications internes (ou cloud), là encore structurées. Avec toutefois un petit bémol, car il faut être sûr que l’application de « peuplement » pourra y accéder sans passer par des outils standards ou transactions propres aux applications. Ce qui est loin d’être toujours le cas.

Au niveau 2, on trouve les données générées par des partenaires ou l’administration (Open Data). Normalement, ceux-ci font bien leur travail et il ne sera pas compliqué d’en construire une interface pour les récupérer.


L’interfaçage avec les sources externes peut s’avérer très vite insoluble
Les niveaux 3 et 4 sont constitués des données issues de plates-formes externes, émises sous forme de fichiers XML. En se basant sur les schémas vers lesquels ils pointent, il est facile de n’importer que les données utiles, en levant l’ambigüité sur leur format d’origine.

Le niveau 5 entre à peu près dans ce cadre, qui permet notamment d’accéder aux données émises par la bureautique interne (XML) et à celles exposées par des applications cloud, en mode SaaS.

Le niveau 6, celui que l’on associe généralement aux « big data », regroupe les fournisseurs sur lesquels nous n’avons aucune emprise : les réseaux sociaux, la presse, les nombreux blogs et autres supports de micro-blogging, tels que Twitter. Remontée qui se fera bien entendu en temps réel, au gré de l’humeur des internautes.

Alors, puisque c’est si simple, comment se fait-il que les applications qui se réclament de ce procédé soient si peu nombreuses ?

Accéder par exemple aux contenus Facebook, pourtant la cible privilégiée, est déjà une opération délicate. La firme de Marc Zuckerberg propose bien une API, accessible en Javascript (via JQuery, entre autre), PHP, Actionscript ou Java, qui permet de se « brancher » sur des Web Services Facebook, mais cette API n’est pas performante. Elle est mal documentée, très lente et remplie de bogues malencontreux.

Normalement, elle permet à une application externe de lire le Graph API (Open Graph), qui modélise dans une arborescence, le contenu Facebook en objets : amis, photos, events et pages.

On peut ainsi récupérer pour chaque page, son nom (name), sa catégorie d’appartenance (category), le nombre d’utilisateurs qui ont l’ont aimée (likes) ou le nombre de ceux qui en ont parlé (talking_about_count). L’idéal donc pour se faire une idée de la popularité d’une page et de la pertinence de son contenu. L’objectif étant de l’importer automatiquement dans le support « big data ».

Juste sur le papier, mais beaucoup plus difficile à réaliser concrètement.

Il existe d’autres solutions : internes telles que l’intégration dans un programme PHP, ASP.Net ou Java, de requêtes FQL (Facebook Query Language) ou externes, telles que le module Spring Social pour connecter une application Java au réseau social (module qui appartient au conteneur léger Spring).

De tout cela, il ressort une impression de flou, d’improvisation et de manque de maturité de certaines solutions, avec lesquels le chef de projet devra pourtant se familiariser et qu’il devra maintenir dans le temps. Opération qui s’annonce d’ores et déjà difficile.

Au delà des réseaux sociaux, les vidéos et autres podcasts et enregistrements de webconférences, dont on annonce qu’ils s’intègreront sans effort dans les « big data », ils posent, eux, des problèmes spécifiques, redoutables et sans doute insurmontables.

Ou alors il faudra que l’on nous explique comment déterminer si un fichier .MOV ou .AVI est pertinent et digne de participer à l’effort « big data », sans le visionner au préalable et passer par un travail manuel d’analyse, de rédaction de résumé, d’insertion de mots clés et de catalogage.

C’est faisable, certes, mais pas en appuyant sur un bouton.

Comment s’assurer de la qualité des données
Ce n’est pas tout d’importer des données, parfois d’origines incontrôlées, encore faut-il s’assurer qu’elles sont de bonne qualité et représentatives de ce qu’elles prétendent être…

Et c’est là que le bât blesse.

Certes il existe des outils de gestion de la qualité des données, tels que ceux de Talend, Dataflux (SAS), SAP (BO), IBM, Oracle (Hyperion), Trilium Software, voire Microsoft, mais ils s’appliquent plus à des données structurées, que l’on cherche à valider, nettoyer, voire complémenter, qu’à des données non structurées, souvent textuelles, comme celles que l’on importe depuis un réseau social.

Là, le problème est entier. Certes, on peut toujours construire une usine à gaz, pour retrouver des mots clés dans les flots d’informations et les valider, mais cela obligera la plupart du temps les utilisateurs à écrire du code spécifique…qu’il faudra ensuite maintenir.

Par contre si l’on se contente de données formatées, on pourra s’appuyer sur des outils qui sauront effectuer automatiquement certains contrôles : erreurs, doublons, incohérences, valeurs manquantes ou incomplètes, valeurs crédibles (si le CAC 40 se met subitement à dépasser les 10.000 points…), valeurs obsolètes ou aberrantes, etc.

Ces outils mettent en œuvre, peu ou prou, le même arsenal d’outils :


  • Le profilage ou la découverte, qui consiste à recueillir des informations et statistiques portant sur les données importées : caractéristiques et attributs principaux, usages, état

  • Le nettoyage pour éliminer certaines erreurs et formater les données selon des règles prédéfinies

  • L’enrichissement pour trouver des informations susceptibles de compléter les données existantes

  • Le scoring pour attribuer une « note de confiance » aux données, etc


C’est évidemment plus facile qu’importer et décortiquer un texte apparu dans un réseau social, qui affirme « que tous les opérateurs de télécommunications mobiles sont des gangsters » !!! Quelle confiance lui accorder, quelle est sa représentativité, etc.

Organisations physique et logique des « big data »
En supposant que l’on ait réussi à écrire les couches applicatives pour importer automatiquement les contenus dans notre architecture « big data », il faut ensuite définir la manière dont ces informations seront stockées, logiquement et physiquement, dans une base de données.

La couche logique correspond à la perception que nous (applications) avons de l’entrepôt de « big data », qui induira directement sur les techniques d’interrogation.

Il pourra s’agir d’une base relationnelle, avec le risque de mauvaises performances sur des volumes élevés. Si cette solution est adoptée, elle présentera au moins l’avantage d’une plus grande simplicité d’intégration des données de peuplement.

Pour des questions de volumétrie, ce n’est pas cette solution qui sera retenue.

On adoptera plutôt un paradigme nouveau, celui des bases NoSQL (Not Only SQL), à choisir parmi les bases clés-valeurs (pas d’enregistrements mais des couples clés-valeurs), les bases de documents (les valeurs sont remplacées par des documents), les bases géographiques, les bases hiérarchiques, les bases orientées colonnes ou pour les nostalgiques de l’objet, les bases orientées objets.

Les plus connues, grâce à Big Table de Google et Cassandra d’Apache, sont les bases colonnes, qui permettent d’obtenir des temps de réponse excellents avec des volumes de données gigantesques.

Il n’est écrit nulle part, que la totalité de l’entrepôt « big data » doit être perçu logiquement par une seule de ces organisations. En fait, il y aura fragmentation et l’interface d’accès, portera sur diverses structures logiques, chacune d’elles s’adaptant au mieux à la nature des données enregistrées.

Ce qui ne manquera pas, bien sûr, de complexifier le sujet.


Les couches logiques et physiques des données, ainsi que leur traitement, sont les mieux représentées sur le marché.
Car derrière l’organisation logique, se cachent les API et outils de requêtage, propres à chacune d’elles.

Les bases NoSQL les plus populaires, s’appuient toutes sur un éventail solide d’API, accessibles à partir des principaux langages du marché : Java, Python, PHP, ASP.Net, C# et C++, Ruby, voire des langages plu spécialisés tels que Erlang ou ActionScript (Flash Adobe).

Comme toujours c’est la mise en œuvre de ces API qui s’avèrera la tâche la plus délicate à effectuer.

Au niveau inférieur, l’organisation logique des données, est basée sur un système de fichiers adapté, qui dans le cas des « big data », sera orientée performances.

Ce sont généralement des systèmes de fichiers spécifiques, capables de créer de multiples copies d’un même bloc de données et de les distribuer sur les nœuds d’une infrastructure de clusters, reliés par des connexions très rapides (ce qui exclut habituellement Internet).

Il n’y a pas de lien direct entre l’organisation logique des fichiers et leur stockage physique sur un cluster. Chaque éditeur trouvera dans certaines associations des avantages qui lui sembleront déterminants et fera donc les choix structurants, dont il faudra prendre acte pour apprécier leurs solutions commerciales.

A la limite, on pourrait envisager une base orientée colonnes, comme Cassandra ou Big Table, mais aussi une base SQL Oracle ou une base orientée graphes, telle que NeoJ, qui toutes s’appuieraient sur un même système de fichiers HDFS de Hadoop, GPFS d’IBM ou OCFS d’Oracle. Système de fichiers qui s’avèrera donc le plus souvent transparent pour le développement.

Restera le traitement proprement dit, à effectuer sur ces données distribuées.

Là encore, pour des questions de performances, ces systèmes sont fondés le plus souvent sur un cœur d’exécution, dit « map and reduce », conçu par Google pour ses propres besoins en 2001, qui permet depuis un serveur maître, de découper une tâche en sous-tâches, de les attribuer aux nœuds d’une première couche de nœuds d’un cluster, puis de découper ces sous-tâches en sous-sous-tâches, attribuées cette fois à une deuxième couche de nœuds et ainsi de suite.

Le système « map and reduce » est capable de détecter qu’un nœud est défaillant et de lui en substituer un autre, voire de s’organiser en fonction de la disponibilité et des performances des noeuds du cluster.

Sous sa forme native, « map and reduce » comporte un minimum de modules qui lui permettant de s’adapter aux conditions courantes du cluster, mais la plupart des éditeurs qui ont adopté Hadoop, ont ajouté leurs propres modules à l’API, qui permettent d’aller beaucoup plus loin.

En sens inverse, la fonction reduce permet de faire remonter les résultats de niveau en niveau, jusqu’à la racine émettrice.

Les solutions du marché
La plupart des solutions disponibles sur le marché sont fondées sur le framework Open Source Hadoop, qui dispose d’une position quasi hégémonique.

Les trois principaux éditeurs spécialistes sont actuellement MAPR Technologies, Cloudera et HortonWorks, ces deux derniers se disputant d’ailleurs la paternité de l’outil.

MAPR Technologies est le moins connu, qui vient cependant de se signaler en annonçant une version multiclusters, qui permet à l’administrateur de partitionner un cluster physique en plusieurs clusters logiques et de leur attribuer des tâches différentes.

Les autres grands noms du décisionnel et des infrastructures sont bien entendu présents : IBM, HP, Oracle, VMWare qui propose désormais une solution Serengeti en Open Source, pour permettre aux administrateurs de déployer des nœuds Hadoop dans des conteneurs virtuels, gérés par vCenter, NetApp, Microsoft avec son SQL Server for Hadoop, la division Greenplum d’EMC, ou encore Teradata avec un nouveau langage de requête, SQL-H, qui permet d’attaquer directement les données HDFS, sans oublier Talend qui ajoute au support d’Hadoop sa capacité à évaluer la qualité des données référencées.

Au-delà des fonctions natives de Hadoop, HDFS et Map Reduce, toutes ces solutions apportent leurs lots de compléments : langages de requête, gestion de fichiers pour clusters, interfaces « exotiques », frameworks et méthodes pour paralléliser les traitements, traitement automatique de la qualité, outils de modélisation, etc.

Claude Marson

similaire:

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconEn cette belle matinée d’octobre
«anciens» quelques souvenirs nostalgiques et aux plus jeunes quelques idées sur la vie lycéenne d’antan…

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconL’essence de l’inspiration; du savoir à la pratique
«comment l’art influence les architectes ?» et, «comment les artistes utilisent et représentent l’espace ?». Cependant, après mes...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconNote : les numéros suivis d’un h sont des hors-série tous les bateaux...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconNote : les numéros suivis d’un h sont des hors-série tous les bateaux...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconNote : les numéros suivis d’un h sont des hors-série tous les bateaux...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconRésumé Depuis quelques années, la gestion des risques est devenu...
«danger éventuel plus ou moins prévisible». Le risque fait partie intrinsèque de la condition humaine, à fortiori dans les champs...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconNote : les numéros suivis d’un h sont des hors-série tous les bateaux...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconNote : les numéros suivis d’un h sont des hors-série tous les bateaux...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconDiscours de pierre au service de la monarchie
«gothiques». Les idées italiennes les plus novatrices et les formes françaises les plus «nationales» se trouvent ainsi associées,...

Au risque de refroidir les ardeurs de quelques dsi, le temps semble venu de se remettre les idées en place !!! iconAdresse : ville
«Français, …vous lui devez une place d’honneur à votre foyer», période 2ème gm. Affiche polychrome présentant les portraits officiels...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com