1 データウェアハウスの階層化とモデリング理論

1.1 データウェアハウスの目的

社内のあらゆるビジネスデータを統合し、統合データセンターを構築
意思決定のためのビジネスレポートを作成する
Webサイト運用における運用データのサポートを提供します
各業務のデータソースとして活用でき、業務データを相互にフィードバックする好循環を形成
データマイニングによるユーザー行動データの分析、入力コストの削減と入力効果の向上
会社に直接的または間接的に利益をもたらすデータ製品を開発する

1.2 データウェアハウスの運用アーキテクチャ図

1.3 データマートとデータウェアハウスの違い

データマート (データマーケット): これは小型のデータウェアハウスであり、通常はデータ、対象領域、履歴データが少ないため、部門レベルであり、通常は管理サービスの特定の範囲のみを対象としています。

データウェアハウス (データウェアハウス): データウェアハウスはエンタープライズレベルであり、企業全体のさまざまな部門の運用に意思決定支援手段を提供できます。

1.4 データウェアハウスの階層

1.4.1 階層化の理由

複雑な問題を単純化する: 複雑なタスクを複数のレイヤーに分解して完了します。各レイヤーは単純なタスクのみを処理するため、問題を特定するのに便利です。
繰り返しの開発を削減: データの階層化を標準化し、中間層のデータを使用することで、大量の繰り返し計算を削減し、計算結果の再利用性を高めます。
生データを分離する: データの異常であっても、データの機密性であっても、実際のデータを統計データから分離します。

1.4.2 基本的な階層モデル

ODS (データソースレイヤー、生データ) – ETL --> DWD (データ詳細レイヤー) – hive SQL --> DWS (データサマリー) – sqoop --> ADS (データアプリケーション: レポート、ユーザーポートレート)

1.5 データウェアハウスの階層

1.5.1 データウェアハウス階層の概要

アリババのデータシステムでは、データウェアハウスを下から上の 3 つの層に分割することが推奨されています。

データ導入層 ODS (オペレーションデータストア): 未処理の生データをデータウェアハウスシステムに保存します。データウェアハウスシステムは、構造的にソースシステムと一致しており、データウェアハウスのデータ準備領域です。主に基本データを MaxCompute にインポートする作業を実行し、基本データの履歴変更を記録します。

データパブリックレイヤー CDM (Common Data Model、共通データモデルレイヤーとも呼ばれます): ODS レイヤーデータから処理された DIM ディメンションテーブル、DWD、DWS を含みます。主に、完全なデータ処理と統合、一貫したディメンションの確立、分析と統計用の再利用可能な詳細なファクトテーブルの構築、公開粒度指標の要約を行います。現在のビジネス特性に従って、DWD レイヤーのみが一時的に確立されます

詳細粒度のファクトレイヤー (DWD): ビジネスプロセスをモデリングドライバーとして使用し、特定の各ビジネスプロセスの特性に基づいて、最も粒度の細かい詳細レベルのファクトテーブルを構築します。詳細ファクトテーブルの一部の重要なディメンション属性フィールドは、企業のデータ使用特性 (つまり、ワイドテーブル処理) と組み合わせて、適切に冗長にすることができます。
データ中間層: DWM (Data Ware House Middle) この層は、DWD 層のデータに基づいてデータに対して軽い集計操作を実行し、一連の中間テーブルを生成し、パブリックインジケーターの再利用性を向上させ、繰り返し処理を削減します。直感的に言えば、共通のコアディメンションを集計し、対応する統計指標を計算することです。
パブリックサマリー粒度ファクトレイヤー (DWS): 分析の対象オブジェクトをモデリングドライバーとして使用し、上位レベルのアプリケーションおよび製品インジケーターの要件に基づいて、パブリックサマリー粒度ファクトテーブルを構築し、広範な手段によってモデルを物理化します。テーブル。命名規則と一貫した基準を備えた統計指標を構築し、上位層に公開指標を提供し、概要全体のテーブルと詳細なファクトテーブルを確立します。
Common Dimension Layer (DIM): ディメンションモデリングの概念に基づいて、企業全体の一貫したディメンションを確立します。データ計算の能力とアルゴリズムに一貫性がないリスクを軽減します。共通ディメンション層のテーブルは通常、論理ディメンションテーブルとも呼ばれ、ディメンションとディメンション論理テーブルは通常、1対1に対応します。
データアプリケーション層 ADS (Application Data Service): データ製品のパーソナライズされた統計インデックスデータを保存します。CDM および ODS 層の処理に従って生成されます。

