大數據篇：一文讀懂@數據倉庫(PPT文字版)

大數據篇：一文讀懂@數據倉庫

1 網絡詞彙總結

1.1 數據中臺

1. 數據中臺是聚合和治理跨域數據，將數據抽象封裝成服務，提供給前臺以業務價值的邏輯概念。

2. 數據中臺是一套可持續「讓企業的數據用起來」的機制，一種戰略選擇和組織形式，是依據企業特有的業務模式和組織架構，經過有形的產品和實施方法論支撐，構建一套持續不斷把數據變成資產並服務於業務的機制。

3. 數據中臺鏈接數據前臺和後臺，突破數據侷限，爲企業提供更靈活、高效、低成本的數據分析挖掘服務，避免企業爲知足具體某部門某種數據分析需求而投放大量高成本、重複性的數據開發成本。

4. 數據中臺是指經過數據技術，對海量數據進行採集、計算、存儲、加工，同時統一標準和口徑。數據中臺把數據統一以後，會造成標準數據，再進行存儲，造成大數據資產層，進而爲客戶提供高效服務。

5. 數據中臺，包括平臺、工具、數據、組織、流程、規範等一切與企業數據資產如何用起來所相關的。

能夠看出，數據中臺是解決如何用好數據的問題，目前還缺少一個標準，而說到數據中臺必定會說起大數據，而大數據又是由數據倉庫發展起來的。

1.1.1 數據倉庫（Data WareHouse）

1. 數據倉庫，按照傳統的定義，數據倉庫是一個面向主題的、集成的、非易失的、反映歷史變化（隨時間變化），用來支持管理人員決策的數據集合。

爲企業全部決策制定過程，提供全部系統數據支持的戰略集合

• 面向主題

操做型數據庫的數據組織面向事務處理任務，各個業務系統之間各自分離，而數據倉庫中的數據是按照必定的主題域進行組織。

主題是一個抽象的概念，是數據歸類的標準，是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題一般與多個操做型信息系統相關。每個主題基本對應一個宏觀的分析領域。

例如，銀行的數據倉庫的主題：客戶

客戶數據來源：從銀行儲蓄數據庫、信用卡數據庫、貸款數據庫等幾個數據庫中抽取的數據整理而成。這些客戶信息有多是一致的，也多是不一致的，這些信息須要統一整合才能完總體現客戶。

• 集成

面向事務處理的操做型數據庫一般與某些特定的應用相關，數據庫之間相互獨立，而且每每是異構的。而數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上通過系統加工、彙總和整理獲得的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。

具體以下：

1：數據進入數據倉庫後、使用以前，必須通過加工與集成。

2：對不一樣的數據來源進行統一數據結構和編碼。統一原始數 據中的全部矛盾之處，如字段的同名異義，異名同義，單位不統一，字長不一致等。

3：將原始數據結構作一個從面向應用到面向主題的大轉變。

• 非易失即相對穩定的

操做型數據庫中的數據一般實時更新，數據根據須要及時發生變化。數據倉庫的數據主要供企業決策分析之用，所涉及的數據操做主要是數據查詢，一旦某個數據進入數據倉庫之後，通常狀況下將被長期保留，也就是數據倉庫中通常有大量的查詢操做，但修改和刪除操做不多，一般只須要按期的加載、刷新。

數據倉庫中包括了大量的歷史數據。

數據經集成進入數據倉庫後是極少或根本不更新的。

• 隨時間變化即反映歷史變化

操做型數據庫主要關心當前某一個時間段內的數據，而數據倉庫中的數據一般包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信息，經過這些信息，能夠對企業的發展歷程和將來趨勢作出定量分析和預測。企業數據倉庫的建設，是以現有企業業務系統和大量業務數據的積累爲基礎。數據倉庫不是靜態的概念，只有把信息及時交給須要這些信息的使用者，供他們作出改善其業務經營的決策，信息才能發揮做用，信息纔有意義。而把信息加以整理概括和重組，並及時提供給相應的管理決策人員，是數據倉庫的根本任務。所以，從產業界的角度看，數據倉庫建設是一個工程，是一個過程

數據倉庫內的數據時限通常在５-１０年以上，甚至永不刪除，這些數據的鍵碼都包含時間項，標明數據的歷史時期，方便作時間趨勢分析。

2. 數據倉庫，並非數據最終目的地，而是爲數據最終的目的地作好準備：清洗、轉義、分類、重組、合併、拆分、統計等等

