文檔大綱：

一、數倉基本概念

1. 數據倉庫架構

我們在談數倉之前址儒，為了讓大家有直觀的認識，先來談數倉架構衅疙，“架構”是什么莲趣？這個問題從來就沒有一個準確的答案。這里我們引用一段話：在軟件行業(yè)饱溢，一種被普遍接受的架構定義是指系統(tǒng)的一個或多個結構喧伞。結構中包括軟件的構建（構建是指軟件的設計與實現），構建的外部可以看到屬性以及它們之間的相互關系。

這里參考此定義潘鲫，把數據倉庫架構理解成構成數據倉庫的組件及其之間的關系翁逞，畫出下面的數倉架構圖：

數倉架構

上圖中顯示的整個數據倉庫環(huán)境包括操作型系統(tǒng)和數據倉庫系統(tǒng)兩大部分。操作型系統(tǒng)的數據由各種形式的業(yè)務數據組成溉仑，這些數據經過抽取挖函、轉換和裝載（ETL）過程進入數據倉庫系統(tǒng)。

任何事物都是隨著時間的演進變得越來越完善彼念，當然也是越來越復雜挪圾，數倉也不例外。在數據倉庫技術演化過程中逐沙，產生了幾種主要的架構方法哲思，包括數據集市架構、Inmon企業(yè)信息工廠架構吩案、Kimball數據倉庫架構棚赔、混合型數據倉庫架構。這幾種架構我們后面再講徘郭，接下來看下數倉的基本概念靠益。

2. 數據倉庫概念

英文名稱為Data Warehouse，可簡寫為DW或DWH残揉。數據倉庫的目的是構建面向分析的集成化數據環(huán)境胧后，為企業(yè)提供決策支持（Decision Support）。它出于分析性報告和決策支持目的而創(chuàng)建抱环。

數據倉庫本身并不“生產”任何數據壳快，同時自身也不需要“消費”任何的數據，數據來源于外部镇草，并且開放給外部應用眶痰，這也是為什么叫“倉庫”，而不叫“工廠”的原因梯啤。

1) 基本特征

數據倉庫是面向主題的竖伯、集成的、非易失的和時變的數據集合因宇，用以支持管理決策七婴。

面向主題:

傳統(tǒng)數據庫中，最大的特點是面向應用進行數據的組織察滑，各個業(yè)務系統(tǒng)可能是相互分離的打厘。而數據倉庫則是面向主題的。主題是一個抽象的概念杭棵，是較高層次上企業(yè)信息系統(tǒng)中的數據綜合婚惫、歸類并進行分析利用的抽象氛赐。在邏輯意義上，它是對應企業(yè)中某一宏觀分析領域所涉及的分析對象先舷。

集成性:

通過對分散艰管、獨立、異構的數據庫數據進行抽取蒋川、清理牲芋、轉換和匯總便得到了數據倉庫的數據，這樣保證了數據倉庫內的數據關于整個企業(yè)的一致性捺球。

數據倉庫中的綜合數據不能從原有的數據庫系統(tǒng)直接得到缸浦。因此在數據進入數據倉庫之前，必然要經過統(tǒng)一與綜合氮兵，這一步是數據倉庫建設中最關鍵裂逐、最復雜的一步，所要完成的工作有：

要統(tǒng)一源數據中所有矛盾之處泣栈，如字段的同名異義卜高、異名同義、單位不統(tǒng)一南片、字長不一致掺涛，等等。

進行數據綜合和計算疼进。數據倉庫中的數據綜合工作可以在從原有數據庫抽取數據時生成薪缆，但許多是在數據倉庫內部生成的，即進入數據倉庫以后進行綜合生成的伞广。

下圖說明一個保險公司綜合數據的簡單處理過程拣帽，其中數據倉庫中與“保險” 主題有關的數據來自于多個不同的操作型系統(tǒng)。這些系統(tǒng)內部數據的命名可能不同赔癌，數據格式也可能不同诞外。把不同來源的數據存儲到數據倉庫之前澜沟，需要去除這些不一致灾票。

數倉主題

非易失性（不可更新性）:

數據倉庫的數據反映的是一段相當長的時間內歷史數據的內容，是不同時點的數據庫快照的集合茫虽，以及基于這些快照進行統(tǒng)計刊苍、綜合和重組的導出數據。

數據非易失性主要是針對應用而言濒析。數據倉庫的用戶對數據的操作大多是數據查詢或比較復雜的挖掘正什，一旦數據進入數據倉庫以后，一般情況下被較長時間保留号杏。數據倉庫中一般有大量的查詢操作婴氮，但修改和刪除操作很少斯棒。因此，數據經加工和集成進入數據倉庫后是極少更新的主经，通常只需要定期的加載和更新荣暮。

時變性:

數據倉庫包含各種粒度的歷史數據。數據倉庫中的數據可能與某個特定日期罩驻、星期穗酥、月份、季度或者年份有關惠遏。數據倉庫的目的是通過分析企業(yè)過去一段時間業(yè)務的經營狀況砾跃，挖掘其中隱藏的模式。雖然數據倉庫的用戶不能修改數據节吮，但并不是說數據倉庫的數據是永遠不變的抽高。分析的結果只能反映過去的情況，當業(yè)務變化后透绩，挖掘出的模式會失去時效性厨内。因此數據倉庫的數據需要更新，以適應決策的需要渺贤。從這個角度講雏胃，數據倉庫建設是一個項目，更是一個過程志鞍。數據倉庫的數據隨時間的變化表現在以下幾個方面：

（1） 數據倉庫的數據時限一般要遠遠長于操作型數據的數據時限瞭亮。

（2） 操作型系統(tǒng)存儲的是當前數據，而數據倉庫中的數據是歷史數據固棚。

（3） 數據倉庫中的數據是按照時間順序追加的统翩，它們都帶有時間屬性。

3. 為什么要有數據倉庫

先來看下數據倉庫的數據從哪里來此洲，最終要到哪里去厂汗？

通常數據倉庫的數據來自各個業(yè)務應用系統(tǒng)。業(yè)務系統(tǒng)中的數據形式多種多樣呜师，可能是 Oracle娶桦、MySQL、SQL Server等關系數據庫里的結構化數據汁汗，可能是文本衷畦、CSV等平面文件或Word、Excel文檔中的數據知牌，還可能是HTML祈争、XML等自描述的半結構化數據。這些業(yè)務數據經過一系列的數據抽取角寸、轉換菩混、清洗忿墅，最終以一種統(tǒng)一的格式裝載進數據倉庫。數據倉庫里的數據作為分析用的數據源沮峡，提供給后面的即席查詢球匕、 分析系統(tǒng)、數據集市帖烘、報表系統(tǒng)亮曹、數據挖掘系統(tǒng)等。

這時我們就想了秘症，為什么不能把業(yè)務系統(tǒng)的數據直接拿來供即席查詢照卦、分析系統(tǒng)、報表系統(tǒng)等使用呢乡摹，為什么要經過數據倉庫這一步役耕？實際上在數倉出現之前，確實是這么做的聪廉，但是有很多數據分析的先驅者當時已經發(fā)現瞬痘，簡單的“直接訪問”方式很難良好工作，這樣做的失敗案例數不勝數板熊。下面列舉一些直接訪問業(yè)務系統(tǒng)無法工作的原因：

某些業(yè)務數據由于安全或其他因素不能直接訪問框全。

業(yè)務系統(tǒng)的版本變更很頻繁，每次變更都需要重寫分析系統(tǒng)并重新測試干签。

很難建立和維護匯總數據來源于多個業(yè)務系統(tǒng)版本的報表津辩。

業(yè)務系統(tǒng)的列名通常是硬編碼，有時僅僅是無意義的字符串容劳，這讓編寫分析系統(tǒng)更加困難喘沿。

業(yè)務系統(tǒng)的數據格式，如日期竭贩、數字的格式不統(tǒng)一蚜印。

業(yè)務系統(tǒng)的表結構為事務處理性能而優(yōu)化，有時并不適合查詢與分析留量。

沒有適當的方式將有價值的數據合并進特定應用的數據庫窄赋。

沒有適當的位置存儲元數據。

用戶需要看到的顯示數據字段肪获，有時在數據庫中并不存在寝凌。

通常事務處理的優(yōu)先級比分析系統(tǒng)高柒傻，所以如果分析系統(tǒng)和事務處理運行在同一硬件之上孝赫，分析系統(tǒng)往往性能很差。

有誤用業(yè)務數據的風險红符。

極有可能影響業(yè)務系統(tǒng)的性能青柄。

盡管需要增加軟硬件的投入伐债，但建立獨立數據倉庫與直接訪問業(yè)務數據相比，無論是成本還是帶來的好處蒸殿，這樣做都是值得的脱拼。隨著處理器和存儲成本的逐年降低回还，數據倉庫方案的優(yōu)勢更加明顯，在經濟上也更具可行性虹蒋。

4. 數據倉庫與數據庫的區(qū)別

數據庫與數據倉庫的區(qū)別實際講的是 OLTP 與 OLAP 的區(qū)別。

操作型處理飒货，叫聯機事務處理 OLTP（On-Line Transaction Processing魄衅，），也可以稱面向交易的處理系統(tǒng)塘辅，它是針對具體業(yè)務在數據庫聯機的日常操作晃虫，通常對少數記錄進行查詢、修改扣墩。用戶較為關心操作的響應時間哲银、數據的安全性、完整性和并發(fā)支持的用戶數等問題呻惕。傳統(tǒng)的數據庫系統(tǒng)作為數據管理的主要手段荆责，主要用于操作型處理，像Mysql亚脆，Oracle等關系型數據庫一般屬于OLTP草巡。

分析型處理，叫聯機分析處理 OLAP（On-Line Analytical Processing）一般針對某些主題的歷史數據進行分析型酥，支持管理決策山憨。