中国語と英語と略語:

データ導入層（ODS、オペレーションデータストア）

データパブリック層（CDM、共通データモデル）

共通ディメンションレイヤー (DIM、ディメンション)

データウェアハウスの詳細 (DWD、データウェアハウスの詳細)

データサマリーレイヤー (DWS、データウェアハウスサービス)

データアプリケーション層 (ADS、アプリケーションデータサービス)

1.5.2 各レベルの用途

**1) データ導入層（ODS、オペレーションデータストア）：**元のデータはほとんど加工されずにデータウェアハウスシステムに保存され、基本的にはソースシステムと構造が一致しており、データウェアハウスシステムのデータ準備領域となります。データウェアハウス。生データ、主に埋め込まれたポイントデータ (ログデータ) とビジネスオペレーションデータ (binlong)、データソースは主に Mysql、HDFS、Kafka などです。

2) データパブリックレイヤー (CDM、Common Data Model、共通データモデルレイヤーとも呼ばれます)。ODSレイヤーデータから処理された DIM ディメンションテーブル、DWD、DWS を含みます。主に、データの処理と統合を完了し、一貫したディメンションを確立し、分析と統計用に再利用可能な詳細なファクトテーブルを構築し、公開粒度の指標を要約します。この層には次の 3 つの層が含まれます。

共通ディメンションレイヤー (DIM):

ディメンションモデリングの概念に基づいて、企業全体の一貫したディメンションを確立します。データ計算の能力とアルゴリズムに一貫性がないリスクを軽減します。共通ディメンション層のテーブルは通常、論理ディメンションテーブルとも呼ばれ、ディメンションとディメンション論理テーブルは通常、1対1に対応します。
主に MySQL、Hbase、Redis の 3 つのストレージエンジンを使用します。MySQL は、ディメンションテーブルのデータが比較的小さい場合に使用できます。単一のデータサイズが比較的小さく、クエリの QPS が比較的高い場合は、Redis ストレージを使用できます。データ量が比較的多く、ディメンションテーブルデータの変更の影響を特に受けないシナリオでは、HBase ストレージを使用できます。

データウェアハウス詳細レイヤー (DWD) :

ODS レイヤーはクリーニングされ、このレイヤー上に配置されます。これは一般に最も粒度が細かいものです。
ビジネスプロセスをモデリングドライバーとして使用し、** 特定の各ビジネスプロセスの特性に基づいて、最も詳細な詳細レベルのファクトテーブルを構築します。**企業のデータ使用特性と組み合わせると、詳細ファクトテーブルの一部の重要なディメンション属性フィールドを適切に冗長にすることができます (つまり、ワイドテーブル処理)。

データ要約層 (DWS):

DWD レイヤーのわずかな集約と、再利用性を高めるためのいくつかの累積インジケーターの集約。
分析対象オブジェクトをモデリングドライバーとして、上位レベルのアプリケーションおよび製品インデックスの要件に基づいて、公開粒度のサマリーインデックスファクトテーブルを構築し、ワイドテーブルを使用してモデルを物理化します。命名規則と一貫した基準を備えた統計指標を構築し、上位層に公開指標を提供し、概要全体のテーブルと詳細なファクトテーブルを確立します。パブリックサマリー粒度ファクトレイヤーのテーブルは通常、サマリー論理テーブルとも呼ばれ、派生指標データを保存するために使用されます。

