數倉建設保姆級教程，離線和實時一網打盡(理論+實戰)
本文大綱：
因內容較多，帶目錄的PDF檢視是比較方便的：
一、數倉基本概念
1. 資料倉庫架構
我們在談數倉之前，為了讓大家有直觀的認識，先來談數倉架構，“架構”是什麼？這個問題從來就沒有一個準確的答案。這裡我們引用一段話：在軟體行業，一種被普遍接受的架構定義是指系統的一個或多個結構。結構中包括軟體的構建（構建是指軟體的設計與實現），構建的外部可以看到屬性以及它們之間的相互關係。
這裡參考此定義，把資料倉庫架構理解成構成資料倉庫的元件及其之間的關係，畫出下面的數倉架構圖：
上圖中顯示的整個資料倉庫環境包括操作型系統和資料倉庫系統兩大部分。操作型系統的資料由各種形式的業務資料組成，這些資料經過抽取、轉換和裝載（ETL）過程進入資料倉庫系統。
任何事物都是隨著時間的演進變得越來越完善，當然也是越來越複雜，數倉也不例外。在資料倉庫技術演化過程中，產生了幾種主要的架構方法，包括資料集市架構、Inmon企業資訊工廠架構、Kimball資料倉庫架構、混合型資料倉庫架構。這幾種架構我們後面再講，接下來看下數倉的基本概念。
2. 資料倉庫概念
英文名稱為Data Warehouse，可簡寫為DW或DWH。資料倉庫的目的是構建面向分析的整合化資料環境，為企業提供決策支援（Decision Support）。它出於分析性報告和決策支援目的而建立。
資料倉庫本身並不“生產”任何資料，同時自身也不需要“消費”任何的資料，資料來源於外部，並且開放給外部應用，這也是為什麼叫“倉庫”，而不叫“工廠”的原因。
1) 基本特徵
資料倉庫是面向主題的、整合的、非易失的和時變的資料集合，用以支援管理決策。
面向主題:
傳統資料庫中，最大的特點是面向應用進行資料的組織，各個業務系統可能是相互分離的。而資料倉庫則是面向主題的。主題是一個抽象的概念，是較高層次上企業資訊系統中的資料綜合、歸類並進行分析利用的抽象。在邏輯意義上，它是對應企業中某一巨集觀分析領域所涉及的分析物件。
整合性:
通過對分散、獨立、異構的資料庫資料進行抽取、清理、轉換和彙總便得到了資料倉庫的資料，這樣保證了資料倉庫內的資料關於整個企業的一致性。
資料倉庫中的綜合資料不能從原有的資料庫系統直接得到。因此在資料進入資料倉庫之前，必然要經過統一與綜合，這一步是資料倉庫建設中最關鍵、最複雜的一步，所要完成的工作有：
要統一源資料中所有矛盾之處，如欄位的同名異義、異名同義、單位不統一、字長不一致，等等。 進行資料綜合和計算。資料倉庫中的資料綜合工作可以在從原有資料庫抽取資料時生成，但許多是在資料倉庫內部生成的，即進入資料倉庫以後進行綜合生成的。
下圖說明一個保險公司綜合資料的簡單處理過程，其中資料倉庫中與“保險” 主題有關的資料來自於多個不同的操作型系統。這些系統內部資料的命名可能不同，資料格式也可能不同。把不同來源的資料儲存到資料倉庫之前，需要去除這些不一致。
非易失性（不可更新性）:
資料倉庫的資料反映的是一段相當長的時間內歷史資料的內容，是不同時點的資料庫快照的集合，以及基於這些快照進行統計、綜合和重組的匯出資料。
資料非易失性主要是針對應用而言。資料倉庫的使用者對資料的操作大多是資料查詢或比較複雜的挖掘，一旦資料進入資料倉庫以後，一般情況下被較長時間保留。資料倉庫中一般有大量的查詢操作，但修改和刪除操作很少。因此，資料經加工和整合進入資料倉庫後是極少更新的，通常只需要定期的載入和更新。
時變性:
資料倉庫包含各種粒度的歷史資料。資料倉庫中的資料可能與某個特定日期、星期、月份、季度或者年份有關。資料倉庫的目的是通過分析企業過去一段時間業務的經營狀況，挖掘其中隱藏的模式。雖然資料倉庫的使用者不能修改資料，但並不是說資料倉庫的資料是永遠不變的。分析的結果只能反映過去的情況，當業務變化後，挖掘出的模式會失去時效性。因此資料倉庫的資料需要更新，以適應決策的需要。從這個角度講，資料倉庫建設是一個專案，更是一個過程。資料倉庫的資料隨時間的變化表現在以下幾個方面：
（1） 資料倉庫的資料時限一般要遠遠長於操作型資料的資料時限。
（2） 操作型系統儲存的是當前資料，而資料倉庫中的資料是歷史資料。
（3） 資料倉庫中的資料是按照時間順序追加的，它們都帶有時間屬性。
3. 為什麼要有資料倉庫
先來看下資料倉庫的資料從哪裡來，最終要到哪裡去？
通常資料倉庫的資料來自各個業務應用系統。業務系統中的資料形式多種多樣，可能是 Oracle、MySQL、SQL Server等關係資料庫裡的結構化資料，可能是文字、CSV等平面檔案或Word、Excel文件中的資料，還可能是HTML、XML等自描述的半結構化資料。這些業務資料經過一系列的資料抽取、轉換、清洗，最終以一種統一的格式裝載進資料倉庫。資料倉庫裡的資料作為分析用的資料來源，提供給後面的即席查詢、 分析系統、資料集市、報表系統、資料探勘系統等。
這時我們就想了，為什麼不能把業務系統的資料直接拿來供即席查詢、分析系統、報表系統等使用呢，為什麼要經過資料倉庫這一步？實際上在數倉出現之前，確實是這麼做的，但是有很多資料分析的先驅者當時已經發現，簡單的“直接訪問”方式很難良好工作，這樣做的失敗案例數不勝數。下面列舉一些直接訪問業務系統無法工作的原因：
某些業務資料由於安全或其他因素不能直接訪問。 業務系統的版本變更很頻繁，每次變更都需要重寫分析系統並重新測試。 很難建立和維護彙總資料來源於多個業務系統版本的報表。 業務系統的列名通常是硬編碼，有時僅僅是無意義的字串，這讓編寫分析系統更加困難。 業務系統的資料格式，如日期、數字的格式不統一。 業務系統的表結構為事務處理效能而優化，有時並不適合查詢與分析。 沒有適當的方式將有價值的資料合併進特定應用的資料庫。 沒有適當的位置儲存元資料。 使用者需要看到的顯示資料欄位，有時在資料庫中並不存在。 通常事務處理的優先順序比分析系統高，所以如果分析系統和事務處理執行在同一硬體之上，分析系統往往效能很差。 有誤用業務資料的風險。 極有可能影響業務系統的效能。
儘管需要增加軟硬體的投入，但建立獨立資料倉庫與直接訪問業務資料相比，無論是成本還是帶來的好處，這樣做都是值得的。隨著處理器和儲存成本的逐年降低，資料倉庫方案的優勢更加明顯，在經濟上也更具可行性。
4. 資料倉庫與資料庫的區別
資料庫與資料倉庫的區別實際講的是 OLTP 與 OLAP 的區別。
操作型處理，叫聯機事務處理 OLTP（On-Line Transaction Processing，），也可以稱面向交易的處理系統，它是針對具體業務在資料庫聯機的日常操作，通常對少數記錄進行查詢、修改。使用者較為關心操作的響應時間、資料的安全性、完整性和併發支援的使用者數等問題。傳統的資料庫系統作為資料管理的主要手段，主要用於操作型處理，像Mysql，Oracle等關係型資料庫一般屬於OLTP。
分析型處理，叫聯機分析處理 OLAP（On-Line Analytical Processing）一般針對某些主題的歷史資料進行分析，支援管理決策。
首先要明白，資料倉庫的出現，並不是要取代資料庫。資料庫是面向事務的設計，資料倉庫是面向主題設計的。資料庫一般儲存業務資料，資料倉庫儲存的一般是歷史資料。
資料庫設計是儘量避免冗餘，一般針對某一業務應用進行設計，比如一張簡單的User表，記錄使用者名稱、密碼等簡單資料即可，符合業務應用，但是不符合分析。資料倉庫在設計是有意引入冗餘，依照分析需求，分析維度、分析指標進行設計。
資料庫是為捕獲資料而設計，資料倉庫是為分析資料而設計。
以銀行業務為例。資料庫是事務系統的資料平臺，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這裡，可以簡單地理解為用資料庫記賬。資料倉庫是分析系統的資料平臺，它從事務系統獲取資料，並做彙總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款餘額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。
顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求資料庫只能儲存很短一段時間的資料。而分析系統是事後的，它要提供關注時間段內所有的有效資料。這些資料是海量的，彙總計算起來也要慢一些，但是，只要能夠提供有效的分析資料就達到目的了。
資料倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘資料資源、為了決策需要而產生的，它決不是所謂的“大型資料庫”。
5. 資料倉庫分層架構
按照資料流入流出的過程，資料倉庫架構可分為：源資料、資料倉庫、資料應用
資料倉庫的資料來源於不同的源資料，並提供多樣的資料應用，資料自下而上流入資料倉庫後向上層開放應用，而資料倉庫只是中間整合化資料管理的一個平臺。
源資料：此層資料無任何更改，直接沿用外圍系統資料結構和資料，不對外開放；為臨時儲存層，是介面資料的臨時儲存區域，為後一步的資料處理做準備。
資料倉庫：也稱為細節層，DW層的資料應該是一致的、準確的、乾淨的資料，即對源系統資料進行了清洗（去除了雜質）後的資料。
資料應用：前端應用直接讀取的資料來源；根據報表、專題分析需求而計算生成的資料。
資料倉庫從各資料來源獲取資料及在資料倉庫內的資料轉換和流動都可以認為是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是資料倉庫的流水線，也可以認為是資料倉庫的血液，它維繫著資料倉庫中資料的新陳代謝，而資料倉庫日常的管理和維護工作的大部分精力就是保持ETL的正常和穩定。
那麼為什麼要資料倉庫進行分層呢?
用空間換時間，通過大量的預處理來提升應用系統的使用者體驗（效率），因此資料倉庫會存在大量冗餘的資料；不分層的話，如果源業務系統的業務規則發生變化將會影響整個資料清洗過程，工作量巨大。
通過資料分層管理可以簡化資料清洗的過程，因為把原來一步的工作分到了多個步驟去完成，相當於把一個複雜的工作拆成了多個簡單的工作，把一個大的黑盒變成了一個白盒，每一層的處理邏輯都相對簡單和容易理解，這樣我們比較容易保證每一個步驟的正確性，當資料發生錯誤的時候，往往我們只需要區域性調整某個步驟即可。
6. 主要資料倉庫架構
通過上面的內容我們大概瞭解數倉的概念，接下來就看下數倉的幾種演進架構。
1. 資料集市架構
資料集市是按主題域組織的資料集合，用於支援部門級的決策。有兩種型別的資料集市：獨立資料集市和從屬資料集市。
1) 獨立資料集市
獨立資料集市集中於部門所關心的單一主題域，資料以部門為基礎部署，無須考慮企業級別的資訊共享與整合。例如，製造部門、人力資源部門和其他部門都各自有他們自己的資料集市。
優點：因為一個部門的業務相對於整個企業要簡單，資料量也小得多，所以部門的獨立資料集市具有周期短、見效快的特點。
缺點：
從業務角度看，當部門的分析需求擴充套件，或者需要分析跨部門或跨主題域的資料時，獨立資料市場會顯得力不從心。 當資料存在歧義，比如同一個產品，在A部門和B部門的定義不同時，將無法在部門間進行資訊比較。 每個部門使用不同的技術，建立不同的ETL的過程，處理不同的事務系統，而在多個獨立的資料集市之間還會存在資料的交叉與重疊，甚至會有資料不一致的情況。
2) 從屬資料集市
從屬資料集市的資料來源於資料倉庫。資料倉庫裡的資料經過整合、重構、彙總後傳遞給從屬資料集市。
建立從屬資料集市的好處主要有：
效能：當資料倉庫的查詢效能出現問題，可以考慮建立幾個從屬資料集市，將查詢從資料倉庫移出到資料集市。 安全：每個部門可以完全控制他們自己的資料。 資料一致：因為每個資料集市的資料來源都是同一個資料倉庫，有效消除了資料不一致的情況。
2. Inmon企業工廠架構
上圖的前兩步不過多介紹，直接從第三步開始。
企業級資料倉庫：是該架構中的核心元件。正如Inmon資料倉庫所定義的，企業級資料倉庫是一個細節資料的整合資源庫。其中的資料以最低粒度級別被捕獲，儲存在滿足三正規化設計的關係資料庫中。
部門級資料集市：是面向主題資料的部門級檢視，資料從企業級資料倉庫獲取。資料在進入部門資料集市時可能進行聚合。資料集市使用多維模型設計，用於資料分析。重要的一點是，所有的報表工具、BI工具或其他資料分析應用都從資料集市查詢資料，而不是直接查詢企業級資料倉庫。
3. Kimball資料倉庫架構
對比上一張圖可以看到，Kimball與Inmon兩種架構的主要區別在於核心資料倉庫的設計和建立。
Kimball的資料倉庫包含高粒度的企業資料，使用多維模型設計，這也意味著資料倉庫由星型模式的維度表和事實表構成。分析系統或報表工具可以直接訪問多維資料倉庫裡的資料。
在此架構中的資料集市也與Inmon中的不同。這裡的資料集市是一個邏輯概念，只是多維資料倉庫中的主題域劃分，並沒有自己的物理儲存，也可以說是虛擬的資料集市。
4. 混合型資料倉庫架構
所謂的混合型結構，指的是在一個數據倉庫環境中，聯合使用Inmon和Kimball兩種架構。
從架構圖可以看到，這種架構將Inmon方法中的資料集市部分替換成了一個多維資料倉庫，而資料集市則是多維資料倉庫上的邏輯檢視。
使用這種架構的好處是：既可以利用規範化設計消除資料冗餘，保證資料的粒度足夠細；又可以利用多維結構更靈活地在企業級實現報表和分析。
7. 資料倉庫元資料的管理
元資料（Meta Date），主要記錄資料倉庫中模型的定義、各層級間的對映關係、監控資料倉庫的資料狀態及ETL的任務執行狀態。一般會通過元資料資料庫（Metadata Repository）來統一地儲存和管理元資料，其主要目的是使資料倉庫的設計、部署、操作和管理能達成協同和一致。
元資料是資料倉庫管理系統的重要組成部分，元資料管理是企業級資料倉庫中的關鍵元件，貫穿資料倉庫構建的整個過程，直接影響著資料倉庫的構建、使用和維護。
構建資料倉庫的主要步驟之一是ETL。這時元資料將發揮重要的作用，它定義了源資料系統到資料倉庫的對映、資料轉換的規則、資料倉庫的邏輯結構、資料更新的規則、資料匯入歷史記錄以及裝載週期等相關內容。資料抽取和轉換的專家以及資料倉庫管理員正是通過元資料高效地構建資料倉庫。 使用者在使用資料倉庫時，通過元資料訪問資料，明確資料項的含義以及定製報表。 資料倉庫的規模及其複雜性離不開正確的元資料管理，包括增加或移除外部資料來源，改變資料清洗方法，控制出錯的查詢以及安排備份等。
元資料可分為技術元資料和業務元資料。技術元資料為開發和管理資料倉庫的IT 人員使用，它描述了與資料倉庫開發、管理和維護相關的資料，包括資料來源資訊、資料轉換描述、資料倉庫模型、資料清洗與更新規則、資料對映和訪問許可權等。而業務元資料為管理層和業務分析人員服務，從業務角度描述資料，包括商務術語、資料倉庫中有什麼資料、資料的位置和資料的可用性等，幫助業務人員更好地理解資料倉庫中哪些資料是可用的以及如何使用。
由上可見，元資料不僅定義了資料倉庫中資料的模式、來源、抽取和轉換規則等，而且是整個資料倉庫系統執行的基礎，元資料把資料倉庫系統中各個鬆散的元件聯絡起來，組成了一個有機的整體。
8. 數倉常見術語解析
本文件首發於公眾號【五分鐘學大資料】
本小節結構如下圖所示：
1. 數倉名詞解釋
1. 實體
實體是指依附的主體，就是我們分析的一個物件，比如我們分析商品的銷售情況，如華為手機近半年的銷售量是多少，那華為手機就是一個實體；我們分析使用者的活躍度，使用者就是一個實體。當然實體也可以現實中不存在的，比如虛擬的業務物件，活動，會員等都可看做一個實體。
實體的存在是為了業務分析，作為分析的一個篩選的維度，擁有描述自己的屬性，本身具有可分析的價值。
2. 維度
維度就是看待問題的角度，分析業務資料，從什麼角度分析，就建立什麼樣的維度。所以維度就是要對資料進行分析時所用的一個量，比如你要分析產品銷售情況，你可以選擇按商品類別來進行分析，這就構成一個維度，把所有商品類別集合在一起，就構成了維度表。
3. 度量
度量是業務流程節點上的一個數值。比如銷量，價格，成本等等。
事實表中的度量可分為三類：完全可加，半可加，不可加。
完全可加的度量是最靈活，最有用的，比如說銷量，銷售額等，可進行任意維度彙總；
半可加的度量可以對某些維度彙總，但不能對所有維度彙總，差額是常見的半可加度量，它除了時間維度外，可以跨所有維度進行加法操作；
還有一種是完全不可加的，例如：比率。對於這類非可加度量，一種好的方法是，儘可能儲存非可加度量的完全可加分量，並在計算出最終的非可加事實前，將這些分量彙總到最終的結果集中。
4. 粒度
粒度就是業務流程中對度量的單位，比如商品是按件記錄度量，還是按批記錄度量。
在數倉建設中，我們說這是使用者粒度的事實表，那麼表中每行資料都是一個使用者，無重複使用者；例如還有銷售粒度的表，那麼表中每行都是一條銷售記錄。
選擇合適的粒度級別是資料倉庫建設好壞的重要關鍵內容，在設計資料粒度時，通常需重點考慮以下因素：
要接受的分析型別、可接受的資料最低粒度和能儲存的資料量；
粒度的層次定義越高，就越不能在該倉庫中進行更細緻的分析；
如果儲存資源有一定的限制，就只能採用較高的資料粒度劃分；
資料粒度劃分策略一定要保證：資料的粒度確實能夠滿足使用者的決策分析需要，這是資料粒度劃分策略中最重要的一個準則。
5. 口徑
口徑就是取數邏輯（如何取數的），比如要取的數是10歲以下兒童中男孩的平均身高，這就是統計的口徑。
6. 指標
指標是口徑的衡量值，也就是最後的結果。比如最近七天的訂單量，一個促銷活動的購買轉化率等。
一個指標具體到計算實施，主要有以下幾部分組成：
指標加工邏輯，比如count ,sum, avg
維度，比如按部門、地域進行指標統計，對應sql中的group by
業務限定/修飾詞，比如以不同的支付渠道來算對應的指標，微信支付的訂單退款率，支付寶支付的訂單退款率 。對應sql中的where。
除此之外，指標本身還可以衍生、派生出更多的指標，基於這些特點，可以將指標進行分類：
原子指標：基本業務事實，沒有業務限定、沒有維度。比如訂單表中的訂單量、訂單總金額都算原子指標；
業務方更關心的指標，是有實際業務含義，可以直接取資料的指標。比如店鋪近1天訂單支付金額就是一個派生指標，會被直接在產品上展示給商家看。
但是這個指標卻不能直接從數倉的統一中間層裡取數（因為沒有現成的事實欄位，數倉提供的一般都是大寬表）。需要有一個橋樑連線數倉中間層和業務方的指標需求，於是便有了派生指標
派生指標：維度+修飾詞+原子指標。 店鋪近1天訂單支付金額中店鋪是維度，近1天是一個時間型別的修飾詞，支付金額是一個原子指標；
維度：觀察各項指標的角度；
修飾詞：維度的一個或某些值，比如維度性別下，男和女就是2種修飾詞。
衍生指標：比如某一個促銷活動的轉化率就是衍生指標，因為需要促銷投放人數指標和促銷訂單數指標進行計算得出。
7. 標籤
標籤是人為設定的、根據業務場景需求，對目標物件運用一定的演算法得到的高度精煉的特徵標識。可見標籤是經過人為再加工後的結果，如網紅、白富美、蘿莉。對於有歧義的標籤，我們內部可進行標籤區分，比如：蘋果，我們可以定義蘋果指的是水果，蘋果手機才指的是手機。
8. 自然鍵
由現實中已經存在的屬性組成的鍵，它在業務概念中是唯一的，並具有一定的業務含義，比如商品ID，員工ID。
以數倉角度看，來自於業務系統的識別符號就是自然鍵，比如業務庫中員工的編號。
9. 持久鍵
保持永久性不會發生變化。有時也被叫做超自然持久鍵。比如身份證號屬於持久鍵。
自然鍵和持久鍵區別：舉個例子就明白了，比如說公司員工離職之後又重新入職，他的自然鍵也就是員工編號發生了變化，但是他的持久鍵身份證號是不變的。
10. 代理鍵
就是不具有業務含義的鍵。代理鍵有許多其他的稱呼：無意義鍵、整數鍵、非自然鍵、人工鍵、合成鍵等。
代理鍵就是簡單的以按照順序序列生產的整數表示。產品行的第1行代理鍵為1，則下一行的代理鍵為2，如此進行。代理鍵的作用僅僅是連線維度表和事實表。
11. 退化維度
退化維度，就是那些看起來像是事實表的一個維度關鍵字，但實際上並沒有對應的維度表，就是維度屬性儲存到事實表中，這種儲存到事實表中的維度列被稱為退化維度。與其他儲存在維表中的維度一樣，退化維度也可以用來進行事實表的過濾查詢、實現聚合操作等。
那麼究竟怎麼定義退化維度呢？比如說訂單id，這種量級很大的維度，沒必要用一張維度表來進行儲存，而我們進行資料查詢或者資料過濾的時候又非常需要，所以這種就冗餘在事實表裡面，這種就叫退化維度，citycode這種我們也會冗餘在事實表裡面，但是它有對應的維度表，所以它不是退化維度。
12. 下鑽
這是在資料分析中常見的概念，下鑽可以理解成增加維的層次，從而可以由粗粒度到細粒度來觀察資料，比如對產品銷售情況分析時，可以沿著時間維從年到月到日更細粒度的觀察資料。從年的維度可以下鑽到月的維度、日的維度等。
13. 上卷
知道了下鑽，上卷就容易理解了，它倆是相逆的操作，所以上卷可以理解為刪掉維的某些層，由細粒度到粗粒度觀察資料的操作或沿著維的層次向上聚合彙總資料。
14. 資料集市
資料集市（Data Mart），也叫資料市場，資料集市就是滿足特定的部門或者使用者的需求，按照多維的方式進行儲存，包括定義維度、需要計算的指標、維度的層次等，生成面向決策分析需求的資料立方體。其實就是從資料倉庫中抽取出來的一個小合集。
2. 數倉名詞之間關係
1. 實體表，事實表，維度表之間的關係
在Kimball維度建模中有維度與事實，在Inmon正規化建模中有實體與關係，如果我們分開兩種建模方式看這些概念比較容易理解。但是目前也出現了不少混合建模方式，兩種建模方式結合起來看，這些概念是不是容易記憶混亂，尤其事實表和實體表，它們之間到底有怎樣區別與聯絡，先看下它們各自概念：
維度表：維度表可以看成是使用者用來分析一個事實的視窗，它裡面的資料應該是對事實的各個方面描述，比如時間維度表，地域維度表，維度表是事實表的一個分析角度。
事實表：事實表其實就是通過各種維度和一些指標值的組合來確定一個事實的，比如通過時間維度，地域組織維度，指標值可以去確定在某時某地的一些指標值怎麼樣的事實。事實表的每一條資料都是幾條維度表的資料和指標值交匯而得到的。
實體表：實體表就是一個實際物件的表，實體表放的資料一定是一條條客觀存在的事物資料，比如說各種商品，它就是客觀存在的，所以可以將其設計一個實體表。實時表只描述各個事物，並不存在具體的事實，所以也有人稱實體表是無事實的事實表。
舉個例子：比如說手機商場中有蘋果手機，華為手機等各品牌各型號的手機，這些資料可以組成一個手機實體表，但是表中沒有可度量的資料。某天蘋果手機賣了15臺，華為手機賣了20臺，這些手機銷售資料屬於事實，組成一個事實表。這樣就可以使用日期維度表和地域維度表對這個事實表進行各種維度分析。
2. 指標與標籤的區別
概念不同
指標是用來定義、評價和描述特定事物的一種標準或方式。比如：新增使用者數、累計使用者數、使用者活躍率等是衡量使用者發展情況的指標；
標籤是人為設定的、根據業務場景需求，對目標物件運用一定的演算法得到的高度精煉的特徵標識。可見標籤是經過人為再加工後的結果，如網紅、白富美、蘿莉。
構成不同
指標名稱是對事物質與量兩方面特點的命名；指標取值是指標在具體時間、地域、條件下的數量表現，如人的體重，指標名稱是體重，指標的取值就是120斤；
標籤名稱通常都是形容詞或形容詞+名詞的結構，標籤一般是不可量化的，通常是孤立的，除了基礎類標籤，通過一定演算法加工出來的標籤一般都沒有單位和量綱。如將超過200斤的稱為大胖子。
分類不同
對指標的分類：
按照指標計算邏輯，可以將指標分為原子指標、派生指標、衍生指標三種類型；
按照對事件描述內容的不同，分為過程性指標和結果性指標；
對標籤的分類：
按照標籤的變化性分為靜態標籤和動態標籤；
按照標籤的指代和評估指標的不同，可分為定性標籤和定量標籤；
指標最擅長的應用是監測、分析、評價和建模。
標籤最擅長的應用是標註、刻畫、分類和特徵提取。
特別需要指出的是，由於對結果的標註也是一種標籤，所以在自然語言處理和機器學習相關的演算法應用場景下，標籤對於監督式學習有重要價值，只是單純的指標難以做到的。而指標在任務分配、績效管理等領域的作用，也是標籤無法做到的。
3. 維度和指標區別與聯絡
維度就是資料的觀察角度，即從哪個角度去分析問題，看待問題。
指標就是從維度的基礎上去衡算這個結果的值。
維度一般是一個離散的值，比如時間維度上每一個獨立的日期或地域，因此統計時，可以把維度相同記錄的聚合在一起，應用聚合函式做累加、均值、最大值、最小值等聚合計算。
指標就是被聚合的通計算，即聚合運算的結果，一般是一個連續的值。
4. 自然鍵與代理鍵在數倉的使用區別
數倉工具箱中說維度表的唯一主鍵應該是代理鍵而不應該是自然鍵。有時建模人員不願意放棄使用自然鍵，因為他們希望與操作型程式碼查詢事實表，而不希望與維度表做連線操作。然而，應該避免使用包含業務含義的多維鍵，因為不管我們做出任何假設最終都可能變得無效，因為我們控制不了業務庫的變動。
所以資料倉庫中維度表與事實表的每個連線應該基於無實際含義的整數代理鍵。避免使用自然鍵作為維度表的主鍵。
5. 資料集市和資料倉庫的關係
資料集市是企業級資料倉庫的一個子集，他主要面向部門級業務，並且只面向某個特定的主題。為了解決靈活性和效能之間的矛盾，資料集市就是資料倉庫體系結構中增加的一種小型的部門或工作組級別的資料倉庫。資料集市儲存為特定使用者預先計算好的資料，從而滿足使用者對效能的需求。資料集市可以在一定程度上緩解訪問資料倉庫的瓶頸。
資料集市和資料倉庫的主要區別：資料倉庫是企業級的，能為整個企業各個部門的執行提供決策支援手段；而資料集市則是一種微型的資料倉庫,它通常有更少的資料,更少的主題區域,以及更少的歷史資料,因此是部門級的，一般只能為某個區域性範圍內的管理人員服務，因此也稱之為部門級資料倉庫。
文章都會首發在公眾號【五分鐘學大資料】
二、離線數倉建設核心
資料倉庫的核心是展現層和提供優質的服務。ETL 及其規範、分層等所做的一切都是為了一個更清晰易用的展現層。
1. 數倉分層
數倉分層的原則：
為便於資料分析，要遮蔽底層複雜業務，簡單、完整、整合的將資料暴露給分析層。
底層業務變動與上層需求變動對模型衝擊最小化，業務系統變化影響削弱在基礎資料層，結合自上而下的建設方法削弱需求變動對模型的影響。
高內聚鬆耦合，即主題之內或各個完整意義的系統內資料的高內聚，主題之間或各個完整意義的系統間資料的鬆耦合。
構建倉庫基礎資料層，使底層業務資料整合工作與上層應用開發工作相隔離，為倉庫大規模開發奠定基礎 倉庫層次更加清晰，對外暴露資料更加統一。
一般採用如下分層結構：
1. 資料來源層：ODS（Operational Data Store）
ODS 層，是最接近資料來源中資料的一層，為了考慮後續可能需要追溯資料問題，因此對於這一層就不建議做過多的資料清洗工作，原封不動地接入原始資料即可，至於資料的去噪、去重、異常值處理等過程可以放在後面的 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 層要做的就是將資料清理、整合、規範化、髒資料、垃圾資料、規範不一致的、狀態定義不一致的、命名不規範的資料都會被處理。
同時，為了提高資料明細層的易用性，該層會採用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯。
另外，在該層也會做一部分的資料聚合，將相同主題的資料彙集到一張表中，提高資料的可用性 。
2) 資料中間層：DWM（Data WareHouse Middle）
該層會在 DWD 層的資料基礎上，資料做輕度的聚合操作，生成一系列的中間表，提升公共指標的複用性，減少重複加工。
直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。
在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在 DWM 層先計算出多個小的中間表，然後再拼接成一張 DWS 的寬表。由於寬和窄的界限不易界定，也可以去掉 DWM 這一層，只留 DWS 層，將所有的資料再放在 DWS 亦可。
3) 資料服務層：DWS（Data WareHouse Servce）
DWS 層為公共彙總層，會進行輕度彙總，粒度比明細資料稍粗，基於 DWD 層上的基礎資料，整合彙總成分析某一個主題域的服務資料，一般是寬表。DWS 層應覆蓋 80% 的應用場景。又稱資料集市或寬表。
按照業務劃分，如主題域流量、訂單、使用者等，生成欄位比較多的寬表，用於提供後續的業務查詢，OLAP 分析，資料分發等。
一般來講，該層的資料表會相對比較少，一張表會涵蓋比較多的業務內容，由於其欄位較多，因此一般也會稱該層的表為寬表。
3. 資料應用層：APP（Application）
在這裡，主要是提供給資料產品和資料分析使用的資料，一般會存放在 ES、 PostgreSql、Redis 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供資料分析和資料探勘使用。比如我們經常說的報表資料，一般就放在這裡。
4. 維表層：DIM（Dimension）
如果維表過多，也可針對維表設計單獨一層，維表層主要包含兩部分資料：
高基數維度資料：一般是使用者資料表、商品資料表類似的資料表。資料量可能是千萬級或者上億級別。
低基數維度資料：一般是配置表，比如列舉值對應的中文含義，或者日期維表。 資料量可能是個位數或者幾千幾萬。
2. 數倉建模方法
數倉建模在哪層建設呢？我們以維度建模為例，建模是在資料來源層的下一層進行建設，在上節的分層架構中，就是在DW層進行數倉建模，所以DW層是數倉建設的核心層。
那數倉建模怎麼建呢？其實資料倉庫的建模方法有很多種，每一種建模方法代表了哲學上的一個觀點，代表了一種歸納、概括世界的一種方法。常見的有 正規化建模法、維度建模法、實體建模法等，每種方法從本質上將是從不同的角度看待業務中的問題。
1. 正規化建模法（Third Normal Form，3NF）
正規化建模法其實是我們在構建資料模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關係型資料庫的資料儲存，利用的一種技術層面上的方法。目前，我們在關係型資料庫中的建模方法，大部分採用的是三正規化建模法。
正規化 是符合某一種級別的關係模式的集合。構造資料庫必須遵循一定的規則，而在關係型資料庫中這種規則就是正規化，這一過程也被稱為規範化。目前關係資料庫有六種正規化：第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF）、Boyce-Codd正規化（BCNF）、第四正規化（4NF）和第五正規化（5NF）。
在資料倉庫的模型設計中，一般採用第三正規化。一個符合第三正規化的關係必須具有以下三個條件 :
每個屬性值唯一，不具有多義性 ;
每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;
每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去。
根據 Inmon 的觀點，資料倉庫模型的建設方法和業務系統的企業資料模型類似。在業務系統中，企業資料模型決定了資料的來源，而企業資料模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關係型資料庫上的例項化。
2. 維度建模法（Dimensional Modeling）
維度模型是資料倉庫領域另一位大師Ralph Kimall所倡導，他的《資料倉庫工具箱》是資料倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應效能。
典型的代表是我們比較熟知的星形模型（Star-schema），以及在一些特殊場景下適用的雪花模型（Snow-schema）。
維度建模中比較重要的概念就是 事實表（Fact table）和維度表（Dimension table）。其最簡單的描述就是，按照事實表、維度表來構建資料倉庫、資料集市。
3. 實體建模法（Entity Modeling）
實體建模法並不是資料倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關係組成。那麼我們在資料倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關係，以及針對這些關係的說明就是我們資料建模需要做的工作。
雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件，說明，如下圖所示：
上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述的是一個業務過程，我們在這裡可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。
3. 維度建模詳解
目前在網際網路公司最常用的建模方法就是維度建模，我們將重點講解！
維度建模是專門應用於分析型資料庫、資料倉庫、資料集市建模的方法。資料集市可以理解為是一種"小型資料倉庫"。
我們先不著急開始維度建模，先來了解下維度建模中表的型別和維度建模的模式之後再開始建模，這樣能夠讓我們深刻理解！
1. 維度建模中表的型別
維度建模分為兩種表：事實表和維度表：
事實表：必然存在的一些資料，像採集的日誌檔案，訂單表，都可以作為事實表 。
特徵：是一堆主鍵的集合，每個主鍵對應維度表中的一條記錄，客觀存在的，根據主題確定出需要使用的資料維度表：維度就是所分析的資料的一個量，維度表就是以合適的角度來建立的表，分析問題的一個角度：時間、地域、終端、使用者等角度
1. 事實表
發生在現實世界中的操作型事件，其所產生的可度量數值，儲存在事實表中。從最低的粒度級別來看，事實錶行對應一個度量事件，反之亦然。
事實表表示對分析主題的度量。比如一次購買行為我們就可以理解為是一個事實。
圖中的訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄。 事實表的特徵：表裡沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯的外來鍵，可與維度表關聯。事實表的度量通常是數值型別，且記錄數會不斷增加，表資料規模迅速增長。
明細表（寬表）：
事實表的資料中，有些屬性共同組成了一個欄位（糅合在一起），比如年月日時分秒構成了時間,當需要根據某一屬性進行分組統計的時候，需要擷取拼接之類的操作，效率極低。 如：
| local_time |
|---|
| 2021-03-18 06:31:42 |
為了分析方便，可以事實表中的一個欄位切割提取多個屬性出來構成新的欄位，因為欄位變多了，所以稱為寬表，原來的成為窄表。
將上述的local_time欄位擴充套件為如下6個欄位：
| year | month | day | hour | m | s |
|---|---|---|---|---|---|
| 2021 | 03 | 18 | 06 | 31 | 42 |
又因為寬表的資訊更加清晰明細，所以也可以稱之為明細表。
事實表種類
事實表分為以下6類：
事務事實表 週期快照事實表 累積快照事實表 無事實的事實表 聚集事實表 合併事實表
簡單解釋下每種表的概念：
事務事實表
表中的一行對應空間或時間上某點的度量事件。就是一行資料中必須有度量欄位，什麼是度量，就是指標，比如說銷售金額，銷售數量等這些可加的或者半可加就是度量值。另一點就是事務事實表都包含一個與維度表關聯的外來鍵。並且度量值必須和事務粒度保持一致。
週期快照事實表
顧名思義，週期事實表就是每行都帶有時間值欄位，代表週期，通常時間值都是標準週期，如某一天，某周，某月等。粒度是週期，而不是個體的事務，也就是說一個週期快照事實表中資料可以是多個事實，但是它們都屬於某個週期內。
累計快照事實表
週期快照事實表是單個週期內資料，而累計快照事實表是由多個週期數據組成，每行彙總了過程開始到結束之間的度量。每行資料相當於管道或工作流，有事件的起點，過程，終點，並且每個關鍵步驟都包含日期欄位。如訂單資料，累計快照事實表的一行就是一個訂單，當訂單產生時插入一行，當訂單發生變化時，這行就被修改。
無事實的事實表
我們以上討論的事實表度量都是數字化的，當然實際應用中絕大多數都是數字化的度量，但是也可能會有少量的沒有數字化的值但是還很有價值的欄位，無事實的事實表就是為這種資料準備的，利用這種事實表可以分析發生了什麼。
聚集事實表
聚集，就是對原子粒度的資料進行簡單的聚合操作，目的就是為了提高查詢效能。如我們需求是查詢全國所有門店的總銷售額，我們原子粒度的事實表中每行是每個分店每個商品的銷售額，聚集事實表就可以先聚合每個分店的總銷售額，這樣彙總所有門店的銷售額時計算的資料量就會小很多。
合併事實表
這種事實表遵循一個原則，就是相同粒度，資料可以來自多個過程，但是隻要它們屬於相同粒度，就可以合併為一個事實表，這類事實表特別適合經常需要共同分析的多過程度量。
2．維度表
每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外來鍵，當然，維度錶行的描述環境應與事實錶行完全對應。維度表通常比較寬，是扁平型非規範表，包含大量的低粒度的文字屬性。
維度表示你要對資料進行分析時所用的一個量，比如你要分析產品銷售情況， 你可以選擇按類別來進行分析，或按區域來分析。每個類別就構成一個維度。上圖中的使用者表、商家表、時間表這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的資料資訊。
總的說來，在資料倉庫中不需要嚴格遵守規範化設計原則。因為資料倉庫的主導功能就是面向分析，以查詢為主，不涉及資料更新操作。事實表的設計是以能夠正確記錄歷史資訊為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。
維度表結構
維度表謹記一條原則，包含單一主鍵列，但有時因業務複雜，也可能出現聯合主鍵，請儘量避免，如果無法避免，也要確保必須是單一的，這很重要，如果維表主鍵不是單一，和事實表關聯時會出現資料發散，導致最後結果可能出現錯誤。
維度表通常比較寬，包含大量的低粒度的文字屬性。
跨表鑽取
跨表鑽取意思是當每個查詢的行頭都包含相同的一致性屬性時，使不同的查詢能夠針對兩個或更多的事實表進行查詢
鑽取可以改變維的層次，變換分析的粒度。它包括上鑽/下鑽：
上鑽（roll-up）：上卷是沿著維的層次向上聚集彙總資料。例如，對產品銷售資料，沿著時間維上卷，可以求出所有產品在所有地區每月（或季度或年或全部）的銷售額。
下鑽（drill-down）：下鑽是上鑽的逆操作，它是沿著維的層次向下，檢視更詳細的資料。
退化維度
退化維度就是將維度退回到事實表中。因為有時維度除了主鍵沒有其他內容，雖然也是合法維度鍵，但是一般都會退回到事實表中，減少關聯次數，提高查詢效能
多層次維度
多數維度包含不止一個自然層次，如日期維度可以從天的層次到周到月到年的層次。所以在有些情況下，在同一維度中存在不同的層次。
維度表空值屬性
當給定維度行沒有被全部填充時，或者當存在屬性沒有被應用到所有維度行時，將產生空值維度屬性。上述兩種情況，推薦採用描述性字串代替空值，如使用 unknown 或 not applicable 替換空值。
日曆日期維度
在日期維度表中，主鍵的設定不要使用順序生成的id來表示，可以使用更有意義的資料表示，比如將年月日合併起來表示，即YYYYMMDD，或者更加詳細的精度。
2. 維度建模三種模式
1. 星型模式
星形模式(Star Schema)是最常用的維度建模方式。星型模式是以事實表為中心，所有的維度表直接連線在事實表上，像星星一樣。 星形模式的維度建模由一個事實表和一組維表成，且具有以下特點： a. 維表只和事實表關聯，維表之間沒有關聯； b. 每個維表主鍵為單列，且該主鍵放置在事實表中，作為兩邊連線的外來鍵； c. 以事實表為核心，維表圍繞核心呈星形分佈；
2. 雪花模式
雪花模式(Snowflake Schema)是對星形模式的擴充套件。雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規範一些，但是由於這種模型不太容易理解，維護成本比較高，而且效能方面需要關聯多層維表，效能也比星型模型要低。所以一般不是很常用
3．星座模式
星座模式是星型模式延伸而來，星型模式是基於一張事實表的，而星座模式是基於多張事實表的，而且共享維度資訊。 前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。
3. 維度建模過程
我們知道維度建模的表型別有事實表，維度表；模式有星形模型，雪花模型，星座模型這些概念了，但是實際業務中，給了我們一堆資料，我們怎麼拿這些資料進行數倉建設呢，數倉工具箱作者根據自身60多年的實際業務經驗，給我們總結了如下四步，請務必記住！
數倉工具箱中的維度建模四步走：
請牢記以上四步，不管什麼業務，就按照這個步驟來，順序不要搞亂，因為這四步是環環相扣，步步相連。下面詳細拆解下每個步驟怎麼做
1、選擇業務過程
維度建模是緊貼業務的，所以必須以業務為根基進行建模，那麼選擇業務過程，顧名思義就是在整個業務流程中選取我們需要建模的業務，根據運營提供的需求及日後的易擴充套件性等進行選擇業務。比如商城，整個商城流程分為商家端，使用者端，平臺端，運營需求是總訂單量，訂單人數，及使用者的購買情況等，我們選擇業務過程就選擇使用者端的資料，商家及平臺端暫不考慮。業務選擇非常重要，因為後面所有的步驟都是基於此業務資料展開的。
2、宣告粒度
先舉個例子：對於使用者來說，一個使用者有一個身份證號，一個戶籍地址，多個手機號，多張銀行卡，那麼與使用者粒度相同的粒度屬性有身份證粒度，戶籍地址粒度，比使用者粒度更細的粒度有手機號粒度，銀行卡粒度，存在一對一的關係就是相同粒度。為什麼要提相同粒度呢，因為維度建模中要求我們，在同一事實表中，必須具有相同的粒度，同一事實表中不要混用多種不同的粒度，不同的粒度資料建立不同的事實表。並且從給定的業務過程獲取資料時，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始，因為原子粒度能夠承受無法預期的使用者查詢。但是上卷彙總粒度對查詢效能的提升很重要的，所以對於有明確需求的資料，我們建立針對需求的上卷彙總粒度，對需求不明朗的資料我們建立原子粒度。
3、確認維度
維度表是作為業務分析的入口和描述性標識，所以也被稱為資料倉庫的“靈魂”。在一堆的資料中怎麼確認哪些是維度屬性呢，如果該列是對具體值的描述，是一個文字或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性，數倉工具箱中告訴我們牢牢掌握事實表的粒度，就能將所有可能存在的維度區分開，並且要確保維度表中不能出現重複資料，應使維度主鍵唯一
4、確認事實
事實表是用來度量的，基本上都以數量值表示，事實表中的每行對應一個度量，每行中的資料是一個特定級別的細節資料，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。有時候往往不能確定該列資料是事實屬性還是維度屬性。記住最實用的事實就是數值型別和可加類事實。所以可以通過分析該列是否是一種包含多個值並作為計算的參與者的度量，這種情況下該列往往是事實。
三、離線數倉建設實戰
技術是為業務服務的，業務是為公司創造價值的，離開業務的技術是無意義的
1. 業務介紹
需要針對不同需求的使用者開發不同的產品，所以公司內部有很多條業務線，但是對於資料部門來說，所有業務線的資料都是資料來源。對資料的劃分不只是根據業務進行，而是結合資料的屬性。
2. 早期規劃
之前開發是不同業務線對應不同的資料團隊，每個資料團隊互不干擾，這種模式比較簡單，只針對自己的業務線進行數倉建設及報表開發即可。
但是隨著業務的發展，頻繁迭代及跨部門的垂直業務單元越來越多，業務之間的出現耦合情況，這時再採用這種煙囪式開發就出現了問題：
例如許可權問題，公司對資料管理比較嚴格，不同的資料開發組沒有許可權共享資料，需要其他業務線的資料許可權需要上報審批，比較耽誤時間；
還有重複開發問題，不同業務線會出現相同的報表需求，如果每個業務方都開發各自的報表，太浪費資源。
所以對於資料開發而言，需要對各個業務線的資料進行統一管理，所以就有了資料中臺的出現。
3. 資料中臺
我認為資料中臺是根據每個公司具體的業務需求而搭建的，不同的業務，對中臺的理解有所不同。
公司內部開發的敏捷資料中臺，主要從資料技術和計算能力的複用，到資料資產和資料服務的複用，資料中臺以更大價值頻寬，快準精讓資料直接賦能業務。提供一個統一化的管理，打破資料孤島，追溯資料血緣，實現自助化及高複用度。
如下所示：
以上解釋比較抽象，我們以實際專案開發來看下資料中臺的便利性。
比如我們之前做報表開發流程，首先是要資料採集，不同的資料來源通過sqoop等工具採集到大資料平臺，然後進行數倉搭建，最後產出報表資料，放到視覺化系統展示，最終把整個流程寫成指令碼放到排程平臺進行自動化執行。
而有了資料中臺之後就不需要那麼繁瑣，直接進行數倉搭建，產生報表即可，無需將精力過多放在資料來源、視覺化展示及排程。並且可以直觀的檢視資料血緣關係，計算表之間血緣。像下面圖中，表之間的依賴關係很明確：
另一點，資料中臺的異構資料系統可以非常簡單的進行關聯查詢，比如hive的表關聯mysql的表。 可透明遮蔽異構資料系統異構互動方式，輕鬆實現跨異構資料系統透明混算。
異構資料系統原理是資料中臺提供虛擬表到物理表之間的對映,終端使用者無需關心資料的物理存放位置和底層資料來源的特性，可直接操作資料，體驗類似操作一個虛擬資料庫。
資料中臺額外整合視覺化展示，提供一站式資料視覺化解決方案，支援JDBC資料來源和CSV檔案上傳，支援基於資料模型拖拽智慧生成視覺化元件，大屏展示自適應不同大小螢幕。
排程系統是公司內部自寫整合到資料中臺的，在編寫完sql語句之後可以直接進行排程。
4. 數倉建設
到這才真正到數倉建設，為什麼前面我要佔那麼大篇幅去介紹公司業務及所使用的資料中臺系統，因為下面的數倉建設是根據公司的業務發展及現有的資料中臺進行，數倉的建設離不開公司的業務。
數倉建設核心思想：從設計、開發、部署和使用層面，避免重複建設和指標冗餘建設，從而保障資料口徑的規範和統一，最終實現資料資產全鏈路關聯、提供標準資料輸出以及建立統一的資料公共層。
有了核心思想，那怎麼開始數倉建設，有句話說數倉建設者即是技術專家，也是大半個業務專家，所以採用的方式就是需求推動資料建設，並且因為資料中臺，所以各業務知識體系比較集中，各業務資料不再分散，加快了數倉建設速度。
數倉建設主要從兩個方面進行，模型和規範，所有業務進行統一化
模型
所有業務採用統一的模型體系，從而降低研發成本，增強指標複用，並且能保證資料口徑的統一
模型分層
結合公司業務，後期新增需求較多，所以分層不宜過多，並且需要清晰明確各層職責，要保證資料層的穩定又要遮蔽對下游影響，所以採用如下分層結構：
資料流向
遵循模型開發時分層結構，資料從 ods -> dw -> dm ->app 這樣正向流動，可以防止因資料引用不規範而造成資料鏈路混亂及SLA時效難保障等問題，同時保證血緣關係簡潔化，能夠輕易追蹤資料流向。 在開發時應避免以下情況出現：
資料引用鏈路不正確，如 ods -> dm ->app ，出現這種情況說明明細層沒有完全覆蓋資料；如 ods -> dw -> app ，說明輕度彙總層主題劃分未覆蓋全 。減少跨層引用，才能提高中間表的複用度。理想的數倉模型設計應當具備：資料模型可復⽤，完善且規範。 儘量避免一層的表生成當前層的表，如dw層表生成dw層表，這樣會影響ETL效率。 禁止出現反向依賴，如dw表依賴於dm表。
規範
表命名規範
對於ods、dm、app層表名：型別_主題_表含義，如：dm_xxsh_user 對於dw層表名：型別_主題_維度_表含義，如：dw_xxsh_fact_users（事實表）、dw_xxsh_dim_city（維度表）
欄位命名規範
構建詞根，詞根是維度和指標管理的基礎，劃分為普通詞根與專有詞根普通詞根：描述事物的最小單元體，如：sex-性別。 專有詞根：具備行業專屬或公司內部規定的描述體，如：xxsh-公司內部對某個產品的稱呼。
指令碼命名規範
指令碼名稱：指令碼型別.指令碼功用.[庫名].指令碼名稱，如 hive.hive.dm.dm_xxsh_users
指令碼型別主要分為以下三類：常規Hive sql：hive 自定義shell指令碼：sh 自定義Python指令碼：python
指令碼內容規範
#變數的定義要符合python的語法要求
#指定任務負責人
owner="[email protected]"
#指令碼存放目錄/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
資料來源層主要將各個業務資料匯入到大資料平臺，作為業務資料的快照儲存。
資料明細層DW
事實表中的每行對應一個度量，每行中的資料是一個特定級別的細節資料，稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。
維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重複資料，否則和事實表關聯會出現資料發散問題。
有時候往往不能確定該列資料是事實屬性還是維度屬性。記住最實用的事實就是數值型別和可加類事實。所以可以通過分析該列是否是一種包含多個值並作為計算的參與者的度量，這種情況下該列往往是事實；如果該列是對具體值的描述，是一個文字或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性。但是還是要結合業務進行最終判斷是維度還是事實。
資料輕度彙總層DM
此層命名為輕彙總層，就代表這一層已經開始對資料進行彙總，但是不是完全彙總，只是對相同粒度的資料進行關聯彙總，不同粒度但是有關係的資料也可進行彙總，此時需要將粒度通過聚合等操作進行統一。
資料應用層APP
資料應用層的表就是提供給使用者使用的，數倉建設到此就接近尾聲了，接下來就根據不同的需求進行不同的取數，如直接進行報表展示，或提供給資料分析的同事所需的資料，或其他的業務支撐。
6. 總結
一張圖總結下資料倉庫的構建整體流程：
7. 實際生產中注意事項
生產環境中操作不能像我們自己測試時那樣隨意，一不小心都可能造成生產事故。所以每步操作都要十分小心，需全神貫注，管好大腦管住右手。
僅列出以下但不限於以下的注意事項：
請勿操作自己管理及授權表之外的其它庫表； 未經授權，請勿操作生產環境中其他人的指令碼及檔案； 在修改生產環境指令碼前，請務必自行備份到本地； 請確認自己的修改操作能迅速回滾； 生產環境中表名及欄位等所有命名請遵循命名規則。
推薦閱讀：
四、實時計算
實時計算一般都是針對海量資料進行的，並且要求為秒級。由於大資料興起之初，Hadoop並沒有給出實時計算解決方案，隨後Storm，SparkStreaming，Flink等實時計算框架應運而生，而Kafka，ES的興起使得實時計算領域的技術越來越完善，而隨著物聯網，機器學習等技術的推廣，實時流式計算將在這些領域得到充分的應用。
實時計算的三個特徵：
無限資料：無限資料指的是一種不斷增長的，基本上無限的資料集。這些通常被稱為“流資料”，而與之相對的是有限的資料集。
無界資料處理：一種持續的資料處理模式,能夠通過處理引擎重複的去處理上面的無限資料，是能夠突破有限資料處理引擎的瓶頸的。
低延遲：延遲是多少並沒有明確的定義。但我們都知道資料的價值將隨著時間的流逝降低，時效性將是需要持續解決的問題。
現在大資料應用比較火爆的領域，比如推薦系統在實踐之初受技術所限，可能要一分鐘，一小時，甚至更久對使用者進行推薦，這遠遠不能滿足需要，我們需要更快的完成對資料的處理，而不是進行離線的批處理。
1. 實時計算應用場景
隨著實時技術發展趨於成熟，實時計算應用越來越廣泛，以下僅列舉常見的幾種實時計算的應用場景：
1. 實時智慧推薦
智慧推薦會根據使用者歷史的購買或瀏覽行為，通過推薦演算法訓練模型，預測使用者未來可能會購買的物品或喜愛的資訊。對個人來說，推薦系統起著資訊過濾的作用，對Web/App服務端來說，推薦系統起著滿足使用者個性化需求，提升使用者滿意度的作用。推薦系統本身也在飛速發展，除了演算法越來越完善，對時延的要求也越來越苛刻和實時化。利用Flink流計算幫助使用者構建更加實時的智慧推薦系統，對使用者行為指標進行實時計算，對模型進行實時更新，對使用者指標進行實時預測，並將預測的資訊推送給Web/App端，幫助使用者獲取想要的商品資訊，另一方面也幫助企業提升銷售額，創造更大的商業價值。
2. 實時欺詐檢測
在金融領域的業務中，常常出現各種型別的欺詐行為，例如信用卡欺詐，信貸申請欺詐等，而如何保證使用者和公司的資金安全，是近年來許多金融公司及銀行共同面對的挑戰。隨著不法分子欺詐手段的不斷升級，傳統的反欺詐手段已經不足以解決目前所面臨的問題。以往可能需要幾個小時才能通過交易資料計算出使用者的行為指標，然後通過規則判別出具有欺詐行為嫌疑的使用者，再進行案件調查處理，在這種情況下資金可能早已被不法分子轉移，從而給企業和使用者造成大量的經濟損失。而運用Flink流式計算技術能夠在毫秒內就完成對欺詐行為判斷指標的計算，然後實時對交易流水進行實時攔截，避免因為處理不及時而導致的經濟損失。
3. 輿情分析
有的客戶需要做輿情分析，要求所有資料存放若干年，輿情資料每日資料量可能超百萬，年資料量可達到幾十億的資料。而且爬蟲爬過來的資料是輿情，通過大資料技術進行分詞之後得到的可能是大段的網友評論，客戶往往要求對輿情進行查詢，做全文字搜尋，並要求響應時間控制在秒級。爬蟲將資料爬到大資料平臺的Kafka裡，在裡面做Flink流處理，去重去噪做語音分析，寫到ElasticSearch裡。大資料的一個特點是多資料來源，大資料平臺能根據不同的場景選擇不同的資料來源。
4. 複雜事件處理
對於複雜事件處理，比較常見的集中於工業領域，例如對車載感測器，機械裝置等實時故障檢測，這些業務型別通常資料量都非常大，且對資料處理的時效性要求非常高。通過利用Flink提供的CEP進行時間模式的抽取，同時應用Flink的Sql進行事件資料的轉換，在流式系統中構建實施規則引擎，一旦事件觸發報警規則，便立即將告警結果通知至下游通知系統，從而實現對裝置故障快速預警檢測，車輛狀態監控等目的。
5. 實時機器學習
實時機器學習是一個更寬泛的概念，傳統靜態的機器學習主要側重於靜態的模型和歷史資料進行訓練並提供預測。很多時候使用者的短期行為，對模型有修正作用，或者說是對業務判斷有預測作用。對系統來說，需要採集使用者最近的行為並進行特徵工程，然後給到實時機器學習系統進行機器學習。如果動態地實施新規則，或是推出新廣告，就會有很大的參考價值。
2. 實時計算總覽
我們先來看一張大資料平臺的實時架構圖：
資料同步：
在上面這張架構圖中，資料從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. 資料質量及血緣分析：資料質量分為平臺監控和資料監控兩個部分，血緣分析則主要是對實時資料依賴關係、實時任務的依賴關係進行分析。
以上架構只是大資料平臺通用的資料模型，如果要具體的建設，需要考慮以下情況，業務需求需要實時還是準實時即可，資料時效性是秒級還是分鐘級等。
在排程開銷方面，準實時資料是批處理過程，因此仍然需要排程系統支援，排程頻率較高，而實時資料卻沒有排程開銷；
在業務靈活性方面，因為準實時資料是基於 ETL 或 OLAP 引擎實現，靈活性優於基於流計算的方式；
在對資料晚到的容忍度方面，因為準實時資料可以基於一個週期內的資料進行全量計算，因此對於資料晚到的容忍度也是比較高的，而實時資料使用的是增量計算，對於資料晚到的容忍度更低一些；
在適用場景方面，準實時資料主要用於有實時性要求但不太高、涉及多表關聯和業務變更頻繁的場景，如交易型別的實時分析，實時資料則更適用於實時性要求高、資料量大的場景，如實時特徵、流量型別實時分析等場景。
3. 實時架構
在某些場景中，資料的價值隨著時間的推移而逐漸減少。所以在傳統大資料離線數倉的基礎上，逐漸對資料的實時性提出了更高的要求。
於是隨之誕生了大資料實時數倉，並且衍生出了兩種技術架構Lambda和Kappa。
1. Lambda架構
先來看下Lambda架構圖：
資料從底層的資料來源開始，經過Kafka、Flume等資料元件進行收集，然後分成兩條線進行計算：
一條線是進入流式計算平臺（例如 Storm、Flink或者SparkStreaming），去計算實時的一些指標；
另一條線進入批量資料處理離線計算平臺（例如Mapreduce、Hive，Spark SQL），去計算T+1的相關業務指標，這些指標需要隔日才能看見。
為什麼Lambda架構要分成兩條線計算？
假如整個系統只有一個批處理層，會導致使用者必須等待很久才能獲取計算結果，一般有幾個小時的延遲。電商資料分析部門只能檢視前一天的統計分析結果，無法獲取當前的結果，這對於實時決策來說有一個巨大的時間鴻溝，很可能導致管理者錯過最佳決策時機。
Lambda架構屬於較早的一種架構方式，早期的流處理不如現在這樣成熟，在準確性、擴充套件性和容錯性上，流處理層無法直接取代批處理層，只能給使用者提供一個近似結果，還不能為使用者提供一個一致準確的結果。因此Lambda架構中，出現了批處理和流處理並存的現象。
在 Lambda 架構中，每層都有自己所肩負的任務。
1. 批處理層儲存管理主資料集（不可變的資料集）和預先批處理計算好的檢視：
批處理層使用可處理大量資料的分散式處理系統預先計算結果。它通過處理所有的已有歷史資料來實現資料的準確性。這意味著它是基於完整的資料集來重新計算的，能夠修復任何錯誤，然後更新現有的資料檢視。輸出通常儲存在只讀資料庫中，更新則完全取代現有的預先計算好的檢視。
2. 流處理層會實時處理新來的大資料：
流處理層通過提供最新資料的實時檢視來最小化延遲。流處理層所生成的資料檢視可能不如批處理層最終生成的檢視那樣準確或完整，但它們幾乎在收到資料後立即可用。而當同樣的資料在批處理層處理完成後，在速度層的資料就可以被替代掉了。
那Lambda架構有沒有缺點呢？
Lambda架構經歷多年的發展，其優點是穩定，對於實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構支撐了資料行業的早期發展，但是它也有一些致命缺點，並在大資料3.0時代越來越不適應資料分析業務的需求。缺點如下：
使用兩套大資料處理引擎：維護兩個複雜的分散式系統，成本非常高。
批量計算在計算視窗內無法完成：在IOT時代，資料量級越來越大，經常發現夜間只有4、5個小時的時間視窗，已經無法完成白天20多個小時累計的資料，保證早上上班前準時出資料已成為每個大資料團隊頭疼的問題。
資料來源變化都要重新開發，開發週期長：每次資料來源的格式變化，業務的邏輯變化都需要針對ETL和Streaming做開發修改，整體開發週期很長，業務反應不夠迅速。
導致 Lambda 架構的缺點根本原因是要同時維護兩套系統架構：批處理層和速度層。我們已經知道，在架構中加入批處理層是因為從批處理層得到的結果具有高準確性，而加入速度層是因為它在處理大規模資料時具有低延時性。
那我們能不能改進其中某一層的架構，讓它具有另外一層架構的特性呢？
例如，改進批處理層的系統讓它具有更低的延時性，又或者是改進速度層的系統，讓它產生的資料檢視更具準確性和更加接近歷史資料呢？
另外一種在大規模資料處理中常用的架構——Kappa 架構，便是在這樣的思考下誕生的。
2. Kappa架構
Kafka的創始人Jay Kreps認為在很多場景下，維護一套Lambda架構的大資料處理平臺耗時耗力，於是提出在某些場景下，沒有必要維護一個批處理層，直接使用一個流處理層即可滿足需求，即下圖所示的Kappa架構：
這種架構只關注流式計算，資料以流的方式被採集過來，實時計算引擎將計算結果放入資料服務層以供查詢。可以認為Kappa架構是Lambda架構的一個簡化版本，只是去除掉了Lambda架構中的離線批處理部分；
Kappa架構的興起主要有兩個原因：
Kafka不僅起到訊息佇列的作用，也可以儲存更長時間的歷史資料，以替代Lambda架構中批處理層資料倉庫部分。流處理引擎以一個更早的時間作為起點開始消費，起到了批處理的作用。
Flink流處理引擎解決了事件亂序下計算結果的準確性問題。
Kappa架構相對更簡單，實時性更好，所需的計算資源遠小於Lambda架構，隨著實時處理的需求在不斷增長，更多的企業開始使用Kappa架構。但這不意味著kappa架構能夠取代Lambda架構。
Lambda和kappa架構都有各自的適用領域；例如流處理與批處理分析流程比較統一，且允許一定的容錯，用Kappa比較合適，少量關鍵指標（例如交易金額、業績統計等）使用Lambda架構進行批量計算，增加一次校對過程。
還有一些比較複雜的場景，批處理與流處理產生不同的結果（使用不同的機器學習模型，專家系統，或者實時計算難以處理的複雜計算），可能更適合Lambda架構。
4. 實時數倉解決方案
實時數倉分層架構為了避免面向需求響應的煙囪式構建，實時數倉也引入了類似於離線數倉的分層理念，主要是為了提高模型的複用率，同時也要考慮易用性、一致性以及計算成本。
當然實時數倉的分層架構在設計上並不會像離線數倉那麼複雜，避免資料在流轉過程中造成的不必要的延時響應；
實時數倉分層架構圖：
ODS層：以Kafka為支撐，將所有需要實時處理的相關資料放到Kafka佇列中來實現貼源資料層；
DWD層：實時計算訂閱業務資料訊息佇列，然後通過資料清洗、多資料來源join、流式資料與離線維度資訊等的組合，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加資料易用性和複用性，得到最終的實時明細資料；
DIM層：存放用於關聯查詢的維度資訊，可以根據資料現狀來選擇儲存介質，例如使用HBase或者Mysql
DWS層：輕度彙總層是為了便於面向AdHoc查詢或者Olap分析構建的輕度彙總結果集合，適合資料維度、指標資訊比較多的情況，為了方便根據自定義條件的快速篩選和指標聚合，推薦使用MPP型別資料庫進行儲存，此層可視場景情況決定是否構建；
APP層：面向實時資料場景需求構建的高度彙總層，可以根據不同的資料應用場景決定使用儲存介質或者引擎；例如面向業務歷史明細、BI支援等Olap分析場景，可以使用Druid、Greenplum，面向實時監控大屏、高併發彙總指標等需求，可以使用KV模式的HBase；資料量較小的時候，也可以使用Mysql來進行儲存。
這裡要注意下，其實APP層已經脫離了數倉，這裡雖然作為了數倉的獨立分層，但是實際APP層的資料已經分佈儲存在各種介質中用於使用。
基於Flink構建的實時數倉
隨著業務場景的豐富，更多的實時需求不斷湧現，在追求實時任務高吞吐低延遲的同時，對計算過程中間狀態管理，靈活時間視窗支援，以及 exactly once 語義保障的訴求也越來越多。
為什麼選擇Flink實時計算平臺？之所以選擇用Flink替代原有Storm、SparkStreaming是基於以下原因考慮的，這也是實時數倉關注的核心問題：
高吞吐、低延時；
端到端的 Exactly-once，保證了資料的準確性；
可容錯的狀態管理，實時數倉裡面會進行很多的聚合計算，這些都需要對於狀態進行訪問和管理；
豐富的API，對Streaming/Table/SQL支援良好，支援UDF、流式join、時間視窗等高階用法；
完善的生態體系，實時數倉的構建會涉及多種儲存，Flink在這方面的支援也比較完善。
基於Flink的實時數倉資料流轉過程:
資料在實時數倉中的流轉過程，實際和離線數倉非常相似，只是由Flink替代Hive作為了計算引擎，把儲存由HDFS更換成了Kafka，但是模型的構建思路與流轉過程並沒有發生變化。
本文件總共九章，因字數限制，本文只發了前四章，此數倉建設完整版文件：
本文來自微信公眾號：五分鐘學大資料，轉載請在公眾號後臺獲取作者微信進行授權