Hadoop : encore trop lent pour l’analytique temps réel ?

Avec tout le buzz généré par Hadoop dans les milieux IT ces jours-ci, il est facile de penser que le framework Open Source a la capacité d’appréhender toutes les problématiques des environnements Big Data. Mais l’analyse en temps réel et l’émission de requêtes sur les données contenues dans Hadoop font notamment partie de l’exception.

Hadoop est optimisé pour absorber un grand volume de données structurées, ou non structurées, mais a été développé pour fonctionner en mode batch - un mode de traitement par lots qui ne convient pas aux exigences de rapidité et de performances pour l’analyse rapide de données.

Jan Gelin, vice-président des opérations techniques chez Rubicon Project, affirme que la vitesse d’analyse est quelque chose de nécessaire pour les régies publicitaires - malheureusement. Rubicon Project, basé en Californie, développe une plate-forme de vente d’espaces publicitaires sur les pages Web, qui s’affichent en fonction des visites des internautes. Le système permet aux publicitaires d’accéder à des informations sur les visiteurs de sites avant de faire une offre et s’assurer que les publicités ne sont vues que par les internautes potentiellement intéressés. Gelin explique que le processus implique de nombreuses analyses qui doivent s'effectuer en une fraction de seconde.

Rubicon s’appuie fortement sur Hadoop pour motoriser sa plate-forme d’enchères d’espaces publicitaires. Mais la clé, soutient-il est de coupler Hadoop à d’autres technologies qui peuvent gérer de véritables analyses en temps réel. Rubicon a par exemple recours au moteur CEP de Strom pour capturer et analyser rapidement de grandes quantités de données lors du processus d’enchères d’espaces. Storm envoie ensuite les données dans un cluster Hadoop fonctionnant sur la distribution de MapR Technologies. Le cluster Hadoop est d’abord utilisé pour transformer les données et les adapter à des applications analytiques plus traditionnelles, comme celles de reporting. Même pour cette étape, le gros des informations est chargé dans une base analytique Greenplum une fois le processus de transformation finalisé.

La réalité Hadoop

Selon Gelin, les volumes de données que produit Rubicon au quotidien sont confiées aux muscles d’Hadoop. Mais lorsqu’il s’agit d’analyser les données, commente-t-il « vous ne pouvez ignorer qu’Hadoop repose sur un système de batch. Il existe d’autres choses au dessus d’Hadoop qui sont en fait comme du vrai temps réel ». Plusieurs spécialistes Hadoop essaient de dépasser ces limites en matière d’analytique en temps réel. Cloudera a annoncé en avril son moteur de requête Impala, avec la promesse de pouvoir exécuter des requêtes SQL sur des données Hadoop avec des performances proches du temps réel. Pivotal, une spinoff d’EMC et de VMware a suivi avec le lancement, trois mois après, d’une technologie identique baptisée Hawq. Sans parler de Splunk qui capture les flux de données issus de machines et de capteurs. La société a développé un outil d’analyse de données Hadoop baptisé Hunk.

La version 2 du framework Hadoop, sortie en octobre, contribue aussi à cet effort en ouvrant les systèmes Hadoop à des applications autres que les tâches MapReduce. Avec tous ces outils et fonctions, Hadoop devrait bientôt être capable de relever le défi de l’analyse en temps réel, relève Mike Gualtieri, analyste au sein du cabinet Forrester Research. Un des moteurs, selon lui, est que les éditeurs ainsi que les utilisateurs sont déterminés à faire fonctionner la technologie en temps réel - ou presque - pour l’analytique.

« Hadoop est fondamentalement un environnement en mode Batch. Toutefois. à cause de son architecture distribuée et parce que de nombreux cas d’usage impliquent de placer ses données dans Hadoop, de nombreux éditeurs et utilisateurs font la demande de possibilité de requêtes temps réel sur Hadoop. Et c’est une demande saine. »

Les freins à l’analyse temps réel

Gualtieri voit deux principaux obstacles à cela. Le premier : la plupart de ces nouveaux moteurs de requêtes Hadoop ne sont toujours pas aussi rapides que ce que peuvent proposer les bases de données traditionnelles. Les outils comme Impala et Hawq fournissent des interfaces qui permettent aux utilisateurs d’écrire des requêtes en SQL. Celles-ci sont ensuite converties en MapReduce pour être exécutées sur un cluster Hadoop, mais ce processus est en soi plus lent que d’exécuter une requête directement sur une base de données relationnelle, lance Gualtieri.

Le second obstacle, entrevu par Gualtieri, est que Hadoop n’est actuellement qu’un système « read-only », une fois que les données ont été inscrites dans HDFS (Hadoop Distributed File System). Les utilisateurs ne peuvent pas facilement insérer, supprimer ou encore modifier les données stockées dans le système de fichiers comme ils le font dans une base de données traditionnelle, affirme-t-il.

Joint par email, Nick Heudecker de Gartner admet que même si les nouveaux moteurs de requêtes ne supportent par de vraies fonctions analytiques en temps réel, ils permettent tout de même aux utilisateurs, avec moins de bagages techniques, d’accéder et d’analyser des données stockées dans Hadoop. Cela permet de réduire la durée du cycle ainsi que les coûts associés à l’exécution des tâches analytiques car les développeurs MapReduce n’ont plus besoin de s’impliquer dans la programmation de requêtes, affirme-t-il.

Les entreprises devront évaluer s’il s’agit d’une justification suffisante pour déployer de tels outils. La scalabilité et la disponibilité d’Hadoop sont séduisantes — mais cela peut envoyer certaines entreprises dans la mauvaise direction, affirme Patricia Gorla, consultant IT au sein du cabinet OpenSource Connections. Ce qui est capital, indique Gorla, c’est trouver le meilleur usage d’Hadoop - et ne pas essayer de l’insérer, en force, au sein d'une architecture système. « Hadoop est bon dans ce qu’il fait, et pas dans ce qu’il ne fait pas. »

Traduit et adapté de l’anglais par la rédaction