3) データアプリケーション層 (ADS、Application Data Service) : データ製品のパーソナライズされた統計インデックスデータを保存します。CDM および ODS 層の処理に従って生成されます。

1.6 開発仕様

1.6.1 命名規則

1) オッズレイヤー

增量数据： {
    
    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) 薄暗いレイヤー

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

3) 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) 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) 広告レイヤー

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

1.7 レイヤリングの誤解

データウェアハウス層の内部分割は階層化のためのものではなく、ETL タスクとワークフローの編成、データの流れ、読み取りおよび書き込み権限の制御、さまざまなニーズの満足など、さまざまな問題を解決するために階層化が行われます。

業界では、データウェアハウスレイヤー (DW) 全体を dwd、dwb、dws、dim、mid、その他多くのレイヤーに分割するのがより一般的です。ただし、これらのレイヤー間の明確な境界が何であるかは依然としてわかりません。または、レイヤー間の境界を明確に説明することはできますが、複雑なビジネスシナリオにより実際に実装することができません。

したがって、データ階層化の 3 つの層である ODS、DWD、DWS が一般に最も基本的なものになります。

DW レイヤーを分割する方法については、特定のビジネスニーズと企業シナリオに応じて定義されます。一般的に、次のものが必要です。

階層化の目的は、データフローを解決し、ビジネスを迅速にサポートすることです。
対象領域や事業領域に応じて浸透させなければならない。
層間に逆の依存関係はありません。
ODS レイヤーのデータに依存してデータサポートを完了できる場合、ビジネス側はランディングレイヤーを直接使用します。これは、一部のデータの迅速かつ低コストの探索と実験にも役立ちます。
階層化された仕様を決定したら、将来的にはこの構造に従うのが最善であり、合意することができます。
血族関係、データ依存関係、データ辞書、データ命名規則などが最初にサポートされます。

DW でのレイヤリングは最も正しいというわけではなく、あなたにとって最も適しているだけです。

1.8 ワイドテーブルに関する誤解

ワイドテーブルはデータウェアハウス層で導入されます。いわゆるワイドテーブルですが、今のところ明確な定義はありません。一般的には、多くのディメンション、ファクトロールアップ、またはドリルダウンを特定のファクトテーブルに関連付けて、多数のディメンションと関連ファクトの両方を含むテーブルを形成します。

広いテーブルを使用すると便利です。ユーザーはディメンションテーブルとの関連性を考慮する必要はなく、ディメンションテーブルとファクトテーブルが何であるかを理解する必要もありません。
ただし、ビジネスが成長するにつれて、ワイドテーブルで冗長なディメンションの数を予測どおりに設計および定義することはできません。また、ワイドテーブルでの冗長ディメンションの最終ラインがどこにあるのかを明確に定義することもできません。

考えられる状況としては、使用要件を満たすために、ディメンションテーブル内の既存の列をワイドテーブルに継続的に追加する必要があるということです。これは、ワイドテーブルのテーブル構造の頻繁な変更に直接つながります。

私たちが現在行っていることは次のとおりです。

対象ドメインとビジネスドメインに従って、特定のビジネスのすべてのノードを分類します。
キーノードのデータをファクトテーブルの基礎として使用し、他のファクトテーブルのロールアップデータ (一部の統計指標を含む) を水平方向に拡張し、同時にノード上のいくつかの主キーに対応するディメンションを追加します。垂直方向。
ワイドテーブルの関与は、特定のビジネス要件に依存せず、ビジネスライン全体と一致します。
幅の広いテーブルの代わりにディメンションモデリングを使用するようにしてください。

可能な限りワイドテーブルではなくディメンションモデリングを使用するのはなぜですか? フィールドとデータが冗長である場合でも、ディメンションモデリングの方法ではデータの全量も表現されます。ワイドテーブルモードの方が優れています。理由:

