Générer un schéma en étoile dans une ruche

Question

Je suis issu du monde SQL Datawarehouse où, à partir d'un flux plat, je génère des tables de dimension et de faits. Dans les projets généraux d'entrepôt de données, nous divisons l'alimentation en faits et en dimensions. Ex:

Je suis complètement nouveau pour Hadoop et je suis venu pour savoir que je peux construire l'entrepôt de données dans la ruche. Maintenant, je suis familier avec l'utilisation de guid qui, je pense, est applicable en tant que clé primaire dans la ruche. Donc, la stratégie ci-dessous est la bonne façon de charger le fait et la dimension dans la ruche?

1. Charger les données source dans une table de ruche; disons Sales_Data_Warehouse

2. Générer Dimension à partir de sales_data_warehouse; ex:

   SELECT New_Guid(), Customer_Name, Customer_Address De Sales_Data_Warehouse

3. Lorsque toutes les dimensions sont faites ensuite charger la table de fait comme

   SELECT New_Guid() AS 'Fact_Key', Customer.Customer_Key, Magasin .Store_Key ... dE 'source' Sales_Data_Warehouse AS REJOIGNEZ Customer_Dimension client sur source.Customer_Name = Customer.Customer_Name ET source.Customer_Address = Customer.Customer_Address REJOIGNEZ Store_Dimension AS 'Store' ON Store.Store_Name = Source.St ore_Name JOIN produit 'Product_Dimension AS ON .....

Est-ce la façon dont je devrais charger mon fait et une table de dimension dans la ruche? En outre, dans les projets d'entrepôt général, nous devons mettre à jour les attributs de dimensions (ex: Customer_Address est changé en quelque chose d'autre) ou mettre à jour la clé étrangère de table de faits (rarement, mais cela arrive). Alors, comment puis-je avoir une charge INSERT-UPDATE dans la ruche. (Comme nous le faisons Lookup dans SSIS ou MERGE Statement dans TSQL)?

Answer 1

Nous bénéficions toujours des avantages des modèles dimensionnels sur Hadoop et Hive. Cependant, certaines fonctionnalités de Hadoop nous obligent à adopter légèrement l'approche standard de la modélisation dimensionnelle.

Le système de fichiers Hadoop est immuable. Nous pouvons seulement ajouter mais pas mettre à jour les données. Par conséquent, nous ne pouvons ajouter que des enregistrements aux tables de dimension (While Hive a ajouté une fonctionnalité de mise à jour et des transactions, ce qui semble être plutôt bogué). Changement lent de dimensions sur Hadoop devient le comportement par défaut. Afin d'obtenir l'enregistrement le plus récent et le plus à jour dans une table de dimension, nous avons trois options. Tout d'abord, nous pouvons créer une vue qui récupère le dernier enregistrement en utilisant les fonctions de fenêtrage. Deuxièmement, nous pouvons avoir un service de compactage en arrière-plan qui recrée l'état le plus récent. Troisièmement, nous pouvons stocker nos tables de dimension dans un stockage mutable, par ex. HBase et fédérez les requêtes entre les deux types de stockage.

La façon dont les données sont distribuées sur HDFS rend l'assemblage de données coûteux. Dans une base de données relationnelle distribuée (MPP), nous pouvons co-localiser des enregistrements avec les mêmes clés primaires et étrangères sur le même noeud dans un cluster. Cela rend relativement peu coûteux de rejoindre de très grandes tables. Aucune donnée n'a besoin de se déplacer sur le réseau pour effectuer la jointure. Ceci est très différent sur Hadoop et HDFS. Sur les tables HDFS, les tables sont divisées en gros morceaux et réparties sur les nœuds de notre cluster. Nous n'avons aucun contrôle sur la manière dont les enregistrements individuels et leurs clés sont répartis dans le cluster. En conséquence, se connecter à Hadoop pour deux très grandes tables est assez cher que les données doivent voyager à travers le réseau. Nous devrions éviter les jointures si possible.Pour un grand tableau de faits et de dimensions, nous pouvons dé-normaliser la table de dimension directement dans la table de faits. Pour deux tables de transactions très volumineuses, nous pouvons imbriquer les enregistrements de la table enfant dans la table parent et aplatir les données lors de l'exécution. Nous pouvons utiliser des extensions SQL telles que array_agg dans BigQuery/Postgres etc. pour gérer plusieurs grains dans une table de faits

Je voudrais également mettre en doute l'utilité des clés de substitution. Pourquoi ne pas utiliser la clé naturelle? Peut-être que la performance pour les clés composées complexes peut être un problème, mais sinon les clés de substitution ne sont pas vraiment utiles et je ne les utilise jamais.