Manuel de construction d'entrepôt de données Hive

1 Théorie de la superposition et de la modélisation de l'entrepôt de données

1.1 Objectif de l'entrepôt de données

• Intégrer toutes les données commerciales de l'entreprise et établir un centre de données unifié
• Générer des rapports commerciaux pour la prise de décision
• Fournir un support de données opérationnelles pour les opérations du site Web
• Il peut être utilisé comme source de données pour chaque entreprise, formant un cercle vertueux de rétroaction mutuelle des données d'entreprise
• Analysez les données de comportement des utilisateurs, réduisez les coûts d'entrée et améliorez les effets d'entrée grâce à l'exploration de données
• Développer des produits de données qui profitent directement ou indirectement à l'entreprise

1.2 Schéma d'architecture d'exploitation de l'entrepôt de données

1.3 La différence entre datamart et datawarehouse

Data Mart (marché de données) : il s'agit d'un entrepôt de données miniature, qui contient généralement moins de données, moins de domaines et moins de données historiques, il est donc au niveau du département et généralement uniquement pour une certaine gamme de services de gestion.

Entrepôt de données (Data Warehouse): L'entrepôt de données est au niveau de l'entreprise et peut fournir des moyens d'aide à la décision pour le fonctionnement de divers départements de l'ensemble de l'entreprise.

1.4 Hiérarchie des entrepôts de données

1.4.1 Raisons de la stratification

• Simplifiez les problèmes complexes : décomposez les tâches complexes en plusieurs couches à compléter, et chaque couche ne gère que les tâches simples, ce qui est pratique pour localiser les problèmes.
• Réduisez le développement répétitif : standardisez la superposition des données et utilisez les données de la couche intermédiaire pour réduire un grand nombre de calculs répétés et augmenter la réutilisabilité des résultats de calcul.
• Isolez les données brutes : qu'il s'agisse d'anomalies ou de sensibilité des données, découplez les données réelles des données statistiques.

1.4.2 Modèle hiérarchique de base

ODS (couche source de données, données brutes) – ETL --> DWD (couche détail des données) – hive sql --> DWS (résumé des données) – sqoop --> ADS (application de données : rapports, portraits d'utilisateurs)

1.5 Hiérarchie des entrepôts de données

1.5.1 Présentation de la hiérarchie des entrepôts de données

Dans le système de données d'Alibaba, il est recommandé de diviser l'entrepôt de données en trois couches, de bas en haut :

Couche d'introduction de données ODS (Operation Data Store): stocke les données brutes non traitées dans le système d'entrepôt de données, ce qui est cohérent avec la structure du système source et constitue la zone de préparation des données de l'entrepôt de données. Effectuez principalement les tâches d'importation des données de base dans MaxCompute et enregistrez les modifications historiques des données de base.

Couche publique de données CDM (Common Data Model, également connu sous le nom de couche de modèle de données commun) : y compris la table de dimension DIM, DWD et DWS, traitées à partir des données de la couche ODS. Compléter principalement le traitement et l'intégration des données, établir des dimensions cohérentes, créer des tableaux de faits détaillés réutilisables pour l'analyse et les statistiques, et résumer les indicateurs de granularité publics Selon les caractéristiques commerciales actuelles, seule la couche DWD est temporairement établie

• Couche de faits détaillée (DWD) : avec le processus métier comme pilote de modélisation, en fonction des caractéristiques de chaque processus métier spécifique, créez la table de faits la plus détaillée au niveau des détails. Certains champs d'attributs de dimension importants de la table de faits détaillée peuvent être redondants de manière appropriée en combinaison avec les caractéristiques d'utilisation des données de l'entreprise, c'est-à-dire le traitement de table large.

• Couche intermédiaire de données : DWM (Data Ware House Middle) Cette couche effectuera des opérations légères d'agrégation sur les données à partir des données de la couche DWD, générera une série de tables intermédiaires, améliorera la réutilisabilité des indicateurs publics et réduira les traitements répétés. Intuitivement parlant, il s'agit d'agréger les dimensions du tronc commun et de calculer les indicateurs statistiques correspondants.

• Couche de faits de granularité de résumé public (DWS) : avec l'objet d'analyse comme pilote de modélisation, en fonction des exigences de niveau supérieur de l'application et de l'indicateur de produit, créez une table de faits d'indicateur de résumé granulaire public et personnalisez le modèle au moyen d'un large tableau. Construire des indicateurs statistiques avec des conventions de dénomination et un calibre cohérent, fournir des indicateurs publics pour la couche supérieure et établir des tableaux récapitulatifs larges et des tableaux de faits détaillés.

• Couche de dimension commune (DIM) : basée sur le concept de modélisation dimensionnelle, établissez une dimension cohérente pour l'ensemble de l'entreprise. Réduisez le risque de calibre et d'algorithmes de calcul de données incohérents. Les tables de la couche de dimension commune sont généralement également appelées tables de dimension logique, et les dimensions et les tables logiques de dimension sont généralement en correspondance un à un.

• Couche application de données ADS (Application Data Service) : stocke les données d'index statistiques personnalisées des produits de données. Généré selon le traitement des couches CDM et ODS.

Chinois et anglais et abréviations :

Couche d'introduction des données (ODS, Operation Data Store)

Couche publique de données (CDM, Common Data Model)

Couche de dimension commune (DIM, Dimension)

Détail de l'entrepôt de données (DWD, détail de l'entrepôt de données)

Couche de synthèse des données (DWS, Data Warehouse Service)

Couche application de données (ADS, Application Data Service)

1.5.2 Usages de chaque niveau

**1) Couche d'introduction des données (ODS, Operation Data Store) : **Les données d'origine sont stockées dans le système d'entrepôt de données avec presque aucun traitement. La structure est fondamentalement cohérente avec le système source, et c'est la zone de préparation des données de l'entrepôt de données. Données brutes, principalement des données ponctuelles enfouies (données de journal) et des données d'exploitation commerciale (binlong), la source de données est principalement Mysql, HDFS, Kafka, etc.

