Forrester : il est temps de faire émerger un organisme de standardisation pour Hadoop 

SearchDataManagement s'est entretenu avec James Kobielus afin de faire la lumière sur l'adoption d'Hadoop. Il revient sur les contraintes de stockage liées à l'analyse des données en volume et explique pourquoi, selon lui, un organisme de standards aiderait Hadoop à franchir quelques niveaux en terme d'adoption. En voici quelques extraits.

SearchDataManagement : Hadoop et le Big Data ont occupé le haut de l'affiche ces derniers temps. Alors pourquoi tout le monde ne s'y met pas ?

James Kobielus : Quel que soit le moyen utilisé pour implémenter des outils analytiques de type Big Data, qu'il s'agisse d'un datawarehouse ou d'un cluster Hadoop, des petabytes ou plusieurs centaines de terabytes de données doivent être stockés. Cela coûte cher. Le facteur bloquant dans cet univers du Big Data est le prix du stockage. Combien cela coûte-t-il ? Quelle quantité de données pouvez-vous vraiment vous permettre de stocker, de façon déconnectée, quel est le moyen de stockage meilleur marché, et quid des bandes... etc.

SearchDataManagement : Avez-vous déjà rencontré des early daopters d'Hadoop qui analysent des petabytes de données ?

J. K : La plupart des clusters Hadoop, dans le monde réel, ne gèrent pas des volumes de données de l'ordre du petabyte. Beaucoup sont plus prés de centaines de terabytes. Mais parmi les projets d'implémentation en cours, nombreux ont été ceux qui ont affirmé que le stockage serait, justement, une véritable problématique, s'ils avaient à gérer un pétabytes de données. C'est la raison pour laquelle il n'existe pour l'heure qu'un nombre réduit de datawarehouses ou encore de plate-formes traditionnelles gérant un petabyte de données. C'est encore trop cher. 

SearchDataManagement : Quel autre facteur joue un rôle dans l'adoption d'Hadoop et du Big Data ?

J. K : L'ensemble de l'éco-système Hadoop est encore immature. Soit la majorité des éditeurs de solutions de Datawarehouse ne disposent pas de leur propre distribution, soit ils en possèdent une mais son intégration au sein de leurs outils de datawarehouse n'est pas complète. Et c'est bien un indicateur d'immaturité.

SearchDataManagement : Existe-t-il d'autres signes d'immaturité ?

J. K : La communauté Hadoop manque de standardisation. En fait, c'est standardisé, au même titre que le sont les projets Open Source. A savoir, une réunion d'entreprises, et de développeurs, un développement collaboratif d'un logiciel et et une mise à l'Open Source. Mais ce modèle ne comprend pas de forme de standardisation officielle ni de processus de ratification. De nombreuses personnes, à la fois dans la communauté Hadoop et plus globalement dans l'Open Source, pensent que cette standardisation et ratification ne sont pas de bonnes méthodes. Je respecte ce point de vue. Mais une partie du problème réside dans le fait que sans standardisation, les entreprises qui souhaitent implémenter la solution risquent gros.

SearchDataManagement : Et pourquoi est-ce risqué ?

J. K : Le fait, par exemple, qu'il n'existe pas d'architecture de référence commune de clusters Hadoop - une architecture de référence qui définirait clairement les interfaces pour se plugger à la couche de stockage et des interfaces standards pour faire intéropérer les différentes implémentations de MapReduce. Il n'existe pas de framework de référence commun équivalent à celui qu'a développé la communauté SOA il y a 10 ans, autour de technologies telles que SOAP, WSDL ou UDDI, afin de promouvoir l'intéropérabilité dans l'ensemble du monde des services Web. Avec Hadoop, il n'y a pas de test d'interopérabilité ni de certification, pas de sceau ou d'approbation en matière compatibilité. Cela peut devenir critique pour nombre de secteurs. Prenons l'exemple d'une grande entreprise qui a déployé des clusters Hadoop dans plusieurs de ses départements et qui souhaite les faire dialoguer ou les fédérer. Il n'existe pas encore de standard en matière de fédération de clusters Hadoop. Pas de spécification commune pour la manipulation de données en temps réel, également.

SearchDataManagement : Comment ces early adopters contournent ces problèmes d'intéropérabilité ?

J. K : Si vous souhaitez mettre en place un vrai système analytique en temps réel dans un environnement distribué Hadoop, avec plusieurs distributions différentes, vous allez devoir écrire de nombreuses lignes de code spécifiques… sans avoir de garantie d'un bon fonctionnement. Le risque est important dans ce cas. Je crois qu'il est temps de commencer à réfléchir à la création d'un framework de référence commun en matière de tests d'intéropérabilité et de certification. De préférence, un framework élaboré en collaboration avec des organismes de standardisation officiels qui pourraient alors ratifier quelques briques, comme par exemple les version de HDFS, le système de fichier coeur utilisé dans la plupart de ce type de clusters.

D'aprés un article de Mark Brunelli, SearchDataManagement, traduit de l'anglais par la rédaction.