ディメンションモデリングは、特定の確立された事実に基づいており、ファクトテーブルであるため、この部分のビジネスが変わらない限り、ファクトテーブルの粒度は基本的に変わりません。
ファクトテーブルとディメンションテーブルは分離されており、ディメンションテーブルの変更は基本的にファクトテーブルには影響せず、結果テーブルはデータフローを更新するだけで済みます。
新しいディメンションは、スタースキーマまたはスノーフレークスキーマに従って動的に追加できます。
ディメンションモデルはワイドテーブルのベースとして使用でき、データフロー全体が決定されると、対応するワイドテーブルをディメンションモデルを通じて再生成して、ビジネスを迅速にサポートできます。

2次元テーブルとファクトテーブル

Hive_dimension テーブルとファクトテーブル

2.1 寸法表

寸法表: 一般的に事実を説明します。各ディメンションテーブルは、現実世界のオブジェクトまたは概念に対応します。例: ユーザー、製品、日付、地域など。

寸法表の特徴:

ディメンションテーブルは範囲が広い (複数の属性、列の比較を含む)
ファクトテーブルと比較すると、行数は比較的少なく、通常は 100,000 未満です。
内容は比較的固定されています: コード表

時間ディメンションテーブル:

日付ID	曜日	一年のうちの日	四半期	休日
2020-01-01	2	1	1	新年
2020-01-02	3	2	1	なし
2020-01-03	4	3	1	なし
2020-01-04	5	4	1	なし
2020-01-05	6	5	1	なし

2.2 ファクトテーブル

ファクトテーブル:すべてのデータウェアハウスには 1 つ以上のファクトテーブルが含まれます。ファクトテーブルには、レジのトランザクションによって生成されたデータなどの企業売上データが含まれる場合があり、通常、ファクトテーブルには多数の行が含まれます。ファクトテーブルの主な特徴は、数値データ (ファクト) が含まれていることです。この数値情報を集計して、ユニットに関するデータを履歴として提供できます。各ファクトテーブルには、キーの関連性を含むマルチパートインデックスが含まれています。ディメンションテーブルは主キーですが、ディメンションテーブルにはファクトレコードの属性が含まれます。ファクトテーブルには、説明的な情報を含めることはできません。また、ファクトをディメンションテーブル内の項目に対応させる数値メジャーフィールドおよび関連インデックスフィールド以外のデータを含めることはできません。

ファクトテーブルに含まれる「メジャー」には 2 種類あります。1 つはロールアップできるメジャー、もう 1 つはロールアップできないメジャーです。最も有用なメジャーはロールアップできるものであり、合計された数値は非常に意味があります。ユーザーは、メトリクスを蓄積することで集約された情報を取得できます。特定の期間における店舗グループの特定の商品の売上を要約できます。非累積測定はファクトテーブルでも使用できます。集計結果は一般に意味がありません。たとえば、建物内の異なる場所で温度を測定する場合、建物内のすべての異なる場所の温度を合計することは意味がありませんが、平均化により、検出。

一般に、ファクトデータテーブルは 1 つ以上の緯度テーブルに関連付けられており、ユーザーはファクトデータテーブルを使用してキューブを作成するときに1 つ以上のディメンションテーブルを使用できます。

ファクトテーブルのデータの各行は、ビジネスイベント (注文、支払い、返金、レビューなど) を表します。「事実」という用語は、ビジネスイベントの測定値（数えられる回数、数、金額など）を指します。たとえば、2020年5月21日、宋松氏は250元で海犬人参の瓶を購入しました。 JD.comの錠剤。ディメンションテーブル: 時間、ユーザー、製品、販売者。ファクトシート: 250 元、ボトル

各ファクトテーブルの行には、加算的な数値メジャー値、ディメンションテーブルに接続された外部キー (通常は 2 つ以上の外部キー) が含まれます。

ファクトテーブルの特徴:

とても大きい
コンテンツは比較的狭い: 列の数は少ない (主に外部キー ID とメジャー値)
頻繁に変更され、毎日多くの新しい機能が追加されます。

