Data lake et Dataviz au secours des Data Scientists 2/2

Data lake et Dataviz au secours des Data Scientists 2/2

Nous distinguons généralement 2 étapes dans la recherche, la recherche des données pertinentes et l’exploration de ces données.

L’outillage pour l’exploration des données

La recherche des données pertinentes dans un contexte multi-entrepôt comportant des centaines de tables et de relations peut constituer un véritable défi que nous adressons avec différents types d’outils selon les contextes et l’existant :

Moteur de recherche : la solution idéale fonctionnellement, bien que techniquement complexe, consiste à « câbler » un moteur de recherche de type Lucene (SOLR ou Elasticsearch) sur les entrepôts de données qu’ils soient SQL ou Nosql. Ces moteurs indexent toutes les informations et offrent un service de type Google dans lequel l’utilisateur peut chercher les données soit par leur contenu soit par leur description. Ces indexations peuvent être enrichies par exemple par des taxonomies (ex : compteur->linky) ou des paramétrages de pondérations (ex : proximité des noms des relais électriques surpondérée par la distance géographique).

Dictionnaire de méta-données : tous les ETL proposent une solution plus ou moins élaborée de dictionnaire de données qui permet aux utilisateurs d’effectuer des recherches sur les méta-données (les données sur les données).

Base documentaire : en dernier ressort, une base documentaire pourra être utilisée en référence pour rechercher les données pertinentes.
Une fois les données pertinentes identifiées, l’exploration à proprement parler consiste d’une part à en établir une description (moyenne, répartition, complétude, qualité des jointures…) et à en extraire des éléments signifiants (corrélations, cooccurrences, patterns temporels…). Cette phase exploratoire est généralement un préalable qui va orienter l’étape de modélisation, voire une étape intermédiaire de datamanagement pour élaborer des agrégats ou effectuer des opérations de nettoyage.

Pour l’exploration des données, nous nous appuyons la plupart du temps sur 3 types d’outils :

Business Intelligence : des outils tels que SAP BI ou Microstrategy permettent d’explorer des données au travers de liens (jointures, foreign keys…) et de facettes (dimensions et indicateurs) la plupart du temps explicites et prédéterminés.

Dataviz : les outils de datavisualisation (Qlikview, Tableau, SAS Visual Analytics et consorts) développent le principe de « Self-Service BI » en ouvrant aux utilisateurs la possibilité d’expliciter par eux-mêmes de nouveaux liens ou de nouveaux indicateurs, voire des traitements de transformations ou de redressement de la qualité. Ils offrent également des modes de visualisation facilitant la détection visuelle d’éléments signifiants (ex : un point anormal ou un arbre de segmentation).

Analytique : les outils analytiques (R, SAS, SPSS et consorts) interviennent également parfois dans les phases exploratoires lorsque les outils précédents présentent des limites fonctionnelles ou techniques. Il s’agit non pas d’exploiter à ce stade la puissance de leurs algorithmes statistiques mais simplement leurs fonctions de datamanagement et d’automatisation des étapes.

Bacs à sable utilisateurs et agilité

Que ce soit à des fins de reporting, d’exploration ou d’analyse, les DSI n’arrivent plus à suivre le rythme des demandes des métiers. Dans ce contexte, la solution passe par la mise à disposition d’outils et de données aux utilisateurs pour expérimenter, voire produire, en toute autonomie.

Ces bacs à sable prennent différentes formes selon les organisations mais partagent assez généralement quelques principes :

Accès libre aux données de détail : dans la mesure des droits d’accès (tant en largeur qu’en profondeur), les utilisateurs peuvent naviguer dans les données jusqu’à la ligne élémentaire en tant que de besoin.

Espaces personnels : les utilisateurs disposent d’une zone de stockage qui peut peser des dizaines de tera-octets dans laquelle ils entreposent des copies de données et de résultats de leurs traitements de transformation ou de modélisation.