首先要明白，數據倉庫的出現弥喉，并不是要取代數據庫郁竟。數據庫是面向事務的設計，數據倉庫是面向主題設計的由境。數據庫一般存儲業(yè)務數據棚亩，數據倉庫存儲的一般是歷史數據。

數據庫設計是盡量避免冗余虏杰，一般針對某一業(yè)務應用進行設計讥蟆，比如一張簡單的User表，記錄用戶名纺阔、密碼等簡單數據即可瘸彤，符合業(yè)務應用，但是不符合分析笛钝。數據倉庫在設計是有意引入冗余质况，依照分析需求愕宋，分析維度、分析指標進行設計结榄。

數據庫是為捕獲數據而設計中贝，數據倉庫是為分析數據而設計。

以銀行業(yè)務為例臼朗。數據庫是事務系統(tǒng)的數據平臺邻寿，客戶在銀行做的每筆交易都會寫入數據庫，被記錄下來视哑，這里老厌，可以簡單地理解為用數據庫記賬。數據倉庫是分析系統(tǒng)的數據平臺黎炉，它從事務系統(tǒng)獲取數據枝秤，并做匯總、加工慷嗜，為決策者提供決策的依據淀弹。比如，某銀行某分行一個月發(fā)生多少交易庆械，該分行當前存款余額是多少薇溃。如果存款又多，消費交易又多缭乘，那么該地區(qū)就有必要設立ATM了沐序。

顯然，銀行的交易量是巨大的堕绩，通常以百萬甚至千萬次來計算策幼。事務系統(tǒng)是實時的，這就要求時效性奴紧，客戶存一筆錢需要幾十秒是無法忍受的特姐，這就要求數據庫只能存儲很短一段時間的數據。而分析系統(tǒng)是事后的黍氮，它要提供關注時間段內所有的有效數據唐含。這些數據是海量的，匯總計算起來也要慢一些沫浆，但是捷枯，只要能夠提供有效的分析數據就達到目的了。

數據倉庫专执，是在數據庫已經大量存在的情況下淮捆，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的“大型數據庫”争剿。

5. ?數據倉庫分層架構

按照數據流入流出的過程已艰，數據倉庫架構可分為：源數據痊末、數據倉庫蚕苇、數據應用

數據倉庫

數據倉庫的數據來源于不同的源數據，并提供多樣的數據應用凿叠，數據自下而上流入數據倉庫后向上層開放應用涩笤，而數據倉庫只是中間集成化數據管理的一個平臺。

源數據：此層數據無任何更改盒件，直接沿用外圍系統(tǒng)數據結構和數據蹬碧，不對外開放；為臨時存儲層炒刁，是接口數據的臨時存儲區(qū)域恩沽，為后一步的數據處理做準備。

數據倉庫：也稱為細節(jié)層翔始，DW層的數據應該是一致的罗心、準確的、干凈的數據城瞎，即對源系統(tǒng)數據進行了清洗（去除了雜質）后的數據渤闷。

數據應用：前端應用直接讀取的數據源；根據報表脖镀、專題分析需求而計算生成的數據飒箭。

數據倉庫從各數據源獲取數據及在數據倉庫內的數據轉換和流動都可以認為是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是數據倉庫的流水線蜒灰，也可以認為是數據倉庫的血液弦蹂，它維系著數據倉庫中數據的新陳代謝，而數據倉庫日常的管理和維護工作的大部分精力就是保持ETL的正常和穩(wěn)定强窖。

那么為什么要數據倉庫進行分層呢?

用空間換時間盈匾，通過大量的預處理來提升應用系統(tǒng)的用戶體驗（效率），因此數據倉庫會存在大量冗余的數據毕骡；不分層的話削饵，如果源業(yè)務系統(tǒng)的業(yè)務規(guī)則發(fā)生變化將會影響整個數據清洗過程，工作量巨大未巫。

通過數據分層管理可以簡化數據清洗的過程窿撬，因為把原來一步的工作分到了多個步驟去完成，相當于把一個復雜的工作拆成了多個簡單的工作叙凡，把一個大的黑盒變成了一個白盒劈伴，每一層的處理邏輯都相對簡單和容易理解，這樣我們比較容易保證每一個步驟的正確性，當數據發(fā)生錯誤的時候跛璧，往往我們只需要局部調整某個步驟即可严里。

6. 主要數據倉庫架構

通過上面的內容我們大概了解數倉的概念，接下來就看下數倉的幾種演進架構追城。

1. 數據集市架構

數據集市是按主題域組織的數據集合刹碾，用于支持部門級的決策。有兩種類型的數據集市：獨立數據集市和從屬數據集市座柱。

1) 獨立數據集市

獨立數據集市集中于部門所關心的單一主題域迷帜，數據以部門為基礎部署，無須考慮企業(yè)級別的信息共享與集成色洞。例如戏锹，制造部門、人力資源部門和其他部門都各自有他們自己的數據集市火诸。

優(yōu)點：因為一個部門的業(yè)務相對于整個企業(yè)要簡單锦针，數據量也小得多，所以部門的獨立數據集市具有周期短置蜀、見效快的特點奈搜。

缺點：

從業(yè)務角度看，當部門的分析需求擴展盾碗，或者需要分析跨部門或跨主題域的數據時媚污，獨立數據市場會顯得力不從心。

當數據存在歧義廷雅，比如同一個產品耗美，在A部門和B部門的定義不同時，將無法在部門間進行信息比較航缀。

每個部門使用不同的技術商架，建立不同的ETL的過程，處理不同的事務系統(tǒng)芥玉，而在多個獨立的數據集市之間還會存在數據的交叉與重疊蛇摸，甚至會有數據不一致的情況。

2) 從屬數據集市

從屬數據集市的數據來源于數據倉庫灿巧。數據倉庫里的數據經過整合赶袄、重構、匯總后傳遞給從屬數據集市抠藕。

建立從屬數據集市的好處主要有：

性能：當數據倉庫的查詢性能出現問題饿肺，可以考慮建立幾個從屬數據集市，將查詢從數據倉庫移出到數據集市盾似。

安全：每個部門可以完全控制他們自己的數據敬辣。

數據一致：因為每個數據集市的數據來源都是同一個數據倉庫，有效消除了數據不一致的情況。

2. Inmon企業(yè)工廠架構

上圖的前兩步不過多介紹溉跃，直接從第三步開始村刨。

企業(yè)級數據倉庫：是該架構中的核心組件。正如Inmon數據倉庫所定義的撰茎，企業(yè)級數據倉庫是一個細節(jié)數據的集成資源庫嵌牺。其中的數據以最低粒度級別被捕獲，存儲在滿足三范式設計的關系數據庫中乾吻。

部門級數據集市：是面向主題數據的部門級視圖髓梅，數據從企業(yè)級數據倉庫獲取拟蜻。數據在進入部門數據集市時可能進行聚合绎签。數據集市使用多維模型設計，用于數據分析酝锅。重要的一點是诡必，所有的報表工具、BI工具或其他數據分析應用都從數據集市查詢數據搔扁，而不是直接查詢企業(yè)級數據倉庫爸舒。

3. Kimball數據倉庫架構

對比上一張圖可以看到，Kimball與Inmon兩種架構的主要區(qū)別在于核心數據倉庫的設計和建立稿蹲。

Kimball的數據倉庫包含高粒度的企業(yè)數據扭勉，使用多維模型設計，這也意味著數據倉庫由星型模式的維度表和事實表構成苛聘。分析系統(tǒng)或報表工具可以直接訪問多維數據倉庫里的數據涂炎。

在此架構中的數據集市也與Inmon中的不同。這里的數據集市是一個邏輯概念设哗，只是多維數據倉庫中的主題域劃分唱捣，并沒有自己的物理存儲，也可以說是虛擬的數據集市网梢。

4. 混合型數據倉庫架構

所謂的混合型結構颜启，指的是在一個數據倉庫環(huán)境中袱结，聯合使用Inmon和Kimball兩種架構。

從架構圖可以看到，這種架構將Inmon方法中的數據集市部分替換成了一個多維數據倉庫川抡，而數據集市則是多維數據倉庫上的邏輯視圖。

使用這種架構的好處是：既可以利用規(guī)范化設計消除數據冗余忠蝗，保證數據的粒度足夠細船万；又可以利用多維結構更靈活地在企業(yè)級實現報表和分析。

7. 數據倉庫元數據的管理

元數據（Meta Date）啸盏，主要記錄數據倉庫中模型的定義重贺、各層級間的映射關系、監(jiān)控數據倉庫的數據狀態(tài)及ETL的任務運行狀態(tài)。一般會通過元數據資料庫（Metadata Repository）來統(tǒng)一地存儲和管理元數據气笙，其主要目的是使數據倉庫的設計次企、部署、操作和管理能達成協(xié)同和一致潜圃。

元數據是數據倉庫管理系統(tǒng)的重要組成部分缸棵，元數據管理是企業(yè)級數據倉庫中的關鍵組件，貫穿數據倉庫構建的整個過程谭期，直接影響著數據倉庫的構建堵第、使用和維護。

構建數據倉庫的主要步驟之一是ETL隧出。這時元數據將發(fā)揮重要的作用踏志，它定義了源數據系統(tǒng)到數據倉庫的映射、數據轉換的規(guī)則胀瞪、數據倉庫的邏輯結構针余、數據更新的規(guī)則、數據導入歷史記錄以及裝載周期等相關內容凄诞。數據抽取和轉換的專家以及數據倉庫管理員正是通過元數據高效地構建數據倉庫圆雁。

用戶在使用數據倉庫時，通過元數據訪問數據帆谍，明確數據項的含義以及定制報表伪朽。

數據倉庫的規(guī)模及其復雜性離不開正確的元數據管理，包括增加或移除外部數據源汛蝙，改變數據清洗方法烈涮，控制出錯的查詢以及安排備份等。

