前言web
數據建模乍一聽的時候感受很是的有技術性，而且外行感受很是的高大上，高深莫測。面試
在目前的時代下，數據量能夠說是海量，而且還在持續增加，那麼對於企業來講，如何快速的準確的從這些數據中獲取本身想獲得的信息呢？算法
什麼是數據建模數據庫
數據建模簡單來講就是基於對業務的理解，將各類數據進行整合和關聯，並最終使得這些數據可用性，可讀性加強，讓使用方能快速的獲取到本身關心的有價值的信息而且及時的做出響應，爲公司帶來效益。
微信
爲何要建模數據結構
數據建模是一套方法論，主要是對數據的整合和存儲作一些指導，強調從各個角度合理的存儲數據。
架構
有了合適的數據模型，是會帶來不少好處的：
app
查詢使用性能提高
數據庫設計用戶效率提升，改善用戶體驗
編輯器數據質量提高
......
因此大數據系統須要數據模型方法來更好的組織和存儲，以便在性能,成本，效率和質量之間取的平衡。
建模經常使用工具
PowerDesigner：
Power Designer 是Sybase公司的CASE工具集，使用它能夠方便地對管理信息系統進行分析設計，他幾乎包括了數據庫模型設計的全過程。利用Power Designer能夠製做數據流程圖、概念數據模型、物理數據模型，還能夠爲數據倉庫製做結構模型，也能對團隊設計模型進行控制。他能夠與許多流行的軟件開發工具，例如PowerBuilder、Delphi、VB等相配合使開發時間縮短和使系統設計更優化。
power designer是能進行數據庫設計的強大的軟件，是一款開發人員經常使用的數據庫建模工具。使用它能夠分別從概念數據模型(Conceptual Data Model)和物理數據模型(Physical Data Model)兩個層次對數據庫進行設計。在這裏，概念數據模型描述的是獨立於數據庫管理系統(DBMS)的實體定義和實體關係定義；物理數據模型是在概念數據模型的基礎上針對目標數據庫管理系統的具體化。
業務系統和數據倉庫建模區別
在業務系統中，一般面對業務庫的隨機讀寫，目前主要是採用三範式（3NF）模型存儲數據。
而在數據倉庫的建模過程當中，因爲主要是數據的批量讀取操做，可是事物並非咱們所關心的，主要是關注數據的整合以及查詢處理性能，所以會採用其餘的建模方法，以Kimball維度建模最爲經典。
Kimball和Inmon架構
Inmon架構
輻射狀企業信息工廠(CIF) 方法由Bill Inmon及業界人士倡導的。在這個環境下，數據從操做性數據源中獲取，在ETL系統中處理，將這一過程稱爲數據獲取，從這一過程當中得到的原子數據保存在知足第三範式的數據庫中，這種規範化的原子數據的倉庫被稱爲CIF架構下的企業級數據倉庫(EDW)
與Kimball方法類似，CIF提倡企業數據協調與集成，但CIF認爲要利用規範化的EDW承擔這一角色，而Kimball架構強調具備一致性維度的企業總線的重要做用
Inmon企業級數據倉庫的分析數據庫一般以部門爲中心（而不是圍繞業務過程來組織），並且包含彙總數據，並非原子級別數據，若是ETL過程當中數據所應用的業務規則超越了基本概要，如部門更名了或者其餘的相似計算，要將分析數據庫與EDW原子數據聯繫起來將變得很困難
Kimball架構利用了CIF中處於中心地位的EDW，可是這次的EDW徹底與分析與報表用戶隔離，僅做爲數據來源，其中數據是維度的，原子的，以過程爲中心的，與企業級數據倉庫總線結構保持一致。
流程
Inmon架構是自頂向下，即從數據抽取-->數據倉庫-->數據集市，以數據源爲導向，是一種瀑布流開發方法，模型偏向於3NF，
Kimball:架構是自下向上，即從數據集市(主題劃分)-->數據倉庫--> 數據抽取，是以需求爲導向的，通常使用星型模型
事實表和維表
Inmon架構下，不強調事實表和維表的概念，由於數據源變化可能會比較大，更增強調的是數據清洗的工做
kimball架構強調模型由事實表和維表組成，注重事實表與維表的設計
數據集市
Inmon架構中，數據集市有本身的物理存儲，是真實存在的。
Kimball數據倉庫架構中，數據集市是一個邏輯概念，只是多維數據倉庫中的主題域劃分，並無本身的物理存儲，也能夠說是虛擬的數據集市。是數據倉庫的一個訪問層，是按主題域組織的數據集合，用於支持部門級的決策。
中心
Inmon架構是以部門爲中心，而Kimball架構是以業務過程爲中心
EDW的訪問
Inmon架構中用戶能夠直接訪問企業數據倉庫(EDW)
Kimball架構中用戶不能夠直接訪問企業數據倉庫(EDW)，只能訪問展示區數據
企業開發中通常選擇Kimball維度建模
數據建模的幾種方式
ER模型是屬於三範式的，是企業級的主題抽象而不是單獨描述某個業務
1.1 什麼是範式
當分類不可再分時，這種關係是規範化的，一個低級範式分解轉換爲更高級的範式時，就叫作規範化
數據表能夠分爲1-5NF，第一範式是最低要求，第五範式則是最高要求
最經常使用的範式有第一範式（1NF）、第二範式（2NF）、第三範式（3NF）
1.2 第一範式
表中的每一列都是不可拆分的原子項
由上圖可知，phone字段裏面存了2個值，具備可分割性，不符合1NF，能夠改爲：
1.3 第二範式
第二範式要同時知足下面兩個條件：
知足第一範式。
沒有部分依賴。
上圖能夠看出，若是一個用戶下了不少訂單，則用戶名，收穫地址和手機號有重複出現的狀況形成數據冗餘，很明顯不太符合第二範式，能夠改爲：
1.4 第三範式
第三範式要同時知足下面兩個條件：
知足第二範式。
沒有傳遞依賴。
簡單點說，關係重複，能互相推導出來
如上圖所示，若是知道了zip郵編，實際上是能推出來省市區的，相反，知道了省市區，也是能夠推出郵編的，有傳遞依賴，形成了冗餘，不符合第三範式，須要改造:
1.5 小結
在關係數據模型設計中，通常須要知足第三範式的要求。若是一個表有良好的主外鍵設計，就應該是知足3NF的表。
規範化帶來的好處是經過減小數據冗餘提升更新數據的效率，同時保證數據完整性。然而，咱們在實際應用中也要防止過分規範化的問題。規範化程度越高，劃分的表就越多，在查詢數據時越有可能使用錶鏈接操做。
而若是鏈接的表過多，會影響查詢的性能。關鍵的問題是要依據業務需求，仔細權衡數據查詢和數據更新的關係，制定最適合的規範化程度。還有一點須要注意的是，不要爲了遵循嚴格的規範化規則而修改業務需求。
維度建模
維度建模是一種將大量數據結構化的邏輯設計手段，包含維度和指標，它不像ER模型目的是消除冗餘數據，維度建模是面向分析，最終目的是提升查詢性能，因此會增長數據冗餘，而且違反三範式。
維度建模也是重點關注讓用戶快速完成需求分析且對於複雜查詢及時響應，維度建模通常能夠分爲三種：
星型模型
雪花模型
星座模型
其中最經常使用的實際上是星型模型
2.1 背景
在多維分析的商業智能解決方案中，根據事實表和維度表的關係，又可將常見的模型分爲星型模型，雪花型模型及星座模型。在設計邏輯型數據的模型的時候，就應考慮數據是按照星型模型，雪花型模型仍是星座模型進行組織。
星形模型中有一張事實表，以及零個或多個維度表，事實表與維度表經過主鍵外鍵相關聯，維度表之間沒有關聯，當全部維表都直接鏈接到「 事實表」上時，整個圖解就像星星同樣，故將該模型稱爲星型模型。星形模型是最簡單，也是最經常使用的模型。因爲星形模型只有一張大表，所以它相比於其餘模型更適合於大數據處理。其餘模型能夠經過必定的轉換，變爲星形模型。
星型架構是一種非正規化的結構，多維數據集的每個維度都直接與事實表相鏈接，不存在漸變維度，因此數據有必定的冗餘，如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那麼國家 A 和省 B 的信息分別存儲了兩次，即存在冗餘。
2.3 雪花模型
當有一個或多個維表沒有直接鏈接到事實表上，而是經過其餘維錶鏈接到事實表上時，其圖解就像多個雪花鏈接在一塊兒，故稱雪花模型。雪花模型是對星型模型的擴展。它對星型模型的維表進一步層次化，原有的各維表可能被擴展爲小的維度表，造成一些局部的 " 層次 " 區域，這些被分解的表都鏈接到主維度表而不是事實表。如圖，將地域維表又分解爲國家，省份，城市等維表。它的優勢是 : 經過最大限度地減小數據存儲量以及聯合較小的維表來改善查詢性能。雪花型結構去除了數據冗餘。
2.4 星座模型
星座模型是由星型模型延伸而來，星型模型是基於一張事實表而星座模式是基於多張事實表，而且共享維度表信息，這種模型每每應用於數據關係比星型模型和雪花模型更復雜的場合。星座模型須要多個事實表共享維度表，於是能夠視爲星形模型的集合，故亦被稱爲星系模型
2.5 對比
星型模型由於數據的冗餘因此不少統計查詢不須要作外部的鏈接，所以通常狀況下效率比雪花型模型要高。
星型結構不用考慮不少正規化的因素，設計與實現都比較簡單。
雪花型模型因爲去除了冗餘，有些統計就須要經過表的聯接才能產生，因此效率比較低。
正規化也是一種比較複雜的過程，相應的數據庫結構設計、數據的 ETL、以及後期的維護都要複雜一些。
2.6 小結
經過對比，咱們能夠發現數據倉庫大多數時候是比較適合使用星型模型構建底層數據Hive表，經過大量的冗餘來減小表查詢的次數從而提高查詢效率，星型模型對OLAP的分析引擎支持比較友好，這一點在Kylin中比較能體現。而雪花模型在關係型數據庫中如MySQL，Oracle中很是常見，尤爲像電商的數據庫表。在數據倉庫中雪花模型和星座模型的應用場景比較少，但也不是沒有，因此在具體設計的時候，能夠考慮是否是能結合二者的優勢參與設計，以此達到設計的最優化目的。
2.7 建模原則：
高內聚和低輯合
將業務相近或者相關、粒度相同的數據設計爲一個邏輯或者物理模型：將高几率同 時訪問的數據放一塊兒 ，將低機率同時訪問的數據分開存儲。
核心模型與擴展模型分離
創建核心模型與擴展模型體系，核心模型包括的宇段支持經常使用的核心業務，擴展模型包括的字段支持個性化或少許應用的須要 ，不能讓擴展模型的宇段過分侵人核心模型，以避免破壞核心模型的架構簡潔性與可維護性。
公共處理邏輯下沉及單一
越是底層公用的處理邏輯越應該在數據調度依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯多處同時存在。
成本與性能平衡
適當的數據冗餘可換取查詢和刷新性能，不宜過分冗餘與數據複製。
數據可回滾
處理邏輯不變，在不一樣時間屢次運行數據結果肯定不變。
一致性
具備相同含義的字段在不一樣表中的命名必須相同，必須使用規範定義中的名稱。
命名清晰、可理解
表命名需清晰、一致，表名需易於消費者理解和使用。
星型模型設計步驟：
選擇須要進行分析決策的業務過程。業務過程能夠是單個業務事件，好比交易的支付、退款等；也能夠是某個事件的狀態，好比當前的帳戶餘額等；還能夠是一系列相關業務事件組成的業務流程，具體須要看咱們分析的是某些事件發生狀況，仍是當前狀態，或是事件流轉效率。
選擇粒度。在事件分析中，咱們要預判全部分析須要細分的程度，從而決定選擇的粒度。粒度是維度的一個組合。
識別維表。選擇好粒度以後，就須要基於此粒度設計維表，包括維度屬性，用於分析時進行分組和篩選。
選擇事實。肯定分析須要衡量的指標
Data Vault Dan Linstedt 發起建立的一種模型，它是模型的衍生，其設計的出發點也是爲了實現數據的整合，但不能直接用於數據分析決策。它強調創建一個可審計的基礎數據層，也就是強調數據的歷史性、可追溯性和原子性，而不要求對數據進行過分的一致性處理和整合；
同時它基於主題概念將企業數據進行結構化組織，並引入了更進一步的範式處理來優化模型，以應對源系統變動的擴展性。Data Vault 型由如下幾部分組成。
• Hub ：是企業的核心業務實體，由 實體 key 、數據倉庫序列代理鍵、裝載時間、數據來源組成。
• Link ：表明 Hub 之間的關係。這裏與 模型最大的區別是將關系做爲一個獨立的單元抽象，能夠提高模型的擴展性。它能夠直
接描述 1:1 1:n n:n 的關係，而不須要作任何變動。它由 Hub 的代理鍵、裝載時間、數據來源組成。
• Satellite ：是 Hub 的詳細描述內容， 一個 Hub 能夠有多個 Satellite它由 Hub 的代理鍵、裝載時間、來源類型、詳細的 Hub 描述信息組成。
Data Vault 模型比 ER 模型更容易設計和產出，它的 ETL 加工可實現配置化。
模型分層
前言
數據倉庫通常分爲三層，自上而下分別爲數據貼源層（ODS，Operation Data Store）、數據公共層（CDM，Common Data Model）和數據應用層（ADS，Application Data Service）。
貼源層，與業務庫保持一致，不作任何處理
公共維度層（DIM）：基於維度建模理念思想，創建企業一致性維度。下降數據計算口徑和算法不統一風險。 公共維度層的表一般也被稱爲邏輯維度表，維度和維度邏 輯表一般一一對應。
明細粒度事實層（DWD）：對數據進行規範化編碼轉換，清洗，統一格式，脫敏等，不作橫向整合
主題寬表層(DW) 對dwd各類信息進行整合，輸出主題寬表(面 向業務過 程，不一樣業務過程的信息不冗餘建設，採用外鍵形式)
公共彙總粒度事實層（DWS）：以分析的主題對象做爲建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標事實表，以寬表化手段物理化模型。構建命名規範、口徑一致的統計指標，爲上層提供公共指標，創建彙總寬表、明細事實表。
清晰數據結構：每個數據分層都有它的做用域，這樣咱們在使用表的時候能更方便地定位和理解。
數據血緣追蹤：簡單來說能夠這樣理解，咱們最終給業務呈現的是一張能直接使用的張業務表，可是它的來源有不少，若是有一張來源表出問題了，咱們但願可以快速準確地定位到問題，並清楚它的危害範圍。
減小重複開發：規範數據分層，開發一些通用的中間層數據，可以減小極大的重複計算。
把複雜問題簡單化：將一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。並且便於維護數據的準確性，當數據出現問題以後，能夠不用修復全部的數據，只須要從有問題的步驟開始修復。
# 參考 《大數據之路：阿里巴巴大數據實踐》
# 參考 《數據倉庫工具箱-維度建模指南》
# PowerDesigner介紹來自百度百科
如何寫好一篇數據部門規範文檔
如何優化整個數倉的執行時長(好比7點全部任務跑完，如何優化到5點)
深刻探究order by,sort by,distribute by,cluster by
本文分享自微信公衆號 - 大數據私房菜（datagogogo）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。