1) トランザクションファクトテーブル

各トランザクションまたはイベント (販売注文レコード、支払いレコードなど) をファクトテーブル内のデータ行として取得します。トランザクションがコミットされ、ファクトテーブルデータが挿入されると、データは変更されなくなり、更新方法は増分更新になります。

2) 定期スナップショットファクトテーブル

定期スナップショットファクトテーブルにはすべてのデータが保持されるのではなく、日次または月次の売上高や月次の口座残高など、一定の時間間隔のデータのみが保持されます。

たとえば、製品の追加や減算を伴うショッピングカートはいつでも変更される可能性がありますが、私たちは、毎日の終わりに製品がいくつあるかをより重視します。これは、後の統計分析に便利です。

3) 累積スナップショットファクトテーブル

累積スナップショットファクトテーブルは、ビジネスファクトへの変更を追跡するために使用されます。たとえば、データウェアハウスは、注文の発注時から、注文が梱包、出荷、署名されるまでの各ビジネスステージの時点データを蓄積または保存して、注文を追跡する必要がある場合があります。注文宣言サイクルの進捗状況。このビジネスプロセスの進行中、ファクトテーブル内のレコードも常に更新されます。

注文ID	ユーザーID	注文時間	梱包時間	納期	提出時間	注文金額
		3-8	3-8	3-9	3-10

3 データウェアハウスモデリングの計画

3.1 ODS層

HDFS 上でユーザー行動データとビジネスデータをどのように計画し、処理するのでしょうか?

(1) データをそのままの姿で残し、データをバックアップする役割を果たします。

(2) ディスクのストレージ容量を減らすためにデータが圧縮されます (例: 元のデータは 100G ですが、約 10G まで圧縮できます)

(3) パーティションテーブルを作成して、後続のフルテーブルスキャンを防止します。

3.2 DIM層とDWD層

DIM 層と DWD 層は次元モデルを構築する必要があり、通常はスターモデルが採用され、提示されるステータスは通常はコンスタレーションモデルになります。

次元モデリングは通常、次の 4 つの手順に従います。

ビジネスプロセス→宣言粒度→ディメンションの確認→ファクトの確認を選択します。

(1) ビジネスプロセスの選択

ビジネスシステムで、注文ビジネス、支払いビジネス、返金ビジネス、物流ビジネスなど、関心のあるビジネスラインを選択します。ビジネスラインはファクトテーブルに対応します。

(2) ステートメントの粒度

データの粒度は、データウェアハウスに保存されているデータの精製度または包括性のレベルを指します。

粒度の宣言とは、ファクトテーブルのデータ行が何を表すかを正確に定義することを意味し、さまざまなニーズを満たすために、可能な限り最小の粒度を選択する必要があります。

一般的な粒度の宣言は次のようになります。

注文ファクトテーブル内のデータの行は、注文内の商品アイテムを表します。

支払いファクトテーブルのデータ行は支払いレコードを表します。

(3) 寸法の決定

ディメンションの主な役割はビジネス上の事実を記述することであり、主に「誰が、どこで、いつ」などの情報を表現します。

ディメンションを決定するための原則は、後続の要件で関連するディメンションの指標を分析するかどうかです。たとえば、最も多くの注文がいつ行われたのか、どの地域で最も多くの注文が行われたのか、どのユーザーが最も多くの注文を行ったのかなどの統計を作成する必要があります。決定する必要がある次元には、時間次元、地域次元、およびユーザー次元が含まれます。

(4) 事実の認定

ここでいう「事実」とは、受注金額や受注件数など、ビジネスにおける計測値（時間、個数、個数、金額など）を指します。

DWD レイヤーでは、ビジネスプロセスがモデリングドライブとして使用され、特定の各ビジネスプロセスの特性に基づいて、詳細レイヤーの最も詳細なファクトテーブルが構築されます。ファクトテーブルは適切に拡張できます。

