Guides Essentiels
Voir tous les articles de ce guide
Actualites
Cet article fait partie de notre guide: Guide : tout savoir sur Hadoop

Entrepôt de données vs Hadoop : ces frères ennemis qui doivent cohabiter

Hadoop ne tuera pas l’entrepôt de données. Il peut offrir en revanche des capacités de délestage de données pour accroître la flexibilité des environnements des entreprises.

Publié le: 09 mars 2016

Hadoop n’est pas prêt de tuer l’entrepôt de données, mais peut en être un bon complément. C’est une des conclusions que l'on peut tirer d’une table ronde organisée lors de l’édition 2016 de Big Data Paris.

Au départ, tout semble opposé ces deux technologies. D’un côté, «  l’entrepôt de données existe avec la modélisation, reste normalisé, répond à un besoin fonctionnel, est disponible et est adapté au monde structuré et SQL, explique Franck Poulain, Technology Presales Director chez Oracle. Et de l’autre, Hadoop permet la création de datalake. « L’entrepôt de données organise des éléments métiers avec des SLA spécifiques. Mais il s’agit aussi d’un principe d’architecture. Les fonctions d’un datalake ne sont pas les mêmes », ajoute Jean-Marc Bonnet, directeur de l’architecture et des solutions analytiques chez Teradata France.

Deux mondes qui répondent à des cas d’usage distincts mais qui finalement peuvent coopérer. A condition de bien cerner le périmètre de chacun, s’accordent à dire les intervenants de cette table ronde. Bref, la cohabitation est judicieuse dans cet environnement hybride.

Ce que soutient Franck Poulain (Oracle) pour qui « la base Oracle doit (aujourd’hui) coopérer avec Hadoop. Le déluge de données est difficile à appréhender avec le relationnel (d’un point de vue technique), mais aussi pour des raisons de coûts ». C’est bien là que se justifie ce couplage entrepôt de données / Hadoop.

Délestage de l’entrepôt de données et de l’ETL

Aujourd’hui Hadoop peut très bien être associé à un entrepôt de données confirme Olivier Renault, Ingénieur Solutions chez Hortonworks, interrogé par la rédaction. Il y voit généralement deux cas de figures. Par exemple, Hadoop sait très bien offloader des données historiques dans l’entrepôt de données. « Vous conservez les données dans l’entrepôt de données, vous en migrez vers un environnement Hadoop. La vision se retrouve augmentée, puis vous supprimez de l’espace qui n’était pas utilisé. »

Hortonworks travaille par exemple avec la société Attunity. Celle-ci propose une solution que l’on installe pendant un mois dans l’entrepôt de données et qui analyse toutes les zones de données qui n’ont pas été requêtées. Celles-ci peuvent ensuite être déplacées vers Hadoop. « Dans les faits, 40% des données de la plupart des entreprises sont requêtées de façon épisodique. Une fois exportées vers Hadoop, l’entreprise gagne donc de l’espace et optimise ses coûts sur l’entrepôt de données. Cela permet aussi de donner du temps à l’entreprise dans le cadre d’une mise à jour. Seules les données sans valeur ajoutée sont alors délestées. »

Ce qui permet de calculer rapidement le ROI, souligne-t-il. En se donnant du temps et en décalant voire en évitant les mises à jour de l’entrepôt de données, l’entreprise investit dans une solution moins couteuse (Hadoop) et utilise son budget pour financer d’autres projets.

L’autre cas d’usage aujourd’hui est encore le délestage d’ETL (ETL Offload) ; un cas commun dans lequel Hadoop est - selon Hortonworks - très à l’aise.

Mais Olivier Renault explique qu’il existe aussi des cas où il n’est pas nécessaire d’investir dans un entrepôt de données (surtout si l’entreprise n’en possède pas) et oùil est plus adapté d'exploiter un cluster Hadoop en guise de Data Warehouse. Même si « cela aura certes des contraintes et des limites », admet-il. Et de citer le cas de Spotify qui a préféré s’appuyer sur Hadoop. « Toutes les requêtes des utilisateurs sont gérées dans Hadoop. Spotify dispose certes de nombre de connexions d’utilisateurs simultanées, mais il a déployé un cluster de 1.200 noeuds.

Hadoop : des limites pour entreposer des données

Pourtant, le framework Open Source - s’il peut parfois  s’immiscer dans des scenarios d’entrepôt de données - manque de certaines briques clés. « Hadoop n’est pas encore tout à fait adapté pour répondre à tous les besoins des entrepôts de données », explique Olivier Renault (Hortonworks).

Même si finalement, un Datalake ressemble à un Data Warehouse (« On parle de données stockées pour être requêtées ») aujourd’hui, effectuer des requêtes SQL sur Hadoop est réalisable mais il manque une partie encore des fonctions SQL (« cela répond à 80% des besoins des utilisateurs », sous-entendu, il en manque encore un cinquième).

Autre frein à cette possibilité de stocker et d'exploiter massivement des données structurées dans Hadoop, les capacités à gérer la concurrence entre utilisateurs seraient encore limitées ; alors que l’entrepôt de données est très bien adapté à ces scénarios.

Rendre ce tandem accessible pour les utilisateurs

Au final, tant pour Franck Poulain (Oracle) que pour Jean-Marc Bonnet (Teradata), le principe de cette cohabitation revient à camoufler la complexité du tandem aux utilisateurs. « Il s’agit de faciliter la navigation entre l’entrepôt de données et Hadoop et l’orchestration en ces deux mondes de la façon la plus transparente possible », soutient le responsable de Teradata.

« Faire collaborer un entrepôt de données SQL et Hadoop permet d’atteindre un maximum de flexibilité. L’entrepôt de données stocke par exemple les fichiers clients ; Hadoop, tous les événements liés aux à  comportements de ces clients. Le moteur va chercher au bon endroit avec la même requête », enrichit enfin le responsable d’Oracle. Force est de constater que les travaux sur les moteurs SQL-On-Hadoop vont bien dans ce sens. 

Pour approfondir sur Big Data et Data lake