鑽石舞台

文檔大綱：

我們在談數倉之前，為了讓大家有直觀的認識，先來談數倉架構，「架構」是什麼？這個問題從來就沒有一個準確的答案。這裡我們引用一段話：在軟件行業，一種被普遍接受的架構定義是指系統的一個或多個結構。結構中包括軟件的構建（構建是指軟件的設計與實現），構建的外部可以看到屬性以及它們之間的相互關係。

這裡參考此定義，把數據倉庫架構理解成構成數據倉庫的組件及其之間的關係，畫出下面的數倉架構圖：

上圖中顯示的整個數據倉庫環境包括操作型系統和數據倉庫系統兩大部分。操作型系統的數據由各種形式的業務數據組成，這些數據經過抽取、轉換和裝載（ETL）過程進入數據倉庫系統。

任何事物都是隨着時間的演進變得越來越完善，當然也是越來越複雜，數倉也不例外。在數據倉庫技術演化過程中，產生了幾種主要的架構方法，包括數據集市架構、Inmon企業信息工廠架構、Kimball數據倉庫架構、混合型數據倉庫架構。這幾種架構我們後面再講，接下來看下數倉的基本概念。

英文名稱為Data Warehouse，可簡寫為DW或DWH。數據倉庫的目的是構建面向分析的集成化數據環境，為企業提供決策支持（Decision Support）。它出於分析性報告和決策支持目的而創建。

數據倉庫本身並不「生產」任何數據，同時自身也不需要「消費」任何的數據，數據來源於外部，並且開放給外部應用，這也是為什麼叫「倉庫」，而不叫「工廠」的原因。

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

傳統數據庫中，最大的特點是面向應用進行數據的組織，各個業務系統可能是相互分離的。而數據倉庫則是面向主題的。主題是一個抽象的概念，是較高層次上企業信息系統中的數據綜合、歸類並進行分析利用的抽象。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析對象。

通過對分散、獨立、異構的數據庫數據進行抽取、清理、轉換和匯總便得到了數據倉庫的數據，這樣保證了數據倉庫內的數據關於整個企業的一致性。

數據倉庫中的綜合數據不能從原有的數據庫系統直接得到。因此在數據進入數據倉庫之前，必然要經過統一與綜合，這一步是數據倉庫建設中最關鍵、最複雜的一步，所要完成的工作有：

下圖說明一個保險公司綜合數據的簡單處理過程，其中數據倉庫中與「保險」 主題有關的數據來自於多個不同的操作型系統。這些系統內部數據的命名可能不同，數據格式也可能不同。把不同來源的數據存儲到數據倉庫之前，需要去除這些不一致。

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

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

數據倉庫包含各種粒度的歷史數據。數據倉庫中的數據可能與某個特定日期、星期、月份、季度或者年份有關。數據倉庫的目的是通過分析企業過去一段時間業務的經營狀況，挖掘其中隱藏的模式。雖然數據倉庫的用戶不能修改數據，但並不是說數據倉庫的數據是永遠不變的。分析的結果只能反映過去的情況，當業務變化後，挖掘出的模式會失去時效性。因此數據倉庫的數據需要更新，以適應決策的需要。從這個角度講，數據倉庫建設是一個項目，更是一個過程。數據倉庫的數據隨時間的變化表現在以下幾個方面：

（1） 數據倉庫的數據時限一般要遠遠長於操作型數據的數據時限。（2） 操作型系統存儲的是當前數據，而數據倉庫中的數據是歷史數據。（3） 數據倉庫中的數據是按照時間順序追加的，它們都帶有時間屬性。

先來看下數據倉庫的數據從哪裡來，最終要到哪裡去？

通常數據倉庫的數據來自各個業務應用系統。業務系統中的數據形式多種多樣，可能是 Oracle、MySQL、SQL Server等關係數據庫里的結構化數據，可能是文本、CSV等平面文件或Word、Excel文檔中的數據，還可能是HTML、XML等自描述的半結構化數據。這些業務數據經過一系列的數據抽取、轉換、清洗，最終以一種統一的格式裝載進數據倉庫。數據倉庫里的數據作為分析用的數據源，提供給後面的即席查詢、 分析系統、數據集市、報表系統、數據挖掘系統等。

