大數(shù)據(jù)封面.png

上一篇：
http://www.reibang.com/p/beeb4c87db26

二、離線數(shù)倉建設核心

數(shù)據(jù)倉庫的核心是展現(xiàn)層和提供優(yōu)質(zhì)的服務。ETL 及其規(guī)范、分層等所做的一切都是為了一個更清晰易用的展現(xiàn)層。

1、數(shù)倉分層

數(shù)倉分層的原則：

• 為便于數(shù)據(jù)分析内狗，要屏蔽底層復雜業(yè)務，簡單义锥、完整柳沙、集成的將數(shù)據(jù)暴露給分析層。

• 底層業(yè)務變動與上層需求變動對模型沖擊最小化拌倍，業(yè)務系統(tǒng)變化影響削弱在基礎數(shù)據(jù)層赂鲤，結(jié)合自上而下的建設方法削弱需求變動對模型的影響。

• 高內(nèi)聚松耦合柱恤，即主題之內(nèi)或各個完整意義的系統(tǒng)內(nèi)數(shù)據(jù)的高內(nèi)聚数初，主題之間或各個完整意義的系統(tǒng)間數(shù)據(jù)的松耦合。

• 構(gòu)建倉庫基礎數(shù)據(jù)層梗顺，使底層業(yè)務數(shù)據(jù)整合工作與上層應用開發(fā)工作相隔離妙真，為倉庫大規(guī)模開發(fā)奠定基礎 倉庫層次更加清晰，對外暴露數(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ù)倉庫時要核心設計的一層，在這里获列，從 ODS 層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型谷市。

DW 層又細分為** DWD（Data Warehouse Detail）層、DWM（Data WareHouse Middle）層和 DWS**（Data WareHouse Servce） 層击孩。

①數(shù)據(jù)明細層：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ù)明細層的易用性法绵，該層會采用一些維度退化手法箕速，將維度退化至事實表中，減少事實表和維表的關聯(lián)礼烈。

另外，在該層也會做一部分的數(shù)據(jù)聚合婆跑，將相同主題的數(shù)據(jù)匯集到一張表中此熬，提高數(shù)據(jù)的可用性 。

②數(shù)據(jù)中間層：DWM（Data WareHouse Middle）

該層會在 DWD 層的數(shù)據(jù)基礎上滑进，數(shù)據(jù)做輕度的聚合操作犀忱，生成一系列的中間表，提升公共指標的復用性扶关，減少重復加工阴汇。

直觀來講，就是對通用的核心維度進行聚合操作节槐，算出相應的統(tǒng)計指標搀庶。

在實際計算中拐纱，如果直接從 DWD 或者 ODS 計算出寬表的統(tǒng)計指標，會存在計算量太大并且維度太少的問題哥倔，因此一般的做法是秸架，在 DWM 層先計算出多個小的中間表，然后再拼接成一張 DWS 的寬表咆蒿。由于寬和窄的界限不易界定东抹，也可以去掉 DWM 這一層，只留 DWS 層沃测，將所有的數(shù)據(jù)再放在 DWS 亦可缭黔。

③數(shù)據(jù)服務層：DWS（Data WareHouse Servce）

DWS 層為公共匯總層，會進行輕度匯總蒂破，粒度比明細數(shù)據(jù)稍粗馏谨，基于 DWD 層上的基礎數(shù)據(jù)，整合匯總成分析某一個主題域的服務數(shù)據(jù)寞蚌，一般是寬表田巴。DWS 層應覆蓋 80% 的應用場景。又稱數(shù)據(jù)集市或?qū)挶怼?/p>

按照業(yè)務劃分挟秤，如主題域流量壹哺、訂單、用戶等艘刚，生成字段比較多的寬表管宵，用于提供后續(xù)的業(yè)務查詢，OLAP 分析攀甚，數(shù)據(jù)分發(fā)等箩朴。

一般來講，該層的數(shù)據(jù)表會相對比較少秋度，一張表會涵蓋比較多的業(yè)務內(nèi)容炸庞，由于其字段較多，因此一般也會稱該層的表為寬表荚斯。

3）數(shù)據(jù)應用層：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ù)：

高基數(shù)維度數(shù)據(jù)：一般是用戶資料表、商品資料表類似的資料表胡岔。數(shù)據(jù)量可能是千萬級或者上億級別法希。

低基數(shù)維度數(shù)據(jù)：一般是配置表，比如枚舉值對應的中文含義靶瘸，或者日期維表苫亦。數(shù)據(jù)量可能是個位數(shù)或者幾千幾萬。

2怨咪、數(shù)倉建模方法

數(shù)倉建模在哪層建設呢屋剑？我們以維度建模為例，建模是在數(shù)據(jù)源層的下一層進行建設诗眨，在上節(jié)的分層架構(gòu)中唉匾，就是在DW層進行數(shù)倉建模，所以DW層是數(shù)倉建設的核心層匠楚。

那數(shù)倉建模怎么建呢巍膘？其實數(shù)據(jù)倉庫的建模方法有很多種，每一種建模方法代表了哲學上的一個觀點芋簿，代表了一種歸納峡懈、概括世界的一種方法。常見的有 范式建模法与斤、維度建模法肪康、實體建模法等，每種方法從本質(zhì)上將是從不同的角度看待業(yè)務中的問題撩穿。

1）范式建模法（Third Normal Form磷支，3NF）

范式建模法其實是我們在構(gòu)建數(shù)據(jù)模型常用的一個方法，該方法的主要由 Inmon 所提倡食寡，主要解決關系型數(shù)據(jù)庫的數(shù)據(jù)存儲雾狈，利用的一種技術層面上的方法。目前抵皱，我們在關系型數(shù)據(jù)庫中的建模方法善榛，大部分采用的是三范式建模法。

范式 是符合某一種級別的關系模式的集合叨叙。構(gòu)造數(shù)據(jù)庫必須遵循一定的規(guī)則锭弊，而在關系型數(shù)據(jù)庫中這種規(guī)則就是范式堪澎，這一過程也被稱為規(guī)范化擂错。目前關系數(shù)據(jù)庫有六種范式：第一范式（1NF）、第二范式（2NF）樱蛤、第三范式（3NF）钮呀、Boyce-Codd范式（BCNF）剑鞍、第四范式（4NF）和第五范式（5NF）。

在數(shù)據(jù)倉庫的模型設計中爽醋，一般采用第三范式蚁署。一個符合第三范式的關系必須具有以下三個條件 :

• 每個屬性值唯一，不具有多義性 ;

• 每個非主屬性必須完全依賴于整個主鍵蚂四，而非主鍵的一部分 ;

• 每個非主屬性不能依賴于其他關系中的屬性光戈，因為這樣的話，這種屬性應該歸到其他關系中去遂赠。

圖片

范式建模

