数仓：维度建模
1.背景
數據倉庫的核心是展現層和提供優質的服務。ETL 及其規范、分層等所做的一切都是為了一個更清晰易用的展現層。
2.數倉架構的原則：
1、底層業務的數據驅動為導向同時結合業務需求驅動
2、便于數據分析屏蔽底層復雜業務簡單、完整、集成的將數據暴露給分析層
3、底層業務變動與上層需求變動對模型沖擊最小化業務系統變化影響削弱在基礎數據層（資金訂單改造）結合自上而下的建設方法削弱需求變動對模型的影響數據水平層次清晰化
4、高內聚松耦合主題之內或各個完整意義的系統內數據的高內聚主題之間或各個完整意義的系統間數據的松耦合
5、構建倉庫基礎數據層使得底層業務數據整合工作與上層應用開發工作相隔離，為倉庫大規模開發奠定基礎倉庫層次更加清晰，對外暴露數據更加統一
數倉模型不只是考慮如何設計和實現功能，設計原則應該從訪問性能、數據成本、使用成本、數據質量、擴展性來考慮。
3.如何搭建一個好的數據倉庫：
數倉設計的3個維度：
當前主流建模方法為：ER模型、維度模型。
1、ER模型常用于OLTP數據庫建模，應用到構建數倉時更偏重數據整合， 站在企業整體考慮，將各個系統的數據按相似性一致性、合并處理，為數據分析、決策服務，但并不便于直接用來支持分析。缺陷：需要全面梳理企業所有的業務和數據流，周期長，人員要求高。
2、維度建模是面向分析場景而生，針對分析場景構建數倉模型；重點關注快速、靈活的解決分析需求，同時能夠提供大規模數據的快速響應性能。針對性強，主要應用于數據倉庫構建和OLAP引擎低層數據模型。優點：不需要完整的梳理企業業務流程和數據，實施周期根據主題邊界而定，容易快速實現demo，而且相對來說便于理解、提高查詢性能、對稱并易擴展。
作為大數據板塊，數據來源更加廣泛，針對的業務域也更加寬廣，所以維度建模相對來說更加靈活并適用。
在討論維度建模之前，關注數倉和BI的基本目標是非常有意義的，在做日常的數據需求的時候，經常會遇到如下幾個痛點：
1.收集了海量數據，不知道如何去做ETL；
2.不同來源的數據該如何去聚合；
3.如何方便業務人員快速方便的獲取數據；
4.如何定義重要的數據指標；
5.如何確保數據準確性；
6.數據如何支持決策；
基于上面的痛點，就需要搭建一套DW/BI系統（當然現在市面上有很多類似的產品，例如：如：QuickBI、GrowingIO、神策、猛犸等等），但是對于公司而言，適合自己的才是最好的，大部分公司選擇自己搭建或者利用開源的軟件（例如MateBase），這個系統必須滿足：
1.DW/BI系統能夠方便的存儲信息（或者說能跟現在主流的數據庫打通）。也就是說系統展現的內容必須是容易理解的，對于業務人員必須直觀而且好操作，數據結構和標示必須符合業務思維過程和詞匯，用戶能夠以各種形式切割和分析數據，同時能夠快速的將查詢結果反饋。
2.DW/BI系統必須以一致性的形式展現信息（指標的唯一性）。也就是說數據必須是可信的，同一指標定義在不同的數據源中，所含的意義必須相同，既同名同意性。
3.DW/BI系統能夠適應變化（模塊的低耦合）。當用戶需求、業務維度需要調整的調整的時候，設計的DW模型必須能夠兼容這些變化，已經存在數據和指標不應該被破壞或修改，就算一些指標的調整，也要以適當的方式描述變化，并對用戶完全透明。
4.DW/BI系統必須保證數據安全（數據安全）。能展示的數據必須是統計的結果數據，一些詳單展現和下載必須和平臺的權限系統掛鉤，避免數據泄漏。
5.DW/BI系統成功的標示是業務群體接收并使用，而且必須配套一個展現模塊的監控系統，能夠讓產品方知道各個模塊的使用情況，對一些訪問量比較少的模塊可以適當的調整和優化。
4.介紹
DW/BI架構：
**源事務：**業務庫或者日志等各個方面的數據源，一般不維護歷史信息。
ETL：目的是構建和加載數據到展現區的目標維度模型中，劃分維度和事實。
模型：圍繞業務過程度量事件進行構建，為滿足用戶無法預估的需求，必須包含詳細的原子數據。
為避免數據的冗余存儲造成的浪費和低效，并方便多業務部門查詢方便以及同一指標的數據準確性和業務的擴展性，一般采取以下的架構模式：
4.1維度建模：
用于度量的事實表，事實表一般會有兩個或者多個外健與維度表的主鍵進行關聯。事實表的主鍵一般是組合健，表達多對多的關系。
用于描述環境的維度表，單一主鍵。維度表的屬性是所有查詢約束和報表標示的來源。維度提供數據的入口點，提供所有DW/BI分析的最終標識和分組。
所以維度建模表示每個業務過程包含的事實表，事實表里面存儲事件的數值化度量，圍繞事實表的是多個維度表，維度表包含事件發生的實際存在的文本環境。
從圖表中能看出來，維度模型（星型模型）比較簡單，而且適于變化，各個維度的地位相同。可根據業務情況進行新增或者修改（只要維度的單一值已經存在事實表中）。
4.2雪花模型：
4.3維度建模的主要是4個主要決策：
1、選擇業務過程
業務過程是通常表示的是業務執行的活動，與之相關的維度描述和每個業務過程事件關聯的描述性環境。
通常由某個操作型系統支持，例如：訂單系統。
業務過程建立或獲取關鍵性能度量。
一系列過程產生一系列事實表。
2、聲明粒度
粒度傳遞的是與事實表度量有關的細節級別。
精確定義某個事實表的每一行表示什么。
對事實表的粒度要達成共識。
3、確認維度
健壯的維度集合來粉飾事實表。
維度表示承擔每個度量環境中所有可能的單值描述符。
4、確認事實
不同粒度的事實必須放在不同的事實表中。
事實表的設計完全依賴物理活動，不受最終報表的影響。
事實表通過外健關聯與之相關的維度。
查詢操作主要是基于事實表開展計算和聚合。
其中粒度是非常重要的，粒度用于確定事實表的行表示什么，建議從關注原子級別的粒度數據開始設計，因為原子粒度能夠承受無法預估的用戶查詢，而且原子數據可以以各種可能的方式進行上卷，而一旦選擇了高粒度，則無法滿足用戶下鉆細節的需求。
事實是整個維度建模的核心，其中雪花模型或者星型模型都是基于一張事實表通過外健關聯維表進行擴展，生成一份能夠支撐可預知查詢需求的模型寬表，而且最后的查詢也是落在事實表中進行。
目前常見的維度模型：星型模型每一個維表都與都與事實表相關聯。數據冗余量較大雪花模型有些維表可能不與事實表直接關聯，而是通過其他維表關聯到事實表。數據冗余量較小星座模型由多個事實表相組合，維表是公共的。企業中一般都是星座模型
注意：
維度表的唯一主鍵應該是代理健而不是來自系統的標示符，也就是所謂的自然健，因為自然鍵通常具有一定的業務含義，但日久天長，這些信息是有可能發生變化的，而代理健可以提高關聯效率并將關系數據庫設計和業務的解耦。
維度表和事實表關聯的每個連接應該基于無含義的整數代理健。
固定深度層次在維度表中應該扁平化，規范化的雪花模型不利于多屬性瀏覽，而且大量的表和連接操作會影響性能。
非完全獨立的維度應該合并為一個維度，將同一層次的元素標示為事實表中不同維度是錯誤的，會增加查詢和存儲負擔，最后變成蜈蚣表，例如：日維度、周維度、月維度等可以合并為一個周期維度。
5.案例
維度建模是一個迭代設計過程，設計工作從總線矩陣中抽取實體級別的初始圖形化模型開始，詳細建模過程要深入定義、資源、關系、數據質量問題以及每張表的數據轉換，主要目標是建立滿足用戶需求的模型，校驗可加載到模型中的數據，為ETL提供明確的方向。
這是一個以客戶創建為事實表的售前流程的雪花模型。
事實表：客戶創建信息表
維度表：銷售信息表、店鋪信息表、跟進表/約見表/風控通過表/訂單表的維度上卷。
以上面的維度模型可以聚合出創建、跟進、風控等各個維度的上層展現的數據。
6.擴展：實時即未來
目前不少公司都在嘗試以Flink、Kudu為基礎的實時數倉架構，里面的數倉分層模型和離線的數倉架構基本相同。
下圖為實時數倉架構，離線和實時的差不多，畫圖好難 ，所以在網上拷貝了這個圖，如侵刪，具體實時的架構圖見：
1、ODS原始層是存放原始數據，主要是埋點數據（日志數據）和業務操作數據（binlong），數據源主要是Mysql、HDFS、Kafka等
2、DW中間層主要存放ETL和主題匯總之后的中間層數據，這塊又分為：
DWD：事實表（data warehouse detail） 數據倉庫明細表，以業務過程作為建模驅動，基于每個具體的業務過程特點，構建最細粒度的明細層事實表。
DWS：事實表 （data warehouse summary） 數據倉庫輕度匯總層，按照各個業務域進行輕度匯總成分析某一個主題域的服務數據，一般是寬表。
DIM：維度表，公共維度層，基于維度建模理念思想，建立整個業務過程的一致性維度，主要使用 MySQL、Hbase、Redis 三種存儲引擎，對于維表數據比較少的情況可以使用 MySQL，對于單條數據大小比較小，查詢 QPS 比較高的情況，可以使用 Redis 存儲，降低機器內存資源占用，對于數據量比較大，對維表數據變化不是特別敏感的場景，可以使用HBase 存儲。
3、DM數據集市層，以數據域+業務域的理念建設公共匯總層，對于DM層比較復雜，需要綜合考慮對于數據落地的要求以及具體的查詢引擎來選擇不同的存儲方式，分為輕度匯總層和高度匯總層。
輕度匯總層以寬表的形式存在，主要是針對業務域進行快速方便的查詢；
高度匯總層由明細數據層或輕度匯總層通過聚合計算后寫入到存儲引擎中，產出一部分實時數據指標需求，靈活性比較差，主要做大屏展現。
4、理論上上面還一APP層，應用層，主要是通過這幾層之后，生成輕度或者高度匯總的數據，然后根據業務域進行接口封裝提供給上層使用。
但是實時數倉面臨以下幾個實施關鍵點：
端到端數據延遲、數據流量的監控；
故障的快速恢復能力；
數據的回溯處理，系統支持消費指定時間段內的數據；
實時數據從實時數倉中查詢，T+1數據借助離線通道修正；
業務數據質量的實時監控；
思考：
實時數倉架構和數據中臺一樣，雖然都是屬于當前比較熱門的概念，但是對于實時數倉的狂熱追求大可不必。首先，在技術上幾乎沒有難點，基于強大的開源中間件（例如：Flink、kudu等）實現實時數據倉庫的需求已經變得沒有那么困難。其次，實時數倉的建設一定是伴隨著業務的發展而發展，武斷的認為實時數倉架構最符合當前公司的需求是不對的。實際情況中隨著業務的發展數倉的架構變得沒有那么非此即彼。最后，如何順暢的將傳統的離線數倉+實時鏈路處理流程升級到實時數倉架構是個很大的問題，畢竟中間涉及到很多的數據模式、技術中間件、計算引擎都不太一樣。
常見的數倉命名規則：
前綴（ODS/DWD/MID）+主題域（user/shp）+業務類型+自定義表名+后綴（dd/ds/pi）
7.問題
7.1維度建模的缺點
- 維度建模之前需要進行大量的數據預處理，因此會導致大量的數據處理工作（ETL）。
- 當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗余。
- 如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用于維度建模的方法。
維度建模的領域主要適用與數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的復雜關系的抽象方法。
當前公司的數倉模型架構：
首先對ETL得到的數據進行ER建模，關系建模，得到一個規范化的公司層面的數據倉庫模式。然后用這個中心倉數據庫為公司各部門建立基于維度建模的數據集市。
而維度建模都集中在各個DM層里面，也就是針對具體的業務線或者主題域，這樣緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。
7.2分層的誤區
數倉層內部的劃分不是為了分層而分層，分層是為了解決 ETL 任務及工作流的組織、數據的流向、讀寫權限的控制、不同需求的滿足等各類問題。
業界較為通行的做法將整個數倉層又劃分成了 dwd、dwb、dws、dim、mid 等等很多層。然而我們卻始終說不清楚這幾層之間清晰的界限是什么，或者說我們能說清楚它們之間的界限，復雜的業務場景卻令我們無法真正落地執行。
所以數據分層這塊一般來說三層是最基礎的：
至于DW層如何進行切分，是根據具體的業務需求和公司場景自己去定義，一般來說需要：
1、分層是解決數據流向和快速支撐業務的目的；
2、必須按照主題域和業務域進行貫穿；
3、層級之間不可逆向依賴。
4、如果依賴ODS層數據可以完成數據支撐，那么業務方直接使用落地層這也有利于快速、低成本地進行一些數據方面的探索和嘗試。
5、確定分層規范后，后續最好都遵循這個架構，約定成俗即可；
6、血緣關系、數據依賴、數據字典、數據命名規范等配套先行；
DW 內的分層沒有最正確的，只有最適合你的。
7.3寬表的誤區
在數倉層開始引入了寬表。所謂寬表，迄今為止并沒有一個明確的定義。通常做法是把很多的維度、事實上卷或者下鉆之后關聯到某一個事實表中，形成一張既包含了大量維度又包含了相關事實的表。
寬表的使用，有其一定的便利性。使用方不需要再去考慮跟維度表的關聯，也不需要了解維度表和事實表是什么東西。
但是隨著業務的增長，我們始終無法預見性地設計和定義寬表究竟該冗余多少維度，也無法清晰地定義出寬表冗余維度的底線在哪里。
一個可能存在的情況是，為了滿足使用上的需求，要不斷地將維表中已經存在的列增加到寬表中。這直接導致了寬表的表結構頻繁發生變動。
目前我們所采用的做法是：
1、根據主題域和業務域，將某個業務的所有節點梳理清楚；
2、將關鍵節點的數據作為事實表依據，然后橫向擴充其他事實表上卷數據（包含一些統計指標），同時縱向的添加該節點上一些主鍵對應的維度；
3、寬表的涉及不依賴具體的業務需求而是根據整體業務線相匹配；
4、盡量用維度建模代替寬表；
為什么說盡量用維度建模代替寬表，就算字段和數據會冗余，維度建模的方式也會表全量數據的寬表模式較好，原因：
1、維度建模是以某一個既定的事實為依據，既然是事實表，那么這塊的業務如果不變動的情況下，事實表的粒度基本不會改變；
2、事實表和維度表解耦，維度表的變更事實表基本不會影響，結果表也只需要回刷一下數據流程即可；
3、新增維度完全可以按照星型模型或者雪花模型動態添加新維度；
4、維度模型可以作為寬表的基礎，一旦確定全部的數據流程，可以通過維度模型再生成對應寬表進行快速的業務支撐；
7.4指標管理
數倉模型中，最重要的模塊可能就是數據治理，我們在建立數倉分層的時候，雖然解決 ETL 任務及工作流的組織、數據的流向、讀寫權限的控制、不同需求的滿足等各類問題，但是在給業務方提供不同數據需求的情況下不可避免的會發生一下幾個問題：
1、指標定義不夠清晰明確，兩個頁面上的指標定義其實是不同的，但是展示給商家看到的可能是同一個中文名稱。又或者同樣一個含義的指標在不同的界面上展示的名稱卻不相同，讓人產生歧義。
2、同一個指標因為由不同的數據開發同學來制作，可能會被重復開發，不但造成資源浪費，還會造成維護困難。
3、對于需要新開發的指標，不僅缺少開發工具簡化開發流程，甚至該使用哪些表，不該使用哪些表很大程度上都要憑借數據開發同學與數倉同學的經驗。如果稍微馬虎一點或者缺乏經驗，比如使用了某些業務域下特有的表或者不是由數倉提供的統一中間層的表就可能會使用錯誤的數據，造成后期返工等情況。
而且在數據需求越來越多，數據中臺提供的指標也日益豐富。但是指標定義混亂，描述不清會嚴重影響數據的可信度和數據開發的成本，所以就需要搭建一個指標系統，來維護已有的數據指標，并為未來可能新增的指標建立相應的規范。
8.如何去建立好這個指標庫或者指標系統呢。
一般來說指標系統主要分為：原子指標和派生指標
1、在數倉分層的時候，進行維度建模，那么就必須指定好相應的主題域和事實表處理的最小邏輯（也就是事實），那么在這個基礎上可以先定義原子指標。
原子指標：原子指標和度量含義相同，基于某一業務事件行為下的度量，是業務定義中不可再拆分的指標，具有明確業務含義的名詞 ，如支付金額。原子指標描述的其實是一種指標的類型，比如訂單支付金額，支付訂單數，下單訂單數，PV，UV 等等。但是僅僅一個原子指標是不能直接取數的。
但業務方更關心的指標，是有實際業務含義，可以直接取數據的指標。比如店鋪近1天訂單支付金額就是一個派生指標，會被直接在產品上展示給商家看。這個指標卻不能直接從數倉的統一中間層里取數（因為沒有現成的事實字段，數倉提供的一般都是大寬表）。需要有一個橋梁連接數倉中間層和業務方的指標需求，于是便有了派生指標。
2、派生指標=維度+原子指標+修飾詞。當維度，原子指標，修飾詞都確定的時候就可以唯一確定一個派生指標，同時給出具體數值。
例如：店鋪近1天訂單支付金額中店鋪是維度，近1天是一個時間類型的修飾詞，支付金額是一個原子指標。
業務方制作每一個派生指標都是通過選擇維度，原子指標，修飾詞三種元數據來定義的，相對于使用名稱來區別不同指標，更可以保證指標的唯一性。如果2個派生指標是不同的，那他們的組成部分一定會有區別，或是不同維度，或是不同原子指標，修飾詞。
所以在指標管理的過程中，指標庫給予每個指標一個精確且唯一的定義。通過指標庫可以快速且規范的查詢，開發和使用指標。
指標庫主要提供如下服務：
- 通過設置指標的組成要素來唯一精確定義每個指標（派生指標）。
- 通過指標在業務域內唯一的性質，解決指標重復定義，重復開發，部分數據對不上的問題。
- 通過將數倉中間層錄入指標庫為新制作指標提供指導性的 SQL 或庫表推薦。
- 打通其他各數據平臺：
- 打通數據開發平臺和統一數據服務平臺，為指標的定義，調度，在線使用提供一條龍服務，簡化開發流程。
- 打通數據資產管理平臺，沉淀指標的資產價值。
- 打通 BI 平臺，提供拖拽維度，指標生成報表的功能。
其中派生指標的生成是通過：業務域+維度+原子指標+修飾詞來唯一確定的。
在數倉搭建的時候，業務域、維度、原子指標都是已經明確的，而修飾詞是維度的某一些特殊的值，對應 SQL 中的 where 過濾條件。所以如果在數據產品的層面在某個業務域對指標數據定義、生產、使用等過程的流程規范化與平臺化，那么就能夠從源頭上解決上面出現的數據指標不統一、重復開發、指標體系不好維護的問題。
–end–
總結
- 上一篇： 观察者模式案例的简单分析
- 下一篇： 智能无人机课程用的是研扬TX2底板+TX