這時我們就想了，為什麼不能把業務系統的數據直接拿來供即席查詢、分析系統、報表系統等使用呢，為什麼要經過數據倉庫這一步？實際上在數倉出現之前，確實是這麼做的，但是有很多數據分析的先驅者當時已經發現，簡單的「直接訪問」方式很難良好工作，這樣做的失敗案例數不勝數。下面列舉一些直接訪問業務系統無法工作的原因：

儘管需要增加軟硬件的投入，但建立獨立數據倉庫與直接訪問業務數據相比，無論是成本還是帶來的好處，這樣做都是值得的。隨着處理器和存儲成本的逐年降低，數據倉庫方案的優勢更加明顯，在經濟上也更具可行性。

數據庫與數據倉庫的區別實際講的是 OLTP 與 OLAP 的區別。

操作型處理，叫聯機事務處理 OLTP（On-Line Transaction Processing，），也可以稱面向交易的處理系統，它是針對具體業務在數據庫聯機的日常操作，通常對少數記錄進行查詢、修改。用戶較為關心操作的響應時間、數據的安全性、完整性和並發支持的用戶數等問題。傳統的數據庫系統作為數據管理的主要手段，主要用於操作型處理，像Mysql，Oracle等關係型數據庫一般屬於OLTP。

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

首先要明白，數據倉庫的出現，並不是要取代數據庫。數據庫是面向事務的設計，數據倉庫是面向主題設計的。數據庫一般存儲業務數據，數據倉庫存儲的一般是歷史數據。

數據庫設計是儘量避免冗餘，一般針對某一業務應用進行設計，比如一張簡單的User表，記錄用戶名、密碼等簡單數據即可，符合業務應用，但是不符合分析。數據倉庫在設計是有意引入冗餘，依照分析需求，分析維度、分析指標進行設計。

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

以銀行業務為例。數據庫是事務系統的數據平台，客戶在銀行做的每筆交易都會寫入數據庫，被記錄下來，這裡，可以簡單地理解為用數據庫記賬。數據倉庫是分析系統的數據平台，它從事務系統獲取數據，並做匯總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款餘額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。

顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求數據庫只能存儲很短一段時間的數據。而分析系統是事後的，它要提供關注時間段內所有的有效數據。這些數據是海量的，匯總計算起來也要慢一些，但是，只要能夠提供有效的分析數據就達到目的了。

數據倉庫，是在數據庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的「大型數據庫」。

按照數據流入流出的過程，數據倉庫架構可分為：源數據、數據倉庫、數據應用

數據倉庫的數據來源於不同的源數據，並提供多樣的數據應用，數據自下而上流入數據倉庫後向上層開放應用，而數據倉庫只是中間集成化數據管理的一個平台。

源數據：此層數據無任何更改，直接沿用外圍系統數據結構和數據，不對外開放；為臨時存儲層，是接口數據的臨時存儲區域，為後一步的數據處理做準備。

數據倉庫：也稱為細節層，DW層的數據應該是一致的、準確的、乾淨的數據，即對源系統數據進行了清洗（去除了雜質）後的數據。

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

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

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

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

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

獨立數據集市集中於部門所關心的單一主題域，數據以部門為基礎部署，無須考慮企業級別的信息共享與集成。例如，製造部門、人力資源部門和其他部門都各自有他們自己的數據集市。

優點：因為一個部門的業務相對於整個企業要簡單，數據量也小得多，所以部門的獨立數據集市具有周期短、見效快的特點。

缺點：

從屬數據集市的數據來源於數據倉庫。數據倉庫里的數據經過整合、重構、匯總後傳遞給從屬數據集市。

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

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

企業級數據倉庫：是該架構中的核心組件。正如Inmon數據倉庫所定義的，企業級數據倉庫是一個細節數據的集成資源庫。其中的數據以最低粒度級別被捕獲，存儲在滿足三範式設計的關係數據庫中。

部門級數據集市：是面向主題數據的部門級視圖，數據從企業級數據倉庫獲取。數據在進入部門數據集市時可能進行聚合。數據集市使用多維模型設計，用於數據分析。重要的一點是，所有的報表工具、BI工具或其他數據分析應用都從數據集市查詢數據，而不是直接查詢企業級數據倉庫。

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

Kimball的數據倉庫包含高粒度的企業數據，使用多維模型設計，這也意味着數據倉庫由星型模式的維度表和事實表構成。分析系統或報表工具可以直接訪問多維數據倉庫里的數據。

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