根據(jù) Inmon 的觀點久妆，數(shù)據(jù)倉庫模型的建設方法和業(yè)務系統(tǒng)的企業(yè)數(shù)據(jù)模型類似。在業(yè)務系統(tǒng)中跷睦，企業(yè)數(shù)據(jù)模型決定了數(shù)據(jù)的來源筷弦，而企業(yè)數(shù)據(jù)模型也分為兩個層次，即主題域模型和邏輯模型抑诸。同樣烂琴，主題域模型可以看成是業(yè)務模型的概念模型，而邏輯模型則是域模型在關系型數(shù)據(jù)庫上的實例化蜕乡。

2）維度建模法（Dimensional Modeling）

維度模型是數(shù)據(jù)倉庫領域另一位大師Ralph Kimall所倡導奸绷，他的《數(shù)據(jù)倉庫工具箱》是數(shù)據(jù)倉庫工程領域最流行的數(shù)倉建模經(jīng)典。維度建模以分析決策的需求出發(fā)構(gòu)建模型异希，構(gòu)建的數(shù)據(jù)模型為分析需求服務健盒，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規(guī)模復雜查詢的響應性能称簿。

圖片

維度建模

典型的代表是我們比較熟知的星形模型（Star-schema）扣癣，以及在一些特殊場景下適用的雪花模型（Snow-schema）。

維度建模中比較重要的概念就是 事實表（Fact table）和維度表（Dimension table）憨降。其最簡單的描述就是父虑，按照事實表、維度表來構(gòu)建數(shù)據(jù)倉庫授药、數(shù)據(jù)集市士嚎。

3）實體建模法（Entity Modeling）

實體建模法并不是數(shù)據(jù)倉庫建模中常見的一個方法，它來源于哲學的一個流派悔叽。從哲學的意義上說莱衩，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體娇澎，以及實體與實體之間的關系組成笨蚁。那么我們在數(shù)據(jù)倉庫的建模過程中完全可以引入這個抽象的方法，將整個業(yè)務也可以劃分成一個個的實體，而每個實體之間的關系括细，以及針對這些關系的說明就是我們數(shù)據(jù)建模需要做的工作伪很。

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易奋单。即我們可以將任何一個業(yè)務過程劃分成 3 個部分锉试，實體，事件览濒，說明呆盖，如下圖所示：

圖片

實體建模

上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”贷笛。以這個業(yè)務事實為例絮短，我們可以把“小明”，“學凶蛞洌”看成是一個實體丁频，“上學”描述的是一個業(yè)務過程，我們在這里可以抽象為一個具體“事件”邑贴，而“開車去”則可以看成是事件“上學”的一個說明席里。

3、維度建模詳解

目前在互聯(lián)網(wǎng)公司最常用的建模方法就是維度建模拢驾，我們將重點講解奖磁！

維度建模是專門應用于分析型數(shù)據(jù)庫、數(shù)據(jù)倉庫繁疤、數(shù)據(jù)集市建模的方法咖为。數(shù)據(jù)集市可以理解為是一種"小型數(shù)據(jù)倉庫"。

我們先不著急開始維度建模稠腊，先來了解下維度建模中表的類型和維度建模的模式之后再開始建模躁染，這樣能夠讓我們深刻理解！

1）維度建模中表的類型

維度建模分為兩種表：事實表和維度表：

• 事實表：必然存在的一些數(shù)據(jù)架忌，像采集的日志文件吞彤，訂單表，都可以作為事實表

特征：是一堆主鍵的集合叹放，每個主鍵對應維度表中的一條記錄饰恕， 客觀存在的，根據(jù)主題確定出需要使用的數(shù)據(jù)

• 維度表：維度就是所分析的數(shù)據(jù)的一個量井仰，維度表就是以合適的角度來創(chuàng)建的表埋嵌，分析問題的一個角度：時間、地域俱恶、終端雹嗦、用戶等角度拌喉。

①事實表

發(fā)生在現(xiàn)實世界中的操作型事件，其所產(chǎn)生的可度量數(shù)值俐银，存儲在事實表中。從最低的粒度級別來看端仰，事實表行對應一個度量事件捶惜，反之亦然。

事實表表示對分析主題的度量荔烧。比如一次購買行為我們就可以理解為是一個事實吱七。

圖片

事實與維度

圖中的訂單表就是一個事實表，你可以理解他就是在現(xiàn)實中發(fā)生的一次操作型事件鹤竭，我們每完成一個訂單踊餐，就會在訂單中增加一條記錄。事實表的特征：表里沒有存放實際的內(nèi)容臀稚，他是一堆主鍵的集合吝岭，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯(lián)的外鍵吧寺，可與維度表關聯(lián)窜管。事實表的度量通常是數(shù)值類型，且記錄數(shù)會不斷增加稚机，表數(shù)據(jù)規(guī)模迅速增長幕帆。

明細表（寬表）：

事實表的數(shù)據(jù)中，有些屬性共同組成了一個字段（糅合在一起）赖条，比如年月日時分秒構(gòu)成了時間,當需要根據(jù)某一屬性進行分組統(tǒng)計的時候失乾，需要截取拼接之類的操作，效率極低纬乍。如：

圖片

為了分析方便碱茁，可以事實表中的一個字段切割提取多個屬性出來構(gòu)成新的字段，因為字段變多了仿贬，所以稱為寬表早芭，原來的成為窄表。

將上述的local_time字段擴展為如下6個字段：

圖片

又因為寬表的信息更加清晰明細诅蝶，所以也可以稱之為明細表退个。

事實表種類

事實表分為以下6類：

• 事務事實表

• 周期快照事實表

• 累積快照事實表

• 無事實的事實表

• 聚集事實表

• 合并事實表

簡單解釋下每種表的概念：

• 事務事實表

表中的一行對應空間或時間上某點的度量事件。就是一行數(shù)據(jù)中必須有度量字段调炬，什么是度量语盈，就是指標，比如說銷售金額缰泡，銷售數(shù)量等這些可加的或者半可加就是度量值刀荒。另一點就是事務事實表都包含一個與維度表關聯(lián)的外鍵代嗤。并且度量值必須和事務粒度保持一致。

• 周期快照事實表

顧名思義缠借，周期事實表就是每行都帶有時間值字段干毅，代表周期，通常時間值都是標準周期泼返，如某一天硝逢，某周，某月等绅喉。粒度是周期渠鸽，而不是個體的事務，也就是說一個周期快照事實表中數(shù)據(jù)可以是多個事實柴罐，但是它們都屬于某個周期內(nèi)徽缚。

• 累計快照事實表

周期快照事實表是單個周期內(nèi)數(shù)據(jù)，而累計快照事實表是由多個周期數(shù)據(jù)組成革屠，每行匯總了過程開始到結(jié)束之間的度量凿试。每行數(shù)據(jù)相當于管道或工作流，有事件的起點似芝，過程红省，終點，并且每個關鍵步驟都包含日期字段国觉。如訂單數(shù)據(jù)吧恃，累計快照事實表的一行就是一個訂單，當訂單產(chǎn)生時插入一行麻诀，當訂單發(fā)生變化時痕寓，這行就被修改。

• 無事實的事實表

