Architecture Data Warehouse – Approches Traditionnelle vs Cloud

Et vous, êtes-vous sur place ou dans les nuages ?

Un Data Warehouse (ou entrepôt de données) est un système informatique permettant de regrouper les données d’une entreprise provenant de différentes sources puis d’utiliser ces données pour aider les prises de décision.

De nombreuses entreprises se tournent désormais vers des Data Warehouses basés sur le cloud, se différenciant des solutions traditionnelles « sur site » par trois principaux aspects :

• L’entreprise n’a plus besoin d’acheter de matériel hardware
• La mise en place puis la gestion sont plus simples et plus rapides
• Les requêtes analytiques complexes sont exécutées plus rapidement grâce au MPP (Massively Parallel Processing)

Mais alors comment fonctionne une architecture Data Warehouse traditionnelle ? Et quels sont les nouveaux principes et enjeux introduits par les architectures Data Warehouse Cloud ? Ce sont à ces questions que nous allons répondre.

Les architectures Data Warehouse traditionnelles

Voyons ensemble les concepts et principes qui façonnent les architectures Data Warehouse traditionnelles.

L’architecture trois tiers

Un Data Warehouse traditionnel s’appuie sur une architecture trois tiers composée des tiers suivants :

• L’accès aux données : contient le serveur de base de données utilisé pour extraire les données de nombreuses sources différentes, comme les bases de données transactionnelles utilisées pour les applications frontales
• Le traitement : contient un serveur OLAP, qui transforme les données en une structure mieux adaptée à l’analyse et aux requêtes complexes. Le serveur OLAP peut fonctionner de deux manières : soit comme un système étendu de gestion de base de données relationnelles qui associe les opérations sur des données multidimensionnelles à des opérations relationnelles standard (OLAP relationnel), soit en utilisant un modèle OLAP multidimensionnel qui implémente directement les données et opérations multidimensionnelles
• La présentation : correspond à la couche client. Ce tiers contient les outils utilisés pour l’analyse de données de haut niveau, le reporting et le data mining (exploration de données)

Kimball vs. Inmon

Deux pionniers des Data Warehouses, Bill Inmon et Ralph Kimball, avaient des approches différentes de la conception de ces entrepôts de données.

L’approche de Ralph Kimball a mis en avance l’importance des Data Marts, des dépôts de données appartenant à des secteurs d’activité particuliers. Le Data Warehouse est simplement une combinaison de différents Data Marts qui facilite le reporting et l’analyse. Cette conception de Kimball correspond à l’approche ascendante (« bottom-up »).

Bill Inmon considérait lui le Data Warehouse comme le dépôt centralisé de toutes les données de l’entreprise. Dans cette approche, une organisation crée d’abord un modèle de Data Warehouse normalisé. Les Data Marts des différents secteurs sont ensuite créés sur la base du modèle de l’entrepôt. C’est ce qu’on appelle une approche descendante (ou « top-down ») de l’entreposage des données.

Les modèles de Data Warehouse

Dans une architecture traditionnelle, il existe trois modèles communs de Data Warehouses : Data Warehouse virtuel, Data Mart et Data Warehouse d’entreprise :

• Un Data Warehouse virtuel est un ensemble de bases de données séparées, qui peuvent être interrogées ensemble, de sorte qu’un utilisateur peut accéder efficacement à toutes les données comme si elles étaient stockées dans un seul entrepôt de données.
• Un modèle de Data Mart est utilisé pour les rapports et les analyses spécifiques à un secteur d’activité. Dans ce modèle d’entrepôt de données, les données sont agrégées à partir d’une gamme de systèmes sources pertinents pour un domaine d’activité spécifique, comme les ventes ou la finance.
• Un Data Warehouse d’entreprise implique que l’entrepôt de données doit contenir des données agrégées couvrant l’ensemble de l’organisation. Ce modèle considère l’entrepôt de données comme le cœur du système d’information de l’entreprise, avec des données intégrées provenant de toutes les unités d’affaires.

Schéma en étoile et Schéma en flocon

Le schéma en étoile et le schéma en flocon sont deux façons de structurer un Data Warehouse.