所謂的混合型結構，指的是在一個數據倉庫環境中，聯合使用Inmon和Kimball兩種架構。

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

使用這種架構的好處是：既可以利用規範化設計消除數據冗餘，保證數據的粒度足夠細；又可以利用多維結構更靈活地在企業級實現報表和分析。

元數據（Meta Date），主要記錄數據倉庫中模型的定義、各層級間的映射關係、監控數據倉庫的數據狀態及ETL的任務運行狀態。一般會通過元數據資料庫（Metadata Repository）來統一地存儲和管理元數據，其主要目的是使數據倉庫的設計、部署、操作和管理能達成協同和一致。

元數據是數據倉庫管理系統的重要組成部分，元數據管理是企業級數據倉庫中的關鍵組件，貫穿數據倉庫構建的整個過程，直接影響着數據倉庫的構建、使用和維護。

元數據可分為技術元數據和業務元數據。技術元數據為開發和管理數據倉庫的IT 人員使用，它描述了與數據倉庫開發、管理和維護相關的數據，包括數據源信息、數據轉換描述、數據倉庫模型、數據清洗與更新規則、數據映射和訪問權限等。而業務元數據為管理層和業務分析人員服務，從業務角度描述數據，包括商務術語、數據倉庫中有什麼數據、數據的位置和數據的可用性等，幫助業務人員更好地理解數據倉庫中哪些數據是可用的以及如何使用。

由上可見，元數據不僅定義了數據倉庫中數據的模式、來源、抽取和轉換規則等，而且是整個數據倉庫系統運行的基礎，元數據把數據倉庫系統中各個鬆散的組件聯繫起來，組成了一個有機的整體。

本小節結構如下圖所示：

實體是指依附的主體，就是我們分析的一個對象，比如我們分析商品的銷售情況，如華為手機近半年的銷售量是多少，那華為手機就是一個實體；我們分析用戶的活躍度，用戶就是一個實體。當然實體也可以現實中不存在的，比如虛擬的業務對象，活動，會員等都可看做一個實體。

實體的存在是為了業務分析，作為分析的一個篩選的維度，擁有描述自己的屬性，本身具有可分析的價值。

維度就是看待問題的角度，分析業務數據，從什麼角度分析，就建立什麼樣的維度。所以維度就是要對數據進行分析時所用的一個量，比如你要分析產品銷售情況，你可以選擇按商品類別來進行分析，這就構成一個維度，把所有商品類別集合在一起，就構成了維度表。

度量是業務流程節點上的一個數值。比如銷量，價格，成本等等。

事實表中的度量可分為三類：完全可加，半可加，不可加。

粒度就是業務流程中對度量的單位，比如商品是按件記錄度量，還是按批記錄度量。

在數倉建設中，我們說這是用戶粒度的事實表，那麼表中每行數據都是一個用戶，無重複用戶；例如還有銷售粒度的表，那麼表中每行都是一條銷售記錄。

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

口徑就是取數邏輯（如何取數的），比如要取的數是10歲以下兒童中男孩的平均身高，這就是統計的口徑。

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

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

除此之外，指標本身還可以衍生、派生出更多的指標，基於這些特點，可以將指標進行分類：

業務方更關心的指標，是有實際業務含義，可以直接取數據的指標。比如店鋪近1天訂單支付金額就是一個派生指標，會被直接在產品上展示給商家看。但是這個指標卻不能直接從數倉的統一中間層里取數（因為沒有現成的事實字段，數倉提供的一般都是大寬表）。需要有一個橋樑連接數倉中間層和業務方的指標需求，於是便有了派生指標

維度：觀察各項指標的角度；修飾詞：維度的一個或某些值，比如維度性別下，男和女就是2種修飾詞。

標籤是人為設定的、根據業務場景需求，對目標對象運用一定的算法得到的高度精煉的特徵標識。可見標籤是經過人為再加工後的結果，如網紅、白富美、蘿莉。對於有歧義的標籤，我們內部可進行標籤區分，比如：蘋果，我們可以定義蘋果指的是水果，蘋果手機才指的是手機。

由現實中已經存在的屬性組成的鍵，它在業務概念中是唯一的，並具有一定的業務含義，比如商品ID，員工ID。

