Hadoop et les traitements en temps réel…
Pour ceux qui ne connaissent pas très bien Hadoop, la conception a eu lieu chez Google et l’accouchement s’est fait dans des sociétés comme Facebook ou Yahoo. Le problème que ces sociétés cherchaient à résoudre était celui du traitement à très grande échelle de log web. Ils avaient beaucoup de données à traiter en mode batch. Ils ont donc conçu MapReduce, un système de traitement de données en mode batch pour analyser ces données. Cela a transformé la façon dont Internet opère. Ce qui nous a motivés chez Cloudera est que nous étions convaincus que ce qui a transformé l’Internet grand public était applicable aux entreprises : Google n’était pas différent d’une entreprise normale, il opérait simplement 10 ans dans le futur…
Stocker de grandes quantités de données et pouvoir réaliser des traitements en mode batch dessus a déjà changé les choses. Mais soyons honnêtes, il y a beaucoup d’applications qui ne fonctionnent pas en mode batch dans le monde. Il y aussi un grand nombre d’applications temps réel et interactives. Si Hadoop était prisonnier du ghetto batch, il ne pourrait pas tirer parti d’opportunités de marché très larges. C’est pourquoi dans le cadre de notre plate-forme, nous délivrons une plate-forme d’analyse de données en temps réel baptisée Hbase. Nous avons aussi fait une contribution majeure à la communauté Open Source avec un logiciel de traitement en temps réel baptisé Impala qui permet d’effectuer des requêtes interactives sur les données stockées dans Hadoop. En fait vous pouvez utiliser MapReduce, Hbase ou Impala sur un même jeu de données. Une fois que les données sont stockées sur Hadoop, vous pouvez lui apporter tout type de moteur de traitement. MapReduce n’est pas la seule alternative, Hbase ou Impala sont disponibles aujourd’hui mais au fil des ans de nouveaux moteurs devraient s’ajouter à la liste.
Impala n’est-il pas une implémentation de Google Dremel avec 2 à 4 ans de retard ? Et que dire du retard général Hadoop sur les technologies développées en interne par Google ?
Si vous regardez le projet open source Hadoop vous avez effectivement raison. Il s’agit d’une « imitation » avec 4 ans de retard sur ce que Google avait inventé en interne. J’ai passé 26 ans de ma carrière dans le monde des SGBD, j’ai lu à l’époque l’article de Google sur MapReduce et j’ai pensé qu’il s’agissait d’une blague.
Tout le monde dans l’industrie pensait savoir comment bâtir des bases de données à grande échelle et nous avons complètement raté l’opportunité que représentaient Hadoop et le Big Data en général. Une industrie avec des milliards de dollars de revenus, avec un énorme budget R&D épaulé par la recherche de multiples universités de classe mondiale, a passé 30 ans à perfectionner ses logiciels de traitement de données et au final, c’est une bande de développeurs hirsutes de Mountain View en Californie qui a sorti de son chapeau la technologie qui a révolutionné le secteur.(…)
Impala est un mix entre des idées neuves et des concepts empruntés à Dremel. Dans les trimestres à venir, nous allons apporter de nouvelles innovations à la plate-forme qui ne sont pas dérivées de Google. Mais nous n’avons pas honte : nous prendrons les bonnes idées d’où qu’elles proviennent. Ce que nous avons fait franchement est d’interroger notre base installée pour voir quels étaient ses besoins et pour y répondre, nous avons embauché l’ingénieur de Google qui avait construit Dremel. Il y a en revanche des fonctions qui arrivent qui sont inspirées de demandes de nos clients et qui n’ont rien à voir avec ce que fait Google. Et je le répète. Nous n’avons aucune réserve à emprunter de bonnes idées à Google.
En fait, il va se passer pour la plate-forme Hadoop, ce qui est arrivé aux SGBD. Il y a 30 ans, vous pouviez aller voir Ingres et acheter un SGBD. Aujourd’hui vous ne pouvez plus aller voir Ingres (sic), mais IBM, Oracle ou Microsoft pour acheter votre SGBD. Mais ce logiciel n’a plus rien à voir avec les SGBD d’il y a 30 ans. Hadoop est jeune, il va évoluer pour exploiter de nouveaux développements techniques, comme la généralisation des réseaux longue distance à haute performance, la chute des coûts du stockage. Il sera intéressant de voir ce que sera le positionnement prix de la Flash d’ici 5 ans. En fait si vous entendez aujourd’hui quelqu’un critiquer Hadoop en disant, « oui, mais Hadoop n’est bon qu’à X ou Y », il est prudent de rajouter « aujourd’hui ». Les limitations que nous connaissons aujourd’hui seront certainement contournables dans le futur avec un peu d’ingénierie.
Egalement sur LeMagIT :
Hadoop : MapR débarque en Europe
Conseil national du numérique : la résurrection