數倉建設保姆級教程，離線和實時一網打盡(理論+實戰)

本文大綱：

因内容較多，帶目錄的PDF檢視是比較友善的：

數倉建設保姆級教程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表。

規範
表命名規範
1. 對于ods、dm、app層表名：類型_主題_表含義，如：dm_xxsh_user
2. 對于dw層表名：類型_主題_次元_表含義，如：dw_xxsh_fact_users（事實表）、dw_xxsh_dim_city（次元表）
字段命名規範

建構詞根，詞根是次元和名額管理的基礎，劃分為普通詞根與專有詞根
1. 普通詞根：描述事物的最小單元體，如：sex-性别。
2. 專有詞根：具備行業專屬或公司内部規定的描述體，如：xxsh-公司内部對某個産品的稱呼。
腳本命名規範

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

腳本類型主要分為以下三類：
1. 正常Hive sql：hive
2. 自定義shell腳本：sh
3. 自定義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架構圖：

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架構

這種架構隻關注流式計算，資料以流的方式被采集過來，實時計算引擎将計算結果放入資料服務層以供查詢。可以認為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，但是模型的建構思路與流轉過程并沒有發生變化。

本文檔總共九章，因字數限制，本文隻發了前四章，此數倉建設完整版文檔：

本文來自微信公衆号：五分鐘學大資料，轉載請在公衆号背景擷取作者微信進行授權