我們以上討論的事實表度量都是數(shù)字化的蝇闭，當然實際應用中絕大多數(shù)都是數(shù)字化的度量呻率，但是也可能會有少量的沒有數(shù)字化的值但是還很有價值的字段，無事實的事實表就是為這種數(shù)據(jù)準備的呻引，利用這種事實表可以分析發(fā)生了什么礼仗。

• 聚集事實表

聚集，就是對原子粒度的數(shù)據(jù)進行簡單的聚合操作逻悠，目的就是為了提高查詢性能元践。如我們需求是查詢?nèi)珖虚T店的總銷售額，我們原子粒度的事實表中每行是每個分店每個商品的銷售額童谒，聚集事實表就可以先聚合每個分店的總銷售額单旁，這樣匯總所有門店的銷售額時計算的數(shù)據(jù)量就會小很多。

• 合并事實表

這種事實表遵循一個原則饥伊，就是相同粒度象浑，數(shù)據(jù)可以來自多個過程蔫饰，但是只要它們屬于相同粒度，就可以合并為一個事實表愉豺，這類事實表特別適合經(jīng)常需要共同分析的多過程度量篓吁。

②維度表

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯(lián)的任何事實表的外鍵蚪拦，當然杖剪，維度表行的描述環(huán)境應與事實表行完全對應。維度表通常比較寬外盯，是扁平型非規(guī)范表，包含大量的低粒度的文本屬性翼雀。

維度表示你要對數(shù)據(jù)進行分析時所用的一個量饱苟，比如你要分析產(chǎn)品銷售情況， 你可以選擇按類別來進行分析狼渊，或按區(qū)域來分析箱熬。每個類別就構(gòu)成一個維度。上圖中的用戶表狈邑、商家表城须、時間表這些都屬于維度表，這些表都有一個唯一的主鍵米苹，然后在表中存放了詳細的數(shù)據(jù)信息糕伐。

總的說來，在數(shù)據(jù)倉庫中不需要嚴格遵守規(guī)范化設計原則蘸嘶。因為數(shù)據(jù)倉庫的主導功能就是面向分析良瞧，以查詢?yōu)橹鳎簧婕皵?shù)據(jù)更新操作训唱。事實表的設計是以能夠正確記錄歷史信息為準則褥蚯，維度表的設計是以能夠以合適的角度來聚合主題內(nèi)容為準則。

• 維度表結(jié)構(gòu)

維度表謹記一條原則况增，包含單一主鍵列赞庶，但有時因業(yè)務復雜，也可能出現(xiàn)聯(lián)合主鍵澳骤，請盡量避免歧强，如果無法避免，也要確保必須是單一的为肮，這很重要誊锭，如果維表主鍵不是單一，和事實表關聯(lián)時會出現(xiàn)數(shù)據(jù)發(fā)散弥锄，導致最后結(jié)果可能出現(xiàn)錯誤丧靡。

維度表通常比較寬蟆沫，包含大量的低粒度的文本屬性。

• 跨表鉆取

跨表鉆取意思是當每個查詢的行頭都包含相同的一致性屬性時温治，使不同的查詢能夠針對兩個或更多的事實表進行查詢

鉆取可以改變維的層次饭庞，變換分析的粒度。它包括上鉆/下鉆：

上鉆（roll-up）：上卷是沿著維的層次向上聚集匯總數(shù)據(jù)熬荆。例如舟山，對產(chǎn)品銷售數(shù)據(jù)，沿著時間維上卷卤恳，可以求出所有產(chǎn)品在所有地區(qū)每月（或季度或年或全部）的銷售額。

下鉆（drill-down）：下鉆是上鉆的逆操作若债，它是沿著維的層次向下拆融，查看更詳細的數(shù)據(jù)。

• 退化維度

退化維度就是將維度退回到事實表中傲须。因為有時維度除了主鍵沒有其他內(nèi)容，雖然也是合法維度鍵趟脂，但是一般都會退回到事實表中，減少關聯(lián)次數(shù)菇绵，提高查詢性能

• 多層次維度

多數(shù)維度包含不止一個自然層次咬最，如日期維度可以從天的層次到周到月到年的層次永乌。所以在有些情況下翅雏，在同一維度中存在不同的層次望几。

• 維度表空值屬性

當給定維度行沒有被全部填充時萤厅，或者當存在屬性沒有被應用到所有維度行時，將產(chǎn)生空值維度屬性玉锌。上述兩種情況疟羹，推薦采用描述性字符串代替空值榄融，如使用 unknown 或 not applicable 替換空值愧杯。

• 日歷日期維度

在日期維度表中民效，主鍵的設置不要使用順序生成的id來表示畏邢，可以使用更有意義的數(shù)據(jù)表示舒萎，比如將年月日合并起來表示臂寝，即YYYYMMDD咆贬，或者更加詳細的精度掏缎。

2）維度建模三種模式

①星型模式

星形模式(Star Schema)是最常用的維度建模方式眷蜈。星型模式是以事實表為中心，所有的維度表直接連接在事實表上忌怎，像星星一樣呆躲。星形模式的維度建模由一個事實表和一組維表成灰瞻，且具有以下特點：a. 維表只和事實表關聯(lián)酝润，維表之間沒有關聯(lián)要销；b. 每個維表主鍵為單列疏咐，且該主鍵放置在事實表中浑塞，作為兩邊連接的外鍵酌壕；c. 以事實表為核心，維表圍繞核心呈星形分布糊昙；

圖片

②雪花模式

雪花模式(Snowflake Schema)是對星形模式的擴展释牺。雪花模式的維度表可以擁有其他維度表的船侧，雖然這種模型相比星型更規(guī)范一些，但是由于這種模型不太容易理解袁梗，維護成本比較高遮怜，而且性能方面需要關聯(lián)多層維表锯梁，性能也比星型模型要低陌凳。所以一般不是很常用

圖片

雪花模式

③星座模式

星座模式是星型模式延伸而來初橘，星型模式是基于一張事實表的保檐，而星座模式是基于多張事實表的夜只，而且共享維度信息盐肃。前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內(nèi)的事實表不止一個峦阁，而一個維表也可能被多個事實表用到榔昔。在業(yè)務發(fā)展后期名党，絕大部分維度建模都采用的是星座模式。

圖片

星座模型

3）維度建模過程

我們知道維度建模的表類型有事實表怔檩，維度表薛训；模式有星形模型闸英，雪花模型自阱，星座模型這些概念了沛豌，但是實際業(yè)務中加派，給了我們一堆數(shù)據(jù)，我們怎么拿這些數(shù)據(jù)進行數(shù)倉建設呢娄琉，數(shù)倉工具箱作者根據(jù)自身60多年的實際業(yè)務經(jīng)驗孽水，給我們總結(jié)了如下四步女气，請務必記住谒主！

數(shù)倉工具箱中的維度建模四步走：

圖片

維度建模四步走

請牢記以上四步，不管什么業(yè)務姿现，就按照這個步驟來备典，順序不要搞亂提佣，因為這四步是環(huán)環(huán)相扣潮针，步步相連每篷。下面詳細拆解下每個步驟怎么做