以數倉角度看，來自於業務系統的標識符就是自然鍵，比如業務庫中員工的編號。

保持永久性不會發生變化。有時也被叫做超自然持久鍵。比如身份證號屬於持久鍵。

自然鍵和持久鍵區別：舉個例子就明白了，比如說公司員工離職之後又重新入職，他的自然鍵也就是員工編號發生了變化，但是他的持久鍵身份證號是不變的。

就是不具有業務含義的鍵。代理鍵有許多其他的稱呼：無意義鍵、整數鍵、非自然鍵、人工鍵、合成鍵等。

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

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

那麼究竟怎麼定義退化維度呢？比如說訂單id，這種量級很大的維度，沒必要用一張維度表來進行存儲，而我們進行數據查詢或者數據過濾的時候又非常需要，所以這種就冗餘在事實表裡面，這種就叫退化維度，citycode這種我們也會冗餘在事實表裡面，但是它有對應的維度表，所以它不是退化維度。

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

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

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

在Kimball維度建模中有維度與事實，在Inmon範式建模中有實體與關係，如果我們分開兩種建模方式看這些概念比較容易理解。但是目前也出現了不少混合建模方式，兩種建模方式結合起來看，這些概念是不是容易記憶混亂，尤其事實表和實體表，它們之間到底有怎樣區別與聯繫，先看下它們各自概念：

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

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

標籤是人為設定的、根據業務場景需求，對目標對象運用一定的算法得到的高度精煉的特徵標識。可見標籤是經過人為再加工後的結果，如網紅、白富美、蘿莉。

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

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

對指標的分類：

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

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

對標籤的分類：

按照標籤的變化性分為靜態標籤和動態標籤；

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

指標最擅長的應用是監測、分析、評價和建模。標籤最擅長的應用是標註、刻畫、分類和特徵提取。特別需要指出的是，由於對結果的標註也是一種標籤，所以在自然語言處理和機器學習相關的算法應用場景下，標籤對於監督式學習有重要價值，只是單純的指標難以做到的。而指標在任務分配、績效管理等領域的作用，也是標籤無法做到的。

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

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

維度一般是一個離散的值，比如時間維度上每一個獨立的日期或地域，因此統計時，可以把維度相同記錄的聚合在一起，應用聚合函數做累加、均值、最大值、最小值等聚合計算。

指標就是被聚合的通計算，即聚合運算的結果，一般是一個連續的值。

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

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

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

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

數據倉庫的核心是展現層和提供優質的服務。ETL 及其規範、分層等所做的一切都是為了一個更清晰易用的展現層。

數倉分層的原則：

一般採用如下分層結構：

ODS 層，是最接近數據源中數據的一層，為了考慮後續可能需要追溯數據問題，因此對於這一層就不建議做過多的數據清洗工作，原封不動地接入原始數據即可，至於數據的去噪、去重、異常值處理等過程可以放在後面的 DWD 層來做。

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

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

該層一般保持和 ODS 層一樣的數據粒度，並且提供一定的數據質量保證。DWD 層要做的就是將數據清理、整合、規範化、髒數據、垃圾數據、規範不一致的、狀態定義不一致的、命名不規範的數據都會被處理。

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

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

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

直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。

在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在 DWM 層先計算出多個小的中間表，然後再拼接成一張 DWS 的寬表。由於寬和窄的界限不易界定，也可以去掉 DWM 這一層，只留 DWS 層，將所有的數據再放在 DWS 亦可。

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

按照業務劃分，如主題域流量、訂單、用戶等，生成字段比較多的寬表，用於提供後續的業務查詢，OLAP 分析，數據分發等。

一般來講，該層的數據表會相對比較少，一張表會涵蓋比較多的業務內容，由於其字段較多，因此一般也會稱該層的表為寬表。

在這裡，主要是提供給數據產品和數據分析使用的數據，一般會存放在 ES、 PostgreSql、Redis 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用。比如我們經常說的報表數據，一般就放在這裡。

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

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

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

數倉建模在哪層建設呢？我們以維度建模為例，建模是在數據源層的下一層進行建設，在上節的分層架構中，就是在DW層進行數倉建模，所以DW層是數倉建設的核心層。

