# 大資料篇：一文讀懂@資料倉庫 ## 1 網路詞彙總結 - 人工智慧層的：智慧地球、智慧城市、智慧社會 - 企業層面的：數字網際網路，數字經濟、數字平臺、數字城市、數字政府； - 平臺層面的：物聯網，雲端計算，大資料，5G，人工智慧，機器智慧，深度學習，知識圖譜 - 技術層面的：資料倉庫、資料集市、大資料平臺、資料湖、資料中臺、業務中臺、技術中臺等等 > 挑重點簡介 ### 1.1 資料中臺 1. 資料中臺是聚合和治理跨域資料，將資料抽象封裝成服務，提供給前臺以業務價值的邏輯概念。 2. 資料中臺是一套可持續“讓企業的資料用起來”的機制，一種戰略選擇和組織形式，是依據企業特有的業務模式和組織架構，通過有形的產品和實施方法論支撐，構建一套持續不斷把資料變成資產並服務於業務的機制。 3. 資料中臺連線資料前臺和後臺，突破資料侷限，為企業提供更靈活、高效、低成本的資料分析挖掘服務，避免企業為滿足具體某部門某種資料分析需求而投放大量高成本、重複性的資料開發成本。 4. 資料中臺是指通過資料技術，對海量資料進行採集、計算、儲存、加工，同時統一標準和口徑。資料中臺把資料統一之後，會形成標準資料，再進行儲存，形成大資料資產層，進而為客戶提供高效服務。 5. 資料中臺，包括平臺、工具、資料、組織、流程、規範等一切與企業資料資產如何用起來所相關的。 > 可以看出，資料中臺是解決如何用好資料的問題，目前還缺乏一個標準，而說到資料中臺一定會提及大資料，而大資料又是由資料倉庫發展起來的。 #### 1.1.1 資料倉庫（Data WareHouse） 1. 資料倉庫，按照傳統的定義，資料倉庫是一個面向主題的、整合的、非易失的、反映歷史變化（隨時間變化），用來支援管理人員決策的資料集合。 >為企業所有決策制定過程，提供所有系統資料支援的戰略集合 > >- 面向主題 > > 操作型資料庫的資料組織面向事務處理任務，各個業務系統之間各自分離，而資料倉庫中的資料是按照一定的主題域進行組織。 > > 主題是一個抽象的概念，是資料歸類的標準，是指使用者使用資料倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型資訊系統相關。每一個主題基本對應一個巨集觀的分析領域。 > > 例如，銀行的資料倉庫的主題：客戶 > > 客戶資料來源：從銀行儲蓄資料庫、信用卡資料庫、貸款資料庫等幾個資料庫中抽取的資料整理而成。這些客戶資訊有可能是一致的，也可能是不一致的，這些資訊需要統一整合才能完整體現客戶。 > >- 整合 > > 面向事務處理的操作型資料庫通常與某些特定的應用相關，資料庫之間相互獨立，並且往往是異構的。而資料倉庫中的資料是在對原有分散的資料庫資料抽取、清理的基礎上經過系統加工、彙總和整理得到的，必須消除源資料中的不一致性，以保證資料倉庫內的資訊是關於整個企業的一致的全域性資訊。 > > 具體如下： > > 1：資料進入資料倉庫後、使用之前，必須經過加工與整合。 > > 2：對不同的資料來源進行統一資料結構和編碼。統一原始數 據中的所有矛盾之處，如欄位的同名異義，異名同義，單位不統一，字長不一致等。 > > 3：將原始資料結構做一個從面向應用到面向主題的大轉變。 > >- 非易失即相對穩定的 > > 操作型資料庫中的資料通常實時更新，資料根據需要及時發生變化。資料倉庫的資料主要供企業決策分析之用，所涉及的資料操作主要是資料查詢，一旦某個資料進入資料倉庫以後，一般情況下將被長期保留，也就是資料倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的載入、重新整理。 > > 資料倉庫中包括了大量的歷史資料。 > > 資料經整合進入資料倉庫後是極少或根本不更新的。 > >- 隨時間變化即反映歷史變化 > > 操作型資料庫主要關心當前某一個時間段內的資料，而資料倉庫中的資料通常包含歷史資訊，系統記錄了企業從過去某一時點(如開始應用資料倉庫的時點)到目前的各個階段的資訊，通過這些資訊，可以對企業的發展歷程和未來趨勢做出定量分析和預測。企業資料倉庫的建設，是以現有企業業務系統和大量業務資料的積累為基礎。資料倉庫不是靜態的概念，只有把資訊及時交給需要這些資訊的使用者，供他們做出改善其業務經營的決策，資訊才能發揮作用，資訊才有意義。而把資訊加以整理歸納和重組，並及時提供給相應的管理決策人員，是資料倉庫的根本任務。因此，從產業界的角度看，資料倉庫建設是一個工程，是一個過程 > > 資料倉庫內的資料時限一般在５-１０年以上，甚至永不刪除，這些資料的鍵碼都包含時間項，標明資料的歷史時期，方便做時間趨勢分析。 2. 資料倉庫，並不是資料最終目的地，而是為資料最終的目的地做好準備：清洗、轉義、分類、重組、合併、拆分、統計等等 > 通過對資料倉庫中資料的分析，可以幫助企業，改進業務流程、控制、成本、提高產品質量等 3. 主要解決問題：資料報表，資料沉澱，資料計算Join過多，資料查詢過慢等問題。 >防止煙囪式開發，減少重複開發，開發通用中間層資料，減少重複計算； > >將複雜問題簡單化，將複雜任務的多個步驟分解到各個層次中，每一層只處理較少的步驟，使單個任務更容易理解； > >可進行資料血緣追蹤，便於快速定位問題； > >整個資料層次清晰，每個層次的資料都有職責定位，便於使用和理解。 4. 主要價值體現：企業資料模型，這些模型隨著前端業務系統的發展變化，不斷變革，不斷追加，不斷豐富和完善，即使系統不再了，也可以在短期內快速重建起來，這也是大資料產品能夠快速迭代起來的一個重要原因 > 總結：資料倉庫，即為企業資料的模型沉澱，為了能更快的發展大資料應用，提供可靠的模型來快速迭代。本文也主要為了講解資料倉庫 - 數倉硬體架構圖  - 數倉功能架構圖  - 數倉流程架構圖1  - 數倉流程架構圖2  - 實時數倉流程架構圖  #### 1.1.2 大資料平臺（DATA Platform） 1. 大資料平臺則是指以處理海量資料儲存、計算及流資料實時計算等場景為主的一套基礎設施，包括了統一的資料採集中心、資料計算和儲存中心、資料治理中心、運維管控中心、開放共享中心和應用中心。 2. 大資料平臺的建設出發點是節約投資降低成本，但實際上無論從硬體投資還是從軟體開發上都遠遠超過資料倉庫的建設，大量的硬體和各種開源技術的組合，增加了研發的難度、調測部署的週期、運維的複雜度，人力上的投入已是最初的幾倍；還有很多技術上的困難也非一朝一夕能夠突破。 3. 首先是資料的應用問題，無論是資料倉庫還是大資料平臺，裡面包含了介面層資料、儲存層資料、輕度彙總層、重度彙總層、模型層資料、報表層資料等等，各種各樣的表有成千上萬，這些表有的是中間處理過程，有些是一次性的報表，不同表之間的資料一致性和口徑也會不同，而且不同的表不同的欄位對資料安全要求級別也不同。 4. 此外還要考慮多租戶的資源安全管理，如何讓內部開發者快速獲取所需的資料資產目錄，如何閱讀相關資料的來龍去脈，如何快速的實現開發，這些在大資料平臺建設初期沒有考慮周全。 5. 另外一個問題是對外應用，隨著大資料平臺的應用建設，每一個對外應用都採用單一的資料庫加單一應用建設模式，獨立考慮網路安全、資料安全、共享安全，逐漸又走向了煙囪似的開發道路。 > 總結：大資料平臺，即為資料一站式服務，提供視覺化的資料展示，提取，計算任務安排，資源管理，資料治理，安全措施，共享應用等等。 - 平臺數據流向圖  - 平臺流程架構圖  #### 1.1.3 資料中臺（Data Middle Platform） 1. 資料中臺要解決什麼？資料如何安全的、快速的、最小許可權的、且能夠溯源的被探測和快速應用的問題。 2. 資料中臺不應該被過度的承載平臺的計算、儲存、加工任務，而是應該放在解決企業邏輯模型的搭建和儲存、資料標準的建立、資料目錄的梳理、資料安全的界定、資料資產的開放，知識圖譜的構建。 3. 通過一系列工具、組織、流程、規範，實現資料前臺和後臺的連線，突破資料侷限，為企業提供更靈活、高效、低成本的資料分析挖掘服務，避免企業為滿足具體某部門某種資料分析需求而投放大量高成本、重複性的資料開發成本。 > 總結：**厚平臺，大中臺，小前臺；沒有基礎厚實笨重的大資料平臺，是不可能構建資料能力強大、功能強大的資料中臺的；沒有大資料中臺，要迅速搭建小快靈的小前臺也只是理想化的。** - 中臺架構圖  - 阿里資料中臺架構圖  ## 2 資料庫的"分家" **隨著關係資料庫理論的提出，誕生了一系列經典的RDBMS，如Oracle，MySQL，SQL Server等。這些RDBMS被成功推向市場，併為社會資訊化的發展做出的重大貢獻。然而隨著資料庫使用範圍的不斷擴大，它被逐步劃分為兩大基本型別：** 1. 操作型資料庫（OLTP） > 主要用於業務支撐。一個公司往往會使用並維護若干個資料庫，這些資料庫儲存著公司的日常操作資料，比如商品購買、酒店預訂、打車下單、外賣訂購等； 2. 分析型資料庫（OLAP） >主要用於歷史資料分析。這類資料庫作為公司的單獨資料儲存，負責利用歷史資料對公司各主題域進行統計分析； - 總結 >那麼為什麼要"分家"？在一起不合適嗎？能不能構建一個同樣適用於操作和分析的統一資料庫？ > >答案是NO。一個顯然的原因是它們會"打架"......如果操作型任務和分析型任務搶資源怎麼辦呢？再者，它們有太多不同，以致於早已"貌合神離"。接下來看看它們到底有哪些不同吧。 > >因為主導功能的不同(面向操作/面向分析)，兩類資料庫就產生了很多細節上的差異。就好像玩LOL一箇中單一個ADC，肯定有很多行為/觀念上的不同 ### 2.1 OLAP 和 OLTP簡介 **資料處理大致可以分成兩大類：** >聯機事務處理OLTP（on-line transaction processing）：是傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。系統強調資料庫記憶體效率，強調記憶體各種指標的命令率，強調繫結變數，強調併發操作。 > >聯機分析處理OLAP（On-Line Analytical Processing）：是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。 系統則強調資料分析，強調SQL執行市場，強調磁碟I/O，強調分割槽等。 ### 2.2 定義差別 | 對比內容 | 操作型資料庫(OLTP) | 分析型資料庫(OLAP) | | ---------------- | ------------------------------ | -------------------------------------- | | 資料內容 | 當前值 | 歷史的、存檔的、歸納的、計算的資料 | | 資料目標 | 面向業務操作程式，重複處理 | 面向主題域，分析應用，支援決策 | | 資料特性 | 動態變化，按欄位更新 | 靜態、不能直接更新，只能定時新增、重新整理 | | 資料結構 | 高度結構化、複雜，適合操作計算 | 簡單，適合分析 | | 使用頻率 | 高 | 中到低 | | 資料訪問量 | 每個事務只訪問少量記錄 | 有的事務可能需要訪問大量記錄 | | 對響應時間的要求 | 以秒為單位計算 | 以秒、分鐘、甚至小時為計算單位 | ### 2.3 定位差別 | 對比屬性 | OLTP | OLAP | | -------- | -------------------------- | ------------------------ | | 代表 | Mysql | Hive | | 讀特性 | 每次查詢只返回少量資料 | 對大量資料進行彙總 | | 寫特性 | 隨機、低延遲寫入使用者的操作 | 批量匯入 | | 使用者 | 操作人員 | 決策人員 | | DB設計 | 面向應用 | 面向主題 | | 資料 | 當前的，最新的細節，二維表 | 歷史的，聚集的，多維表 | | 工作單位 | 事務性保證 | 複雜查詢 | | 使用者數 | 上千個 | 上百萬個 | | DB大小 | 100MB-GB | 100GB-TB以上 | | 時間要求 | 具有實時性 | 對時間的要求不嚴格 | | 主要應用 | 資料庫：WEB專案 | 資料倉庫：分析師，挖掘師 | ### 2.4 組成差別 | 對比內容 | 操作型資料庫(OLTP) | 分析型資料庫(OLAP) | | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | 資料時間範圍差別 | 只會存放一定天數的資料 | 存放的則是數年內的資料 | | 資料細節層次差別 | 存放的主要是細節資料 也有彙總需求，但彙總資料本身不儲存而只儲存其生成公式。
這是因為操作型資料是動態變化的，因此彙總資料會在每次查詢時動態生成。 | 存放的既有細節資料，又有彙總資料，對於使用者來說，重點關注的是彙總資料部分。
因為彙總資料比較穩定不會發生改變，而且其計算量也比較大(因為時間跨度大)，因此它的彙總資料可考慮事先計算好，以避免重複計算。 | | 資料時間表示差別 | 通常反映的是現實世界的當前狀態 | 既有當前狀態，還有過去各時刻的快照。
可以綜合所有快照對各個歷史階段進行統計分析 | ### 2.5 技術差別 | 對比內容 | 操作型資料庫(OLTP) | 分析型資料庫(OLAP) | | ------------ | ------------------------------------------------- | ------------------------------------------------------------ | | 資料更新差別 | 允許使用者進行增，刪，改，查 | 規範是隻能進行查詢 | | 資料冗餘差別 | 減少資料冗餘，避免更新異常 | 沒有更新操作。因此，減少資料冗餘也就沒那麼重要了 | ### 2.6 功能差別 | 對比內容 | 操作型資料庫(OLTP) | 分析型資料庫(OLAP) | | ------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | | 資料讀者差別 | 使用者是業務環境內的各個角色，如使用者，商家，進貨商等 | 只被少量使用者(高階管理者)用來做綜合性決策 | | 資料定位差別 | 是為了支撐具體業務建立的，因此也被稱為"面向應用型資料庫" | 是針對各特定業務主題域的分析任務建立的，因此也被稱為"面向主題型資料庫" | ### 2.7 OLTP資料庫三正規化介紹 - 定義：正規化可以理解為設計一張資料表的表結構，符合的標準級別。 規範和要求 - 優點：關係型資料庫設計時，遵照一定的規範要求，目的在於降低資料的冗餘性。 - 十幾年前，磁碟很貴，為了減少磁碟儲存。 - 以前沒有分散式系統，都是單機，只能增加磁碟，磁碟個數也是有限的 - 一次修改，需要修改多個表，很難保證資料一致性 - 缺點：正規化的缺點是獲取資料時，需要通過 Join 拼接出最後的資料。 > 目前業界正規化有：第一正規化(1NF)、第二正規化(2NF)、第三正規化(3NF)、巴斯-科德正規化 (BCNF)、第四正規化(4NF)、第五正規化(5NF)。 #### 2.7.1 函式依賴 | 學號 | 姓名 | 系名 | 班主任 | 課名 | 分數 | | --------------------------- | ---- | ------ | ------ | ------------------------------- | ---- | | 001 | 張三 | 古文系 | 李白 | 文言文 | 89 | | 001 | 張三 | 古文系 | 李白 | 古詩詞 | 78 | | 001 | 張三 | 古文系 | 李白 | 現代漢語 | 65 | | 002 | 李四 | 古文系 | 李白 | 文言文 | 45 | | 002 | 李四 | 古文系 | 李白 | 古詩詞 | 78 | | 002 | 李四 | 古文系 | 李白 | 甲骨文 | 98 | | 003 | 王五 | 數學系 | 牛頓 | 高等數學 | 88 | | 003 | 王五 | 數學系 | 牛頓 | 數學基礎 | 88 | 1. 完全函式依賴： > 通過 AB 能推出 C，但是 AB 單獨得不到 C，那麼可以說：C 完全依賴於 AB > > （學號，課名）推出 分數，但是 單獨用學號 推不出 分數，那麼可以說：分數 完全依賴於（學號，課名） 2. 部分函式依賴： > 通過 AB 能推出 C，通過 單獨的A 或者 單獨的B 也能推出 C，那麼可以說：C 部分依賴於 AB > > （學號，課名）推出 姓名，而還可以通過 學號 直接推出 姓名，那麼可以說：姓名 部分依賴於（學號，課名） 3. 傳遞函式依賴： > 通過 A 得到 B，通過 B 得到 C，但是通過 C 不能得到 A，那麼可以說：C 傳遞依賴於 A > > 通過 學號 推出 系名，系名 推出 系主任，但是 系主任 不能推出 學號，那麼可以說：系主任 專遞依賴於 學號 #### 2.7.2 三正規化區分 ##### 2.7.2.1 第一正規化：屬性不可切割 - 不符合第一正規化表設計 | ID | 商品 | 商家ID | 使用者ID | | ---- | ------------------------------ | -------- | ------ | | 001 | 5臺電腦 | 小米_001 | 00001 | > 如上表格不符合第一正規化，商品列中的資料不是原子資料項，是可以進行分割的。 - 符合第一正規化表設計 | ID | 商品 | 數量 | 商家ID | 使用者ID | | ---- | --------------------------- | ------------------------ | -------- | ------ | | 001 | 電腦 | 5 | 小米_001 | 00001 | > 1NF是所有關係資料庫的最基本要求 ##### 2.7.2.2 第二正規化：不能存在"部分函式依賴" - 不符合第二正規化表設計 | 學號 | 姓名 | 系名 | 班主任 | 課名 | 分數 | | --------------------------- | ---- | ------ | ------ | ------------------------------- | ---- | | 001 | 張三 | 古文系 | 李白 | 文言文 | 89 | | 001 | 張三 | 古文系 | 李白 | 古詩詞 | 78 | | 001 | 張三 | 古文系 | 李白 | 現代漢語 | 65 | | 002 | 李四 | 古文系 | 李白 | 文言文 | 45 | | 002 | 李四 | 古文系 | 李白 | 古詩詞 | 78 | | 002 | 李四 | 古文系 | 李白 | 甲骨文 | 98 | | 003 | 王五 | 數學系 | 牛頓 | 高等數學 | 88 | | 003 | 王五 | 數學系 | 牛頓 | 數學基礎 | 88 | > 如上表格不符合第二正規化，比如：這張表主鍵（學號，課名），分數完全依賴於（學號和課名），但是姓名並不完全依賴於（學號和課名） - 符合第二正規化表設計 | 學號 | 課名 | 分數 | | --------------------------- | ------------------------------- | ---- | | 001 | 文言文 | 89 | | 001 | 古詩詞 | 78 | | 001 | 現代漢語 | 65 | | 002 | 文言文 | 45 | | 002 | 古詩詞 | 78 | | 002 | 甲骨文 | 98 | | 003 | 高等數學 | 88 | | 003 | 數學基礎 | 88 | | 學號 | 姓名 | 系名 | 班主任 | | --------------------------- | ---- | ------ | ------ | | 001 | 張三 | 古文系 | 李白 | | 002 | 李四 | 古文系 | 李白 | | 003 | 王五 | 數學系 | 牛頓 | ##### 2.7.2.3 第三正規化：不能存在"傳遞函式依賴" - 不符合第三正規化表設計 | 學號 | 姓名 | 系名 | 班主任 | | --------------------------- | ---- | ------ | ------ | | 001 | 張三 | 古文系 | 李白 | | 002 | 李四 | 古文系 | 李白 | | 003 | 王五 | 數學系 | 牛頓 | >如上表格不符合第三正規化，比如：學號-->系名-->系主任，但是系主任推不出學號 - 符合第三正規化表設計 | 學號 | 姓名 | 系名 | | --------------------------- | ---- | ------ | | 001 | 張三 | 古文系 | | 002 | 李四 | 古文系 | | 003 | 王五 | 數學系 | | 系名 | 班主任 | | ------ | ------ | | 古文系 | 李白 | | 古文系 | 李白 | | 數學系 | 牛頓 | ### 2.8 OLAP典型架構 **OLAP有多種實現方法，根據儲存資料的方式不同可以分為ROLAP、MOLAP、HOLAP** | 名稱 | 描述 | 細節資料儲存位置 | 聚合後的資料儲存位置 | | ---------------------------- | -------------------------- | ---------------- | -------------------- | | ROLAP(Relational OLAP) | 基於關係資料庫的OLAP實現 | 關係型資料庫 | 關係型資料庫 | | MOLAP(Multidimensional OLAP) | 基於多維資料組織的OLAP實現 | 資料立方體 | 資料立方體 | | HOLAP(Hybrid OLAP) | 基於混合資料組織的OLAP實現 | 關係型資料庫 | 資料立方體 | 1. ROLAP(Relational Online Analytical Processing) > ROLAP架構並不會生成實際的多維資料集，而是使用雪花模式以及多個關係表對資料立方體進行模擬，它的OLAP引擎就是將使用者的OLAP操作，如上鑽下鑽過濾合併等，轉換成SQL語句提交到資料庫中執行，並且提供聚集導航功能，根據使用者操作的維度和度量將SQL查詢定位到最粗粒度的事實表上去 > > 這種架構下的查詢沒有MOLAP快速。因為ROLAP中，所有的查詢都是被轉換為SQL語句執行的。而這些SQL語句的執行會涉及到多個表之間的JOIN操作，沒有MOLAP速度快，往往都是通過記憶體計算實現。(記憶體的昂貴大家是知道的)  2. MOLAP(Multidimensional Online Analytical Processing) > MOLAP架構會生成一個新的多維資料集，也可以說是構建了一個實際資料立方體。事先將彙總資料計算好，存放在自己特定的多維資料庫中，使用者的OLAP操作可以直接對映到多維資料庫的訪問，不通過SQL訪問。(空間換時間，典型代表Kylin) > > 在該立方體中，每一格對應一個直接地址，且常用的查詢已被預先計算好。因此每次的查詢都是非常快速的，但是由於立方體的更新比較慢，所以是否使用這種架構得具體問題具體分析。  3. HOLAP(Hybrid Online Analytical Processing) > 這種架構綜合參考MOLAP和ROLAP而採用一種混合解決方案，將某些需要特別提速的查詢放到MOLAP引擎，其他查詢則呼叫ROLAP引擎。上述MOLAP和ROLAP的結合。它提供了更大的靈活度，MOLAP提供提供了更加快速的響應速度。但是帶來的問題是，資料裝載的效率非常低，因為其實就是將多維的資料預先填好，但是隨著資料量過大維度成本越高，容易引起“資料爆炸”。  ### 2.9 OLAP資料立方體(Data Cube) **OLAP（online analytical processing）是一種軟體技術，它使分析人員能夠迅速、一致、互動地從各個方面觀察資訊，以達到深入理解資料的目的。從各方面觀察資訊，也就是從不同的維度分析資料，因此OLAP也稱為多維分析。** > 很多年前，當我們要手工從一堆資料中提取資訊時，我們會分析一堆資料報告。通常這些資料報告採用二維表示，是行與列組成的二維表格。但在真實世界裡我們分析資料的角度很可能有多個，資料立方體可以理解為就是維度擴充套件後的二維表格。下圖展示了一個三維資料立方體：  > 更多時候資料立方體是N維的。它的實現有兩種方式。其中星形模式就是其中一種，該模式其實是一種連線關係表與資料立方體的橋樑。但對於大多數純OLAP使用者來講，資料分析的物件就是這個邏輯概念上的資料立方體，其具體實現不用深究。對於這些OLAP工具的使用者來講，基本用法是首先配置好維表、事實表，然後在每次查詢的時候告訴OLAP需要展示的維度和事實欄位和操作型別即可。 > > 最常見的五大操作：切片，切塊，旋轉，上卷，下鑽。 #### 2.9.1 切片和切塊(Slice and Dice) > 在資料立方體的某一維度上選定一個維成員的操作叫切片，而對兩個或多個維執行選擇則叫做切塊。下圖邏輯上展示了切片和切塊操作：  #### 2.9.2 旋轉(Pivot) > 旋轉就是指改變報表或頁面的展示方向。對於使用者來說，就是個檢視操作，而從SQL模擬語句的角度來說，就是改變SELECT後面欄位的順序而已。下圖邏輯上展示了旋轉操作：  #### 2.9.3 上卷和下鑽(Rol-up and Drill-down) > 上卷可以理解為"無視"某些維度；下鑽則是指將某些維度進行細分。下圖邏輯上展示了上卷和下鑽操作：  #### 2.9.4 Cube 和 Cuboid  > **Cube（或 Data Cube）**，即資料立方體，是一種常用於資料分析與索引的技術；它可以對原始資料建立多維度索引。通過 Cube 對資料進行分析，可以大大加快資料的查詢效率。 > **Cuboid** 特指在某一種維度組合下所計算的資料。 給定一個數據模型，我們可以對其上的所有維度進行組合。對於 N 個維度來說，組合的所有可能性共有 2 的 N 次方種。對於每一種維度的組合，將度量做 聚合運算，然後將運算的結果儲存為一個物化檢視，稱為 Cuboid。 > 所有維度組合的 Cuboid 作為一個整體，被稱為 Cube。所以簡單來說，一個 Cube 就是許多按維度聚合的物化檢視的集合。 > 下面來列舉一個具體的例子： > > 假定有一個電商的銷售資料集，其中維度包括 時間（Time）、商品（Item）、地點（Location）和供應商（Supplier），度量為銷售額（GMV）。 > > - 那麼所有維度的組合就有 2 的 4 次方 =16 種 > - 一維度（1D） 的組合有[Time]、[Item]、[Location]、[Supplier]4 種 > - 二維度（2D）的組合 有[Time，Item]、[Time，Location]、[Time、Supplier]、[Item，Location]、 [Item，Supplier]、[Location，Supplier]6 種 > - 三維度（3D）的組合也有 4 種 > - 零維度（0D）的組合有 1 種 > - 四維度（4D）的組合有 1 種  ## 3 資料倉庫的演進  ## 4 資料倉庫主要用途 > 大家應該已經意識到這個問題：既然分析型資料庫中的操作都是查詢，因此也就不需要嚴格滿足完整性/參照性約束以及正規化設計要求，而這些卻正是分析型資料庫精華所在。這樣的情況下再將它歸為資料庫會很容易引起大家混淆，畢竟在絕大多數人心裡資料庫是可以關係型資料庫畫上等號的。 - 那麼為什麼不乾脆叫"面向分析的儲存系統"呢？ > 這就是關於資料倉庫最貼切的定義了。事實上資料倉庫不應讓傳統關係資料庫來實現，因為關係資料庫最少也要求滿足第1正規化，而資料倉庫裡的關係表可以不滿足第1正規化。也就是說，同樣的記錄在一個關係表裡可以出現N次。但由於大多數資料倉庫內的表的統計分析還是用SQL，因此很多人把它和關係資料庫搞混了。 ### 4.1 支援資料提取 >資料提取可以支撐來自企業各業務部門的資料需求。 > >由之前的不同業務部門給不同業務系統提需求轉變為不同業務系統統一給資料倉庫提需求，避免煙囪式開發  ### 4.2 支援報表系統 > 基於企業的資料倉庫，向上支撐企業的各部門的統計報表需求，輔助支撐企業日常運營決策。  ### 4.3 支援資料分析 >從許多來自不同的企業業務系統的資料中提取出有用的資料並進行清理，以保證資料的正確性，然後經過抽取、轉換和裝載,即ETL過程，合併到一個企業級的資料倉庫裡，從而得到企業資料的一個全域性檢視； > >在此基礎上利用合適的查詢和分析工具、資料探勘工具、OLAP工具等對其進行分析和處理（這時資訊變為輔助決策的知識）； > >最後將知識呈現給管理者，為管理者的決策過程提供支援 。  ### 4.4 支援資料探勘 >資料探勘也稱為資料庫知識發現（Knowledge Discovery in Databases, KDD），就是將高階智慧計算技術應用於大量資料中，讓計算機在有人或無人指導的情況下從海量資料中發現潛在的，有用的模式（也叫知識）。 > >Jiawei Han在《資料探勘概念與技術》一書中對資料探勘的定義：資料探勘是從大量資料中挖掘有趣模式和知識的過程，資料來源包括資料庫、資料倉庫、Web、其他資訊儲存庫或動態地流入系統的資料。  ### 4.5 支援資料應用 >物聯網基於位置資料的旅遊客流分析及人群畫像 > >通訊基於位置資料的人流監控和預警 > >銀行基於使用者交易資料的金融畫像應用 > >電商根據使用者瀏覽和購買行為的使用者標籤體系及推薦系統 > >徵信機構根據使用者信用記錄的信用評估 > >出行基於位置資料的車流量分析，排程預測 ## 5 資料集市 > 資料集市可以理解為是一種"小型資料倉庫"，它只包含單個主題，且關注範圍也非全域性。 > 資料集市可以分為兩種，一種是獨立資料集市(independent data mart)，這類資料集市有自己的源資料庫和ETL架構；另一種是非獨立資料集市(dependent data mart)，這種資料集市沒有自己的源系統，它的資料來自資料倉庫。當用戶或者應用程式不需要/不必要/不允許用到整個資料倉庫的資料時，非獨立資料集市就可以簡單為使用者提供一個數據倉庫的"子集"。 - 簡單理解： - 資料集市：部門級別的資料倉庫，能為某個區域性範圍內的管理人員提供服務。 - 資料倉庫：企業級別的資料倉庫，能為企業各個部門的執行提供決策支援。 ## 6 建模的基本概念 ### 6.1 關係建模  > 上圖為web應用中的一個建模片段，遵循三正規化建模，可以看出，較為鬆散、零碎， 物理表數量多，而資料冗餘程度低。由於資料分佈於眾多的表中，這些資料可以更為靈活地 被應用，功能性較強。關係模型主要應用與 OLTP 系統中，為了保證資料的一致性以及避免 冗餘，所以大部分業務系統的表都是遵循第三正規化的。 ### 6.2 維度建模 > 維度建模(dimensional modeling)是專門用於分析型資料庫、資料倉庫、資料集市建模的方法  > 上圖為維度模型建模片段，主要應用於 OLAP 系統中，通常以某一個事實表為中心進行表的 組織，主要面向業務，特徵是可能存在資料的冗餘，但是能方便的得到資料。 > > 關係模型雖然冗餘少，但是在大規模資料，跨表分析統計查詢過程中，會造成多表關聯，這會大大降低執行效率。所以通常我們採用維度模型建模，把相關各種表整理成兩種： 事實表和維度表兩種 ### 6.3 維度建模的三種模式  1. **星形模式**  > 星形模式(Star Schema)是最常用的維度建模方式 > > 可以看出，星形模式的維度建模由一個事實表和一組維表成，且具有以下特點： > > 1. 維表只和事實表關聯，維表之間沒有關聯； > 2. 每個維表的主碼為單列，且該主碼放置在事實表中，作為兩邊連線的邏輯外來鍵； > 3. 以事實表為核心，維表圍繞核心呈星形分佈； 2. **雪花模式**  > 雪花模式(Snowflake Schema)是對星形模式的擴充套件，每個維表可繼續向外連線多個子維表。(三正規化代表作) > > 星形模式中的維表相對雪花模式來說要大，而且不滿足規範化設計。雪花模型相當於將星形模式的大維表拆分成小維表，滿足了規範化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發難度增大，而資料冗餘問題在資料倉庫裡並不嚴重。 3. **星座模式**  > 星座模式(Fact Constellations Schema)也是星型模式的擴充套件。 > > 前面兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，星座模式將作為最主要的維度建模。 ### 6.4 維度表和事實表 1. **維度表(dimension)** > 表示對分析主題所屬型別的描述。比如"昨天早上張三在京東花費200元購買了一個皮包"。那麼以購買為主題進行分析，可從這段資訊中提取三個維度：時間維度(昨天早上)，地點維度(京東), 商品維度(皮包)。通常來說維度表資訊比較固定，且資料量小。 2. **事實表(fact table)** > 表示對分析主題的度量。比如上面那個例子中，200元就是事實資訊。事實表包含了與各維度表相關聯的邏輯外來鍵，並通過JOIN方式與維度表關聯。事實表的度量通常是數值型別，且記錄數會不斷增加，表規模迅速增長。 3. **事實維度舉例** > 昨天我去菜市場買了一隻蝙蝠，然後我就被隔離了。 > > - 事實：訂單==>買蝙蝠這個事 > > - 維度： > - 時間==>昨天 > - 使用者==>我 > - 商品==>蝙蝠 > - 地理==>菜市場 #### 6.4.1 維度表 > 維度表：一般是對事實的描述資訊。每一張維表對應現實世界中的一個物件或者概念。 例如：使用者、商品、日期、地區等。 > > 常用於一個客觀世界的維度描述，往往列比較多。 > > 審視資料的角度 - 維表的特徵： - 維表的範圍很寬（具有多個屬性、列比較多） - 跟事實表相比，行數相對較小：通常< 10 萬條 - 靜態表示的，名詞性質的表 #### 6.4.2 事實表 >事實表用於正確的記錄既定的已經發生的事實，常用於儲存ID和度量值，各種維度外來鍵 > >事實表中的每行資料代表一個業務事件（下單、支付、退款、評價等）。“事實”這 個術語表示的是業務事件的度量值（可統計次數、個數、件數、金額等），例如，訂單事件中的下單金額。 > >每一個事實表的行包括：具有可加性的數值型的度量值、與維表相連線的外來鍵、通常具 有兩個和兩個以上的外來鍵、外來鍵之間表示維表之間多對多的關係。 - 事實表的特徵： - 非常的大 - 內容相對的窄：列數較少 - 經常發生變化，每天會新增加很多 - 動態表示的，動詞性質的表 1. 事務型事實表(每天匯入新增) - 以每個事務或事件為單位，例如一個銷售訂單記錄，一筆支付記錄等，作為事實表裡的 一行資料。一旦事務被提交，事實表資料被插入，資料就不再進行更改，其更新方式為增量 更新 2. 週期型快照事實表(每日全量) - 週期型快照事實表中不會保留所有資料，只保留固定時間間隔的資料，例如每天或者 每月的銷售額，或每月的賬戶餘額等 3. 累積型快照事實表(每天匯入新增及變化) - 累計快照事實表用於跟蹤業務事實的變化。例如，資料倉庫中可能需要累積或者儲存 訂單從下訂單開始，到訂單商品被打包、運輸、和簽收的各個業務階段的時間點資料來跟蹤 訂單宣告週期的進展情況。當這個業務過程進行時，事實表的記錄也要不斷更新。 ### 6.5 資料分層 - 為什麼分層： - 簡單化：把複雜的任務分解為多層來完成，每層處理各自的任務，方便定位問題。 - 減少重複開發：規範資料分層，通過中間層資料，能夠極大的減少重複計算，增加結果複用性。 - 隔離資料：不論是資料異常還是資料敏感性，使真實資料和統計資料解耦。    > 下面列舉常見電商表的分層結構 #### 6.5.1 ODS層 - 保持資料原貌不做任何修改，起到備份資料的作用。 - 資料採用壓縮，減少磁碟儲存空間（例如：原始資料 100G，可以壓縮到 10G 左 右） - 建立分割槽表，防止後續的全表掃描 #### 6.5.2 DWD層 > DWD 層需構建維度模型，一般採用星型模型，呈現的狀態一般為星座模型。 - 維度建模一般按照四個步驟： 選擇業務過程→宣告粒度→確認維度→確認事實 - 選擇業務過程 - 在業務系統中，挑選我們感興趣的業務線，比如下單業務，支付業務，退款業務，物流 業務，一條業務線對應一張事實表。 - 宣告粒度 - 資料粒度指資料倉庫的資料中儲存資料的細化程度或綜合程度的級別。 - 宣告粒度意味著精確定義事實表中的一行資料表示什麼，應該儘可能選擇最小粒度，以 此來應各種各樣的需求。 - 典型的粒度宣告如下： - 訂單中，每個商品項作為下單事實表中的一行，粒度為每次下單 - 每週的訂單次數作為一行，粒度就是每週下單。 - 每月的訂單次數作為一行，粒度就是每月下單 - 確定維度 - 維度的主要作用是描述業務是事實，主要表示的是“誰，何處，何時”等資訊。 - 確定事實 - 此處的“事實”一詞，指的是業務中的度量值，例如訂單金額、下單次數等。 - 在 DWD 層，以業務過程為建模驅動，基於每個具體業務過程的特點，構建最細粒度的 明細層事實表。事實表可做適當的寬表化處理。  | 事實/維度 | 時間 | 使用者 | 地區 | 商品 | 優惠卷 | 活動 | 編碼 | 度量 | | ---------- | ---- | ---- | ---- | ---- | ------ | ---- | ---- | --------- | | 訂單 | √ | √ | √ | | | √ | | 件數/金額 | | 訂單詳情 | √ | | √ | √ | | | | 件數/金額 | | 支付 | √ | | √ | | | | | 次數/金額 | | 加入購物車 | √ | √ | | √ | | | | 件數/金額 | | 收藏 | √ | √ | | √ | | | | 個數 | | 評價 | √ | √ | | √ | | | | 個數 | | 退款 | √ | √ | | √ | | | | 件數/金額 | | 優惠卷領用 | √ | √ | | | √ | | | 個數 | #### 6.5.3 DWS層 - 統計各個主題物件的當天行為，服務於 DWT 層的主題寬表，以及一些業務明細資料， 應對特殊需求（例如，購買行為，統計商品復購率）。  #### 6.5.4 DWT層 - 以分析的主題物件為建模驅動，基於上層的應用和產品的指標需求，構建主題物件的全 量寬表。（就是按照維度來決定分析者的角度，如使用者->什麼時間->下了什麼單，支付了什麼，加入購物車了什麼）  #### 6.5.5 ADS層 > 對系統各大主題指標分別進行分析。