2) Couche publique de données (CDM, Common Data Model, également connue sous le nom de couche de modèle de données commun) , y compris la table de dimension DIM, DWD et DWS, traitée à partir des données de la couche ODS. Il complète principalement le traitement et l'intégration des données, établit des dimensions cohérentes, construit des tableaux de faits détaillés réutilisables pour l'analyse et les statistiques, et résume les indicateurs de granularité publique . Cette couche comprend trois couches :

• Couche de dimension commune (DIM) :

1. Sur la base du concept de modélisation dimensionnelle, établissez une dimension cohérente pour l'ensemble de l'entreprise. Réduisez le risque de calibre et d'algorithmes de calcul de données incohérents. Les tables de la couche de dimension commune sont généralement également appelées tables de dimension logique, et les dimensions et les tables logiques de dimension sont généralement en correspondance un à un.
2. Utilisez principalement trois moteurs de stockage : MySQL, Hbase et Redis. MySQL peut être utilisé lorsque les données de la table de dimension sont relativement petites. Dans le cas où la taille des données individuelles est relativement petite et le QPS de la requête est relativement élevé, le stockage Redis peut être utilisé pour réduire l'occupation des ressources mémoire de la machine. Pour les scénarios où la quantité de données est relativement importante et n'est pas particulièrement sensible aux modifications des données de la table de dimension, le stockage HBase peut être utilisé.

• Couche de détail de l'entrepôt de données (DWD) :

1. La couche d'ODS est nettoyée et déposée sur cette couche, qui est généralement la granularité la plus fine.
2. Avec le processus métier comme pilote de modélisation, **construisez la table de faits la plus détaillée au niveau des détails en fonction des caractéristiques de chaque processus métier spécifique. ** En combinaison avec les caractéristiques d'utilisation des données de l'entreprise, certains champs d'attributs de dimension importants de la table de faits détaillée peuvent être redondants de manière appropriée, c'est-à-dire un traitement de table large.

• Couche de synthèse des données (DWS) :

1. Légère agrégation de la couche DWD et agrégation de certains indicateurs cumulatifs pour augmenter la réutilisabilité.
2. En prenant l'objet d'analyse comme pilote de modélisation, en fonction des exigences de l'application de niveau supérieur et de l'index de produit, créez une table de faits d'index récapitulative avec une granularité publique et personnalisez le modèle au moyen d'une table large. Construire des indicateurs statistiques avec des conventions de dénomination et un calibre cohérent, fournir des indicateurs publics pour la couche supérieure et établir des tableaux récapitulatifs larges et des tableaux de faits détaillés. Les tables de la couche de faits de granularité récapitulative publique sont généralement également appelées tables logiques récapitulatives, qui sont utilisées pour stocker les données d'indicateur dérivées.

3) Couche application de données (ADS, Application Data Service) : stocke les données d'index statistiques personnalisées des produits de données. Généré selon le traitement des couches CDM et ODS.

1.6 Spécifications de développement

1.6.1 Règles de nommage

1) couche ods

增量数据： {
    
    project_name}.ods_{
    
    数据来源}_{
    
    源系统表名}_delta
全量数据： {
    
    project_name}.ods_{
    
    数据来源}_{
    
    源系统表名}
 
数据来源说明：
01 -> hdfs 数据
02 -> mysql 数据
03 -> redis 数据
04 -> mongodb 数据
05 -> tidb 数据
 
举例如下：
行为日志表： ods_01_action_log
用户表： ods_02_user

2) couche sombre

公共区域维表： {
    
    project_name}.dim_pub_{
    
    自定义命名标签}
具体业务维表： {
    
    project_name}.dim_{
    
    业务缩写}_{
    
    自定义命名标签}
 
举例如下：
公共区域维表： dim_pub_area
公共时间维表： dim_pub_date
A公司电商板块的商品全量表： dim_asale_itm

3) couche dwd

多个业务公共表： {
    
    project_name}.dwd_pub_{
    
    自定义命名标签}
具体业务数据增量表： {
    
    project_name}.dwd_{
    
    业务缩写}_{
    
    自定义命名标签}_di
具体业务数据全量表： {
    
    project_name}.dwd_{
    
    业务缩写}_{
    
    自定义命名标签}_df
 
举例如下：
交易会员信息事实表：ods_asale_trd_mbr_di
交易商品信息事实表：dwd_asale_trd_itm_di
交易订单信息事实表：dwd_asale_trd_ord_di

4) couche dws

多个业务公共表： {
    
    project_name}.dws_pub_{
    
    自定义命名标签}
具体业务最近一天汇总事实表： {
    
    project_name}.dws_{
    
    业务缩写}_{
    
    自定义命名标签}_1d
具体业务最近N天汇总事实表： {
    
    project_name}.dws_{
    
    业务缩写}_{
    
    自定义命名标签}_nd
具体业务历史截至当天汇总表： {
    
    project_name}.dws_{
    
    业务缩写}_{
    
    自定义命名标签}_td
具体业务小时汇总表： {
    
    project_name}.dws_{
    
    业务缩写}_{
    
    自定义命名标签}_hh
 
举例如下：
dws_asale_trd_byr_subpay_1d（A电商公司买家粒度交易分阶段付款一日汇总事实表）
dws_asale_trd_byr_subpay_td（A电商公司买家粒度分阶段付款截至当日汇总表）
dws_asale_trd_byr_cod_nd（A电商公司买家粒度货到付款交易汇总事实表）
dws_asale_itm_slr_td（A电商公司卖家粒度商品截至当日存量汇总表）
dws_asale_itm_slr_hh（A电商公司卖家粒度商品小时汇总表）---维度为小时
dws_asale_itm_slr_mm（A电商公司卖家粒度商品分钟汇总表）---维度为分钟

5) couche d'annonces

{
    
    project_name}.ads_{
    
    业务缩写}_{
    
    自定义命名标签}
 
举例如下：
订单统计表： ads_nshop_order_form
订单支付统计： ads_nshop_orderpay_form

1.7 Malentendus sur la superposition