那數倉建模怎麼建呢？其實數據倉庫的建模方法有很多種，每一種建模方法代表了哲學上的一個觀點，代表了一種歸納、概括世界的一種方法。常見的有 範式建模法、維度建模法、實體建模法等，每種方法從本質上將是從不同的角度看待業務中的問題。

範式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關係型數據庫的數據存儲，利用的一種技術層面上的方法。目前，我們在關係型數據庫中的建模方法，大部分採用的是三範式建模法。

範式 是符合某一種級別的關係模式的集合。構造數據庫必須遵循一定的規則，而在關係型數據庫中這種規則就是範式，這一過程也被稱為規範化。目前關係數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、Boyce-Codd範式（BCNF）、第四範式（4NF）和第五範式（5NF）。

在數據倉庫的模型設計中，一般採用第三範式。一個符合第三範式的關係必須具有以下三個條件 :

根據 Inmon 的觀點，數據倉庫模型的建設方法和業務系統的企業數據模型類似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關係型數據庫上的實例化。

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

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

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

實體建模法並不是數據倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關係組成。那麼我們在數據倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關係，以及針對這些關係的說明就是我們數據建模需要做的工作。

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

上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：「小明開車去學校上學」。以這個業務事實為例，我們可以把「小明」，「學校」看成是一個實體，「上學」描述的是一個業務過程，我們在這裡可以抽象為一個具體「事件」，而「開車去」則可以看成是事件「上學」的一個說明。

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

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

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

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

發生在現實世界中的操作型事件，其所產生的可度量數值，存儲在事實表中。從最低的粒度級別來看，事實表行對應一個度量事件，反之亦然。

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

圖中的訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄。事實表的特徵：表里沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯的外鍵，可與維度表關聯。事實表的度量通常是數值類型，且記錄數會不斷增加，表數據規模迅速增長。

明細表（寬表）：

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

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

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

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

事實表種類

事實表分為以下6類：

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

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

顧名思義，周期事實表就是每行都帶有時間值字段，代表周期，通常時間值都是標準周期，如某一天，某周，某月等。粒度是周期，而不是個體的事務，也就是說一個周期快照事實表中數據可以是多個事實，但是它們都屬於某個周期內。

周期快照事實表是單個周期內數據，而累計快照事實表是由多個周期數據組成，每行匯總了過程開始到結束之間的度量。每行數據相當於管道或工作流，有事件的起點，過程，終點，並且每個關鍵步驟都包含日期字段。如訂單數據，累計快照事實表的一行就是一個訂單，當訂單產生時插入一行，當訂單發生變化時，這行就被修改。

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

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

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

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度表行的描述環境應與事實表行完全對應。維度表通常比較寬，是扁平型非規範表，包含大量的低粒度的文本屬性。

維度表示你要對數據進行分析時所用的一個量，比如你要分析產品銷售情況， 你可以選擇按類別來進行分析，或按區域來分析。每個類別就構成一個維度。上圖中的用戶表、商家表、時間表這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的數據信息。

總的說來，在數據倉庫中不需要嚴格遵守規範化設計原則。因為數據倉庫的主導功能就是面向分析，以查詢為主，不涉及數據更新操作。事實表的設計是以能夠正確記錄歷史信息為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。

維度表謹記一條原則，包含單一主鍵列，但有時因業務複雜，也可能出現聯合主鍵，請儘量避免，如果無法避免，也要確保必須是單一的，這很重要，如果維表主鍵不是單一，和事實表關聯時會出現數據發散，導致最後結果可能出現錯誤。

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

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

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

上鑽（roll-up）：上卷是沿着維的層次向上聚集匯總數據。例如，對產品銷售數據，沿着時間維上卷，可以求出所有產品在所有地區每月（或季度或年或全部）的銷售額。

下鑽（drill-down）：下鑽是上鑽的逆操作，它是沿着維的層次向下，查看更詳細的數據。

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

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

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

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

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

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

星座模式是星型模式延伸而來，星型模式是基於一張事實表的，而星座模式是基於多張事實表的，而且共享維度信息。前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。

我們知道維度建模的表類型有事實表，維度表；模式有星形模型，雪花模型，星座模型這些概念了，但是實際業務中，給了我們一堆數據，我們怎麼拿這些數據進行數倉建設呢，數倉工具箱作者根據自身60多年的實際業務經驗，給我們總結了如下四步，請務必記住！

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

