檔案大綱
一、數倉基本概念
1、資料倉庫架構
我們在談數倉之前，為了讓大家有直觀的認識，先來談數倉架構，“架構”是什么？這個問題從來就沒有一個準確的答案，這里我們參考一段話：在軟體行業，一種被普遍接受的架構定義是指系統的一個或多個結構，結構中包括軟體的構建（構建是指軟體的設計與實作），構建的外部可以看到屬性以及它們之間的相互關系，
這里參考此定義，把資料倉庫架構理解成構成資料倉庫的組件及其之間的關系，畫出下面的數倉架構圖：
數倉架構
上圖中顯示的整個資料倉庫環境包括操作型系統和資料倉庫系統兩大部分，操作型系統的資料由各種形式的業務資料組成，這些資料經過抽取、轉換和裝載（ETL）程序進入資料倉庫系統，
任何事物都是隨著時間的演進變得越來越完善，當然也是越來越復雜，數倉也不例外，在資料倉庫技術演化程序中，產生了幾種主要的架構方法，包括資料集市架構、Inmon企業資訊工廠架構、Kimball資料倉庫架構、混合型資料倉庫架構，這幾種架構我們后面再講，接下來看下數倉的基本概念，
2、資料倉庫概念
英文名稱為Data Warehouse，可簡寫為DW或DWH，資料倉庫的目的是構建面向分析的集成化資料環境，為企業提供決策支持（Decision Support），它出于分析性報告和決策支持目的而創建，
資料倉庫本身并不“生產”任何資料，同時自身也不需要“消費”任何的資料，資料來源于外部，并且開放給外部應用，這也是為什么叫“倉庫”，而不叫“工廠”的原因，
1) 基本特征
資料倉庫是面向主題的、集成的、非易失的和時變的資料集合，用以支持管理決策，
①面向主題:
傳統資料庫中，最大的特點是面向應用進行資料的組織，各個業務系統可能是相互分離的，而資料倉庫則是面向主題的，主題是一個抽象的概念，是較高層次上企業資訊系統中的資料綜合、歸類并進行分析利用的抽象，在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析物件，
②集成性:
通過對分散、獨立、異構的資料庫資料進行抽取、清理、轉換和匯總便得到了資料倉庫的資料，這樣保證了資料倉庫內的資料關于整個企業的一致性，
資料倉庫中的綜合資料不能從原有的資料庫系統直接得到，因此在資料進入資料倉庫之前，必然要經過統一與綜合，這一步是資料倉庫建設中最關鍵、最復雜的一步，所要完成的作業有：
-
要統一源資料中所有矛盾之處，如欄位的同名異義、異名同義、單位不統一、字長不一致，等等，
-
進行資料綜合和計算，資料倉庫中的資料綜合作業可以在從原有資料庫抽取資料時生成，但許多是在資料倉庫內部生成的，即進入資料倉庫以后進行綜合生成的，
下圖說明一個保險公司綜合資料的簡單處理程序，其中資料倉庫中與“保險” 主題有關的資料來自于多個不同的操作型系統，這些系統內部資料的命名可能不同，資料格式也可能不同，把不同來源的資料存盤到資料倉庫之前，需要去除這些不一致，
數倉主題
③非易失性（不可更新性）:
資料倉庫的資料反映的是一段相當長的時間內歷史資料的內容，是不同時點的資料庫快照的集合，以及基于這些快照進行統計、綜合和重組的匯出資料，
資料非易失性主要是針對應用而言，資料倉庫的用戶對資料的操作大多是資料查詢或比較復雜的挖掘，一旦資料進入資料倉庫以后，一般情況下被較長時間保留，資料倉庫中一般有大量的查詢操作，但修改和洗掉操作很少，因此，資料經加工和集成進入資料倉庫后是極少更新的，通常只需要定期的加載和更新，
④時變性:
資料倉庫包含各種粒度的歷史資料，資料倉庫中的資料可能與某個特定日期、星期、月份、季度或者年份有關，資料倉庫的目的是通過分析企業過去一段時間業務的經營狀況，挖掘其中隱藏的模式，雖然資料倉庫的用戶不能修改資料，但并不是說資料倉庫的資料是永遠不變的，分析的結果只能反映過去的情況，當業務變化后，挖掘出的模式會失去時效性，因此資料倉庫的資料需要更新，以適應決策的需要，從這個角度講，資料倉庫建設是一個專案，更是一個程序，資料倉庫的資料隨時間的變化表現在以下幾個方面：
-
資料倉庫的資料時限一般要遠遠長于操作型資料的資料時限，
-
操作型系統存盤的是當前資料，而資料倉庫中的資料是歷史資料，
-
資料倉庫中的資料是按照時間順序追加的，它們都帶有時間屬性，
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）資料集市架構
資料集市是按主題域組織的資料集合，用于支持部門級的決策，有兩種型別的資料集市：獨立資料集市和從屬資料集市，
① 獨立資料集市
獨立資料集市集中于部門所關心的單一主題域，資料以部門為基礎部署，無須考慮企業級別的資訊共享與集成，例如，制造部門、人力資源部門和其他部門都各自有他們自己的資料集市，
優點：因為一個部門的業務相對于整個企業要簡單，資料量也小得多，所以部門的獨立資料集市具有周期短、見效快的特點，
缺點：
-
從業務角度看，當部門的分析需求擴展，或者需要分析跨部門或跨主題域的資料時，獨立資料市場會顯得力不從心，
-
當資料存在歧義，比如同一個產品，在A部門和B部門的定義不同時，將無法在部門間進行資訊比較，
-
每個部門使用不同的技術，建立不同的ETL的程序，處理不同的事務系統，而在多個獨立的資料集市之間還會存在資料的交叉與重疊，甚至會有資料不一致的情況，
②從屬資料集市
從屬資料集市的資料來源于資料倉庫，資料倉庫里的資料經過整合、重構、匯總后傳遞給從屬資料集市，
建立從屬資料集市的好處主要有：
-
性能：當資料倉庫的查詢性能出現問題，可以考慮建立幾個從屬資料集市，將查詢從資料倉庫移出到資料集市，
-
安全：每個部門可以完全控制他們自己的資料，
-
資料一致：因為每個資料集市的資料來源都是同一個資料倉庫，有效消除了資料不一致的情況，
2）Inmon企業工廠架構
上圖的前兩步不過多介紹，直接從第三步開始，
企業級資料倉庫：是該架構中的核心組件，正如Inmon資料倉庫所定義的，企業級資料倉庫是一個細節資料的集成資源庫，其中的資料以最低粒度級別被捕獲，存盤在滿足三范式設計的關系資料庫中，
部門級資料集市：是面向主題資料的部門級視圖，資料從企業級資料倉庫獲取，資料在進入部門資料集市時可能進行聚合，資料集市使用多維模型設計，用于資料分析，重要的一點是，所有的報表工具、BI工具或其他資料分析應用都從資料集市查詢資料，而不是直接查詢企業級資料倉庫，
3）Kimball資料倉庫架構
對比上一張圖可以看到，Kimball與Inmon兩種架構的主要區別在于核心資料倉庫的設計和建立，
Kimball的資料倉庫包含高粒度的企業資料，使用多維模型設計，這也意味著資料倉庫由星型模式的維度表和事實表構成，分析系統或報表工具可以直接訪問多維資料倉庫里的資料，
在此架構中的資料集市也與Inmon中的不同，這里的資料集市是一個邏輯概念，只是多維資料倉庫中的主題域劃分，并沒有自己的物理存盤，也可以說是虛擬的資料集市，
4）混合型資料倉庫架構
所謂的混合型結構，指的是在一個資料倉庫環境中，聯合使用Inmon和Kimball兩種架構，
從架構圖可以看到，這種架構將Inmon方法中的資料集市部分替換成了一個多維資料倉庫，而資料集市則是多維資料倉庫上的邏輯視圖，
使用這種架構的好處是：既可以利用規范化設計消除資料冗余，保證資料的粒度足夠細；又可以利用多維結構更靈活地在企業級實作報表和分析，
7、資料倉庫元資料的管理
元資料（Meta Date），主要記錄資料倉庫中模型的定義、各層級間的映射關系、監控資料倉庫的資料狀態及ETL的任務運行狀態，一般會通過元資料資料庫（Metadata Repository）來統一地存盤和管理元資料，其主要目的是使資料倉庫的設計、部署、操作和管理能達成協同和一致，
元資料是資料倉庫管理系統的重要組成部分，元資料管理是企業級資料倉庫中的關鍵組件，貫穿資料倉庫構建的整個程序，直接影響著資料倉庫的構建、使用和維護，
-
構建資料倉庫的主要步驟之一是ETL，這時元資料將發揮重要的作用，它定義了源資料系統到資料倉庫的映射、資料轉換的規則、資料倉庫的邏輯結構、資料更新的規則、資料匯入歷史記錄以及裝載周期等相關內容，資料抽取和轉換的專家以及資料倉庫管理員正是通過元資料高效地構建資料倉庫，
-
用戶在使用資料倉庫時，通過元資料訪問資料，明確資料項的含義以及定制報表，
-
資料倉庫的規模及其復雜性離不開正確的元資料管理，包括增加或移除外部資料源，改變資料清洗方法，控制出錯的查詢以及安排備份等，
元資料可分為技術元資料和業務元資料，技術元資料為開發和管理資料倉庫的IT 人員使用，它描述了與資料倉庫開發、管理和維護相關的資料，包括資料源資訊、資料轉換描述、資料倉庫模型、資料清洗與更新規則、資料映射和訪問權限等，而業務元資料為管理層和業務分析人員服務，從業務角度描述資料，包括商務術語、資料倉庫中有什么資料、資料的位置和資料的可用性等，幫助業務人員更好地理解資料倉庫中哪些資料是可用的以及如何使用，
由上可見，元資料不僅定義了資料倉庫中資料的模式、來源、抽取和轉換規則等，而且是整個資料倉庫系統運行的基礎，元資料把資料倉庫系統中各個松散的組件聯系起來，組成了一個有機的整體，
8、數倉常見術語決議
本小節結構如下圖所示：
1）數倉名詞解釋
① 物體
物體是指依附的主體，就是我們分析的一個物件，比如我們分析商品的銷售情況，如華為手機近半年的銷售量是多少，那華為手機就是一個物體；我們分析用戶的活躍度，用戶就是一個物體，當然物體也可以現實中不存在的，比如虛擬的業務物件，活動，會員等都可看做一個物體，
物體的存在是為了業務分析，作為分析的一個篩選的維度，擁有描述自己的屬性，本身具有可分析的價值，
②維度
維度就是看待問題的角度，分析業務資料，從什么角度分析，就建立什么樣的維度，所以維度就是要對資料進行分析時所用的一個量，比如你要分析產品銷售情況，你可以選擇按商品類別來進行分析，這就構成一個維度，把所有商品類別集合在一起，就構成了維度表，
③度量
度量是業務流程節點上的一個數值，比如銷量，價格，成本等等，
事實表中的度量可分為三類：完全可加，半可加，不可加，
-
完全可加的度量是最靈活，最有用的，比如說銷量，銷售額等，可進行任意維度匯總；
-
半可加的度量可以對某些維度匯總，但不能對所有維度匯總，差額是常見的半可加度量，它除了時間維度外，可以跨所有維度進行加法操作；
-
還有一種是完全不可加的，例如：比率，對于這類非可加度量，一種好的方法是，盡可能存盤非可加度量的完全可加分量，并在計算出最終的非可加事實前，將這些分量匯總到最終的結果集中，
④粒度
粒度就是業務流程中對度量的單位，比如商品是按件記錄度量，還是按批記錄度量，
在數倉建設中，我們說這是用戶粒度的事實表，那么表中每行資料都是一個用戶，無重復用戶；例如還有銷售粒度的表，那么表中每行都是一條銷售記錄，
選擇合適的粒度級別是資料倉庫建設好壞的重要關鍵內容，在設計資料粒度時，通常需重點考慮以下因素：
-
要接受的分析型別、可接受的資料最低粒度和能存盤的資料量；
-
粒度的層次定義越高，就越不能在該倉庫中進行更細致的分析；
-
如果存盤資源有一定的限制，就只能采用較高的資料粒度劃分；
-
資料粒度劃分策略一定要保證：資料的粒度確實能夠滿足用戶的決策分析需要，這是資料粒度劃分策略中最重要的一個準則，
⑤口徑
口徑就是取數邏輯（如何取數的），比如要取的數是10歲以下兒童中男孩的平均身高，這就是統計的口徑，
⑥指標
指標是口徑的衡量值，也就是最后的結果，比如最近七天的訂單量，一個促銷活動的購買轉化率等，
一個指標具體到計算實施，主要有以下幾部分組成：
-
指標加工邏輯，比如count ,sum, avg，
-
維度，比如按部門、地域進行指標統計，對應sql中的group by，
-
業務限定/修飾詞，比如以不同的支付渠道來算對應的指標，微信支付的訂單退款率，支付寶支付的訂單退款率 ，對應sql中的where，
除此之外，指標本身還可以衍生、派生出更多的指標，基于這些特點，可以將指標進行分類：
-
原子指標：基本業務事實，沒有業務限定、沒有維度，比如訂單表中的訂單量、訂單總金額都算原子指標；
業務方更關心的指標，是有實際業務含義，可以直接取資料的指標，比如店鋪近1天訂單支付金額就是一個派生指標，會被直接在產品上展示給商家看，
但是這個指標卻不能直接從數倉的統一中間層里取數（因為沒有現成的事實欄位，數倉提供的一般都是大寬表），需要有一個橋梁連接數倉中間層和業務方的指標需求，于是便有了派生指標，
-
派生指標：維度+修飾詞+原子指標，店鋪近1天訂單支付金額中店鋪是維度，近1天是一個時間型別的修飾詞，支付金額是一個原子指標；
維度：觀察各項指標的角度；
修飾詞：維度的一個或某些值，比如維度性別下，男和女就是2種修飾詞，
-
衍生指標：比如某一個促銷活動的轉化率就是衍生指標，因為需要促銷投放人數指標和促銷訂單數指標進行計算得出，
⑦標簽
標簽是人為設定的、根據業務場景需求，對目標物件運用一定的演算法得到的高度精煉的特征標識，可見標簽是經過人為再加工后的結果，如網紅、白富美、蘿莉，對于有歧義的標簽，我們內部可進行標簽區分，比如：蘋果，我們可以定義蘋果指的是水果，蘋果手機才指的是手機，
⑧自然鍵
由現實中已經存在的屬性組成的鍵，它在業務概念中是唯一的，并具有一定的業務含義，比如商品ID，員工ID，
以數倉角度看，來自于業務系統的識別符號就是自然鍵，比如業務庫中員工的編號，
⑨持久鍵
保持永久性不會發生變化，有時也被叫做超自然持久鍵，比如身份證號屬于持久鍵，
自然鍵和持久鍵區別：舉個例子就明白了，比如說公司員工離職之后又重新入職，他的自然鍵也就是員工編號發生了變化，但是他的持久鍵身份證號是不變的，
⑩代理鍵
就是不具有業務含義的鍵，代理鍵有許多其他的稱呼：無意義鍵、整數鍵、非自然鍵、人工鍵、合成鍵等，
代理鍵就是簡單的以按照順序序列生產的整數表示，產品行的第1行代理鍵為1，則下一行的代理鍵為2，如此進行，代理鍵的作用僅僅是連接維度表和事實表，
?退化維度
退化維度，就是那些看起來像是事實表的一個維度關鍵字，但實際上并沒有對應的維度表，就是維度屬性存盤到事實表中，這種存盤到事實表中的維度列被稱為退化維度，與其他存盤在維表中的維度一樣，退化維度也可以用來進行事實表的過濾查詢、實作聚合操作等，
那么究竟怎么定義退化維度呢？比如說訂單id，這種量級很大的維度，沒必要用一張維度表來進行存盤，而我們進行資料查詢或者資料過濾的時候又非常需要，所以這種就冗余在事實表里面，這種就叫退化維度，citycode這種我們也會冗余在事實表里面，但是它有對應的維度表，所以它不是退化維度，
?下鉆
這是在資料分析中常見的概念，下鉆可以理解成增加維的層次，從而可以由粗粒度到細粒度來觀察資料，比如對產品銷售情況分析時，可以沿著時間維從年到月到日更細粒度的觀察資料，從年的維度可以下鉆到月的維度、日的維度等，
?上卷
知道了下鉆，上卷就容易理解了，它倆是相逆的操作，所以上卷可以理解為刪掉維的某些層，由細粒度到粗粒度觀察資料的操作或沿著維的層次向上聚合匯總資料，
?資料集市
資料集市（Data Mart），也叫資料市場，資料集市就是滿足特定的部門或者用戶的需求，按照多維的方式進行存盤，包括定義維度、需要計算的指標、維度的層次等，生成面向決策分析需求的資料立方體，其實就是從資料倉庫中抽取出來的一個小合集，
2）數倉名詞之間關系
①物體表，事實表，維度表之間的關系
在Kimball維度建模中有維度與事實，在Inmon范式建模中有物體與關系，如果我們分開兩種建模方式看這些概念比較容易理解，但是目前也出現了不少混合建模方式，兩種建模方式結合起來看，這些概念是不是容易記憶混亂，尤其事實表和物體表，它們之間到底有怎樣區別與聯系，先看下它們各自概念：
-
維度表：維度表可以看成是用戶用來分析一個事實的視窗，它里面的資料應該是對事實的各個方面描述，比如時間維度表，地域維度表，維度表是事實表的一個分析角度，
-
事實表：事實表其實就是通過各種維度和一些指標值的組合來確定一個事實的，比如通過時間維度，地域組織維度，指標值可以去確定在某時某地的一些指標值怎么樣的事實，事實表的每一條資料都是幾條維度表的資料和指標值交匯而得到的，
-
物體表：物體表就是一個實際物件的表，物體表放的資料一定是一條條客觀存在的事物資料，比如說各種商品，它就是客觀存在的，所以可以將其設計一個物體表，實時表只描述各個事物，并不存在具體的事實，所以也有人稱物體表是無事實的事實表，
舉個例子：比如說手機商場中有蘋果手機，華為手機等各品牌各型號的手機，這些資料可以組成一個手機物體表，但是表中沒有可度量的資料，某天蘋果手機賣了15臺，華為手機賣了20臺，這些手機銷售資料屬于事實，組成一個事實表，這樣就可以使用日期維度表和地域維度表對這個事實表進行各種維度分析，
②指標與標簽的區別
-
概念不同
指標是用來定義、評價和描述特定事物的一種標準或方式，比如：新增用戶數、累計用戶數、用戶活躍率等是衡量用戶發展情況的指標；
標簽是人為設定的、根據業務場景需求，對目標物件運用一定的演算法得到的高度精煉的特征標識，可見標簽是經過人為再加工后的結果，如網紅、白富美、蘿莉，
-
構成不同
指標名稱是對事物質與量兩方面特點的命名；指標取值是指標在具體時間、地域、條件下的數量表現，如人的體重，指標名稱是體重，指標的取值就是120斤；
標簽名稱通常都是形容詞或形容詞+名詞的結構，標簽一般是不可量化的，通常是孤立的，除了基礎類標簽，通過一定演算法加工出來的標簽一般都沒有單位和量綱，如將超過200斤的稱為大胖子，
-
分類不同
對指標的分類：
按照指標計算邏輯，可以將指標分為原子指標、派生指標、衍生指標三種型別；
按照對事件描述內容的不同，分為程序性指標和結果性指標；
對標簽的分類：
按照標簽的變化性分為靜態標簽和動態標簽；
按照標簽的指代和評估指標的不同，可分為定性標簽和定量標簽；
指標最擅長的應用是監測、分析、評價和建模，
標簽最擅長的應用是標注、刻畫、分類和特征提取，
特別需要指出的是，由于對結果的標注也是一種標簽，所以在自然語言處理和機器學習相關的演算法應用場景下，標簽對于監督式學習有重要價值，只是單純的指標難以做到的，而指標在任務分配、績效管理等領域的作用，也是標簽無法做到的，
③維度和指標區別與聯系
維度就是資料的觀察角度，即從哪個角度去分析問題，看待問題，
指標就是從維度的基礎上去衡算這個結果的值，
維度一般是一個離散的值，比如時間維度上每一個獨立的日期或地域，因此統計時，可以把維度相同記錄的聚合在一起，應用聚合函式做累加、均值、最大值、最小值等聚合計算，
指標就是被聚合的通計算，即聚合運算的結果，一般是一個連續的值，
④自然鍵與代理鍵在數倉的使用區別
數倉工具箱中說維度表的唯一主鍵應該是代理鍵而不應該是自然鍵，有時建模人員不愿意放棄使用自然鍵，因為他們希望與操作型代碼查詢事實表，而不希望與維度表做連接操作，然而，應該避免使用包含業務含義的多維鍵，因為不管我們做出任何假設最終都可能變得無效，因為我們控制不了業務庫的變動，
所以資料倉庫中維度表與事實表的每個連接應該基于無實際含義的整數代理鍵，避免使用自然鍵作為維度表的主鍵，
⑤資料集市和資料倉庫的關系
資料集市是企業級資料倉庫的一個子集，他主要面向部門級業務，并且只面向某個特定的主題，為了解決靈活性和性能之間的矛盾，資料集市就是資料倉庫體系結構中增加的一種小型的部門或作業組級別的資料倉庫，資料集市存盤為特定用戶預先計算好的資料，從而滿足用戶對性能的需求，資料集市可以在一定程度上緩解訪問資料倉庫的瓶頸，
資料集市和資料倉庫的主要區別：資料倉庫是企業級的，能為整個企業各個部門的運行提供決策支持手段；而資料集市則是一種微型的資料倉庫,它通常有更少的資料,更少的主題區域,以及更少的歷史資料,因此是部門級的，一般只能為某個區域范圍內的管理人員服務，因此也稱之為部門級資料倉庫，
二、離線數倉建設核心
資料倉庫的核心是展現層和提供優質的服務，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） 層，
①資料明細層：DWD（Data Warehouse Detail）
該層一般保持和 ODS 層一樣的資料粒度，并且提供一定的資料質量保證，DWD 層要做的就是將資料清理、整合、規范化、臟資料、垃圾資料、規范不一致的、狀態定義不一致的、命名不規范的資料都會被處理，
同時，為了提高資料明細層的易用性，該層會采用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯，
另外，在該層也會做一部分的資料聚合，將相同主題的資料匯集到一張表中，提高資料的可用性 ，
②資料中間層：DWM（Data WareHouse Middle）
該層會在 DWD 層的資料基礎上，資料做輕度的聚合操作，生成一系列的中間表，提升公共指標的復用性，減少重復加工，
直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標，
在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統計指標，會存在計算量太大并且維度太少的問題，因此一般的做法是，在 DWM 層先計算出多個小的中間表，然后再拼接成一張 DWS 的寬表，由于寬和窄的界限不易界定，也可以去掉 DWM 這一層，只留 DWS 層，將所有的資料再放在 DWS 亦可，
③資料服務層：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）維度建模中表的型別
維度建模分為兩種表：事實表和維度表：
-
事實表：必然存在的一些資料，像采集的日志檔案，訂單表，都可以作為事實表
特征：是一堆主鍵的集合，每個主鍵對應維度表中的一條記錄， 客觀存在的，根據主題確定出需要使用的資料
-
維度表：維度就是所分析的資料的一個量，維度表就是以合適的角度來創建的表，分析問題的一個角度：時間、地域、終端、用戶等角度，
①事實表
發生在現實世界中的操作型事件，其所產生的可度量數值，存盤在事實表中，從最低的粒度級別來看，事實表行對應一個度量事件，反之亦然，
事實表表示對分析主題的度量，比如一次購買行為我們就可以理解為是一個事實，
事實與維度
圖中的訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄，事實表的特征：表里沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄，事實表包含了與各維度表相關聯的外鍵，可與維度表關聯，事實表的度量通常是數值型別，且記錄數會不斷增加，表資料規模迅速增長，
明細表（寬表）：
事實表的資料中，有些屬性共同組成了一個欄位（糅合在一起），比如年月日時分秒構成了時間,當需要根據某一屬性進行分組統計的時候，需要截取拼接之類的操作，效率極低，如：
為了分析方便，可以事實表中的一個欄位切割提取多個屬性出來構成新的欄位，因為欄位變多了，所以稱為寬表，原來的成為窄表，
將上述的local_time欄位擴展為如下6個欄位：
又因為寬表的資訊更加清晰明細，所以也可以稱之為明細表，
事實表種類
事實表分為以下6類：
-
事務事實表
-
周期快照事實表
-
累積快照事實表
-
無事實的事實表
-
聚集事實表
-
合并事實表
簡單解釋下每種表的概念：
-
事務事實表
表中的一行對應空間或時間上某點的度量事件，就是一行資料中必須有度量欄位，什么是度量，就是指標，比如說銷售金額，銷售數量等這些可加的或者半可加就是度量值，另一點就是事務事實表都包含一個與維度表關聯的外鍵，并且度量值必須和事務粒度保持一致，
-
周期快照事實表
顧名思義，周期事實表就是每行都帶有時間值欄位，代表周期，通常時間值都是標準周期，如某一天，某周，某月等，粒度是周期，而不是個體的事務，也就是說一個周期快照事實表中資料可以是多個事實，但是它們都屬于某個周期內，
-
累計快照事實表
周期快照事實表是單個周期內資料，而累計快照事實表是由多個周期資料組成，每行匯總了程序開始到結束之間的度量，每行資料相當于管道或作業流，有事件的起點，程序，終點，并且每個關鍵步驟都包含日期欄位，如訂單資料，累計快照事實表的一行就是一個訂單，當訂單產生時插入一行，當訂單發生變化時，這行就被修改，
-
無事實的事實表
我們以上討論的事實表度量都是數字化的，當然實際應用中絕大多數都是數字化的度量，但是也可能會有少量的沒有數字化的值但是還很有價值的欄位，無事實的事實表就是為這種資料準備的，利用這種事實表可以分析發生了什么，
-
聚集事實表
聚集，就是對原子粒度的資料進行簡單的聚合操作，目的就是為了提高查詢性能，如我們需求是查詢全國所有門店的總銷售額，我們原子粒度的事實表中每行是每個分店每個商品的銷售額，聚集事實表就可以先聚合每個分店的總銷售額，這樣匯總所有門店的銷售額時計算的資料量就會小很多，
-
合并事實表
這種事實表遵循一個原則，就是相同粒度，資料可以來自多個程序，但是只要它們屬于相同粒度，就可以合并為一個事實表，這類事實表特別適合經常需要共同分析的多程序度量，
②維度表
每個維度表都包含單一的主鍵列，維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度表行的描述環境應與事實表行完全對應，維度表通常比較寬，是扁平型非規范表，包含大量的低粒度的文本屬性，
維度表示你要對資料進行分析時所用的一個量，比如你要分析產品銷售情況， 你可以選擇按類別來進行分析，或按區域來分析，每個類別就構成一個維度，上圖中的用戶表、商家表、時間表這些都屬于維度表，這些表都有一個唯一的主鍵，然后在表中存放了詳細的資料資訊，
總的說來，在資料倉庫中不需要嚴格遵守規范化設計原則，因為資料倉庫的主導功能就是面向分析，以查詢為主，不涉及資料更新操作，事實表的設計是以能夠正確記錄歷史資訊為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則，
-
維度表結構
維度表謹記一條原則，包含單一主鍵列，但有時因業務復雜，也可能出現聯合主鍵，請盡量避免，如果無法避免，也要確保必須是單一的，這很重要，如果維表主鍵不是單一，和事實表關聯時會出現資料發散，導致最后結果可能出現錯誤，
維度表通常比較寬，包含大量的低粒度的文本屬性，
-
跨表鉆取
跨表鉆取意思是當每個查詢的行頭都包含相同的一致性屬性時，使不同的查詢能夠針對兩個或更多的事實表進行查詢
鉆取可以改變維的層次，變換分析的粒度，它包括上鉆/下鉆：
上鉆（roll-up）：上卷是沿著維的層次向上聚集匯總資料，例如，對產品銷售資料，沿著時間維上卷，可以求出所有產品在所有地區每月（或季度或年或全部）的銷售額，
下鉆（drill-down）：下鉆是上鉆的逆操作，它是沿著維的層次向下，查看更詳細的資料，
-
退化維度
退化維度就是將維度退回到事實表中，因為有時維度除了主鍵沒有其他內容，雖然也是合法維度鍵，但是一般都會退回到事實表中，減少關聯次數，提高查詢性能
-
多層次維度
多數維度包含不止一個自然層次，如日期維度可以從天的層次到周到月到年的層次，所以在有些情況下，在同一維度中存在不同的層次，
-
維度表空值屬性
當給定維度行沒有被全部填充時，或者當存在屬性沒有被應用到所有維度行時，將產生空值維度屬性，上述兩種情況，推薦采用描述性字串代替空值，如使用 unknown 或 not applicable 替換空值，
-
日歷日期維度
在日期維度表中，主鍵的設定不要使用順序生成的id來表示，可以使用更有意義的資料表示，比如將年月日合并起來表示，即YYYYMMDD，或者更加詳細的精度，
2）維度建模三種模式
①星型模式
星形模式(Star Schema)是最常用的維度建模方式，星型模式是以事實表為中心，所有的維度表直接連接在事實表上，像星星一樣，星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：a. 維表只和事實表關聯，維表之間沒有關聯；b. 每個維表主鍵為單列，且該主鍵放置在事實表中，作為兩邊連接的外鍵；c. 以事實表為核心，維表圍繞核心呈星形分布；
②雪花模式
雪花模式(Snowflake Schema)是對星形模式的擴展，雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規范一些，但是由于這種模型不太容易理解，維護成本比較高，而且性能方面需要關聯多層維表，性能也比星型模型要低，所以一般不是很常用
雪花模式
③星座模式
星座模式是星型模式延伸而來，星型模式是基于一張事實表的，而星座模式是基于多張事實表的，而且共享維度資訊，前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到，在業務發展后期，絕大部分維度建模都采用的是星座模式，
星座模型
3）維度建模程序
我們知道維度建模的表型別有事實表，維度表；模式有星形模型，雪花模型，星座模型這些概念了，但是實際業務中，給了我們一堆資料，我們怎么拿這些資料進行數倉建設呢，數倉工具箱作者根據自身60多年的實際業務經驗，給我們總結了如下四步，請務必記住！
數倉工具箱中的維度建模四步走：
維度建模四步走
請牢記以上四步，不管什么業務，就按照這個步驟來，順序不要搞亂，因為這四步是環環相扣，步步相連，下面詳細拆解下每個步驟怎么做
①選擇業務程序
維度建模是緊貼業務的，所以必須以業務為根基進行建模，那么選擇業務程序，顧名思義就是在整個業務流程中選取我們需要建模的業務，根據運營提供的需求及日后的易擴展性等進行選擇業務，比如商城，整個商城流程分為商家端，用戶端，平臺端，運營需求是總訂單量，訂單人數，及用戶的購買情況等，我們選擇業務程序就選擇用戶端的資料，商家及平臺端暫不考慮，業務選擇非常重要，因為后面所有的步驟都是基于此業務資料展開的，
②宣告粒度
先舉個例子：對于用戶來說，一個用戶有一個身份證號，一個戶籍地址，多個手機號，多張銀行卡，那么與用戶粒度相同的粒度屬性有身份證粒度，戶籍地址粒度，比用戶粒度更細的粒度有手機號粒度，銀行卡粒度，存在一對一的關系就是相同粒度，為什么要提相同粒度呢，因為維度建模中要求我們，在同一事實表中，必須具有相同的粒度，同一事實表中不要混用多種不同的粒度，不同的粒度資料建立不同的事實表，并且從給定的業務程序獲取資料時，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始，因為原子粒度能夠承受無法預期的用戶查詢，但是上卷匯總粒度對查詢性能的提升很重要的，所以對于有明確需求的資料，我們建立針對需求的上卷匯總粒度，對需求不明朗的資料我們建立原子粒度，
③確認維度
維度表是作為業務分析的入口和描述性標識，所以也被稱為資料倉庫的“靈魂”，在一堆的資料中怎么確認哪些是維度屬性呢，如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性，數倉工具箱中告訴我們牢牢掌握事實表的粒度，就能將所有可能存在的維度區分開，并且要確保維度表中不能出現重復資料，應使維度主鍵唯一，
④確認事實
事實表是用來度量的，基本上都以數量值表示，事實表中的每行對應一個度量，每行中的資料是一個特定級別的細節資料，稱為粒度，維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度，這樣能確保不會出現重復計算度量的問題，有時候往往不能確定該列資料是事實屬性還是維度屬性，記住最實用的事實就是數值型別和可加類事實，所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實，
三、離線數倉建設實戰
技術是為業務服務的，業務是為公司創造價值的，離開業務的技術是無意義的，
1、業務介紹
需要針對不同需求的用戶開發不同的產品，所以公司內部有很多條業務線，但是對于資料部門來說，所有業務線的資料都是資料源，對資料的劃分不只是根據業務進行，而是結合資料的屬性，
2、早期規劃
之前開發是不同業務線對應不同的資料團隊，每個資料團隊互不干擾，這種模式比較簡單，只針對自己的業務線進行數倉建設及報表開發即可，
但是隨著業務的發展，頻繁迭代及跨部門的垂直業務單元越來越多，業務之間的出現耦合情況，這時再采用這種煙囪式開發就出現了問題：
例如權限問題，公司對資料管理比較嚴格，不同的資料開發組沒有權限共享資料，需要其他業務線的資料權限需要上報審批，比較耽誤時間；
還有重復開發問題，不同業務線會出現相同的報表需求，如果每個業務方都開發各自的報表，太浪費資源，
所以對于資料開發而言，需要對各個業務線的資料進行統一管理，所以就有了資料中臺的出現，
3、資料中臺
我認為資料中臺是根據每個公司具體的業務需求而搭建的，不同的業務，對中臺的理解有所不同，
公司內部開發的敏捷資料中臺，主要從資料技術和計算能力的復用，到資料資產和資料服務的復用，資料中臺以更大價值帶寬，快準精讓資料直接賦能業務，提供一個統一化的管理，打破資料孤島，追溯資料血緣，實作自助化及高復用度，
如下所示：
資料中臺
以上解釋比較抽象，我們以實際專案開發來看下資料中臺的便利性，
比如我們之前做報表開發流程，首先是要資料采集，不同的資料源通過sqoop等工具采集到大資料平臺，然后進行數倉搭建，最后產出報表資料，放到可視化系統展示，最終把整個流程寫成腳本放到調度平臺進行自動化執行，
而有了資料中臺之后就不需要那么繁瑣，直接進行數倉搭建，產生報表即可，無需將精力過多放在資料源、可視化展示及調度，并且可以直觀的查看資料血緣關系，計算表之間血緣，像下面圖中，表之間的依賴關系很明確：
資料中臺
另一點，資料中臺的異構資料系統可以非常簡單的進行關聯查詢，比如hive的表關聯MySQL的表，可透明屏蔽異構資料系統異構互動方式，輕松實作跨異構資料系統透明混算，
異構資料系統原理是資料中臺提供虛擬表到物理表之間的映射，終端用戶無需關心資料的物理存放位置和底層資料源的特性，可直接操作資料，體驗類似操作一個虛擬資料庫，
資料中臺額外集成可視化展示，提供一站式資料可視化解決方案，支持JDBC資料源和CSV檔案上傳，支持基于資料模型拖拽智能生成可視化組件，大屏展示自適應不同大小螢屏，
調度系統是公司內部自寫集成到資料中臺的，在撰寫完sql陳述句之后可以直接進行調度，
4、數倉建設
到這才真正到數倉建設，為什么前面我要占那么大篇幅去介紹公司業務及所使用的資料中臺系統，因為下面的數倉建設是根據公司的業務發展及現有的資料中臺進行，數倉的建設離不開公司的業務，
數倉建設核心思想：從設計、開發、部署和使用層面，避免重復建設和指標冗余建設，從而保障資料口徑的規范和統一，最終實作資料資產全鏈路關聯、提供標準資料輸出以及建立統一的資料公共層，有了核心思想，那怎么開始數倉建設，有句話說數倉建設者即是技術專家，也是大半個業務專家，所以采用的方式就是需求推動資料建設，并且因為資料中臺，所以各業務知識體系比較集中，各業務資料不再分散，加快了數倉建設速度，
數倉建設主要從兩個方面進行，模型和規范，所有業務進行統一化，
1）模型
所有業務采用統一的模型體系，從而降低研發成本，增強指標復用，并且能保證資料口徑的統一，
2）模型分層
結合公司業務，后期新增需求較多，所以分層不宜過多，并且需要清晰明確各層職責，要保證資料層的穩定又要屏蔽對下游影響，所以采用如下分層結構：
資料分層架構
3）資料流向
遵循模型開發時分層結構，資料從 ods -> dw -> dm ->app 這樣正向流動，可以防止因資料參考不規范而造成資料鏈路混亂及SLA時效難保障等問題，同時保證血緣關系簡潔化，能夠輕易追蹤資料流向，在開發時應避免以下情況出現：
-
資料參考鏈路不正確，如 ods -> dm ->app ，出現這種情況說明明細層沒有完全覆寫資料；如 ods -> dw -> app ，說明輕度匯總層主題劃分未覆寫全 ，減少跨層參考，才能提高中間表的復用度，理想的數倉模型設計應當具備：資料模型可復?，完善且規范，
-
盡量避免一層的表生成當前層的表，如dw層表生成dw層表，這樣會影響ETL效率，
-
禁止出現反向依賴，如dw表依賴于dm表，
4）規范
①表命名規范
-
對于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、資料層具體實作
使用四張圖說明每層的具體實作：
1）資料源層ODS
資料源層
資料源層主要將各個業務資料匯入到大資料平臺，作為業務資料的快照存盤，
2）資料明細層DW
資料明細層
事實表中的每行對應一個度量，每行中的資料是一個特定級別的細節資料，稱為粒度，維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度，這樣能確保不會出現重復計算度量的問題，
維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重復資料，否則和事實表關聯會出現資料發散問題，
有時候往往不能確定該列資料是事實屬性還是維度屬性，記住最實用的事實就是數值型別和可加類事實，所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實；如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性，但是還是要結合業務進行最終判斷是維度還是事實，
3）資料輕度匯總層DM
資料輕度匯總層
此層命名為輕匯總層，就代表這一層已經開始對資料進行匯總，但是不是完全匯總，只是對相同粒度的資料進行關聯匯總，不同粒度但是有關系的資料也可進行匯總，此時需要將粒度通過聚合等操作進行統一，
4）資料應用層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、實時計算總覽
我們先來看一張大資料平臺的實時架構圖：
1）資料同步：
在上面這張架構圖中，資料從Web平臺中產生，通過資料同步系統匯入到大資料平臺，由于資料源不同，這里的資料同步系統實際上是多個相關系統的組合，資料庫同步通常用 Sqoop，日志同步可以選擇 Flume等，不同的資料源產生的資料質量可能差別很大，資料庫中的格式化資料直接匯入大資料系統即可，而日志和爬蟲產生的資料就需要進行大量的清洗、轉化處理才能有效使用，
2）資料存盤：
該層對原始資料、清洗關聯后的明細資料進行存盤，基于統一的實時資料模型分層理念，將不同應用場景的資料分別存盤在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存盤中，
3）資料計算：
計算層主要使用 Flink、Spark、Presto 以及 ClickHouse 自帶的計算能力等四種計算引擎，Flink 計算引擎主要用于實時資料同步、 流式 ETL、關鍵系統秒級實時指標計算場景，Spark SQL 主要用于復雜多維分析的準實時指標計算需求場景，Presto 和 ClickHouse 主要滿足多維自助分析、對查詢回應時間要求不太高的場景，
4）實時應用：
以統一查詢服務對各個業務線資料場景進行支持，業務主要包括實時大屏、實時資料產品、實時 OLAP、實時特征等，
當然一個好的大資料平臺不能缺少元資料管理及資料治理：
①元資料及指標管理
主要對實時的Kafka表、Kudu表、Clickhouse表、Hive表等進行統一管理，以數倉模型中表的命名方式規范表的命名，明確每張表的欄位含義、使用方，指標管理則是盡量通過指標管理系統將所有的實時指標統一管理起來，明確計算口徑，提供給不同的業務方使用；
②資料質量及血緣分析
資料質量分為平臺監控和資料監控兩個部分，血緣分析則主要是對實時資料依賴關系、實時任務的依賴關系進行分析，
以上架構只是大資料平臺通用的資料模型，如果要具體的建設，需要考慮以下情況，業務需求需要實時還是準實時即可，資料時效性是秒級還是分鐘級等，
-
在調度開銷方面，準實時資料是批處理程序，因此仍然需要調度系統支持，調度頻率較高，而實時資料卻沒有調度開銷；
-
在業務靈活性方面，因為準實時資料是基于 ETL 或 OLAP 引擎實作，靈活性優于基于流計算的方式；
-
在對資料晚到的容忍度方面，因為準實時資料可以基于一個周期內的資料進行全量計算，因此對于資料晚到的容忍度也是比較高的，而實時資料使用的是增量計算，對于資料晚到的容忍度更低一些；
-
在適用場景方面，準實時資料主要用于有實時性要求但不太高、涉及多表關聯和業務變更頻繁的場景，如交易型別的實時分析，實時資料則更適用于實時性要求高、資料量大的場景，如實時特征、流量型別實時分析等場景，
3、實時架構
在某些場景中，資料的價值隨著時間的推移而逐漸減少，所以在傳統大資料離線數倉的基礎上，逐漸對資料的實時性提出了更高的要求，
于是隨之誕生了大資料實時數倉，并且衍生出了兩種技術架構Lambda和Kappa，
1）Lambda架構
先來看下Lambda架構圖：
Lambda架構圖
資料從底層的資料源開始，經過Kafka、Flume等資料組件進行收集，然后分成兩條線進行計算：
-
一條線是進入流式計算平臺（例如 Storm、Flink或者SparkStreaming），去計算實時的一些指標；
-
另一條線進入批量資料處理離線計算平臺（例如Mapreduce、Hive，Spark SQL），去計算T+1的相關業務指標，這些指標需要隔日才能看見，
①為什么Lambda架構要分成兩條線計算？
假如整個系統只有一個批處理層，會導致用戶必須等待很久才能獲取計算結果，一般有幾個小時的延遲，電商資料分析部門只能查看前一天的統計分析結果，無法獲取當前的結果，這對于實時決策來說有一個巨大的時間鴻溝，很可能導致管理者錯過最佳決策時機，
Lambda架構屬于較早的一種架構方式，早期的流處理不如現在這樣成熟，在準確性、擴展性和容錯性上，流處理層無法直接取代批處理層，只能給用戶提供一個近似結果，還不能為用戶提供一個一致準確的結果，因此Lambda架構中，出現了批處理和流處理并存的現象，
在 Lambda 架構中，每層都有自己所肩負的任務，
-
批處理層存盤管理主資料集（不可變的資料集）和預先批處理計算好的視圖：
批處理層使用可處理大量資料的分布式處理系統預先計算結果，它通過處理所有的已有歷史資料來實作資料的準確性，這意味著它是基于完整的資料集來重新計算的，能夠修復任何錯誤，然后更新現有的資料視圖，輸出通常存盤在只讀資料庫中，更新則完全取代現有的預先計算好的視圖，
-
流處理層會實時處理新來的大資料：
流處理層通過提供最新資料的實時視圖來最小化延遲，流處理層所生成的資料視圖可能不如批處理層最終生成的視圖那樣準確或完整，但它們幾乎在收到資料后立即可用，而當同樣的資料在批處理層處理完成后，在速度層的資料就可以被替代掉了，
②那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架構，
作者丨園陌
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Digital-warehouse-construction-nanny-level-5W-word-tutorial-offline-and-real-time-all-in-one-net.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/543142.html
標籤：其他