經過對數據倉庫中數據的分析，能夠幫助企業，改進業務流程、控制、成本、提升產品質量等

3. 主要解決問題：數據報表，數據沉澱，數據計算Join過多，數據查詢過慢等問題。

防止煙囪式開發，減小重複開發，開發通用中間層數據，減小重複計算；

將複雜問題簡單化，將複雜任務的多個步驟分解到各個層次中，每一層只處理較少的步驟，使單個任務更容易理解；

可進行數據血緣追蹤，便於快速定位問題；

整個數據層次清晰，每一個層次的數據都有職責定位，便於使用和理解。

4. 主要價值體現：企業數據模型，這些模型隨着前端業務系統的發展變化，不斷變革，不斷追加，不斷豐富和完善，即便系統再也不了，也能夠在短時間內快速重建起來，這也是大數據產品可以快速迭代起來的一個重要緣由

• 數倉硬件架構圖

• 數倉功能架構圖

• 數倉流程架構圖1

• 數倉流程架構圖2

• 實時數倉流程架構圖

總結：數據倉庫，即爲企業數據的模型沉澱，爲了能更快的發展大數據應用，提供可靠的模型來快速迭代。本文也主要爲了講解數據倉庫

• 拓展：血緣圖

• 拓展:BI層

• 拓展：BI圖

1.1.2 大數據平臺（DATA Platform）

1. 大數據平臺則是指以處理海量數據存儲、計算及流數據實時計算等場景爲主的一套基礎設施，包括了統一的數據採集中心、數據計算和存儲中心、數據治理中心、運維管控中心、開放共享中心和應用中心。

2. 大數據平臺的建設出發點是節約投資下降成本，但實際上不管從硬件投資仍是從軟件開發上都遠遠超過數據倉庫的建設，大量的硬件和各類開源技術的組合，增長了研發的難度、調測部署的週期、運維的複雜度，人力上的投入已經是最初的幾倍；還有不少技術上的困難也非一朝一夕可以突破。

3. 首先是數據的應用問題，不管是數據倉庫仍是大數據平臺，裏面包含了接口層數據、存儲層數據、輕度彙總層、重度彙總層、模型層數據、報表層數據等等，各類各樣的表有成千上萬，這些表有的是中間處理過程，有些是一次性的報表，不一樣表之間的數據一致性和口徑也會不一樣，並且不一樣的表不一樣的字段對數據安全要求級別也不一樣。

4. 此外還要考慮多租戶的資源安全管理，如何讓內部開發者快速獲取所需的數據資產目錄，如何閱讀相關數據的前因後果，如何快速的實現開發，這些在大數據平臺建設初期沒有考慮周全。

5. 另一個問題是對外應用，隨着大數據平臺的應用建設，每個對外應用都採用單一的數據庫加單一應用建設模式，獨立考慮網絡安全、數據安全、共享安全，逐漸又走向了煙囪似的開發道路。

• 平臺數據流向圖

• 平臺流程架構圖

總結：大數據平臺，即爲數據一站式服務，提供可視化的數據展現，提取，計算任務安排，資源管理，數據治理，安全措施，共享應用等等。

1.1.3 數據中臺（Data Middle Platform）

1. 數據中臺要解決什麼？數據如何安全的、快速的、最小權限的、且可以溯源的被探測和快速應用的問題。
2. 數據中臺不該該被過分的承載平臺的計算、存儲、加工任務，而是應該放在解決企業邏輯模型的搭建和存儲、數據標準的創建、數據目錄的梳理、數據安全的界定、數據資產的開放，知識圖譜的構建。
3. 經過一系列工具、組織、流程、規範，實現數據前臺和後臺的鏈接，突破數據侷限，爲企業提供更靈活、高效、低成本的數據分析挖掘服務，避免企業爲知足具體某部門某種數據分析需求而投放大量高成本、重複性的數據開發成本。

• 中臺架構圖

• 阿里數據中臺架構圖

總結：厚平臺，大中臺，小前臺；沒有基礎厚實笨重的大數據平臺，是不可能構建數據能力強大、功能強大的數據中臺的；沒有大數據中臺，要迅速搭建小快靈的小前臺也只是理想化的。

2 數據倉庫的演進

• 實時數倉架構圖

• 離線數倉架構圖

3 數據倉庫主要用途

你們應該已經意識到這個問題：既然分析型數據庫中的操做都是查詢，所以也就不須要嚴格知足完整性/參照性約束以及範式設計要求，而這些卻正是分析型數據庫精華所在。這樣的狀況下再將它歸爲數據庫會很容易引發你們混淆，畢竟在絕大多數人內心數據庫是能夠關係型數據庫畫上等號的。

