1.最後のレビュー

https://blog.csdn.net/SparkOnYarn/article/details/105388526
簡単なレビュー：基本情報、製品カテゴリ（SKU）、サプライヤー、マーチャント+ユーザー、購入プロセス、販売倉庫小売、在庫のしきい値は通常、企業内で人為的に（データマイニングによって）設定されます。倉庫の最も重要なポイントは、倉庫の在庫です。倉庫の物理的なオブジェクトとシステムは一貫していない可能性があります（盗まれたり、誤って誤って送信されたりする可能性があります）。一般に、購入と配送のために選択される商品。単価の比較的高い商品も数える必要があります。

2.データウェアハウスの理論的知識

2.1データウェアハウスとは

データウェアハウス（英語名はデータウェアハウス）は、DWまたはDWHと省略できます。
データウェアハウスは、企業のあらゆるレベルの意思決定プロセスにあらゆるタイプのデータサポートを提供する戦略的なコレクションです。
これは、分析レポートおよび意思決定支援の目的で作成された単一のデータストアです。
ビジネスインテリジェンスを必要とする企業に対して、ビジネスプロセスの改善、監視時間、コスト、品質、および制御に関するガイダンスを提供します。

簡単に言う
と、1つのデータ収集データは、ログタイプ（挿入ステートメントのみを含む）とDBリレーショナルタイプ（設計の更新、挿入、削除）の2つのタイプに分類されます。

2.実効値レポートレポートのマイニング（静的レポート：固定Webインターフェイスはハードコーディングされ、動的レポート：データは基本データです。運用担当者は、倉庫の1時間あたりの注文数量を確認するだけでなく、倉庫の毎日の注文も確認する必要があります。ボリューム、倉庫内のさまざまなサプライヤーの1時間ごとの供給を確認するため）、リアルタイムの大画面、他のビジネスシステムの指標の計算（インテリジェントな注文、パッケージソリューションのインテリジェントな推奨）、ネイルアプリケーション（アプリの場合、Android、IOS、スタッフのオーバーヘッド）大きすぎます; h5は爪にネストされています。直接使用してください; IDSインテリジェント決定システム）

3.企業の意思決定を提供する

データがログタイプのみの場合は、非常に満足するはずです。dbタイプになると、ログタイプよりも複雑さが増します。一般的に、データをマイニングすることの効果的な値は、実際にレポートを作成することです。

次の4つの指標：
a。1時間あたりの各倉庫の注文数量b。1日あたりの各倉庫の注文数量
（要約）
c。1時間あたりの各倉庫の
各サプライヤーの注文数量d。1日あたりの各倉庫の各サプライヤーの注文数量

aによれば、bは取得でき、dはcから直接取得できます。一番下のデータは、1時間あたりの各サプライヤーの注文のみを必要とします。

倉庫	サプライヤー	時間	時	件数
B01	サプライヤー1	2020-04-08	00	1000
B01	サプライヤー1	2020-04-08	01	1500
B01	サプライヤー1	2020-04-08	02	2000年
B01	サプライヤー1	2020-04-08	03	3000

一般に、最小の粒度でのみ多次元要約データを保存します。動的レポートのステートメントは、倉庫の日次発注量、倉庫の月次発注量、倉庫の各サプライヤーの月次発注量の計算など、ドリルアップとドリルダウンです。sql-> group byは自動的に接続されます。

時間ディメンションに従って実行できる計算：年、月、日、四半期、早い、中間、遅い;

静的レポートと動的レポート：

静的レポートは4つのテーブルを保存して書き込むことです。動的レポートには、最も多くのディメンションと最小の粒度を持つレポートが必要です。次に、group byステートメントを実行します。J兄弟の本番データはESに保存されます。動的レポートは、ビジネスニーズに応じて静的に変換できます。レポート。静的レポートは選択するだけでよく、動的レポートはステートメントごとにグループ化する必要があります。

例として、有効な値のマイニングにおけるインテリジェントな順序付けを取り上げます。

たとえば、収穫先住所が上海の場合、ユーザーの住所に従って解析され、倉庫に商品があるかどうかを判断している間、注文は最寄りの倉庫に配布されます。手動で商品を選び、それを確認して梱包し、梱包後にスキャンして、倉庫エリアに置きます。
包装スキームのインテリジェントな推奨は、古い鶏を購入する、履歴データに基づいてモデルを計算する、現在のデータに基づいてモデルを計算する、送信する箱の大きさ、ドライアイスの量など、包装箱を作るための商品のサイズに基づきます。

データマート（データウェアハウスのサブセット）は、データウェアハウスが複数のデータマートから組み立てられることでも理解できます。

データマートはデータマーケットとも呼ばれ、特定の部門やユーザーのニーズを満たし、ディメンションの定義、計算対象のインジケーター、ディメンションのディメンションなどを含む多次元的な方法で格納して、意思決定指向の生成を行います分析に必要なデータキューブ。
スコープの観点から、データは企業全体のデータベース、データウェアハウス、またはより専門的なデータウェアハウスから抽出されます。データセンターの焦点は、分析、コンテンツ、パフォーマンス、および使いやすさの点で、プロのユーザーグループの特別なニーズに応えることです。データセンターのユーザーは、データが慣れ親しんだ言葉で表現されることを期待しています。

データウェアハウスとは、すべてのデータをマイニングして分析する必要があることを意味します。たとえば、データマートは調達部門のみを分析します。

データウェアハウス	データマート
企業レベル	部門レベル
たくさんの完全なデータ	データの一部のみ

データウェアハウスはありません。データセンターについて話し、データウェアハウスを準備するだけです。

2.2データウェアハウスの階層化

