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

• 2020 年 7 月 24 日
• 筆記
• ④大數據篇

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

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 定義差別

5.3 定位差別

5.4 組成差別

5.5 技術差別

5.6 功能差別

5.7 OLTP資料庫三範式介紹

5.8 OLAP典型架構

OLAP有多種實現方法，根據存儲數據的方式不同可以分為ROLAP、MOLAP、HOLAP

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 維度建模四個步驟