hadoop - une - schema ruche abeille



Génération d'un schéma en étoile dans une ruche (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 exemple des requêtes HBase et fédérées sur les deux types de stockage.

La façon dont les données sont distribuées sur HDFS rend l'intégration des données coûteuse. 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 sur 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.

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 à Hadoop et je suis venu à savoir que je peux construire un 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 à partir de Sales_Data_Warehouse

  3. Quand toutes les dimensions sont faites, chargez la table de faits comme

    SELECT New_Guid () AS «Fact_Key», Customer.Customer_Key, Store.Store_Key ... FROM Sales_Data_Warehouse AS «source» JOIN Customer_Dimension Client sur source.Customer_Name = Customer.Customer_Name ET source.Customer_Address = Customer.Customer_Address JOIN Store_Dimension AS 'Magasin' ON Store.Store_Name = Source.Store_Name JOIN Product_Dimension AS 'Produit' SUR .....

Est-ce la façon dont je devrais charger mon fait et table de dimension dans la ruche?

En outre, dans les projets d'entrepôt généraux, 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 la table des 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)?





fact