ファクトテーブルとディメンションテーブル間の関連付けは比較的柔軟ですが、より複雑なビジネス要件を満たすために、関連付けられるテーブルを可能な限り関連付けることができます。

	時間	ユーザー	エリア	商品	クーポン	アクティビティ	メトリック
注文	√	√	√				送料/オファー金額/元の金額/最終金額
注文詳細	√	√	√	√	√	√	個数/プレミアム金額/当初金額/最終金額
支払う	√	√	√				支払金額
購入を追加する	√	√		√			個数・金額
収集	√	√		√			周波数
評価	√	√		√			周波数
チャージバック	√	√	√	√			個数・金額
返金	√	√	√	√			個数・金額
クーポンの収集	√	√			√		周波数

これまでのところ、データウェアハウスの次元モデリングは完了しており、DWD レイヤーはビジネスプロセスによって駆動されます。

DWS レイヤー、DWT レイヤー、および ADS レイヤーはすべて需要主導型であり、ディメンションモデリングとは何の関係もありません。

DWS と DWT はどちらも広いテーブルを構築し、テーマに応じてテーブルを構築します。テーマは問題の観察の角度に相当します。寸法表に対応します。

3.3 DWS層とDWT層

DWS 層と DWT 層は総称して広表面層と呼ばれますが、両層の設計思想はほぼ同じであり、以下の例で説明します。

1) 問題が抽出されます: 2 つの要件、各州の注文数を数える、各州の注文総量を数える

2) 処理方法: 州テーブルと順序テーブルを結合し、州ごとにグループ化して計算します。同じデータが 2 回計算されるため、実際にはさらに類似したシナリオが存在します。

では、どうすれば二重カウントを回避できる設計になるのでしょうか?

上記のシナリオでは、主キーが地域 ID であり、フィールドには注文時間、注文金額、支払時間、支払金額などが含まれる地域全体のテーブルを設計できます。上記の指標はすべて均一に計算され、結果は広いテーブルに保存されるため、データの二重計算を効果的に回避できます。

3) 概要:

(1) どの幅のテーブルを構築する必要があるか: ディメンションに基づいて。

(2) 広いテーブル内のフィールド: ファクトテーブルの集計された測定値に焦点を当て、さまざまな次元の観点からファクトテーブルを観察します。

(3) DWS 層と DWT 層の違い: DWS 層は、その日の各地域での注文数、注文金額など、その日のすべての対象オブジェクトの概要の動作を保存します。 DWT レイヤーには、過去 7 日間 (15 日、30 日、60 日) の各リージョンでの注文数や注文量など、すべての対象オブジェクトの累積動作が保存されます。

3.4 ADS層

電子商取引システムの主要なテーマ別指標を個別に分析します。

4 ハイブデータウェアハウスの戦闘

ここに画像の説明を挿入

1 ODS層の構築

1.1 ODS層の機能と責任

1) データをそのままの形で保存し、データをバックアップする役割を果たします。

2) データは LZO によって圧縮され、ディスクのストレージ容量が削減されます。100Gのデータを10G以内に圧縮できます。

3) パーティションテーブルを作成して、後続のフルテーブルスキャンを防止し、エンタープライズ開発でパーティションテーブルを広範囲に使用します。

4) 外部テーブルを作成します。エンタープライズ開発では、自分用の一時テーブルの作成や内部テーブルの作成に加えて、ほとんどのシナリオで外部テーブルを作成します。

1.2 ODS レイヤーの構築 - データのインポート - フルカバレッジ

パーティションは必要なく、各同期では最初に削除してから書き込み、直接上書きします。

データに新たな追加や変更がない場合に適用されます。

たとえば、地域辞書テーブル、時刻、性別などのディメンションデータは変更されないか、ほとんど変更されず、最新の値のみを保持できます。

ここでは、t_district エリア辞書テーブルを例に説明します。

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');

スクープデータの同期

テーブルは ORC 形式で保存されるため、sqoop を使用してデータをインポートする場合は HCatalog API が必要です。