• 數據提取圖：規整數據源

• 報表系統圖：用於分析企業指標

• 數據分析圖：用於分析週期數據

• 數據挖掘圖：讓數據更有價值

• 畫像系統指標圖:

• 數據大屏圖

4 數據集市&數據分層

4.1 數據集市

4.2 數據分層

6.5.1 ODS層

• 保持數據原貌不作任何修改，起到備份數據的做用。
• 數據採用壓縮，減小磁盤存儲空間（例如：原始數據 100G，能夠壓縮到 10G 左 右）
• 建立分區表，防止後續的全表掃描

6.5.2 DWD層

• DWD 層需構建維度模型，通常採用星型模型，呈現的狀態通常爲星座模型。

事實/維度	時間	用戶	地區	商品	優惠卷	活動	編碼	度量
訂單	√	√	√			√		件數/金額
訂單詳情	√		√	√				件數/金額
支付	√		√					次數/金額
加入購物車	√	√		√				件數/金額
收藏	√	√		√				個數
評價	√	√		√				個數
退款	√	√		√				件數/金額
優惠卷領用	√	√			√			個數

6.5.3 DWS層

• 統計各個主題對象的當天行爲，服務於 DWT 層的主題寬表，以及一些業務明細數據， 應對特殊需求（例如，購買行爲，統計商品復購率）。

6.5.4 DWT層

• 以分析的主題對象爲建模驅動，基於上層的應用和產品的指標需求，構建主題對象的全量寬表。（按照維度來決定分析者的角度，如用戶->什麼時間->下了什麼單，支付了什麼，加入購物車了什麼）

6.5.5 ADS層

對系統各大主題指標分別進行分析。

5 數據庫的"分家"

5.1 OLAP 和 OLTP簡介

數據處理大體能夠分紅兩大類：

聯機事務處理OLTP（on-line transaction processing）：是傳統的關係型數據庫的主要應用，主要是基本的、平常的事務處理，例如銀行交易。系統強調數據庫內存效率，強調內存各類指標的命令率，強調綁定變量，強調併發操做。

聯機分析處理OLAP（On-Line Analytical Processing）：是數據倉庫系統的主要應用，支持複雜的分析操做，側重決策支持，而且提供直觀易懂的查詢結果。 系統則強調數據分析，強調SQL執行市場，強調磁盤I/O，強調分區等。

5.2 定義差異

對比內容	操做型數據庫(OLTP)	分析型數據庫(OLAP)
數據內容	當前值	歷史的、存檔的、概括的、計算的數據
數據目標	面向業務操做程序，重複處理	面向主題域，分析應用，支持決策
數據特性	動態變化，按字段更新	靜態、不能直接更新，只能定時添加、刷新
數據結構	高度結構化、複雜，適合操做計算	簡單，適合分析
使用頻率	高	中到低
數據訪問量	每一個事務只訪問少許記錄	有的事務可能須要訪問大量記錄
對響應時間的要求	以秒爲單位計算	以秒、分鐘、甚至小時爲計算單位

5.3 定位差異

對比屬性	OLTP	OLAP
表明	Mysql	Hive
讀特性	每次查詢只返回少許數據	對大量數據進行彙總
寫特性	隨機、低延遲寫入用戶的操做	批量導入
用戶	操做人員	決策人員
DB設計	面向應用	面向主題
數據	當前的，最新的細節，二維表	歷史的，彙集的，多維表
工做單位	事務性保證	複雜查詢
用戶數	上千個	上百萬個
DB大小	100MB-GB	100GB-TB以上
時間要求	具備實時性	對時間的要求不嚴格
主要應用	數據庫：WEB項目	數據倉庫：分析師，挖掘師

5.4 組成差異

對比內容	操做型數據庫(OLTP)	分析型數據庫(OLAP)
數據時間範圍差異	只會存放必定天數的數據	存放的則是數年內的數據
數據細節層次差異	存放的主要是細節數據 也有彙總需求，但彙總數據自己不存儲而只存儲其生成公式。 這是由於操做型數據是動態變化的，所以彙總數據會在每次查詢時動態生成。	存放的既有細節數據，又有彙總數據，對於用戶來講，重點關注的是彙總數據部分。 由於彙總數據比較穩定不會發生改變，並且其計算量也比較大(由於時間跨度大)，所以它的彙總數據可考慮事先計算好，以免重複計算。
數據時間表示差異	一般反映的是現實世界的當前狀態	既有當前狀態，還有過去各時刻的快照。 能夠綜合全部快照對各個歷史階段進行統計分析

