本文大綱：
因內(nèi)容較多澡绩，帶目錄的PDF查看是比較方便的：
一宛蚓、數(shù)倉基本概念
1. 數(shù)據(jù)倉庫架構(gòu)
我們在談數(shù)倉之前，為了讓大家有直觀的認(rèn)識恢氯，先來談數(shù)倉架構(gòu)，“架構(gòu)”是什么程腹？這個問題從來就沒有一個準(zhǔn)確的答案嚼吞。這里我們引用一段話：在軟件行業(yè)，一種被普遍接受的架構(gòu)定義是指系統(tǒng)的一個或多個結(jié)構(gòu)刽严。結(jié)構(gòu)中包括軟件的構(gòu)建（構(gòu)建是指軟件的設(shè)計與實現(xiàn)）昂灵，構(gòu)建的外部可以看到屬性以及它們之間的相互關(guān)系。
這里參考此定義舞萄，把數(shù)據(jù)倉庫架構(gòu)理解成構(gòu)成數(shù)據(jù)倉庫的組件及其之間的關(guān)系眨补，畫出下面的數(shù)倉架構(gòu)圖：
數(shù)倉架構(gòu)
上圖中顯示的整個數(shù)據(jù)倉庫環(huán)境包括操作型系統(tǒng)和數(shù)據(jù)倉庫系統(tǒng)兩大部分。操作型系統(tǒng)的數(shù)據(jù)由各種形式的業(yè)務(wù)數(shù)據(jù)組成倒脓，這些數(shù)據(jù)經(jīng)過抽取撑螺、轉(zhuǎn)換和裝載（ETL）過程進(jìn)入數(shù)據(jù)倉庫系統(tǒng)。
任何事物都是隨著時間的演進(jìn)變得越來越完善崎弃，當(dāng)然也是越來越復(fù)雜甘晤，數(shù)倉也不例外。在數(shù)據(jù)倉庫技術(shù)演化過程中饲做，產(chǎn)生了幾種主要的架構(gòu)方法线婚，包括數(shù)據(jù)集市架構(gòu)、Inmon企業(yè)信息工廠架構(gòu)盆均、Kimball數(shù)據(jù)倉庫架構(gòu)塞弊、混合型數(shù)據(jù)倉庫架構(gòu)。這幾種架構(gòu)我們后面再講，接下來看下數(shù)倉的基本概念游沿。
2. 數(shù)據(jù)倉庫概念
英文名稱為Data Warehouse饰抒，可簡寫為DW或DWH。數(shù)據(jù)倉庫的目的是構(gòu)建面向分析的集成化數(shù)據(jù)環(huán)境奏候，為企業(yè)提供決策支持（Decision Support）循集。它出于分析性報告和決策支持目的而創(chuàng)建。
數(shù)據(jù)倉庫本身并不“生產(chǎn)”任何數(shù)據(jù)蔗草，同時自身也不需要“消費”任何的數(shù)據(jù)咒彤，數(shù)據(jù)來源于外部，并且開放給外部應(yīng)用咒精，這也是為什么叫“倉庫”镶柱，而不叫“工廠”的原因。
1) 基本特征
數(shù)據(jù)倉庫是面向主題的模叙、集成的歇拆、非易失的和時變的數(shù)據(jù)集合，用以支持管理決策范咨。
面向主題:
傳統(tǒng)數(shù)據(jù)庫中故觅，最大的特點是面向應(yīng)用進(jìn)行數(shù)據(jù)的組織，各個業(yè)務(wù)系統(tǒng)可能是相互分離的渠啊。而數(shù)據(jù)倉庫則是面向主題的输吏。主題是一個抽象的概念，是較高層次上企業(yè)信息系統(tǒng)中的數(shù)據(jù)綜合替蛉、歸類并進(jìn)行分析利用的抽象贯溅。在邏輯意義上，它是對應(yīng)企業(yè)中某一宏觀分析領(lǐng)域所涉及的分析對象躲查。
集成性:
通過對分散它浅、獨立、異構(gòu)的數(shù)據(jù)庫數(shù)據(jù)進(jìn)行抽取镣煮、清理姐霍、轉(zhuǎn)換和匯總便得到了數(shù)據(jù)倉庫的數(shù)據(jù)，這樣保證了數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)關(guān)于整個企業(yè)的一致性典唇。
數(shù)據(jù)倉庫中的綜合數(shù)據(jù)不能從原有的數(shù)據(jù)庫系統(tǒng)直接得到邮弹。因此在數(shù)據(jù)進(jìn)入數(shù)據(jù)倉庫之前，必然要經(jīng)過統(tǒng)一與綜合蚓聘，這一步是數(shù)據(jù)倉庫建設(shè)中最關(guān)鍵腌乡、最復(fù)雜的一步，所要完成的工作有：
要統(tǒng)一源數(shù)據(jù)中所有矛盾之處夜牡，如字段的同名異義与纽、異名同義侣签、單位不統(tǒng)一、字長不一致急迂，等等影所。
進(jìn)行數(shù)據(jù)綜合和計算。數(shù)據(jù)倉庫中的數(shù)據(jù)綜合工作可以在從原有數(shù)據(jù)庫抽取數(shù)據(jù)時生成僚碎，但許多是在數(shù)據(jù)倉庫內(nèi)部生成的猴娩，即進(jìn)入數(shù)據(jù)倉庫以后進(jìn)行綜合生成的。
下圖說明一個保險公司綜合數(shù)據(jù)的簡單處理過程勺阐，其中數(shù)據(jù)倉庫中與“保險” 主題有關(guān)的數(shù)據(jù)來自于多個不同的操作型系統(tǒng)卷中。這些系統(tǒng)內(nèi)部數(shù)據(jù)的命名可能不同，數(shù)據(jù)格式也可能不同渊抽。把不同來源的數(shù)據(jù)存儲到數(shù)據(jù)倉庫之前蟆豫，需要去除這些不一致。
數(shù)倉主題
非易失性（不可更新性）:
數(shù)據(jù)倉庫的數(shù)據(jù)反映的是一段相當(dāng)長的時間內(nèi)歷史數(shù)據(jù)的內(nèi)容懒闷，是不同時點的數(shù)據(jù)庫快照的集合十减，以及基于這些快照進(jìn)行統(tǒng)計、綜合和重組的導(dǎo)出數(shù)據(jù)愤估。
數(shù)據(jù)非易失性主要是針對應(yīng)用而言帮辟。數(shù)據(jù)倉庫的用戶對數(shù)據(jù)的操作大多是數(shù)據(jù)查詢或比較復(fù)雜的挖掘，一旦數(shù)據(jù)進(jìn)入數(shù)據(jù)倉庫以后玩焰，一般情況下被較長時間保留由驹。數(shù)據(jù)倉庫中一般有大量的查詢操作，但修改和刪除操作很少震捣。因此，數(shù)據(jù)經(jīng)加工和集成進(jìn)入數(shù)據(jù)倉庫后是極少更新的闹炉，通常只需要定期的加載和更新蒿赢。
時變性:
數(shù)據(jù)倉庫包含各種粒度的歷史數(shù)據(jù)。數(shù)據(jù)倉庫中的數(shù)據(jù)可能與某個特定日期渣触、星期羡棵、月份、季度或者年份有關(guān)嗅钻。數(shù)據(jù)倉庫的目的是通過分析企業(yè)過去一段時間業(yè)務(wù)的經(jīng)營狀況皂冰，挖掘其中隱藏的模式。雖然數(shù)據(jù)倉庫的用戶不能修改數(shù)據(jù)养篓，但并不是說數(shù)據(jù)倉庫的數(shù)據(jù)是永遠(yuǎn)不變的秃流。分析的結(jié)果只能反映過去的情況，當(dāng)業(yè)務(wù)變化后柳弄，挖掘出的模式會失去時效性舶胀。因此數(shù)據(jù)倉庫的數(shù)據(jù)需要更新，以適應(yīng)決策的需要。從這個角度講嚣伐，數(shù)據(jù)倉庫建設(shè)是一個項目糖赔，更是一個過程。數(shù)據(jù)倉庫的數(shù)據(jù)隨時間的變化表現(xiàn)在以下幾個方面：
（1）數(shù)據(jù)倉庫的數(shù)據(jù)時限一般要遠(yuǎn)遠(yuǎn)長于操作型數(shù)據(jù)的數(shù)據(jù)時限轩端。
（2）操作型系統(tǒng)存儲的是當(dāng)前數(shù)據(jù)放典，而數(shù)據(jù)倉庫中的數(shù)據(jù)是歷史數(shù)據(jù)。
（3）數(shù)據(jù)倉庫中的數(shù)據(jù)是按照時間順序追加的基茵，它們都帶有時間屬性奋构。
3. 為什么要有數(shù)據(jù)倉庫
先來看下數(shù)據(jù)倉庫的數(shù)據(jù)從哪里來，最終要到哪里去耿导？
通常數(shù)據(jù)倉庫的數(shù)據(jù)來自各個業(yè)務(wù)應(yīng)用系統(tǒng)声怔。業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)形式多種多樣，可能是 Oracle舱呻、MySQL醋火、SQL Server等關(guān)系數(shù)據(jù)庫里的結(jié)構(gòu)化數(shù)據(jù)，可能是文本箱吕、CSV等平面文件或Word芥驳、Excel文檔中的數(shù)據(jù)，還可能是HTML茬高、XML等自描述的半結(jié)構(gòu)化數(shù)據(jù)兆旬。這些業(yè)務(wù)數(shù)據(jù)經(jīng)過一系列的數(shù)據(jù)抽取、轉(zhuǎn)換怎栽、清洗丽猬，最終以一種統(tǒng)一的格式裝載進(jìn)數(shù)據(jù)倉庫。數(shù)據(jù)倉庫里的數(shù)據(jù)作為分析用的數(shù)據(jù)源熏瞄，提供給后面的即席查詢脚祟、 分析系統(tǒng)、數(shù)據(jù)集市强饮、報表系統(tǒng)由桌、數(shù)據(jù)挖掘系統(tǒng)等。
這時我們就想了邮丰，為什么不能把業(yè)務(wù)系統(tǒng)的數(shù)據(jù)直接拿來供即席查詢行您、分析系統(tǒng)、報表系統(tǒng)等使用呢剪廉，為什么要經(jīng)過數(shù)據(jù)倉庫這一步娃循？實際上在數(shù)倉出現(xiàn)之前，確實是這么做的斗蒋，但是有很多數(shù)據(jù)分析的先驅(qū)者當(dāng)時已經(jīng)發(fā)現(xiàn)淮野，簡單的“直接訪問”方式很難良好工作捧书，這樣做的失敗案例數(shù)不勝數(shù)。下面列舉一些直接訪問業(yè)務(wù)系統(tǒng)無法工作的原因：
某些業(yè)務(wù)數(shù)據(jù)由于安全或其他因素不能直接訪問骤星。
業(yè)務(wù)系統(tǒng)的版本變更很頻繁经瓷，每次變更都需要重寫分析系統(tǒng)并重新測試。
很難建立和維護匯總數(shù)據(jù)來源于多個業(yè)務(wù)系統(tǒng)版本的報表洞难。
業(yè)務(wù)系統(tǒng)的列名通常是硬編碼舆吮，有時僅僅是無意義的字符串，這讓編寫分析系統(tǒng)更加困難队贱。
業(yè)務(wù)系統(tǒng)的數(shù)據(jù)格式色冀，如日期、數(shù)字的格式不統(tǒng)一柱嫌。
業(yè)務(wù)系統(tǒng)的表結(jié)構(gòu)為事務(wù)處理性能而優(yōu)化锋恬，有時并不適合查詢與分析。
沒有適當(dāng)?shù)姆绞綄⒂袃r值的數(shù)據(jù)合并進(jìn)特定應(yīng)用的數(shù)據(jù)庫。
沒有適當(dāng)?shù)奈恢么鎯υ獢?shù)據(jù)。
用戶需要看到的顯示數(shù)據(jù)字段亥曹，有時在數(shù)據(jù)庫中并不存在。
通常事務(wù)處理的優(yōu)先級比分析系統(tǒng)高索守，所以如果分析系統(tǒng)和事務(wù)處理運行在同一硬件之上，分析系統(tǒng)往往性能很差抑片。
有誤用業(yè)務(wù)數(shù)據(jù)的風(fēng)險卵佛。
極有可能影響業(yè)務(wù)系統(tǒng)的性能。
盡管需要增加軟硬件的投入敞斋，但建立獨立數(shù)據(jù)倉庫與直接訪問業(yè)務(wù)數(shù)據(jù)相比截汪，無論是成本還是帶來的好處，這樣做都是值得的植捎。隨著處理器和存儲成本的逐年降低衙解，數(shù)據(jù)倉庫方案的優(yōu)勢更加明顯，在經(jīng)濟上也更具可行性鸥跟。
4. 數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別
數(shù)據(jù)庫與數(shù)據(jù)倉庫的區(qū)別實際講的是 OLTP 與 OLAP 的區(qū)別丢郊。
操作型處理盔沫，叫聯(lián)機事務(wù)處理 OLTP（On-Line Transaction Processing医咨，），也可以稱面向交易的處理系統(tǒng)架诞，它是針對具體業(yè)務(wù)在數(shù)據(jù)庫聯(lián)機的日常操作拟淮，通常對少數(shù)記錄進(jìn)行查詢、修改谴忧。用戶較為關(guān)心操作的響應(yīng)時間很泊、數(shù)據(jù)的安全性角虫、完整性和并發(fā)支持的用戶數(shù)等問題。傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)作為數(shù)據(jù)管理的主要手段委造，主要用于操作型處理戳鹅，像Mysql，Oracle等關(guān)系型數(shù)據(jù)庫一般屬于OLTP昏兆。
分析型處理枫虏，叫聯(lián)機分析處理 OLAP（On-Line Analytical Processing）一般針對某些主題的歷史數(shù)據(jù)進(jìn)行分析，支持管理決策爬虱。
首先要明白隶债，數(shù)據(jù)倉庫的出現(xiàn)，并不是要取代數(shù)據(jù)庫跑筝。數(shù)據(jù)庫是面向事務(wù)的設(shè)計死讹，數(shù)據(jù)倉庫是面向主題設(shè)計的。數(shù)據(jù)庫一般存儲業(yè)務(wù)數(shù)據(jù)曲梗，數(shù)據(jù)倉庫存儲的一般是歷史數(shù)據(jù)赞警。
數(shù)據(jù)庫設(shè)計是盡量避免冗余，一般針對某一業(yè)務(wù)應(yīng)用進(jìn)行設(shè)計稀并，比如一張簡單的User表仅颇，記錄用戶名、密碼等簡單數(shù)據(jù)即可碘举，符合業(yè)務(wù)應(yīng)用忘瓦，但是不符合分析。數(shù)據(jù)倉庫在設(shè)計是有意引入冗余引颈，依照分析需求耕皮，分析維度、分析指標(biāo)進(jìn)行設(shè)計蝙场。
數(shù)據(jù)庫是為捕獲數(shù)據(jù)而設(shè)計凌停，數(shù)據(jù)倉庫是為分析數(shù)據(jù)而設(shè)計。
以銀行業(yè)務(wù)為例售滤。數(shù)據(jù)庫是事務(wù)系統(tǒng)的數(shù)據(jù)平臺罚拟，客戶在銀行做的每筆交易都會寫入數(shù)據(jù)庫，被記錄下來完箩，這里赐俗，可以簡單地理解為用數(shù)據(jù)庫記賬。數(shù)據(jù)倉庫是分析系統(tǒng)的數(shù)據(jù)平臺弊知，它從事務(wù)系統(tǒng)獲取數(shù)據(jù)阻逮，并做匯總、加工秩彤，為決策者提供決策的依據(jù)叔扼。比如事哭，某銀行某分行一個月發(fā)生多少交易，該分行當(dāng)前存款余額是多少瓜富。如果存款又多鳍咱，消費交易又多，那么該地區(qū)就有必要設(shè)立ATM了与柑。
顯然流炕，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算仅胞。事務(wù)系統(tǒng)是實時的每辟，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的干旧，這就要求數(shù)據(jù)庫只能存儲很短一段時間的數(shù)據(jù)渠欺。而分析系統(tǒng)是事后的，它要提供關(guān)注時間段內(nèi)所有的有效數(shù)據(jù)椎眯。這些數(shù)據(jù)是海量的挠将，匯總計算起來也要慢一些，但是编整，只要能夠提供有效的分析數(shù)據(jù)就達(dá)到目的了舔稀。
數(shù)據(jù)倉庫，是在數(shù)據(jù)庫已經(jīng)大量存在的情況下掌测，為了進(jìn)一步挖掘數(shù)據(jù)資源内贮、為了決策需要而產(chǎn)生的，它決不是所謂的“大型數(shù)據(jù)庫”汞斧。
5.? 數(shù)據(jù)倉庫分層架構(gòu)
按照數(shù)據(jù)流入流出的過程夜郁，數(shù)據(jù)倉庫架構(gòu)可分為：源數(shù)據(jù)、數(shù)據(jù)倉庫粘勒、數(shù)據(jù)應(yīng)用
數(shù)據(jù)倉庫
數(shù)據(jù)倉庫的數(shù)據(jù)來源于不同的源數(shù)據(jù)竞端，并提供多樣的數(shù)據(jù)應(yīng)用，數(shù)據(jù)自下而上流入數(shù)據(jù)倉庫后向上層開放應(yīng)用庙睡，而數(shù)據(jù)倉庫只是中間集成化數(shù)據(jù)管理的一個平臺事富。
源數(shù)據(jù)：此層數(shù)據(jù)無任何更改，直接沿用外圍系統(tǒng)數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)乘陪，不對外開放统台；為臨時存儲層，是接口數(shù)據(jù)的臨時存儲區(qū)域暂刘，為后一步的數(shù)據(jù)處理做準(zhǔn)備饺谬。
數(shù)據(jù)倉庫：也稱為細(xì)節(jié)層捂刺，DW層的數(shù)據(jù)應(yīng)該是一致的谣拣、準(zhǔn)確的募寨、干凈的數(shù)據(jù)，即對源系統(tǒng)數(shù)據(jù)進(jìn)行了清洗（去除了雜質(zhì)）后的數(shù)據(jù)森缠。
數(shù)據(jù)應(yīng)用：前端應(yīng)用直接讀取的數(shù)據(jù)源拔鹰；根據(jù)報表、專題分析需求而計算生成的數(shù)據(jù)贵涵。
數(shù)據(jù)倉庫從各數(shù)據(jù)源獲取數(shù)據(jù)及在數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)轉(zhuǎn)換和流動都可以認(rèn)為是ETL（抽取Extra, 轉(zhuǎn)化Transfer, 裝載Load）的過程列肢，ETL是數(shù)據(jù)倉庫的流水線，也可以認(rèn)為是數(shù)據(jù)倉庫的血液宾茂，它維系著數(shù)據(jù)倉庫中數(shù)據(jù)的新陳代謝瓷马，而數(shù)據(jù)倉庫日常的管理和維護工作的大部分精力就是保持ETL的正常和穩(wěn)定。
那么為什么要數(shù)據(jù)倉庫進(jìn)行分層呢?
用空間換時間跨晴，通過大量的預(yù)處理來提升應(yīng)用系統(tǒng)的用戶體驗（效率）欧聘，因此數(shù)據(jù)倉庫會存在大量冗余的數(shù)據(jù)；不分層的話端盆，如果源業(yè)務(wù)系統(tǒng)的業(yè)務(wù)規(guī)則發(fā)生變化將會影響整個數(shù)據(jù)清洗過程怀骤，工作量巨大。
通過數(shù)據(jù)分層管理可以簡化數(shù)據(jù)清洗的過程焕妙，因為把原來一步的工作分到了多個步驟去完成蒋伦，相當(dāng)于把一個復(fù)雜的工作拆成了多個簡單的工作，把一個大的黑盒變成了一個白盒焚鹊，每一層的處理邏輯都相對簡單和容易理解痕届，這樣我們比較容易保證每一個步驟的正確性，當(dāng)數(shù)據(jù)發(fā)生錯誤的時候末患，往往我們只需要局部調(diào)整某個步驟即可爷抓。
6. 主要數(shù)據(jù)倉庫架構(gòu)
通過上面的內(nèi)容我們大概了解數(shù)倉的概念，接下來就看下數(shù)倉的幾種演進(jìn)架構(gòu)阻塑。
1. 數(shù)據(jù)集市架構(gòu)
數(shù)據(jù)集市是按主題域組織的數(shù)據(jù)集合蓝撇，用于支持部門級的決策。有兩種類型的數(shù)據(jù)集市：獨立數(shù)據(jù)集市和從屬數(shù)據(jù)集市陈莽。
1) 獨立數(shù)據(jù)集市
獨立數(shù)據(jù)集市集中于部門所關(guān)心的單一主題域渤昌，數(shù)據(jù)以部門為基礎(chǔ)部署，無須考慮企業(yè)級別的信息共享與集成走搁。例如独柑，制造部門、人力資源部門和其他部門都各自有他們自己的數(shù)據(jù)集市私植。
優(yōu)點：因為一個部門的業(yè)務(wù)相對于整個企業(yè)要簡單忌栅，數(shù)據(jù)量也小得多，所以部門的獨立數(shù)據(jù)集市具有周期短曲稼、見效快的特點索绪。
缺點：
從業(yè)務(wù)角度看湖员，當(dāng)部門的分析需求擴展，或者需要分析跨部門或跨主題域的數(shù)據(jù)時瑞驱，獨立數(shù)據(jù)市場會顯得力不從心娘摔。
當(dāng)數(shù)據(jù)存在歧義，比如同一個產(chǎn)品唤反，在A部門和B部門的定義不同時凳寺，將無法在部門間進(jìn)行信息比較。
每個部門使用不同的技術(shù)彤侍，建立不同的ETL的過程肠缨，處理不同的事務(wù)系統(tǒng)，而在多個獨立的數(shù)據(jù)集市之間還會存在數(shù)據(jù)的交叉與重疊盏阶，甚至?xí)袛?shù)據(jù)不一致的情況怜瞒。
2) 從屬數(shù)據(jù)集市
從屬數(shù)據(jù)集市的數(shù)據(jù)來源于數(shù)據(jù)倉庫。數(shù)據(jù)倉庫里的數(shù)據(jù)經(jīng)過整合般哼、重構(gòu)吴汪、匯總后傳遞給從屬數(shù)據(jù)集市。
建立從屬數(shù)據(jù)集市的好處主要有：
性能：當(dāng)數(shù)據(jù)倉庫的查詢性能出現(xiàn)問題蒸眠，可以考慮建立幾個從屬數(shù)據(jù)集市漾橙，將查詢從數(shù)據(jù)倉庫移出到數(shù)據(jù)集市。
安全：每個部門可以完全控制他們自己的數(shù)據(jù)楞卡。
數(shù)據(jù)一致：因為每個數(shù)據(jù)集市的數(shù)據(jù)來源都是同一個數(shù)據(jù)倉庫霜运，有效消除了數(shù)據(jù)不一致的情況。
2. Inmon企業(yè)工廠架構(gòu)
上圖的前兩步不過多介紹蒋腮，直接從第三步開始淘捡。
企業(yè)級數(shù)據(jù)倉庫：是該架構(gòu)中的核心組件。正如Inmon數(shù)據(jù)倉庫所定義的池摧，企業(yè)級數(shù)據(jù)倉庫是一個細(xì)節(jié)數(shù)據(jù)的集成資源庫焦除。其中的數(shù)據(jù)以最低粒度級別被捕獲，存儲在滿足三范式設(shè)計的關(guān)系數(shù)據(jù)庫中作彤。
部門級數(shù)據(jù)集市：是面向主題數(shù)據(jù)的部門級視圖膘魄，數(shù)據(jù)從企業(yè)級數(shù)據(jù)倉庫獲取。數(shù)據(jù)在進(jìn)入部門數(shù)據(jù)集市時可能進(jìn)行聚合竭讳。數(shù)據(jù)集市使用多維模型設(shè)計创葡，用于數(shù)據(jù)分析。重要的一點是绢慢，所有的報表工具灿渴、BI工具或其他數(shù)據(jù)分析應(yīng)用都從數(shù)據(jù)集市查詢數(shù)據(jù)，而不是直接查詢企業(yè)級數(shù)據(jù)倉庫。
3. Kimball數(shù)據(jù)倉庫架構(gòu)
對比上一張圖可以看到骚露，Kimball與Inmon兩種架構(gòu)的主要區(qū)別在于核心數(shù)據(jù)倉庫的設(shè)計和建立蹬挤。
Kimball的數(shù)據(jù)倉庫包含高粒度的企業(yè)數(shù)據(jù)，使用多維模型設(shè)計秆麸，這也意味著數(shù)據(jù)倉庫由星型模式的維度表和事實表構(gòu)成鲜戒。分析系統(tǒng)或報表工具可以直接訪問多維數(shù)據(jù)倉庫里的數(shù)據(jù)。
在此架構(gòu)中的數(shù)據(jù)集市也與Inmon中的不同。這里的數(shù)據(jù)集市是一個邏輯概念箭养，只是多維數(shù)據(jù)倉庫中的主題域劃分，并沒有自己的物理存儲得湘，也可以說是虛擬的數(shù)據(jù)集市募狂。
4. 混合型數(shù)據(jù)倉庫架構(gòu)
所謂的混合型結(jié)構(gòu)，指的是在一個數(shù)據(jù)倉庫環(huán)境中诞帐，聯(lián)合使用Inmon和Kimball兩種架構(gòu)欣尼。
從架構(gòu)圖可以看到，這種架構(gòu)將Inmon方法中的數(shù)據(jù)集市部分替換成了一個多維數(shù)據(jù)倉庫停蕉，而數(shù)據(jù)集市則是多維數(shù)據(jù)倉庫上的邏輯視圖愕鼓。
使用這種架構(gòu)的好處是：既可以利用規(guī)范化設(shè)計消除數(shù)據(jù)冗余，保證數(shù)據(jù)的粒度足夠細(xì)慧起；又可以利用多維結(jié)構(gòu)更靈活地在企業(yè)級實現(xiàn)報表和分析菇晃。
7. 數(shù)據(jù)倉庫元數(shù)據(jù)的管理
元數(shù)據(jù)（Meta Date），主要記錄數(shù)據(jù)倉庫中模型的定義蚓挤、各層級間的映射關(guān)系磺送、監(jiān)控數(shù)據(jù)倉庫的數(shù)據(jù)狀態(tài)及ETL的任務(wù)運行狀態(tài)。一般會通過元數(shù)據(jù)資料庫（Metadata Repository）來統(tǒng)一地存儲和管理元數(shù)據(jù)灿意，其主要目的是使數(shù)據(jù)倉庫的設(shè)計估灿、部署、操作和管理能達(dá)成協(xié)同和一致缤剧。
元數(shù)據(jù)是數(shù)據(jù)倉庫管理系統(tǒng)的重要組成部分馅袁，元數(shù)據(jù)管理是企業(yè)級數(shù)據(jù)倉庫中的關(guān)鍵組件，貫穿數(shù)據(jù)倉庫構(gòu)建的整個過程荒辕，直接影響著數(shù)據(jù)倉庫的構(gòu)建司顿、使用和維護。
構(gòu)建數(shù)據(jù)倉庫的主要步驟之一是ETL兄纺。這時元數(shù)據(jù)將發(fā)揮重要的作用大溜，它定義了源數(shù)據(jù)系統(tǒng)到數(shù)據(jù)倉庫的映射、數(shù)據(jù)轉(zhuǎn)換的規(guī)則估脆、數(shù)據(jù)倉庫的邏輯結(jié)構(gòu)钦奋、數(shù)據(jù)更新的規(guī)則、數(shù)據(jù)導(dǎo)入歷史記錄以及裝載周期等相關(guān)內(nèi)容。數(shù)據(jù)抽取和轉(zhuǎn)換的專家以及數(shù)據(jù)倉庫管理員正是通過元數(shù)據(jù)高效地構(gòu)建數(shù)據(jù)倉庫付材。
用戶在使用數(shù)據(jù)倉庫時朦拖，通過元數(shù)據(jù)訪問數(shù)據(jù)，明確數(shù)據(jù)項的含義以及定制報表厌衔。
數(shù)據(jù)倉庫的規(guī)模及其復(fù)雜性離不開正確的元數(shù)據(jù)管理璧帝，包括增加或移除外部數(shù)據(jù)源，改變數(shù)據(jù)清洗方法富寿，控制出錯的查詢以及安排備份等睬隶。
元數(shù)據(jù)可分為技術(shù)元數(shù)據(jù)和業(yè)務(wù)元數(shù)據(jù)。技術(shù)元數(shù)據(jù)為開發(fā)和管理數(shù)據(jù)倉庫的IT 人員使用页徐，它描述了與數(shù)據(jù)倉庫開發(fā)苏潜、管理和維護相關(guān)的數(shù)據(jù)，包括數(shù)據(jù)源信息变勇、數(shù)據(jù)轉(zhuǎn)換描述恤左、數(shù)據(jù)倉庫模型、數(shù)據(jù)清洗與更新規(guī)則搀绣、數(shù)據(jù)映射和訪問權(quán)限等飞袋。而業(yè)務(wù)元數(shù)據(jù)為管理層和業(yè)務(wù)分析人員服務(wù)，從業(yè)務(wù)角度描述數(shù)據(jù)链患，包括商務(wù)術(shù)語授嘀、數(shù)據(jù)倉庫中有什么數(shù)據(jù)、數(shù)據(jù)的位置和數(shù)據(jù)的可用性等锣险，幫助業(yè)務(wù)人員更好地理解數(shù)據(jù)倉庫中哪些數(shù)據(jù)是可用的以及如何使用蹄皱。
由上可見，元數(shù)據(jù)不僅定義了數(shù)據(jù)倉庫中數(shù)據(jù)的模式芯肤、來源巷折、抽取和轉(zhuǎn)換規(guī)則等，而且是整個數(shù)據(jù)倉庫系統(tǒng)運行的基礎(chǔ)崖咨，元數(shù)據(jù)把數(shù)據(jù)倉庫系統(tǒng)中各個松散的組件聯(lián)系起來锻拘，組成了一個有機的整體。
8. 數(shù)倉常見術(shù)語解析
本文檔首發(fā)于公眾號【五分鐘學(xué)大數(shù)據(jù)】
本小節(jié)結(jié)構(gòu)如下圖所示：
1. 數(shù)倉名詞解釋
1. 實體
實體是指依附的主體击蹲，就是我們分析的一個對象署拟，比如我們分析商品的銷售情況，如華為手機近半年的銷售量是多少歌豺，那華為手機就是一個實體推穷；我們分析用戶的活躍度，用戶就是一個實體类咧。當(dāng)然實體也可以現(xiàn)實中不存在的馒铃，比如虛擬的業(yè)務(wù)對象蟹腾，活動，會員等都可看做一個實體区宇。
實體的存在是為了業(yè)務(wù)分析娃殖，作為分析的一個篩選的維度，擁有描述自己的屬性议谷，本身具有可分析的價值炉爆。
2. 維度
維度就是看待問題的角度，分析業(yè)務(wù)數(shù)據(jù)卧晓，從什么角度分析芬首，就建立什么樣的維度。所以維度就是要對數(shù)據(jù)進(jìn)行分析時所用的一個量禀崖，比如你要分析產(chǎn)品銷售情況衩辟，你可以選擇按商品類別來進(jìn)行分析螟炫，這就構(gòu)成一個維度波附，把所有商品類別集合在一起，就構(gòu)成了維度表昼钻。
3. 度量
度量是業(yè)務(wù)流程節(jié)點上的一個數(shù)值掸屡。比如銷量，價格然评，成本等等仅财。
事實表中的度量可分為三類：完全可加，半可加碗淌，不可加盏求。
完全可加的度量是最靈活，最有用的亿眠，比如說銷量碎罚，銷售額等，可進(jìn)行任意維度匯總纳像；
半可加的度量可以對某些維度匯總荆烈，但不能對所有維度匯總，差額是常見的半可加度量竟趾，它除了時間維度外憔购，可以跨所有維度進(jìn)行加法操作；
還有一種是完全不可加的岔帽，例如：比率玫鸟。對于這類非可加度量，一種好的方法是犀勒，盡可能存儲非可加度量的完全可加分量鞋邑，并在計算出最終的非可加事實前诵次，將這些分量匯總到最終的結(jié)果集中。
4. 粒度
粒度就是業(yè)務(wù)流程中對度量的單位枚碗，比如商品是按件記錄度量逾一，還是按批記錄度量。
在數(shù)倉建設(shè)中肮雨，我們說這是用戶粒度的事實表遵堵，那么表中每行數(shù)據(jù)都是一個用戶，無重復(fù)用戶怨规；例如還有銷售粒度的表陌宿，那么表中每行都是一條銷售記錄。
選擇合適的粒度級別是數(shù)據(jù)倉庫建設(shè)好壞的重要關(guān)鍵內(nèi)容波丰，在設(shè)計數(shù)據(jù)粒度時壳坪，通常需重點考慮以下因素：
要接受的分析類型、可接受的數(shù)據(jù)最低粒度和能存儲的數(shù)據(jù)量掰烟；
粒度的層次定義越高爽蝴，就越不能在該倉庫中進(jìn)行更細(xì)致的分析；
如果存儲資源有一定的限制纫骑，就只能采用較高的數(shù)據(jù)粒度劃分蝎亚；
數(shù)據(jù)粒度劃分策略一定要保證：數(shù)據(jù)的粒度確實能夠滿足用戶的決策分析需要，這是數(shù)據(jù)粒度劃分策略中最重要的一個準(zhǔn)則先馆。
5. 口徑
口徑就是取數(shù)邏輯（如何取數(shù)的）发框，比如要取的數(shù)是10歲以下兒童中男孩的平均身高，這就是統(tǒng)計的口徑煤墙。
6. 指標(biāo)
指標(biāo)是口徑的衡量值梅惯，也就是最后的結(jié)果。比如最近七天的訂單量仿野，一個促銷活動的購買轉(zhuǎn)化率等铣减。
一個指標(biāo)具體到計算實施，主要有以下幾部分組成：
指標(biāo)加工邏輯设预，比如count ,sum, avg
維度徙歼，比如按部門、地域進(jìn)行指標(biāo)統(tǒng)計鳖枕，對應(yīng)sql中的group by
業(yè)務(wù)限定/修飾詞魄梯，比如以不同的支付渠道來算對應(yīng)的指標(biāo)，微信支付的訂單退款率宾符，支付寶支付的訂單退款率 酿秸。對應(yīng)sql中的where。
除此之外魏烫，指標(biāo)本身還可以衍生辣苏、派生出更多的指標(biāo)肝箱，基于這些特點，可以將指標(biāo)進(jìn)行分類：
原子指標(biāo)：基本業(yè)務(wù)事實稀蟋，沒有業(yè)務(wù)限定煌张、沒有維度。比如訂單表中的訂單量退客、訂單總金額都算原子指標(biāo)骏融；
業(yè)務(wù)方更關(guān)心的指標(biāo)，是有實際業(yè)務(wù)含義萌狂，可以直接取數(shù)據(jù)的指標(biāo)档玻。比如店鋪近1天訂單支付金額就是一個派生指標(biāo)，會被直接在產(chǎn)品上展示給商家看茫藏。
但是這個指標(biāo)卻不能直接從數(shù)倉的統(tǒng)一中間層里取數(shù)（因為沒有現(xiàn)成的事實字段误趴，數(shù)倉提供的一般都是大寬表）。需要有一個橋梁連接數(shù)倉中間層和業(yè)務(wù)方的指標(biāo)需求务傲，于是便有了派生指標(biāo)
派生指標(biāo)：維度+修飾詞+原子指標(biāo)凉当。 店鋪近1天訂單支付金額中店鋪是維度，近1天是一個時間類型的修飾詞树灶，支付金額是一個原子指標(biāo)纤怒；
維度：觀察各項指標(biāo)的角度糯而；
修飾詞：維度的一個或某些值天通，比如維度性別下，男和女就是2種修飾詞熄驼。
衍生指標(biāo)：比如某一個促銷活動的轉(zhuǎn)化率就是衍生指標(biāo)像寒，因為需要促銷投放人數(shù)指標(biāo)和促銷訂單數(shù)指標(biāo)進(jìn)行計算得出。
7. 標(biāo)簽
標(biāo)簽是人為設(shè)定的瓜贾、根據(jù)業(yè)務(wù)場景需求诺祸，對目標(biāo)對象運用一定的算法得到的高度精煉的特征標(biāo)識〖缆可見標(biāo)簽是經(jīng)過人為再加工后的結(jié)果筷笨，如網(wǎng)紅、白富美龟劲、蘿莉胃夏。對于有歧義的標(biāo)簽，我們內(nèi)部可進(jìn)行標(biāo)簽區(qū)分昌跌，比如：蘋果仰禀，我們可以定義蘋果指的是水果，蘋果手機才指的是手機蚕愤。
8. 自然鍵
由現(xiàn)實中已經(jīng)存在的屬性組成的鍵答恶，它在業(yè)務(wù)概念中是唯一的饺蚊，并具有一定的業(yè)務(wù)含義，比如商品ID悬嗓，員工ID污呼。
以數(shù)倉角度看券时，來自于業(yè)務(wù)系統(tǒng)的標(biāo)識符就是自然鍵逻族，比如業(yè)務(wù)庫中員工的編號。
9. 持久鍵
保持永久性不會發(fā)生變化度气。有時也被叫做超自然持久鍵映企。比如身份證號屬于持久鍵悟狱。
自然鍵和持久鍵區(qū)別：舉個例子就明白了，比如說公司員工離職之后又重新入職堰氓，他的自然鍵也就是員工編號發(fā)生了變化挤渐，但是他的持久鍵身份證號是不變的。
10. 代理鍵
就是不具有業(yè)務(wù)含義的鍵双絮。代理鍵有許多其他的稱呼：無意義鍵浴麻、整數(shù)鍵、非自然鍵囤攀、人工鍵软免、合成鍵等。
代理鍵就是簡單的以按照順序序列生產(chǎn)的整數(shù)表示焚挠。產(chǎn)品行的第1行代理鍵為1膏萧，則下一行的代理鍵為2，如此進(jìn)行蝌衔。代理鍵的作用僅僅是連接維度表和事實表榛泛。
11. 退化維度
退化維度，就是那些看起來像是事實表的一個維度關(guān)鍵字噩斟，但實際上并沒有對應(yīng)的維度表曹锨，就是維度屬性存儲到事實表中，這種存儲到事實表中的維度列被稱為退化維度剃允。與其他存儲在維表中的維度一樣沛简，退化維度也可以用來進(jìn)行事實表的過濾查詢、實現(xiàn)聚合操作等斥废。
那么究竟怎么定義退化維度呢椒楣？比如說訂單id，這種量級很大的維度营袜，沒必要用一張維度表來進(jìn)行存儲撒顿，而我們進(jìn)行數(shù)據(jù)查詢或者數(shù)據(jù)過濾的時候又非常需要，所以這種就冗余在事實表里面荚板，這種就叫退化維度凤壁，citycode這種我們也會冗余在事實表里面吩屹，但是它有對應(yīng)的維度表，所以它不是退化維度拧抖。
12. 下鉆
這是在數(shù)據(jù)分析中常見的概念煤搜，下鉆可以理解成增加維的層次，從而可以由粗粒度到細(xì)粒度來觀察數(shù)據(jù)唧席，比如對產(chǎn)品銷售情況分析時擦盾，可以沿著時間維從年到月到日更細(xì)粒度的觀察數(shù)據(jù)。從年的維度可以下鉆到月的維度淌哟、日的維度等迹卢。
13. 上卷
知道了下鉆，上卷就容易理解了徒仓，它倆是相逆的操作腐碱，所以上卷可以理解為刪掉維的某些層，由細(xì)粒度到粗粒度觀察數(shù)據(jù)的操作或沿著維的層次向上聚合匯總數(shù)據(jù)掉弛。
14. 數(shù)據(jù)集市
數(shù)據(jù)集市（Data Mart）症见，也叫數(shù)據(jù)市場，數(shù)據(jù)集市就是滿足特定的部門或者用戶的需求殃饿，按照多維的方式進(jìn)行存儲谋作，包括定義維度、需要計算的指標(biāo)乎芳、維度的層次等遵蚜，生成面向決策分析需求的數(shù)據(jù)立方體。其實就是從數(shù)據(jù)倉庫中抽取出來的一個小合集秒咐。
2. 數(shù)倉名詞之間關(guān)系
1. 實體表谬晕，事實表碘裕，維度表之間的關(guān)系
在Kimball維度建模中有維度與事實携取，在Inmon范式建模中有實體與關(guān)系，如果我們分開兩種建模方式看這些概念比較容易理解帮孔。但是目前也出現(xiàn)了不少混合建模方式雷滋，兩種建模方式結(jié)合起來看，這些概念是不是容易記憶混亂文兢，尤其事實表和實體表晤斩，它們之間到底有怎樣區(qū)別與聯(lián)系，先看下它們各自概念：
維度表：維度表可以看成是用戶用來分析一個事實的窗口姆坚，它里面的數(shù)據(jù)應(yīng)該是對事實的各個方面描述澳泵，比如時間維度表，地域維度表兼呵，維度表是事實表的一個分析角度兔辅。
事實表：事實表其實就是通過各種維度和一些指標(biāo)值的組合來確定一個事實的腊敲，比如通過時間維度，地域組織維度维苔，指標(biāo)值可以去確定在某時某地的一些指標(biāo)值怎么樣的事實碰辅。事實表的每一條數(shù)據(jù)都是幾條維度表的數(shù)據(jù)和指標(biāo)值交匯而得到的。
實體表：實體表就是一個實際對象的表介时，實體表放的數(shù)據(jù)一定是一條條客觀存在的事物數(shù)據(jù)没宾，比如說各種商品，它就是客觀存在的沸柔，所以可以將其設(shè)計一個實體表循衰。實時表只描述各個事物，并不存在具體的事實褐澎，所以也有人稱實體表是無事實的事實表羹蚣。
舉個例子：比如說手機商場中有蘋果手機，華為手機等各品牌各型號的手機乱凿，這些數(shù)據(jù)可以組成一個手機實體表顽素，但是表中沒有可度量的數(shù)據(jù)。某天蘋果手機賣了15臺徒蟆，華為手機賣了20臺胁出，這些手機銷售數(shù)據(jù)屬于事實，組成一個事實表段审。這樣就可以使用日期維度表和地域維度表對這個事實表進(jìn)行各種維度分析全蝶。
2. 指標(biāo)與標(biāo)簽的區(qū)別
概念不同
指標(biāo)是用來定義、評價和描述特定事物的一種標(biāo)準(zhǔn)或方式寺枉。比如：新增用戶數(shù)抑淫、累計用戶數(shù)、用戶活躍率等是衡量用戶發(fā)展情況的指標(biāo)姥闪；
標(biāo)簽是人為設(shè)定的始苇、根據(jù)業(yè)務(wù)場景需求，對目標(biāo)對象運用一定的算法得到的高度精煉的特征標(biāo)識筐喳〈呤剑可見標(biāo)簽是經(jīng)過人為再加工后的結(jié)果，如網(wǎng)紅避归、白富美荣月、蘿莉。
構(gòu)成不同
指標(biāo)名稱是對事物質(zhì)與量兩方面特點的命名梳毙；指標(biāo)取值是指標(biāo)在具體時間哺窄、地域、條件下的數(shù)量表現(xiàn)，如人的體重萌业，指標(biāo)名稱是體重蔑担，指標(biāo)的取值就是120斤；
標(biāo)簽名稱通常都是形容詞或形容詞+名詞的結(jié)構(gòu)咽白，標(biāo)簽一般是不可量化的啤握，通常是孤立的，除了基礎(chǔ)類標(biāo)簽晶框，通過一定算法加工出來的標(biāo)簽一般都沒有單位和量綱排抬。如將超過200斤的稱為大胖子。
分類不同
對指標(biāo)的分類：
按照指標(biāo)計算邏輯授段，可以將指標(biāo)分為原子指標(biāo)蹲蒲、派生指標(biāo)、衍生指標(biāo)三種類型侵贵；
按照對事件描述內(nèi)容的不同届搁，分為過程性指標(biāo)和結(jié)果性指標(biāo)；
對標(biāo)簽的分類：
按照標(biāo)簽的變化性分為靜態(tài)標(biāo)簽和動態(tài)標(biāo)簽窍育；
按照標(biāo)簽的指代和評估指標(biāo)的不同卡睦，可分為定性標(biāo)簽和定量標(biāo)簽；
指標(biāo)最擅長的應(yīng)用是監(jiān)測漱抓、分析表锻、評價和建模。
標(biāo)簽最擅長的應(yīng)用是標(biāo)注乞娄、刻畫瞬逊、分類和特征提取。
特別需要指出的是仪或，由于對結(jié)果的標(biāo)注也是一種標(biāo)簽确镊，所以在自然語言處理和機器學(xué)習(xí)相關(guān)的算法應(yīng)用場景下，標(biāo)簽對于監(jiān)督式學(xué)習(xí)有重要價值范删，只是單純的指標(biāo)難以做到的蕾域。而指標(biāo)在任務(wù)分配、績效管理等領(lǐng)域的作用瓶逃，也是標(biāo)簽無法做到的束铭。
3. 維度和指標(biāo)區(qū)別與聯(lián)系
維度就是數(shù)據(jù)的觀察角度，即從哪個角度去分析問題厢绝，看待問題。
指標(biāo)就是從維度的基礎(chǔ)上去衡算這個結(jié)果的值带猴。
維度一般是一個離散的值昔汉，比如時間維度上每一個獨立的日期或地域，因此統(tǒng)計時，可以把維度相同記錄的聚合在一起靶病，應(yīng)用聚合函數(shù)做累加会通、均值、最大值娄周、最小值等聚合計算涕侈。
指標(biāo)就是被聚合的通計算，即聚合運算的結(jié)果煤辨，一般是一個連續(xù)的值裳涛。
4. 自然鍵與代理鍵在數(shù)倉的使用區(qū)別
數(shù)倉工具箱中說維度表的唯一主鍵應(yīng)該是代理鍵而不應(yīng)該是自然鍵。有時建模人員不愿意放棄使用自然鍵众辨，因為他們希望與操作型代碼查詢事實表端三，而不希望與維度表做連接操作。然而鹃彻，應(yīng)該避免使用包含業(yè)務(wù)含義的多維鍵郊闯，因為不管我們做出任何假設(shè)最終都可能變得無效，因為我們控制不了業(yè)務(wù)庫的變動蛛株。
所以數(shù)據(jù)倉庫中維度表與事實表的每個連接應(yīng)該基于無實際含義的整數(shù)代理鍵团赁。避免使用自然鍵作為維度表的主鍵。
5. 數(shù)據(jù)集市和數(shù)據(jù)倉庫的關(guān)系
數(shù)據(jù)集市是企業(yè)級數(shù)據(jù)倉庫的一個子集谨履，他主要面向部門級業(yè)務(wù)然痊，并且只面向某個特定的主題。為了解決靈活性和性能之間的矛盾屉符，數(shù)據(jù)集市就是數(shù)據(jù)倉庫體系結(jié)構(gòu)中增加的一種小型的部門或工作組級別的數(shù)據(jù)倉庫剧浸。數(shù)據(jù)集市存儲為特定用戶預(yù)先計算好的數(shù)據(jù)，從而滿足用戶對性能的需求矗钟。數(shù)據(jù)集市可以在一定程度上緩解訪問數(shù)據(jù)倉庫的瓶頸唆香。
數(shù)據(jù)集市和數(shù)據(jù)倉庫的主要區(qū)別：數(shù)據(jù)倉庫是企業(yè)級的，能為整個企業(yè)各個部門的運行提供決策支持手段吨艇；而數(shù)據(jù)集市則是一種微型的數(shù)據(jù)倉庫,它通常有更少的數(shù)據(jù),更少的主題區(qū)域,以及更少的歷史數(shù)據(jù),因此是部門級的躬它，一般只能為某個局部范圍內(nèi)的管理人員服務(wù)，因此也稱之為部門級數(shù)據(jù)倉庫东涡。
文章都會首發(fā)在公眾號【五分鐘學(xué)大數(shù)據(jù)】
二冯吓、離線數(shù)倉建設(shè)核心
數(shù)據(jù)倉庫的核心是展現(xiàn)層和提供優(yōu)質(zhì)的服務(wù)。ETL 及其規(guī)范疮跑、分層等所做的一切都是為了一個更清晰易用的展現(xiàn)層组贺。
1. 數(shù)倉分層
數(shù)倉分層的原則：
為便于數(shù)據(jù)分析，要屏蔽底層復(fù)雜業(yè)務(wù)祖娘，簡單失尖、完整、集成的將數(shù)據(jù)暴露給分析層。
底層業(yè)務(wù)變動與上層需求變動對模型沖擊最小化掀潮，業(yè)務(wù)系統(tǒng)變化影響削弱在基礎(chǔ)數(shù)據(jù)層菇夸，結(jié)合自上而下的建設(shè)方法削弱需求變動對模型的影響。
高內(nèi)聚松耦合仪吧，即主題之內(nèi)或各個完整意義的系統(tǒng)內(nèi)數(shù)據(jù)的高內(nèi)聚庄新，主題之間或各個完整意義的系統(tǒng)間數(shù)據(jù)的松耦合。
構(gòu)建倉庫基礎(chǔ)數(shù)據(jù)層薯鼠，使底層業(yè)務(wù)數(shù)據(jù)整合工作與上層應(yīng)用開發(fā)工作相隔離择诈，為倉庫大規(guī)模開發(fā)奠定基礎(chǔ) 倉庫層次更加清晰，對外暴露數(shù)據(jù)更加統(tǒng)一人断。
一般采用如下分層結(jié)構(gòu)：
1. 數(shù)據(jù)源層：ODS（Operational Data Store）
ODS 層吭从，是最接近數(shù)據(jù)源中數(shù)據(jù)的一層，為了考慮后續(xù)可能需要追溯數(shù)據(jù)問題，因此對于這一層就不建議做過多的數(shù)據(jù)清洗工作，原封不動地接入原始數(shù)據(jù)即可枷颊，至于數(shù)據(jù)的去噪、去重步做、異常值處理等過程可以放在后面的 DWD 層來做。
2. 數(shù)據(jù)倉庫層：DW（Data Warehouse）
數(shù)據(jù)倉庫層是我們在做數(shù)據(jù)倉庫時要核心設(shè)計的一層奈附，在這里全度，從 ODS 層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型。
DW 層又細(xì)分為DWD（Data Warehouse Detail）層斥滤、DWM（Data WareHouse Middle）層和DWS（Data WareHouse Servce） 層将鸵。
1) 數(shù)據(jù)明細(xì)層：DWD（Data Warehouse Detail）
該層一般保持和 ODS 層一樣的數(shù)據(jù)粒度，并且提供一定的數(shù)據(jù)質(zhì)量保證佑颇。DWD 層要做的就是將數(shù)據(jù)清理顶掉、整合、規(guī)范化挑胸、臟數(shù)據(jù)痒筒、垃圾數(shù)據(jù)、規(guī)范不一致的茬贵、狀態(tài)定義不一致的簿透、命名不規(guī)范的數(shù)據(jù)都會被處理。
同時解藻，為了提高數(shù)據(jù)明細(xì)層的易用性老充，該層會采用一些維度退化手法，將維度退化至事實表中舆逃，減少事實表和維表的關(guān)聯(lián)蚂维。
另外戳粒，在該層也會做一部分的數(shù)據(jù)聚合路狮，將相同主題的數(shù)據(jù)匯集到一張表中虫啥，提高數(shù)據(jù)的可用性 。
2) 數(shù)據(jù)中間層：DWM（Data WareHouse Middle）
該層會在 DWD 層的數(shù)據(jù)基礎(chǔ)上奄妨，數(shù)據(jù)做輕度的聚合操作涂籽，生成一系列的中間表，提升公共指標(biāo)的復(fù)用性砸抛，減少重復(fù)加工评雌。
直觀來講，就是對通用的核心維度進(jìn)行聚合操作直焙，算出相應(yīng)的統(tǒng)計指標(biāo)景东。
在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統(tǒng)計指標(biāo)奔誓，會存在計算量太大并且維度太少的問題斤吐，因此一般的做法是，在 DWM 層先計算出多個小的中間表厨喂，然后再拼接成一張 DWS 的寬表和措。由于寬和窄的界限不易界定，也可以去掉 DWM 這一層蜕煌，只留 DWS 層派阱，將所有的數(shù)據(jù)再放在 DWS 亦可。
3) 數(shù)據(jù)服務(wù)層：DWS（Data WareHouse Servce）
DWS 層為公共匯總層斜纪，會進(jìn)行輕度匯總贫母，粒度比明細(xì)數(shù)據(jù)稍粗，基于 DWD 層上的基礎(chǔ)數(shù)據(jù)盒刚，整合匯總成分析某一個主題域的服務(wù)數(shù)據(jù)腺劣，一般是寬表。DWS 層應(yīng)覆蓋 80% 的應(yīng)用場景伪冰。又稱數(shù)據(jù)集市或?qū)挶怼?/p>
按照業(yè)務(wù)劃分誓酒，如主題域流量、訂單贮聂、用戶等靠柑，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務(wù)查詢吓懈，OLAP 分析歼冰，數(shù)據(jù)分發(fā)等。
一般來講耻警，該層的數(shù)據(jù)表會相對比較少隔嫡，一張表會涵蓋比較多的業(yè)務(wù)內(nèi)容甸怕，由于其字段較多，因此一般也會稱該層的表為寬表腮恩。
3. 數(shù)據(jù)應(yīng)用層：APP（Application）
在這里梢杭，主要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會存放在 ES秸滴、 PostgreSql武契、Redis 等系統(tǒng)中供線上系統(tǒng)使用，也可能會存在 Hive 或者 Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用荡含。比如我們經(jīng)常說的報表數(shù)據(jù)咒唆，一般就放在這里。
4. 維表層：DIM（Dimension）
如果維表過多释液，也可針對維表設(shè)計單獨一層全释，維表層主要包含兩部分?jǐn)?shù)據(jù)：
高基數(shù)維度數(shù)據(jù)：一般是用戶資料表、商品資料表類似的資料表误债。數(shù)據(jù)量可能是千萬級或者上億級別浸船。
低基數(shù)維度數(shù)據(jù)：一般是配置表，比如枚舉值對應(yīng)的中文含義找前，或者日期維表糟袁。 數(shù)據(jù)量可能是個位數(shù)或者幾千幾萬。
2. 數(shù)倉建模方法
數(shù)倉建模在哪層建設(shè)呢躺盛？我們以維度建模為例项戴，建模是在數(shù)據(jù)源層的下一層進(jìn)行建設(shè)，在上節(jié)的分層架構(gòu)中槽惫，就是在DW層進(jìn)行數(shù)倉建模周叮，所以DW層是數(shù)倉建設(shè)的核心層。
那數(shù)倉建模怎么建呢界斜？其實數(shù)據(jù)倉庫的建模方法有很多種仿耽，每一種建模方法代表了哲學(xué)上的一個觀點，代表了一種歸納各薇、概括世界的一種方法项贺。常見的有范式建模法、維度建模法峭判、實體建模法等开缎，每種方法從本質(zhì)上將是從不同的角度看待業(yè)務(wù)中的問題。
1. 范式建模法（Third Normal Form林螃，3NF）
范式建模法其實是我們在構(gòu)建數(shù)據(jù)模型常用的一個方法奕删，該方法的主要由 Inmon 所提倡，主要解決關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)存儲疗认，利用的一種技術(shù)層面上的方法完残。目前伏钠，我們在關(guān)系型數(shù)據(jù)庫中的建模方法，大部分采用的是三范式建模法谨设。
范式 是符合某一種級別的關(guān)系模式的集合熟掂。構(gòu)造數(shù)據(jù)庫必須遵循一定的規(guī)則，而在關(guān)系型數(shù)據(jù)庫中這種規(guī)則就是范式铝宵，這一過程也被稱為規(guī)范化打掘。目前關(guān)系數(shù)據(jù)庫有六種范式：第一范式（1NF）华畏、第二范式（2NF）鹏秋、第三范式（3NF）、Boyce-Codd范式（BCNF）亡笑、第四范式（4NF）和第五范式（5NF）侣夷。
在數(shù)據(jù)倉庫的模型設(shè)計中，一般采用第三范式仑乌。一個符合第三范式的關(guān)系必須具有以下三個條件 :
每個屬性值唯一百拓，不具有多義性 ;
每個非主屬性必須完全依賴于整個主鍵，而非主鍵的一部分 ;
每個非主屬性不能依賴于其他關(guān)系中的屬性晰甚，因為這樣的話衙传，這種屬性應(yīng)該歸到其他關(guān)系中去。
范式建模
根據(jù) Inmon 的觀點厕九，數(shù)據(jù)倉庫模型的建設(shè)方法和業(yè)務(wù)系統(tǒng)的企業(yè)數(shù)據(jù)模型類似蓖捶。在業(yè)務(wù)系統(tǒng)中，企業(yè)數(shù)據(jù)模型決定了數(shù)據(jù)的來源扁远，而企業(yè)數(shù)據(jù)模型也分為兩個層次俊鱼，即主題域模型和邏輯模型。同樣畅买，主題域模型可以看成是業(yè)務(wù)模型的概念模型并闲，而邏輯模型則是域模型在關(guān)系型數(shù)據(jù)庫上的實例化。
2. 維度建模法（Dimensional Modeling）
維度模型是數(shù)據(jù)倉庫領(lǐng)域另一位大師Ralph Kimall所倡導(dǎo)谷羞，他的《數(shù)據(jù)倉庫工具箱》是數(shù)據(jù)倉庫工程領(lǐng)域最流行的數(shù)倉建模經(jīng)典帝火。維度建模以分析決策的需求出發(fā)構(gòu)建模型，構(gòu)建的數(shù)據(jù)模型為分析需求服務(wù)湃缎，因此它重點解決用戶如何更快速完成分析需求犀填，同時還有較好的大規(guī)模復(fù)雜查詢的響應(yīng)性能。
維度建模
典型的代表是我們比較熟知的星形模型（Star-schema）雁歌，以及在一些特殊場景下適用的雪花模型（Snow-schema）宏浩。
維度建模中比較重要的概念就是 事實表（Fact table）和維度表（Dimension table）。其最簡單的描述就是靠瞎，按照事實表比庄、維度表來構(gòu)建數(shù)據(jù)倉庫求妹、數(shù)據(jù)集市。
3. 實體建模法（Entity Modeling）
實體建模法并不是數(shù)據(jù)倉庫建模中常見的一個方法佳窑，它來源于哲學(xué)的一個流派制恍。從哲學(xué)的意義上說，客觀世界應(yīng)該是可以細(xì)分的神凑，客觀世界應(yīng)該可以分成由一個個實體净神，以及實體與實體之間的關(guān)系組成。那么我們在數(shù)據(jù)倉庫的建模過程中完全可以引入這個抽象的方法溉委，將整個業(yè)務(wù)也可以劃分成一個個的實體鹃唯，而每個實體之間的關(guān)系，以及針對這些關(guān)系的說明就是我們數(shù)據(jù)建模需要做的工作瓣喊。
雖然實體法粗看起來好像有一些抽象坡慌，其實理解起來很容易。即我們可以將任何一個業(yè)務(wù)過程劃分成 3 個部分藻三，實體洪橘，事件，說明棵帽，如下圖所示：
實體建模
上圖表述的是一個抽象的含義熄求，如果我們描述一個簡單的事實：“小明開車去學(xué)校上學(xué)”。以這個業(yè)務(wù)事實為例逗概，我們可以把“小明”弟晚，“學(xué)校”看成是一個實體仗谆，“上學(xué)”描述的是一個業(yè)務(wù)過程指巡，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學(xué)”的一個說明隶垮。
3. 維度建模詳解
目前在互聯(lián)網(wǎng)公司最常用的建模方法就是維度建模藻雪，我們將重點講解！
維度建模是專門應(yīng)用于分析型數(shù)據(jù)庫狸吞、數(shù)據(jù)倉庫勉耀、數(shù)據(jù)集市建模的方法。數(shù)據(jù)集市可以理解為是一種"小型數(shù)據(jù)倉庫"蹋偏。
我們先不著急開始維度建模便斥，先來了解下維度建模中表的類型和維度建模的模式之后再開始建模，這樣能夠讓我們深刻理解威始！
1. 維度建模中表的類型
維度建模分為兩種表：事實表和維度表：
事實表：必然存在的一些數(shù)據(jù)枢纠，像采集的日志文件，訂單表黎棠，都可以作為事實表 晋渺。
特征：是一堆主鍵的集合镰绎，每個主鍵對應(yīng)維度表中的一條記錄，客觀存在的木西，根據(jù)主題確定出需要使用的數(shù)據(jù)
維度表：維度就是所分析的數(shù)據(jù)的一個量畴栖，維度表就是以合適的角度來創(chuàng)建的表，分析問題的一個角度：時間八千、地域吗讶、終端、用戶等角度
1. 事實表
發(fā)生在現(xiàn)實世界中的操作型事件恋捆，其所產(chǎn)生的可度量數(shù)值照皆，存儲在事實表中。從最低的粒度級別來看鸠信，事實表行對應(yīng)一個度量事件纵寝，反之亦然。
事實表表示對分析主題的度量星立。比如一次購買行為我們就可以理解為是一個事實。
事實與維度
圖中的訂單表就是一個事實表葬凳，你可以理解他就是在現(xiàn)實中發(fā)生的一次操作型事件绰垂，我們每完成一個訂單，就會在訂單中增加一條記錄火焰。
事實表的特征：表里沒有存放實際的內(nèi)容劲装，他是一堆主鍵的集合，這些ID分別能對應(yīng)到維度表中的一條記錄昌简。事實表包含了與各維度表相關(guān)聯(lián)的外鍵占业，可與維度表關(guān)聯(lián)。事實表的度量通常是數(shù)值類型纯赎，且記錄數(shù)會不斷增加谦疾，表數(shù)據(jù)規(guī)模迅速增長。
明細(xì)表（寬表）：
事實表的數(shù)據(jù)中犬金，有些屬性共同組成了一個字段（糅合在一起）念恍，比如年月日時分秒構(gòu)成了時間,當(dāng)需要根據(jù)某一屬性進(jìn)行分組統(tǒng)計的時候，需要截取拼接之類的操作，效率極低。
如：
local_time
2021-03-18 06:31:42
為了分析方便拆吆，可以事實表中的一個字段切割提取多個屬性出來構(gòu)成新的字段太惠，因為字段變多了，所以稱為寬表愧哟，原來的成為窄表。
將上述的local_time字段擴展為如下6個字段：
yearmonthdayhourms
20210318063142
又因為寬表的信息更加清晰明細(xì)讲逛，所以也可以稱之為明細(xì)表匣摘。
事實表種類
事實表分為以下6類：
事務(wù)事實表
周期快照事實表
累積快照事實表
無事實的事實表
聚集事實表
合并事實表
簡單解釋下每種表的概念：
事務(wù)事實表
表中的一行對應(yīng)空間或時間上某點的度量事件锅锨。就是一行數(shù)據(jù)中必須有度量字段，什么是度量恋沃，就是指標(biāo)必搞，比如說銷售金額，銷售數(shù)量等這些可加的或者半可加就是度量值囊咏。另一點就是事務(wù)事實表都包含一個與維度表關(guān)聯(lián)的外鍵恕洲。并且度量值必須和事務(wù)粒度保持一致。
周期快照事實表
顧名思義梅割，周期事實表就是每行都帶有時間值字段霜第，代表周期，通常時間值都是標(biāo)準(zhǔn)周期户辞，如某一天泌类，某周，某月等底燎。粒度是周期刃榨，而不是個體的事務(wù)，也就是說一個周期快照事實表中數(shù)據(jù)可以是多個事實双仍，但是它們都屬于某個周期內(nèi)枢希。
累計快照事實表
周期快照事實表是單個周期內(nèi)數(shù)據(jù)，而累計快照事實表是由多個周期數(shù)據(jù)組成朱沃，每行匯總了過程開始到結(jié)束之間的度量苞轿。每行數(shù)據(jù)相當(dāng)于管道或工作流，有事件的起點逗物，過程搬卒，終點，并且每個關(guān)鍵步驟都包含日期字段翎卓。如訂單數(shù)據(jù)契邀，累計快照事實表的一行就是一個訂單，當(dāng)訂單產(chǎn)生時插入一行莲祸，當(dāng)訂單發(fā)生變化時蹂安，這行就被修改。
無事實的事實表
我們以上討論的事實表度量都是數(shù)字化的锐帜，當(dāng)然實際應(yīng)用中絕大多數(shù)都是數(shù)字化的度量田盈，但是也可能會有少量的沒有數(shù)字化的值但是還很有價值的字段，無事實的事實表就是為這種數(shù)據(jù)準(zhǔn)備的缴阎，利用這種事實表可以分析發(fā)生了什么允瞧。
聚集事實表
聚集，就是對原子粒度的數(shù)據(jù)進(jìn)行簡單的聚合操作，目的就是為了提高查詢性能述暂。如我們需求是查詢?nèi)珖虚T店的總銷售額痹升，我們原子粒度的事實表中每行是每個分店每個商品的銷售額，聚集事實表就可以先聚合每個分店的總銷售額畦韭，這樣匯總所有門店的銷售額時計算的數(shù)據(jù)量就會小很多疼蛾。
合并事實表
這種事實表遵循一個原則，就是相同粒度艺配，數(shù)據(jù)可以來自多個過程察郁，但是只要它們屬于相同粒度，就可以合并為一個事實表转唉，這類事實表特別適合經(jīng)常需要共同分析的多過程度量皮钠。
2．維度表
每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關(guān)聯(lián)的任何事實表的外鍵赠法，當(dāng)然麦轰，維度表行的描述環(huán)境應(yīng)與事實表行完全對應(yīng)。維度表通常比較寬砖织，是扁平型非規(guī)范表款侵，包含大量的低粒度的文本屬性。
維度表示你要對數(shù)據(jù)進(jìn)行分析時所用的一個量镶苞，比如你要分析產(chǎn)品銷售情況喳坠， 你可以選擇按類別來進(jìn)行分析，或按區(qū)域來分析茂蚓。每個類別就構(gòu)成一個維度。上圖中的用戶表剃幌、商家表聋涨、時間表這些都屬于維度表，這些表都有一個唯一的主鍵负乡，然后在表中存放了詳細(xì)的數(shù)據(jù)信息牍白。
總的說來，在數(shù)據(jù)倉庫中不需要嚴(yán)格遵守規(guī)范化設(shè)計原則抖棘。因為數(shù)據(jù)倉庫的主導(dǎo)功能就是面向分析茂腥，以查詢?yōu)橹鳎簧婕皵?shù)據(jù)更新操作切省。事實表的設(shè)計是以能夠正確記錄歷史信息為準(zhǔn)則最岗，維度表的設(shè)計是以能夠以合適的角度來聚合主題內(nèi)容為準(zhǔn)則。
維度表結(jié)構(gòu)
維度表謹(jǐn)記一條原則朝捆，包含單一主鍵列般渡，但有時因業(yè)務(wù)復(fù)雜，也可能出現(xiàn)聯(lián)合主鍵，請盡量避免驯用，如果無法避免脸秽，也要確保必須是單一的，這很重要蝴乔，如果維表主鍵不是單一记餐，和事實表關(guān)聯(lián)時會出現(xiàn)數(shù)據(jù)發(fā)散，導(dǎo)致最后結(jié)果可能出現(xiàn)錯誤薇正。
維度表通常比較寬片酝，包含大量的低粒度的文本屬性。
跨表鉆取
跨表鉆取意思是當(dāng)每個查詢的行頭都包含相同的一致性屬性時铝穷，使不同的查詢能夠針對兩個或更多的事實表進(jìn)行查詢
鉆取可以改變維的層次钠怯，變換分析的粒度。它包括上鉆/下鉆：
上鉆（roll-up）：上卷是沿著維的層次向上聚集匯總數(shù)據(jù)曙聂。例如晦炊，對產(chǎn)品銷售數(shù)據(jù)，沿著時間維上卷宁脊，可以求出所有產(chǎn)品在所有地區(qū)每月（或季度或年或全部）的銷售額断国。
下鉆（drill-down）：下鉆是上鉆的逆操作，它是沿著維的層次向下榆苞，查看更詳細(xì)的數(shù)據(jù)稳衬。
退化維度
退化維度就是將維度退回到事實表中。因為有時維度除了主鍵沒有其他內(nèi)容坐漏，雖然也是合法維度鍵薄疚，但是一般都會退回到事實表中，減少關(guān)聯(lián)次數(shù)赊琳，提高查詢性能
多層次維度
多數(shù)維度包含不止一個自然層次街夭，如日期維度可以從天的層次到周到月到年的層次。所以在有些情況下躏筏，在同一維度中存在不同的層次板丽。
維度表空值屬性
當(dāng)給定維度行沒有被全部填充時，或者當(dāng)存在屬性沒有被應(yīng)用到所有維度行時趁尼，將產(chǎn)生空值維度屬性埃碱。上述兩種情況，推薦采用描述性字符串代替空值酥泞，如使用 unknown 或 not applicable 替換空值砚殿。
日歷日期維度
在日期維度表中，主鍵的設(shè)置不要使用順序生成的id來表示婶博，可以使用更有意義的數(shù)據(jù)表示瓮具，比如將年月日合并起來表示荧飞，即YYYYMMDD，或者更加詳細(xì)的精度名党。
2. 維度建模三種模式
1. 星型模式
星形模式(Star Schema)是最常用的維度建模方式叹阔。星型模式是以事實表為中心，所有的維度表直接連接在事實表上传睹，像星星一樣耳幢。星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：a. 維表只和事實表關(guān)聯(lián)欧啤，維表之間沒有關(guān)聯(lián)睛藻；b. 每個維表主鍵為單列，且該主鍵放置在事實表中邢隧，作為兩邊連接的外鍵店印；c. 以事實表為核心，維表圍繞核心呈星形分布倒慧；
2. 雪花模式
雪花模式(Snowflake Schema)是對星形模式的擴展按摘。雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規(guī)范一些纫谅，但是由于這種模型不太容易理解炫贤，維護成本比較高，而且性能方面需要關(guān)聯(lián)多層維表付秕，性能也比星型模型要低兰珍。所以一般不是很常用
雪花模式
3．星座模式
星座模式是星型模式延伸而來，星型模式是基于一張事實表的询吴，而星座模式是基于多張事實表的掠河，而且共享維度信息。前面介紹的兩種維度建模方法都是多維表對應(yīng)單事實表猛计，但在很多時候維度空間內(nèi)的事實表不止一個口柳，而一個維表也可能被多個事實表用到。在業(yè)務(wù)發(fā)展后期有滑，絕大部分維度建模都采用的是星座模式。
星座模型
3. 維度建模過程
我們知道維度建模的表類型有事實表嵌削，維度表毛好；模式有星形模型，雪花模型苛秕，星座模型這些概念了肌访，但是實際業(yè)務(wù)中，給了我們一堆數(shù)據(jù)艇劫，我們怎么拿這些數(shù)據(jù)進(jìn)行數(shù)倉建設(shè)呢吼驶，數(shù)倉工具箱作者根據(jù)自身60多年的實際業(yè)務(wù)經(jīng)驗，給我們總結(jié)了如下四步，請務(wù)必記仔费荨风钻！
數(shù)倉工具箱中的維度建模四步走：
維度建模四步走
請牢記以上四步，不管什么業(yè)務(wù)酒请，就按照這個步驟來骡技，順序不要搞亂，因為這四步是環(huán)環(huán)相扣羞反，步步相連布朦。下面詳細(xì)拆解下每個步驟怎么做
1、選擇業(yè)務(wù)過程
維度建模是緊貼業(yè)務(wù)的昼窗，所以必須以業(yè)務(wù)為根基進(jìn)行建模是趴，那么選擇業(yè)務(wù)過程，顧名思義就是在整個業(yè)務(wù)流程中選取我們需要建模的業(yè)務(wù)澄惊，根據(jù)運營提供的需求及日后的易擴展性等進(jìn)行選擇業(yè)務(wù)唆途。比如商城，整個商城流程分為商家端缤削，用戶端窘哈，平臺端，運營需求是總訂單量亭敢，訂單人數(shù)滚婉，及用戶的購買情況等，我們選擇業(yè)務(wù)過程就選擇用戶端的數(shù)據(jù)帅刀，商家及平臺端暫不考慮让腹。業(yè)務(wù)選擇非常重要，因為后面所有的步驟都是基于此業(yè)務(wù)數(shù)據(jù)展開的扣溺。
2骇窍、聲明粒度
先舉個例子：對于用戶來說，一個用戶有一個身份證號锥余，一個戶籍地址腹纳，多個手機號，多張銀行卡驱犹，那么與用戶粒度相同的粒度屬性有身份證粒度嘲恍，戶籍地址粒度，比用戶粒度更細(xì)的粒度有手機號粒度雄驹，銀行卡粒度佃牛，存在一對一的關(guān)系就是相同粒度。為什么要提相同粒度呢医舆，因為維度建模中要求我們俘侠，在同一事實表中象缀，必須具有相同的粒度，同一事實表中不要混用多種不同的粒度爷速，不同的粒度數(shù)據(jù)建立不同的事實表央星。并且從給定的業(yè)務(wù)過程獲取數(shù)據(jù)時，強烈建議從關(guān)注原子粒度開始設(shè)計遍希，也就是從最細(xì)粒度開始等曼，因為原子粒度能夠承受無法預(yù)期的用戶查詢。但是上卷匯總粒度對查詢性能的提升很重要的凿蒜，所以對于有明確需求的數(shù)據(jù)禁谦，我們建立針對需求的上卷匯總粒度，對需求不明朗的數(shù)據(jù)我們建立原子粒度废封。
3州泊、確認(rèn)維度
維度表是作為業(yè)務(wù)分析的入口和描述性標(biāo)識，所以也被稱為數(shù)據(jù)倉庫的“靈魂”漂洋。在一堆的數(shù)據(jù)中怎么確認(rèn)哪些是維度屬性呢遥皂，如果該列是對具體值的描述，是一個文本或常量刽漂，某一約束和行標(biāo)識的參與者演训，此時該屬性往往是維度屬性，數(shù)倉工具箱中告訴我們牢牢掌握事實表的粒度贝咙，就能將所有可能存在的維度區(qū)分開样悟，并且要確保維度表中不能出現(xiàn)重復(fù)數(shù)據(jù)，應(yīng)使維度主鍵唯一
4庭猩、確認(rèn)事實
事實表是用來度量的窟她，基本上都以數(shù)量值表示歼秽，事實表中的每行對應(yīng)一個度量幅聘，每行中的數(shù)據(jù)是一個特定級別的細(xì)節(jié)數(shù)據(jù)，稱為粒度蚤假。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度趴腋。這樣能確保不會出現(xiàn)重復(fù)計算度量的問題吊说。有時候往往不能確定該列數(shù)據(jù)是事實屬性還是維度屬性。記住最實用的事實就是數(shù)值類型和可加類事實优炬。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量疏叨，這種情況下該列往往是事實。
三穿剖、離線數(shù)倉建設(shè)實戰(zhàn)
技術(shù)是為業(yè)務(wù)服務(wù)的，業(yè)務(wù)是為公司創(chuàng)造價值的卦溢，離開業(yè)務(wù)的技術(shù)是無意義的
1. 業(yè)務(wù)介紹
需要針對不同需求的用戶開發(fā)不同的產(chǎn)品糊余，所以公司內(nèi)部有很多條業(yè)務(wù)線秀又，但是對于數(shù)據(jù)部門來說，所有業(yè)務(wù)線的數(shù)據(jù)都是數(shù)據(jù)源贬芥。對數(shù)據(jù)的劃分不只是根據(jù)業(yè)務(wù)進(jìn)行吐辙，而是結(jié)合數(shù)據(jù)的屬性。
2. 早期規(guī)劃
之前開發(fā)是不同業(yè)務(wù)線對應(yīng)不同的數(shù)據(jù)團隊蘸劈，每個數(shù)據(jù)團隊互不干擾昏苏，這種模式比較簡單，只針對自己的業(yè)務(wù)線進(jìn)行數(shù)倉建設(shè)及報表開發(fā)即可威沫。
但是隨著業(yè)務(wù)的發(fā)展贤惯，頻繁迭代及跨部門的垂直業(yè)務(wù)單元越來越多，業(yè)務(wù)之間的出現(xiàn)耦合情況棒掠，這時再采用這種煙囪式開發(fā)就出現(xiàn)了問題：
例如權(quán)限問題孵构，公司對數(shù)據(jù)管理比較嚴(yán)格，不同的數(shù)據(jù)開發(fā)組沒有權(quán)限共享數(shù)據(jù)烟很，需要其他業(yè)務(wù)線的數(shù)據(jù)權(quán)限需要上報審批颈墅，比較耽誤時間；
還有重復(fù)開發(fā)問題雾袱，不同業(yè)務(wù)線會出現(xiàn)相同的報表需求恤筛，如果每個業(yè)務(wù)方都開發(fā)各自的報表，太浪費資源芹橡。
所以對于數(shù)據(jù)開發(fā)而言毒坛，需要對各個業(yè)務(wù)線的數(shù)據(jù)進(jìn)行統(tǒng)一管理，所以就有了數(shù)據(jù)中臺的出現(xiàn)僻族。
3. 數(shù)據(jù)中臺
我認(rèn)為數(shù)據(jù)中臺是根據(jù)每個公司具體的業(yè)務(wù)需求而搭建的粘驰，不同的業(yè)務(wù)，對中臺的理解有所不同述么。
公司內(nèi)部開發(fā)的敏捷數(shù)據(jù)中臺蝌数，主要從數(shù)據(jù)技術(shù)和計算能力的復(fù)用，到數(shù)據(jù)資產(chǎn)和數(shù)據(jù)服務(wù)的復(fù)用度秘，數(shù)據(jù)中臺以更大價值帶寬顶伞，快準(zhǔn)精讓數(shù)據(jù)直接賦能業(yè)務(wù)。提供一個統(tǒng)一化的管理剑梳，打破數(shù)據(jù)孤島唆貌，追溯數(shù)據(jù)血緣，實現(xiàn)自助化及高復(fù)用度垢乙。
如下所示：
數(shù)據(jù)中臺
以上解釋比較抽象锨咙，我們以實際項目開發(fā)來看下數(shù)據(jù)中臺的便利性。
比如我們之前做報表開發(fā)流程追逮，首先是要數(shù)據(jù)采集酪刀，不同的數(shù)據(jù)源通過sqoop等工具采集到大數(shù)據(jù)平臺粹舵，然后進(jìn)行數(shù)倉搭建，最后產(chǎn)出報表數(shù)據(jù)骂倘，放到可視化系統(tǒng)展示眼滤，最終把整個流程寫成腳本放到調(diào)度平臺進(jìn)行自動化執(zhí)行。
而有了數(shù)據(jù)中臺之后就不需要那么繁瑣历涝，直接進(jìn)行數(shù)倉搭建诅需，產(chǎn)生報表即可，無需將精力過多放在數(shù)據(jù)源荧库、可視化展示及調(diào)度堰塌。并且可以直觀的查看數(shù)據(jù)血緣關(guān)系，計算表之間血緣电爹。像下面圖中蔫仙，表之間的依賴關(guān)系很明確：
數(shù)據(jù)中臺
另一點，數(shù)據(jù)中臺的異構(gòu)數(shù)據(jù)系統(tǒng)可以非常簡單的進(jìn)行關(guān)聯(lián)查詢丐箩，比如hive的表關(guān)聯(lián)mysql的表摇邦。
可透明屏蔽異構(gòu)數(shù)據(jù)系統(tǒng)異構(gòu)交互方式，輕松實現(xiàn)跨異構(gòu)數(shù)據(jù)系統(tǒng)透明混算屎勘。
異構(gòu)數(shù)據(jù)系統(tǒng)原理是數(shù)據(jù)中臺提供虛擬表到物理表之間的映射,終端用戶無需關(guān)心數(shù)據(jù)的物理存放位置和底層數(shù)據(jù)源的特性施籍，可直接操作數(shù)據(jù)，體驗類似操作一個虛擬數(shù)據(jù)庫概漱。
數(shù)據(jù)中臺額外集成可視化展示丑慎，提供一站式數(shù)據(jù)可視化解決方案，支持JDBC數(shù)據(jù)源和CSV文件上傳瓤摧，支持基于數(shù)據(jù)模型拖拽智能生成可視化組件竿裂，大屏展示自適應(yīng)不同大小屏幕。
調(diào)度系統(tǒng)是公司內(nèi)部自寫集成到數(shù)據(jù)中臺的照弥，在編寫完sql語句之后可以直接進(jìn)行調(diào)度腻异。
4. 數(shù)倉建設(shè)
到這才真正到數(shù)倉建設(shè)，為什么前面我要占那么大篇幅去介紹公司業(yè)務(wù)及所使用的數(shù)據(jù)中臺系統(tǒng)这揣，因為下面的數(shù)倉建設(shè)是根據(jù)公司的業(yè)務(wù)發(fā)展及現(xiàn)有的數(shù)據(jù)中臺進(jìn)行悔常，數(shù)倉的建設(shè)離不開公司的業(yè)務(wù)。
智能數(shù)倉規(guī)劃
數(shù)倉建設(shè)核心思想：從設(shè)計给赞、開發(fā)机打、部署和使用層面，避免重復(fù)建設(shè)和指標(biāo)冗余建設(shè)片迅，從而保障數(shù)據(jù)口徑的規(guī)范和統(tǒng)一残邀，最終實現(xiàn)數(shù)據(jù)資產(chǎn)全鏈路關(guān)聯(lián)、提供標(biāo)準(zhǔn)數(shù)據(jù)輸出以及建立統(tǒng)一的數(shù)據(jù)公共層。有了核心思想罐旗，那怎么開始數(shù)倉建設(shè)膳汪，有句話說數(shù)倉建設(shè)者即是技術(shù)專家，也是大半個業(yè)務(wù)專家九秀，所以采用的方式就是需求推動數(shù)據(jù)建設(shè)，并且因為數(shù)據(jù)中臺粘我，所以各業(yè)務(wù)知識體系比較集中鼓蜒，各業(yè)務(wù)數(shù)據(jù)不再分散，加快了數(shù)倉建設(shè)速度征字。
數(shù)倉建設(shè)主要從兩個方面進(jìn)行都弹，模型和規(guī)范，所有業(yè)務(wù)進(jìn)行統(tǒng)一化
模型
所有業(yè)務(wù)采用統(tǒng)一的模型體系匙姜，從而降低研發(fā)成本畅厢，增強指標(biāo)復(fù)用，并且能保證數(shù)據(jù)口徑的統(tǒng)一
模型分層
結(jié)合公司業(yè)務(wù)氮昧，后期新增需求較多框杜，所以分層不宜過多，并且需要清晰明確各層職責(zé)袖肥，要保證數(shù)據(jù)層的穩(wěn)定又要屏蔽對下游影響咪辱，所以采用如下分層結(jié)構(gòu)：
數(shù)據(jù)分層架構(gòu)
數(shù)據(jù)流向
遵循模型開發(fā)時分層結(jié)構(gòu)，數(shù)據(jù)從 ods -> dw -> dm ->app 這樣正向流動椎组，可以防止因數(shù)據(jù)引用不規(guī)范而造成數(shù)據(jù)鏈路混亂及SLA時效難保障等問題油狂，同時保證血緣關(guān)系簡潔化，能夠輕易追蹤數(shù)據(jù)流向寸癌。
在開發(fā)時應(yīng)避免以下情況出現(xiàn)：
數(shù)據(jù)引用鏈路不正確专筷，如 ods -> dm ->app ，出現(xiàn)這種情況說明明細(xì)層沒有完全覆蓋數(shù)據(jù)蒸苇；如 ods -> dw -> app 磷蛹，說明輕度匯總層主題劃分未覆蓋全 。減少跨層引用填渠，才能提高中間表的復(fù)用度弦聂。理想的數(shù)倉模型設(shè)計應(yīng)當(dāng)具備：數(shù)據(jù)模型可復(fù)?，完善且規(guī)范氛什。
盡量避免一層的表生成當(dāng)前層的表莺葫，如dw層表生成dw層表，這樣會影響ETL效率枪眉。
禁止出現(xiàn)反向依賴捺檬，如dw表依賴于dm表。
規(guī)范
表命名規(guī)范
對于ods贸铜、dm堡纬、app層表名：類型_主題_表含義聂受，如：dm_xxsh_user
對于dw層表名：類型_主題_維度_表含義，如：dw_xxsh_fact_users（事實表）烤镐、dw_xxsh_dim_city（維度表）
字段命名規(guī)范
構(gòu)建詞根蛋济，詞根是維度和指標(biāo)管理的基礎(chǔ)，劃分為普通詞根與專有詞根
普通詞根：描述事物的最小單元體炮叶，如：sex-性別碗旅。
專有詞根：具備行業(yè)專屬或公司內(nèi)部規(guī)定的描述體，如：xxsh-公司內(nèi)部對某個產(chǎn)品的稱呼镜悉。
腳本命名規(guī)范
腳本名稱：腳本類型.腳本功用.[庫名].腳本名稱祟辟，如 hive.hive.dm.dm_xxsh_users
腳本類型主要分為以下三類：
常規(guī)Hive sql：hive
自定義shell腳本：sh
自定義Python腳本：python
腳本內(nèi)容規(guī)范
#變量的定義要符合python的語法要求
#指定任務(wù)負(fù)責(zé)人
owner?="zhangsan@xxx.com"
#腳本存放目錄/opt/xxx
#腳本名稱?hive.hive.dm.dm_xxsh_users
#source用來標(biāo)識上游依賴表，一個任務(wù)如果有多個上游表侣肄，都需要寫進(jìn)去
#(xxx_name?是需要改動的旧困，其余不需要改)
source=?{
"table_name":?{
"db":"db_name",
"table":"table_name"
}
}
#如source，但是每個任務(wù)target只有一張表
target?=?{
"db_table":?{
"host":"hive",
"db":"db_name",
"table":"table_name"
}
}
#變量列表
#$now
#$now.date?常用稼锅，格式示例：2020-12-11
task?='''
寫sql代碼
'
''
5. 數(shù)據(jù)層具體實現(xiàn)
使用四張圖說明每層的具體實現(xiàn)
數(shù)據(jù)源層ODS
數(shù)據(jù)源層
數(shù)據(jù)源層主要將各個業(yè)務(wù)數(shù)據(jù)導(dǎo)入到大數(shù)據(jù)平臺吼具，作為業(yè)務(wù)數(shù)據(jù)的快照存儲。
數(shù)據(jù)明細(xì)層DW
數(shù)據(jù)明細(xì)層
事實表中的每行對應(yīng)一個度量缰贝，每行中的數(shù)據(jù)是一個特定級別的細(xì)節(jié)數(shù)據(jù)馍悟，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度剩晴。這樣能確保不會出現(xiàn)重復(fù)計算度量的問題锣咒。
維度表一般都是單一主鍵，少數(shù)是聯(lián)合主鍵赞弥，注意維度表不要出現(xiàn)重復(fù)數(shù)據(jù)毅整，否則和事實表關(guān)聯(lián)會出現(xiàn)數(shù)據(jù)發(fā)散問題。
有時候往往不能確定該列數(shù)據(jù)是事實屬性還是維度屬性绽左。記住最實用的事實就是數(shù)值類型和可加類事實悼嫉。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實拼窥；如果該列是對具體值的描述戏蔑，是一個文本或常量，某一約束和行標(biāo)識的參與者鲁纠，此時該屬性往往是維度屬性总棵。但是還是要結(jié)合業(yè)務(wù)進(jìn)行最終判斷是維度還是事實。
數(shù)據(jù)輕度匯總層DM
數(shù)據(jù)輕度匯總層
此層命名為輕匯總層改含，就代表這一層已經(jīng)開始對數(shù)據(jù)進(jìn)行匯總情龄，但是不是完全匯總，只是對相同粒度的數(shù)據(jù)進(jìn)行關(guān)聯(lián)匯總，不同粒度但是有關(guān)系的數(shù)據(jù)也可進(jìn)行匯總骤视，此時需要將粒度通過聚合等操作進(jìn)行統(tǒng)一鞍爱。
數(shù)據(jù)應(yīng)用層APP
數(shù)據(jù)應(yīng)用層
數(shù)據(jù)應(yīng)用層的表就是提供給用戶使用的，數(shù)倉建設(shè)到此就接近尾聲了专酗，接下來就根據(jù)不同的需求進(jìn)行不同的取數(shù)睹逃，如直接進(jìn)行報表展示，或提供給數(shù)據(jù)分析的同事所需的數(shù)據(jù)祷肯，或其他的業(yè)務(wù)支撐唯卖。
6. 總結(jié)
一張圖總結(jié)下數(shù)據(jù)倉庫的構(gòu)建整體流程：
數(shù)據(jù)中臺
7. 實際生產(chǎn)中注意事項
生產(chǎn)環(huán)境中操作不能像我們自己測試時那樣隨意，一不小心都可能造成生產(chǎn)事故躬柬。所以每步操作都要十分小心，需全神貫注抽减，管好大腦管住右手允青。
僅列出以下但不限于以下的注意事項：
請勿操作自己管理及授權(quán)表之外的其它庫表；
未經(jīng)授權(quán)卵沉，請勿操作生產(chǎn)環(huán)境中其他人的腳本及文件颠锉；
在修改生產(chǎn)環(huán)境腳本前，請務(wù)必自行備份到本地史汗；
請確認(rèn)自己的修改操作能迅速回滾琼掠；
生產(chǎn)環(huán)境中表名及字段等所有命名請遵循命名規(guī)則。
推薦閱讀：
結(jié)合公司業(yè)務(wù)分析離線數(shù)倉建設(shè)
數(shù)倉建設(shè)中最常用模型--Kimball維度建模詳解
四停撞、實時計算
實時計算一般都是針對海量數(shù)據(jù)進(jìn)行的瓷蛙，并且要求為秒級。由于大數(shù)據(jù)興起之初戈毒，Hadoop并沒有給出實時計算解決方案艰猬，隨后Storm，SparkStreaming埋市，F(xiàn)link等實時計算框架應(yīng)運而生冠桃，而Kafka，ES的興起使得實時計算領(lǐng)域的技術(shù)越來越完善道宅，而隨著物聯(lián)網(wǎng)食听，機器學(xué)習(xí)等技術(shù)的推廣，實時流式計算將在這些領(lǐng)域得到充分的應(yīng)用污茵。
實時計算的三個特征：
無限數(shù)據(jù)：無限數(shù)據(jù)指的是一種不斷增長的樱报，基本上無限的數(shù)據(jù)集。這些通常被稱為“流數(shù)據(jù)”省咨，而與之相對的是有限的數(shù)據(jù)集肃弟。
無界數(shù)據(jù)處理：一種持續(xù)的數(shù)據(jù)處理模式,能夠通過處理引擎重復(fù)的去處理上面的無限數(shù)據(jù)，是能夠突破有限數(shù)據(jù)處理引擎的瓶頸的。
低延遲：延遲是多少并沒有明確的定義笤受。但我們都知道數(shù)據(jù)的價值將隨著時間的流逝降低穷缤，時效性將是需要持續(xù)解決的問題。
現(xiàn)在大數(shù)據(jù)應(yīng)用比較火爆的領(lǐng)域箩兽，比如推薦系統(tǒng)在實踐之初受技術(shù)所限津肛，可能要一分鐘，一小時汗贫，甚至更久對用戶進(jìn)行推薦身坐，這遠(yuǎn)遠(yuǎn)不能滿足需要，我們需要更快的完成對數(shù)據(jù)的處理落包，而不是進(jìn)行離線的批處理部蛇。
1. 實時計算應(yīng)用場景
隨著實時技術(shù)發(fā)展趨于成熟，實時計算應(yīng)用越來越廣泛咐蝇，以下僅列舉常見的幾種實時計算的應(yīng)用場景：
1. 實時智能推薦
智能推薦會根據(jù)用戶歷史的購買或瀏覽行為涯鲁，通過推薦算法訓(xùn)練模型，預(yù)測用戶未來可能會購買的物品或喜愛的資訊有序。對個人來說抹腿，推薦系統(tǒng)起著信息過濾的作用，對Web/App服務(wù)端來說旭寿，推薦系統(tǒng)起著滿足用戶個性化需求警绩，提升用戶滿意度的作用。推薦系統(tǒng)本身也在飛速發(fā)展盅称，除了算法越來越完善肩祥，對時延的要求也越來越苛刻和實時化。利用Flink流計算幫助用戶構(gòu)建更加實時的智能推薦系統(tǒng)微渠，對用戶行為指標(biāo)進(jìn)行實時計算搭幻，對模型進(jìn)行實時更新，對用戶指標(biāo)進(jìn)行實時預(yù)測逞盆，并將預(yù)測的信息推送給Web/App端檀蹋，幫助用戶獲取想要的商品信息，另一方面也幫助企業(yè)提升銷售額云芦，創(chuàng)造更大的商業(yè)價值俯逾。
2. 實時欺詐檢測
在金融領(lǐng)域的業(yè)務(wù)中，常常出現(xiàn)各種類型的欺詐行為，例如信用卡欺詐，信貸申請欺詐等舱禽，而如何保證用戶和公司的資金安全，是近年來許多金融公司及銀行共同面對的挑戰(zhàn)坠七。隨著不法分子欺詐手段的不斷升級水醋，傳統(tǒng)的反欺詐手段已經(jīng)不足以解決目前所面臨的問題。以往可能需要幾個小時才能通過交易數(shù)據(jù)計算出用戶的行為指標(biāo)彪置，然后通過規(guī)則判別出具有欺詐行為嫌疑的用戶拄踪，再進(jìn)行案件調(diào)查處理，在這種情況下資金可能早已被不法分子轉(zhuǎn)移拳魁，從而給企業(yè)和用戶造成大量的經(jīng)濟損失惶桐。而運用Flink流式計算技術(shù)能夠在毫秒內(nèi)就完成對欺詐行為判斷指標(biāo)的計算，然后實時對交易流水進(jìn)行實時攔截潘懊，避免因為處理不及時而導(dǎo)致的經(jīng)濟損失姚糊。
3. 輿情分析
有的客戶需要做輿情分析，要求所有數(shù)據(jù)存放若干年授舟，輿情數(shù)據(jù)每日數(shù)據(jù)量可能超百萬救恨，年數(shù)據(jù)量可達(dá)到幾十億的數(shù)據(jù)。而且爬蟲爬過來的數(shù)據(jù)是輿情释树，通過大數(shù)據(jù)技術(shù)進(jìn)行分詞之后得到的可能是大段的網(wǎng)友評論忿薇，客戶往往要求對輿情進(jìn)行查詢，做全文本搜索躏哩，并要求響應(yīng)時間控制在秒級。爬蟲將數(shù)據(jù)爬到大數(shù)據(jù)平臺的Kafka里揉燃，在里面做Flink流處理扫尺，去重去噪做語音分析，寫到ElasticSearch里炊汤。大數(shù)據(jù)的一個特點是多數(shù)據(jù)源正驻，大數(shù)據(jù)平臺能根據(jù)不同的場景選擇不同的數(shù)據(jù)源。
4. 復(fù)雜事件處理
對于復(fù)雜事件處理抢腐，比較常見的集中于工業(yè)領(lǐng)域姑曙，例如對車載傳感器，機械設(shè)備等實時故障檢測迈倍，這些業(yè)務(wù)類型通常數(shù)據(jù)量都非常大伤靠，且對數(shù)據(jù)處理的時效性要求非常高。通過利用Flink提供的CEP進(jìn)行時間模式的抽取啼染，同時應(yīng)用Flink的Sql進(jìn)行事件數(shù)據(jù)的轉(zhuǎn)換宴合，在流式系統(tǒng)中構(gòu)建實施規(guī)則引擎，一旦事件觸發(fā)報警規(guī)則迹鹅，便立即將告警結(jié)果通知至下游通知系統(tǒng)卦洽，從而實現(xiàn)對設(shè)備故障快速預(yù)警檢測，車輛狀態(tài)監(jiān)控等目的斜棚。
5. 實時機器學(xué)習(xí)
實時機器學(xué)習(xí)是一個更寬泛的概念阀蒂，傳統(tǒng)靜態(tài)的機器學(xué)習(xí)主要側(cè)重于靜態(tài)的模型和歷史數(shù)據(jù)進(jìn)行訓(xùn)練并提供預(yù)測该窗。很多時候用戶的短期行為，對模型有修正作用蚤霞，或者說是對業(yè)務(wù)判斷有預(yù)測作用酗失。對系統(tǒng)來說，需要采集用戶最近的行為并進(jìn)行特征工程争便，然后給到實時機器學(xué)習(xí)系統(tǒng)進(jìn)行機器學(xué)習(xí)级零。如果動態(tài)地實施新規(guī)則，或是推出新廣告滞乙，就會有很大的參考價值奏纪。
2. 實時計算總覽
我們先來看一張大數(shù)據(jù)平臺的實時架構(gòu)圖：
數(shù)據(jù)同步：
在上面這張架構(gòu)圖中，數(shù)據(jù)從Web平臺中產(chǎn)生斩启，通過數(shù)據(jù)同步系統(tǒng)導(dǎo)入到大數(shù)據(jù)平臺序调，由于數(shù)據(jù)源不同，這里的數(shù)據(jù)同步系統(tǒng)實際上是多個相關(guān)系統(tǒng)的組合兔簇。數(shù)據(jù)庫同步通常用 Sqoop发绢，日志同步可以選擇 Flume等，不同的數(shù)據(jù)源產(chǎn)生的數(shù)據(jù)質(zhì)量可能差別很大垄琐，數(shù)據(jù)庫中的格式化數(shù)據(jù)直接導(dǎo)入大數(shù)據(jù)系統(tǒng)即可边酒，而日志和爬蟲產(chǎn)生的數(shù)據(jù)就需要進(jìn)行大量的清洗、轉(zhuǎn)化處理才能有效使用狸窘。
數(shù)據(jù)存儲：
該層對原始數(shù)據(jù)墩朦、清洗關(guān)聯(lián)后的明細(xì)數(shù)據(jù)進(jìn)行存儲，基于統(tǒng)一的實時數(shù)據(jù)模型分層理念翻擒，將不同應(yīng)用場景的數(shù)據(jù)分別存儲在 Kafka氓涣、HDFS、Kudu陋气、 Clickhouse劳吠、Hbase等存儲中。
數(shù)據(jù)計算：
計算層主要使用 Flink巩趁、Spark痒玩、Presto 以及 ClickHouse 自帶的計算能力等四種計算引擎，F(xiàn)link 計算引擎主要用于實時數(shù)據(jù)同步议慰、 流式 ETL凰荚、關(guān)鍵系統(tǒng)秒級實時指標(biāo)計算場景，Spark SQL 主要用于復(fù)雜多維分析的準(zhǔn)實時指標(biāo)計算需求場景褒脯，Presto 和 ClickHouse 主要滿足多維自助分析便瑟、對查詢響應(yīng)時間要求不太高的場景。
實時應(yīng)用：
以統(tǒng)一查詢服務(wù)對各個業(yè)務(wù)線數(shù)據(jù)場景進(jìn)行支持番川，業(yè)務(wù)主要包括實時大屏到涂、實時數(shù)據(jù)產(chǎn)品脊框、實時 OLAP、實時特征等践啄。
當(dāng)然一個好的大數(shù)據(jù)平臺不能缺少元數(shù)據(jù)管理及數(shù)據(jù)治理：
1. 元數(shù)據(jù)及指標(biāo)管理：主要對實時的Kafka表浇雹、Kudu表、Clickhouse表屿讽、Hive表等進(jìn)行統(tǒng)一管理昭灵，以數(shù)倉模型中表的命名方式規(guī)范表的命名，明確每張表的字段含義伐谈、使用方烂完，指標(biāo)管理則是盡量通過指標(biāo)管理系統(tǒng)將所有的實時指標(biāo)統(tǒng)一管理起來，明確計算口徑诵棵，提供給不同的業(yè)務(wù)方使用抠蚣；
2. 數(shù)據(jù)質(zhì)量及血緣分析：數(shù)據(jù)質(zhì)量分為平臺監(jiān)控和數(shù)據(jù)監(jiān)控兩個部分，血緣分析則主要是對實時數(shù)據(jù)依賴關(guān)系履澳、實時任務(wù)的依賴關(guān)系進(jìn)行分析嘶窄。
以上架構(gòu)只是大數(shù)據(jù)平臺通用的數(shù)據(jù)模型，如果要具體的建設(shè)距贷，需要考慮以下情況柄冲，業(yè)務(wù)需求需要實時還是準(zhǔn)實時即可，數(shù)據(jù)時效性是秒級還是分鐘級等忠蝗。
在調(diào)度開銷方面羊初，準(zhǔn)實時數(shù)據(jù)是批處理過程，因此仍然需要調(diào)度系統(tǒng)支持什湘，調(diào)度頻率較高，而實時數(shù)據(jù)卻沒有調(diào)度開銷晦攒；
在業(yè)務(wù)靈活性方面闽撤，因為準(zhǔn)實時數(shù)據(jù)是基于 ETL 或 OLAP 引擎實現(xiàn)，靈活性優(yōu)于基于流計算的方式脯颜；
在對數(shù)據(jù)晚到的容忍度方面哟旗，因為準(zhǔn)實時數(shù)據(jù)可以基于一個周期內(nèi)的數(shù)據(jù)進(jìn)行全量計算，因此對于數(shù)據(jù)晚到的容忍度也是比較高的栋操，而實時數(shù)據(jù)使用的是增量計算闸餐，對于數(shù)據(jù)晚到的容忍度更低一些；
在適用場景方面矾芙，準(zhǔn)實時數(shù)據(jù)主要用于有實時性要求但不太高舍沙、涉及多表關(guān)聯(lián)和業(yè)務(wù)變更頻繁的場景，如交易類型的實時分析剔宪，實時數(shù)據(jù)則更適用于實時性要求高拂铡、數(shù)據(jù)量大的場景壹无，如實時特征、流量類型實時分析等場景感帅。
3. 實時架構(gòu)
在某些場景中斗锭，數(shù)據(jù)的價值隨著時間的推移而逐漸減少。所以在傳統(tǒng)大數(shù)據(jù)離線數(shù)倉的基礎(chǔ)上失球，逐漸對數(shù)據(jù)的實時性提出了更高的要求岖是。
于是隨之誕生了大數(shù)據(jù)實時數(shù)倉，并且衍生出了兩種技術(shù)架構(gòu)Lambda和Kappa实苞。
1. Lambda架構(gòu)
先來看下Lambda架構(gòu)圖：
Lambda架構(gòu)圖
數(shù)據(jù)從底層的數(shù)據(jù)源開始豺撑，經(jīng)過Kafka、Flume等數(shù)據(jù)組件進(jìn)行收集硬梁，然后分成兩條線進(jìn)行計算：
一條線是進(jìn)入流式計算平臺（例如 Storm前硫、Flink或者SparkStreaming），去計算實時的一些指標(biāo)荧止；
另一條線進(jìn)入批量數(shù)據(jù)處理離線計算平臺（例如Mapreduce屹电、Hive，Spark SQL）跃巡，去計算T+1的相關(guān)業(yè)務(wù)指標(biāo)危号，這些指標(biāo)需要隔日才能看見。
為什么Lambda架構(gòu)要分成兩條線計算素邪？
假如整個系統(tǒng)只有一個批處理層外莲，會導(dǎo)致用戶必須等待很久才能獲取計算結(jié)果，一般有幾個小時的延遲兔朦。電商數(shù)據(jù)分析部門只能查看前一天的統(tǒng)計分析結(jié)果偷线，無法獲取當(dāng)前的結(jié)果，這對于實時決策來說有一個巨大的時間鴻溝沽甥，很可能導(dǎo)致管理者錯過最佳決策時機声邦。
Lambda架構(gòu)屬于較早的一種架構(gòu)方式，早期的流處理不如現(xiàn)在這樣成熟摆舟，在準(zhǔn)確性亥曹、擴展性和容錯性上，流處理層無法直接取代批處理層恨诱，只能給用戶提供一個近似結(jié)果媳瞪，還不能為用戶提供一個一致準(zhǔn)確的結(jié)果。因此Lambda架構(gòu)中照宝，出現(xiàn)了批處理和流處理并存的現(xiàn)象蛇受。
在 Lambda 架構(gòu)中，每層都有自己所肩負(fù)的任務(wù)厕鹃。
1. 批處理層存儲管理主數(shù)據(jù)集（不可變的數(shù)據(jù)集）和預(yù)先批處理計算好的視圖：
批處理層使用可處理大量數(shù)據(jù)的分布式處理系統(tǒng)預(yù)先計算結(jié)果龙巨。它通過處理所有的已有歷史數(shù)據(jù)來實現(xiàn)數(shù)據(jù)的準(zhǔn)確性笼呆。這意味著它是基于完整的數(shù)據(jù)集來重新計算的，能夠修復(fù)任何錯誤旨别，然后更新現(xiàn)有的數(shù)據(jù)視圖诗赌。輸出通常存儲在只讀數(shù)據(jù)庫中，更新則完全取代現(xiàn)有的預(yù)先計算好的視圖秸弛。
2. 流處理層會實時處理新來的大數(shù)據(jù)：
流處理層通過提供最新數(shù)據(jù)的實時視圖來最小化延遲铭若。流處理層所生成的數(shù)據(jù)視圖可能不如批處理層最終生成的視圖那樣準(zhǔn)確或完整，但它們幾乎在收到數(shù)據(jù)后立即可用递览。而當(dāng)同樣的數(shù)據(jù)在批處理層處理完成后叼屠，在速度層的數(shù)據(jù)就可以被替代掉了。
那Lambda架構(gòu)有沒有缺點呢绞铃？
Lambda架構(gòu)經(jīng)歷多年的發(fā)展镜雨，其優(yōu)點是穩(wěn)定，對于實時計算部分的計算成本可控儿捧，批量處理可以用晚上的時間來整體批量計算荚坞，這樣把實時計算和離線計算高峰分開，這種架構(gòu)支撐了數(shù)據(jù)行業(yè)的早期發(fā)展菲盾，但是它也有一些致命缺點颓影，并在大數(shù)據(jù)3.0時代越來越不適應(yīng)數(shù)據(jù)分析業(yè)務(wù)的需求。缺點如下：
使用兩套大數(shù)據(jù)處理引擎：維護兩個復(fù)雜的分布式系統(tǒng)懒鉴，成本非常高诡挂。
批量計算在計算窗口內(nèi)無法完成：在IOT時代，數(shù)據(jù)量級越來越大临谱，經(jīng)常發(fā)現(xiàn)夜間只有4璃俗、5個小時的時間窗口，已經(jīng)無法完成白天20多個小時累計的數(shù)據(jù)悉默，保證早上上班前準(zhǔn)時出數(shù)據(jù)已成為每個大數(shù)據(jù)團隊頭疼的問題城豁。
數(shù)據(jù)源變化都要重新開發(fā)，開發(fā)周期長：每次數(shù)據(jù)源的格式變化麦牺，業(yè)務(wù)的邏輯變化都需要針對ETL和Streaming做開發(fā)修改，整體開發(fā)周期很長鞭缭，業(yè)務(wù)反應(yīng)不夠迅速剖膳。
導(dǎo)致 Lambda 架構(gòu)的缺點根本原因是要同時維護兩套系統(tǒng)架構(gòu)：批處理層和速度層。我們已經(jīng)知道岭辣，在架構(gòu)中加入批處理層是因為從批處理層得到的結(jié)果具有高準(zhǔn)確性吱晒，而加入速度層是因為它在處理大規(guī)模數(shù)據(jù)時具有低延時性。
那我們能不能改進(jìn)其中某一層的架構(gòu)沦童，讓它具有另外一層架構(gòu)的特性呢仑濒？
例如叹话，改進(jìn)批處理層的系統(tǒng)讓它具有更低的延時性，又或者是改進(jìn)速度層的系統(tǒng)墩瞳，讓它產(chǎn)生的數(shù)據(jù)視圖更具準(zhǔn)確性和更加接近歷史數(shù)據(jù)呢驼壶？
另外一種在大規(guī)模數(shù)據(jù)處理中常用的架構(gòu)——Kappa 架構(gòu)，便是在這樣的思考下誕生的喉酌。
2. Kappa架構(gòu)
Kafka的創(chuàng)始人Jay Kreps認(rèn)為在很多場景下热凹，維護一套Lambda架構(gòu)的大數(shù)據(jù)處理平臺耗時耗力，于是提出在某些場景下泪电，沒有必要維護一個批處理層般妙，直接使用一個流處理層即可滿足需求，即下圖所示的Kappa架構(gòu)：
Kappa架構(gòu)
這種架構(gòu)只關(guān)注流式計算相速，數(shù)據(jù)以流的方式被采集過來碟渺，實時計算引擎將計算結(jié)果放入數(shù)據(jù)服務(wù)層以供查詢。可以認(rèn)為Kappa架構(gòu)是Lambda架構(gòu)的一個簡化版本突诬，只是去除掉了Lambda架構(gòu)中的離線批處理部分苫拍；
Kappa架構(gòu)的興起主要有兩個原因：
Kafka不僅起到消息隊列的作用，也可以保存更長時間的歷史數(shù)據(jù)攒霹，以替代Lambda架構(gòu)中批處理層數(shù)據(jù)倉庫部分怯疤。流處理引擎以一個更早的時間作為起點開始消費，起到了批處理的作用催束。
Flink流處理引擎解決了事件亂序下計算結(jié)果的準(zhǔn)確性問題集峦。
Kappa架構(gòu)相對更簡單，實時性更好抠刺，所需的計算資源遠(yuǎn)小于Lambda架構(gòu)塔淤，隨著實時處理的需求在不斷增長，更多的企業(yè)開始使用Kappa架構(gòu)速妖。但這不意味著kappa架構(gòu)能夠取代Lambda架構(gòu)高蜂。
Lambda和kappa架構(gòu)都有各自的適用領(lǐng)域；例如流處理與批處理分析流程比較統(tǒng)一罕容，且允許一定的容錯备恤，用Kappa比較合適，少量關(guān)鍵指標(biāo)（例如交易金額锦秒、業(yè)績統(tǒng)計等）使用Lambda架構(gòu)進(jìn)行批量計算露泊，增加一次校對過程。
還有一些比較復(fù)雜的場景旅择，批處理與流處理產(chǎn)生不同的結(jié)果（使用不同的機器學(xué)習(xí)模型惭笑，專家系統(tǒng)，或者實時計算難以處理的復(fù)雜計算），可能更適合Lambda架構(gòu)沉噩。
4. 實時數(shù)倉解決方案
實時數(shù)倉分層架構(gòu)為了避免面向需求響應(yīng)的煙囪式構(gòu)建捺宗，實時數(shù)倉也引入了類似于離線數(shù)倉的分層理念，主要是為了提高模型的復(fù)用率川蒙，同時也要考慮易用性蚜厉、一致性以及計算成本。
當(dāng)然實時數(shù)倉的分層架構(gòu)在設(shè)計上并不會像離線數(shù)倉那么復(fù)雜派歌，避免數(shù)據(jù)在流轉(zhuǎn)過程中造成的不必要的延時響應(yīng)弯囊；
實時數(shù)倉分層架構(gòu)圖：
實時數(shù)倉分層架構(gòu)
ODS層：以Kafka為支撐，將所有需要實時處理的相關(guān)數(shù)據(jù)放到Kafka隊列中來實現(xiàn)貼源數(shù)據(jù)層胶果；
DWD層：實時計算訂閱業(yè)務(wù)數(shù)據(jù)消息隊列匾嘱，然后通過數(shù)據(jù)清洗、多數(shù)據(jù)源join早抠、流式數(shù)據(jù)與離線維度信息等的組合霎烙，將一些相同粒度的業(yè)務(wù)系統(tǒng)、維表中的維度屬性全部關(guān)聯(lián)到一起蕊连，增加數(shù)據(jù)易用性和復(fù)用性悬垃，得到最終的實時明細(xì)數(shù)據(jù)；
DIM層：存放用于關(guān)聯(lián)查詢的維度信息甘苍，可以根據(jù)數(shù)據(jù)現(xiàn)狀來選擇存儲介質(zhì)尝蠕，例如使用HBase或者M(jìn)ysql
DWS層：輕度匯總層是為了便于面向AdHoc查詢或者Olap分析構(gòu)建的輕度匯總結(jié)果集合，適合數(shù)據(jù)維度载庭、指標(biāo)信息比較多的情況看彼，為了方便根據(jù)自定義條件的快速篩選和指標(biāo)聚合，推薦使用MPP類型數(shù)據(jù)庫進(jìn)行存儲囚聚，此層可視場景情況決定是否構(gòu)建靖榕；
APP層：面向?qū)崟r數(shù)據(jù)場景需求構(gòu)建的高度匯總層，可以根據(jù)不同的數(shù)據(jù)應(yīng)用場景決定使用存儲介質(zhì)或者引擎顽铸；例如面向業(yè)務(wù)歷史明細(xì)茁计、BI支持等Olap分析場景，可以使用Druid谓松、Greenplum星压，面向?qū)崟r監(jiān)控大屏、高并發(fā)匯總指標(biāo)等需求鬼譬，可以使用KV模式的HBase娜膘；數(shù)據(jù)量較小的時候，也可以使用Mysql來進(jìn)行存儲拧簸。
這里要注意下劲绪，其實APP層已經(jīng)脫離了數(shù)倉男窟，這里雖然作為了數(shù)倉的獨立分層盆赤，但是實際APP層的數(shù)據(jù)已經(jīng)分布存儲在各種介質(zhì)中用于使用贾富。
基于Flink構(gòu)建的實時數(shù)倉
隨著業(yè)務(wù)場景的豐富忱叭，更多的實時需求不斷涌現(xiàn)赐纱，在追求實時任務(wù)高吞吐低延遲的同時镀迂，對計算過程中間狀態(tài)管理蛾默，靈活時間窗口支持殖氏，以及 exactly once 語義保障的訴求也越來越多奔穿。
為什么選擇Flink實時計算平臺独柑？之所以選擇用Flink替代原有Storm盈厘、SparkStreaming是基于以下原因考慮的春缕，這也是實時數(shù)倉關(guān)注的核心問題：
高吞吐盗胀、低延時；
端到端的 Exactly-once锄贼，保證了數(shù)據(jù)的準(zhǔn)確性票灰；
可容錯的狀態(tài)管理，實時數(shù)倉里面會進(jìn)行很多的聚合計算宅荤，這些都需要對于狀態(tài)進(jìn)行訪問和管理屑迂；
豐富的API，對Streaming/Table/SQL支持良好冯键，支持UDF惹盼、流式j(luò)oin、時間窗口等高級用法惫确；
完善的生態(tài)體系手报，實時數(shù)倉的構(gòu)建會涉及多種存儲，F(xiàn)link在這方面的支持也比較完善雕薪。
基于Flink的實時數(shù)倉數(shù)據(jù)流轉(zhuǎn)過程:
實時數(shù)倉數(shù)據(jù)流轉(zhuǎn)過程
數(shù)據(jù)在實時數(shù)倉中的流轉(zhuǎn)過程昧诱，實際和離線數(shù)倉非常相似，只是由Flink替代Hive作為了計算引擎所袁，把存儲由HDFS更換成了Kafka盏档，但是模型的構(gòu)建思路與流轉(zhuǎn)過程并沒有發(fā)生變化。
本文檔總共九章燥爷，因字?jǐn)?shù)限制蜈亩，本文只發(fā)了前四章，此數(shù)倉建設(shè)完整版文檔：