La division interne de la couche de l'entrepôt de données n'est pas destinée à la stratification, mais à la résolution de divers problèmes tels que l'organisation des tâches et des flux de travail ETL, le flux de données, le contrôle des autorisations de lecture et d'écriture et la satisfaction de différents besoins.

Une pratique plus courante dans l'industrie consiste à diviser l'ensemble de la couche d'entrepôt de données (DW) en couches dwd, dwb, dws, dim, mid et bien d'autres. Cependant, nous ne pouvons toujours pas dire quelles sont les limites claires entre ces couches, ou nous pouvons expliquer clairement les limites entre elles, mais des scénarios commerciaux complexes nous empêchent de les mettre en œuvre.

Par conséquent, les trois couches de couches de données, ODS, DWD et DWS, sont généralement les plus élémentaires :

Quant à la façon de diviser la couche DW, elle est définie en fonction des besoins spécifiques de l'entreprise et des scénarios de l'entreprise.

• La superposition est le but de résoudre le flux de données et de soutenir rapidement les affaires ;
• Il doit être pénétré selon le domaine d'étude et le domaine d'activité ;
• Il n'y a pas de dépendance inverse entre les couches.
• Si le support de données peut être complété en s'appuyant sur les données de la couche ODS, alors le côté métier utilise directement la couche d'atterrissage, ce qui est également propice à l'exploration et à l'expérimentation rapides et peu coûteuses de certaines données.
• Après avoir déterminé la spécification en couches, il est préférable de suivre cette structure à l'avenir, et elle peut être convenue ;
• La consanguinité, la dépendance des données, le dictionnaire de données, les conventions de dénomination des données, etc. sont d'abord pris en charge ;

La superposition dans DW n'est pas la plus correcte, seulement la plus appropriée pour vous.

1.8 Malentendus des tableaux larges

Les tables larges sont introduites au niveau de l'entrepôt de données. La soi-disant table large, jusqu'à présent, il n'y a pas de définition claire. Une pratique courante consiste à associer de nombreuses dimensions, synthèses de faits ou explorations vers le bas à une certaine table de faits pour former une table qui contient à la fois un grand nombre de dimensions et de faits associés.

L'utilisation de tables larges a sa commodité certaine. L'utilisateur n'a pas besoin de considérer l'association avec la table de dimension, ni de comprendre ce que sont la table de dimension et la table de faits.
Cependant, à mesure que l'entreprise se développe, nous ne pouvons toujours pas concevoir et définir de manière prévisible le nombre de dimensions qui doivent être redondantes dans les tableaux larges, ni définir clairement où se situe la ligne de fond des dimensions redondantes dans les tableaux larges.

Une situation possible est que pour répondre aux exigences d'utilisation, les colonnes existantes dans la table de dimension doivent être continuellement ajoutées à la table large. Cela conduit directement à des changements fréquents dans la structure de table de la table large.

Ce que nous faisons actuellement c'est :

• Selon le domaine sujet et le domaine métier, triez tous les nœuds d'une certaine activité ;
• Utilisez les données des nœuds clés comme base de la table de faits, puis développez horizontalement les données cumulées d'autres tables de faits (y compris certains indicateurs statistiques), et ajoutez en même temps les dimensions correspondant à certaines clés primaires sur le nœud verticalement;
• L'implication des tables larges ne dépend pas d'exigences métier spécifiques mais correspond à l'ensemble du métier ;
• Essayez d'utiliser la modélisation dimensionnelle au lieu de tableaux larges ;

Pourquoi utiliser autant que possible la modélisation dimensionnelle au lieu de tableaux larges ? Même si les champs et les données sont redondants, le mode de modélisation dimensionnelle représentera également la quantité totale de données. Le mode tableau large est préférable. Raisons :

• La modélisation dimensionnelle est basée sur un certain fait établi. Puisqu'il s'agit d'une table de faits, la granularité de la table de faits ne changera fondamentalement pas si l'activité de cette pièce ne change pas ;
• La table de faits et la table de dimension sont découplées, et la modification de la table de dimension n'affectera fondamentalement pas la table de faits, et la table de résultats n'a besoin que d'actualiser le flux de données ;
• De nouvelles dimensions peuvent être ajoutées dynamiquement selon le schéma en étoile ou le schéma en flocon de neige ;
• Le modèle dimensionnel peut être utilisé comme base de la table large. Une fois que l'ensemble du flux de données est déterminé, la table large correspondante peut être régénérée via le modèle dimensionnel pour un support commercial rapide ;

Table à 2 dimensions et table de faits

• Tables Hive_dimension et tables de faits

2.1 Tableau des dimensions

Tableau de dimension : décrit généralement les faits. Chaque table de dimension correspond à un objet ou un concept dans le monde réel. Par exemple : utilisateur, produit, date, région, etc.

Caractéristiques du tableau des dimensions :

• Les tableaux de dimension ont une portée étendue (avec plusieurs attributs, comparaisons de colonnes)
• Par rapport à la table de faits, le nombre de lignes est relativement faible : généralement < 100 000
• Le contenu est relativement fixe : liste de codes

Tableau de dimension temporelle :

ID de date	jour de la semaine	jour de l'année	le quartier	vacances
2020-01-01	2	1	1	Nouvelle année
2020-01-02	3	2	1	aucun
2020-01-03	4	3	1	aucun
2020-01-04	5	4	1	aucun
2020-01-05	6	5	1	aucun

2.2 Tableau des faits

Tables de faits : chaque entrepôt de données contient une ou plusieurs tables de faits. Les tables de faits peuvent contenir des données sur les ventes commerciales, telles que celles produites par les transactions de caisse enregistreuse, et les tables de faits contiennent généralement un grand nombre de lignes. La principale caractéristique d'une table de faits est qu'elle contient des données numériques (faits), et ces informations numériques peuvent être agrégées pour fournir des données sur l'unité sous forme d'historique. Chaque table de faits contient un index en plusieurs parties qui contient Clé Pertinence La table de dimension est la clé primaire tandis que la table de dimension contient les attributs de l'enregistrement de faits. Les tables de faits ne doivent pas contenir d'informations descriptives ni de données autres que les champs de mesure numériques et les champs d'index associés qui font correspondre les faits aux éléments de la table de dimension.