元數據可分為技術元數據和業(yè)務元數據患雇。技術元數據為開發(fā)和管理數據倉庫的IT 人員使用跃脊，它描述了與數據倉庫開發(fā)、管理和維護相關的數據苛吱，包括數據源信息酪术、數據轉換描述、數據倉庫模型翠储、數據清洗與更新規(guī)則绘雁、數據映射和訪問權限等。而業(yè)務元數據為管理層和業(yè)務分析人員服務援所，從業(yè)務角度描述數據庐舟，包括商務術語、數據倉庫中有什么數據住拭、數據的位置和數據的可用性等挪略，幫助業(yè)務人員更好地理解數據倉庫中哪些數據是可用的以及如何使用历帚。

由上可見，元數據不僅定義了數據倉庫中數據的模式杠娱、來源挽牢、抽取和轉換規(guī)則等，而且是整個數據倉庫系統(tǒng)運行的基礎摊求，元數據把數據倉庫系統(tǒng)中各個松散的組件聯系起來禽拔，組成了一個有機的整體。

8. 數倉常見術語解析

本小節(jié)結構如下圖所示：

1. 數倉名詞解釋

1. 實體

實體是指依附的主體室叉，就是我們分析的一個對象睹栖，比如我們分析商品的銷售情況，如華為手機近半年的銷售量是多少茧痕，那華為手機就是一個實體野来；我們分析用戶的活躍度，用戶就是一個實體凿渊。當然實體也可以現實中不存在的梁只，比如虛擬的業(yè)務對象缚柳，活動埃脏，會員等都可看做一個實體。

實體的存在是為了業(yè)務分析秋忙，作為分析的一個篩選的維度彩掐，擁有描述自己的屬性，本身具有可分析的價值灰追。

2. 維度

維度就是看待問題的角度堵幽，分析業(yè)務數據，從什么角度分析弹澎，就建立什么樣的維度朴下。所以維度就是要對數據進行分析時所用的一個量，比如你要分析產品銷售情況苦蒿，你可以選擇按商品類別來進行分析殴胧，這就構成一個維度，把所有商品類別集合在一起佩迟，就構成了維度表团滥。

3. 度量

度量是業(yè)務流程節(jié)點上的一個數值。比如銷量报强，價格灸姊，成本等等。

事實表中的度量可分為三類：完全可加秉溉，半可加力惯，不可加碗誉。

完全可加的度量是最靈活，最有用的父晶，比如說銷量诗充，銷售額等，可進行任意維度匯總诱建；

半可加的度量可以對某些維度匯總蝴蜓，但不能對所有維度匯總，差額是常見的半可加度量俺猿，它除了時間維度外茎匠，可以跨所有維度進行加法操作；

還有一種是完全不可加的押袍，例如：比率诵冒。對于這類非可加度量，一種好的方法是谊惭，盡可能存儲非可加度量的完全可加分量汽馋，并在計算出最終的非可加事實前，將這些分量匯總到最終的結果集中圈盔。

4. 粒度

粒度就是業(yè)務流程中對度量的單位豹芯，比如商品是按件記錄度量，還是按批記錄度量驱敲。

在數倉建設中铁蹈，我們說這是用戶粒度的事實表，那么表中每行數據都是一個用戶众眨，無重復用戶握牧；例如還有銷售粒度的表，那么表中每行都是一條銷售記錄娩梨。

選擇合適的粒度級別是數據倉庫建設好壞的重要關鍵內容沿腰，在設計數據粒度時，通常需重點考慮以下因素：

要接受的分析類型狈定、可接受的數據最低粒度和能存儲的數據量颂龙；

粒度的層次定義越高，就越不能在該倉庫中進行更細致的分析掸冤；

如果存儲資源有一定的限制厘托，就只能采用較高的數據粒度劃分；

數據粒度劃分策略一定要保證：數據的粒度確實能夠滿足用戶的決策分析需要稿湿，這是數據粒度劃分策略中最重要的一個準則铅匹。

5. 口徑

口徑就是取數邏輯（如何取數的），比如要取的數是10歲以下兒童中男孩的平均身高饺藤，這就是統(tǒng)計的口徑包斑。

6. 指標

指標是口徑的衡量值流礁，也就是最后的結果。比如最近七天的訂單量罗丰，一個促銷活動的購買轉化率等神帅。

一個指標具體到計算實施，主要有以下幾部分組成：

指標加工邏輯萌抵，比如count ,sum, avg

維度找御，比如按部門、地域進行指標統(tǒng)計绍填，對應sql中的group by

業(yè)務限定/修飾詞霎桅，比如以不同的支付渠道來算對應的指標，微信支付的訂單退款率讨永，支付寶支付的訂單退款率 滔驶。對應sql中的where。

除此之外卿闹，指標本身還可以衍生揭糕、派生出更多的指標，基于這些特點锻霎，可以將指標進行分類：

原子指標：基本業(yè)務事實著角，沒有業(yè)務限定、沒有維度量窘。比如訂單表中的訂單量雇寇、訂單總金額都算原子指標；

業(yè)務方更關心的指標蚌铜，是有實際業(yè)務含義，可以直接取數據的指標嫩海。比如店鋪近1天訂單支付金額就是一個派生指標冬殃，會被直接在產品上展示給商家看。

但是這個指標卻不能直接從數倉的統(tǒng)一中間層里取數（因為沒有現成的事實字段叁怪，數倉提供的一般都是大寬表）审葬。需要有一個橋梁連接數倉中間層和業(yè)務方的指標需求，于是便有了派生指標

派生指標：維度+修飾詞+原子指標奕谭。店鋪近1天訂單支付金額中店鋪是維度涣觉，近1天是一個時間類型的修飾詞，支付金額是一個原子指標血柳；

維度：觀察各項指標的角度官册；

修飾詞：維度的一個或某些值，比如維度性別下难捌，男和女就是2種修飾詞膝宁。

衍生指標：比如某一個促銷活動的轉化率就是衍生指標鸦难，因為需要促銷投放人數指標和促銷訂單數指標進行計算得出。

7. 標簽

標簽是人為設定的员淫、根據業(yè)務場景需求合蔽，對目標對象運用一定的算法得到的高度精煉的特征標識〗榉担可見標簽是經過人為再加工后的結果拴事，如網紅、白富美圣蝎、蘿莉挤聘。對于有歧義的標簽，我們內部可進行標簽區(qū)分捅彻，比如：蘋果组去，我們可以定義蘋果指的是水果，蘋果手機才指的是手機步淹。

8. 自然鍵

由現實中已經存在的屬性組成的鍵从隆，它在業(yè)務概念中是唯一的，并具有一定的業(yè)務含義缭裆，比如商品ID键闺，員工ID。

以數倉角度看澈驼，來自于業(yè)務系統(tǒng)的標識符就是自然鍵辛燥，比如業(yè)務庫中員工的編號。

9. 持久鍵

保持永久性不會發(fā)生變化缝其。有時也被叫做超自然持久鍵挎塌。比如身份證號屬于持久鍵。

自然鍵和持久鍵區(qū)別：舉個例子就明白了内边，比如說公司員工離職之后又重新入職榴都，他的自然鍵也就是員工編號發(fā)生了變化，但是他的持久鍵身份證號是不變的漠其。

10. 代理鍵

就是不具有業(yè)務含義的鍵嘴高。代理鍵有許多其他的稱呼：無意義鍵、整數鍵和屎、非自然鍵拴驮、人工鍵、合成鍵等柴信。

代理鍵就是簡單的以按照順序序列生產的整數表示憔恳。產品行的第1行代理鍵為1较雕，則下一行的代理鍵為2胶哲，如此進行。代理鍵的作用僅僅是連接維度表和事實表抹竹。

11. 退化維度

退化維度，就是那些看起來像是事實表的一個維度關鍵字止潮，但實際上并沒有對應的維度表窃判，就是維度屬性存儲到事實表中，這種存儲到事實表中的維度列被稱為退化維度喇闸。與其他存儲在維表中的維度一樣袄琳，退化維度也可以用來進行事實表的過濾查詢、實現聚合操作等燃乍。

那么究竟怎么定義退化維度呢唆樊？比如說訂單id，這種量級很大的維度刻蟹，沒必要用一張維度表來進行存儲逗旁，而我們進行數據查詢或者數據過濾的時候又非常需要，所以這種就冗余在事實表里面舆瘪，這種就叫退化維度片效，citycode這種我們也會冗余在事實表里面，但是它有對應的維度表英古，所以它不是退化維度淀衣。

12. 下鉆

這是在數據分析中常見的概念，下鉆可以理解成增加維的層次召调，從而可以由粗粒度到細粒度來觀察數據膨桥，比如對產品銷售情況分析時，可以沿著時間維從年到月到日更細粒度的觀察數據唠叛。從年的維度可以下鉆到月的維度只嚣、日的維度等。

13. 上卷

知道了下鉆玻墅，上卷就容易理解了介牙，它倆是相逆的操作，所以上卷可以理解為刪掉維的某些層澳厢，由細粒度到粗粒度觀察數據的操作或沿著維的層次向上聚合匯總數據。

14. 數據集市

數據集市（Data Mart）囚似，也叫數據市場剩拢，數據集市就是滿足特定的部門或者用戶的需求，按照多維的方式進行存儲饶唤，包括定義維度徐伐、需要計算的指標、維度的層次等募狂，生成面向決策分析需求的數據立方體办素。其實就是從數據倉庫中抽取出來的一個小合集角雷。

2. 數倉名詞之間關系

1. 實體表，事實表性穿，維度表之間的關系

在Kimball維度建模中有維度與事實勺三，在Inmon范式建模中有實體與關系，如果我們分開兩種建模方式看這些概念比較容易理解需曾。但是目前也出現了不少混合建模方式吗坚，兩種建模方式結合起來看，這些概念是不是容易記憶混亂呆万，尤其事實表和實體表商源，它們之間到底有怎樣區(qū)別與聯系，先看下它們各自概念：

