Gloire et déclin du cube OLAP (au bénéfice des BDD en colonnes)

L’abandon progressif des cubes au profit des BDD en colonnes pour faire de l’OLAP est l’un des changements les plus importants de ces 10 dernières années dans le monde de la Data Analysis.

Les cubes OLAP ont pendant des décennies étaient à la base de tous les dispositifs de BI. Comment expliquer ce succès ? Et surtout comment expliquer le déclin progressif des cubes OLAP au profit des bases de données en colonnes ? Est-ce que nous sommes face à un vrai changement de paradigme ou à un effet de mode (comme le mouvement NoSQL) ?

Dans cet article, inspiré par un blog post d’Holistics, nous allons :

• Voir en quoi consiste l’OLAP (vs l’OLTP).
• Analyser les raisons de l’émergence des cubes OLAP.
• Comprendre le déclin des cubes OLAP et l’apparition des BDD en colonnes comme alternatives pour réaliser des analyses décisionnelles.

Qu’est-ce que le cube OLAP ? Définition & Cas d’usage

L’OLAP ou Online Analytical Processing est un terme apparu au début des années 1990 par Edgar F. Codd, souvent désigné comme le père des bases de données relationnelles. Mais qu’est-ce que l’OLAP ? Pour bien comprendre, faisons un petit détour. Pour une entreprise, une base de données remplit essentiellement deux cas d’usage :

• Une base de données sert d’abord à gérer les process internes de l’entreprise. Supposons que vous soyez un concessionnaire automobile. Lorsqu’un commercial vend une voiture, vous avez besoin de garder un enregistrement de cet événement. C’est indispensable d’un point de vue opérationnel : Cela permet d’avoir une trace de la transaction, de calculer les primes de vos commerciaux, etc.
• Une base de données est aussi un outil pour faire de l’analyse décisionnelle. Vous avez besoin de collecter des données et des chiffres pour analyser votre business et prendre les bonnes décisions stratégiques. Une BDD est un support à la prise de décision. Elle permet de répondre à des questions du type : « Combien d’Honda Civic ont été vendues à Londres au cours des 3 derniers mois ? » ou bien « Qui sont les commerciaux les plus productifs ? ».

Le premier cas d’usage est ce que l’on appelle l’Online Transaction Processing ou OLTP. La seconde catégorie de cas d’usage est connue sous le nom d’Online Analytical Processing ou OLAP.

Présentés de manière très synthétique :

• L’OLTP consiste à utiliser la base de données pour faire tourner votre business.
• L’OLAP consiste à utiliser la base de données pour comprendre votre business.

Pourquoi distinguer les deux catégories ? Parce que le mode d’accès aux données, la manière d’interroger la BDD, sont très différents dans les deux cas.

Avec une base de données OLTP, vous pouvez enregistrer des choses comme « Une Honda Civic a été vendue par le commerciale Jane Doe dans le point de vente de Londres le 1 janvier 2016. Les requêtes utilisées en OLTP sont relativement simples.

Avec l’OLAP, les requêtes sont en général beaucoup plus complexes. Par exemple : Le total de ventes des Honda Civic au Royaume-Uni au cours des 6 derniers mois. Ou : Le nombre de voitures que le commercial Jane Doe a vendu le mois passé. Ou bien : Comparer le nombre d’Honda vendu ce trimestre par rapport au trimestre précédent. Pour obtenir les réponses à ces questions, les requêtes utilisées pour interroger la base sont très complexes, elles font appel à plusieurs agrégats de données.

Si votre base de données est peu volumineuse (et que votre business est simple), vous pouvez utiliser une base de données relationnelle classique à deux dimensions à la fois pour vos requêtes OLTP et OLAP. Mais à partir d’une certaine volumétrie et/ complexité, il devient nécessaire de structurer vos données d’une manière spécifique pour les traitements OLAP. Sinon, vous risquez de faire face à des problèmes de performance.

Découvrez notre guide complet pour choisir le bon type de base de données pour son projet d’entreprise.

