Hadoop vs. Data Warehouse : (lequel) faut-il choisir ?

La plateforme serait en train de devenir le Data Warehouse de demain. Il n’en est rien.

Ces solutions divergent en plusieurs points, à commencer par leur philosophie intrinsèque, et présentent chacune des caractéristiques qui les prédestinent à des usages différents.

Hadoop a depuis de nombreuses années déjà démontré ses capacités ETL pour traiter de très grands volumes de données semi structurées (fichiers logs, données événementielles…) ou non structurées (analyse de sentiments basée sur les média sociaux tels que tweets, blogs ou forums), en s’appuyant sur des jobs MapReduce. Il ne s’agit pas d’un outil ETL mais plutôt d’une solution capable d’exécuter des processus ETL en parallèle.

Par ailleurs, Hadoop fonctionne en mode batch et ne peut donc être confortablement utilisé comme source de données d’outils décisionnels pour effectuer des analyses ad-hoc interactives, en tout cas pas dans l’état actuel de performance du système de fichier distribué HDFS sur lequel il s’appuie (plutôt conçu pour assurer la résilience des données que pour offrir d’excellentes performances) et des architectures matérielles sous-jacentes (peu coûteuses et moyennement performantes). En revanche, son architecture massivement distribuée permet un traitement (nettoyage, filtrage, etc.) rapide des données, et les coûts bas de stockage de la plate-forme Azure sur laquelle il s’appuie permettent d’y conserver les données brutes stockées plusieurs semaines voire plusieurs mois si nécessaires.

Toutefois, une solution décisionnelle telle qu’un data warehouse demeure encore aujourd’hui la meilleure solution pour permettre une analyse interactive et performante des données structurées (qui peuvent être issues des calculs d’un cluster Hadoop) via des outils décisionnels adaptés tels que PowerPivot ou PowerView. SQL Server Fast Track, SQL Server Parallel Data Warehouse (PDW) et Analysis Services constituent des solutions idéales répondant à différents besoins en matière de volumétrie et de performance.

Des solutions Grid comme Hadoop et décisionnelles telles que SQL Server (PDW) ou Analysis Services (SSAS) ne sont donc ni antagonistes ni exclusives, mais seront au contraire complémen-taires la plupart du temps pour répondre à une problématique Big Data, chacune d’elles ayant ses points forts. Certains de nos partenaires constructeurs ne s’y sont pas trompés et proposent, à l’instar de Dell, des solutions Hadoop clés en main sous forme d’appliances, interopérables avec leurs appliances décisionnelles PDW par exemple.

La figure ci-dessus illustre un cas d’usage typique de cycle de gestion de données Big Data : traitement des données de détail dans un cluster Hadoop (on premises ou sur Azure), intégration des données nettoyées et filtrées  dans une base de données relationnelle, pré-calcul et stockage d’agrégations dans un cube OLAP qui servira de source aux analyses à partir d’outils décisionnels tels qu’Excel, PowerPivot ou PowerView.

C’est par exemple l’architecture que Yahoo! a mis en œuvre pour analyser les logs des systèmes de fichiers de ses serveurs Web, illustrée par la figure ci-dessous.

Les fichiers Logs sont collectés à l’aide d’un cluster Hadoop hébergeant plusieurs pétaoctets de données, traités et agrégés, puis stockés dans une base de données sur laquelle le cube OLAP SSAS est basé. Les mises à jour des données du cube se font de manière incrémentale à partir d’un serveur OLAP de traitement. Ces mises à jour sont ensuite répliquées (synchronisées) vers des serveurs OLAP constitués en ferme de répartition de charge dédiés aux requêtes utilisateurs.

Le cas de la société Klout constitue également un bon exemple de mise en œuvre de solutions Big Data de Microsoft au côté de leur cluster Hadoop existant afin d’améliorer la compréhension de leurs données et réduire les coûts de maintenance de leur solution BI.

Les solutions de type Cloud permettent quant à elles de répondre à des besoins de stockage massifs à bas coûts et permettent aux entreprises d’évoluer d’un modèle CAPEX vers un modèle OPEX basé sur une facturation à l’usage.