①選擇業(yè)務過程

維度建模是緊貼業(yè)務的焦读，所以必須以業(yè)務為根基進行建模，那么選擇業(yè)務過程张症，顧名思義就是在整個業(yè)務流程中選取我們需要建模的業(yè)務俗他，根據(jù)運營提供的需求及日后的易擴展性等進行選擇業(yè)務郭变。比如商城诉濒，整個商城流程分為商家端专挪，用戶端寨腔，平臺端迫卢，運營需求是總訂單量每界，訂單人數(shù)眨层，及用戶的購買情況等，我們選擇業(yè)務過程就選擇用戶端的數(shù)據(jù)伊佃，商家及平臺端暫不考慮金刁。業(yè)務選擇非常重要尤蛮，因為后面所有的步驟都是基于此業(yè)務數(shù)據(jù)展開的醇锚。

②聲明粒度

先舉個例子：對于用戶來說焊唬，一個用戶有一個身份證號，一個戶籍地址鸥滨，多個手機號老速，多張銀行卡烁峭，那么與用戶粒度相同的粒度屬性有身份證粒度，戶籍地址粒度鬓梅，比用戶粒度更細的粒度有手機號粒度，銀行卡粒度坊罢，存在一對一的關系就是相同粒度活孩。為什么要提相同粒度呢，因為維度建模中要求我們起趾，在同一事實表中，必須具有相同的粒度边琉，同一事實表中不要混用多種不同的粒度艺骂，不同的粒度數(shù)據(jù)建立不同的事實表。并且從給定的業(yè)務過程獲取數(shù)據(jù)時忧额，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始托嚣，因為原子粒度能夠承受無法預期的用戶查詢。但是上卷匯總粒度對查詢性能的提升很重要的夫嗓，所以對于有明確需求的數(shù)據(jù)，我們建立針對需求的上卷匯總粒度排霉，對需求不明朗的數(shù)據(jù)我們建立原子粒度。

③確認維度

維度表是作為業(yè)務分析的入口和描述性標識辙诞，所以也被稱為數(shù)據(jù)倉庫的“靈魂”。在一堆的數(shù)據(jù)中怎么確認哪些是維度屬性呢较店，如果該列是對具體值的描述，是一個文本或常量官卡，某一約束和行標識的參與者哮翘，此時該屬性往往是維度屬性饭寺，數(shù)倉工具箱中告訴我們牢牢掌握事實表的粒度，就能將所有可能存在的維度區(qū)分開员凝，并且要確保維度表中不能出現(xiàn)重復數(shù)據(jù)，應使維度主鍵唯一。

④確認事實

事實表是用來度量的阶捆，基本上都以數(shù)量值表示，事實表中的每行對應一個度量垒棋，每行中的數(shù)據(jù)是一個特定級別的細節(jié)數(shù)據(jù)，稱為粒度乖订。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現(xiàn)重復計算度量的問題哥遮。有時候往往不能確定該列數(shù)據(jù)是事實屬性還是維度屬性元潘。記住最實用的事實就是數(shù)值類型和可加類事實君仆。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實牲距。

三返咱、離線數(shù)倉建設實戰(zhàn)

技術是為業(yè)務服務的，業(yè)務是為公司創(chuàng)造價值的牍鞠，離開業(yè)務的技術是無意義的。

1难述、業(yè)務介紹

需要針對不同需求的用戶開發(fā)不同的產(chǎn)品萤晴，所以公司內(nèi)部有很多條業(yè)務線，但是對于數(shù)據(jù)部門來說胁后，所有業(yè)務線的數(shù)據(jù)都是數(shù)據(jù)源店读。對數(shù)據(jù)的劃分不只是根據(jù)業(yè)務進行，而是結(jié)合數(shù)據(jù)的屬性攀芯。

2屯断、早期規(guī)劃

之前開發(fā)是不同業(yè)務線對應不同的數(shù)據(jù)團隊，每個數(shù)據(jù)團隊互不干擾侣诺，這種模式比較簡單殖演，只針對自己的業(yè)務線進行數(shù)倉建設及報表開發(fā)即可。

但是隨著業(yè)務的發(fā)展年鸳，頻繁迭代及跨部門的垂直業(yè)務單元越來越多趴久，業(yè)務之間的出現(xiàn)耦合情況，這時再采用這種煙囪式開發(fā)就出現(xiàn)了問題：

例如權限問題搔确，公司對數(shù)據(jù)管理比較嚴格彼棍，不同的數(shù)據(jù)開發(fā)組沒有權限共享數(shù)據(jù)，需要其他業(yè)務線的數(shù)據(jù)權限需要上報審批妥箕，比較耽誤時間滥酥；

還有重復開發(fā)問題，不同業(yè)務線會出現(xiàn)相同的報表需求畦幢，如果每個業(yè)務方都開發(fā)各自的報表坎吻，太浪費資源。

所以對于數(shù)據(jù)開發(fā)而言宇葱，需要對各個業(yè)務線的數(shù)據(jù)進行統(tǒng)一管理瘦真，所以就有了數(shù)據(jù)中臺的出現(xiàn)刊头。

3、數(shù)據(jù)中臺

我認為數(shù)據(jù)中臺是根據(jù)每個公司具體的業(yè)務需求而搭建的诸尽，不同的業(yè)務原杂，對中臺的理解有所不同。

公司內(nèi)部開發(fā)的敏捷數(shù)據(jù)中臺您机，主要從數(shù)據(jù)技術和計算能力的復用穿肄，到數(shù)據(jù)資產(chǎn)和數(shù)據(jù)服務的復用，數(shù)據(jù)中臺以更大價值帶寬际看，快準精讓數(shù)據(jù)直接賦能業(yè)務咸产。提供一個統(tǒng)一化的管理，打破數(shù)據(jù)孤島仲闽，追溯數(shù)據(jù)血緣脑溢，實現(xiàn)自助化及高復用度。

如下所示：

圖片

數(shù)據(jù)中臺

以上解釋比較抽象赖欣，我們以實際項目開發(fā)來看下數(shù)據(jù)中臺的便利性屑彻。

比如我們之前做報表開發(fā)流程，首先是要數(shù)據(jù)采集顶吮，不同的數(shù)據(jù)源通過sqoop等工具采集到大數(shù)據(jù)平臺社牲，然后進行數(shù)倉搭建，最后產(chǎn)出報表數(shù)據(jù)云矫，放到可視化系統(tǒng)展示膳沽，最終把整個流程寫成腳本放到調(diào)度平臺進行自動化執(zhí)行。

而有了數(shù)據(jù)中臺之后就不需要那么繁瑣让禀，直接進行數(shù)倉搭建挑社，產(chǎn)生報表即可，無需將精力過多放在數(shù)據(jù)源巡揍、可視化展示及調(diào)度痛阻。并且可以直觀的查看數(shù)據(jù)血緣關系，計算表之間血緣腮敌。像下面圖中阱当，表之間的依賴關系很明確：

圖片

