大資料篇:一文讀懂@資料倉庫(PPT文字版)
大資料篇:一文讀懂@資料倉庫
1 網絡詞彙總結
1.1 資料中台
- 資料中台是聚合和治理跨域資料,将資料抽象封裝成服務,提供給前台以業務價值的邏輯概念。
- 資料中台是一套可持續“讓企業的資料用起來”的機制,一種戰略選擇群組織形式,是依據企業特有的業務模式群組織架構,通過有形的産品和實施方法論支撐,建構一套持續不斷把資料變成資産并服務于業務的機制。
- 資料中台連接配接資料前台和背景,突破資料局限,為企業提供更靈活、高效、低成本的資料分析挖掘服務,避免企業為滿足具體某部門某種資料分析需求而投放大量高成本、重複性的資料開發成本。
- 資料中台是指通過資料技術,對海量資料進行采集、計算、存儲、加工,同時統一标準和口徑。資料中台把資料統一之後,會形成标準資料,再進行存儲,形成大資料資産層,進而為客戶提供高效服務。
- 資料中台,包括平台、工具、資料、組織、流程、規範等一切與企業資料資産如何用起來所相關的。
可以看出,資料中台是解決如何用好資料的問題,目前還缺乏一個标準,而說到資料中台一定會提及大資料,而大資料又是由資料倉庫發展起來的。
1.1.1 資料倉庫(Data WareHouse)
- 資料倉庫,按照傳統的定義,資料倉庫是一個面向主題的、內建的、非易失的、反映曆史變化(随時間變化),用來支援管理人員決策的資料集合。
為企業所有決策制定過程,提供所有系統資料支援的戰略集合
- 面向主題
操作型資料庫的資料組織面向事務處理任務,各個業務系統之間各自分離,而資料倉庫中的資料是按照一定的主題域進行組織。
主題是一個抽象的概念,是資料歸類的标準,是指使用者使用資料倉庫進行決策時所關心的重點方面,一個主題通常與多個操作型資訊系統相關。每一個主題基本對應一個宏觀的分析領域。
例如,銀行的資料倉庫的主題:客戶
客戶資料來源:從銀行儲蓄資料庫、信用卡資料庫、貸款資料庫等幾個資料庫中抽取的資料整理而成。這些客戶資訊有可能是一緻的,也可能是不一緻的,這些資訊需要統一整合才能完整展現客戶。
- 內建
面向事務處理的操作型資料庫通常與某些特定的應用相關,資料庫之間互相獨立,并且往往是異構的。而資料倉庫中的資料是在對原有分散的資料庫資料抽取、清理的基礎上經過系統加工、彙總和整理得到的,必須消除源資料中的不一緻性,以保證資料倉庫内的資訊是關于整個企業的一緻的全局資訊。
具體如下:
1:資料進入資料倉庫後、使用之前,必須經過加工與內建。
2:對不同的資料來源進行統一資料結構和編碼。統一原始數 據中的所有沖突之處,如字段的同名異義,異名同義,機關不統一,字長不一緻等。
3:将原始資料結構做一個從面向應用到面向主題的大轉變。
- 非易失即相對穩定的
操作型資料庫中的資料通常實時更新,資料根據需要及時發生變化。資料倉庫的資料主要供企業決策分析之用,所涉及的資料操作主要是資料查詢,一旦某個資料進入資料倉庫以後,一般情況下将被長期保留,也就是資料倉庫中一般有大量的查詢操作,但修改和删除操作很少,通常隻需要定期的加載、重新整理。
資料倉庫中包括了大量的曆史資料。
資料經內建進入資料倉庫後是極少或根本不更新的。
- 随時間變化即反映曆史變化
操作型資料庫主要關心目前某一個時間段内的資料,而資料倉庫中的資料通常包含曆史資訊,系統記錄了企業從過去某一時點(如開始應用資料倉庫的時點)到目前的各個階段的資訊,通過這些資訊,可以對企業的發展曆程和未來趨勢做出定量分析和預測。企業資料倉庫的建設,是以現有企業業務系統和大量業務資料的積累為基礎。資料倉庫不是靜态的概念,隻有把資訊及時交給需要這些資訊的使用者,供他們做出改善其業務經營的決策,資訊才能發揮作用,資訊才有意義。而把資訊加以整理歸納和重組,并及時提供給相應的管理決策人員,是資料倉庫的根本任務。是以,從産業界的角度看,資料倉庫建設是一個工程,是一個過程
資料倉庫内的資料時限一般在5-10年以上,甚至永不删除,這些資料的鍵碼都包含時間項,标明資料的曆史時期,友善做時間趨勢分析。
- 資料倉庫,并不是資料最終目的地,而是為資料最終的目的地做好準備:清洗、轉義、分類、重組、合并、拆分、統計等等
通過對資料倉庫中資料的分析,可以幫助企業,改進業務流程、控制、成本、提高産品品質等
- 主要解決問題:資料報表,資料沉澱,資料計算Join過多,資料查詢過慢等問題。
防止煙囪式開發,減少重複開發,開發通用中間層資料,減少重複計算;
将複雜問題簡單化,将複雜任務的多個步驟分解到各個層次中,每一層隻處理較少的步驟,使單個任務更容易了解;
可進行資料血緣追蹤,便于快速定位問題;
整個資料層次清晰,每個層次的資料都有職責定位,便于使用和了解。
- 主要價值展現:企業資料模型,這些模型随着前端業務系統的發展變化,不斷變革,不斷追加,不斷豐富和完善,即使系統不再了,也可以在短期内快速重建起來,這也是大資料産品能夠快速疊代起來的一個重要原因
- 數倉硬體架構圖
- 數倉功能架構圖
- 數倉流程架構圖1
- 數倉流程架構圖2
- 實時數倉流程架構圖
總結:資料倉庫,即為企業資料的模型沉澱,為了能更快的發展大資料應用,提供可靠的模型來快速疊代。本文也主要為了講解資料倉庫
- 拓展:血緣圖
- 拓展:BI層
- 拓展:BI圖
1.1.2 大資料平台(DATA Platform)
- 大資料平台則是指以處理海量資料存儲、計算及流資料實時計算等場景為主的一套基礎設施,包括了統一的資料采集中心、資料計算和存儲中心、資料治理中心、運維管控中心、開放共享中心和應用中心。
- 大資料平台的建設出發點是節約投資降低成本,但實際上無論從硬體投資還是從軟體開發上都遠遠超過資料倉庫的建設,大量的硬體和各種開源技術的組合,增加了研發的難度、調測部署的周期、運維的複雜度,人力上的投入已是最初的幾倍;還有很多技術上的困難也非一朝一夕能夠突破。
- 首先是資料的應用問題,無論是資料倉庫還是大資料平台,裡面包含了接口層資料、存儲層資料、輕度彙總層、重度彙總層、模型層資料、報表層資料等等,各種各樣的表有成千上萬,這些表有的是中間處理過程,有些是一次性的報表,不同表之間的資料一緻性和口徑也會不同,而且不同的表不同的字段對資料安全要求級别也不同。
- 此外還要考慮多租戶的資源安全管理,如何讓内部開發者快速擷取所需的資料資産目錄,如何閱讀相關資料的來龍去脈,如何快速的實作開發,這些在大資料平台建設初期沒有考慮周全。
- 另外一個問題是對外應用,随着大資料平台的應用建設,每一個對外應用都采用單一的資料庫加單一應用建設模式,獨立考慮網絡安全、資料安全、共享安全,逐漸又走向了煙囪似的開發道路。
- 平台資料流向圖
- 平台流程架構圖
總結:大資料平台,即為資料一站式服務,提供可視化的資料展示,提取,計算任務安排,資源管理,資料治理,安全措施,共享應用等等。
1.1.3 資料中台(Data Middle Platform)
- 資料中台要解決什麼?資料如何安全的、快速的、最小權限的、且能夠溯源的被探測和快速應用的問題。
- 資料中台不應該被過度的承載平台的計算、存儲、加工任務,而是應該放在解決企業邏輯模型的搭建和存儲、資料标準的建立、資料目錄的梳理、資料安全的界定、資料資産的開放,知識圖譜的建構。
- 通過一系列工具、組織、流程、規範,實作資料前台和背景的連接配接,突破資料局限,為企業提供更靈活、高效、低成本的資料分析挖掘服務,避免企業為滿足具體某部門某種資料分析需求而投放大量高成本、重複性的資料開發成本。
- 中台架構圖
- 阿裡資料中台架構圖
總結:厚平台,大中台,小前台;沒有基礎厚實笨重的大資料平台,是不可能建構資料能力強大、功能強大的資料中台的;沒有大資料中台,要迅速搭建小快靈的小前台也隻是理想化的。
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 次元表
- 一般是對事實的描述資訊。每一張維表對應現實世界中的一個對象或者概念。 例如:使用者、商品、日期、地區等。
- 常用于一個客觀世界的次元描述。(具有多個屬性、列比較多)
- 審視資料的角度。(如使用者,商品)
- 行數相對較小:通常< 10 萬條。(對比事實表)
- 靜态表示的,名詞性質的表。(如地理,時間,狀态)
- 變化較慢。(新增修改操作較少)
- 維表的特征:
- 維表的範圍很寬(具有多個屬性、列比較多)
- 跟事實表相比,行數相對較小:通常< 10 萬條
- 靜态表示的,名詞性質的表
6.3.2 事實表
- 事實表用于正确的記錄既定的已經發生的事實,常用于存儲ID和路徑成本,各種次元外鍵
- 事實表中的每行資料代表一個業務事件(下單、支付、退款、評價等)。“事實”這 個術語表示的是業務事件的路徑成本(可統計次數、個數、件數、金額等),例如,訂單事件中的下單金額。
- 每一個事實表的行包括:具有可加性的數值型的路徑成本、與維表相連接配接的外鍵、通常具 有兩個和兩個以上的外鍵、外鍵之間表示維表之間多對多的關系。
- 行數相對較多。(對比次元表)
- 列數較少。(不是絕對)
- 變化較快。(新增修改操作較多)
- 動态表示的,動詞性質的表。(如下單,優惠卷領用)
- 事實表導入政策一般有三種劃分:事務型事實表,周期型快照事實表,累積型快照事實表
劃分/比較點 | 事務情況 | 導入政策 |
---|---|---|
事務型事實表 | 以每個事務或事件為機關,例如一個銷售訂單記錄,一筆支付記錄等,作為 事實表裡的一行資料。一旦事務被送出,事實表資料被插入,資料就不再進 行更改,其更新方式為增量更新 | 每天導入新增 |
周期型快照事實表 | 周期型快照事實表中不會保留所有資料,隻保留固定時間間隔的資料,例如 每天或者每月的銷售額,或每月的賬戶餘額等 | 每日全量 |
累積型快照事實表 | 累計快照事實表用于跟蹤業務事實的變化。例如,資料倉庫中可能需要累積 或者存儲訂單從下訂單開始,到訂單商品被打包、運輸、和簽收的各個業務 階段的時間點資料來跟蹤 訂單聲明周期的進展情況。當這個業務過程進行時 ,事實表的記錄也要不斷更新 | 每天導入新增及變化 |