5.5 技術差異

對比內容	操做型數據庫(OLTP)	分析型數據庫(OLAP)
數據更新差異	容許用戶進行增，刪，改，查	規範是隻能進行查詢
數據冗餘差異	減小數據冗餘，避免更新異常	沒有更新操做。所以，減小數據冗餘也就沒那麼重要了

5.6 功能差異

對比內容	操做型數據庫(OLTP)	分析型數據庫(OLAP)
數據讀者差異	使用者是業務環境內的各個角色，如用戶，商家，進貨商等	只被少許用戶(高級管理者)用來作綜合性決策
數據定位差異	是爲了支撐具體業務建立的，所以也被稱爲"面向應用型數據庫"	是針對各特定業務主題域的分析任務建立的，所以也被稱爲"面向主題型數據庫"

5.7 OLTP數據庫三範式介紹

5.8 OLAP典型架構

OLAP有多種實現方法，根據存儲數據的方式不一樣能夠分爲ROLAP、MOLAP、HOLAP

名稱	描述	細節數據存儲位置	聚合後的數據存儲位置
ROLAP(Relational OLAP)	基於關係數據庫的OLAP實現	關係型數據庫	關係型數據庫
MOLAP(Multidimensional OLAP)	基於多維數據組織的OLAP實現	數據立方體	數據立方體
HOLAP(Hybrid OLAP)	基於混合數據組織的OLAP實現	關係型數據庫	數據立方體

5.9 OLAP數據立方體(Data Cube)

6 數據建模

6.1 關係建模(適用於OLTP)

6.2 維度建模(適用於OLAP)

6.3 經常使用詞解釋

6.3.1 維度表

1. 通常是對事實的描述信息。每一張維表對應現實世界中的一個對象或者概念。 例如：用戶、商品、日期、地區等。
2. 經常使用於一個客觀世界的維度描述。（具備多個屬性、列比較多）
3. 審視數據的角度。(如用戶，商品)
4. 行數相對較小：一般< 10 萬條。(對比事實表)
5. 靜態表示的，名詞性質的表。(如地理，時間，狀態)
6. 變化較慢。（新增修改操做較少）

• 維表的特徵：
  • 維表的範圍很寬（具備多個屬性、列比較多）
  • 跟事實表相比，行數相對較小：一般< 10 萬條
  • 靜態表示的，名詞性質的表

6.3.2 事實表

1. 事實表用於正確的記錄既定的已經發生的事實，經常使用於存儲ID和度量值，各類維度外鍵

2. 事實表中的每行數據表明一個業務事件（下單、支付、退款、評價等）。「事實」這 個術語表示的是業務事件的度量值（可統計次數、個數、件數、金額等），例如，訂單事件中的下單金額。

3. 每個事實表的行包括：具備可加性的數值型的度量值、與維表相鏈接的外鍵、一般具 有兩個和兩個以上的外鍵、外鍵之間表示維表之間多對多的關係。

4. 行數相對較多。(對比維度表)

5. 列數較少。（不是絕對）

6. 變化較快。（新增修改操做較多）

7. 動態表示的，動詞性質的表。（以下單，優惠卷領用）

8. 事實表導入策略通常有三種劃分：事務型事實表，週期型快照事實表，累積型快照事實表

劃分/比較點	事務狀況	導入策略
事務型事實表	以每一個事務或事件爲單位，例如一個銷售訂單記錄，一筆支付記錄等，做爲 事實表裏的一行數據。一旦事務被提交，事實表數據被插入，數據就再也不進 行更改，其更新方式爲增量更新	天天導入新增
週期型快照事實表	週期型快照事實表中不會保留全部數據，只保留固定時間間隔的數據，例如 天天或者每個月的銷售額，或每個月的帳戶餘額等	每日全量
累積型快照事實表	累計快照事實表用於跟蹤業務事實的變化。例如，數據倉庫中可能須要累積 或者存儲訂單從下訂單開始，到訂單商品被打包、運輸、和簽收的各個業務 階段的時間點數據來跟蹤 訂單聲明週期的進展狀況。當這個業務過程進行時 ，事實表的記錄也要不斷更新	天天導入新增及變化

6.4 建模的三種模式

6.5 維度建模四個步驟