-- 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 ODS レイヤーの構築 – データのインポート – 増分同期

毎日新しい日付パーティションが追加され、その日の新しいデータが同期されて保存されます。

例えば、ログインログテーブル、アクセスログテーブル、取引記録テーブル、商品評価テーブル、注文評価テーブルなどです。

ここでは、t_user_login ログインログテーブルを例として説明します。

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');

スクープデータの同期

初回（全額）

1. モードに関係なく、初回は完全同期であり、サイクルが再度同期されるときは、where 条件を通じて同期データの範囲を自分で制御できます。

2. ${TD_DATE} はパーティション日付を表します。通常は今日の前日である必要があります。通常の状況では、現在は夜の 12 時で、前日の作業が完了しているため、パーティションフィールドはデータは前日のものである必要があります。

3. デモンストレーションの目的で、${TD_DATE} が最初にハードコーディングされます。

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

ループ (増分同期)

#!/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 ODS レイヤーの構築 - データのインポート - 新規および更新された同期

新しい日付パーティションが毎日追加され、その日の新規および更新されたデータが同期されて保存されます。

ユーザーテーブル、注文テーブル、製品テーブルなどの新規データと更新データの両方に適用されます。

ここでは、t_store ショップテーブルを例として説明します。

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');

スクープデータの同期

新規および更新された同期を実現するための鍵は、テーブルに 2 つの時間関連フィールドがあることです。

create_time 作成時刻は生成されると変更されません。

update_time 更新時刻データ変更時刻修正

where 条件を通じて、同期データの範囲を自分で制御します。

初め

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

サイクル

#!/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

最後に、すべての ODS レイヤーテーブルが MySql からインポートされました

ここに画像の説明を挿入

1.5 概要

ここでは、HIve データウェアハウスニューリテールプロジェクトの ODS レイヤーの構築を、主に 3 つの方法で紹介します。

フルカバー
増分同期
新しい追加と更新の同期

2 DWD層の構築

2.1 DWD 層の機能と責任

ods レイヤーテーブル内のデータをクリーンアップし、データクリーニングルールを参照して、実際の状況に従ってデータをクリーンアップします。

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

dwd 層は中国語で詳細データ層と呼ばれます。
主な機能:
- データのクリーニングと変換、品質保証の提供。
- 事実と次元を区別してください。
テーブル名の指定

dwd.fact_xxxxxx

注文メインテーブル、注文決済、注文グループ、注文返金、注文商品スナップショット、ショッピングカート、ストアコレクションなど。

dwd.dim_yyyyyy

ユーザー、エリア、時間、店舗、商圏、住所情報、商品、商品カテゴリ、ブランドなど。

2.2 DWD レイヤーの構築 - 地域ディメンションテーブル - フルカバレッジのインポート

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');

フルカバレッジオペレーション

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 DWD レイヤーの構築 - 注文評価フォーム - 増分インポート

#解释：每一次增量的数据都创建一个分区进行报错
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');

初めて輸入する（全額）

-- 从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;

増分インポート操作

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 DWD レイヤーの構築 - 注文ファクトテーブル - ループとジッパーのインポート

ジッパーテーブルは面接のキーポイントで、倉庫関係の職種の場合、面接官が特に好む質問です。

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');

ここに画像の説明を挿入

最初のインポート
動的パーティション挿入の場合は、関連するパラメータを忘れないでください。
ods レイヤーのテーブルのフィールドが列挙型である場合、case when ステートメントを使用して、ETL のプロセスでそれを 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;

ここに画像の説明を挿入

ジップ操作

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 概要

ここでは、HIve の新しい小売プロジェクトの DWD レイヤーの構築を主に 3 つの方法で紹介します。

フルカバレッジのインポート
増分インポート
ループと zip インポート

3 DWS層の構築

3.1 DWS 層の機能と責任

DWS レイヤー: トピック統計分析に基づいて、このレイヤーは通常、最も詳細な統計操作に使用されます。