Il existe deux types de "mesures" incluses dans une table de faits : l'une est une mesure qui peut être cumulée et l'autre est une mesure qui n'est pas cumulée. Les mesures les plus utiles sont celles qui peuvent être cumulées, les chiffres qui s'additionnent sont très significatifs. Les utilisateurs peuvent obtenir des informations agrégées en accumulant des métriques, par ex. Vous pouvez résumer les ventes d'un article spécifique pour un groupe de magasins sur une période spécifique. Des mesures non cumulatives peuvent également être utilisées dans les tables de faits. Les résultats agrégés n'ont généralement pas de sens. Par exemple, lors de la mesure de la température à différents endroits d'un bâtiment, il est inutile d'additionner les températures à tous les différents endroits du bâtiment, mais le calcul de la moyenne sens.

De manière générale, une table de données de faits est associée à une ou plusieurs tables de latitude, et les utilisateurs peuvent utiliser une ou plusieurs tables de dimension lors de la création de cubes avec des tables de données de faits .

Chaque ligne de données de la table de faits représente un événement commercial (commande, paiement, remboursement, avis, etc.). Le terme "fait" fait référence à la valeur de mesure d'un événement commercial (temps dénombrables, nombre, montant, etc.), par exemple, le 21 mai 2020, M. Song Song a acheté une bouteille de ginseng marin pour 250 yuans en Pilule JD.com. Tableaux de dimension : temps, utilisateur, produit, commerçant. Fiche technique : 250 yuans, une bouteille

Les lignes de chaque table de faits comprennent : des valeurs de mesures numériques additives, des clés étrangères connectées à des tables de dimensions, généralement avec deux clés étrangères ou plus.

Caractéristiques d'une table de faits :

• très grand
• Le contenu est relativement étroit : le nombre de colonnes est faible (principalement l'identifiant de la clé étrangère et la valeur de la mesure)
• Change fréquemment, avec de nombreux ajouts chaque jour.

1) Table de faits transactionnelle

Considérez chaque transaction ou événement comme une unité, comme un enregistrement de commande client, un enregistrement de paiement, etc., comme une ligne de données dans la table de faits. Une fois la transaction validée et les données de la table de faits insérées, les données ne seront plus modifiées et la méthode de mise à jour est la mise à jour incrémentielle.

2) Tableau de faits d'instantanés périodiques

Les tables de faits d'instantanés périodiques ne conservent pas toutes les données, mais uniquement les données à des intervalles de temps fixes, telles que les ventes quotidiennes ou mensuelles, ou les soldes de compte mensuels.

Par exemple, les paniers d'achat, avec ajout et soustraction de produits, peuvent changer à tout moment, mais nous sommes plus préoccupés par le nombre de produits présents à la fin de chaque journée, ce qui est pratique pour notre analyse statistique ultérieure.

3) Tableau des faits instantanés cumulatifs

Une table de faits d'instantanés cumulés est utilisée pour suivre les modifications apportées aux faits commerciaux. Par exemple, l'entrepôt de données peut avoir besoin d'accumuler ou de stocker les données ponctuelles de chaque étape commerciale de la commande à partir du moment où la commande est passée jusqu'au moment où la commande est emballée, expédiée et signée pour suivre le déroulement du cycle de déclaration de commande. Lorsque ce processus métier est en cours, les enregistrements de la table de faits sont également constamment mis à jour.

numéro de commande	ID de l'utilisateur	temps de commande	temps d'emballage	Délai de livraison	Heure de soumission	montant de la commande
		3-8	3-8	3-9	3-10

3 Planification de la modélisation de l'entrepôt de données

3.1 Couche ODS

Comment planifions-nous et traitons-nous les données sur le comportement des utilisateurs et les données commerciales sur HDFS ?

(1) Conservez l'apparence d'origine des données sans aucune modification et jouez le rôle de sauvegarde des données.

(2) Les données sont compressées pour réduire l'espace de stockage sur disque (par exemple : les données d'origine sont de 100 G, qui peuvent être compressées à environ 10 G)

(3) Créer une table de partition pour empêcher les analyses ultérieures complètes de la table

3.2 Couche DIM et couche DWD

La couche DIM et la couche DWD doivent construire un modèle dimensionnel, qui adopte généralement un modèle en étoile, et l'état présenté est généralement un modèle de constellation.

La modélisation dimensionnelle suit généralement les quatre étapes suivantes :

Sélectionnez Processus métier→Granularité de la déclaration→Confirmer la dimension→Confirmer le fait

(1) Sélectionnez le processus métier

Dans le système de gestion, sélectionnez le secteur d'activité qui nous intéresse, tel que le secteur des commandes, le secteur des paiements, le secteur des remboursements, le secteur de la logistique, et un secteur d'activité correspond à une table de faits.

(2) Granularité des déclarations

La granularité des données fait référence au niveau de raffinement ou d'exhaustivité des données stockées dans l'entrepôt de données.

Déclarer la granularité signifie définir précisément ce que représente une ligne de données dans la table de faits. La granularité la plus petite doit être sélectionnée autant que possible pour répondre aux différents besoins.

Une déclaration de granularité typique ressemble à ceci :

Une ligne de données dans la table de faits de commande représente un article de base dans une commande.

Une ligne de données dans la table des faits de paiement représente un enregistrement de paiement.

(3) Déterminer la dimension

Le rôle principal des dimensions est de décrire les faits commerciaux, exprimant principalement des informations telles que "qui, où et quand".

Le principe de détermination des dimensions est le suivant : s'il faut analyser les indicateurs des dimensions connexes dans les exigences ultérieures. Par exemple, il est nécessaire de faire des statistiques sur le moment où le plus de commandes ont été passées, quelle région a passé le plus de commandes et quel utilisateur a passé le plus de commandes. Les dimensions qui doivent être déterminées incluent : la dimension temporelle, la dimension régionale et la dimension utilisateur.