維度表：維度表可以看成是用戶用來分析一個事實的窗口谋减，它里面的數據應該是對事實的各個方面描述牡彻，比如時間維度表，地域維度表出爹，維度表是事實表的一個分析角度庄吼。

事實表：事實表其實就是通過各種維度和一些指標值的組合來確定一個事實的，比如通過時間維度以政，地域組織維度霸褒，指標值可以去確定在某時某地的一些指標值怎么樣的事實。事實表的每一條數據都是幾條維度表的數據和指標值交匯而得到的盈蛮。

實體表：實體表就是一個實際對象的表废菱，實體表放的數據一定是一條條客觀存在的事物數據，比如說各種商品抖誉，它就是客觀存在的殊轴，所以可以將其設計一個實體表。實時表只描述各個事物袒炉，并不存在具體的事實旁理，所以也有人稱實體表是無事實的事實表。

舉個例子：比如說手機商場中有蘋果手機我磁，華為手機等各品牌各型號的手機孽文，這些數據可以組成一個手機實體表，但是表中沒有可度量的數據夺艰。某天蘋果手機賣了15臺芋哭，華為手機賣了20臺，這些手機銷售數據屬于事實郁副，組成一個事實表减牺。這樣就可以使用日期維度表和地域維度表對這個事實表進行各種維度分析。

2. 指標與標簽的區(qū)別

概念不同

指標是用來定義、評價和描述特定事物的一種標準或方式拔疚。比如：新增用戶數肥隆、累計用戶數、用戶活躍率等是衡量用戶發(fā)展情況的指標稚失；

標簽是人為設定的栋艳、根據業(yè)務場景需求，對目標對象運用一定的算法得到的高度精煉的特征標識墩虹≈鼋恚可見標簽是經過人為再加工后的結果，如網紅诫钓、白富美旬昭、蘿莉。

構成不同

指標名稱是對事物質與量兩方面特點的命名菌湃；指標取值是指標在具體時間问拘、地域、條件下的數量表現惧所，如人的體重骤坐，指標名稱是體重，指標的取值就是120斤下愈；

標簽名稱通常都是形容詞或形容詞+名詞的結構纽绍，標簽一般是不可量化的，通常是孤立的势似，除了基礎類標簽拌夏，通過一定算法加工出來的標簽一般都沒有單位和量綱。如將超過200斤的稱為大胖子履因。

分類不同

對指標的分類：

按照指標計算邏輯障簿，可以將指標分為原子指標、派生指標栅迄、衍生指標三種類型站故；

按照對事件描述內容的不同，分為過程性指標和結果性指標毅舆；

對標簽的分類：

按照標簽的變化性分為靜態(tài)標簽和動態(tài)標簽西篓；

按照標簽的指代和評估指標的不同，可分為定性標簽和定量標簽憋活；

指標最擅長的應用是監(jiān)測污淋、分析、評價和建模余掖。

標簽最擅長的應用是標注、刻畫、分類和特征提取盐欺。

特別需要指出的是赁豆，由于對結果的標注也是一種標簽，所以在自然語言處理和機器學習相關的算法應用場景下冗美，標簽對于監(jiān)督式學習有重要價值魔种，只是單純的指標難以做到的。而指標在任務分配粉洼、績效管理等領域的作用节预，也是標簽無法做到的。

3. 維度和指標區(qū)別與聯系

維度就是數據的觀察角度属韧，即從哪個角度去分析問題安拟，看待問題。

指標就是從維度的基礎上去衡算這個結果的值宵喂。

維度一般是一個離散的值糠赦，比如時間維度上每一個獨立的日期或地域，因此統(tǒng)計時锅棕，可以把維度相同記錄的聚合在一起拙泽，應用聚合函數做累加、均值裸燎、最大值顾瞻、最小值等聚合計算。

指標就是被聚合的通計算德绿，即聚合運算的結果荷荤，一般是一個連續(xù)的值。

4. 自然鍵與代理鍵在數倉的使用區(qū)別

數倉工具箱中說維度表的唯一主鍵應該是代理鍵而不應該是自然鍵脆炎。有時建模人員不愿意放棄使用自然鍵梅猿，因為他們希望與操作型代碼查詢事實表，而不希望與維度表做連接操作秒裕。然而袱蚓，應該避免使用包含業(yè)務含義的多維鍵，因為不管我們做出任何假設最終都可能變得無效几蜻，因為我們控制不了業(yè)務庫的變動喇潘。

所以數據倉庫中維度表與事實表的每個連接應該基于無實際含義的整數代理鍵。避免使用自然鍵作為維度表的主鍵梭稚。

5. 數據集市和數據倉庫的關系

數據集市是企業(yè)級數據倉庫的一個子集颖低，他主要面向部門級業(yè)務，并且只面向某個特定的主題弧烤。為了解決靈活性和性能之間的矛盾忱屑，數據集市就是數據倉庫體系結構中增加的一種小型的部門或工作組級別的數據倉庫。數據集市存儲為特定用戶預先計算好的數據，從而滿足用戶對性能的需求莺戒。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸伴嗡。

數據集市和數據倉庫的主要區(qū)別：數據倉庫是企業(yè)級的，能為整個企業(yè)各個部門的運行提供決策支持手段从铲；而數據集市則是一種微型的數據倉庫,它通常有更少的數據,更少的主題區(qū)域,以及更少的歷史數據,因此是部門級的瘪校，一般只能為某個局部范圍內的管理人員服務，因此也稱之為部門級數據倉庫名段。

二阱扬、離線數倉建設核心

數據倉庫的核心是展現層和提供優(yōu)質的服務。ETL 及其規(guī)范伸辟、分層等所做的一切都是為了一個更清晰易用的展現層麻惶。

1. 數倉分層

數倉分層的原則：

為便于數據分析，要屏蔽底層復雜業(yè)務自娩，簡單用踩、完整、集成的將數據暴露給分析層忙迁。

底層業(yè)務變動與上層需求變動對模型沖擊最小化脐彩，業(yè)務系統(tǒng)變化影響削弱在基礎數據層，結合自上而下的建設方法削弱需求變動對模型的影響姊扔。

高內聚松耦合惠奸，即主題之內或各個完整意義的系統(tǒng)內數據的高內聚，主題之間或各個完整意義的系統(tǒng)間數據的松耦合恰梢。

構建倉庫基礎數據層佛南，使底層業(yè)務數據整合工作與上層應用開發(fā)工作相隔離，為倉庫大規(guī)模開發(fā)奠定基礎 倉庫層次更加清晰嵌言，對外暴露數據更加統(tǒng)一嗅回。

一般采用如下分層結構：

1. 數據源層：ODS（Operational Data Store）

ODS 層，是最接近數據源中數據的一層摧茴，為了考慮后續(xù)可能需要追溯數據問題绵载，因此對于這一層就不建議做過多的數據清洗工作，原封不動地接入原始數據即可苛白，至于數據的去噪娃豹、去重、異常值處理等過程可以放在后面的 DWD 層來做购裙。

2. 數據倉庫層：DW（Data Warehouse）

數據倉庫層是我們在做數據倉庫時要核心設計的一層懂版，在這里，從 ODS 層中獲得的數據按照主題建立各種數據模型躏率。

DW 層又細分為?DWD（Data Warehouse Detail）層躯畴、DWM（Data WareHouse Middle）層和?DWS（Data WareHouse Servce） 層民鼓。

1) 數據明細層：DWD（Data Warehouse Detail）

該層一般保持和 ODS 層一樣的數據粒度，并且提供一定的數據質量保證私股。DWD 層要做的就是將數據清理摹察、整合、規(guī)范化倡鲸、臟數據、垃圾數據黄娘、規(guī)范不一致的峭状、狀態(tài)定義不一致的、命名不規(guī)范的數據都會被處理逼争。

同時优床，為了提高數據明細層的易用性，該層會采用一些維度退化手法誓焦，將維度退化至事實表中胆敞，減少事實表和維表的關聯。

另外杂伟，在該層也會做一部分的數據聚合嗜愈，將相同主題的數據匯集到一張表中疙筹，提高數據的可用性 。

2) 數據中間層：DWM（Data WareHouse Middle）

該層會在 DWD 層的數據基礎上，數據做輕度的聚合操作益缠，生成一系列的中間表，提升公共指標的復用性匈庭，減少重復加工仰禀。

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

在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統(tǒng)計指標挣跋，會存在計算量太大并且維度太少的問題三圆，因此一般的做法是，在 DWM 層先計算出多個小的中間表浆劲，然后再拼接成一張 DWS 的寬表嫌术。由于寬和窄的界限不易界定，也可以去掉 DWM 這一層牌借，只留 DWS 層度气，將所有的數據再放在 DWS 亦可。

3) 數據服務層：DWS（Data WareHouse Servce）

DWS 層為公共匯總層膨报，會進行輕度匯總磷籍，粒度比明細數據稍粗适荣，基于 DWD 層上的基礎數據，整合匯總成分析某一個主題域的服務數據院领，一般是寬表弛矛。DWS 層應覆蓋 80% 的應用場景。又稱數據集市或寬表比然。

按照業(yè)務劃分丈氓，如主題域流量、訂單强法、用戶等万俗，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務查詢饮怯，OLAP 分析闰歪，數據分發(fā)等。

一般來講蓖墅，該層的數據表會相對比較少库倘，一張表會涵蓋比較多的業(yè)務內容，由于其字段較多论矾，因此一般也會稱該層的表為寬表教翩。

3. 數據應用層：APP（Application）

在這里，主要是提供給數據產品和數據分析使用的數據拇囊，一般會存放在 ES迂曲、 PostgreSql、Redis 等系統(tǒng)中供線上系統(tǒng)使用寥袭，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用路捧。比如我們經常說的報表數據，一般就放在這里传黄。

4. 維表層：DIM（Dimension）

如果維表過多杰扫，也可針對維表設計單獨一層，維表層主要包含兩部分數據：

