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