(4) Déterminer les faits

Le mot "fait" fait ici référence à la valeur de mesure dans l'entreprise (temps, nombre, nombre de pièces, montant, qui peut être cumulé), comme le montant de la commande, le numéro de commande, etc.

Au niveau de la couche DWD, le processus métier est utilisé comme moteur de modélisation et, en fonction des caractéristiques de chaque processus métier spécifique, la table de faits la plus fine de la couche détail est construite. Les tables de faits peuvent être élargies de manière appropriée.

L'association entre la table de faits et la table de dimension est relativement souple, mais afin de répondre à des besoins métiers plus complexes, vous pouvez associer autant que possible les tables pouvant être associées.

	temps	utilisateur	zone	marchandise	coupon	Activité	métrique
Commande	√	√	√				Frais d'expédition/montant de l'offre/montant initial/montant final
détails de la commande	√	√	√	√	√	√	Nombre de pièces/Montant de la prime/Montant initial/Montant final
payer	√	√	√				montant du paiement
ajouter un achat	√	√		√			Nombre de pièces/quantité
collecter	√	√		√			fréquence
évaluer	√	√		√			fréquence
Rétrofacturation	√	√	√	√			Nombre de pièces/quantité
Remboursement	√	√	√	√			Nombre de pièces/quantité
Collecte de coupons	√	√			√		fréquence

Jusqu'à présent, la modélisation dimensionnelle de l'entrepôt de données est terminée et la couche DWD est pilotée par les processus métier.

La couche DWS, la couche DWT et la couche ADS sont toutes axées sur la demande et n'ont rien à voir avec la modélisation dimensionnelle.

DWS et DWT construisent des tableaux larges et construisent des tableaux selon des thèmes. Le thème équivaut à l'angle d'observation du problème. Correspond au tableau des dimensions.

3.3 Couche DWS et couche DWT

La couche DWS et la couche DWT sont collectivement appelées la couche de surface large.Les idées de conception des deux couches sont à peu près les mêmes et sont illustrées à travers les cas suivants.

1) La question est tirée : deux exigences, compter le nombre de commandes dans chaque province et compter le nombre total de commandes dans chaque province

2) Méthode de traitement : joindre la table de province et la table de commande, grouper par province, puis calculer. Les mêmes données sont calculées deux fois, et en fait il y aura plus de scénarios similaires.

Alors, comment la conception peut-elle éviter le double comptage ?

Pour le scénario ci-dessus, une table à l'échelle de la région peut être conçue, dont la clé primaire est l'ID de région, et les champs incluent : les heures de commande, le montant de la commande, les heures de paiement, le montant du paiement, etc. Tous les indicateurs ci-dessus sont calculés de manière uniforme et les résultats sont enregistrés dans le tableau large, ce qui permet d'éviter efficacement le double calcul des données.

3) Résumé :

(1) Quelles tables larges doivent être construites : en fonction des dimensions.

(2) Champs de la table large : examinez la table de faits du point de vue de différentes dimensions, en vous concentrant sur les valeurs de mesure agrégées de la table de faits.

(3) La différence entre les couches DWS et DWT : la couche DWS stocke le comportement récapitulatif de tous les objets sujets du jour, tels que le nombre de commandes passées dans chaque région le jour, le montant de la commande, etc., et le La couche DWT stocke le comportement cumulé de tous les objets sujets, tels que le nombre de commandes passées et le nombre de commandes passées dans chaque région au cours des 7 derniers jours (15 jours, 30 jours, 60 jours).

3.4 Couche ADS

Analyser séparément les principaux indicateurs thématiques du système de commerce électronique.

4 Combat d'entrepôt de données Hive

1 Construction de la couche ODS

1.1 Fonctions et responsabilités de la couche ODS

1) Conservez l'apparence d'origine des données sans aucune modification et jouez le rôle de sauvegarde des données.

2) Les données sont compressées par LZO pour réduire l'espace de stockage sur le disque. Les données 100G peuvent être compressées à moins de 10G.

3) Créez une table de partition pour empêcher les analyses de table complètes ultérieures et utilisez les tables de partition de manière intensive dans le développement d'entreprise.

4) Créez une table externe. Dans le développement d'entreprise, en plus de créer des tables temporaires pour votre propre usage et de créer des tables internes, la plupart des scénarios consistent à créer des tables externes.

1.2 Construction de la couche ODS - importation de données - couverture complète

Il n'y a pas besoin de partitions, et chaque synchronisation consiste à supprimer d'abord, puis à écrire, en écrasant directement.

Applicable aux situations où il n'y aura pas de nouveaux ajouts ou modifications aux données.

Par exemple, les données de dimension telles que les tables de dictionnaire régional, l'heure et le sexe ne changeront pas ou changeront rarement, et seules les dernières valeurs peuvent être conservées.

Ici, nous prenons la table de dictionnaire de zone t_district comme exemple à expliquer.

DROP TABLE if exists yp_ods.t_district;
CREATE TABLE yp_ods.t_district
(
    `id` string COMMENT '主键ID',
    `code` string COMMENT '区域编码',
    `name` string COMMENT '区域名称',
    `pid`  int COMMENT '父级ID',
    `alias` string COMMENT '别名'
)
comment '区域字典表'
row format delimited fields terminated by '\t' 
stored as orc tblproperties ('orc.compress'='ZLIB');

synchronisation des données sqoop

Étant donné que les tables sont stockées au format ORC, l'API HCatalog est requise lors de l'utilisation de sqoop pour importer des données.

-- Sqoop导入之前可以先原表的数据进行清空
truncate table yp_ods.t_district;

方式1-使用1个maptask进行导入
sqoop import  \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select * from t_district where \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_district \
--m 1

1.3 Construction de la couche ODS – Importation de données – Synchronisation incrémentielle

Une nouvelle partition de date est ajoutée chaque jour, et les nouvelles données du jour sont synchronisées et stockées.

Par exemple, table de journal de connexion, table de journal d'accès, table d'enregistrement des transactions, table d'évaluation des produits, table d'évaluation des commandes, etc.