高基數維度數據：一般是用戶資料表膘掰、商品資料表類似的資料表章姓。數據量可能是千萬級或者上億級別。

低基數維度數據：一般是配置表识埋，比如枚舉值對應的中文含義凡伊，或者日期維表。數據量可能是個位數或者幾千幾萬窒舟。

2. 數倉建模方法

數倉建模在哪層建設呢系忙？我們以維度建模為例，建模是在數據源層的下一層進行建設惠豺，在上節(jié)的分層架構中银还，就是在DW層進行數倉建模风宁，所以DW層是數倉建設的核心層。

那數倉建模怎么建呢蛹疯？其實數據倉庫的建模方法有很多種戒财，每一種建模方法代表了哲學上的一個觀點，代表了一種歸納捺弦、概括世界的一種方法饮寞。常見的有?范式建模法、維度建模法羹呵、實體建模法等骂际，每種方法從本質上將是從不同的角度看待業(yè)務中的問題。

1. 范式建模法（Third Normal Form冈欢，3NF）

范式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡盈简，主要解決關系型數據庫的數據存儲凑耻，利用的一種技術層面上的方法。目前柠贤，我們在關系型數據庫中的建模方法香浩，大部分采用的是三范式建模法。

范式 是符合某一種級別的關系模式的集合臼勉。構造數據庫必須遵循一定的規(guī)則邻吭，而在關系型數據庫中這種規(guī)則就是范式，這一過程也被稱為規(guī)范化宴霸。目前關系數據庫有六種范式：第一范式（1NF）囱晴、第二范式（2NF）、第三范式（3NF）瓢谢、Boyce-Codd范式（BCNF）畸写、第四范式（4NF）和第五范式（5NF）。

在數據倉庫的模型設計中氓扛，一般采用第三范式枯芬。一個符合第三范式的關系必須具有以下三個條件 :

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

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

每個非主屬性不能依賴于其他關系中的屬性千所，因為這樣的話，這種屬性應該歸到其他關系中去蒜埋。

范式建模

根據 Inmon 的觀點淫痰，數據倉庫模型的建設方法和業(yè)務系統(tǒng)的企業(yè)數據模型類似。在業(yè)務系統(tǒng)中理茎，企業(yè)數據模型決定了數據的來源黑界，而企業(yè)數據模型也分為兩個層次管嬉，即主題域模型和邏輯模型。同樣朗鸠，主題域模型可以看成是業(yè)務模型的概念模型蚯撩，而邏輯模型則是域模型在關系型數據庫上的實例化。

2. 維度建模法（Dimensional Modeling）

維度模型是數據倉庫領域另一位大師Ralph Kimall所倡導烛占，他的《數據倉庫工具箱》是數據倉庫工程領域最流行的數倉建模經典胎挎。維度建模以分析決策的需求出發(fā)構建模型，構建的數據模型為分析需求服務忆家，因此它重點解決用戶如何更快速完成分析需求犹菇，同時還有較好的大規(guī)模復雜查詢的響應性能。

維度建模

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

維度建模中比較重要的概念就是 事實表（Fact table）和維度表（Dimension table）。其最簡單的描述就是卸例，按照事實表称杨、維度表來構建數據倉庫、數據集市筷转。

3. 實體建模法（Entity Modeling）

實體建模法并不是數據倉庫建模中常見的一個方法姑原，它來源于哲學的一個流派。從哲學的意義上說呜舒，客觀世界應該是可以細分的锭汛，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關系組成袭蝗。那么我們在數據倉庫的建模過程中完全可以引入這個抽象的方法唤殴，將整個業(yè)務也可以劃分成一個個的實體，而每個實體之間的關系呻袭，以及針對這些關系的說明就是我們數據建模需要做的工作眨八。

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易左电。即我們可以將任何一個業(yè)務過程劃分成 3 個部分廉侧，實體，事件篓足，說明段誊，如下圖所示：

實體建模

上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”栈拖。以這個業(yè)務事實為例连舍，我們可以把“小明”，“學猩矗”看成是一個實體索赏，“上學”描述的是一個業(yè)務過程盼玄，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明潜腻。

3. 維度建模詳解

目前在互聯網公司最常用的建模方法就是維度建模埃儿，我們將重點講解！

維度建模是專門應用于分析型數據庫融涣、數據倉庫童番、數據集市建模的方法。數據集市可以理解為是一種"小型數據倉庫"威鹿。

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

1. 維度建模中表的類型

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

事實表：必然存在的一些數據幼东，像采集的日志文件，訂單表科雳，都可以作為事實表 筋粗。

特征：是一堆主鍵的集合，每個主鍵對應維度表中的一條記錄炸渡，客觀存在的，根據主題確定出需要使用的數據

維度表：維度就是所分析的數據的一個量丽已，維度表就是以合適的角度來創(chuàng)建的表蚌堵，分析問題的一個角度：時間、地域沛婴、終端吼畏、用戶等角度

1. 事實表

發(fā)生在現實世界中的操作型事件，其所產生的可度量數值嘁灯，存儲在事實表中泻蚊。從最低的粒度級別來看，事實表行對應一個度量事件丑婿，反之亦然性雄。

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

事實與維度

圖中的訂單表就是一個事實表秒旋，你可以理解他就是在現實中發(fā)生的一次操作型事件，我們每完成一個訂單诀拭，就會在訂單中增加一條記錄迁筛。事實表的特征：表里沒有存放實際的內容，他是一堆主鍵的集合耕挨，這些ID分別能對應到維度表中的一條記錄细卧。事實表包含了與各維度表相關聯的外鍵尉桩，可與維度表關聯。事實表的度量通常是數值類型贪庙，且記錄數會不斷增加蜘犁，表數據規(guī)模迅速增長。

明細表（寬表）：

事實表的數據中插勤，有些屬性共同組成了一個字段（糅合在一起）沽瘦，比如年月日時分秒構成了時間,當需要根據某一屬性進行分組統(tǒng)計的時候，需要截取拼接之類的操作农尖，效率極低析恋。如：

local_time

2021-03-18 06:31:42

為了分析方便，可以事實表中的一個字段切割提取多個屬性出來構成新的字段盛卡，因為字段變多了助隧，所以稱為寬表，原來的成為窄表滑沧。

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

yearmonthdayhourms

20210318063142

又因為寬表的信息更加清晰明細并村，所以也可以稱之為明細表。

事實表種類

事實表分為以下6類：

事務事實表

周期快照事實表

累積快照事實表

無事實的事實表

聚集事實表

合并事實表

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

事務事實表

表中的一行對應空間或時間上某點的度量事件滓技。就是一行數據中必須有度量字段哩牍，什么是度量，就是指標令漂，比如說銷售金額膝昆，銷售數量等這些可加的或者半可加就是度量值。另一點就是事務事實表都包含一個與維度表關聯的外鍵叠必。并且度量值必須和事務粒度保持一致荚孵。

周期快照事實表

顧名思義，周期事實表就是每行都帶有時間值字段纬朝，代表周期收叶，通常時間值都是標準周期，如某一天共苛，某周判没，某月等。粒度是周期俄讹，而不是個體的事務哆致，也就是說一個周期快照事實表中數據可以是多個事實，但是它們都屬于某個周期內患膛。

累計快照事實表

周期快照事實表是單個周期內數據摊阀，而累計快照事實表是由多個周期數據組成，每行匯總了過程開始到結束之間的度量。每行數據相當于管道或工作流胞此，有事件的起點臣咖，過程，終點漱牵，并且每個關鍵步驟都包含日期字段肌割。如訂單數據缩麸，累計快照事實表的一行就是一個訂單翼悴，當訂單產生時插入一行全度，當訂單發(fā)生變化時，這行就被修改闻镶。

無事實的事實表

我們以上討論的事實表度量都是數字化的甚脉，當然實際應用中絕大多數都是數字化的度量，但是也可能會有少量的沒有數字化的值但是還很有價值的字段铆农，無事實的事實表就是為這種數據準備的牺氨，利用這種事實表可以分析發(fā)生了什么。

聚集事實表

聚集墩剖，就是對原子粒度的數據進行簡單的聚合操作猴凹，目的就是為了提高查詢性能。如我們需求是查詢全國所有門店的總銷售額岭皂，我們原子粒度的事實表中每行是每個分店每個商品的銷售額郊霎，聚集事實表就可以先聚合每個分店的總銷售額，這樣匯總所有門店的銷售額時計算的數據量就會小很多爷绘。

合并事實表

這種事實表遵循一個原則歹篓，就是相同粒度，數據可以來自多個過程揉阎，但是只要它們屬于相同粒度，就可以合并為一個事實表背捌，這類事實表特別適合經常需要共同分析的多過程度量毙籽。

2．維度表

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

維度表示你要對數據進行分析時所用的一個量蝇刀，比如你要分析產品銷售情況螟加， 你可以選擇按類別來進行分析，或按區(qū)域來分析。每個類別就構成一個維度捆探。上圖中的用戶表然爆、商家表、時間表這些都屬于維度表黍图，這些表都有一個唯一的主鍵曾雕，然后在表中存放了詳細的數據信息。

總的說來助被，在數據倉庫中不需要嚴格遵守規(guī)范化設計原則剖张。因為數據倉庫的主導功能就是面向分析，以查詢?yōu)橹骺罚簧婕皵祿虏僮鳌?b>事實表的設計是以能夠正確記錄歷史信息為準則搔弄，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。

維度表結構

維度表謹記一條原則检盼，包含單一主鍵列肯污，但有時因業(yè)務復雜，也可能出現聯合主鍵吨枉，請盡量避免蹦渣，如果無法避免，也要確保必須是單一的貌亭，這很重要柬唯，如果維表主鍵不是單一，和事實表關聯時會出現數據發(fā)散圃庭，導致最后結果可能出現錯誤锄奢。

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

跨表鉆取

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

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