Les cubes OLAP, une solution à un problème de performance

Les cubes OLAP facilitent la manipulation de données à des fins décisionnelles lorsque les données sous-jacentes sont très volumineuses et relèvent de plusieurs dimensions. Pour vous donner une idée des problématiques de performance que les requêtes OLAP posent, reprenons les 3 exemples de requêtes que nous avons formulés tout à l’heure :

• Donne-moi le nombre total de ventes d’Honda Civics vendu au Royaume-Uni au cours des 6 derniers mois.
• Dis-moi combien de voitures le commercial Jane Doe a vendu le mois dernier.
• Dis-moi combien de voitures Honda ont été vendues ce trimestre par rapport au trimestre précédent.

Ces différentes requêtes peuvent être réduites à un nombre de dimensions, chaque dimension correspondant à une propriété / un agrégat que vous souhaitez filtrer. Dans notre exemple, vous voulez extraire les agrégats suivants :

• La date (incluant le mois, l’année et le jour).
• Le modèle de véhicule.
• Le constructeur automobile.
• Le commercial.
• Le montant des transactions.

Si vous voulez stocker toutes ces données dans une base relationnelle classique, vous allez devoir exécuter une requête SQL de ce type pour extraire les données de 3 tables de dimensions :

Vous devez réaliser trois « unions » de tables. On peut généraliser : Pour agréger des données issues de X dimensions, vous devez réaliser X unions. Vous pensez peut-être que c’est déjà compliqué et vous avez raison. Mais vous n’avez encore rien vu. Cet exemple ne donne qu’un aperçu des difficultés qu’il y a à exécuter des requêtes OLAP sur une base relationnelle classique SQL. Supposons maintenant que vous souhaitiez construire un tableau croisé dynamique, comme celui-ci :

Les requêtes nécessaires pour produire un tableau croisé dynamique impliquent une combinaison encore plus complexe d’unions et d’opérateurs GROUP BY. Un tableau croisé dynamique avec 6 dimensions, par exemple, nécessite 64 unions et 64 GROUP BY différents. Dans la plupart des bases de données relationnelles, cela nécessite 64 scans de vos données et 64 tris de données. Résultat : Vous pouvez attendre longtemps avant d’obtenir votre tableau croisé dynamique.

Les professionnels en BI ont en fait très rapidement compris qu’utiliser des bases de données SQL pour exécuter des requêtes OLAP était une mauvaise idée. Surtout qu’à l’époque, dans les années 1990, les ordinateurs étaient largement moins puissants qu’aujourd’hui. Il faut se rappeler qu’au milieu des années 1990, 1 Go de RAM coûtait plusieurs dizaines de milliers de dollars. Les entreprises étaient contraintes de faire de la BI avec les moyens du bord, c’est-à-dire avec peu de mémoire vive à disposition. D’où l’émergence d’une nouvelle approche consistant à n’extraire de la BDD que les données dont on a besoin et ensuite les déposer dans une structure de données ad hoc pour faciliter la manipulation. C’est de là que vient le cube OLAP.

Découvrez notre guide complet sur le Design d’Un Data Warehouse (Zoom sur la modélisation en étoile).

Les raisons du succès du cube OLAP

Entrons dans le vif du sujet. Le cube OLAP est né d’une idée de programmation simple : Prendre les données et les intégrer dans une matrice à deux dimensions – c’est-à-dire : une liste de listes. Puis, progressivement, pour pouvoir analyser un plus grand nombre de dimensions, on a eu l’idée d’imbriquer plus de tables et de créer des matrices à 3 dimensions (une liste de listes de listes) puis à 4 dimensions (une liste de listes de listes de listes), etc. Parce que la plupart des langages de programmation permettaient de créer des matrices, on a logiquement eu l’idée de charger les données dans une structure de données relationnelle.

