《數(shù)據(jù)倉庫知識體系》

38頁《數(shù)據(jù)倉庫知識體系.pdf》拿去面試用!

目錄

一、數(shù)據(jù)倉庫的8個(gè)發(fā)展階段

1.概念階段(1978-1988)

2.萌芽階段

3.集成階段

4.確立階段(1991)

5.數(shù)據(jù)集市(1994—1996)

6.爭吵與混亂(1996-1997)

7.合并(1998-2001)

8.未來

二、四種常見數(shù)據(jù)模型

1.為什么要進(jìn)行數(shù)據(jù)倉庫建模

2.四種常見模型

2.1維度模型

2.1.1星型模型

2.1.2雪花模型

2.1.3星座模型

2.2范式模型

2.3DataVault模型

2.4Anchor模型

3.數(shù)據(jù)模型的評價(jià)標(biāo)準(zhǔn)

三、三種事實(shí)表(設(shè)計(jì)原則，設(shè)計(jì)方法)

1.三種事實(shí)表概述

2.三種事實(shí)表對比

3.事實(shí)表設(shè)計(jì)8大原則

4.事實(shí)表設(shè)計(jì)方法

第一步：選擇業(yè)務(wù)過程及確定事實(shí)表類型

第二步：聲明粒度

第三步：確定維度

第四步：確定事實(shí)

四、多維體系結(jié)構(gòu)

1.總線架構(gòu)

2.一致性維度

3.一致性事實(shí)

4.小編有話

五、數(shù)據(jù)倉庫規(guī)范設(shè)計(jì)

1.為什么要進(jìn)行規(guī)范設(shè)計(jì)

2.設(shè)計(jì)規(guī)范-指標(biāo)

3.命名規(guī)范-表命名

3.1常規(guī)表

3.2中間表

3.3臨時(shí)表

3.4維度表

4.開發(fā)規(guī)范

5.流程規(guī)范

六、元數(shù)據(jù)管理

1.業(yè)務(wù)元數(shù)據(jù)

2.技術(shù)元數(shù)據(jù)

3.管理元數(shù)據(jù)

4.小編有話

七、維度表

1.什么是維度表

2.維度表設(shè)計(jì)原則

3.維度表設(shè)計(jì)方法

八、三范式與反范式

1.第一范式

2.第二范式

3.第三范式

4.反范式化

5.范式化設(shè)計(jì)和反范式化設(shè)計(jì)的優(yōu)缺點(diǎn)

5.1范式化（時(shí)間換空間）

5.2反范式化（空間換時(shí)間）

6.0LAP和OLTP中如何設(shè)計(jì)范式

九、數(shù)據(jù)倉庫架構(gòu)-Lambda和Kappa

1.Lambda架構(gòu)原理

2.Lambda架構(gòu)的缺點(diǎn)

3.Kappa架構(gòu)原理

4.Lambda架構(gòu)和Kappa架構(gòu)優(yōu)缺點(diǎn)對比

5.數(shù)據(jù)架構(gòu)評價(jià)標(biāo)準(zhǔn)

6.小編有話

十、數(shù)據(jù)治理（目的、方法、流程）

1.什么是數(shù)據(jù)治理

2.數(shù)據(jù)治理的目的

3.數(shù)據(jù)治理的方法

4.數(shù)據(jù)質(zhì)量8個(gè)衡量標(biāo)準(zhǔn)

5.數(shù)據(jù)治理流程

H-一、ETL

1.什么是ETL

2.ETL&ELT

3.常用的ETL工具

3.1sqoop

3.2DataX

3.3Kettle

3.4canal

十二、數(shù)據(jù)應(yīng)用-OLAP

1.OLAP和OLTP的區(qū)別

2.OLAP分類

3.OLAP基本操作

4.OLAP選型

十三、數(shù)據(jù)傾斜

1.數(shù)據(jù)傾斜表現(xiàn)

1.1hadoop中的數(shù)據(jù)傾斜表現(xiàn)

1.2hive中數(shù)據(jù)傾斜

1.3Spark中的數(shù)據(jù)傾斜

2.數(shù)據(jù)傾斜產(chǎn)生原因

3.解決數(shù)據(jù)傾斜思路

2.1業(yè)務(wù)邏輯

2.2程序?qū)用?/p>

2.3調(diào)參方面

2.4從業(yè)務(wù)和數(shù)據(jù)上解決

數(shù)據(jù)倉庫的8個(gè)發(fā)展階段

1、概念階段(1978-1988)

數(shù)據(jù)倉庫最早的概念可以追溯到20世紀(jì)70年代MIT的一項(xiàng)研究，

該研究致力于開發(fā)一種優(yōu)化的技術(shù)架構(gòu)并提出這些架構(gòu)的指導(dǎo)性意見。

第一次，MH■的研究員將業(yè)務(wù)系統(tǒng)和分析系統(tǒng)分開，將業(yè)務(wù)處理和分

析處理分成不同的層次，并采用單獨(dú)的數(shù)據(jù)存儲(chǔ)和完全不同的設(shè)計(jì)準(zhǔn)則。

同時(shí)，MIT的研究成果與80年代提出的信息中心(Informationcenter)

相吻合：即把那些新出現(xiàn)的、不可以預(yù)測的、但是大量存在的分析型的負(fù)

載從業(yè)務(wù)處理系統(tǒng)中剝離出來。

但是限于當(dāng)時(shí)的信息處理和數(shù)據(jù)存儲(chǔ)能力，該研究只是確立了一個(gè)論

點(diǎn)：這兩種信息處理的方式差別如此之大，以至于它們只能采用完全不同

的架構(gòu)和設(shè)計(jì)方法。

2、萌芽階段

在80年代中后期，作為當(dāng)時(shí)技術(shù)最先進(jìn)的公司,DEC已經(jīng)開始采用分

布式網(wǎng)絡(luò)架構(gòu)來支持其業(yè)務(wù)應(yīng)用，并且DEC公司首先將業(yè)務(wù)系統(tǒng)移植到

其自身的RDBMS產(chǎn)品：RdB,并且，DEC公司從工程部、銷售部、財(cái)

務(wù)部以及信息技術(shù)部抽調(diào)了不同的人員組建了新的小組，不僅研究新的分

析系統(tǒng)架構(gòu)，并要求將其應(yīng)用到其全球的財(cái)務(wù)系統(tǒng)中。該小組結(jié)合MIT的

研究結(jié)論，建立了TA2(TechnicalArchitecture2)規(guī)范，該規(guī)范定義了

分析系統(tǒng)的四個(gè)組成部分：

?數(shù)據(jù)獲取

?數(shù)據(jù)訪問

?目錄

?用戶服務(wù)

其中的數(shù)據(jù)獲取和數(shù)據(jù)訪問目前大家都很清楚，而目錄服務(wù)是用于幫

助用戶在網(wǎng)絡(luò)中找到他們想要的信息，類似于業(yè)務(wù)元數(shù)據(jù)管理；用戶服務(wù)

用以支持對數(shù)據(jù)的直接交互，包含了其他服務(wù)的所有人機(jī)交互界面，這是

系統(tǒng)架構(gòu)的一個(gè)非常大的轉(zhuǎn)變，第一次將交互界面作為單獨(dú)的組件提出

來。

3、集成階段

全企業(yè)集成(Enterpriselntergration,1988)同時(shí)，IBM也在處理信

息管理不同方面的問題，其最煩人的問題是不斷增加的信息孤島，舊M的