Autonomie dans les transformations : les utilisateurs sont équipés d’outils qui leur permettent d’enchaîner des étapes de transformation (ex : unpivot, dédoublonnage, cumuls….) de la donnée pour la mettre dans la forme attendue pour les traitements qu’ils envisagent.

Ergonomie et interactivité : les analystes et les métiers doivent pouvoir explorer ensemble les données. Ceci impose une bonne ergonomie des outils, que ce soit pour la visualisation ou l’analyse. Compte tenu des volumes en jeu, il est également nécessaire que les outils permettent de travailler sur des sous-ensembles de données pour faciliter l’interactivité et éviter des temps d’attente trop importants lors des ateliers.

Chargement de données externes : la performance des modèles est souvent liée au croisement de sources de données diverses. En particulier, il convient de donner aux utilisateurs des outils et des autorisations pour charger par eux-mêmes, moyennant des règles de sécurité d’entreprise, des sources externes (ex : météo, trafic…) sous les différentes formes qu’elles peuvent prendre (ex : excel, csv, xml, Json…).

Capacité à créer des liens : au-delà des jointures et autres clés externes prédéterminées, l’utilisateur doit disposer des moyens de constituer ses propres liens sans avoir à passer par un tiers. Il s’agit là d’un facteur essentiel pour développer réellement l’agilité et l’autonomie des analystes.

Outils intégrés pour l’industrialisation : le passage d’une phase de modélisation sur le bac à sable à un algorithme industrialisé applicable en batch ou en temps réel doit être outillé dans une logique Devops. C’est pourquoi les outils proposent des fonctionnalités de génération de Webservices (ex : SPSS Cads) ou d’ordonnancement de tâches (ex : Qlikview).

Méthode agile : sans nécessairement respecter stricto sensu la méthode agile, l’objectif est de s’en inspirer ; travail par atelier réunissant métier, analyste, voire datamanager ; délai court des itérations entre chaque atelier…

Conditions de succès d’une démarche exploratoire

Une démarche exploratoire mobilise quatre compétences :

  1. Métier, pour la formulation du problème à résoudre et des contraintes imposées à la solution.
  2. Datamanagement, pour accéder à la donnée, l’explorer et effectuer les transformations nécessaires que ce soit par de simples requêtes (ex : SQL), le paramétrage de progiciels (ex : SAS Miner) ou la programmation de routines (ex : Python).
  3. Statistiques ou mathématique, pour réaliser les modèles supervisés (ex : score) ou non supervisés (ex : nuées dynamiques).
  4. Gestion de projet, pour planifier puis coordonner les différentes activités et ressources (ex : mobilisation de puissance de traitement dans le cloud) dans le temps.

Selon l’organisation et la complexité des cas d’usages, ces compétences sont réparties sur une à plusieurs dizaines de personnes. Avant même la compétence intrinsèque des participants, c’est leur capacité à collaborer efficacement qui constitue le principal facteur clé de succès d’une démarche exploratoire.

Confiance et reconnaissance mutuelles sont les fondements pour une bonne collaboration et ils passent par des qualités de professionnalisme, telles que clarté des engagements pris, respect des jalons et qualité des livrables.

Il est ensuite essentiel que chaque participant ait au minimum un vernis sur les 3 autres domaines d’expertise pour fluidifier le dialogue et éviter que des incompréhensions n’aboutissent à des pertes de temps ou d’énergie.

Par ailleurs, tout ce qui pourra contribuer à l’autonomie de l’équipe (outils, moyens de communication, accès aux données, capacité intrinsèque de décision…) fluidifiera d’autant les processus et donc l’efficacité de la production.

Enfin, la disponibilité d’un vivier de référents experts capables d’orienter les intervenants sur des problématiques spécifiques pointues (ex : choix d’une méthode, optimisation d’une requête…) permettra d’accélérer le travail des intervenants et de baliser leur parcours de bonnes pratiques.

Revoir la présentation « Le Data Lake : révolution de la data science, complément au Data Warehouse ou simple buzz marketing ? »

Ecrire un commentaire

* Name, Email, Comment are Required