Ici, nous prenons la table de journal de connexion t_user_login comme exemple à expliquer.

DROP TABLE if exists yp_ods.t_user_login;
CREATE TABLE if not exists yp_ods.t_user_login(
   id string,
   login_user string,
   login_type string COMMENT '登录类型（登陆时使用）',
   client_id string COMMENT '推送标示id(登录、第三方登录、注册、支付回调、给用户推送消息时使用)',
   login_time string,
   login_ip string,
   logout_time string
) 
COMMENT '用户登录记录表'
partitioned by (dt string)
row format delimited fields terminated by '\t'
stored as orc tblproperties ('orc.compress' = 'ZLIB');

synchronisation des données sqoop

• Première fois (montant total)

1. Quel que soit le mode, la première fois est une synchronisation complète ; lorsque le cycle est à nouveau synchronisé, vous pouvez contrôler vous-même la portée des données de synchronisation via la condition where ;

2. ${TD_DATE} représente la date de partition, qui devrait normalement être la veille d'aujourd'hui, car dans des circonstances normales, il est midi et le travail de la veille est terminé, donc le champ de partition de les données doivent appartenir à la veille.

3. À des fins de démonstration, ${TD_DATE} est codé en dur en premier.

sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *,'2022-11-18' as dt from t_user_login where  \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_user_login \
--m 1

• Boucle (synchronisation incrémentale)

#!/bin/bash
date -s '2022-11-20'  #模拟导入增量19号的数据

#你认为现在是2022-11-20，昨天是2022-11-19
TD_DATE=`date -d '1 days ago' "+%Y-%m-%d"`
/usr/bin/sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *, '${TD_DATE}' as dt from t_user_login where 1=1 and (login_time between '${TD_DATE} 00:00:00' and 
'${TD_DATE} 23:59:59') and  \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_user_login \
-m 1

1.4 Construction de la couche ODS - importation de données - synchronisation nouvelle et mise à jour

Une nouvelle partition de date est ajoutée chaque jour, et les données nouvelles et mises à jour de la journée sont synchronisées et stockées.

Applicable aux données nouvelles et mises à jour, telles que les tables d'utilisateurs, les tables de commandes, les tables de produits, etc.

Ici, nous prenons la table t_store shop comme exemple pour expliquer.

drop table if exists yp_ods.t_store;
CREATE TABLE yp_ods.t_store
(
    `id`                 string COMMENT '主键',
    `user_id`            string,
    `store_avatar`       string COMMENT '店铺头像',
    `address_info`       string COMMENT '店铺详细地址',
    `name`               string COMMENT '店铺名称',
    `store_phone`        string COMMENT '联系电话',
    `province_id`        INT COMMENT '店铺所在省份ID',
    `city_id`            INT COMMENT '店铺所在城市ID',
    `area_id`            INT COMMENT '店铺所在县ID',
    `mb_title_img`       string COMMENT '手机店铺 页头背景图',
    `store_description` string COMMENT '店铺描述',
    `notice`             string COMMENT '店铺公告',
    `is_pay_bond`        TINYINT COMMENT '是否有交过保证金 1：是0：否',
    `trade_area_id`      string COMMENT '归属商圈ID',
    `delivery_method`    TINYINT COMMENT '配送方式  1 ：自提 ；3 ：自提加配送均可; 2 : 商家配送',
    `origin_price`       DECIMAL,
    `free_price`         DECIMAL,
    `store_type`         INT COMMENT '店铺类型 22天街网店 23实体店 24直营店铺 33会员专区店',
    `store_label`        string COMMENT '店铺logo',
    `search_key`         string COMMENT '店铺搜索关键字',
    `end_time`           string COMMENT '营业结束时间',
    `start_time`         string COMMENT '营业开始时间',
    `operating_status`   TINYINT COMMENT '营业状态  0 ：未营业 ；1 ：正在营业',
    `create_user`        string,
    `create_time`        string,
    `update_user`        string,
    `update_time`        string,
    `is_valid`           TINYINT COMMENT '0关闭，1开启，3店铺申请中',
    `state`              string COMMENT '可使用的支付类型:MONEY金钱支付;CASHCOUPON现金券支付',
    `idCard`             string COMMENT '身份证',
    `deposit_amount`     DECIMAL(11,2) COMMENT '商圈认购费用总额',
    `delivery_config_id` string COMMENT '配送配置表关联ID',
    `aip_user_id`        string COMMENT '通联支付标识ID',
    `search_name`        string COMMENT '模糊搜索名称字段:名称_+真实名称',
    `automatic_order`    TINYINT COMMENT '是否开启自动接单功能 1：是  0 ：否',
    `is_primary`         TINYINT COMMENT '是否是总店 1: 是 2: 不是',
    `parent_store_id`    string COMMENT '父级店铺的id，只有当is_primary类型为2时有效'
)
comment '店铺表'
partitioned by (dt string) 
row format delimited fields terminated by '\t' 
stored as orc tblproperties ('orc.compress'='ZLIB');

synchronisation des données sqoop

La clé pour réaliser une synchronisation nouvelle et mise à jour est qu'il y a deux champs liés au temps dans la table :

create_time L'heure de création ne sera pas modifiée une fois générée

update_time heure de mise à jour des données modification de l'heure

Contrôlez vous-même la portée des données synchronisées via la condition where.

• d'abord

sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *,'2022-11-18' as dt  from t_store where 1=1 and \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_store \
-m 1

• cycle

#!/bin/bash
date -s '2022-11-20'
TD_DATE=`date -d '1 days ago' "+%Y-%m-%d"`
/usr/bin/sqoop import "-Dorg.apache.sqoop.splitter.allow_text_splitter=true" \
--connect 'jdbc:mysql://192.168.88.80:3306/yipin?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true' \
--username root \
--password 123456 \
--query "select *, '${TD_DATE}' as dt from t_store where 1=1 and ((create_time between '${TD_DATE} 00:00:00' and '${TD_DATE} 23:59:59') or (update_time between '${TD_DATE} 00:00:00' and '${TD_DATE} 23:59:59')) and  \$CONDITIONS" \
--hcatalog-database yp_ods \
--hcatalog-table t_store \
-m 1