上鉆（roll-up）：上卷是沿著維的層次向上聚集匯總數據灰伟。例如，對產品銷售數據儒旬，沿著時間維上卷栏账，可以求出所有產品在所有地區(qū)每月（或季度或年或全部）的銷售額。

下鉆（drill-down）：下鉆是上鉆的逆操作栈源，它是沿著維的層次向下挡爵，查看更詳細的數據。

退化維度

退化維度就是將維度退回到事實表中甚垦。因為有時維度除了主鍵沒有其他內容茶鹃，雖然也是合法維度鍵涣雕，但是一般都會退回到事實表中，減少關聯次數前计，提高查詢性能

多層次維度

多數維度包含不止一個自然層次胞谭，如日期維度可以從天的層次到周到月到年的層次。所以在有些情況下男杈，在同一維度中存在不同的層次丈屹。

維度表空值屬性

當給定維度行沒有被全部填充時，或者當存在屬性沒有被應用到所有維度行時伶棒，將產生空值維度屬性旺垒。上述兩種情況，推薦采用描述性字符串代替空值肤无，如使用 unknown 或 not applicable 替換空值先蒋。

日歷日期維度

在日期維度表中，主鍵的設置不要使用順序生成的id來表示宛渐，可以使用更有意義的數據表示竞漾，比如將年月日合并起來表示，即YYYYMMDD窥翩，或者更加詳細的精度业岁。

2. 維度建模三種模式

1. 星型模式

星形模式(Star Schema)是最常用的維度建模方式。星型模式是以事實表為中心寇蚊，所有的維度表直接連接在事實表上笔时，像星星一樣。星形模式的維度建模由一個事實表和一組維表成仗岸，且具有以下特點：a. 維表只和事實表關聯允耿，維表之間沒有關聯；b. 每個維表主鍵為單列扒怖，且該主鍵放置在事實表中较锡，作為兩邊連接的外鍵；c. 以事實表為核心盗痒，維表圍繞核心呈星形分布念链；

2. 雪花模式

雪花模式(Snowflake Schema)是對星形模式的擴展。雪花模式的維度表可以擁有其他維度表的积糯，雖然這種模型相比星型更規(guī)范一些，但是由于這種模型不太容易理解谦纱，維護成本比較高看成，而且性能方面需要關聯多層維表，性能也比星型模型要低跨嘉。所以一般不是很常用

雪花模式

3．星座模式

星座模式是星型模式延伸而來川慌，星型模式是基于一張事實表的，而星座模式是基于多張事實表的，而且共享維度信息梦重。前面介紹的兩種維度建模方法都是多維表對應單事實表兑燥，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到琴拧。在業(yè)務發(fā)展后期降瞳，絕大部分維度建模都采用的是星座模式。

星座模型

3. 維度建模過程

我們知道維度建模的表類型有事實表蚓胸，維度表挣饥；模式有星形模型，雪花模型沛膳，星座模型這些概念了扔枫，但是實際業(yè)務中，給了我們一堆數據锹安，我們怎么拿這些數據進行數倉建設呢短荐，數倉工具箱作者根據自身60多年的實際業(yè)務經驗，給我們總結了如下四步叹哭，請務必記兹趟巍！

數倉工具箱中的維度建模四步走：

維度建模四步走

請牢記以上四步话速，不管什么業(yè)務讶踪，就按照這個步驟來，順序不要搞亂泊交，因為這四步是環(huán)環(huán)相扣乳讥，步步相連。下面詳細拆解下每個步驟怎么做

1廓俭、選擇業(yè)務過程

維度建模是緊貼業(yè)務的云石，所以必須以業(yè)務為根基進行建模，那么選擇業(yè)務過程研乒，顧名思義就是在整個業(yè)務流程中選取我們需要建模的業(yè)務汹忠，根據運營提供的需求及日后的易擴展性等進行選擇業(yè)務。比如商城雹熬，整個商城流程分為商家端宽菜，用戶端，平臺端竿报，運營需求是總訂單量铅乡，訂單人數，及用戶的購買情況等烈菌，我們選擇業(yè)務過程就選擇用戶端的數據阵幸，商家及平臺端暫不考慮花履。業(yè)務選擇非常重要，因為后面所有的步驟都是基于此業(yè)務數據展開的挚赊。

2诡壁、聲明粒度

先舉個例子：對于用戶來說，一個用戶有一個身份證號荠割，一個戶籍地址妹卿，多個手機號，多張銀行卡涨共，那么與用戶粒度相同的粒度屬性有身份證粒度纽帖，戶籍地址粒度，比用戶粒度更細的粒度有手機號粒度举反，銀行卡粒度懊直，存在一對一的關系就是相同粒度。為什么要提相同粒度呢火鼻，因為維度建模中要求我們室囊，在同一事實表中，必須具有相同的粒度魁索，同一事實表中不要混用多種不同的粒度融撞，不同的粒度數據建立不同的事實表。并且從給定的業(yè)務過程獲取數據時粗蔚，強烈建議從關注原子粒度開始設計尝偎，也就是從最細粒度開始，因為原子粒度能夠承受無法預期的用戶查詢鹏控。但是上卷匯總粒度對查詢性能的提升很重要的致扯，所以對于有明確需求的數據，我們建立針對需求的上卷匯總粒度当辐，對需求不明朗的數據我們建立原子粒度抖僵。

3、確認維度

維度表是作為業(yè)務分析的入口和描述性標識缘揪，所以也被稱為數據倉庫的“靈魂”耍群。在一堆的數據中怎么確認哪些是維度屬性呢，如果該列是對具體值的描述找筝，是一個文本或常量蹈垢，某一約束和行標識的參與者，此時該屬性往往是維度屬性袖裕，數倉工具箱中告訴我們牢牢掌握事實表的粒度曹抬，就能將所有可能存在的維度區(qū)分開，并且要確保維度表中不能出現重復數據陆赋，應使維度主鍵唯一

4沐祷、確認事實

事實表是用來度量的，基本上都以數量值表示攒岛，事實表中的每行對應一個度量赖临，每行中的數據是一個特定級別的細節(jié)數據，稱為粒度灾锯。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度兢榨。這樣能確保不會出現重復計算度量的問題。有時候往往不能確定該列數據是事實屬性還是維度屬性顺饮。記住最實用的事實就是數值類型和可加類事實吵聪。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實兼雄。

三吟逝、離線數倉建設實戰(zhàn)

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

1. 業(yè)務介紹

需要針對不同需求的用戶開發(fā)不同的產品块攒，所以公司內部有很多條業(yè)務線，但是對于數據部門來說佃乘，所有業(yè)務線的數據都是數據源囱井。對數據的劃分不只是根據業(yè)務進行，而是結合數據的屬性趣避。

2. 早期規(guī)劃

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

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

例如權限問題，公司對數據管理比較嚴格敛苇，不同的數據開發(fā)組沒有權限共享數據妆绞，需要其他業(yè)務線的數據權限需要上報審批，比較耽誤時間枫攀；

還有重復開發(fā)問題括饶，不同業(yè)務線會出現相同的報表需求，如果每個業(yè)務方都開發(fā)各自的報表来涨，太浪費資源图焰。

所以對于數據開發(fā)而言，需要對各個業(yè)務線的數據進行統(tǒng)一管理蹦掐，所以就有了數據中臺的出現技羔。

3. 數據中臺

我認為數據中臺是根據每個公司具體的業(yè)務需求而搭建的僵闯，不同的業(yè)務，對中臺的理解有所不同藤滥。

公司內部開發(fā)的敏捷數據中臺鳖粟，主要從數據技術和計算能力的復用，到數據資產和數據服務的復用拙绊，數據中臺以更大價值帶寬萍聊，快準精讓數據直接賦能業(yè)務瑞侮。提供一個統(tǒng)一化的管理娜睛，打破數據孤島苞轿，追溯數據血緣，實現自助化及高復用度金句。

如下所示：

數據中臺

以上解釋比較抽象檩赢，我們以實際項目開發(fā)來看下數據中臺的便利性。

比如我們之前做報表開發(fā)流程趴梢，首先是要數據采集漠畜，不同的數據源通過sqoop等工具采集到大數據平臺，然后進行數倉搭建坞靶，最后產出報表數據憔狞，放到可視化系統(tǒng)展示，最終把整個流程寫成腳本放到調度平臺進行自動化執(zhí)行彰阴。

而有了數據中臺之后就不需要那么繁瑣瘾敢，直接進行數倉搭建，產生報表即可尿这，無需將精力過多放在數據源簇抵、可視化展示及調度。并且可以直觀的查看數據血緣關系射众，計算表之間血緣碟摆。像下面圖中，表之間的依賴關系很明確：

數據中臺

另一點叨橱，數據中臺的異構數據系統(tǒng)可以非常簡單的進行關聯查詢典蜕，比如hive的表關聯mysql的表÷尴矗可透明屏蔽異構數據系統(tǒng)異構交互方式愉舔，輕松實現跨異構數據系統(tǒng)透明混算。

異構數據系統(tǒng)原理是數據中臺提供虛擬表到物理表之間的映射,終端用戶無需關心數據的物理存放位置和底層數據源的特性伙菜，可直接操作數據轩缤，體驗類似操作一個虛擬數據庫。

數據中臺額外集成可視化展示，提供一站式數據可視化解決方案火的，支持JDBC數據源和CSV文件上傳壶愤，支持基于數據模型拖拽智能生成可視化組件，大屏展示自適應不同大小屏幕馏鹤。

調度系統(tǒng)是公司內部自寫集成到數據中臺的公你，在編寫完sql語句之后可以直接進行調度。

4. 數倉建設

到這才真正到數倉建設假瞬，為什么前面我要占那么大篇幅去介紹公司業(yè)務及所使用的數據中臺系統(tǒng)，因為下面的數倉建設是根據公司的業(yè)務發(fā)展及現有的數據中臺進行迂尝，數倉的建設離不開公司的業(yè)務脱茉。