請牢記以上四步，不管什麼業務，就按照這個步驟來，順序不要搞亂，因為這四步是環環相扣，步步相連。下面詳細拆解下每個步驟怎麼做

1、選擇業務過程維度建模是緊貼業務的，所以必須以業務為根基進行建模，那麼選擇業務過程，顧名思義就是在整個業務流程中選取我們需要建模的業務，根據運營提供的需求及日後的易擴展性等進行選擇業務。比如商城，整個商城流程分為商家端，用戶端，平台端，運營需求是總訂單量，訂單人數，及用戶的購買情況等，我們選擇業務過程就選擇用戶端的數據，商家及平台端暫不考慮。業務選擇非常重要，因為後面所有的步驟都是基於此業務數據展開的。

2、聲明粒度先舉個例子：對於用戶來說，一個用戶有一個身份證號，一個戶籍地址，多個手機號，多張銀行卡，那麼與用戶粒度相同的粒度屬性有身份證粒度，戶籍地址粒度，比用戶粒度更細的粒度有手機號粒度，銀行卡粒度，存在一對一的關係就是相同粒度。為什麼要提相同粒度呢，因為維度建模中要求我們，在同一事實表中，必須具有相同的粒度，同一事實表中不要混用多種不同的粒度，不同的粒度數據建立不同的事實表。並且從給定的業務過程獲取數據時，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始，因為原子粒度能夠承受無法預期的用戶查詢。但是上卷匯總粒度對查詢性能的提升很重要的，所以對於有明確需求的數據，我們建立針對需求的上卷匯總粒度，對需求不明朗的數據我們建立原子粒度。

3、確認維度維度表是作為業務分析的入口和描述性標識，所以也被稱為數據倉庫的「靈魂」。在一堆的數據中怎麼確認哪些是維度屬性呢，如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性，數倉工具箱中告訴我們牢牢掌握事實表的粒度，就能將所有可能存在的維度區分開，並且要確保維度表中不能出現重複數據，應使維度主鍵唯一

4、確認事實事實表是用來度量的，基本上都以數量值表示，事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。有時候往往不能確定該列數據是事實屬性還是維度屬性。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值並作為計算的參與者的度量，這種情況下該列往往是事實。

技術是為業務服務的，業務是為公司創造價值的，離開業務的技術是無意義的

需要針對不同需求的用戶開發不同的產品，所以公司內部有很多條業務線，但是對於數據部門來說，所有業務線的數據都是數據源。對數據的劃分不只是根據業務進行，而是結合數據的屬性。

之前開發是不同業務線對應不同的數據團隊，每個數據團隊互不干擾，這種模式比較簡單，只針對自己的業務線進行數倉建設及報表開發即可。

但是隨着業務的發展，頻繁迭代及跨部門的垂直業務單元越來越多，業務之間的出現耦合情況，這時再採用這種煙囪式開發就出現了問題：

例如權限問題，公司對數據管理比較嚴格，不同的數據開發組沒有權限共享數據，需要其他業務線的數據權限需要上報審批，比較耽誤時間；

還有重複開發問題，不同業務線會出現相同的報表需求，如果每個業務方都開發各自的報表，太浪費資源。

所以對於數據開發而言，需要對各個業務線的數據進行統一管理，所以就有了數據中台的出現。

我認為數據中台是根據每個公司具體的業務需求而搭建的，不同的業務，對中台的理解有所不同。

公司內部開發的敏捷數據中台，主要從數據技術和計算能力的復用，到數據資產和數據服務的復用，數據中台以更大價值帶寬，快准精讓數據直接賦能業務。提供一個統一化的管理，打破數據孤島，追溯數據血緣，實現自助化及高復用度。

如下所示：

以上解釋比較抽象，我們以實際項目開發來看下數據中台的便利性。

比如我們之前做報表開發流程，首先是要數據採集，不同的數據源通過sqoop等工具採集到大數據平台，然後進行數倉搭建，最後產出報表數據，放到可視化系統展示，最終把整個流程寫成腳本放到調度平台進行自動化執行。

而有了數據中台之後就不需要那麼繁瑣，直接進行數倉搭建，產生報表即可，無需將精力過多放在數據源、可視化展示及調度。並且可以直觀的查看數據血緣關係，計算表之間血緣。像下面圖中，表之間的依賴關係很明確：

