資料倉儲概念
- 可以把資料倉儲認為是一個國道彙總到高速的一個高速中轉站,負責收集這些不同地方來源的資料,統一歸納整理好再放到高速上去用,達到高效資料中轉的效果
- 資料倉儲的目的就是為了統籌集中所有可以使用的資料,構建面向分析的整合資料環境,透過最終資料分析結果為企業提供決策導向支援
- 對於整個資料倉儲而言,它不需要生產資料,也不用消費資料,而是透過數倉的一系列處理運算操作,將結果提供給外部
資料倉儲整體架構
ODS層(Operational Data Store)
- 操作型資料儲存層
- 用於儲存從業務系統中抽取的原始資料,資料一般未經處理或僅進行了簡單的清洗,保持其原始狀態
DWD層(Data Warehouse Detail)
- 明細資料層
- 將ODS層的原始資料進行清洗、轉換,儲存詳細的、經處理的資料,用於支援詳細的業務分析需求
DWS層(Data Warehouse Summary)
- 彙總資料層
- 對DWD層的資料進行聚合和彙總,生成更高層次的統計資料和指標,便於快速查詢和分析
DIM層(Dimension)
- 維度資料層
- 儲存用於資料分析的維度資料,這些維度資料描述了事實表中的度量資料的上下文,如時間、地點、產品、客戶等
ADS層(Application Data Store)
- 應用資料層
- 儲存為特定應用或分析需求準備的彙總資料,支援特定的業務應用、報表和分析需求
數倉三層架構
資料採集層
- 首先我們需要儲存對應業務相關的資料,透過外部來源資料進行整合
- 因為資料來源不同,非一致性質格式資料,需要透過ETL進行資料的轉換處理,統一格式放入我們的資料倉儲中
資料加工層
- 數倉核心功能,需要將彙總的資料全部處理成我們可以進行分析的資料,不希望損失原始資料資訊
- 一般我們將資料倉儲分為三層,自下而上,逐層提取精煉
資料引入層ODS(Operational Data Store)
- 一般來說ODS可以說得上是作為一張原始資料表的對映表,存放未經過處理的原始資料至資料倉儲系統,結構上與原始資料資訊保持一致,是資料倉儲的資料準備快取區
- 還可以起到儲存歷史資料記錄的作用,也可增加欄位,儲存的歷史資料是隻讀的
在離線數倉中,業務資料定期透過ETL流程匯入到ODS中,匯入方式有:
- 全量匯入:資料第一次匯入時,選擇此種方式
- 增量匯入:資料非第一次匯入,每次只需要匯入新增、更改的資料,建議使用外連線&全覆蓋方式
資料公共層CDM(Common Data Model)
- 又稱通用資料模型層,包括DIM維度表、DWD和DWS,由ODS層資料加工而成
- 主要完成資料加工與整合,建立一致性的維度,構建可複用的面向分析和統計的明細事實表,以及彙總公共粒度的指標
- 最後為ADS層服務,那麼首先要提取出業務以及分析主題兩個抽象事物,需要統一口徑
說明 | 案例 | |
---|---|---|
公共維度彙總層DIM(Dimension) | 主要由維度表(維表)構成,公共維度彙總層(DIM)首先需要定義維度,建立整個企業的一致性維度,降低資料計算口徑和演算法不統一風險 | 對於招標業務,可能需要考慮的維度有:招標專案、招標公司、招標類別、地理區域、時間維度(年、季度、月、日)、專案負責人、投標狀態 |
明細粒度事實層DWD(Data Warehouse Detail) | 將ODS層中的原始資料進行清洗和轉換,可以結合企業的資料使用特點,將明細事實表的某些重要維度屬性欄位做適當冗餘,即寬表化處理,明細粒度事實層的表通常也被稱為邏輯事實表 | 對於招標業務,招標明細可能有:招標專案ID、招標專案名稱、招標類別ID、地區ID、專案負責人ID、投標公司ID、投標金額、投標日期、投標狀態、投標次數等 |
公共彙總粒度事實層DWS(Data Warehouse Summary) | 將詳細的資料進行彙總,公共彙總粒度事實層的表通常也被稱為彙總邏輯表,用於存放派生指標資料,首先確定需要進行彙總的資料以及彙總的維度和指標,接著設計彙總粒度的事實表結構,選擇合適的度量值和維度 | 對於招標業務,可能需要按時間、地區、投標公司、招標類別、專案負責人維度進行彙總,彙總度量值可能有總投標金額、中標金額、投標次數、中標次數等 |
- 維度是邏輯概念,是衡量和觀察業務的角度,維表是根據維度及其屬性將資料平臺上構建的物理化的表,採用寬表設計的原則
程式碼舉例
-- 建立DWS彙總事實表
CREATE TABLE DWS_招標彙總 (
時間ID INT,
地區ID INT,
投標公司ID INT,
招標類別ID INT,
專案負責人ID INT,
總投標金額 DECIMAL(18, 2),
中標金額 DECIMAL(18, 2),
投標次數 INT,
中標次數 INT,
PRIMARY KEY (時間ID, 地區ID, 投標公司ID, 招標類別ID, 專案負責人ID)
);
-- 插入彙總資料到DWS_招標彙總表
INSERT INTO DWS_招標彙總 (時間ID, 地區ID, 投標公司ID, 招標類別ID, 專案負責人ID, 總投標金額, 中標金額, 投標次數, 中標次數)
SELECT
時間ID,
地區ID,
投標公司ID,
招標類別ID,
專案負責人ID,
SUM(投標金額) AS 總投標金額,
SUM(CASE WHEN 投標狀態 = '中標' THEN 投標金額 ELSE 0 END) AS 中標金額,
COUNT(*) AS 投標次數,
SUM(CASE WHEN 投標狀態 = '中標' THEN 1 ELSE 0 END) AS 中標次數
FROM
FACT_招標
GROUP BY
時間ID,
地區ID,
投標公司ID,
招標類別ID,
專案負責人ID;
資料應用層ADS
- 存放資料產品個性化的統計指標資料,根據CDM與ODS層加工生成
- 主要是提供給資料產品和資料分析使用的資料,一般會存放在ES、PostgreSql、Redis等系統中供線上系統使用,也可能會存在Hive或者Druid中供資料分析和資料探勘使用
資料倉儲 VS 資料庫
資料倉儲 | 資料庫 | |
---|---|---|
設計目的 | 主要用於線上分析處理(OLAP),支援複雜的查詢和資料分析 | 主要用於線上事務處理(OLTP),支援日常業務操作和事務處理 |
功能 | 聚合、清洗和轉換大量的歷史資料,支援決策支援系統(DSS)和商業智慧(BI)應用 | 處理頻繁的資料插入、更新和刪除操作,確保資料的實時性和一致性 |
使用場景 | 用於支援資料分析和商業報告,如市場分析、銷售趨勢分析、財務報表分析等 | 用於支援業務應用程式,如電子商務網站、銀行交易系統、企業資源規劃(ERP)系統等 |
資料結構 | 通常是非規範化的(如星型或雪花型模式),以提高查詢效能和分析效率 | 通常是高度規範化的(第三正規化),以減少資料冗餘和提高資料一致性 |
儲存方式 | 儲存大量的歷史資料,資料量龐大,資料更新頻率較低 | 儲存當前的運算元據,資料量相對較小,資料頻繁更新 |
示例 | 銷售事實表、客戶維度表、時間維度表等 | 客戶資訊表、訂單表、庫存表等 |
最佳化目標 | 最佳化查詢效能,支援複雜的多維分析和大規模資料處理 | 最佳化事務處理效能,確保快速的讀寫操作 |
技術 | 使用分割槽、聚合索引、物化檢視等技術來提高查詢速度 | 使用索引、事務處理、鎖機制等技術來保證資料一致性和操作效能 |
資料處理 | 處理批次資料,資料從多個源系統抽取、轉換後載入(ETL) | 處理實時資料,支援併發的讀寫操作 |
資料載入 | 通常透過ETL流程進行批次資料載入,資料載入過程可能在非高峰期進行 | 主要透過應用程式直接插入或更新資料 |
使用者 | 主要是資料分析師、資料科學家、商業使用者,進行資料分析和報表生成 | 主要是應用程式和終端使用者,進行日常的業務操作 |
操作型別 | 複雜的查詢和分析操作,注重資料的整合和歷史資料分析 | CRUD操作(建立、讀取、更新、刪除),注重事務的原子性和一致性 |
資料整合 | 處理多個業務領域的資料,整合度較高,跨多個系統和資料來源 | 通常處理單一業務領域的資料,整合度較低 |
資料來源 | 來自多個異構資料來源,包括內部業務系統、外部資料來源、日誌資料等 | 主要來自內部業務系統 |
資料規模 | >=TB | GB到TB |
資料倉儲基本特徵
- 資料倉儲是面向主題設計的,屬於OLAP(線上分析處理)系統,主要操作是批次讀寫,關注資料整合,以及分析、處理效能,會有意引入榮譽,採用反正規化方式設計
- 面向主題:資料倉儲以主題為導向來組織資料,而不是以應用程式或事務為導向,主題可以是銷售、客戶、產品、財務等,它們反映了業務的主要領域,這種主題導向的資料組織方式便於使用者進行跨部門和跨業務領域的分析
- 整合性:整合了來自多個異構資料來源的資料
- 非易失性:一旦資料被載入到資料倉儲中,通常不會被更新或刪除,資料倉儲中的資料是隻讀的,新的資料會定期載入進資料倉儲,而不是對現有資料進行更新
- 時變性:資料倉儲儲存隨時間變化的歷史資料,這意味著資料倉儲中的每個資料記錄都與一個特定的時間點或時間段相關聯
- 面向分析:資料倉儲的設計和最佳化是為了支援複雜的查詢和資料分析,支援多維分析(OLAP)和資料探勘(Data Mining)
- 支援決策支援系統:資料倉儲是企業決策支援系統(DSS)的核心,旨在為管理層提供可靠的資料基礎,支援戰略決策、業務規劃和運營管理。它能夠整合不同業務領域的資料,提供跨部門的分析能力