Dans un contexte BI, comment bien intégrer une architecture Big data  ?

Pour réussir un projet BI, l’accompagnement dans la démarche de transformation digitale et en particulier sur l’adoption d’outils Big Data est essentiel.

Prenons l’exemple d’une société qui souhaitait plus se digitaliser. Pour y arriver, elle a construit un nouveau datawarehouse (ou datalake ou entrepôt). Ce dernier est basé sur le système Hadoop et devra être intégré, entre autres, dans son écosystème BI (basé sur des technologies Microsoft et IBM) .

Elle a mis en place une architecture assez standard : un cluster Hadoop Hortonworks à 2 nœuds. Il est alimenté par des jobs ELT via le protocole WebHDFS dont les données sont interrogées à travers une couche Apache Hive. Les résultats apparaissent sous forme de tables avec des lignes et des colonnes très proches des modèles de données relationnelles.

Notez que la mise en place de cette brique applicative n’est pas sans difficulté, la preuve dans cet article.

Un challenge organisationnel

Dans ce cas, le datalake est l’unique entrepôt de données pour les différents projets Data. Historiquement, chaque unité métier disposait de son propre entrepôt (base Oracle ou Access, fichiers Excel). Il chargeait les données des applications sources. Ainsi, chacun s’organisait comme il le souhaitait et selon ses besoins dans son entrepôt.
Aujourd’hui, chacun voudrait continuer ainsi, mais ce n’est plus possible ! Le problème majeur est l’absence d’une gouvernance des données centrales. En effet, on constate que chaque équipe projet est en mesure d’ajouter ses tables et son schéma dans un entrepôt, via un nouveau job ELT. Ainsi, la cohérence de l’ensemble est potentiellement affectée avec l’apparition de données redondantes. Ce qui implique un risque pour la performance de la plateforme. Comme par exemple quand on ajoute un job ELT non-contrôlé. Il va saturer la CPU et la mémoire de l’ETL (même multi nœuds) . Ou bien un accroissement de l’espace disque nécessaire sur le HDFS non justifié.
Donc, pour pallier cette difficulté de gouvernance, la solution la plus efficiente est de déployer une organisation adéquat en parallèle de la montée en charge du datalake.

Et un défi technique

Il s’agit de l’appropriation de la stack technique par les équipes projets. En particulier dans le contexte des sujets BI, la stack technique est souvent basée sur des technologies courantes de stockage de Microsoft comme Access avec des scripts VB. Développer et déployer en production les applications sous HDFS est un très grand challenge. Bien évidemment, les équipes sont formées et des renforts externes souvent demandés,  mais les anciennes habitudes peuvent être difficiles à abandonner.

On constate que plusieurs contraintes ou nouveautés apparaissent et affectent la manière de concevoir les développements. Le partitionnement des données sur les différents nœuds du cluster Hadoop en est une. Cette nouveauté s’accompagne également d’une contrainte concernant l’impossibilité de mettre à jour des données existantes comme dans une base de données relationnelle. Seules les insertions et les suppressions de partitions sont possibles.

De plus, une collaboration accrue avec les équipes du client sur place (développements, déploiements) est primordiale pour assurer la montée en compétence et la maîtrise de ce nouvel outil. Il ne faut pas omettre de traiter d’autres sujets non développés ici : la prise en compte de la RGDP, la qualité des données, les temps de traitement de la plateforme HDFS… !

 

Alexis Bourdeau