數(shù)據(jù)中臺

另一點，數(shù)據(jù)中臺的異構(gòu)數(shù)據(jù)系統(tǒng)可以非常簡單的進行關聯(lián)查詢糜工，比如hive的表關聯(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ù)中臺提供虛擬表到物理表之間的映射，終端用戶無需關心數(shù)據(jù)的物理存放位置和底層數(shù)據(jù)源的特性，可直接操作數(shù)據(jù)澈圈，體驗類似操作一個虛擬數(shù)據(jù)庫彬檀。

數(shù)據(jù)中臺額外集成可視化展示，提供一站式數(shù)據(jù)可視化解決方案瞬女，支持JDBC數(shù)據(jù)源和CSV文件上傳窍帝，支持基于數(shù)據(jù)模型拖拽智能生成可視化組件，大屏展示自適應不同大小屏幕诽偷。

調(diào)度系統(tǒng)是公司內(nèi)部自寫集成到數(shù)據(jù)中臺的坤学，在編寫完sql語句之后可以直接進行調(diào)度。

4渤刃、數(shù)倉建設

到這才真正到數(shù)倉建設拥峦，為什么前面我要占那么大篇幅去介紹公司業(yè)務及所使用的數(shù)據(jù)中臺系統(tǒng)贴膘，因為下面的數(shù)倉建設是根據(jù)公司的業(yè)務發(fā)展及現(xiàn)有的數(shù)據(jù)中臺進行卖子，數(shù)倉的建設離不開公司的業(yè)務。

數(shù)倉建設核心思想：從設計刑峡、開發(fā)洋闽、部署和使用層面，避免重復建設和指標冗余建設突梦，從而保障數(shù)據(jù)口徑的規(guī)范和統(tǒng)一诫舅，最終實現(xiàn)數(shù)據(jù)資產(chǎn)全鏈路關聯(lián)、提供標準數(shù)據(jù)輸出以及建立統(tǒng)一的數(shù)據(jù)公共層宫患。有了核心思想刊懈，那怎么開始數(shù)倉建設，有句話說數(shù)倉建設者即是技術專家娃闲，也是大半個業(yè)務專家虚汛，所以采用的方式就是需求推動數(shù)據(jù)建設，并且因為數(shù)據(jù)中臺皇帮，所以各業(yè)務知識體系比較集中卷哩，各業(yè)務數(shù)據(jù)不再分散，加快了數(shù)倉建設速度属拾。

數(shù)倉建設主要從兩個方面進行将谊，模型和規(guī)范，所有業(yè)務進行統(tǒng)一化渐白。

1）模型

所有業(yè)務采用統(tǒng)一的模型體系尊浓，從而降低研發(fā)成本，增強指標復用纯衍，并且能保證數(shù)據(jù)口徑的統(tǒng)一栋齿。

2）模型分層

結(jié)合公司業(yè)務，后期新增需求較多，所以分層不宜過多褒颈，并且需要清晰明確各層職責柒巫，要保證數(shù)據(jù)層的穩(wěn)定又要屏蔽對下游影響，所以采用如下分層結(jié)構(gòu)：

圖片

數(shù)據(jù)分層架構(gòu)

3）數(shù)據(jù)流向

遵循模型開發(fā)時分層結(jié)構(gòu)谷丸，數(shù)據(jù)從 ods -> dw -> dm ->app 這樣正向流動堡掏，可以防止因數(shù)據(jù)引用不規(guī)范而造成數(shù)據(jù)鏈路混亂及SLA時效難保障等問題，同時保證血緣關系簡潔化刨疼，能夠輕易追蹤數(shù)據(jù)流向泉唁。在開發(fā)時應避免以下情況出現(xiàn)：

• 數(shù)據(jù)引用鏈路不正確，如 ods -> dm ->app 揩慕，出現(xiàn)這種情況說明明細層沒有完全覆蓋數(shù)據(jù)亭畜；如 ods -> dw -> app ，說明輕度匯總層主題劃分未覆蓋全 迎卤。減少跨層引用拴鸵，才能提高中間表的復用度。理想的數(shù)倉模型設計應當具備：數(shù)據(jù)模型可復?蜗搔，完善且規(guī)范劲藐。

• 盡量避免一層的表生成當前層的表，如dw層表生成dw層表樟凄，這樣會影響ETL效率聘芜。

• 禁止出現(xiàn)反向依賴，如dw表依賴于dm表缝龄。

4）規(guī)范

①表命名規(guī)范

• 對于ods汰现、dm、app層表名：類型主題表含義叔壤，如：dm_xxsh_user

• 對于dw層表名：類型主題維度_表含義瞎饲，如：dw_xxsh_fact_users（事實表）、dw_xxsh_dim_city（維度表）

②字段命名規(guī)范

構(gòu)建詞根百新，詞根是維度和指標管理的基礎企软，劃分為普通詞根與專有詞根

• 普通詞根：描述事物的最小單元體，如：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ī)范

<pre class="code-snippet__js" data-lang="python" style="margin: 0px; padding: 1em 1em 1em 0px; outline: 0px; max-width: 1000%; box-sizing: border-box !important; overflow-wrap: break-word !important; overflow-x: auto; white-space: normal; -webkit-box-flex: 1; flex: 1 1 0%;">

#變量的定義要符合python的語法要求``#指定任務負責人``owner = "zhangsan@xxx.com"``#腳本存放目錄/opt/xxx``#腳本名稱 hive.hive.dm.dm_xxsh_users``#source用來標識上游依賴表厌漂，一個任務如果有多個上游表，都需要寫進去``#(xxx_name 是需要改動的斟珊，其余不需要改)``source = { "table_name": { "db": "db_name", "table": "table_name" }``}``#如source苇倡，但是每個任務target只有一張表``target = { "db_table": { "host": "hive", "db": "db_name", "table": "table_name" }``}``#變量列表``#$now``#$now.date 常用，格式示例：2020-12-11``task = '''``寫sql代碼``'''

</pre>

5、數(shù)據(jù)層具體實現(xiàn)

使用四張圖說明每層的具體實現(xiàn)：

1）數(shù)據(jù)源層ODS

圖片

數(shù)據(jù)源層

數(shù)據(jù)源層主要將各個業(yè)務數(shù)據(jù)導入到大數(shù)據(jù)平臺旨椒，作為業(yè)務數(shù)據(jù)的快照存儲晓褪。

2）數(shù)據(jù)明細層DW

圖片

數(shù)據(jù)明細層

事實表中的每行對應一個度量，每行中的數(shù)據(jù)是一個特定級別的細節(jié)數(shù)據(jù)综慎，稱為粒度涣仿。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現(xiàn)重復計算度量的問題示惊。

維度表一般都是單一主鍵好港，少數(shù)是聯(lián)合主鍵，注意維度表不要出現(xiàn)重復數(shù)據(jù)米罚，否則和事實表關聯(lián)會出現(xiàn)數(shù)據(jù)發(fā)散問題钧汹。

