# 大資料篇：一文讀懂@資料倉庫   ## 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 維度建模四個步驟 ![](https://img2020.cnblogs.com/blog/1235870/202007/1235870-20200724180305129-3844660