Mais comment faire pour réaliser des analyses sur des sets de données largement plus gros que la mémoire des ordinateurs de l’époque ? C’est là qu’est apparue une deuxième grande idée : agréger puis ensuite mettre en cache les ensembles de données dans la matrice dynamique. C’est l’un des principes du cube OLAP. Le cube OLAP permet de faire des analyses impliquant des data sets de plusieurs terabytes de données.

Le cube OLAP a eu un impact profond sur la BI et sur le métier d’analyste de données. Le cube OLAP s’est imposé comme le support de BI de référence. La conséquence, c’est qu’il fallait souvent créer de nouveaux cubes à chaque fois qu’un nouveau rapport ou qu’un nouveau type d’analyse l’exigeait.

Prenons un exemple. Vous voulez générer un rapport sur le volume de ventes de voitures par département. Si vous avez à disposition des cubes OLAP qui n’intègrent pas l’agrégat « Département », vous devrez faire appel à votre data engineer et lui demander de créer un nouveau cube OLAP ou de modifier un cube existant pour intégrer l’agrégat manquant.

L’utilisation du cube OLAP impliquait aussi que les équipes data devait générer des pipelines compliqués pour transformer les données d’une base de données SQL vers les cubes. Si vous travailliez avec un gros volume de données, une telle opération pouvait prendre beaucoup de temps. La pratique qui s’est imposée consistait à installer la tuyauterie, à mettre en place les pipelines ETL en amont – avant que les analystes entrent en action. Les analystes n’avaient plus besoin d’attendre que les cubes soient mis à jour. Les ordinateurs calculaient les données la nuit, les analystes pouvaient commencer leur travail le matin.

Cette approche est devenue problématique avec l’essor de la globalisation et la multiplication des fuseaux horaires. L’accès aux données devenait plus difficile. Comment faire travailler les ordinateurs la nuit quand « la nuit » correspondait au matin à l’autre bout de la planète ?

Cette manière d’utiliser le cube OLAP impliquait par ailleurs que les bases de données SQL et les Data Warehouses soient organisés d’une manière à faciliter la création de cubes. Les data analysts de l’époque devaient tous se frotter à l’art de la modélisation Kimball ou de la modélisation Inmon…Kimball, Inmon et quelques autres avaient en effet conçus des designs de Data Warehouse spécialement adaptés pour créer des cubes OLAP.

Les exigences inhérentes à l’utilisation des cubes OLAP ont remodelé la manière dont les équipes data travaillaient et nourris des pratiques que l’on continuent de suivre encore aujourd’hui. Par exemple :

• Construire des pipelines ETL complexes pour modéliser les données.
• Recruter de grosses équipes d’ingénieurs data pour maintenir ces pipelines complexes.
• Utiliser les modèles de données de Kimball, Inmon ou Data Vault pour faciliter l’extraction des données et leur chargement dans les cubes OLAP. Et aujourd’hui, même quand on n’utilise plus de cubes OLAP, on continue d’utiliser ces bonnes pratiques pour charger les données dans les outils de BI et de Data Viz – en oubliant que ces pratiques avaient été conçus au départ pour les cubes OLAP.

Mais aujourd’hui la plupart des contraintes qui ont mené à l’émergence des cubes OLAP n’existent plus – ou se sont largement assouplies. Les ordinateurs sont plus rapides. La mémoire vive coûte moins cher. Le cloud est apparu. On a fini par s’apercevoir que les cubes OLAP généraient plus de problèmes qu’ils n’en résolvaient. D’où le progressif déclin des cubes OLAP.

Le progressif déclin du cube OLAP

Imaginons un instant un monde où les ressources serveurs ne coûtent plus grand-chose et où les ordinateurs sont devenus surpuissants. Imaginons un monde où les bases de données SQL sont suffisamment puissantes pour gérer à la fois les requêtes OLTP et les requêtes OLAP. A quoi ressemblerait un monde pareil ?

