Architecture d'entrepôt de données: traditionnelle et cloud

Bonjour, Habr! Beaucoup de choses ont été écrites sur le thème de l'architecture d'entrepôt de données, mais elles ne se sont pas encore réunies aussi succinctement et succinctement que dans un article sur lequel je suis accidentellement tombé.

Je vous invite à prendre connaissance de cet article dans ma traduction. Les commentaires et ajouts sont les bienvenus!


(Source de l'image)

Présentation

Ainsi, l'architecture des entrepôts de données est en train de changer. Dans cet article, nous comparerons les entrepôts de données d'entreprise traditionnels et les solutions cloud avec des coûts initiaux inférieurs, une évolutivité améliorée et des performances.

Un entrepôt de données est un système dans lequel les données sont collectées à partir de diverses sources au sein d'une entreprise et ces données sont utilisées pour soutenir les décisions de gestion.

Les entreprises se tournent de plus en plus vers des entrepôts de données basés sur le cloud au lieu de systèmes traditionnels sur site. Les stockages de données cloud présentent un certain nombre de différences par rapport aux stockages traditionnels:

• Pas besoin d'acheter de l'équipement physique;
• Les entrepôts de données cloud sont plus rapides et moins chers à configurer et à faire évoluer;
• Les entrepôts de données cloud peuvent généralement effectuer des requêtes analytiques complexes beaucoup plus rapidement car ils utilisent un traitement parallèle massif.

Architecture d'entrepôt de données traditionnelle

Les concepts suivants mettent en évidence certaines des idées et principes de conception établis utilisés pour créer des entrepôts de données traditionnels.

Architecture à trois niveaux

Très souvent, l'architecture traditionnelle de l'entrepôt de données a une structure à trois niveaux comprenant les niveaux suivants:

• Niveau inférieur : ce niveau contient le serveur de base de données utilisé pour récupérer des données à partir de nombreuses sources différentes, par exemple, à partir de bases de données transactionnelles utilisées pour des applications frontales.
• Niveau intermédiaire : le niveau intermédiaire contient un serveur OLAP qui transforme les données en une structure mieux adaptée à l'analyse et aux requêtes complexes. Un serveur OLAP peut fonctionner de deux manières: soit en tant que système avancé de gestion de bases de données relationnelles qui mappe les opérations de données multidimensionnelles aux opérations OLAP relationnelles standard, soit en utilisant un modèle OLAP multidimensionnel qui implémente directement les données et opérations multidimensionnelles.
• Niveau supérieur : le niveau supérieur est le niveau client. Ce niveau contient les outils utilisés pour l'analyse de données de haut niveau, la génération de rapports et l'analyse de données.

Kimball vs. Inmon

Deux pionniers des entrepôts de données: Bill Inmon et Ralph Kimball, proposent différentes approches de conception.

L'approche de Ralph Kimball est basée sur l'importance des data marts, qui sont des entrepôts de données appartenant à des entreprises spécifiques. Un entrepôt de données est simplement une combinaison de différents data marts qui facilitent le reporting et l'analyse. Le projet d'entrepôt de données basé sur Kimball utilise une approche ascendante.

L'approche de Bill Inmon est basée sur le fait que l'entrepôt de données est un stockage centralisé de toutes les données de l'entreprise. Avec cette approche, l'organisation crée d'abord un modèle d' entrepôt de données normalisé . Ensuite, des magasins de données dimensionnelles sont créés sur la base du modèle d'entrepôt. Ceci est connu comme une approche descendante d'entrepôt de données.

Modèles d'entrepôt de données

Dans l'architecture traditionnelle, il existe trois modèles généraux d'entrepôts de données: stockage virtuel, vitrine de données et entrepôt de données d'entreprise:

• Un entrepôt de données virtuel est un ensemble de bases de données distinctes qui peuvent être partagées afin que l'utilisateur puisse 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 vitrine de données est utilisé pour signaler et analyser des secteurs d'activité spécifiques. Dans ce modèle de stockage, des données agrégées à partir d'un certain nombre de systèmes sources liés à un domaine d'activité spécifique, comme les ventes ou les finances;
• Le modèle d'entrepôt de données d' entreprise implique le stockage de 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 d'un système d'information d'entreprise avec des données intégrées de toutes les unités commerciales.

Étoile contre Flocon de neige

Les schémas en étoile et en flocon de neige sont deux façons de structurer votre entrepôt de données.

Un schéma en étoile possède un entrepôt de données centralisé, qui est stocké dans une table de faits. Le graphique divise la table de faits en une série de tables de dimensions dénormalisées. La table de faits contient les données agrégées qui seront utilisées pour les rapports, et la table de dimension décrit les données stockées.

Les projets dénormalisés sont moins complexes car les données sont regroupées. La table de faits utilise un seul lien à attacher à chaque table de dimension. La conception plus simple en forme d'étoile simplifie considérablement l'écriture de requêtes complexes.


Un modèle de flocon de neige est différent en ce qu'il utilise des données normalisées. La normalisation signifie une organisation efficace des données afin que toutes les dépendances de données soient définies et que chaque table contienne un minimum de redondance. Ainsi, les tables de mesure individuelles sont fourchues en tables de mesure distinctes.

Le schéma de flocon de neige utilise moins d'espace disque et maintient mieux l'intégrité des données. Le principal inconvénient est la complexité des requêtes nécessaires pour accéder aux données - chaque requête doit passer par plusieurs jointures de table pour obtenir les données correspondantes.

ETL vs. ELT

ETL et ELT sont deux façons différentes de charger des données dans le stockage.

Les ETL (Extraire, Transformer, Charger) récupèrent d'abord les données d'un pool de sources de données. Les données sont stockées dans une base de données intermédiaire temporaire. Ensuite, des opérations de conversion sont effectuées pour structurer et transformer les données en une forme appropriée pour le système d'entrepôt de données cible. Ensuite, les données structurées sont chargées dans le stockage et prêtes pour l'analyse.


Dans le cas d' ELT (Extract, Load, Transform), les données sont immédiatement chargées après l'extraction à partir des pools de données source. Il n'y a pas de base de données intermédiaire, ce qui signifie que les données sont immédiatement téléchargées vers un seul référentiel centralisé.
Les données sont converties en un système d'entrepôt de données pour être utilisées avec des outils de business intelligence et d'analyse.

Maturité organisationnelle

La structure de l'entrepôt de données de l'organisation dépend également de sa situation actuelle et de ses besoins.

La structure de base permet aux utilisateurs finaux de stockage d'accéder directement aux données récapitulatives des systèmes source, de créer des rapports et d'analyser ces données. Cette structure est utile dans les cas où les sources de données proviennent des mêmes types de systèmes de base de données.


Le stockage avec une zone intermédiaire est la prochaine étape logique dans une organisation avec des sources de données hétérogènes avec de nombreux types et formats de données différents. La zone de transfert convertit les données dans un format structuré générique qui est plus facile à demander à l'aide d'outils d'analyse et de génération de rapports.


Une variante de la structure intermédiaire est l'ajout de data marts à l'entrepôt de données. Les magasins de données stockent des données récapitulatives sur un domaine d'activité spécifique, ce qui rend ces données facilement accessibles pour des formes spécifiques d'analyse.

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 et de prédire le comportement des clients. Les data marts facilitent l'analyse en adaptant les données spécifiquement pour répondre aux besoins des utilisateurs finaux.

Nouvelles architectures d'entrepôt de données

Ces dernières années, les entrepôts de données ont migré vers le cloud. Les nouveaux entrepôts de données cloud n'adhèrent pas à l'architecture traditionnelle et chacun d'entre eux propose sa propre architecture unique.

Cette section décrit brièvement les architectures utilisées par les deux stockages cloud les plus populaires: Amazon Redshift et Google BigQuery.

Amazon redshift

Amazon Redshift est une vue basée sur le cloud d'un entrepôt de données traditionnel.

Redshift nécessite que les ressources informatiques soient préparées et configurées en tant que clusters contenant une collection d'un ou plusieurs nœuds. Chaque nœud possède son propre processeur, sa propre mémoire et sa propre RAM. Le nœud principal compile les demandes et les transmet aux nœuds de calcul qui exécutent les demandes.

À chaque nœud, les données sont stockées dans des blocs appelés tranches . Redshift utilise le stockage de colonnes, c'est-à-dire que chaque bloc de données contient des valeurs d'une colonne sur plusieurs lignes, et non d'une ligne avec des valeurs de plusieurs colonnes.


Redshift utilise l'architecture MPP (Massively Parallel Processing), divisant les grands ensembles de données en morceaux qui sont affectés à des tranches dans chaque nœud. Les demandes sont plus rapides car les nœuds de calcul traitent les demandes dans chaque tranche en même temps. Le nœud Leader Node combine les résultats et les renvoie à l'application cliente.

Les applications clientes telles que les outils de BI et d'analyse peuvent se connecter directement à Redshift à l'aide des pilotes open source PostgreSQL JDBC et ODBC. De cette façon, les analystes peuvent effectuer leurs tâches directement sur les données Redshift.

Redshift ne peut charger que des données structurées. Vous pouvez charger des données dans Redshift à l'aide de systèmes pré-intégrés, y compris Amazon S3 et DynamoDB, en transférant des données à partir de n'importe quel hôte local avec une connexion SSH ou en intégrant d'autres sources de données à l'aide de l'API Redshift.

Google bigquery

L'architecture BigQuery ne nécessite pas de serveur, ce qui signifie que Google contrôle dynamiquement l'allocation des ressources informatiques. Par conséquent, toutes les décisions de gestion des ressources sont cachées à l'utilisateur.

BigQuery permet aux clients de télécharger des données depuis Google Cloud Storage et d'autres sources de données lisibles. Une alternative est le streaming de données, qui permet aux développeurs d'ajouter des données à l'entrepôt de données en temps réel, ligne par ligne, lorsqu'elles deviennent disponibles.

BigQuery utilise un moteur de requête appelé Dremel, qui peut analyser des milliards de lignes de données en quelques secondes. Dremel utilise des requêtes massivement parallèles pour analyser les données dans le système de gestion de fichiers de base Colossus. Colossus distribue des fichiers en morceaux de 64 mégaoctets parmi une variété de ressources informatiques appelées nœuds, qui sont regroupées en clusters.
Dremel utilise une structure de données de colonne similaire à Redshift. L'architecture arborescente envoie des requêtes à des milliers de machines en quelques secondes.

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

Panoplie

Panoply fournit une gestion complète des données en tant que service. Son architecture unique d'auto-optimisation utilise l'apprentissage automatique et le traitement du langage naturel (NLP) pour modéliser et rationaliser le transfert de données de la source à l'analyse, réduisant le temps entre les données et les valeurs aussi près de zéro que possible.

Panoply Intelligent Data Infrastructure comprend les fonctionnalités suivantes:

• Analyse des requêtes et des données - déterminer la meilleure configuration pour chaque cas d'utilisation, l'ajuster dans le temps et créer des index, des clés de tri, des clés de disque, des types de données, l'évacuation et le partitionnement.
• Identifie les requêtes qui ne suivent pas les meilleures pratiques - par exemple, celles qui incluent des boucles imbriquées ou des transtypages implicites - et les réécrivent dans une requête équivalente qui nécessite une fraction du temps d'exécution ou des ressources.
• Optimisez la configuration du serveur au fil du temps en fonction des modèles de requête et découvrez quelle configuration de serveur fonctionne le mieux. La plateforme change de façon transparente les types de serveurs et mesure les performances globales.

Au-delà du stockage cloud

L'entreposage de données basé sur le cloud est une grande amélioration par rapport aux approches d'architecture traditionnelles. Cependant, les utilisateurs rencontrent toujours un certain nombre de problèmes lors de leur configuration:

• Le téléchargement de données vers des entrepôts de données basés sur le cloud n'est pas anodin et les pipelines de données à grande échelle nécessitent une configuration, des tests et une prise en charge du processus ETL. Cette partie du processus est généralement effectuée par des outils tiers;
• Les mises à jour, insertions et suppressions peuvent être complexes et doivent être effectuées avec soin pour éviter une dégradation des performances des requêtes;
• Les données semi-structurées sont difficiles à gérer - elles doivent être normalisées dans un format de base de données relationnelle, ce qui nécessite l'automatisation de grands flux de données;
• Les structures imbriquées ne sont généralement pas prises en charge dans les entrepôts de données cloud. Vous devez convertir les tables imbriquées dans des formats que l'entrepôt de données comprend;
• Optimisation de cluster . Il existe différentes options pour configurer un cluster Redshift pour exécuter vos charges de travail. Différentes charges de travail, jeux de données ou même différents types de requêtes peuvent nécessiter des configurations différentes. Pour obtenir des performances optimales, il est nécessaire de revoir en permanence et, si nécessaire, de configurer en plus la configuration;
• Optimisation des requêtes - les requêtes des utilisateurs peuvent ne pas suivre les meilleures pratiques et prendront donc beaucoup plus de temps. Vous pouvez travailler avec des utilisateurs ou des applications client automatisées pour optimiser les requêtes afin que l'entrepôt de données puisse fonctionner comme prévu
• Sauvegarde et restauration - bien que les fournisseurs de stockage de données offrent de nombreuses options pour sauvegarder vos données, ils ne sont pas simples à configurer et nécessitent une surveillance et une attention particulière.

Lien vers le texte original: panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud