Data warehouse : un futur flou ?

On parlait beaucoup de datawarehouse il y a quelques années. Mais de l’aveu même de certains acteurs du marché comme Umanis, il faut reconnaître qu’il est coincé entre le datalake, le blob et tous les services de stockage de données massifs. Mais ces nouvelles approches ne se font pas forcément contre le datawarehouse, mais en complément.

Le big data a beaucoup fait bouger les lignes avec la promesse de travailler sur des données non structurées de toute nature. Jusqu’à l’avènement des outils big data, de nombreuses données étaient mal ou pas utilisées : faute d’outils et de capacité. Aujourd’hui, il s’agit de créer de la valeur avec ces données, faire de la data science, les injecter dans le Machine Learning, etc.

Pour un data scientist, la masse de données peut parfois virer au cauchemar : choisir la bonne donnée pour le bon traitement au bon moment. Le data warehouse consomme beaucoup de données provenant des ERP, CRM. On réalise le modèle / schéma, on définir les champs. Ce modèle est plus rigide que l’approche big data tel qu’on l’entend habituellement.  

On oppose souvent le data warehouse aux autres approches, mais finalement, une partie de données sera sans doute identique que l’on soit dans du data lake, du blob ou du data warehouse.

La question peut alors se poser aux entreprises : faut-il garder le data warehouse existant et rajouter les autres services de données ou le remplacer purement et simplement pour éviter des doublons fonctionnels et des lourdeurs ? Si on regarde le data lake, il faut le considérer comme du stagging dans lequel on stocke tout et n’importe, sans qualitatif alors que le data warehouse oblige à une qualité de données dès le départ. Le data warehouse peut alors se situer derrière pour qualifier et traiter les données selon des schémas bien définis. Le data lake va permettre d’injecter rapidement les données et de les stocker, mais ce n’est pas lui qui fera l’analyse.

Mais selon les données que l’on récupère, l’architecture de données ne sera pas identique. Dans une approche classique ERP / CRM, le data warehouse reste valable, par contre, dans une approche IoT avec architecture lambda ou post-lambda, ce choix n’est pas valable ou mal adapté. Pareillement dans une approche Edge Computing, le data warehouse n’est pas indiqué, car l’architecture est rigide et les schémas plus stricts. En Edge, il faut pouvoir déployer localement une architecture légère, tout en se connectant à une architecture centralisée. On peut déployer un data warehouse au niveau central, mais attention à ne pas alourdir inutilement l’architecture qui est déjà complexe en Edge.

Mais le data warehouse a su aussi évolué et se « simplifier » grâce aux services Cloud comme nous pouvons le voir chez Amazon ou Microsoft. Il est toujours approprié pour les entreprises qui l’utilisent en production, les reporting massifs, en complément aux ETL.

Aujourd’hui, la frontière entre le structuré et le non structuré devient très poreuse et l’architecture doit être capable de traiter toutes ces données et surtout de pouvoir réagir très rapidement, avec des modèles de données pouvant changer à la volée. Même si le data warehouse a fait des progrès sur ce point, il restera un modèle avec des contraintes. 

Merci à Umanis.