3.1.1 寸法の組み合わせ:

日にち
日付+都市
日付 + 都市 + ビジネス地区
日付 + 都市 + ビジネス地区 + 店舗
日付 + ブランド
日付 + カテゴリー
日付+大分類+中分類
日付 + 大カテゴリ + 中列 + 小カテゴリ

3.1.2 指標:

売上収益、プラットフォーム収益、配信売上高、ミニプログラム売上高、Android APP売上高、Apple APP売上高、PCモール売上高、注文量、参加量、ネガティブレビュー量、配信量、返金量、ミニプログラム注文数、Android APP注文数、Apple APP の注文、および PC モールの注文。

3.2 販売テーマ統計の広範な表

最後に、group_type を使用して、インジケーターがどのディメンションからの集計であるかを決定する必要があります。
ここに画像の説明を挿入

3.3 概要

(グループ化セット) モデル。グループ化セットモデルは、多次元のマルチインジケーターの疎な幅のテーブルの構築に適しており、将来のクエリを容易にするために、異なるディメンションを同じ幅のテーブルに配置できます。同時に、集計フィールドを作成するときに、各ディメンションに応じて集計操作をカスタマイズできます。より柔軟に。

(完全結合) モデル。主に低次元のマルチインデックス状況に適しています。完全結合モデルの主なアイデアは次のとおりです。

with ステートメントを使用して、dwb_order_detail テーブルのキーフィールドを抽出します。
まず 6 つの小さな結果テーブルのデータをカウントします。
6 つの小さな結果テーブルのデータを完全に結合します。
完全結合の結果テーブルからデータを抽出する
重複排除、日付と商品IDの重複データを削除します

Hiveデータウェアハウス構築マニュアル

1 データウェアハウスの階層化とモデリング理論

1.1 データウェアハウスの目的

1.2 データ ウェアハウスの運用アーキテクチャ図

1.3 データマートとデータウェアハウスの違い

1.4 データウェアハウスの階層

1.4.1 階層化の理由

1.4.2 基本的な階層モデル

1.5 データウェアハウスの階層

1.5.1 データ ウェアハウス階層の概要

1.5.2 各レベルの用途

1.6 開発仕様

1.6.1 命名規則

1.7 レイヤリングの誤解

1.8 ワイドテーブルに関する誤解

2次元テーブルとファクトテーブル

2.1 寸法表

2.2 ファクトテーブル

3 データ ウェアハウス モデリングの計画

3.1 ODS層

3.2 DIM層とDWD層

3.3 DWS層とDWT層

3.4 ADS層

4 ハイブ データ ウェアハウスの戦闘

1 ODS層の構築

1.1 ODS層の機能と責任

1.2 ODS レイヤーの構築 - データのインポート - フルカバレッジ

1.3 ODS レイヤーの構築 – データのインポート – 増分同期

1.4 ODS レイヤーの構築 - データのインポート - 新規および更新された同期

1.5 概要

2 DWD層の構築

2.1 DWD 層の機能と責任

2.2 DWD レイヤーの構築 - 地域ディメンション テーブル - フルカバレッジのインポート

2.3 DWD レイヤーの構築 - 注文評価フォーム - 増分インポート

2.4 DWD レイヤーの構築 - 注文ファクト テーブル - ループとジッパーのインポート

2.5 概要

3 DWS層の構築

3.1 DWS 層の機能と責任

3.1.1 寸法の組み合わせ:

3.1.2 指標:

3.2 販売テーマ統計の広範な表

3.3 概要

おすすめ

1.2 データウェアハウスの運用アーキテクチャ図

1.5.1 データウェアハウス階層の概要

3 データウェアハウスモデリングの計画

4 ハイブデータウェアハウスの戦闘

2.2 DWD レイヤーの構築 - 地域ディメンションテーブル - フルカバレッジのインポート

2.4 DWD レイヤーの構築 - 注文ファクトテーブル - ループとジッパーのインポート