Le schéma en étoile possède un dépôt de données centralisé, stocké dans une table des faits. Le schéma divise la table des faits en une série de tables de dimensions non normalisées. La table des faits contient des données agrégées à utiliser à des fins de reporting, tandis que la table de dimensions décrit les données stockées.

Les tables non normalisées sont moins complexes du fait que les données sont groupées. La table des faits n’utilise qu’un seul lien pour se joindre à chaque table de dimensions. La conception plus simple du schéma en étoile facilite grandement l’écriture de requêtes complexes.

Le schéma du flocon est différent car il normalise les données : il les organise efficacement de sorte que toutes les dépendances de données soient définies et que chaque table contienne un minimum de redondances. Les tables unidimensionnelles se divisent donc en tables de dimensions séparées.

Le schéma du flocon utilise moins d’espace disque et préserve mieux l’intégrité des données. Son principal inconvénient est la complexité des requêtes nécessaires pour accéder aux données : chaque requête doit creuser profondément pour accéder aux données pertinentes puisqu’il y a plusieurs jointures.

Les méthodes ETL et ELT

ETL et ELT sont deux méthodes différentes de chargement des données dans un Data Warehouse.

Extract, Transform, Load (ETL) extrait d’abord les données d’un ensemble de sources de données, qui sont typiquement des bases de données transactionnelles. Les données sont conservées dans une base de données temporaire. Des opérations de transformation sont ensuite effectuées pour structurer et convertir les données en une forme appropriée pour le système Data Warehouse cible. Les données structurées sont ensuite chargées dans le magasin, prêtes à être analysées.

Avec Extract, Load, Transform (ELT), les données sont chargées immédiatement après avoir été extraites des ensembles de données sources. Il n’y a pas de base de données temporaire, ce qui signifie que les données sont immédiatement chargées dans le référentiel unique et centralisé. Les données sont transformées à l’intérieur du système Data Warehouse pour être utilisées avec des outils de business intelligence et d’analyse.

Maturité de l’entreprise

La structure du Data Warehouse d’une organisation dépend également de sa situation actuelle et de ses besoins.

La structure de base permet aux utilisateurs finaux de l’entrepôt d’accéder directement aux données sommaires dérivées des systèmes sources et d’effectuer l’analyse, la production de rapports et l’exploration de ces données. Cette structure est utile lorsque les sources de données proviennent des mêmes types de systèmes de bases de données.

Un Data Warehouse avec une zone de « staging » est l’étape logique suivante dans une organisation avec des sources de données disparates comportant de nombreux types et formats de données différents. La zone de staging convertit les données dans un format structuré résumé qui est plus facile à interroger à l’aide d’outils d’analyse et de reporting.

Une variante de la structure de staging est l’ajout de Data Marts au Data Warehouse. Les Data Marts stockent des données résumées pour un secteur d’activité particulier, ce qui rend ces données facilement accessibles pour des formes d’analyse et de reporting spécifiques. Par exemple, l’ajout de Data Marts peut permettre à un analyste financier d’effectuer plus facilement des requêtes détaillées sur les données de vente, pour faire des prédictions sur le comportement des clients. Les Data Marts facilitent l’analyse en adaptant les données aux besoins spécifiques de l’utilisateur final.

Les nouvelles architectures Data Warehouse Cloud

Ces dernières années, les Data Warehouses se sont déplacés vers le Cloud. Ces nouveaux entrepôts de données n’adhèrent pas à l’architecture traditionnelle ; et chaque entrepôt de données offre une architecture unique.

Cette partie présente les architectures utilisées par trois des Data Warehouses Cloud les plus populaires : Amazon Redshift, Google BigQuery et Panoply.

Amazon Redshift

Amazon Redshift est une représentation sur le Cloud d’un Data Warehouse traditionnel.

Redshift exige que les ressources informatiques soient provisionnées et mises en place sous forme de clusters, qui contiennent une collection d’un ou plusieurs nœuds. Chaque nœud a ses propres CPU, stockage et RAM. Un nœud leader compile les requêtes et les transfère vers des nœuds de calcul, qui exécutent les requêtes.

Sur chaque nœud, les données sont stockées en plusieurs parties, appelés tranches. Redshift utilise un stockage en colonnes, ce qui signifie que chaque bloc de données contient les valeurs d’une seule colonne sur plusieurs lignes, au lieu d’une seule ligne avec les valeurs de plusieurs colonnes.