智能數倉規(guī)劃

數倉建設核心思想：從設計、開發(fā)垄开、部署和使用層面琴许，避免重復建設和指標冗余建設，從而保障數據口徑的規(guī)范和統(tǒng)一溉躲，最終實現數據資產全鏈路關聯榜田、提供標準數據輸出以及建立統(tǒng)一的數據公共層。有了核心思想锻梳，那怎么開始數倉建設箭券，有句話說數倉建設者即是技術專家，也是大半個業(yè)務專家疑枯，所以采用的方式就是需求推動數據建設辩块，并且因為數據中臺，所以各業(yè)務知識體系比較集中荆永，各業(yè)務數據不再分散废亭，加快了數倉建設速度。

數倉建設主要從兩個方面進行具钥，模型和規(guī)范豆村，所有業(yè)務進行統(tǒng)一化

模型

所有業(yè)務采用統(tǒng)一的模型體系，從而降低研發(fā)成本骂删，增強指標復用掌动，并且能保證數據口徑的統(tǒng)一

模型分層

結合公司業(yè)務，后期新增需求較多桃漾，所以分層不宜過多坏匪，并且需要清晰明確各層職責，要保證數據層的穩(wěn)定又要屏蔽對下游影響撬统，所以采用如下分層結構：

數據分層架構

數據流向

遵循模型開發(fā)時分層結構适滓，數據從 ods -> dw -> dm ->app 這樣正向流動，可以防止因數據引用不規(guī)范而造成數據鏈路混亂及SLA時效難保障等問題恋追，同時保證血緣關系簡潔化凭迹，能夠輕易追蹤數據流向罚屋。在開發(fā)時應避免以下情況出現：

數據引用鏈路不正確，如 ods -> dm ->app 嗅绸，出現這種情況說明明細層沒有完全覆蓋數據脾猛；如 ods -> dw -> app ，說明輕度匯總層主題劃分未覆蓋全 鱼鸠。減少跨層引用猛拴，才能提高中間表的復用度。理想的數倉模型設計應當具備：數據模型可復?蚀狰，完善且規(guī)范愉昆。

盡量避免一層的表生成當前層的表，如dw層表生成dw層表麻蹋，這樣會影響ETL效率跛溉。

禁止出現反向依賴，如dw表依賴于dm表扮授。

規(guī)范

表命名規(guī)范

對于ods芳室、dm、app層表名：類型_主題_表含義刹勃，如：dm_xxsh_user

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

字段命名規(guī)范

構建詞根荔仁，詞根是維度和指標管理的基礎抖格，劃分為普通詞根與專有詞根

普通詞根：描述事物的最小單元體，如：sex-性別咕晋。

專有詞根：具備行業(yè)專屬或公司內部規(guī)定的描述體雹拄，如：xxsh-公司內部對某個產品的稱呼。

腳本命名規(guī)范

腳本名稱：腳本類型.腳本功用.[庫名].腳本名稱掌呜，如 hive.hive.dm.dm_xxsh_users

腳本類型主要分為以下三類：

常規(guī)Hive sql：hive

自定義shell腳本：sh

自定義Python腳本：python

腳本內容規(guī)范

#變量的定義要符合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代碼

'

''

5. 數據層具體實現

使用四張圖說明每層的具體實現

數據源層ODS

數據源層

數據源層主要將各個業(yè)務數據導入到大數據平臺模暗，作為業(yè)務數據的快照存儲禁悠。

數據明細層DW

數據明細層

事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節(jié)數據兑宇，稱為粒度碍侦。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重復計算度量的問題。

維度表一般都是單一主鍵瓷产，少數是聯合主鍵站玄，注意維度表不要出現重復數據，否則和事實表關聯會出現數據發(fā)散問題濒旦。

有時候往往不能確定該列數據是事實屬性還是維度屬性株旷。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量尔邓，這種情況下該列往往是事實晾剖；如果該列是對具體值的描述，是一個文本或常量梯嗽，某一約束和行標識的參與者钞瀑，此時該屬性往往是維度屬性。但是還是要結合業(yè)務進行最終判斷是維度還是事實慷荔。

數據輕度匯總層DM

數據輕度匯總層

此層命名為輕匯總層，就代表這一層已經開始對數據進行匯總缠俺，但是不是完全匯總显晶，只是對相同粒度的數據進行關聯匯總，不同粒度但是有關系的數據也可進行匯總壹士，此時需要將粒度通過聚合等操作進行統(tǒng)一磷雇。

數據應用層APP

數據應用層

數據應用層的表就是提供給用戶使用的，數倉建設到此就接近尾聲了躏救，接下來就根據不同的需求進行不同的取數唯笙，如直接進行報表展示，或提供給數據分析的同事所需的數據盒使，或其他的業(yè)務支撐崩掘。

6. 總結

一張圖總結下數據倉庫的構建整體流程：

數據中臺

7. 實際生產中注意事項

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

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

請勿操作自己管理及授權表之外的其它庫表挽放；

未經授權，請勿操作生產環(huán)境中其他人的腳本及文件蔓纠；

在修改生產環(huán)境腳本前辑畦，請務必自行備份到本地；

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

生產環(huán)境中表名及字段等所有命名請遵循命名規(guī)則纯出。

四、實時計算

實時計算一般都是針對海量數據進行的，并且要求為秒級潦刃。由于大數據興起之初侮措，Hadoop并沒有給出實時計算解決方案，隨后Storm乖杠，SparkStreaming分扎，Flink等實時計算框架應運而生，而Kafka胧洒，ES的興起使得實時計算領域的技術越來越完善畏吓，而隨著物聯網，機器學習等技術的推廣卫漫，實時流式計算將在這些領域得到充分的應用菲饼。

實時計算的三個特征：

無限數據：無限數據指的是一種不斷增長的，基本上無限的數據集列赎。這些通常被稱為“流數據”宏悦，而與之相對的是有限的數據集。

無界數據處理：一種持續(xù)的數據處理模式,能夠通過處理引擎重復的去處理上面的無限數據包吝，是能夠突破有限數據處理引擎的瓶頸的饼煞。

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

現在大數據應用比較火爆的領域，比如推薦系統(tǒng)在實踐之初受技術所限嚷狞，可能要一分鐘块促，一小時，甚至更久對用戶進行推薦床未，這遠遠不能滿足需要竭翠，我們需要更快的完成對數據的處理，而不是進行離線的批處理薇搁。

1. 實時計算應用場景

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

1. 實時智能推薦

智能推薦會根據用戶歷史的購買或瀏覽行為只酥，通過推薦算法訓練模型褥实，預測用戶未來可能會購買的物品或喜愛的資訊。對個人來說裂允，推薦系統(tǒng)起著信息過濾的作用损离，對Web/App服務端來說，推薦系統(tǒng)起著滿足用戶個性化需求绝编，提升用戶滿意度的作用僻澎。推薦系統(tǒng)本身也在飛速發(fā)展貌踏，除了算法越來越完善，對時延的要求也越來越苛刻和實時化窟勃。利用Flink流計算幫助用戶構建更加實時的智能推薦系統(tǒng)祖乳，對用戶行為指標進行實時計算，對模型進行實時更新秉氧，對用戶指標進行實時預測眷昆，并將預測的信息推送給Web/App端，幫助用戶獲取想要的商品信息汁咏，另一方面也幫助企業(yè)提升銷售額亚斋，創(chuàng)造更大的商業(yè)價值。

2. 實時欺詐檢測

在金融領域的業(yè)務中攘滩，常常出現各種類型的欺詐行為帅刊，例如信用卡欺詐，信貸申請欺詐等漂问，而如何保證用戶和公司的資金安全赖瞒，是近年來許多金融公司及銀行共同面對的挑戰(zhàn)。隨著不法分子欺詐手段的不斷升級蚤假，傳統(tǒng)的反欺詐手段已經不足以解決目前所面臨的問題栏饮。以往可能需要幾個小時才能通過交易數據計算出用戶的行為指標，然后通過規(guī)則判別出具有欺詐行為嫌疑的用戶勤哗，再進行案件調查處理，在這種情況下資金可能早已被不法分子轉移掩驱，從而給企業(yè)和用戶造成大量的經濟損失芒划。而運用Flink流式計算技術能夠在毫秒內就完成對欺詐行為判斷指標的計算，然后實時對交易流水進行實時攔截欧穴，避免因為處理不及時而導致的經濟損失民逼。

3. 輿情分析

有的客戶需要做輿情分析，要求所有數據存放若干年涮帘，輿情數據每日數據量可能超百萬拼苍，年數據量可達到幾十億的數據。而且爬蟲爬過來的數據是輿情调缨，通過大數據技術進行分詞之后得到的可能是大段的網友評論疮鲫，客戶往往要求對輿情進行查詢，做全文本搜索弦叶，并要求響應時間控制在秒級俊犯。爬蟲將數據爬到大數據平臺的Kafka里，在里面做Flink流處理伤哺，去重去噪做語音分析燕侠，寫到ElasticSearch里者祖。大數據的一個特點是多數據源，大數據平臺能根據不同的場景選擇不同的數據源绢彤。

4. 復雜事件處理

對于復雜事件處理七问，比較常見的集中于工業(yè)領域，例如對車載傳感器茫舶，機械設備等實時故障檢測械巡，這些業(yè)務類型通常數據量都非常大，且對數據處理的時效性要求非常高奇适。通過利用Flink提供的CEP進行時間模式的抽取坟比，同時應用Flink的Sql進行事件數據的轉換，在流式系統(tǒng)中構建實施規(guī)則引擎嚷往，一旦事件觸發(fā)報警規(guī)則葛账，便立即將告警結果通知至下游通知系統(tǒng)，從而實現對設備故障快速預警檢測皮仁，車輛狀態(tài)監(jiān)控等目的籍琳。

5. 實時機器學習