另一點，數據中台的異構數據系統可以非常簡單的進行關聯查詢，比如hive的表關聯mysql的表。可透明屏蔽異構數據系統異構交互方式，輕鬆實現跨異構數據系統透明混算。

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

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

調度系統是公司內部自寫集成到數據中台的，在編寫完sql語句之後可以直接進行調度。

到這才真正到數倉建設，為什麼前面我要占那麼大篇幅去介紹公司業務及所使用的數據中台系統，因為下面的數倉建設是根據公司的業務發展及現有的數據中台進行，數倉的建設離不開公司的業務。

數倉建設核心思想：從設計、開發、部署和使用層面，避免重複建設和指標冗餘建設，從而保障數據口徑的規範和統一，最終實現數據資產全鏈路關聯、提供標準數據輸出以及建立統一的數據公共層。有了核心思想，那怎麼開始數倉建設，有句話說數倉建設者即是技術專家，也是大半個業務專家，所以採用的方式就是需求推動數據建設，並且因為數據中台，所以各業務知識體系比較集中，各業務數據不再分散，加快了數倉建設速度。數倉建設主要從兩個方面進行，模型和規範，所有業務進行統一化

所有業務採用統一的模型體系，從而降低研發成本，增強指標復用，並且能保證數據口徑的統一

結合公司業務，後期新增需求較多，所以分層不宜過多，並且需要清晰明確各層職責，要保證數據層的穩定又要屏蔽對下游影響，所以採用如下分層結構：

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

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

數據源層主要將各個業務數據導入到大數據平台，作為業務數據的快照存儲。

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

維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重複數據，否則和事實表關聯會出現數據發散問題。

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

此層命名為輕匯總層，就代表這一層已經開始對數據進行匯總，但是不是完全匯總，只是對相同粒度的數據進行關聯匯總，不同粒度但是有關係的數據也可進行匯總，此時需要將粒度通過聚合等操作進行統一。

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

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

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

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

實時計算一般都是針對海量數據進行的，並且要求為秒級。由於大數據興起之初，Hadoop並沒有給出實時計算解決方案，隨後Storm，SparkStreaming，Flink等實時計算框架應運而生，而Kafka，ES的興起使得實時計算領域的技術越來越完善，而隨着物聯網，機器學習等技術的推廣，實時流式計算將在這些領域得到充分的應用。

實時計算的三個特徵：

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

隨着實時技術發展趨於成熟，實時計算應用越來越廣泛，以下僅列舉常見的幾種實時計算的應用場景：

1. 實時智能推薦

智能推薦會根據用戶歷史的購買或瀏覽行為，通過推薦算法訓練模型，預測用戶未來可能會購買的物品或喜愛的資訊。對個人來說，推薦系統起着信息過濾的作用，對Web/App服務端來說，推薦系統起着滿足用戶個性化需求，提升用戶滿意度的作用。推薦系統本身也在飛速發展，除了算法越來越完善，對時延的要求也越來越苛刻和實時化。利用Flink流計算幫助用戶構建更加實時的智能推薦系統，對用戶行為指標進行實時計算，對模型進行實時更新，對用戶指標進行實時預測，並將預測的信息推送給Web/App端，幫助用戶獲取想要的商品信息，另一方面也幫助企業提升銷售額，創造更大的商業價值。

2. 實時欺詐檢測

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

3. 輿情分析

有的客戶需要做輿情分析，要求所有數據存放若干年，輿情數據每日數據量可能超百萬，年數據量可達到幾十億的數據。而且爬蟲爬過來的數據是輿情，通過大數據技術進行分詞之後得到的可能是大段的網友評論，客戶往往要求對輿情進行查詢，做全文本搜索，並要求響應時間控制在秒級。爬蟲將數據爬到大數據平台的Kafka里，在裡面做Flink流處理，去重去噪做語音分析，寫到ElasticSearch里。大數據的一個特點是多數據源，大數據平台能根據不同的場景選擇不同的數據源。

4. 複雜事件處理

對於複雜事件處理，比較常見的集中於工業領域，例如對車載傳感器，機械設備等實時故障檢測，這些業務類型通常數據量都非常大，且對數據處理的時效性要求非常高。通過利用Flink提供的CEP進行時間模式的抽取，同時應用Flink的Sql進行事件數據的轉換，在流式系統中構建實施規則引擎，一旦事件觸發報警規則，便立即將告警結果通知至下游通知系統，從而實現對設備故障快速預警檢測，車輛狀態監控等目的。

