一、模型分層

緩沖數據模型 BDM
源業務系統數據的快照，保存細節數據，按天分區，會保持最近一段時間數據。一般情況下，每個BDM表對應著源業務系統的一個表或者一個日志文件，數據結構與線上基本是對應的。絕大多數的數據快照是經過增量抽取策略抽過來了，對于不支持增量抽取策略或者數據量極少的表采用全量抽取的策略。

基礎數據模型 FDM
基礎數據模型，用來保存源業務系統數據的快照，數據永久保存。對于有更新操作的數據來說，采用拉鏈的方式優化存儲。對于沒有更新操作的數據來說，采用流水方式存儲。

通用數據模型 GDM
根據京東核心業務主題按照星型模型或雪花模型設計方式建設的最細業務粒度匯總層。在本層需要進行指標與維度的標準化，保證指標數據的唯一性。

聚合數據模型 ADM
根據不同的業務需求采用星型或雪花型模型設計方法構建的按維度匯總數據。

維度模型 DIM
維度表可以看作是用戶來分析數據的窗口，維度表中包含事實數據表中事實記錄的特性，有些特性提供描述性信息，有些特性指定如何匯總事實數據表數據，以便為分析者提供有用的信息，維度表包含幫助匯總數據的特性的層次結構。例如，包含訂單信息的維度表通常包含將訂單分為區域、省份、城市等若干類的層次結構。在維度表中，每個表都包含獨立于其他維度表的事實特性，例如，客戶維度表包含有關客戶級別的數據。維度表中的列字段可以將信息分為不同層次的結構級。

臨時層 TMP
用來降低加工過程計算難度，提高運行效率的臨時表，用完即舍，不保存歷史數據。
7 中間層(操作數據模型) ODM
在加工通用模型的時候，對于多個模型都使用到的公共數據需要清洗轉換的時候，用來封裝清洗轉換邏輯保存清洗后的數據，供加工通用模型使用，中間層數據保存歷史狀態。

應用數據模型 APP
應用數據模型按照具體的需求進行設計，其數據直接供前端報表工具展現使用，或者推送到其他系統做相關的數據支撐。

數倉分層意義：

清晰數據結構體系

數據血緣追蹤

減少重復開發和資源浪費（避免煙囪式開發）

復雜問題簡單化

統一數據口徑

二、建模分類
我們先從幾個物理概念入手理解什么是流量，存量，增量
（1）存量：系統在某一時點時的所保有的數量；
（2）流量：是指在某一段時間內流入/出系統的數量
（3）增量：則是指在某一段時間內系統中保有數量的變化
（4）增量=流入量–流出量
（5）本期期末存量=上期期末存量+本期內增量

拉鏈表
（1）記錄一個事物從開始，一直到當前狀態的所有變化的信息；
（2）拉鏈表每次上報的都是歷史記錄的最終狀態，是記錄在當前時刻的歷史總量；
（3）當前記錄存的是當前時間之前的所有歷史記錄的最后變化量（總量）；
（4）存量是在某一時刻的總量；
（5）存量一般設計成拉鏈表（月報-常用、日報）；
（6）流量和存量的區別：流量是增量；存量是總量；
（7）封鏈時間可以是2999，3000，9999等等比較大的年份；拉鏈表到期數據要報0；
（8）拉鏈表和增量表的共同點：表結構基本一樣。

流水表：對于表的每一個修改都會記錄，可以用于反映實際記錄的變更
　區別于拉鏈表：　
拉鏈表通常是對賬戶信息的歷史變動進行處理保留的結果，流水表是每天的交易形成的歷史；
流水表用于統計業務相關情況，拉鏈表用于統計賬戶及客戶的情況

快照表：
按照每天存放的數據以及是否按天分區可以分為增量表，全量表和快照表

全量表
（1）全量表，有無變化，都要報
（2）每次上報的數據都是所有的數據（變化的 + 沒有變化的）

增量表
（1）記錄每次增加的量，而不是總量；
（2）流量是指在一定時間內的增量；
（3）流量一般設計成增量表（日報-常用、月報）；
（4）流量和存量的區別：流量是增量；存量是總量；
（5）增量表，只報變化量，無變化不用報

三、數據倉庫建模理論
1、建模三個階段
1.1、概念模型設計（Concept Data Modeling）
這一階段之前的首要工作是明確需求涵蓋的業務范圍。然后再對需求范圍內的業務及其間關系進行高度概括性的描述，把密切相關業務對象進行歸類，即劃分主題域。概念模型的設計是為邏輯模型的設計做準備。
1.2、邏輯模型設計（Logical Data Modeling）
邏輯數據模型（Logical Data Model）是利用數據和關系來反映集團業務的一個過程，其生成的關系數據模型，利用圖形化方式來展現集團業務規則。邏輯數據模型描述了集團的重要業務元素以及這些元素之間的關系，是集團進行數據管理、分析和交流的重要手段，通過它可以清楚地了解集團的數據結構和業務規則，是IT人員和業務人員溝通的橋梁。同時，邏輯數據模型也是用來發現、記錄和溝通業務，展現業務規則的詳細“藍圖”。邏輯數據模型獨立于技術和特定平臺，邏輯數據模型在特定平臺的實施即為物理數據模型。在建立邏輯模型的時候，我們要盡量把所有的業務邏輯涵蓋在模型之中，不能留給程序去定義業務邏輯

1.3、物理模型設計（Physical Data Modeling）
物理數據模型與邏輯數據模型不同，因為要權衡數據源的數據組織結構、ETL過程的復雜程度以及數據庫本身的特點，因此在物理模型中往往會使用一些非正則化處理，增加一些冗余字段和匯總表，而這些是不會出現在邏輯數據模型中的。另外，邏輯數據模型中的元素在物理數據庫中實現時可能被重新組合，例如實體歸并、屬性從一個實體被移到另一個實體等。但是必須堅持的一個基本原則是，物理模型不能改變業務規則，其目的僅是提高數據分析的速度，適應具體數據庫的容量、性能等限制。因此可以說，這一階段面對的是具體的軟硬件平臺和性能要求。

四、數據倉庫設計規范
1、邏輯模型設計
數據倉庫共性加工層邏輯模型設計總體遵循以下設計原則：
中性的，共享的：服務于多個應用相同業務數據的統計；
逆范式化：設計成寬表模型，重新組織基礎層數據，減少了重新關聯表進行計算所帶來的性能問題，加快了查詢的響應時間；
規范的，易懂的：使用業務定義和語言進行模型設計，易于讓業務人員理解和使用，有助于IT和業務部門人員的溝通。
2、物理模型設計
數據倉庫共性加工層物理模型設計總體遵循以下設計原則：
可實施的：結合特定數據庫平臺進行設計，可以在相應平臺上直接創建數據庫，不具有平臺共享性；
高效的：結合數據及使用特性的通過適度冗余、創建索引等手段保證物理數據庫的高效運轉；
規范的，易懂的：物理數據模型與邏輯數據模型同樣需要遵循命名規范，表名、字段名命名規范一致，方便易懂、易查詢。

模型開發相關：
HiveTask總結：
1. 京東SQL任務提交入口，提供如下功能：
1.1 日志存儲
1.2 Spark/MR（Hive）任務切換
1.3 統一提供初始化內置參數
1.4 增加LZO索引 【Jar包】
1.6 提供合并小文件 【Jar包提供功能支持】
1.7 任務失敗重試【是否切換引擎, 開啟Hive重試機制】
1.8 解析表結構、分析等等

總結

以上是生活随笔為你收集整理的京东数仓分层相关的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。