Avantages de l'utilisation de la base de données intermédiaire lors de la conception de l'entrepôt de données
Je suis en train de concevoir une architecture d'entrepôt de données. En explorant diverses options pour extraire des données de la production et les mettre dans Data Warehouse, je suis tombé sur de nombreux articles qui suggéraient principalement de suivre deux approches -
- DB de production ----> Entrepôt de données (schéma en étoile) ----> OLAP Cube
- DB de production ----> Base de données intermédiaire ----> Entrepôt de données (schéma en étoile) ----> OLAP Cube
Je ne sais toujours pas laquelle est la meilleure approche en termes de performances et de réduction de la charge de traitement sur la base de données de production.
Quelle approche préférez-vous lors de la conception de l'entrepôt de données?
Les points ci-dessous sont tirés de, DWBI Organization's article
Une zone de transit peut être requise si vous avez l'un des scénarios suivants:
- Chargement Delta : Vos données sont lues de manière incrémentielle à partir de la source et vous avez besoin d'un stockage intermédiaire où un ensemble incrémentiel de vos données peut être stocké temporairement à des fins de transformation
- Besoin de transformation : Vous devez effectuer un nettoyage des données, une validation, etc. avant de consommer les données dans l'entrepôt
- Découplage : Votre traitement prend beaucoup de temps et vous ne voulez pas rester connecté à votre système source (probablement le système source est constamment utilisé par les utilisateurs professionnels réels) pendant toute la durée de votre traitement et, par conséquent, préférez simplement lire les données du système source en une seule fois, vous déconnecter de la source, puis continuer à traiter les données de votre "propre côté"
- Objectif de débogage : Vous n'avez pas besoin de revenir à votre source tout le temps et vous pouvez résoudre les problèmes (le cas échéant) à partir de la zone de transfert uniquement
- Recovery Failure : Le système source peut être transitoire et l'état des données peut changer. Si vous rencontrez une défaillance en amont, vous ne serez peut-être pas en mesure de ré-extraire vos données car la source a changé à ce moment-là. Avoir une copie locale aide
Les performances et le traitement réduit peuvent ne pas être uniquement des considérations. L'ajout d'une mise en scène peut parfois augmenter latency (c'est-à-dire le délai entre l'occurrence d'une incidence commerciale et sa déclaration). Mais j'espère que les points ci-dessus vous aideront à porter un meilleur jugement.
ETL = Extraire, Transformer et Charger. Aide de la base de données intermédiaire avec le bit de transformation. Personnellement, j'inclus toujours une étape intermédiaire DB et ETL.
Une base de données intermédiaire permet d'obtenir vos données source dans des structures équivalentes à vos destinations FACT et DIMENSION de l'entrepôt de données. Il dissocie également votre entrepôt et votre processus ETL d'entrepôt de vos données source.
Si vos tables de destination de l'entrepôt de données mappent à peu près vos tables de base de données de production avec seulement quelques champs de dimension supplémentaires, vous pourriez vous débrouiller en ignorant la base de données intermédiaire. Cela vous fera gagner un peu de temps de développement. Je ne le recommande pas car vous:
- Finira par lier votre solution d'entrepôt de données directement à votre base de données source
- Va probablement se retrouver avec une étape ETL très compliquée
- Peut se retrouver avec des conditions de concurrence/des enregistrements orphelins en raison de changements dans votre base de données source pendant le processus ETL
- Les gens de l'entrepôt de données peuvent vous faire des sons de type "hrumph"
Il est fort probable que vous effectuiez une sorte de manipulation de données (conversion de dates en clés DATE_DIM, agrégation de valeurs), auquel cas une base de données intermédiaire vous aidera à séparer votre logique de transformation et vos calculs de vos opérations d'entrepôt de données (dimensionnement des données).
Vous avez peut-être également rencontré ce type de modèle:
[PROD DB] -(ETL)-> [RAW DB] -(ETL)-> [STAGING DB] -(ETL)-> [DW DB] -(ETL)-> [DM DB]
que si les considérations de performances sont importantes, vous voudrez peut-être regarder. Dans votre cas, RAW_DB pourrait être une copie 1: 1 exacte de votre base de données de production et l'étape ETL qui la crée pourrait simplement être une recréation de la base de données à partir de la sauvegarde nocturne la plus récente. (Traditionnellement, RAW_DB était utilisé pour obtenir des données de diverses sources externes avec chaque champ sous forme de texte pur, ces champs étant ensuite convertis en leur type de données attendu avec des exceptions traitées comme rencontrées. Ce n'est pas vraiment un problème lorsque vous avez une source et son une belle base de données normalisée fortement typée)
À partir de ce RAW_DB, le processus ETL suivant tronquerait et remplirait le transfert de telle sorte que la STAGING DB contienne tous les enregistrements nouveaux/mis à jour qui entrent dans l'entrepôt.
Un autre avantage supplémentaire de toutes ces étapes est qu'il aide vraiment à déboguer des données étranges, car pour toute exécution donnée, vous pouvez voir les valeurs d'enregistrement dans chacune des bases de données de différence et identifier le processus ETL qui introduit la tristesse.
Il y a quelques avantages potentiels à utiliser une base de données intermédiaire, qui peut ou non s'appliquer à votre situation. Il n'y a pas de solution parfaite et universelle. Certains des avantages potentiels comprennent:
- Si cela est approprié, vous pouvez prendre un instantané de votre base de données de production (vous pouvez déjà avoir une sauvegarde quotidienne ou un instantané de site actif), puis faire votre ETL à partir de la sauvegarde ou de l'instantané restauré. Cela pourrait économiser de la charge sur votre base de données de production.
- Vous pouvez avoir besoin d'un traitement compliqué pour votre ETL qui nécessite de nombreuses tables intermédiaires qui n'ont aucune utilité sauf pour le processus ETL. Vous ne voudrez peut-être pas encombrer votre entrepôt de données avec ces tables intermédiaires.
- Vos données brutes peuvent ne pas être disponibles d'un seul coup et vous avez besoin d'un endroit pour les accumuler avant de commencer votre processus ETL pour construire votre entrepôt de données.
- Votre entrepôt de données peut avoir des exigences de fenêtre de production qui ne peuvent pas être satisfaites par votre ETL et vous devez donc organiser votre "sortie" (c'est-à-dire de nouveaux enregistrements pour l'entrepôt de données) plutôt que ou en plus de votre base de données de production.
- Le système de production peut se trouver dans un environnement hautement sécurisé et pour une raison quelconque, une décision peut avoir été prise de ne pas permettre au processus ETL un accès complet aux données de production brutes. Le groupe qui contrôle la base de données de production peut vouloir extraire uniquement les données nécessaires vers une base de données intermédiaire afin que le processus ETL ne puisse voir que ce dont il a besoin. J'ai vu cela où le système de production et le processus ETL sont gérés par différents fournisseurs tiers.
- Il se peut que votre processus ETL crée de grandes tables intermédiaires. Parfois, la gestion de l'espace est plus facile si vous commencez avec une base de données de modèles vide pour votre zone de transit ETL, puis la "jetez" chaque jour plutôt que d'essayer de récupérer l'espace de manière plus chirurgicale, comme vous pourriez le faire avec une base de données de production ou de génération de rapports .
Il existe également des inconvénients possibles, qui peuvent ou non vous intéresser. Le plus important est d'avoir un autre serveur de base de données. De nombreux avantages pourraient être vides de sens si vous utilisez le même serveur pour héberger les bases de données de production et/ou d'entrepôt de données.
Vraiment, la zone de rassemblement n'est pas une nécessité si nous pouvons la gérer à la volée. Mais le pouvons-nous? Voici quelques raisons pour lesquelles vous ne pouvez pas éviter une zone de transit: 1. Les systèmes source ne sont disponibles que pour l'extraction pendant un intervalle de temps spécifique qui est généralement inférieur à votre temps de chargement de données global. C'est une bonne idée d'extraire et de conserver les choses de votre côté avant de perdre la connexion aux systèmes source. 2. Vous souhaitez extraire des données en fonction de certaines conditions qui nécessitent que vous joigniez deux systèmes différents ou plus. Par exemple. vous souhaitez extraire uniquement les clients qui existent également dans un autre système. Vous ne pourrez pas effectuer de requête SQL joignant deux tables de deux bases de données physiquement différentes. 3. Différents systèmes sources ont un timing différent pour l'extraction des données. 4. La fréquence de chargement des données de l'entrepôt de données ne correspond pas aux fréquences de rafraîchissement des systèmes source 5. Les données extraites du même ensemble de systèmes source vont être utilisées à plusieurs endroits (chargement de l'entrepôt de données, chargement ODS, applications tierces, etc. .) 6. Le processus ETL implique des transformations de données complexes qui nécessitent un espace supplémentaire pour mettre en scène temporairement les données.
La zone de transfert claire donne beaucoup de flexibilité lors du chargement des données. Ne devrions-nous pas toujours avoir une zone de rassemblement séparée? Y a-t-il un impact à avoir une zone scénique? Oui, il y en a quelques-uns. 1. La zone de transit augmente la latence, c'est-à-dire le temps nécessaire pour qu'un changement dans le système source prenne effet dans l'entrepôt de données. Dans de nombreuses applications en temps réel/quasi temps réel, la zone de transit est plutôt évitée Les données dans la zone de transfert occupent un espace supplémentaire 2. Pour moi, dans tous les sens pratiques, l'avantage d'avoir une zone de transfert l'emporte sur ses problèmes. par conséquent, en général, je proposerai de désigner une zone de transit spécifique dans les projets d'entreposage de données.