Redshift utilise une architecture MPP (Massively Parallel Processing), divisant les grands ensembles de données en parties qui sont assignés aux tranches de chaque nœud. Les requêtes sont plus rapides car les nœuds de calcul traitent les requêtes dans chaque tranche simultanément. Le nœud chef agrège ensuite les résultats et les renvoie à l’application client.

Les applications client, telles que les outils de BI et d’analyse, peuvent se connecter directement à Redshift à l’aide des pilotes open source PostgreSQL JDBC et ODBC. Les analystes peuvent ainsi effectuer leurs tâches directement sur les données Redshift.

Redshift ne peut charger que des données structurées. Il est possible de charger des données vers Redshift à l’aide de systèmes pré-intégrés tels que Amazon S3 et DynamoDB, en poussant les données de n’importe quel hôte sur site avec une connectivité SSH, ou en intégrant d’autres sources de données à l’aide de l’API Redshift.

Google BigQuery

L’architecture de BigQuery est sans serveur, ce qui signifie que Google gère dynamiquement l’allocation des ressources machine. Toutes les décisions de gestion des ressources sont donc cachées à l’utilisateur.

BigQuery permet aux clients de charger des données à partir de Google Cloud Storage et d’autres sources de données lisibles. L’autre option consiste à diffuser les données en continu, ce qui permet aux développeurs d’ajouter des données au Data Warehouse en temps réel, rangée par rangée, au fur et à mesure qu’elles deviennent disponibles.

BigQuery utilise un moteur d’exécution de requêtes nommé Dremel, qui peut scanner des milliards de lignes de données en quelques secondes. Dremel utilise la MPP pour scanner les données dans le système de gestion de fichiers Colossus sous-jacent. Colossus distribue les fichiers en morceaux de 64 mégaoctets parmi de nombreuses ressources informatiques appelées noeuds, qui sont regroupés en clusters.

Dremel utilise une structure de données en colonnes, similaire à Redshift. Une architecture arborescente répartit les requêtes entre des milliers de machines en quelques secondes.

Des commandes SQL simples sont utilisées pour effectuer des requêtes sur les données.

Les enjeux liés à la mise en place d’un Data Warehouse Cloud

Les Data Warehouses Cloud représentent un grand pas en avant par rapport aux architectures traditionnelles. Cependant, les utilisateurs doivent encore faire face à plusieurs défis lors de leur mise en place :

• Le chargement des données dans les Data Warehouses Cloud n’est pas trivial et, pour les pipelines de données à grande échelle, il faut mettre en place, tester et maintenir un processus ETL. Cette partie du processus est généralement réalisée à l’aide d’outils tiers.
• Les mises à jour, les ajouts et les suppressions de données peuvent être délicats et doivent être faits avec soin pour empêcher la dégradation de la performance des requêtes.
• Les données semi-structurées sont difficiles à traiter – elles doivent être normalisées dans un format de base de données relationnelle, ce qui nécessite une automatisation pour les flux de données importants.
• Les structures imbriquées ne sont généralement pas prises en charge dans les Data Warehouses Cloud. Vous devrez transformer les tables imbriquées dans un format que l’entrepôt de données peut comprendre.
• Optimisation de votre cluster : il existe différentes options pour configurer un cluster Redshift afin d’exécuter vos charges de travail. Différentes charges de travail, ensembles de données ou même types de requêtes peuvent nécessiter une configuration différente. Pour rester optimal, vous devrez continuellement revoir et ajuster votre configuration.
• Optimisation des requêtes : les requêtes des utilisateurs peuvent ne pas suivre les meilleures pratiques et, par conséquent, leur exécution prendra beaucoup plus de temps. Vous pouvez travailler avec des utilisateurs ou des applications clients automatisées pour optimiser les requêtes afin que le Data Warehouse puisse fonctionner comme prévu.
• Sauvegarde et restauration : bien que les fournisseurs de Data Warehouses offrent de nombreuses options de sauvegarde de vos données, elles ne sont pas triviales à mettre en place et nécessitent une surveillance et une attention particulière.

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

Découvrir