Enfin, toutes les tables de couches ODS importées de MySql

1.5 Résumé

Voici une introduction à la construction de la couche ODS du nouveau projet de vente au détail de l'entrepôt de données HIVe, principalement de trois manières.

1. Couverture complète
2. Synchronisation incrémentale
3. Synchronisation des nouveaux ajouts et mises à jour

2 Construction de la couche DWD

2.1 Fonctions et responsabilités de la couche DWD

Nettoyez les données dans la table de couche ods, reportez-vous aux règles de nettoyage des données et nettoyez les données en fonction de la situation réelle.

注意：如果清洗规则使用SQL可以实现，那么就使用SQL实现数据清洗，如果清洗的规则使用SQL实现起来非常麻烦，或者使用SQL压根无法实现，此时就可以考虑需要使用MapReduce代码或者Spark代码对数据进行清洗了。

• La couche dwd est appelée la couche de données détaillées en chinois.

• La fonction principale :

  • Nettoyage et transformation des données, fournissant une assurance qualité ;
  • Distinguer les faits et les dimensions.

• Spécification du nom de table

  dwd.fact_xxxxxx

  Tableau principal des commandes, règlement des commandes, groupe de commandes, remboursement de la commande, instantané du produit de la commande, panier, collecte en magasin, etc.

  dwd.dim_yyyyyy

  Utilisateur, zone, heure, magasin, quartier d'affaires, informations d'adresse, produit, catégorie de produit, marque, etc.

2.2 Construction de la couche DWD - tableau des dimensions régionales - importation de couverture complète

DROP TABLE if EXISTS yp_dwd.dim_district;
CREATE TABLE yp_dwd.dim_district(
  id string COMMENT '主键ID', 
  code string COMMENT '区域编码', 
  name string COMMENT '区域名称', 
  pid string COMMENT '父级ID', 
  alias string COMMENT '别名')
COMMENT '区域字典表'
row format delimited fields terminated by '\t'
stored as orc 
tblproperties ('orc.compress' = 'SNAPPY');

Opération de couverture complète

INSERT overwrite TABLE yp_dwd.dim_district
select * from yp_ods.t_district
WHERE code IS NOT NULL AND name IS NOT NULL;

2.3 Construction de la couche DWD - formulaire d'évaluation de la commande - importation incrémentielle

#解释：每一次增量的数据都创建一个分区进行报错
DROP TABLE if EXISTS yp_dwd.fact_goods_evaluation;
CREATE TABLE yp_dwd.fact_goods_evaluation(
  id string, 
  user_id string COMMENT '评论人id', 
  store_id string COMMENT '店铺id', 
  order_id string COMMENT '订单id', 
  geval_scores int COMMENT '综合评分', 
  geval_scores_speed int COMMENT '送货速度评分0-5分(配送评分)', 
  geval_scores_service int COMMENT '服务评分0-5分', 
  geval_isanony tinyint COMMENT '0-匿名评价，1-非匿名', 
  create_user string, 
  create_time string, 
  update_user string, 
  update_time string, 
  is_valid tinyint COMMENT '0 ：失效，1 ：开启')
COMMENT '订单评价表'
partitioned by (dt string)
row format delimited fields terminated by '\t'
stored as orc 
tblproperties ('orc.compress' = 'SNAPPY');

• Importer pour la première fois (montant total)

-- 从ods层进行加载
INSERT overwrite TABLE yp_dwd.fact_goods_evaluation PARTITION(dt)
select 
   id,
   user_id,
   store_id,
   order_id,
   geval_scores,
   geval_scores_speed,
   geval_scores_service,
   geval_isanony,
   create_user,
   create_time,
   update_user,
   update_time,
   is_valid,
   substr(create_time, 1, 10) as dt  
from yp_ods.t_goods_evaluation;

• Opérations d'importation incrémentielles

INSERT into TABLE yp_dwd.fact_goods_evaluation PARTITION(dt)
select 
   id,
   user_id,
   store_id,
   order_id,
   geval_scores,
   geval_scores_speed,
   geval_scores_service,
   geval_isanony,
   create_user,
   create_time,
   update_user,
   update_time,
   is_valid,
   substr(create_time, 1, 10) as dt
from yp_ods.t_goods_evaluation
where dt='2022-11-19';

2.4 Construction de la couche DWD - table des faits de commande - importation de boucles et de fermetures à glissière

La table à fermeture éclair est le point clé de l'entretien.Si vous êtes face à un poste lié à l'entrepôt, l'intervieweur aime particulièrement poser la question.

DROP TABLE if EXISTS yp_dwd.fact_shop_order;
CREATE TABLE if not exists yp_dwd.fact_shop_order(  -- 拉链表
  id string COMMENT '根据一定规则生成的订单编号',
  order_num string COMMENT '订单序号',
  buyer_id string COMMENT '买家的userId',
  store_id string COMMENT '店铺的id',
  order_from string COMMENT '此字段可以转换 1.安卓\; 2.ios\; 3.小程序H5 \; 4.PC',
  order_state int COMMENT '订单状态:1.已下单\; 2.已付款, 3. 已确认 \;4.配送\; 5.已完成\; 6.退款\;7.已取消',
  create_date string COMMENT '下单时间',
  finnshed_time timestamp COMMENT '订单完成时间,当配送员点击确认送达时,进行更新订单完成时间,后期需要根据订单完成时间,进行自动收货以及自动评价',
  is_settlement tinyint COMMENT '是否结算\;0.待结算订单\; 1.已结算订单\;',
  is_delete tinyint COMMENT '订单评价的状态:0.未删除\;  1.已删除\;(默认0)',
  evaluation_state tinyint COMMENT '订单评价的状态:0.未评价\;  1.已评价\;(默认0)',
  way string COMMENT '取货方式:SELF自提\;SHOP店铺负责配送',
  is_stock_up int COMMENT '是否需要备货 0：不需要    1：需要    2:平台确认备货  3:已完成备货 4平台已经将货物送至店铺 ',
  create_user string,
  create_time string,
  update_user string,
  update_time string,
  is_valid tinyint COMMENT '是否有效  0: false\; 1: true\;   订单是否有效的标志',
  end_date string COMMENT '拉链结束日期'
) COMMENT '订单表'
partitioned by (start_date string)
row format delimited fields terminated by '\t'
stored as orc tblproperties ('orc.compress' = 'SNAPPY');