有時候往往不能確定該列數(shù)據(jù)是事實屬性還是維度屬性。記住最實用的事實就是數(shù)值類型和可加類事實录择。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量拔莱，這種情況下該列往往是事實；如果該列是對具體值的描述糊肠，是一個文本或常量辨宠，某一約束和行標識的參與者，此時該屬性往往是維度屬性货裹。但是還是要結(jié)合業(yè)務進行最終判斷是維度還是事實。

3）數(shù)據(jù)輕度匯總層DM

圖片

數(shù)據(jù)輕度匯總層

此層命名為輕匯總層精偿，就代表這一層已經(jīng)開始對數(shù)據(jù)進行匯總弧圆，但是不是完全匯總，只是對相同粒度的數(shù)據(jù)進行關聯(lián)匯總笔咽，不同粒度但是有關系的數(shù)據(jù)也可進行匯總搔预，此時需要將粒度通過聚合等操作進行統(tǒng)一。

4）數(shù)據(jù)應用層APP

圖片

數(shù)據(jù)應用層

數(shù)據(jù)應用層的表就是提供給用戶使用的叶组，數(shù)倉建設到此就接近尾聲了拯田，接下來就根據(jù)不同的需求進行不同的取數(shù)，如直接進行報表展示甩十，或提供給數(shù)據(jù)分析的同事所需的數(shù)據(jù)船庇，或其他的業(yè)務支撐。

6侣监、總結(jié)

一張圖總結(jié)下數(shù)據(jù)倉庫的構(gòu)建整體流程：

圖片

數(shù)據(jù)中臺

7鸭轮、實際生產(chǎn)中注意事項

生產(chǎn)環(huán)境中操作不能像我們自己測試時那樣隨意，一不小心都可能造成生產(chǎn)事故橄霉。所以每步操作都要十分小心窃爷，需全神貫注，管好大腦管住右手。

僅列出以下但不限于以下的注意事項：

• 請勿操作自己管理及授權表之外的其它庫表按厘；

• 未經(jīng)授權医吊，請勿操作生產(chǎn)環(huán)境中其他人的腳本及文件；

• 在修改生產(chǎn)環(huán)境腳本前逮京，請務必自行備份到本地遮咖；

• 請確認自己的修改操作能迅速回滾；

• 生產(chǎn)環(huán)境中表名及字段等所有命名請遵循命名規(guī)則造虏。

四御吞、實時計算

實時計算一般都是針對海量數(shù)據(jù)進行的，并且要求為秒級漓藕。由于大數(shù)據(jù)興起之初陶珠，Hadoop并沒有給出實時計算解決方案，隨后Storm享钞，SparkStreaming揍诽，F(xiàn)link等實時計算框架應運而生，而Kafka栗竖，ES的興起使得實時計算領域的技術越來越完善暑脆，而隨著物聯(lián)網(wǎng)，機器學習等技術的推廣狐肢，實時流式計算將在這些領域得到充分的應用添吗。

實時計算的三個特征：

• 無限數(shù)據(jù)：無限數(shù)據(jù)指的是一種不斷增長的，基本上無限的數(shù)據(jù)集份名。這些通常被稱為“流數(shù)據(jù)”碟联，而與之相對的是有限的數(shù)據(jù)集。

• 無界數(shù)據(jù)處理：一種持續(xù)的數(shù)據(jù)處理模式,能夠通過處理引擎重復的去處理上面的無限數(shù)據(jù)僵腺，是能夠突破有限數(shù)據(jù)處理引擎的瓶頸的鲤孵。

• 低延遲：延遲是多少并沒有明確的定義。但我們都知道數(shù)據(jù)的價值將隨著時間的流逝降低辰如，時效性將是需要持續(xù)解決的問題普监。

現(xiàn)在大數(shù)據(jù)應用比較火爆的領域，比如推薦系統(tǒng)在實踐之初受技術所限琉兜，可能要一分鐘凯正，一小時，甚至更久對用戶進行推薦呕童，這遠遠不能滿足需要漆际，我們需要更快的完成對數(shù)據(jù)的處理，而不是進行離線的批處理夺饲。

1奸汇、實時計算應用場景

隨著實時技術發(fā)展趨于成熟施符，實時計算應用越來越廣泛，以下僅列舉常見的幾種實時計算的應用場景：

1）實時智能推薦

智能推薦會根據(jù)用戶歷史的購買或瀏覽行為擂找，通過推薦算法訓練模型戳吝，預測用戶未來可能會購買的物品或喜愛的資訊。對個人來說贯涎，推薦系統(tǒng)起著信息過濾的作用听哭，對Web/App服務端來說，推薦系統(tǒng)起著滿足用戶個性化需求塘雳，提升用戶滿意度的作用陆盘。推薦系統(tǒng)本身也在飛速發(fā)展，除了算法越來越完善败明，對時延的要求也越來越苛刻和實時化隘马。利用Flink流計算幫助用戶構(gòu)建更加實時的智能推薦系統(tǒng)，對用戶行為指標進行實時計算妻顶，對模型進行實時更新酸员，對用戶指標進行實時預測，并將預測的信息推送給Web/App端讳嘱，幫助用戶獲取想要的商品信息幔嗦，另一方面也幫助企業(yè)提升銷售額，創(chuàng)造更大的商業(yè)價值沥潭。

2）實時欺詐檢測

在金融領域的業(yè)務中邀泉，常常出現(xiàn)各種類型的欺詐行為，例如信用卡欺詐叛氨，信貸申請欺詐等呼渣，而如何保證用戶和公司的資金安全，是近年來許多金融公司及銀行共同面對的挑戰(zhàn)寞埠。隨著不法分子欺詐手段的不斷升級，傳統(tǒng)的反欺詐手段已經(jīng)不足以解決目前所面臨的問題焊夸。以往可能需要幾個小時才能通過交易數(shù)據(jù)計算出用戶的行為指標仁连，然后通過規(guī)則判別出具有欺詐行為嫌疑的用戶，再進行案件調(diào)查處理阱穗，在這種情況下資金可能早已被不法分子轉(zhuǎn)移饭冬，從而給企業(yè)和用戶造成大量的經(jīng)濟損失。而運用Flink流式計算技術能夠在毫秒內(nèi)就完成對欺詐行為判斷指標的計算揪阶，然后實時對交易流水進行實時攔截钟哥，避免因為處理不及時而導致的經(jīng)濟損失瞬捕。

3）輿情分析

有的客戶需要做輿情分析，要求所有數(shù)據(jù)存放若干年，輿情數(shù)據(jù)每日數(shù)據(jù)量可能超百萬，年數(shù)據(jù)量可達到幾十億的數(shù)據(jù)枫匾。而且爬蟲爬過來的數(shù)據(jù)是輿情，通過大數(shù)據(jù)技術進行分詞之后得到的可能是大段的網(wǎng)友評論，客戶往往要求對輿情進行查詢执虹，做全文本搜索，并要求響應時間控制在秒級唠梨。爬蟲將數(shù)據(jù)爬到大數(shù)據(jù)平臺的Kafka里袋励，在里面做Flink流處理，去重去噪做語音分析当叭，寫到ElasticSearch里茬故。大數(shù)據(jù)的一個特點是多數(shù)據(jù)源，大數(shù)據(jù)平臺能根據(jù)不同的場景選擇不同的數(shù)據(jù)源蚁鳖。