很多客戶要面對很多分立系統(tǒng)的數(shù)據(jù)集成問題，而這些系統(tǒng)有不同的編碼

方式和數(shù)據(jù)格式。

1988年，為解決全企業(yè)集成問題，舊M愛爾蘭公司的BarryDevlin和

PaulMurphy第一次提出了"信息倉庫(Informationwarehouse)"的概

念，將其定義為：“一個(gè)結(jié)構(gòu)化的環(huán)境，能支持最終用戶管理其全部的業(yè)

務(wù)，并支持信息技術(shù)部門保證數(shù)據(jù)質(zhì)量”，并在1991年在DECTA2的基

礎(chǔ)上把信息倉庫的概念包含進(jìn)去，并稱之為VITAL規(guī)范，將PC、圖形化

界面、面向?qū)ο蟮慕M件以及局域網(wǎng)都包含在VITAL里，并定義了85種信

息倉庫的組件，包括數(shù)據(jù)抽取、轉(zhuǎn)換、有效性驗(yàn)證、加載、Cube開發(fā)和

圖形化查詢工具等。但是舊M只是將這種領(lǐng)先的概念用于市場宣傳，而沒

有付諸實(shí)際的架構(gòu)設(shè)計(jì)。這是舊M有一個(gè)領(lǐng)域上創(chuàng)新后停止不前導(dǎo)致喪失

其領(lǐng)先地位。因此，在90年代初期，數(shù)據(jù)倉庫的基本原理、框架架構(gòu)，

以及分析系統(tǒng)的主要原則都已經(jīng)確定，主要的技術(shù)，包括關(guān)系型數(shù)據(jù)存

取、網(wǎng)絡(luò)、C/S架構(gòu)和圖形化界面均已具備，只欠東風(fēng)了。

同時(shí)?，在1988年—1991年，一些前沿的公司已經(jīng)開始建立數(shù)據(jù)倉

庫。

、確立階段(1991)

企業(yè)級數(shù)據(jù)倉庫(EDW,1991)1991年，Billlnmon出版了其有關(guān)

數(shù)據(jù)倉庫的第一本書，這本書不僅僅說明為什么要建數(shù)據(jù)倉庫、數(shù)據(jù)倉庫

能給你帶來什么，更重要的是，Inmon第一次提供了如何建設(shè)數(shù)據(jù)倉庫的

指導(dǎo)性意見，該書定義了數(shù)據(jù)倉庫非常具體的原則，包括：數(shù)據(jù)倉庫是面

向主題的(Subject-Oriented)、集成的(Integrated)、包含歷史的

(Time-variant)、相對穩(wěn)定的(Nonvolatile)、面向決策支持的

(DecisionSupport)面向全企業(yè)的(EnterpriseScope)最明細(xì)的數(shù)據(jù)存

(AtomicDetail)數(shù)據(jù)快照式的數(shù)據(jù)獲取(SnapShotCapture)這些原則

到現(xiàn)在仍然是指導(dǎo)數(shù)據(jù)倉庫建設(shè)的最基本原則，雖然中間的一些原則引發(fā)

一些爭論，并導(dǎo)致一些分歧和數(shù)據(jù)倉庫變體的產(chǎn)生。

Billlnmon憑借其這本書奠定了其在數(shù)據(jù)倉庫建設(shè)的位置，被稱之為

“數(shù)據(jù)倉庫之父”。

5、數(shù)據(jù)集市(1994—1996)

數(shù)據(jù)倉庫發(fā)展的第一明顯分歧是數(shù)據(jù)集市概念的產(chǎn)生。由于企業(yè)級數(shù)

據(jù)倉庫的設(shè)計(jì)、實(shí)施很困難，使得最早吃數(shù)據(jù)倉庫螃蟹的公司遭到大面積

的失敗，因此數(shù)據(jù)倉庫的建設(shè)者和分析師開始考慮只建設(shè)企業(yè)級數(shù)據(jù)倉庫

的一部分，然后再逐步添加，但是這有背于Billlnmon的原則：各個(gè)實(shí)施

部分的數(shù)據(jù)抽取、清洗、轉(zhuǎn)換和加載是獨(dú)立，導(dǎo)致了數(shù)據(jù)的混亂與不一致

性。而且部分實(shí)施的項(xiàng)目也有很多失敗，除了常見的業(yè)務(wù)需求定義不清、

項(xiàng)目執(zhí)行不力之外，很重要的原因是因?yàn)槠鋽?shù)據(jù)模型設(shè)計(jì)，在企業(yè)級數(shù)據(jù)

倉庫中，Inmon推薦采用3范式進(jìn)行數(shù)據(jù)建模，但是不排除其他的方法，

但是Inmon的追隨者固守OLTP系統(tǒng)的3范式設(shè)計(jì)，從而無法支持DSS

系統(tǒng)的性能和數(shù)據(jù)易訪問性的要求。

這時(shí)，RalphKimball出現(xiàn)了，他的第一本書

“TheDataWarehouseToolkit”掀起了數(shù)據(jù)集市的狂潮，這本書提供了如

何為分析進(jìn)行數(shù)據(jù)模型優(yōu)化詳細(xì)指導(dǎo)意見，從DimensionalModeling大行

其道，也為傳統(tǒng)的關(guān)系型數(shù)據(jù)模型和多維OLAP之間建立了很好的橋梁。

從此，數(shù)據(jù)集市在很多地方冒了出來，并獲得很大成功，而企業(yè)級數(shù)據(jù)倉

庫已逐漸被人所淡忘。

5、爭吵與混亂(1996-1997)

企業(yè)級數(shù)據(jù)倉庫還是部門級數(shù)據(jù)集市？關(guān)系型還是多維？Billlnmon

和RalphKimball一開始就爭論不休，其各自的追隨者也唇舌相向，形成

相對立的兩派：Inmon派和Kimball派(有點(diǎn)象少林和武當(dāng)，呵呵)。

在初期，數(shù)據(jù)集市的快速實(shí)施和較高的成功率讓Kimball派占了上

風(fēng)，但是很快，他們也發(fā)現(xiàn)自己陷入了某種困境：企業(yè)中存在6—7個(gè)不

同的數(shù)據(jù)集市，分別有不同的ETL,相互之間的數(shù)據(jù)也不完全一致。同

時(shí)，各個(gè)項(xiàng)目實(shí)施中也任意侵犯了Inmon開始定下的準(zhǔn)則：把數(shù)據(jù)集市當(dāng)

成眾多OLTP系統(tǒng)之后的有一個(gè)系統(tǒng)，而不是一個(gè)基礎(chǔ)性的集成性的東

西，為保證數(shù)據(jù)的準(zhǔn)確性和實(shí)時(shí)性，有的甚至可以由OLTP系統(tǒng)直接修改

數(shù)據(jù)集市里面的數(shù)據(jù)，為了保證系統(tǒng)的性能，有的數(shù)據(jù)集市刪除了歷史數(shù)

據(jù)。等等，不一而足。

當(dāng)然，這導(dǎo)致了一些新的應(yīng)用的出現(xiàn)，例如ODS,但是人們對

DataWarehouse、DataMart、ODS的概念非常的模糊，經(jīng)?；鞛橐徽?。

有人說OLAP就是數(shù)據(jù)倉庫，也有人說我要ODS和DataMart,不要

Datawarehouse,也有人說，我DataMart建多了，自然就有

DatawarehouseTo但是Billlnmon一直很旗幟鮮明：“你可以打到幾萬

噸的小魚小蝦，但是這些小魚小蝦加起來不是大鯨魚”。

卜、合并(1998—2001)

