Clarification sur le Datawarehousing

Depuis quelques temps déjà on nous parle de plus en plus de datawarehouse (c'est un assez vieux concept qui semble revenir à la mode) et d’un terme que je trouve un peu pompeux le BI. Etant obligé par mon travail à replonger dans cet univers (mauvais jeu de mot ?), voici un petit billet concernant quelques cogitations à ce sujet…

OLTP et OLAP

OLTP : online transaction process : il s’agit là des base de données bien connu et bien classique (RDMS, entendez relational database management system). Le but de ces bases de données est de stocker des données utilisateurs via des applications clientes. Les paramètres importants sont :

1        1)Transactionnel (toujours se retrouver dans un état cohérent, même si le système crash)

2          2)Intégrité de donnée (clé primaire, foreign key, contrainte)

3          3)Index

4          4)Gestion d’accès concurrent (cfr transaction : Atomicity, Consistency, Isolation, Durability)

L’accent est mis sur la rapidité d’accès aux données et l’intégrité de celle-ci. Idéalement, de mon point de vue, une base de donnée OLTP ne devrait même pas être utilisée pour du reporting (sauf reporting bête et méchant).  Un chirurgien doit attendre d’opérer un patient, car il ne peut accéder aux informations du patient parce que le système est bloqué par quelqu’un générant un rapport trop lourd. Ces types de situations sont évidemment inacceptables.

Pour optimiser et réduire la redondance des informations, on utilise abusivement des formes normales.

Dans certains cas on utilise des ORM (iBATIS, Hibernate…) pour construire la structure du RDMS et assurer un mapping cohérent entre l’architecture objet et sa persistance transactionnelle.

OLAP : online analytical process

Ces bases de données sont dédiées au reporting, voir au reporting sur plusieurs dimensions. Dans cec cas de figure aucun souci par rapport au performance, puisque les deux bases de données sont séparées physiquement.

La structure des tables n’a plus rien à voir avec une base de donnée classique puisque la plupart des tables sont dé-normalisées. L’accès en écriture se fait en général via un processus d’ETL (Export, Transform, Load).

Pratiquement on utilise une table de fait représentant des comptes  en fonction de différentes dimensions. (Axe d’analyse), il s’agit de la table centrale. Les  dimensions sont des variables catégorielles independantes. L’ensemble des dimension forment un espace appelé Univers. La table centrale contient une foreign key pour chaque dimension (on appelle cette modélisation, modélisation en étoile, c’est une des plus simples). On peut aussi décomposer les dimensions suivant leur hiérarchies et définir des sous tables par dimension et niveau hiérarchique (architecture en flocon de neige). On peut aussi faire un mix des deux…

D’un point de vue pratique, même si des clés primaires peuvent être définies conceptuellement, aucune contrainte n’est mise sur la DB et l’autocommit est aussi désactivé puisque la DB fonctionne en read only.

Une fois les dimensions clairement établies, celles-ci peuvent être lues via certains outils de BI (Pentaho, offre quelque bon exemple open source, ceci dit il est aussi possible de faire du BI avec Excel).

Avant de se lancer dans la conception du système, il est important de se figurer les rapports dont on a besoin et les axes suivant lesquels on voudrait naviguer dans les données. Il faut veiller que ses axes soient indépendants (ou alors les regrouper sous forme hiérarchique). On définit ensuite la hiérarchie, puis on modélise.

La partie tricky à mon sens est la partie ETL car si quelque chose foire là-dedans, cela peut très vite devenir problématique. D’une part, les données peuvent venir d’une foulée de systèmes différents, donc on a besoin de réconciliation et de consolidation (remettre les bons ID), d’autre part si la réconciliation se passe mal, ce sont tous les résultats qui peuvent être impacté. C’est pourquoi il est important d’une part de travailler dans une sandbox, et d’autre part de bien dater les modifications.

Une fois les données prêtes (dans mon cas via des scripts PERL), il faut ensuite faire un bulk-copy dans la base de donnée OLAP. Comme cette DB est read-only, la seule phase d’écriture se fait au moment du chargement (LOAD), en général on utilise un bulk-copy (bcp) ou COPY en Postgres.

Les bases de données OLAP sont souvent qualifiées de Datawarehouse, en général le domaine qui nous occupe s’appelle un datamart (partie d’un datawarehouse), si le domaine concerné impacte le business par rapport à ses ventes on parle alors de BI (Business intelligence). Dans ce cas les dimensions sont souvents:la géographie (Région/Pays/Ville), le temps(Year/Quarter/Month), les types de produits. La table de fait est en général le total des ventes en fonctions des dimensions précitées.

Plusieurs systèmes peuvent être utilisés pour créer une base de donnée OLAP : SAS, SQL-Server, ORACLE ou dans les gratuits : R et PostgreSQL. Il en existe bien sûr d’autres mais ce sont ceuxt là que je connais le mieux…