4）復雜事件處理

對于復雜事件處理磺芭，比較常見的集中于工業(yè)領域，例如對車載傳感器才睹，機械設備等實時故障檢測徘跪，這些業(yè)務類型通常數(shù)據(jù)量都非常大，且對數(shù)據(jù)處理的時效性要求非常高琅攘。通過利用Flink提供的CEP進行時間模式的抽取垮庐，同時應用Flink的Sql進行事件數(shù)據(jù)的轉(zhuǎn)換，在流式系統(tǒng)中構(gòu)建實施規(guī)則引擎坞琴，一旦事件觸發(fā)報警規(guī)則哨查，便立即將告警結(jié)果通知至下游通知系統(tǒng)，從而實現(xiàn)對設備故障快速預警檢測剧辐，車輛狀態(tài)監(jiān)控等目的寒亥。

5）實時機器學習

實時機器學習是一個更寬泛的概念，傳統(tǒng)靜態(tài)的機器學習主要側(cè)重于靜態(tài)的模型和歷史數(shù)據(jù)進行訓練并提供預測荧关。很多時候用戶的短期行為溉奕，對模型有修正作用加勤，或者說是對業(yè)務判斷有預測作用。對系統(tǒng)來說项棠，需要采集用戶最近的行為并進行特征工程翅阵，然后給到實時機器學習系統(tǒng)進行機器學習讹语。如果動態(tài)地實施新規(guī)則才菠，或是推出新廣告，就會有很大的參考價值旋炒。

2步悠、實時計算總覽

我們先來看一張大數(shù)據(jù)平臺的實時架構(gòu)圖：

圖片

1）數(shù)據(jù)同步：

在上面這張架構(gòu)圖中，數(shù)據(jù)從Web平臺中產(chǎn)生，通過數(shù)據(jù)同步系統(tǒng)導入到大數(shù)據(jù)平臺厚宰，由于數(shù)據(jù)源不同，這里的數(shù)據(jù)同步系統(tǒng)實際上是多個相關系統(tǒng)的組合撵幽。數(shù)據(jù)庫同步通常用 Sqoop灯荧，日志同步可以選擇 Flume等，不同的數(shù)據(jù)源產(chǎn)生的數(shù)據(jù)質(zhì)量可能差別很大盐杂，數(shù)據(jù)庫中的格式化數(shù)據(jù)直接導入大數(shù)據(jù)系統(tǒng)即可逗载，而日志和爬蟲產(chǎn)生的數(shù)據(jù)就需要進行大量的清洗、轉(zhuǎn)化處理才能有效使用链烈。

2）數(shù)據(jù)存儲****：

該層對原始數(shù)據(jù)厉斟、清洗關聯(lián)后的明細數(shù)據(jù)進行存儲，基于統(tǒng)一的實時數(shù)據(jù)模型分層理念测垛，將不同應用場景的數(shù)據(jù)分別存儲在 Kafka捏膨、HDFS、Kudu食侮、 Clickhouse号涯、Hbase等存儲中。

3）數(shù)據(jù)計算：

計算層主要使用 Flink锯七、Spark链快、Presto 以及 ClickHouse 自帶的計算能力等四種計算引擎，F(xiàn)link 計算引擎主要用于實時數(shù)據(jù)同步眉尸、 流式 ETL域蜗、關鍵系統(tǒng)秒級實時指標計算場景，Spark SQL 主要用于復雜多維分析的準實時指標計算需求場景噪猾，Presto 和 ClickHouse 主要滿足多維自助分析霉祸、對查詢響應時間要求不太高的場景。

4）實時應用：

以統(tǒng)一查詢服務對各個業(yè)務線數(shù)據(jù)場景進行支持袱蜡，業(yè)務主要包括實時大屏丝蹭、實時數(shù)據(jù)產(chǎn)品、實時 OLAP坪蚁、實時特征等奔穿。

當然一個好的大數(shù)據(jù)平臺不能缺少元數(shù)據(jù)管理及數(shù)據(jù)治理：

①元數(shù)據(jù)及指標管理

主要對實時的Kafka表镜沽、Kudu表、Clickhouse表贱田、Hive表等進行統(tǒng)一管理缅茉，以數(shù)倉模型中表的命名方式規(guī)范表的命名，明確每張表的字段含義男摧、使用方蔬墩，指標管理則是盡量通過指標管理系統(tǒng)將所有的實時指標統(tǒng)一管理起來，明確計算口徑彩倚，提供給不同的業(yè)務方使用筹我；

②數(shù)據(jù)質(zhì)量及血緣分析

數(shù)據(jù)質(zhì)量分為平臺監(jiān)控和數(shù)據(jù)監(jiān)控兩個部分，血緣分析則主要是對實時數(shù)據(jù)依賴關系帆离、實時任務的依賴關系進行分析蔬蕊。

以上架構(gòu)只是大數(shù)據(jù)平臺通用的數(shù)據(jù)模型，如果要具體的建設哥谷，需要考慮以下情況岸夯，業(yè)務需求需要實時還是準實時即可，數(shù)據(jù)時效性是秒級還是分鐘級等们妥。

• 在調(diào)度開銷方面猜扮，準實時數(shù)據(jù)是批處理過程，因此仍然需要調(diào)度系統(tǒng)支持监婶，調(diào)度頻率較高旅赢，而實時數(shù)據(jù)卻沒有調(diào)度開銷；

• 在業(yè)務靈活性方面惑惶，因為準實時數(shù)據(jù)是基于 ETL 或 OLAP 引擎實現(xiàn)煮盼，靈活性優(yōu)于基于流計算的方式；

• 在對數(shù)據(jù)晚到的容忍度方面带污，因為準實時數(shù)據(jù)可以基于一個周期內(nèi)的數(shù)據(jù)進行全量計算僵控，因此對于數(shù)據(jù)晚到的容忍度也是比較高的，而實時數(shù)據(jù)使用的是增量計算鱼冀，對于數(shù)據(jù)晚到的容忍度更低一些报破；

• 在適用場景方面，準實時數(shù)據(jù)主要用于有實時性要求但不太高千绪、涉及多表關聯(lián)和業(yè)務變更頻繁的場景充易，如交易類型的實時分析，實時數(shù)據(jù)則更適用于實時性要求高荸型、數(shù)據(jù)量大的場景蔽氨，如實時特征、流量類型實時分析等場景。

3鹉究、實時架構(gòu)

在某些場景中，數(shù)據(jù)的價值隨著時間的推移而逐漸減少踪宠。所以在傳統(tǒng)大數(shù)據(jù)離線數(shù)倉的基礎上自赔，逐漸對數(shù)據(jù)的實時性提出了更高的要求。