經(jīng)過多翻爭吵，證明one-size-fits-all是不可能的，你需要不同的BI

架構(gòu)來滿足不同的業(yè)務(wù)需求。Billlnmon也推出了新的BI架構(gòu)CIF

(Corporationinformationfactory),把Kimball的數(shù)據(jù)集市也包容進(jìn)來

了，第一次，Kimball承認(rèn)了Inmon,但是仍然還有很多人在爭論是自頂

向下，還是自底向上。

8、未來

未來幾個(gè)方向：時(shí)效性方向的實(shí)時(shí)數(shù)倉；數(shù)據(jù)質(zhì)量方向的數(shù)據(jù)治理；數(shù)據(jù)

中臺、數(shù)據(jù)湖(歡迎留言討論！)

推薦閱讀：

數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)平臺、數(shù)據(jù)中臺、數(shù)據(jù)湖到底是什么？

二、四種常見數(shù)據(jù)模型

大數(shù)據(jù)時(shí)代，維度建模已成為各大廠的主流方式。

維度建模從分析決策的需求出發(fā)構(gòu)建模型，為分析需求服務(wù)。重點(diǎn)關(guān)

注用戶如何快速的完成數(shù)據(jù)分析，可以直觀的反應(yīng)業(yè)務(wù)模型中的業(yè)務(wù)問

題，需要大量的數(shù)據(jù)預(yù)處理、數(shù)據(jù)冗余，有較好的大規(guī)模復(fù)雜查詢的響應(yīng)

性能。

1、為什么要進(jìn)行數(shù)據(jù)倉庫建模

?性能：良好的模型能幫我們快速查詢需要的數(shù)據(jù)，減少數(shù)據(jù)的10吞吐

?成本：減少數(shù)據(jù)冗余、計(jì)算結(jié)果復(fù)用、從而降低存儲(chǔ)和計(jì)算成本

?效率：改善用戶使用數(shù)據(jù)的體驗(yàn)，提高使用數(shù)據(jù)的效率

?改善統(tǒng)計(jì)口徑的不一致性，減少數(shù)據(jù)計(jì)算錯(cuò)誤的可能性

2、四種常見模型

2.1維度模型

維度建模按數(shù)據(jù)組織類型劃分可分為星型模型、雪花模型、星座模

型。

Kimball老爺爺維度建模四部曲：

選擇業(yè)務(wù)處理過程>定義粒度>選擇維度>確定事實(shí)

2.1.1星型模型

星型模型主要是維表和事實(shí)表，以事實(shí)表為中心,所有維度直接關(guān)聯(lián)

在事實(shí)表上，呈星型分布。

location

locationkey

street

city

state_or_province

coimtry

2.1.2雪花模型

雪花模型，在星型模型的基礎(chǔ)上，維度表上又關(guān)聯(lián)了其他維度表。這

種模型維護(hù)成本高，性能方面也較差，所以一般不建議使用。尤其是基于

hadoop體系構(gòu)建數(shù)倉，減少join就是減少shuffle,性能差距會(huì)很大。

星型模型可以理解為，一個(gè)事實(shí)表關(guān)聯(lián)多個(gè)維度表，雪花模型可以理

解為一個(gè)事實(shí)表關(guān)聯(lián)多個(gè)維度表，維度表再關(guān)聯(lián)維度表。

「ime|

item\ShippingFactTable

itemkev

SalesFactTableitemnametimekey

brand

itemkey

type

supplier_typeshipperkey

fromlocation

branchlocationtolocation

branch_key

■location_keydollarscost

branch_name

street

branchtypeunitsshipped

city

province_or__state

country|shipper|/

Measures

2.1.3星座模型

星座模型，是對星型模型的擴(kuò)展延伸，多張事實(shí)表共享維度表。

星座模型是很多數(shù)據(jù)倉庫的常態(tài)，因?yàn)楹芏鄶?shù)據(jù)倉庫都是多個(gè)事實(shí)表

的。所以星座模型只反映是否有多個(gè)事實(shí)表，他們之間是否共享一些維度

表。

item\ShippingFactTable

item_key

SalesFactTableitemnainetimekey

brand

typeitem_key

suppiier_typeshipperkey

i-------------------------------------

fi,omlocation

branchlocationtolocation

branch_kev

location_keydollarscost

branchname

street

unitsshipped

branch_typecity

province_or_state

countryshipper/

-----------

Measuresshipper_key

shipper_naine

2.2范式模型

即實(shí)體關(guān)系（ER）模型，數(shù)據(jù)倉庫之父Immon提出的，從全企業(yè)的

高度設(shè)計(jì)一個(gè)3NF模型，用實(shí)體加關(guān)系描述的數(shù)據(jù)模型描述企業(yè)業(yè)務(wù)架

構(gòu)，在范式理論上符合3NF。此建模方法，對建模人員的能力要求非常

高。

特點(diǎn)：設(shè)計(jì)思路自上而下，適合上游基礎(chǔ)數(shù)據(jù)存儲(chǔ)，同一份數(shù)據(jù)只存

儲(chǔ)一份，沒有數(shù)據(jù)冗余，方便解耦，易維護(hù)，缺點(diǎn)是開發(fā)周期一般比較

長，維護(hù)成本高。

詳見后文：三范式與反范式

2.3DataVault模型

DataVault由Hub（關(guān)鍵核心業(yè)務(wù)實(shí)體）、Link（關(guān)系）、Satellite

（實(shí)體屬性）三部分組成，是DanLinstedt發(fā)起創(chuàng)建的一種模型方法論，

它是在ER關(guān)系模型上的衍生，同時(shí)設(shè)計(jì)的出發(fā)點(diǎn)也是為了實(shí)現(xiàn)數(shù)據(jù)的整

合，并非為數(shù)據(jù)決策分析直接使用。

2.4Anchor模型

高度可擴(kuò)展的模型，所有的擴(kuò)展只是添加而不是修改，因此它將模型

規(guī)范到6NF,基本變成了K-V結(jié)構(gòu)模型。企業(yè)很少使用。

3、數(shù)據(jù)模型的評價(jià)標(biāo)準(zhǔn)

數(shù)據(jù)模型建設(shè)的怎么樣，極度依賴規(guī)范設(shè)計(jì)，如果代碼風(fēng)格是“千人

千面”，那么恐怕半年下來，業(yè)務(wù)系統(tǒng)就沒法看了。沒有什么比“數(shù)據(jù)系

統(tǒng)”更看重，，法制，，了，規(guī)范體系不僅能保障數(shù)據(jù)建設(shè)的一致性，也能夠應(yīng)

對業(yè)務(wù)交接的情況，更能夠?yàn)樽詣?dòng)化奠定基礎(chǔ)。

1.業(yè)務(wù)過程清晰：ODS就是原始信息，不修改；DWD面向基礎(chǔ)業(yè)務(wù)過程；

DIM描述維度信息；DWS針對最小場景做指標(biāo)計(jì)算；ADS也要分層，面

向跨域的建設(shè)，和面向應(yīng)用的建設(shè)；

2.指標(biāo)可理解：按照一定業(yè)務(wù)事務(wù)過程進(jìn)行業(yè)務(wù)劃分，明細(xì)層粒度明確、歷

史數(shù)據(jù)可獲取，匯總層維度和指標(biāo)同名同義，能客觀反映業(yè)務(wù)不同角度下

的量化程度；

3.核心模型相對穩(wěn)定：如果業(yè)務(wù)過程運(yùn)行的比較久，過程相對固定，就要盡