Ce serait un monde où les cubes OLAP n’aurait plus aucune utilité. Pourquoi s’ennuyer à créer et générer de nouveaux cubes OLAP lorsque l’on peut tout simplement exécuter des requêtes sur une base SQL existante ? Pourquoi s’embêter à maintenir une tuyauterie ETL complexe si la donnée dont vous avez besoin pour le reporting peut être simplement copié à partir des bases OLTP dans votre base OLAP ? Et pourquoi s’embêter à former des analystes à autre chose qu’au SQL ?

Ce ne sont pas des questions rhétoriques. Combien d’analystes ont souffert de devoir dépendre des ingénieurs data à chaque fois qu’il fallait recréer un cube OLAP et installer une nouvelle tuyauterie pour chaque nouveau besoin de BI ? Cela ralentissait le travail des analystes et créait du fil à retordre aux ingénieurs data.

Dans ce monde que nous avons imaginé, pourquoi mettre tant d’efforts dans la modélisation de données et leur maintenance, en utilisant les frameworks de type Kimball ou Inmon ?

Dès lors que l’on cesse d’utiliser les cubes OLAP pour l’analyse décisionnelle, on n’a plus besoin d’utiliser des pipelines complexes pour extraire la donnée du Data Warehouse. Et si l’on n’a plus besoin d’utiliser des pipelines complexes, on n’a plus besoin non plus de consommer autant d’énergie dans le design du Data Warehouse. Pourquoi le faire si l’on peut modéliser la donnée simplement en créant de nouvelles tables modélisées ou matérialiser de nouvelles vues dans le Data Warehouse ?

Dans le nouveau monde que nous avons imaginé, changer un schéma de données est très simple : Il vous suffit de vider la table (ou de lancer la vue) et d’en créer de nouvelles. Et puisque vos outils de reporting se connectent directement à votre base analytique, cela engendre peu de perturbations : Vous n’avez pas besoin  de ré-agencer vos pipelines ou de changer la manière dont vos cubes sont générés – pour la simple et bonne raison que vous n’avez plus besoin de créer de cubes OLAP. Ce nouveau monde que nous avons imaginé, c’est en fait le monde dans lequel on évolue aujourd’hui. En 2020, la méthode des cubes OLAP comporte plus d’inconvénients qu’elle n’a d’avantages. De nouvelles méthodes sont apparues, dessinant un paradigme nouveau.

L’émergence d’un nouveau paradigme : les BDD à colonnes

Il y a eu trois grosses avancées, trois gros changements depuis ces 20 dernières années. Les deux premiers sont faciles à comprendre. Nous parlerons plus en détail du troisième.

Le premier changement est une simple conséquence de la loi de Moore : les serveurs et la mémoire vive sont devenus une commodité – ils sont devenus très abordables grâce au développement du cloud. Aujourd’hui, tout le monde peut utiliser AWS ou Google Cloud et obtenir en quelques instants des ressources serveurs adaptées à ses besoins. Ceci s’applique aussi aux Data Warehouses Cloud – ces technologies permettent aux entreprises de stocker et d’analyser d’énormes volumes de données sans coûts fixes.

Le deuxième changement réside dans le fait que les Data Warehouses cloud d’aujourd’hui ont une architecture MPP (Massively parallel processing). Avec cette architecture, vous pouvez booster la performance de votre requête en la répartissant sur plusieurs centaines voire plusieurs milliers de machines. Vous n’êtes plus dépendant de la puissance de calcul d’un seul ordinateur. Chaque machine traite une partie de la requête, les résultats de chaque machine étant ensuite agrégés pour former le résultat final. Aujourd’hui une solution comme BigQuery permet de réaliser un regex match sur plus de 314 millions de lignes sans indices et de retourner le résultat en 10 secondes seulement.

Le troisième changement est le développement des Data Warehouses en colonnes. C’est le changement le plus important des trois. C’est surtout lui qui conduit aujourd’hui à abandonner les cubes et à revenir aux bases de données relationnelles pour exécuter des analyses OLAP.

Découvrez comment réussir l’analyse d’une base de données clients.