ここに画像の説明を挿入
1. ODS（操作データストア）の元のデータレイヤーは、何も処理せずに元のデータを格納します;ジッパーテーブル

2. DWD / DWI（データウェアハウスの詳細）の構造と細分性は、ODSレイヤーと一貫性があり、ODSレイヤーデータのみがクリーンアップされます（ダーティデータとnull値がクリーンアップされます）。

3. DWS（データウェアハウスサービス）は、簡単な要約のためのDWDレイヤーに基づいています。一般に、ワイドテーブルを作成し、このレイヤーで結合が1つだけ作成されます。DWSの結果は、DWDレイヤーのデータの複数のテーブルを結合した結果です。、少量でgroup byを使用できます。

4. ADS / APP /ドメイン（アプリケーションデータストア）レイヤーは、サブジェクトごとの統計データを提供することを指します。一般的に、DWSレイヤーに基づくワイドテーブルは、グループごとの計算に使用され、可能な結合計算は少数です（ワイドテーブルによって異なります）。必要なフィールドはありません）

たとえば、各ワイドテーブルの最初のカテゴリのデータをリクエストするには、次のテーブルを結合する必要があります。
本番環境では、ADSレイヤーパーティションテーブルに外部テーブルを使用することをお勧めします。これにより、テーブルが削除されても、データはそのまま残ります。

DWDレイヤーをクリーンアップするかどうかは、主に上流システムに依存します。通常、ODSのデータフローはDWDレイヤーに転送されます。2つのデータは同じであり、これは比較的標準的なデータ分割レベルです。

ODSレイヤーには、開始日と終了日によって制御されるジッパーテーブルも含まれます。DWSレイヤーの幅の広いテーブルは、注文などのテーマを囲む必要があります（その場合、操作には注文関連情報が必要です）。

2.3、Dbeaverを使用してHiveServer2に接続する

補充待ち

2.4。データ品質を保証する方法（上流→下流）

行から列、列から行、およびウィンドウシークのtopNであるMySQLのビジネスシナリオは、基本的にこれらです。

最初からデータウェアハウスプロジェクトが最も成長しています。入力した会社が階層化され、さまざまなビジネス分析指標が確立されました。次に、SQLをプロジェクトに書き込むことができ、データウェアハウスエンジニアと見なすことができます。データ構築モデルモデリングとは、はっきり言って、テーブルを作成し、インジケーターに従ってSQLを作成することです。

アップストリームからダウンストリームへのデータの品質を保証する方法？MySQL-> Hive抽出中にデータの損失はありますか？SqoopなどのSQOOP、DataX、OracleデータをHiveに抽出しますが、Sqoopはエラーをスローしません、

2.5、命名規則（MySQL命名規則の類似化）

テーブルプレフィックス：ods、dwd、dws、ads、dwdレイヤーでは、テーブルプレフィックスはfact（ファクトテーブル）、dim（ディメンションテーブル）と表示さ
れる場合があります。同じ意味のフィールド名の場合、dwsレイヤーのテーブル設計を統一する必要があります。注文番号を例として、表aのorderno、表bのordererid、表cのid、unified ordernoを、例として作成時間を、ctime、cre_time、createtime、create_time、unifiedとします。 create_timeです。

2.6データウェアハウスを層別化する必要があるのはなぜですか

ODSレイヤーとADSレイヤーを直接使用して、DWDレイヤーとDWSレイヤーを削除できないのはなぜですか？
注：機能が同じである限り、各会社の名前と名前は異なる場合があります

1.複雑な問題を単純化する：非常に複雑なタスクを複数のステップに分解して完了します。各レイヤーは単一のステップのみを処理します。これは比較的単純です（2番目のレイヤーでのデータクリーニング、3番目のレイヤーでのデータ結合、4番目など）。レイヤーデータグループ化）;

2.繰り返し開発の削減：中間層のデータにより、繰り返し計算を減らし、1つの計算の再利用性を高めることができます。

3.元のデータを分離できます。ビジネス開発を行う場合、テーブルの各レイヤーに権限があります。たとえば、ODSレイヤーデータからDWDレイヤーデータまで、携帯電話番号、銀行カード番号、自宅住所の列を削除する必要があります。機密性の高い処理。DWDレイヤーのテーブルは権限によって制御されます。会社を新たに入力したため、DWSレイヤーのデータにのみアクセスできます。たとえば、電話番号は138XXXXXXXXです。

ODSレイヤーのデータはそのままMySQLから転送され、ブラザーJの感度低下はMySQLレイヤーで行われたため、データを直接受信できます。

元のデータを分離する：データの機密性により、実際のデータと統計データが分離されます。

データウェアハウスの階層化は優れているわけではなく、妥当な階層設計と計算コストと人件費のバランスが、優れたデータウェアハウスアーキテクチャのパフォーマンスです。

一部の企業では、データウェアハウスに5層、6層、7層があります。層4は非常に古典的なアーキテクチャであり、存在することは妥当です。当時の階層化された処理は、当時のビジネス要件を満たしていました。

3、ERP注文マスターテーブル&&スケジュール設計ケース

データは次のとおりです。

ジュニアプログラマーの設計：注文リスト

注文番号	会員ID	取引時間	商品名	商品価格	商品数	小計	合計金額
2019090900001	12345678	2019-09-O9 09:00:00	ベトナムは赤い果実に入る	33.9	３	101.7	611.5
2019090900001	12345678	2019-09-O9 09:00:00	【ドンポパビリオン】ポメロレッドハニーポメロ	11.8	1	11.8	611.5
2019090900001	12345678	2019-09-O9 09:00:00	チリキングクラブギフトボックス	498	1	498	611.5