實時機器學習是一個更寬泛的概念，傳統(tǒng)靜態(tài)的機器學習主要側重于靜態(tài)的模型和歷史數據進行訓練并提供預測贷祈。很多時候用戶的短期行為趋急，對模型有修正作用，或者說是對業(yè)務判斷有預測作用势誊。對系統(tǒng)來說呜达，需要采集用戶最近的行為并進行特征工程，然后給到實時機器學習系統(tǒng)進行機器學習粟耻。如果動態(tài)地實施新規(guī)則查近，或是推出新廣告，就會有很大的參考價值挤忙。

2. 實時計算總覽

我們先來看一張大數據平臺的實時架構圖：

數據同步：

在上面這張架構圖中霜威，數據從Web平臺中產生乙漓，通過數據同步系統(tǒng)導入到大數據平臺蚊荣，由于數據源不同砚婆，這里的數據同步系統(tǒng)實際上是多個相關系統(tǒng)的組合还蹲。數據庫同步通常用 Sqoop粤策，日志同步可以選擇 Flume等种柑，不同的數據源產生的數據質量可能差別很大疼进，數據庫中的格式化數據直接導入大數據系統(tǒng)即可诅需，而日志和爬蟲產生的數據就需要進行大量的清洗淀零、轉化處理才能有效使用胎署。

數據存儲：

該層對原始數據、清洗關聯后的明細數據進行存儲窑滞，基于統(tǒng)一的實時數據模型分層理念琼牧，將不同應用場景的數據分別存儲在 Kafka恢筝、HDFS、Kudu巨坊、 Clickhouse撬槽、Hbase等存儲中。

數據計算：

計算層主要使用 Flink趾撵、Spark侄柔、Presto 以及 ClickHouse 自帶的計算能力等四種計算引擎，Flink 計算引擎主要用于實時數據同步占调、 流式 ETL暂题、關鍵系統(tǒng)秒級實時指標計算場景，Spark SQL 主要用于復雜多維分析的準實時指標計算需求場景究珊，Presto 和 ClickHouse 主要滿足多維自助分析薪者、對查詢響應時間要求不太高的場景。

實時應用：

以統(tǒng)一查詢服務對各個業(yè)務線數據場景進行支持剿涮，業(yè)務主要包括實時大屏言津、實時數據產品、實時 OLAP取试、實時特征等悬槽。

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

1. 元數據及指標管理：主要對實時的Kafka表、Kudu表瞬浓、Clickhouse表初婆、Hive表等進行統(tǒng)一管理，以數倉模型中表的命名方式規(guī)范表的命名猿棉，明確每張表的字段含義磅叛、使用方，指標管理則是盡量通過指標管理系統(tǒng)將所有的實時指標統(tǒng)一管理起來铺根，明確計算口徑宪躯，提供給不同的業(yè)務方使用乔宿；

2. 數據質量及血緣分析：數據質量分為平臺監(jiān)控和數據監(jiān)控兩個部分位迂，血緣分析則主要是對實時數據依賴關系、實時任務的依賴關系進行分析详瑞。

以上架構只是大數據平臺通用的數據模型掂林，如果要具體的建設，需要考慮以下情況坝橡，業(yè)務需求需要實時還是準實時即可泻帮，數據時效性是秒級還是分鐘級等。

在調度開銷方面计寇，準實時數據是批處理過程锣杂，因此仍然需要調度系統(tǒng)支持脂倦，調度頻率較高，而實時數據卻沒有調度開銷元莫；

在業(yè)務靈活性方面赖阻，因為準實時數據是基于 ETL 或 OLAP 引擎實現，靈活性優(yōu)于基于流計算的方式踱蠢；

在對數據晚到的容忍度方面火欧，因為準實時數據可以基于一個周期內的數據進行全量計算，因此對于數據晚到的容忍度也是比較高的茎截，而實時數據使用的是增量計算苇侵，對于數據晚到的容忍度更低一些；

在適用場景方面企锌，準實時數據主要用于有實時性要求但不太高榆浓、涉及多表關聯和業(yè)務變更頻繁的場景，如交易類型的實時分析霎俩，實時數據則更適用于實時性要求高哀军、數據量大的場景，如實時特征打却、流量類型實時分析等場景杉适。

3. 實時架構

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

于是隨之誕生了大數據實時數倉捌肴，并且衍生出了兩種技術架構Lambda和Kappa蹬叭。

1. Lambda架構

先來看下Lambda架構圖：

Lambda架構圖

數據從底層的數據源開始，經過Kafka状知、Flume等數據組件進行收集秽五，然后分成兩條線進行計算：

一條線是進入流式計算平臺（例如 Storm、Flink或者SparkStreaming）饥悴，去計算實時的一些指標坦喘；

另一條線進入批量數據處理離線計算平臺（例如Mapreduce、Hive西设，Spark SQL）瓣铣，去計算T+1的相關業(yè)務指標，這些指標需要隔日才能看見贷揽。

為什么Lambda架構要分成兩條線計算棠笑？

假如整個系統(tǒng)只有一個批處理層，會導致用戶必須等待很久才能獲取計算結果禽绪，一般有幾個小時的延遲蓖救。電商數據分析部門只能查看前一天的統(tǒng)計分析結果洪规，無法獲取當前的結果，這對于實時決策來說有一個巨大的時間鴻溝循捺，很可能導致管理者錯過最佳決策時機淹冰。

Lambda架構屬于較早的一種架構方式，早期的流處理不如現在這樣成熟巨柒，在準確性樱拴、擴展性和容錯性上，流處理層無法直接取代批處理層洋满，只能給用戶提供一個近似結果晶乔，還不能為用戶提供一個一致準確的結果。因此Lambda架構中牺勾，出現了批處理和流處理并存的現象正罢。

在 Lambda 架構中，每層都有自己所肩負的任務驻民。

1. 批處理層存儲管理主數據集（不可變的數據集）和預先批處理計算好的視圖：

批處理層使用可處理大量數據的分布式處理系統(tǒng)預先計算結果翻具。它通過處理所有的已有歷史數據來實現數據的準確性。這意味著它是基于完整的數據集來重新計算的回还，能夠修復任何錯誤裆泳，然后更新現有的數據視圖。輸出通常存儲在只讀數據庫中柠硕，更新則完全取代現有的預先計算好的視圖工禾。

2. 流處理層會實時處理新來的大數據：

流處理層通過提供最新數據的實時視圖來最小化延遲。流處理層所生成的數據視圖可能不如批處理層最終生成的視圖那樣準確或完整蝗柔，但它們幾乎在收到數據后立即可用闻葵。而當同樣的數據在批處理層處理完成后，在速度層的數據就可以被替代掉了癣丧。

那Lambda架構有沒有缺點呢槽畔？

Lambda架構經歷多年的發(fā)展，其優(yōu)點是穩(wěn)定胁编，對于實時計算部分的計算成本可控厢钧，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開掏呼，這種架構支撐了數據行業(yè)的早期發(fā)展坏快，但是它也有一些致命缺點铅檩，并在大數據3.0時代越來越不適應數據分析業(yè)務的需求憎夷。缺點如下：

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

批量計算在計算窗口內無法完成：在IOT時代拾给，數據量級越來越大祥得，經常發(fā)現夜間只有4、5個小時的時間窗口蒋得，已經無法完成白天20多個小時累計的數據级及，保證早上上班前準時出數據已成為每個大數據團隊頭疼的問題。

數據源變化都要重新開發(fā)额衙，開發(fā)周期長：每次數據源的格式變化饮焦，業(yè)務的邏輯變化都需要針對ETL和Streaming做開發(fā)修改，整體開發(fā)周期很長窍侧，業(yè)務反應不夠迅速县踢。

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

那我們能不能改進其中某一層的架構斧账，讓它具有另外一層架構的特性呢谴返？

例如，改進批處理層的系統(tǒng)讓它具有更低的延時性咧织，又或者是改進速度層的系統(tǒng)嗓袱，讓它產生的數據視圖更具準確性和更加接近歷史數據呢？

另外一種在大規(guī)模數據處理中常用的架構——Kappa 架構习绢，便是在這樣的思考下誕生的索抓。

2. Kappa架構

Kafka的創(chuàng)始人Jay Kreps認為在很多場景下，維護一套Lambda架構的大數據處理平臺耗時耗力毯炮，于是提出在某些場景下逼肯，沒有必要維護一個批處理層，直接使用一個流處理層即可滿足需求桃煎，即下圖所示的Kappa架構：

Kappa架構

這種架構只關注流式計算篮幢，數據以流的方式被采集過來，實時計算引擎將計算結果放入數據服務層以供查詢为迈。可以認為Kappa架構是Lambda架構的一個簡化版本三椿，只是去除掉了Lambda架構中的離線批處理部分；

Kappa架構的興起主要有兩個原因：

Kafka不僅起到消息隊列的作用葫辐，也可以保存更長時間的歷史數據搜锰，以替代Lambda架構中批處理層數據倉庫部分。流處理引擎以一個更早的時間作為起點開始消費耿战，起到了批處理的作用蛋叼。

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

Kappa架構相對更簡單，實時性更好狈涮，所需的計算資源遠小于Lambda架構狐胎，隨著實時處理的需求在不斷增長，更多的企業(yè)開始使用Kappa架構歌馍。但這不意味著kappa架構能夠取代Lambda架構握巢。

Lambda和kappa架構都有各自的適用領域；例如流處理與批處理分析流程比較統(tǒng)一松却，且允許一定的容錯暴浦，用Kappa比較合適，少量關鍵指標（例如交易金額晓锻、業(yè)績統(tǒng)計等）使用Lambda架構進行批量計算肉渴，增加一次校對過程。

還有一些比較復雜的場景带射，批處理與流處理產生不同的結果（使用不同的機器學習模型同规，專家系統(tǒng)，或者實時計算難以處理的復雜計算）窟社，可能更適合Lambda架構券勺。