Une base de données relationnelle classique stocke ses données en rangées. Une rangée de transaction, par exemple, contient les champs « date », « client », « prix », « référence produit », etc; Une base de données en colonnes, en revanche, stocke chacun de ces champs dans des colonnes séparées. Voici un schéma illustrant bien la différence entre les deux (Source):

Avec un cube OLAP, vous devez charger un sous-ensemble des dimensions qui vous intéressent dans le cube. Avec une base de données en colonnes, vous pouvez faire les mêmes analyses OLAP, avec la même performance, sans avoir à extraire des données et sans avoir à créer de nouveaux cubes. En clair : Une base de données en colonnes est une base de données SQL parfaite pour faire des requêtes OLAP.

Voici les trois principaux bénéfices qu’il y a à stocker les données dans des colonnes :

• Les bases de données en colonnes ont une meilleure efficacité de lecture. Si vous exécutez une requête comme « Donne moi le prix moyen de toutes les transactions au cours des 5 dernières années » dans une BDD relationnelle, celle-ci devra charger toutes les rangées des 5 dernières années même si vous avez seulement besoin du champ « prix ». A l’inverse, une base de données en colonnes n’aura besoin d’analyser qu’une seule colonne – la colonne « prix »…La base de données en colonnes n’aura besoin de passer au crible qu’une fraction du dataset total.
• Les bases de données en colonnes compressent mieux les données. Lorsque vous stockez ensemble des données similaires, vous pouvez compresser beaucoup mieux que si vous stockez des informations très différentes. En théorie de l’information, cela renvoie au concept d’entropie de Shannon. Une base de données en colonnes stocke des données en colonnes – c’est-à-dire des valeurs de même type. C’est beaucoup plus facile à compresser que si vous utilisez une BDD en rangées. Cette meilleure capacité de compression permet de charger plus de données en mémoire lorsque vous faites une agrégation et donc d’exécuter les requêtes plus rapidement.
• Les bases de données en colonnes permettent de libérer de l’espace – un espace qui peut être utilisé pour trier et indexer les données dans les colonnes. Le triage et l’indexation des données est beaucoup plus efficace.

En résumé, les bases de données en colonnes proposent un niveau de performance égal à ce que proposent les cubes OLAP mais sans avoir à designer et créer les cubes ! Cela signifie que vous pouvez réaliser tout ce que vous voulez à l’intérieur du Data Warehouse. Le seul inconvénient des bases de données en colonnes est au niveau de la mise à jour des données. Vous devez aller dans chaque colonne pour mettre à jour une rangée. C’est pour cette raison d’ailleurs que beaucoup de BDD en colonnes modernes limitent votre capacité à mettre à jour les données une fois qu’elles sont stockées.

Conclusion

Amazon, Airbnb, Uber ou encore Google ont complètement abandonné le modèle du cube OLAP. Cet événement et quelques autres dessinent une double tendances en cours. Nous n’en sommes qu’au début. Les bases de données en colonnes MPP n’existent que depuis une dizaine d’années : BigQuery a été lancé en 2010, Amazon Redshift en 2012. Il faudra encore quelques années pour que les grosses entreprises fassent évoluer leurs habitudes encore très imprégnées de l’influence des cubes OLAP. Changer de paradigme prend toujours du temps.

Si vous travaillez dans la BI, ces nouvelles tendances qui émergent peuvent avoir un impact sur votre carrière. Il faut anticiper le déclin inéluctable selon nous du cube OLAP. Voici nos conseils :

• Maîtrisez le SQL. La majorité des BDD en colonnes MPP sont en SQL.
• Méfiez-vous des entreprises qui continuent de ne jurer que par les cubes OLAP.
• Familiarisez-vous avec les techniques de modélisation de l’âge des BDD en colonnes.
• Utilisez des ELT quand c’est possible – plutôt que des ETL.
• Étudiez les méthodologies Kimball, Inmon et Data Vault, mais avec du recul, en gardant le nouveau paradigme à l’esprit. Prenez conscience des limites de chacune des approches.

CRM / Data - Plus de 15 ressources & templates gratuits à télécharger.

Découvrir