5. 實時機器學習

實時機器學習是一個更寬泛的概念，傳統靜態的機器學習主要側重於靜態的模型和歷史數據進行訓練並提供預測。很多時候用戶的短期行為，對模型有修正作用，或者說是對業務判斷有預測作用。對系統來說，需要採集用戶最近的行為並進行特徵工程，然後給到實時機器學習系統進行機器學習。如果動態地實施新規則，或是推出新廣告，就會有很大的參考價值。

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

在上面這張架構圖中，數據從Web平台中產生，通過數據同步系統導入到大數據平台，由於數據源不同，這裡的數據同步系統實際上是多個相關系統的組合。數據庫同步通常用 Sqoop，日誌同步可以選擇 Flume等，不同的數據源產生的數據質量可能差別很大，數據庫中的格式化數據直接導入大數據系統即可，而日誌和爬蟲產生的數據就需要進行大量的清洗、轉化處理才能有效使用。

該層對原始數據、清洗關聯後的明細數據進行存儲，基於統一的實時數據模型分層理念，將不同應用場景的數據分別存儲在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存儲中。

計算層主要使用 Flink、Spark、Presto 以及 ClickHouse 自帶的計算能力等四種計算引擎，Flink 計算引擎主要用於實時數據同步、 流式 ETL、關鍵系統秒級實時指標計算場景，Spark SQL 主要用於複雜多維分析的准實時指標計算需求場景，Presto 和 ClickHouse 主要滿足多維自助分析、對查詢響應時間要求不太高的場景。

以統一查詢服務對各個業務線數據場景進行支持，業務主要包括實時大屏、實時數據產品、實時 OLAP、實時特徵等。

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

1. 元數據及指標管理：主要對實時的Kafka表、Kudu表、Clickhouse表、Hive表等進行統一管理，以數倉模型中表的命名方式規範表的命名，明確每張表的字段含義、使用方，指標管理則是儘量通過指標管理系統將所有的實時指標統一管理起來，明確計算口徑，提供給不同的業務方使用；

2. 數據質量及血緣分析：數據質量分為平台監控和數據監控兩個部分，血緣分析則主要是對實時數據依賴關係、實時任務的依賴關係進行分析。

以上架構只是大數據平台通用的數據模型，如果要具體的建設，需要考慮以下情況，業務需求需要實時還是准實時即可，數據時效性是秒級還是分鐘級等。

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

於是隨之誕生了大數據實時數倉，並且衍生出了兩種技術架構Lambda和Kappa。

先來看下Lambda架構圖：

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

為什麼Lambda架構要分成兩條線計算？

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

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

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

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

批處理層使用可處理大量數據的分布式處理系統預先計算結果。它通過處理所有的已有歷史數據來實現數據的準確性。這意味着它是基於完整的數據集來重新計算的，能夠修復任何錯誤，然後更新現有的數據視圖。輸出通常存儲在只讀數據庫中，更新則完全取代現有的預先計算好的視圖。

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

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

那Lambda架構有沒有缺點呢？

Lambda架構經歷多年的發展，其優點是穩定，對於實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構支撐了數據行業的早期發展，但是它也有一些致命缺點，並在大數據3.0時代越來越不適應數據分析業務的需求。缺點如下：

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

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

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

另外一種在大規模數據處理中常用的架構——Kappa 架構，便是在這樣的思考下誕生的。

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

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

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

Kappa架構相對更簡單，實時性更好，所需的計算資源遠小於Lambda架構，隨着實時處理的需求在不斷增長，更多的企業開始使用Kappa架構。但這不意味着kappa架構能夠取代Lambda架構。

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

還有一些比較複雜的場景，批處理與流處理產生不同的結果（使用不同的機器學習模型，專家系統，或者實時計算難以處理的複雜計算），可能更適合Lambda架構。

本文檔總共九章，因字數限制，本文只發了前四章，如獲取此數倉建設完整版文檔，請給本文點在看+轉發朋友圈，然後下方掃碼加我微信，發送轉發朋友圈截圖，即可獲取完整版PDF文檔！(人數較多，發完截圖請耐心等待下)