この記事は参照用であり、https： //blog.csdn.net/a1786742005/article/details/105833521から転送されます。
1.プロジェクトの全体的な構造
2.データの説明
2.1ユーザー行動データ
1.開始ログデータ
は単一のjsonデータです
2.イベントログデータ
構成：タイムスタンプ、共通フィールド、イベントログ
イベント：
（1）製品リスト
（2）製品クリック
（3）製品の詳細
（4）広告
（5）メッセージ通知
（6）アクティブなユーザーの背景
（7）コメント
（8）お気に入り
（9）いいね
（10）エラーログ
2.2ビジネスデータ
1.注文表
2、注文詳細表
3、sku製品表
4、ユーザー表
5、製品レベル1分類表
6、製品レベル2分類表
7、製品3レベル分類表
8、支払いフロー表
9、州表
10地域表
11、ブランド表
12、注文状況表
13、spu製品表
14、製品レビュー表
15、返品フォーム
16、追加購入表
17、製品収集表
18、クーポン受領表
19、クーポン表
20、活動表
21活動順序関連表
22、優先ルール表
23、コーディング辞書表
24、活動参加製品表
25、スケジュール
26、休日表
27、休日時系列
3、データインポートhdfs
3.1ユーザー行動データ
1.ユーザー行動データの生成
2.ログ収集水路構成
（1）ソースはTaildirSourceです。
（2）チャネルはKafkaチャネルであるため、シンクは省略されています。
（3）カスタム水路迎撃機。
カスタマイズされた2つのインターセプター、つまり、ETLインターセプターとログタイプを区別するインターセプター。
ETLインターセプター：不正なタイムスタンプと不完全なJsonデータを使用してログをフィルター処理します。
ログタイプ区別インターセプター：起動ログとイベントログを分離します。これは、Kafkaのさまざまなトピックに送信するのに便利です。
3.ログ消費Flume構成
（1）ソースはkafkaSourceです。
（2）チャネルはfileChannelです。
（3）シンクはhdfsの2つのパスであり、lzoで圧縮されています。
3.2ビジネスデータ
1.プロセス
sqoopはmysqlテーブルをhdfsにインポートし、lzoを使用して圧縮します。
2.データ同期戦略
（1）
データ同期戦略の概要データ同期戦略のタイプには、フルスケール、インクリメンタルテーブル、新規および変更されたテーブルが含まれます。
フルスケール：完全なデータを保存します。
インクリメンタルテーブル：新しく追加されたデータを格納します。
新規および変更されたテーブル：新しく追加されたデータと変更されたデータを格納します。
（2）フルボリューム同期戦略
毎日のフルボリュームとは、完全なデータがパーティションとして毎日保存されることを意味します。
テーブルデータの量が多くなく、毎日新しいデータが挿入され、古いデータも変更されるシナリオに適しています。
例：コーディング辞書テーブル、ブランドテーブル、製品3レベル分類、製品2レベル分類、製品1レベル分類、割引ルールテーブル、アクティビティテーブル、イベント参加製品テーブル、追加購入テーブル、製品コレクションテーブル、クーポンテーブル、sku商品表、spu商品表。
（3）増分同期戦略
毎日の増分とは、毎日1つの増分データをパーティションとして格納することを意味します。
テーブルデータの量が多く、毎日新しいデータのみが挿入されるシナリオに適しています。例：返品フォーム、注文ステータステーブル、注文詳細テーブル、アクティビティと注文の関連付けテーブル、製品レビューテーブル。
（4）新しい追加と変更の戦略
毎日の追加と変更は、ストレージの作成時間または運用時間が今日のデータであることを意味します。
適用可能なシナリオは次のとおりです。テーブル内のデータ量が多く、新しい追加と変更があります。
例：ユーザーテーブル、注文テーブル、クーポン要求テーブル。
（5）特別な戦略
一部の特別なディメンションテーブルは、上記の同期戦略に従う必要はありません。
A.
客観的世界の次元変化していない客観的世界の次元（性別、地域、民族、政治的構成、靴のサイズなど）は、固定値のみを持つことができます。
B.日付ディメンション
日付ディメンションは、1年または数年のデータを一度にインポートできます。
C.地域ディメンション：
州テーブル、地域テーブル
3.アイコン
第四に、データウェアハウスの基本的な知識
4.1なぜ倉庫をレイヤーごとに数える必要があるのですか？
1.複雑な問題を単純化します
。複雑なタスクを複数のレイヤーに分解して完了します。各レイヤーは、問題の特定を容易にするために単純なタスクのみを処理します。
2.繰り返しの開発を減らします。
データの階層化を標準化します。中間層のデータを通じて、繰り返しの計算を大幅に減らし、計算結果の再利用性を高めることができます。
3.元のデータを分離する
データの異常であろうとデータの機密性であろうと、実際のデータを統計データから切り離します。
4.2グラフィカルな階層構造
4.3データウェアハウスの命名規則
1.テーブル名
odsレイヤーの名前はods_テーブル名
dwdレイヤーの名前はdwd_dim / fact_テーブル名
dwsレイヤーの名前はdws_テーブル名
dwtレイヤーの名前はdwt_テーブル名
adsレイヤーの名前はads_テーブル名
一時テーブルの名前はxxx_tmp
ユーザー動作テーブル、接尾辞としてログを使用
2.スクリプトの命名
データsource_to_target_db / log.sh
ユーザー動作スクリプトは、接尾辞としてlogを使用し、ビジネスデータスクリプトは、接尾辞としてdbを使用します。
4.4次元モデリング
次元モデリングに基づいて、スターモデル、スノーフレークモデル、およびコンステレーションモデルの3つのモデルがあります。
1.スターモデル
2.スノーフレークモデル
3.星座モデル
4.モデルの選択
4.5ディメンションテーブルとファクトテーブル
1.ディメンションテーブル
（1）ディメンションテーブルの概要
一般的には、事実の説明情報です。各ディメンションテーブルは、実世界のオブジェクトまたは概念に対応しています。例：ユーザー、製品、日付、地域など。
（2）
ディメンションAの特性、ディメンションの範囲が非常に広い（複数の属性、より多くの列がある）
B、ファクトテーブルと比較して、行数が比較的少なく、通常は<100,000
C、内容は比較的固定：コーディングテーブル
2.ファクトテーブル
（1）ファクトテーブルの概要ファクトテーブル
のデータの各行は、ビジネスイベント（注文、支払い、返金、評価など）を表します。「ファクト」という用語は、ビジネスイベントの測定値（カウント、カウント、アイテムの数、金額など）、たとえば、注文イベントの注文金額を指す。
（2）ファクトテーブルには
、加法性数値メジャー、ディメンションに接続された外部キー（通常は2つ以上の外部キー）、および外部キー間の表現を含む各ファクトテーブルの行が含まれます。ディメンションテーブル間の多対多の関係。
（3）ファクトテーブルの機能
A、非常に大きい
B、比較的狭いコンテンツ、少数の列
C、頻繁な変更、および毎日の多くの新しい追加
3.ファクトテーブルの分類
（1）トランザクションファクトテーブル
は、各トランザクションまたはイベントを、ファクトテーブル内のデータの行として、販売注文レコード、支払いレコードなどの1つの単位として受け取ります。トランザクションが送信され、ファクトテーブルデータが挿入されると、データは変更されなくなり、その更新方法は増分更新になります。
（2）周期スナップショットファクトテーブル
周期ファクトテーブルは、すべてのデータを保持するのではなく、日次または月次の売上、月次の口座残高など、一定の間隔のデータのみを保持します。
（3）累積スナップショットファクトテーブル
累積スナップショットファクトテーブルは、ビジネスファクトの変更を追跡するために使用されます。たとえば、データウェアハウスは、注文が出されてから注文アイテムがパッケージ化、輸送、署名されるまでのさまざまなビジネスステージの時点データを蓄積または保存して、注文宣言サイクルの進行状況を追跡する必要がある場合があります。このビジネスプロセスが進むにつれて、ファクトテーブルのレコードも常に更新する必要があります。
4.6データウェアハウスモデリング
1. odsレイヤー
（1）元のデータを変更せずに保持し、データのバックアップの役割を果たします。
（2）データを圧縮してディスクの記憶容量を減らします（例：元のデータ100G、約10Gに圧縮できます）。
（3）パーティションテーブルを作成して、その後の全表スキャンを防止します。
2. dwdレイヤー
dwdレイヤーは、次元モデルを構築する必要があります。通常、スターモデルが使用され、表示される状態は通常、コンステレーションモデルです。
ディメンションモデリングは通常、次の4つのステップに従います。
ビジネスプロセスの選択->粒度の宣言->ディメンションの確認->ファクトの確認。
（1）ビジネスプロセスの選択ビジネス
システムで、注文ビジネス、支払いビジネス、返金ビジネス、ロジスティクスビジネスなど、関心のあるビジネスラインを選択します。1つのビジネスラインはファクトテーブルに対応します。
（2）粒度の宣言
データの粒度とは、データウェアハウスに格納されているデータの洗練度と統合された手順のレベルを指します。
粒度を宣言するということは、ファクトテーブル内のデータの行が何を表すかを正確に定義することを意味します。さまざまなニーズを満たすために、可能な限り最小の粒度を選択する必要があります。
一般的な粒度ステートメントは次のとおりです。
注文では、各アイテムは注文ファクトテーブルの行と見なされ、粒度は注文が行われるたびに行われます。
1週間あたりの注文数は行と見なされ、粒度は毎週行われる注文です。
1か月あたりの注文数は行と見なされ、粒度は毎月の注文数です。
（3）ディメンション
の決定ディメンションの主な機能は、ビジネスが存在するという事実を説明することであり、主に「誰が、どこで、いつ」などの情報を表します。
（4）
事実の特定ここでの事実という用語は、注文量、注文数など、ビジネスにおける測定値を指します。
dwd層では、ビジネスプロセスがモデリングドライブであり、特定の各ビジネスプロセスの特性に基づいて、最も詳細な詳細レベルのファクトテーブルが作成されます。ファクトテーブルは適切に広げることができます。
3. dwsレイヤー
各サブジェクトオブジェクトの毎日の動作をカウントし、dwtレイヤーのサブジェクト全体のテーブル、および特別なニーズを満たすためのいくつかのビジネス詳細データを提供します。
毎日の機器の動作、毎日のメンバーの動作、毎日の製品の動作、毎日のクーポン統計（予約済み）、毎日のアクティビティ統計（予約済み）、毎日の購入動作（予約済み）。
4. dwtレイヤー
は、分析対象のサブジェクトオブジェクトによってモデル駆動され、上位レイヤーのアプリケーションと製品インデックスの要件に基づいて、サブジェクトオブジェクトの実物大のテーブルが作成されます。
デバイステーマ、メンバーテーマ、製品テーマ、クーポンテーマ（予約済み）、イベントテーマ（予約済み）、購入テーマ（予約済み）。
5.広告レイヤー
eコマースシステムの主要なテーマ別指標を個別に分析します。
5つのodsレイヤーアーキテクチャ
https://blog.csdn.net/a1786742005/article/details/105868600
6つのdwdレイヤーアーキテクチャ
https://blog.csdn.net/a1786742005/article/details/105869203
7つのdwsレイヤーアーキテクチャ
https://blog.csdn.net/a1786742005/article/details/105896551
8つのdwtレイヤーアーキテクチャ
https://blog.csdn.net/a1786742005/article/details/105903030
9つの広告レイヤーアーキテクチャ
https://blog.csdn.net/a1786742005/article/details/105914300
X.プロジェクトの概要
1.データウェアハウスを構築し、事前に適切な需要分析を行うことが非常に重要です。
2.データウェアハウス全体で、odsレイヤーに25テーブル、dwdレイヤーに26テーブル、dwsレイヤーに6テーブル、dwtレイヤーに5テーブル、adsレイヤーに19テーブル、合計81テーブルがあります。