• première importation
• S'il s'agit d'un insert de partition dynamique, n'oubliez pas les paramètres pertinents
• Si le champ de la table dans la couche ods a un type d'énumération, vous pouvez utiliser l'instruction case when pour le convertir dans le processus ETL en dwd.

INSERT overwrite TABLE yp_dwd.fact_shop_order PARTITION (start_date)
SELECT 
   id,
   order_num,
   buyer_id,
   store_id,
   case order_from 
      when 1
      then 'android'
      when 2
      then 'ios'
      when 3
      then 'miniapp'
      when 4
      then 'pcweb'
      else 'other'
      end
      as order_from,
   order_state,
   create_date,
   finnshed_time,
   is_settlement,
   is_delete,
   evaluation_state,
   way,
   is_stock_up,
   create_user,
   create_time,
   update_user,
   update_time,
   is_valid,
   '9999-99-99' end_date,
    dt as start_date
FROM yp_ods.t_shop_order;

• Opération Zip

insert overwrite table yp_dwd.fact_shop_order partition (start_date)
select *
from (
   --1、ods表的新分区数据(有新增和更新的数据)
         select id,
                order_num,
                buyer_id,
                store_id,
                case order_from
                    when 1
                        then 'android'
                    when 2
                        then 'ios'
                    when 3
                        then 'miniapp'
                    when 4
                        then 'pcweb'
                    else 'other'
                    end
                    as order_from,
                order_state,
                create_date,
                finnshed_time,
                is_settlement,
                is_delete,
                evaluation_state,
                way,
                is_stock_up,
                create_user,
                create_time,
                update_user,
                update_time,
                is_valid,
                '9999-99-99' end_date,
               '2022-11-19' as start_date
         from yp_ods.t_shop_order
         where dt='2022-11-19'

         union all

    -- 2、历史拉链表数据，并根据up_id判断更新end_time有效期
         select
             fso.id,
             fso.order_num,
             fso.buyer_id,
             fso.store_id,
             fso.order_from,
             fso.order_state,
             fso.create_date,
             fso.finnshed_time,
             fso.is_settlement,
             fso.is_delete,
             fso.evaluation_state,
             fso.way,
             fso.is_stock_up,
             fso.create_user,
             fso.create_time,
             fso.update_user,
             fso.update_time,
             fso.is_valid,
             --3、更新end_time：如果没有匹配到变更数据，或者当前已经是无效的历史数据，则保留原始end_time过期时间；否则变更end_time时间为前天（昨天之前有效）
             if (tso.id is not null and fso.end_date='9999-99-99',date_add(tso.dt, -1), fso.end_date) end_time,
             fso.start_date
         from yp_dwd.fact_shop_order fso left join (select * from yp_ods.t_shop_order where dt='2022-11-19') tso
         on fso.id=tso.id
     ) his
order by his.id, start_date;

---

2.5 Résumé

Voici une introduction à la construction de la couche DWD du nouveau projet commercial de HIVe, principalement de trois manières :

1. importation de couverture complète
2. importation incrémentielle
3. Boucles et importations de zip

3 Construction de la couche DWS

• Le modèle de construction (ensembles de regroupement) de la couche DWS du nouveau projet de vente au détail de l'entrepôt numérique HIve_Chen Wanjun Allen's Blog-CSDN Blog
• Le modèle de construction (jointure complète) de la couche DWS du nouveau projet de vente au détail de l'entrepôt de données HIVe_Chen Wanjun Allen's Blog-CSDN Blog

3.1 Fonctions et responsabilités de la couche DWS

Couche DWS : basée sur l'analyse statistique des sujets, cette couche est généralement utilisée pour les opérations statistiques les plus fines.

3.1.1 Combinaison de dimensions :

• date

• date+ville

• date + ville + quartier d'affaires

• date + ville + quartier d'affaires + magasin

• date + marque

• date + catégorie

• date+catégorie principale+catégorie moyenne

• date + catégorie principale + colonne du milieu + petite catégorie

3.1.2 Indicateurs :

Chiffre d'affaires, chiffre d'affaires de la plate-forme, chiffre d'affaires des livraisons, chiffre d'affaires des mini-programmes, chiffre d'affaires des applications Android, chiffre d'affaires des applications Apple, chiffre d'affaires du centre commercial PC, volume des commandes, volume de participation, volume des avis négatifs, volume des livraisons et volume des remboursements, commandes des mini-programmes, commandes des applications Android , Commandes Apple APP et Commandes PC Mall.

3.2 Tableau large des statistiques sur le thème des ventes

Enfin, il est nécessaire d'utiliser group_type pour déterminer l'agrégation de quelle dimension provient l'indicateur

3.3 Résumé

(Grouping sets), le modèle Grouping sets convient à la construction de tableaux larges clairsemés multidimensionnels et multi-indicateurs, et différentes dimensions peuvent être placées dans le même tableau large pour faciliter les requêtes futures. Dans le même temps, lors de la création d'un champ d'agrégation, vous pouvez personnaliser l'opération d'agrégation en fonction de chaque dimension. Plus flexible.

Modèle (Jointure complète), principalement pour les situations de faible dimension et multi-index. L'idée principale du modèle de jointure complète est

1. Utilisez l'instruction with pour extraire les champs clés de la table dwb_order_detail
2. Comptez d'abord les données de 6 petits tableaux de résultats
3. Joindre complètement les données des 6 petits tableaux de résultats
4. Extraire les données de la table de résultats de la jointure complète
5. Déduplication, supprimer les données en double de date et de marchandises_id