快下沉到公共層，形成可復(fù)用的核心模型；

4.高內(nèi)聚低耦合：各主題內(nèi)數(shù)據(jù)模型要業(yè)務(wù)高內(nèi)聚，避免在一個(gè)模型耦合其

他業(yè)務(wù)的指標(biāo)，造成該模型主題不清晰和性價(jià)比低。

小編有話

?在傳統(tǒng)企業(yè)數(shù)倉中，業(yè)務(wù)相對穩(wěn)定，以范式建模為主。如電信、金融行業(yè)

等

?在互聯(lián)網(wǎng)公司，業(yè)務(wù)變化快，需求來來回回的改，計(jì)算和存儲(chǔ)也不是問

題，我們更關(guān)心快速便捷的滿足業(yè)務(wù)需求，所以以維度建模為主。

三、三種事實(shí)表

事實(shí)表作為數(shù)據(jù)倉庫維度建模的核心，緊緊圍繞著業(yè)務(wù)過程來設(shè)計(jì)，

通過獲取描述業(yè)務(wù)過程的度量來表達(dá)業(yè)務(wù)過程，包含了引用的維度和與業(yè)

務(wù)過程有關(guān)的度量。

1、三種事實(shí)表概述

事實(shí)表有三種類型：事務(wù)事實(shí)表、周期快照事實(shí)表和累積快照事實(shí)表。

?1.1事務(wù)事實(shí)表

也稱原子事實(shí)表，描述業(yè)務(wù)過程，跟蹤控件或時(shí)間上某點(diǎn)的度量事

件，保存的是最原子的數(shù)據(jù)；

個(gè)人理解：類似于mysqlbinlog日志，每一次相關(guān)的change都記

錄下來，生成一行新的數(shù)據(jù)

?1.2周期快照事實(shí)表

以一個(gè)周期為時(shí)間間隔，來記錄事實(shí)，一般周期可以是每天、每周、

每月、每年等；

個(gè)人理解：只看某個(gè)業(yè)務(wù)過程，比如訂單收貨，數(shù)據(jù)按訂單收貨時(shí)間

來切分，周期可以為每天、每月等。

?1.3累積快照事實(shí)

用來描述過程開始和結(jié)束之間的關(guān)鍵步驟事件，覆蓋過程的整個(gè)生命

周期，通常具有多個(gè)日期字段來記錄關(guān)鍵時(shí)間點(diǎn)；當(dāng)過程隨著生命周期不

斷變化時(shí)，記錄也會(huì)隨著過程的變化而被修改；

個(gè)人理解：要看整個(gè)生命周期的多個(gè)業(yè)務(wù)過程，比如：創(chuàng)建訂單一

買家付款一賣家發(fā)貨一買家確認(rèn)收貨。粒度是一個(gè)訂單一行數(shù)據(jù)，創(chuàng)建

訂單時(shí)間，付款時(shí)間，發(fā)貨時(shí)間，收貨時(shí)間，分別作為一個(gè)字段，便于計(jì)

算不同業(yè)務(wù)過程的時(shí)間間隔。

2、三種事實(shí)表對比

事務(wù)事實(shí)表周期快照事實(shí)表累積快照事實(shí)表

時(shí)期/以有規(guī)律的、可預(yù)測用于時(shí)間跨度不確定

時(shí)間離散事務(wù)時(shí)間點(diǎn)的的不斷變化的工作流

日期相關(guān)業(yè)務(wù)過程涉及的

維度事務(wù)日期快照日期多個(gè)日期

每行代表實(shí)體的一個(gè)每行代表某時(shí)間周期每行代表一個(gè)實(shí)體的

粒度事務(wù)的一個(gè)實(shí)體生命周期

相關(guān)業(yè)務(wù)過程事實(shí)和

事實(shí)事務(wù)事實(shí)累積事實(shí)時(shí)間間隔事實(shí)

事實(shí)

表加

載插入插入插入與更新

事實(shí)

表更

新不更新不更新業(yè)務(wù)過程變更時(shí)更新

3、事實(shí)表設(shè)計(jì)8大原則

?原則1：盡可能包含所有與業(yè)務(wù)過程相關(guān)的事實(shí)

■分析哪些事實(shí)與業(yè)務(wù)過程相關(guān)，是設(shè)計(jì)過程中非常重要的關(guān)注點(diǎn)；

■在事實(shí)表中，盡量包含所有與業(yè)務(wù)過程相關(guān)的事實(shí)，即使存在冗余,

由于事實(shí)通常是數(shù)字型，存儲(chǔ)開銷不會(huì)太大；

?原則2:只選擇與業(yè)務(wù)過程相關(guān)的事實(shí)

■如，訂單的下單這個(gè)業(yè)務(wù)過程，事實(shí)表中不應(yīng)該存在支付金額這個(gè)表

示支付業(yè)務(wù)過程的事實(shí)；

?原則3:分解不可加性事實(shí)為可加的組件

■如，訂單的優(yōu)惠率，應(yīng)分解為訂單原價(jià)金額與訂單優(yōu)惠金額兩個(gè)事實(shí)

存儲(chǔ)在事實(shí)表中；

?原則4:在選擇維度和事實(shí)之前必須先聲明粒度