于是隨之誕生了大數(shù)據(jù)實時數(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ù)組件進行收集他去，然后分成兩條線進行計算：

• 一條線是進入流式計算平臺（例如 Storm、Flink或者SparkStreaming）倒堕，去計算實時的一些指標灾测；

• 另一條線進入批量數(shù)據(jù)處理離線計算平臺（例如Mapreduce、Hive垦巴，Spark SQL）媳搪，去計算T+1的相關業(yè)務指標，這些指標需要隔日才能看見骤宣。

①為什么Lambda架構(gòu)要分成兩條線計算秦爆？

假如整個系統(tǒng)只有一個批處理層，會導致用戶必須等待很久才能獲取計算結(jié)果憔披，一般有幾個小時的延遲等限。電商數(shù)據(jù)分析部門只能查看前一天的統(tǒng)計分析結(jié)果，無法獲取當前的結(jié)果芬膝，這對于實時決策來說有一個巨大的時間鴻溝望门，很可能導致管理者錯過最佳決策時機。

Lambda架構(gòu)屬于較早的一種架構(gòu)方式蔗候，早期的流處理不如現(xiàn)在這樣成熟怒允，在準確性、擴展性和容錯性上锈遥，流處理層無法直接取代批處理層纫事，只能給用戶提供一個近似結(jié)果，還不能為用戶提供一個一致準確的結(jié)果所灸。因此Lambda架構(gòu)中丽惶，出現(xiàn)了批處理和流處理并存的現(xiàn)象。

在 Lambda 架構(gòu)中爬立，每層都有自己所肩負的任務钾唬。

• 批處理層存儲管理主數(shù)據(jù)集（不可變的數(shù)據(jù)集）和預先批處理計算好的視圖：

批處理層使用可處理大量數(shù)據(jù)的分布式處理系統(tǒng)預先計算結(jié)果。它通過處理所有的已有歷史數(shù)據(jù)來實現(xiàn)數(shù)據(jù)的準確性。這意味著它是基于完整的數(shù)據(jù)集來重新計算的抡秆，能夠修復任何錯誤奕巍，然后更新現(xiàn)有的數(shù)據(jù)視圖。輸出通常存儲在只讀數(shù)據(jù)庫中儒士，更新則完全取代現(xiàn)有的預先計算好的視圖的止。

• 流處理層會實時處理新來的大數(shù)據(jù)：

流處理層通過提供最新數(shù)據(jù)的實時視圖來最小化延遲。流處理層所生成的數(shù)據(jù)視圖可能不如批處理層最終生成的視圖那樣準確或完整着撩，但它們幾乎在收到數(shù)據(jù)后立即可用诅福。而當同樣的數(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時代越來越不適應數(shù)據(jù)分析業(yè)務的需求壶辜。缺點如下：

• 使用兩套大數(shù)據(jù)處理引擎：維護兩個復雜的分布式系統(tǒng)悯舟，成本非常高。

• 批量計算在計算窗口內(nèi)無法完成：在IOT時代砸民，數(shù)據(jù)量級越來越大抵怎，經(jīng)常發(fā)現(xiàn)夜間只有4、5個小時的時間窗口岭参，已經(jīng)無法完成白天20多個小時累計的數(shù)據(jù)反惕，保證早上上班前準時出數(shù)據(jù)已成為每個大數(shù)據(jù)團隊頭疼的問題。

• 數(shù)據(jù)源變化都要重新開發(fā)演侯，開發(fā)周期長：每次數(shù)據(jù)源的格式變化姿染，業(yè)務的邏輯變化都需要針對ETL和Streaming做開發(fā)修改，整體開發(fā)周期很長秒际，業(yè)務反應不夠迅速悬赏。

導致 Lambda 架構(gòu)的缺點根本原因是要同時維護兩套系統(tǒng)架構(gòu)：批處理層和速度層。我們已經(jīng)知道娄徊，在架構(gòu)中加入批處理層是因為從批處理層得到的結(jié)果具有高準確性闽颇，而加入速度層是因為它在處理大規(guī)模數(shù)據(jù)時具有低延時性。

那我們能不能改進其中某一層的架構(gòu)寄锐，讓它具有另外一層架構(gòu)的特性呢兵多？

例如尖啡，改進批處理層的系統(tǒng)讓它具有更低的延時性，又或者是改進速度層的系統(tǒng)剩膘，讓它產(chǎn)生的數(shù)據(jù)視圖更具準確性和更加接近歷史數(shù)據(jù)呢衅斩？

另外一種在大規(guī)模數(shù)據(jù)處理中常用的架構(gòu)——Kappa 架構(gòu)，便是在這樣的思考下誕生的援雇。

2）Kappa架構(gòu)

Kafka的創(chuàng)始人Jay Kreps認為在很多場景下矛渴，維護一套Lambda架構(gòu)的大數(shù)據(jù)處理平臺耗時耗力，于是提出在某些場景下惫搏，沒有必要維護一個批處理層，直接使用一個流處理層即可滿足需求蚕涤，即下圖所示的Kappa架構(gòu)：

圖片

Kappa架構(gòu)

這種架構(gòu)只關注流式計算筐赔，數(shù)據(jù)以流的方式被采集過來，實時計算引擎將計算結(jié)果放入數(shù)據(jù)服務層以供查詢揖铜。可以認為Kappa架構(gòu)是Lambda架構(gòu)的一個簡化版本茴丰，只是去除掉了Lambda架構(gòu)中的離線批處理部分；

Kappa架構(gòu)的興起主要有兩個原因：

• Kafka不僅起到消息隊列的作用天吓，也可以保存更長時間的歷史數(shù)據(jù)贿肩，以替代Lambda架構(gòu)中批處理層數(shù)據(jù)倉庫部分。流處理引擎以一個更早的時間作為起點開始消費龄寞，起到了批處理的作用汰规。

• Flink流處理引擎解決了事件亂序下計算結(jié)果的準確性問題。

Kappa架構(gòu)相對更簡單物邑，實時性更好溜哮，所需的計算資源遠小于Lambda架構(gòu)，隨著實時處理的需求在不斷增長色解，更多的企業(yè)開始使用Kappa架構(gòu)茂嗓。但這不意味著kappa架構(gòu)能夠取代Lambda架構(gòu)。

Lambda和kappa架構(gòu)都有各自的適用領域科阎；例如流處理與批處理分析流程比較統(tǒng)一述吸，且允許一定的容錯，用Kappa比較合適锣笨，少量關鍵指標（例如交易金額蝌矛、業(yè)績統(tǒng)計等）使用Lambda架構(gòu)進行批量計算，增加一次校對過程票唆。

還有一些比較復雜的場景朴读，批處理與流處理產(chǎn)生不同的結(jié)果（使用不同的機器學習模型，專家系統(tǒng)走趋，或者實時計算難以處理的復雜計算）衅金，可能更適合Lambda架構(gòu)。

本文轉(zhuǎn)載自《數(shù)倉建設保姆級5W字教程，離線實時一網(wǎng)打盡（理論+實戰(zhàn)）》