Un parallèle se fait aussitôt dans mon esprit entre les flux de données que nous devons gérer au quotidien et des torrents de montagne impétueux que des humains lilliputiens s’acharneraient à domestiquer. Car le Big Data, c’est avant tout cette pression constante, impérieuse des flux de données : chaque instant qui passe, jour et nuit, (à un facteur cent près…) ce sont des centaines de milliers de lignes de logs qui arrivent, des milliers de fichiers. Nos équipes développent des trésors d’ingéniosité pour canaliser ce flux sauvage : on prévoit des bassins de rétention pour que l’eau puisse s’y accumuler le jour où un canal se bouche en aval, on augmente le débit des artères les plus empruntées… Les travaux sont permanents pour garantir le bon écoulement de ce flux jusqu’au grand réservoir, le « Data Lake » où les données vont pouvoir reposer, enfin apaisées.

De gigantesques entrepôts à long terme, ou « Data Lakes »

En réalité, ce sont même trois « Data Lake » qui nous permettent de stocker les données sur le long cours. Un premier, de très grand volume, repose sur la technologie Hadoop, adaptée pour des données structurées (imaginez-les proches de celles que vous stockez dans un tableur). Il bénéficie d’une gigantesque capacité de stockage, au détriment d’un temps de réponse qui se chiffre en heures. Le deuxième est une sous-partie du premier, bien moins complète, mais qui présente l’avantage d’un index intégré, garantissant des réponses en quelques dizaines de secondes. Le troisième est dédié aux données non structurées, pouvant correspondre à des types de fichiers très divers (textes, audios, images, vidéos, etc…).

Lorsque vous posez une question à l’immense entrepôt Hadoop, celle-ci se divise en une multitude de « jobs », qui vont aller interroger l’ensemble des nœuds de stockage. Une question mal posée, trop ouverte, peut même solliciter excessivement le cluster, le rendant indisponible. Il faut donc prévoir des mécanismes de contrôle des jobs soumis, mais il est essentiel de laisser une grande liberté à certains analystes autorisés. En effet, il est impossible de prévoir à l’avance toutes les questions que les opérations de renseignement amèneront à se poser. Plusieurs outils leurs sont mis à disposition pour créer ces requêtes, allant de simples formulaires dans des applications Web jusqu’à des outils évolués d’édition de graphes combinant des traitements élémentaires.

Des technologies comme Spark permettent de complexifier les traitements réalisables sur Hadoop, ce qui a fait évoluer le visage de ce grand cluster. Initialement consacré au stockage, avec des serveurs choisis pour leurs capacités disque, il doit maintenant aussi disposer de capacités de calcul. Par ailleurs, la technologie Hadoop, de par son fonctionnement, sollicite fortement le réseau, qui devient un facteur de performance essentiel. La sélection des matériels demande alors une réflexion approfondie, basée sur de nombreux critères (cœurs CPU, RAM, IOPS d’accès disque, stockage, réseau…), et vise à atteindre des compromis d’ensemble efficients. C’est d’autant plus important de ne pas se tromper que les budgets atteignent vite des montants élevés, les commandes de serveurs se faisant par centaines. Comme souvent, le dérisquage va reposer sur des tests de « benchmark » que l’on va chercher à rendre représentatifs de la diversité des jobs.

« TROIS DATA LAKES POUR STOCKER LES DONNÉES AU LONG COURS »

Concernant le deuxième entrepôt basé sur un index, ces questions de capacité matérielle se retrouvent également. Mais cet entrepôt va surtout demander un travail de gouvernance pour choisir les champs qui bénéficieront d’une indexation, et définir leur type d’indexation (temporelle, numérique, textuelle, spatiale). La performance des futures requêtes en dépend et les utilisateurs devront être associés étroitement à cette démarche.

Canaliser le Big Data jusqu’au Data Lake

Stocker, oui, mais pas n’importe quoi

On touche là au deuxième enjeu du Big Data : après la gestion du flux massif, l’effort doit se porter sur la maîtrise de la donnée, du point de vue de sa sémantique et de sa qualité. Il ne sert à rien de stocker massivement des données de qualité insuffisante, dont on a seulement une vague idée de la signification. 

Le renseignement étant une histoire de recoupements, les ambiguïtés sur les champs peuvent très vite amener à des erreurs ou à des pertes d’information. Si vous stockez les numéros de téléphone parfois avec l’indicatif pays et parfois sans, vous pouvez arriver à conclure qu’un individu est en contact avec une cellule terroriste alors qu’il n’a aucun lien avec elle. Les types des données doivent donc être standardisés et il faut régulièrement s’assurer par des sondages statistiques que les sources injectant des données respectent l’ontologie qui a été définie. A cet égard, les chaînes de « Data Preparation » qui formatent la donnée avant injection jouent un rôle essentiel. L’effort humain associé est loin d’être négligeable mais il est indispensable si on veut garder une maîtrise suffisante. Là encore, les utilisateurs finaux de la donnée doivent être consultés, car eux seuls peuvent identifier les champs qui leur sont utiles, et le niveau de qualité qui leur est nécessaire.

Les algorithmes : la matière grise du Big Data

Pour les fichiers de contenus media, l’enjeu va porter sur leur enrichissement par des métadonnées structurées, pour pouvoir indexer, requêter, filtrer et corréler ces media/fichiers. Le Big Data a bénéficié pour cela de la révolution de l’IA à base d’apprentissage profond, qui a démultiplié les capacités d’extraction d’information dans ces contenus. Par exemple, il devient possible de tagger une image avec les noms des objets détectés dedans par l’IA. Ces métadonnées sont stockées avec le binaire associé, et également indexées dans des index à faible latence, qui vont permettre de construire des requêtes élaborées, croisant des données structurées avec des métadonnées de contenus. La technologie ElasticSearch est souvent employée pour stocker des enrichissements de ce type.

« L’HUMAIN DOITCOMPRENDRE ...LES ALGORITHMES ET, SURTOUT LEURS LIMITES »

A partir des Data Lake, les jobs Hadoop et les algorithmes à base d’IA/Machine Learning vont produire des volumes de données élaborées significatifs, mais de taille plus mesurée, pour lesquels ElasticSearch s’avère un outil de stockage performant, scalable et souple. ElasticSearch matérialise ainsi un espace intermédiaire, où vont se rencontrer le travail humain de l’analyste exploitant et celui des algorithmes de traitement automatisés.

Cette rencontre, qui implique une coopération entre l’intelligence humaine et celle des algorithmes, est un des aspects les plus fascinants du Big Data. Elle pose la question de la confiance de l’humain dans la machine, sachant que la machine est devenue indispensable pour appréhender ces immenses volumes de données. Pour que la confiance s’établisse, l’humain doit comprendre (au moins intuitivement) les tâches qu’effectuent les algorithmes et, surtout, leurs limites de performance. Il doit aussi avoir une vision claire des algorithmes disponibles : qu’ils s’exécutent sous forme de jobs Hadoop, de conteneurs Docker dans un cluster Kubernetes ou de Notebooks Python Jupyter, on retrouve toujours la nécessité de les documenter, de les cataloguer, de gérer leurs versions. 

Sans une maîtrise affirmée de ces trois piliers que sont l’infrastructure matérielle, la gouvernance de la donnée et la capacité à faire vivre un écosystème de savoir-faire analytiques, le torrent du Big Data sera sans pitié avec les humains qui cherchent à le dompter.