■因?yàn)樵恿６忍峁┝俗畲笙薅鹊撵`活性，可以支持無法預(yù)期的各種細(xì)

節(jié)層次的用戶需求；

■粒度用于確定事實(shí)表中一行所表示業(yè)務(wù)的細(xì)節(jié)層次，決定了維度模型

的擴(kuò)展性；

■每個(gè)維度和事實(shí)必須與所定義的粒度保持一致；

■設(shè)計(jì)事實(shí)表時(shí)，粒度定義越細(xì)越好，一般從最低級別的原子粒度開

始；

?原則5:在同一個(gè)事實(shí)表中不能有多種不同粒度的事實(shí)

■粒度為票一級；（實(shí)際業(yè)務(wù)中，一個(gè)訂單可以同時(shí)支付多張票）

■票支付金額和票折扣金額，兩個(gè)事實(shí)的粒度為"票級"，與定義的粒度

一致；

?訂單支付金額和訂單票數(shù)，兩個(gè)事實(shí)的粒度為“訂單級"，屬于上一層

訂單級數(shù)據(jù)，與"票級"事實(shí)表的粒度不一致，且不能進(jìn)行匯總；

■如果，以訂單金額和訂單票數(shù)這兩個(gè)維度匯總總金額和總票數(shù)，會(huì)造

成大量的重復(fù)計(jì)算；

■疑問：怎么判斷不同事實(shí)的粒度是否相同？

?原則6:事實(shí)的單位要保持一致

■如，訂單金額、訂單優(yōu)惠金額、訂單運(yùn)費(fèi)這3個(gè)事實(shí)，應(yīng)該采用統(tǒng)一

的計(jì)量單位，統(tǒng)一為元或者分，以方便使用；

?原則7:對事實(shí)的null值要處理

■原因：在數(shù)據(jù)庫中，null值對常用數(shù)字型字段的SQL過濾條件都不

生效；如，大于、小于、等于、大于或等于、小于或等于；

?處理：用0代替null;

?原則8:使用退化維度提高事實(shí)表的易用性

■易用性：對事實(shí)表，更較少關(guān)聯(lián)操作、過濾查詢、控制聚合層次、排

序數(shù)據(jù)、定義主從關(guān)系等；

1.事實(shí)表中存儲(chǔ)各種類型的常用維度信息，較少下游用戶使用時(shí)關(guān)聯(lián)多

個(gè)表的操作；

2.通過退化維度，可以實(shí)現(xiàn)對事實(shí)表的過濾查詢、控制聚合層次、排序

數(shù)據(jù)、定義主從關(guān)系等；

?在Kimball的維度建模中，通常按照星形模型的方式設(shè)計(jì),通過事實(shí)表的

外鍵關(guān)聯(lián)專門的維表，這種方式來獲取維度，謹(jǐn)慎使用退化維表；這與大

數(shù)據(jù)領(lǐng)域的事實(shí)表設(shè)計(jì)不一樣；

■思路：通過增加冗余存儲(chǔ)，減少計(jì)算開銷，提高使用效率；

、事實(shí)表設(shè)計(jì)方法

Kimball的維度模型設(shè)計(jì)4步法：選擇業(yè)務(wù)過程、聲明粒度、確定維

度、確定事實(shí)；

當(dāng)前的互聯(lián)網(wǎng)大數(shù)據(jù)環(huán)境，維度模型的設(shè)計(jì)，是基于Kimball的四步

維度建模方法進(jìn)行了更進(jìn)一步的改進(jìn)：

?第一步：選擇業(yè)務(wù)過程及確定事實(shí)表類型

■如淘寶的一個(gè)交易訂單，選擇"買家付款”這個(gè)業(yè)務(wù)過程，則事實(shí)表類

型應(yīng)為只包含買家付款這一個(gè)業(yè)務(wù)過程的“單事務(wù)事實(shí)表"；

■如選擇了所有4個(gè)業(yè)務(wù)過程，并且需要分享各業(yè)務(wù)過程的時(shí)間間隔，

則事實(shí)表類型應(yīng)為包含了所有4個(gè)業(yè)務(wù)過程的“累積快照事實(shí)表”；

?如是選擇“買家付款”這個(gè)業(yè)務(wù)過程，還是選擇“創(chuàng)建訂單"和"買家付

款”這兩個(gè)業(yè)務(wù)過程，具體根據(jù)業(yè)務(wù)情況來定；

?思路：詳細(xì)分析需求，對業(yè)務(wù)的整個(gè)生命周期進(jìn)行分析，明確關(guān)鍵的

業(yè)務(wù)步驟，從而選擇與需求有關(guān)的業(yè)務(wù)過程；

-以實(shí)例說明：如何選擇業(yè)務(wù)過程？如何確定事實(shí)表類型？

1.分析業(yè)務(wù)的生命周期，業(yè)務(wù)過程通常使用行為動(dòng)詞表示業(yè)務(wù)執(zhí)行的活

動(dòng)；

2.明確關(guān)鍵的業(yè)務(wù)步驟：該訂單流轉(zhuǎn)的業(yè)務(wù)過程有4個(gè)：創(chuàng)建訂單一

買家付款一賣家發(fā)貨一買家確認(rèn)收貨；

3.根據(jù)業(yè)務(wù)需求，選擇與維度建模有關(guān)的業(yè)務(wù)過程；

4.根據(jù)所選的業(yè)務(wù)過程確定事實(shí)表類型；

?第二步：聲明粒度

■粒度的作用：

■粒度的選擇：盡量選擇最細(xì)級別的原子粒度，以確保事實(shí)表的應(yīng)用具

有最大的靈活性；

1.靈活性：支持無法預(yù)期的各種細(xì)節(jié)層次的用戶需求；

2.對于訂單級別，粒度可以定義為最細(xì)的訂單級別；（如，父子訂單，

事實(shí)表的粒度可以定"子訂單級別"；）

3.粒度的聲明，意味著精確定義事實(shí)表的每一行所表示的業(yè)務(wù)含義；

4.明確的粒度能夠確保對實(shí)表中行的意思的理解不會(huì)產(chǎn)生混淆，保證所

有的事實(shí)按照同樣的細(xì)節(jié)層次記錄；

?第三步：確定維度

■如，淘寶訂單"付款事務(wù)事實(shí)表”中，粒度為"子訂單"，相關(guān)的維度有

買家、賣家、商品、收貨人信息、業(yè)務(wù)類型、訂單時(shí)間等；

■完成了粒度聲明，就意味著確定了主鍵，對應(yīng)的維度組合以及相關(guān)的

維度字段也可以確定了；

■選擇維度的原則：應(yīng)該選擇能夠描述清楚業(yè)務(wù)過程所處的環(huán)境的維度

信息；

?第四步：確定事實(shí)

■確定原則：選擇與業(yè)務(wù)過程有關(guān)的所有事實(shí)，且事實(shí)的粒度要與所聲

明的事實(shí)表的粒度一致；

■思路：可以通過回答"過程的度量是什么"來確定；

■注意：將不可加性事實(shí)分解為可加的組件；（分解的原則：可以通過

分解后的可加的屬性值，計(jì)算得到不可加性事實(shí)）

掃描二維碼獲取

更多精彩

四、多維體系結(jié)構(gòu)

在Kimball的維度建模的數(shù)據(jù)倉庫中，關(guān)于多維體系結(jié)構(gòu)(MD)有

三個(gè)關(guān)鍵性概念：總線架構(gòu)(BusArchitecture),

(ConformedDimension)和一致性事實(shí)(ConfomiedFact)。

1、總線架構(gòu)

多維體系結(jié)構(gòu)(總線架構(gòu))數(shù)據(jù)倉庫領(lǐng)域里，有一種構(gòu)建數(shù)據(jù)倉庫的架

構(gòu)，叫MultidimensionalArchitecture(MD),中文一般翻譯為“多維體系

結(jié)構(gòu)”,也稱為“總線架構(gòu)”(BusArchitecture)?

多維體系結(jié)構(gòu)的創(chuàng)始人是數(shù)據(jù)倉庫領(lǐng)域中最有實(shí)踐經(jīng)驗(yàn)的Kimball博

士。多維體系結(jié)構(gòu)主要包括后臺(BackRoom)和前臺(FrontRoom)兩

部分。后臺也稱為數(shù)據(jù)準(zhǔn)備區(qū)(StagingArea),是MD架構(gòu)的最為核心

的部件。在后臺，是一致性維度的產(chǎn)生、保存和分發(fā)的場所。同時(shí)，代理

鍵也在后臺產(chǎn)生。前臺是MD架構(gòu)對外的接口，包括兩種主要的數(shù)據(jù)集

市，一種是原子數(shù)據(jù)集市，另一種是聚集數(shù)據(jù)集市。

原子數(shù)據(jù)集市保存著最低粒度的細(xì)節(jié)數(shù)據(jù)，數(shù)據(jù)以星型結(jié)構(gòu)來進(jìn)行數(shù)

據(jù)存儲(chǔ)。聚集數(shù)據(jù)集市的粒度通常比原子數(shù)據(jù)集市要高，和原子數(shù)據(jù)集市

一樣，聚集數(shù)據(jù)集市也是以星型結(jié)構(gòu)來進(jìn)行數(shù)據(jù)存儲(chǔ)前臺還包括像查詢

管理、活動(dòng)監(jiān)控等為了提供數(shù)據(jù)倉庫的性能和質(zhì)量的服務(wù)。在多維體系結(jié)

構(gòu)中，所有的這些基于星型機(jī)構(gòu)來建立的數(shù)據(jù)集市可以在物理上存在于一

個(gè)數(shù)據(jù)庫實(shí)例中，也可以分散在不同的機(jī)器上，而所有這些數(shù)據(jù)集市的集

合組成的分布式的數(shù)據(jù)倉庫。

公共維度

業(yè)務(wù)過程

提出購買訂單XXX

接收倉庫存貨XXXX

倉庫庫存XXX

接收商店存貨XXXXX

商店庫存XXX

零售XXXXXX

零售預(yù)測XXX

零售促銷跟蹤XXXX

客戶退貨XXXXXX

退貨至供應(yīng)商XXXX

?？妥訶XXX

圖4-10零售商的企業(yè)數(shù)據(jù)倉庫總線矩陣示例

致性維度

在多維體系結(jié)構(gòu)中，沒有物理上的數(shù)據(jù)倉庫，由物理上的數(shù)據(jù)集市組

合成邏輯上的數(shù)據(jù)倉庫。而且數(shù)據(jù)集市的建立是可以逐步完成的，最終組

合在一起，成為一個(gè)數(shù)據(jù)倉庫。如果分步建立數(shù)據(jù)集市的過程出現(xiàn)了問

題，數(shù)據(jù)集市就會(huì)變成孤立的集市，不能組合成數(shù)據(jù)倉庫，而一致性維度

的提出正式為了解決這個(gè)問題。

一致性維度的范圍是總線架構(gòu)中的維度，即可能會(huì)在多個(gè)數(shù)據(jù)集市中

都存在的維度，這個(gè)范圍的選取需要架構(gòu)師來決定。一致性維度的內(nèi)容和

普通維度并沒有本質(zhì)上區(qū)別，都是經(jīng)過數(shù)據(jù)清洗和整合后的結(jié)果。一致性

維度建立的地點(diǎn)是多維體系結(jié)構(gòu)的后臺(BackRoom),即數(shù)據(jù)準(zhǔn)備區(qū)。

在多維體系結(jié)構(gòu)的數(shù)據(jù)倉庫項(xiàng)目組內(nèi)需要有專門的維度設(shè)計(jì)師，他的

職責(zé)就是建立維度和維護(hù)維度的一致性。在后臺建立好的維度同步復(fù)制到

各個(gè)數(shù)據(jù)集市。這樣所有數(shù)據(jù)集市的這部分維度都是完全相同的。建立新

的數(shù)據(jù)集市時(shí).，需要在后臺進(jìn)行一致性維度處理，根據(jù)情況來決定是否新

增和修改一致性維度，然后同步復(fù)制到各個(gè)數(shù)據(jù)集市。這是不同數(shù)據(jù)集市

維度保持一致的要點(diǎn)。

在同一個(gè)集市內(nèi)，一致性維度的意思是兩個(gè)維度如果有關(guān)系，要么就

是完全一樣的，要么就是一個(gè)維度在數(shù)學(xué)意義上是另一個(gè)維度的子集。

例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完

全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維

度就可以是日期維度的子集，在后續(xù)鉆取等操作時(shí)可以保持一致。如果維

度表中的數(shù)據(jù)量較大，出于效率的考慮，應(yīng)該建立物化視圖或者實(shí)際的物

理表。這樣，維度保持一致后，事實(shí)就可以保存在各個(gè)數(shù)據(jù)集市中。雖然

在物理上是獨(dú)立的，但在邏輯上由一致性維度使所有的數(shù)據(jù)集市是聯(lián)系在

一起，隨時(shí)可以進(jìn)行交叉探察等操作，也就組成了數(shù)據(jù)倉庫。

3、一致性事實(shí)

在建立多個(gè)數(shù)據(jù)集市時(shí)，完成一致性維度的工作就已經(jīng)完成了一致性

的80%—90%的工作量。余下的工作就是建立一致性事實(shí)。一致性事實(shí)和

一致性維度有些不同，一致性維度是由專人維護(hù)在后臺(BackRoom),

發(fā)生修改時(shí)同步復(fù)制到每個(gè)數(shù)據(jù)集市，而事實(shí)表一般不會(huì)在多個(gè)數(shù)據(jù)集市

間復(fù)制。需要查詢多個(gè)數(shù)據(jù)集市中的事實(shí)時(shí).，一般通過交叉探查(drill

across)來實(shí)現(xiàn)。

為了能在多個(gè)數(shù)據(jù)集市間進(jìn)行交叉探查，一致性事實(shí)主要需要保證兩

點(diǎn)：第一個(gè)是KPI的定義及計(jì)算方法要一致，第二個(gè)是事實(shí)的單位要一致

性。如果業(yè)務(wù)要求或事實(shí)上就不能保持一致的話，建議不同單位的事實(shí)分

開建立字段保存。

這樣，一致性維度將多個(gè)數(shù)據(jù)集市結(jié)合在一起，一致性事實(shí)保證不同

數(shù)據(jù)集市間的事實(shí)數(shù)據(jù)可以交叉探查，一個(gè)分布式的數(shù)據(jù)倉庫就建成了。

小遍有活

■總線矩陣：業(yè)務(wù)過程和維度的交點(diǎn)；

■一致性維度：同一集市的維度表，內(nèi)容相同或包含；

?一致性事實(shí)：不同集市的同一事實(shí)，需保證口徑一致，單位統(tǒng)一。

追求一致性必然會(huì)增加開發(fā)工作量，但長期來說，使用方便、運(yùn)維簡

單；一致性和性能之間，需要平衡。

五、數(shù)據(jù)倉庫規(guī)范設(shè)計(jì)

1、為什么要進(jìn)行規(guī)范設(shè)計(jì)

無規(guī)矩、不方圓。規(guī)范設(shè)計(jì)是在具體開發(fā)工作之前制定的，過程中不

斷進(jìn)行完善。目的在于約束N個(gè)人對齊認(rèn)知，按照一個(gè)標(biāo)準(zhǔn)或流程進(jìn)行

開發(fā)，以保證數(shù)據(jù)一致性，流程清晰且穩(wěn)定。

一個(gè)良好的規(guī)范設(shè)計(jì)，應(yīng)當(dāng)起到以下作用：提高開發(fā)效率，提升質(zhì)

■,降低溝通對齊成本，降低運(yùn)維成本等。

下面西紅柿口將帶領(lǐng)大家盤一盤數(shù)據(jù)倉庫有哪些規(guī)范，從中挑選幾個(gè)

重點(diǎn)細(xì)說：

?設(shè)計(jì)規(guī)范

邏輯架構(gòu)、技術(shù)架構(gòu)、分層設(shè)計(jì)、主題劃分、方法論

?命名規(guī)范

各層級命名、任務(wù)命名、表命名、字段命名、指標(biāo)命名等

?模型規(guī)范

建模方法、建模工具、血緣關(guān)系、維度退化、一致性維度、元數(shù)

據(jù)管理

?開發(fā)規(guī)范

腳本注釋、字段別名、編碼規(guī)范、腳本格式、數(shù)據(jù)類型、縮寫規(guī)

范

?流程規(guī)范

需求流程、工程流程、上線流程、調(diào)度流、調(diào)度和表生命周期管

理

人設(shè)計(jì)規(guī)范-指標(biāo)

?Stepl:面向主題域管理

為了提高指標(biāo)管理的效率，你需要按照業(yè)務(wù)線、主題域和業(yè)務(wù)過程三

級目錄方式管理指標(biāo)。

?Step2:劃分原子指標(biāo)和派生指標(biāo)

原子指標(biāo)+原子指標(biāo)=派生指標(biāo)

?Step3:進(jìn)行指標(biāo)命名規(guī)范

需要遵循兩個(gè)原則：易懂與統(tǒng)一

1.易懂，就是看到指標(biāo)的名稱，就可以基本判斷這個(gè)指標(biāo)歸屬于哪個(gè)業(yè)務(wù)過

程；

2.統(tǒng)一，就是要確保派生指標(biāo)和它繼承的原子指標(biāo)命名是一致的。

對于原子指標(biāo)，標(biāo)名稱適合用"動(dòng)作+度量”的命名方式（比如注冊用戶

數(shù)、購買用戶數(shù)）

對于派生指標(biāo)，應(yīng)該嚴(yán)格遵循"時(shí)間周期+統(tǒng)計(jì)粒度+修飾詞+原子指

標(biāo)”的命名方式。（比如30天內(nèi)黑卡會(huì)員購買用戶數(shù)）

?Step4:分級管理

指標(biāo)確實(shí)是多，如果一視同仁去管理其實(shí)很難，所以可以按照下面的原則

進(jìn)行等級劃分：

1.一級指標(biāo)：數(shù)據(jù)中臺直接產(chǎn)出，核心指標(biāo)（提供給公司高層看的）、原子

指標(biāo)以及跨部門的派生指標(biāo)。

2.二級指標(biāo)：基于中臺提供的原子指標(biāo)，業(yè)務(wù)部門創(chuàng)建的派生指標(biāo)。

3、命名規(guī)范-表命名

3.1常規(guī)表

常規(guī)表是我們需要固化的表，是正式使用的表，是目前一段時(shí)間內(nèi)需

要去維護(hù)去完善的表。

規(guī)范:分層前鰥[dwd|dws|ads|bi]_業(yè)務(wù)域一主題域一XXX.更新頻率|

全量/增量。

業(yè)務(wù)域、主題域我們都可以用詞根的方式枚舉清楚，不斷完善，粒度

也是同樣的，主要的是時(shí)間粒度、日、月、年、周等，使用詞根定義好簡

稱。

建議格式：dwd_xxx_xxx_da

?di:每日增量

?da:每日全量

?mi:每月增量

?ma:每月全量

3.2中間表

中間表一般出現(xiàn)在Job中，是Job中臨時(shí)存儲(chǔ)的中間數(shù)據(jù)的表,中

間表的作用域只限于當(dāng)前Job執(zhí)行過程中，Job一旦執(zhí)行完成，該中間表

的使命就完成了，是可以刪除的（按照自己公司的場景自由選擇，以前公

司會(huì)保留幾天的中間表數(shù)據(jù)，用來排查問題）。

建議格式:mid_table_name_[0~9]

table_name是我們?nèi)蝿?wù)中目標(biāo)表的名字，通常來說一個(gè)任務(wù)只有一

個(gè)目標(biāo)表。這里加上表名，是為了防止自由發(fā)揮的時(shí)候表名沖突，而末尾

大家可以選擇自由發(fā)揮，起一些有意義的名字，或者簡單粗暴，使用數(shù)字

代替，各有優(yōu)劣吧，謹(jǐn)慎選擇。

3.3臨時(shí)表

臨時(shí)表是臨時(shí)測試的表，是臨時(shí)使用一次的表，就是暫時(shí)保存下數(shù)據(jù)

看看，后續(xù)一般不再使用的表，是可以隨時(shí)刪除的表。

建議格式：tmp_xxx

只要加上tmp開頭即可,其他名字隨意,注意tmp開頭的表不要用

來實(shí)際使用，只是測試驗(yàn)證而已。

3.4維度表

維度表是基于底層數(shù)據(jù)，抽象出來的描述類的表。維度表可以自動(dòng)從

底層表抽象出來，也可以手工來維護(hù)。

建議格式：dim_xxx

維度表，統(tǒng)一以dim開頭，后面加上，對該指標(biāo)的描述，可以自由發(fā)

揮。

M3聘廂__________________________________________

1表和列的注釋釋是否有缺失，復(fù)雜計(jì)算邏輯是否有注釋釋

2任務(wù)是否支持多次重跑而輸出不變，不能有insertinto語句

3分區(qū)表是否使用分區(qū)鍵過濾并且有有效裁剪

外連接的過逑條件是否使用正確，例如在左連接的where語句存在右

表的過濾條件

5關(guān)聯(lián)小表，是否使用/*+mapjoin*/hint

6不允許引用別的計(jì)算任務(wù)臨時(shí)表

7原則上不允許存在一個(gè)任務(wù)更新多個(gè)目標(biāo)表

8是否存在笞、迪卡爾積

9禁止在代碼里面使用drop11Ible、creat它11Ible、renaiue11lble>

chan零column等ddl語句

10使用動(dòng)態(tài)分區(qū)時(shí).，有沒有檢查分區(qū)鍵值為NULL的情況

11DQC質(zhì)量監(jiān)控規(guī)則是否配置，嚴(yán)禁棵奔

12代碼中有沒有進(jìn)行適當(dāng)?shù)囊?guī)避數(shù)據(jù)傾斜語句

13Where條件中isnull語句有沒有進(jìn)行空字符串處理

5、流程規(guī)范

根據(jù)阿里流程規(guī)范，本文將數(shù)據(jù)倉庫研發(fā)流程抽象為如下幾點(diǎn)：

1.需求階段：數(shù)據(jù)產(chǎn)品經(jīng)理應(yīng)如何應(yīng)對不斷變化的業(yè)務(wù)需求。

2.設(shè)計(jì)階段：數(shù)據(jù)產(chǎn)品經(jīng)理、數(shù)據(jù)開發(fā)者應(yīng)如何綜合性能、成本、效率、質(zhì)

量等因素，更好地組織與存儲(chǔ)數(shù)據(jù)。

3.開發(fā)階段：數(shù)據(jù)研發(fā)者如何高效、規(guī)范地進(jìn)行編碼工作。

4.測試階段：測試人員應(yīng)如何準(zhǔn)確地暴露代碼問題與項(xiàng)目風(fēng)險(xiǎn)，提升產(chǎn)出質(zhì)

量。

5.發(fā)布階段：如何將具備發(fā)布條件的程序平穩(wěn)地發(fā)布到線上穩(wěn)定產(chǎn)出。

6.運(yùn)維階段：運(yùn)維人員應(yīng)如何保障數(shù)據(jù)產(chǎn)出的時(shí)效性和穩(wěn)定性。

參與角色需求階段設(shè)計(jì)階段開發(fā)階段測試階段發(fā)布險(xiǎn)收

六、元數(shù)據(jù)管理

1、業(yè)務(wù)元數(shù)據(jù)

1.描述“數(shù)據(jù)”背后的業(yè)務(wù)含義

2.主題定義：每段ETL、表背后的歸屬業(yè)務(wù)主題。

3.業(yè)務(wù)描述：每段代碼實(shí)現(xiàn)的具體業(yè)務(wù)邏輯。

4.標(biāo)準(zhǔn)指標(biāo)：類似于BI中的語義層、數(shù)倉中的一致性事實(shí)；將分析中的指

標(biāo)進(jìn)行規(guī)范化。

5.標(biāo)準(zhǔn)維度：同標(biāo)準(zhǔn)指標(biāo)，對分析的各維度定義實(shí)現(xiàn)規(guī)范化、標(biāo)準(zhǔn)化。

6.不斷的進(jìn)行維護(hù)且與業(yè)務(wù)方進(jìn)行溝通確認(rèn)。

2、技術(shù)元數(shù)據(jù)

?數(shù)據(jù)源元數(shù)據(jù)

-例如：數(shù)據(jù)源的IP、端口、數(shù)據(jù)庫類型；數(shù)據(jù)獲取的方式；數(shù)據(jù)存儲(chǔ)

的結(jié)構(gòu)；原數(shù)據(jù)各列的定義及key指對應(yīng)的值。

?ETL元數(shù)據(jù)

?根據(jù)ETL目的的不同，可以分為兩類：數(shù)據(jù)清洗元數(shù)據(jù)；數(shù)據(jù)處理元

數(shù)據(jù)。

?數(shù)據(jù)清洗，主要目的是為了解決掉臟數(shù)據(jù)及規(guī)范數(shù)據(jù)格式；因此此處

元數(shù)據(jù)主要為：各表各列的“正確”數(shù)據(jù)規(guī)則；默認(rèn)數(shù)據(jù)類型的“正確"

規(guī)則。

-數(shù)據(jù)處理，例如常見的表輸入表輸出；非結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)化；特殊字

段的拆分等。源數(shù)據(jù)到數(shù)倉、數(shù)據(jù)集市層的各類規(guī)則。比如內(nèi)容、清

理、數(shù)據(jù)刷新規(guī)則。

?數(shù)據(jù)倉庫元數(shù)據(jù)

?數(shù)據(jù)倉庫結(jié)構(gòu)的描述，包括倉庫模式、視圖、維、層次結(jié)構(gòu)及數(shù)據(jù)集

市的位置和內(nèi)容；業(yè)務(wù)系統(tǒng)、數(shù)據(jù)倉庫和數(shù)據(jù)集市的體系結(jié)構(gòu)和模式

等。

?BI元數(shù)據(jù)

?匯總用的算法、包括各類度量和維度定義算法。數(shù)據(jù)粒度、主題領(lǐng)

域、聚集、匯總、預(yù)定義的查詢與報(bào)告。

3、管理元數(shù)據(jù)

管理領(lǐng)域相關(guān)，包括管理流程、人員組織、角色職責(zé)等。

、小編有話

在日常工作中，元數(shù)據(jù)的管理主要體現(xiàn)在元數(shù)據(jù)的采集、存儲(chǔ)、查詢、應(yīng)

用幾個(gè)方面。原則上應(yīng)從規(guī)范化，到腳本化，到工具化的方向進(jìn)行建設(shè)。

?采集：元數(shù)據(jù)采集時(shí)盡可能詳細(xì)，真實(shí)，可通過工具生成或者勾選，避免

手動(dòng)錄入帶來不規(guī)范等問題

?存儲(chǔ)：存儲(chǔ)元數(shù)據(jù)要做到不失真，元數(shù)據(jù)變更時(shí)及時(shí)同步

?查詢：通過網(wǎng)頁或庫表等方式，方便快捷的看到元數(shù)據(jù)，輔助進(jìn)行開發(fā)

?應(yīng)用：數(shù)據(jù)血緣、優(yōu)化調(diào)度依賴、數(shù)據(jù)治理等

七、維度表

1、什么是維度表

維度是維度建模的基礎(chǔ)和靈魂。在維度建模中，將度量稱為“事實(shí)"，將

環(huán)境描述為"維度”。

維度表包含了事實(shí)表中指定屬性的相關(guān)詳細(xì)信息，最常用的維度表有日期

維度、城市維度等。

日期維表：

num字段名字段中文名描述數(shù)據(jù)類型

1date日期日期yyyMMdd格式bigint

2week星期，數(shù)字型星期，數(shù)字型0-6bigint

星期中文名星期

3week_cn星期中文名string

一年中的第兒一年中的第幾周

4year_weeks12bigint

周3.......

5mon_dt本周周一日期本周周一日期bigint

6sun_dt本周周日日期本周周日日期bigint

7month年月年月，yyyyMM格式bigint

月份簡寫，MM格式

8month_short月份簡寫bigint

1~12

9month__cn月份中文名月份中文名一月……string

1()quarter季度季度，yyyyQl\2\3\4string

11quarter_short季度數(shù)字型季度數(shù)字型1-4bigint

季度中文名第一季

12quarter_cn季度中文名string

度……

13year年份年份，yyyy格式bigint

2、維度表設(shè)計(jì)原則

維度的作用一般是查詢約束、分類匯總以及排序等，我們在進(jìn)行維度表設(shè)

計(jì)時(shí)，應(yīng)當(dāng)提前考慮：

(1)維度屬性盡量豐富，為數(shù)據(jù)使用打下基礎(chǔ)

比如淘寶商品維度有近百個(gè)維度屬性，為下游的數(shù)據(jù)統(tǒng)計(jì)、分析、探

查提供了良好的基礎(chǔ)。

(2)給出詳實(shí)的、富有意義的文字描述

屬性不應(yīng)該是編碼，而應(yīng)該是真正的文字。在間里巴巴維度建模中，

一般是編碼和文字同時(shí)存在，比如商品維度中的商品ID和商品標(biāo)題、類

目ID和類目名稱等。ID-般用于不同表之間的關(guān)聯(lián)，而名稱一般用于

報(bào)表標(biāo)簽

(3)區(qū)分?jǐn)?shù)值型屬性和事實(shí)

數(shù)值型宇段是作為事實(shí)還是維度屬性，可以參考字段的一般用途。如

果通常用于查詢約束條件或分組統(tǒng)計(jì)，則是作為維度屬性;如果通常用于

參與度量的計(jì)算，則是作為事實(shí)。比如商品價(jià)格，可以用于查詢約束條

件或統(tǒng)計(jì)價(jià)格區(qū)間的商品數(shù)量，此時(shí)是作為維度屬性使用的;也可以用于

統(tǒng)計(jì)某類目下商品的平均價(jià)格，此時(shí)是作為事實(shí)使用的。另外，如果數(shù)

值型字段是離散值，則作為維度屬性存在的可能性較大;如果數(shù)值型宇段

是連續(xù)值，則作為度量存在的可能性較大，但并不絕對，需要同時(shí)參考

宇段的具體用途。

(4)沉淀出通用的維度屬性，為建立一致性維度做好鋪墊

有些維度屬性獲取需要進(jìn)行比較復(fù)雜的邏輯處理，有些需要通過多表

關(guān)聯(lián)得到，或者通過單表的不同宇段混合處理得到，或者通過對單表的

某個(gè)字段進(jìn)行解析得到。此時(shí)，需要將盡可能多的通用的維度屬性進(jìn)行沉

淀。一方面，可以提高下游使用的方便性，減少復(fù)雜度;另一方面，可以

避免下游使用解析時(shí)由于各自邏輯不同而導(dǎo)致口徑不一致。

(5)退化維度(DegenerateDimension)

在維度類型中，有一種重要的維度稱作為退化維度。這種維度指的是

直接把一些簡單的維度放在事實(shí)表中。退化維度是維度建模領(lǐng)域中的一個(gè)

非常重要的概念，它對理解維度建模有著非常重要的作用，退化維度一般

在分析中可以用來做分組使用。

(6)緩慢變化維(SlowlyChangingDimensions)

維度的屬性并不是始終不變的，它會(huì)隨著時(shí)間的流逝發(fā)生緩慢的變

化，這種隨時(shí)間發(fā)生變化的維度我們一般稱之為緩慢變化維(SCD),緩

慢變化維一般使用代理健作為維度表的主健。

推薦閱讀：緩慢變化維度的10種處理方式

緩慢變化維的三種常用處理方式：

@TYPE1直接覆蓋原值

適用于：不看歷史數(shù)據(jù)，簡單粗暴

user_idusernaaedeptname

El024虎妞產(chǎn)品部

I