數倉系列 - 基本概念整理#
內容整理自:
一、數據倉庫和數據集市#
數據倉庫 (Data Warehouse)#
-
數據倉庫(Data Warehouse)是一種信息系統的資料儲存理論,此理論強調的是利用某些特殊的資料儲存方式,讓所包含的資料特別有利於分析和處理,從而產生有價值的資訊,並可依此做出決策。
-
數據倉庫是
面向主題的
、集成的
、不可更新的(穩定性)
、隨時間不斷變化
(不同時間)的數據集合
,用以支持經營管理中的決策支持系統(DDS:Decision Support System,主要是報表系統) -
利用數據倉庫的方式存放的資料,存入的資料必定包含時間屬性,具有一旦存入,便不會隨時間發生變動的特性。但是數倉隨著時間變化數據可能是不斷增長變化的。
數據集市 (Data Market)#
是一個小型的部門或工作組級別的數據倉庫
聯繫#
數據倉庫 | 數據集市 | |
---|---|---|
數據來源 | 遺留系統、OLTP 系統、外部數據 | 數據倉庫 |
範圍 | 企業級 | 部門級別或工作組級別 |
主題 | 企業主題 | 部門或特殊的分析主題 |
數據粒度 | 最細的粒度 | 較粗的粒度 |
數據結構 | 規範化結構(第三範式) | 星型模式、雪花模式、或兩者混合 |
歷史數據 | 大量的歷史數據 | 適度的歷史數據 |
優化 | 處理海量數據、數據探索 | 便於訪問與分析、快速查詢 |
索引 | 高度索引 | 高度索引 |
二、維度和度量#
維度:
指審視數據的角度,它通常是數據記錄的一個屬性,例如時間、地點等。
一般是一組離散的值,比如時間維度上的每一個獨立的日期,或者商品維度上的每一件獨立的商品。因此統計時可以把維度值相同的記錄聚合在一起,然後應用聚合函數做累加、平均、去重計數等聚合計算。
維度的基數 (Cardinality)
指的是該維度在數據集中出現的不同值的個數。例如 “國家” 是一個維度,如果有 200 個不同的值,那麼此維度的基數就是 200。
通常一個維度的基數會從幾十到幾萬不等,個別維度如 “用戶 ID” 的基數會超過百萬甚至千萬。基數超過一百萬的維度通常被稱為超高基數維度
(UltraHighCardinality,UHC)。
度量:
基於數據所計算出來的考量值;它一般是連續的值,如總銷售額、不同的用戶數等。
舉個例子:
一個 SQL 查詢中,GroupBy 的屬性通常就是維度,而所計算的值則是度量。如下面的示例:
SELECT
department,
site_id,
sum(price) AS total_sales,
count(DISTINCT seller_id) AS sellers
FROM kylin_sales
GROUP BY department, site_id
上面的這個查詢中,department
和site_id
是維度,sum(price)
和count(distinct seller_id)
是度量。
三、Cube 基本概念#
給定一個數據模型,我們可以對其上的所有維度進行組合。對於 N 個維度來說,組合的所有可能性共有 2^n 種。
- 對於一種維度的組合,將度量做聚合運算,然後將運算的結果保存為一個物化視圖,稱為
Cuboid
。 - 所有維度組合的 Cuboid 作為一個整體,被稱為
Cube
。所以簡單來說,一個 Cube 就是許多按維度聚合的物化視圖的集合
。 Cube Segment
是指針對源數據中的某一個片段,計算出來的 Cube 數據。通常數據倉庫中的數據數量會隨著時間的增長而增長,而 Cube Segment 也是按時間順序來構建的。
四、Hierarchy、Level 和 Member#
Cube 就像一個坐標系,每一個Hierarchy
代表了一個坐標軸,而 Hierarchy 中每一個Member
代表了坐標軸上的一個值。下圖以時間維度為例展示了 Dimension 的內部結構:
維是用於從不同角度描述事物特徵的,一般維都會有多層(Level)
,每個 Level 都會包含一些共有的或特有的屬性(Attribute)
,可以用下圖來展示下維的結構和組成:
以時間維為例,時間維一般會包含年、季、月、日這幾個 Level,每個 Level 一般都會有 ID、NAME、DESCRIPTION 這幾個公共屬性,這幾個公共屬性不僅適用於時間維,也同樣表現在其它各種不同類型的維。其中 ID 一般被視為代理主鍵(Agent),它只被用於作為唯一性標誌,並且是多維模型中關聯關係的代理者,在業務層面並不具有任何意義;NAME 一般是業務主鍵(Business),在業務層面限制唯一性,一般作為數據裝載(Load)時的關聯鍵;而 DESCRIPTION 則記錄了詳細描述信息,在多維展示和分析時我們都會選擇使用 DESCRIPTION 來表述具體含義。
上面這個結構的維是無法直接應用於 OLAP 的,OLAP 需要基於有層級的自上而下的鑽取,或者自下而上地聚合。所以每一個維必須有 Hierarchy,至少有一個默認的,當然可以有多個,見下圖:
有了 Hierarchy,維裡面的 Level 就有了自上而下的樹形結構關係,也就是上層的每一個成員(Member)都會包含下層的 0 個或多個成員,也就是樹的分支節點。這裡需要注意的是每個 Hierarchy 樹的根節點一般都設置成所有成員的匯總(Total),當該維未被 OLAP 中使用時,默認顯示的就是該維上的匯總節點,也就是該維所有數據的聚合(或者說該維未被用於細分)。Hierarchy 中的每一層都會包含若干個成員(Member),還是以時間維,假設我們建的是 2006-2015 這樣一個時間跨度的時間維,那麼最高層節點僅有一個 Total 的成員,包含了所有這 10 年的時間,而年的那層 Level 中包含 2006、2007…2015 這 10 個成員,每一年又包含了 4 個季度成員,每個季度包含 3 個月份成員…… 這樣似乎順理成章多了,我們就可以基於 Hierarchy 做一些 OLAP 操作了。
五、數據立方體 (Data Cube)#
數據立方體,是一種常用於數據分析與索引的技術;它可以對原始數據建立多維度索引,通過 Cube 對數據進行分析,可以大大加快數據的查詢效率。
數據立方體只是多維模型的一個形象的說法。立方體其本身只有三維,但多維模型不僅限於三維模型,可以組合更多的維度。一方面是出於更方便地解釋和描述,同時也是給思維成像和想象的空間;另一方面是為了與傳統關係型數據庫的二維表區別開來。
基本操作#
-
鑽取(Drill-down)
:在維的不同層次間的變化,從上層降到下一層,或者說是將匯總數據拆分到更細節的數據,比如通過對 2010 年第二度的總銷售數據進行鑽取來查看 2010 年第二季度 4、5、6 每個月的消費數據,如上圖;當然也可以鑽取浙江省來查看杭州市、波市、溫州市…… 這些城市的銷售數據。 -
上卷(Roll-up)
:鑽取的逆操作,即從細粒度數據向高層的聚合,如將江蘇省、上海市和浙江省的銷售數據進行匯總來查看江浙滬地區的銷售數據,如上圖。 -
切片(Slice)
:選擇維中特定的值進行分析,比如只選擇電子產品的銷售數據,或者 2010 年第二季度的數據。 -
切塊(Dice)
:選擇維中特定區間的數據或者某批特定值進行分析,比如選擇 2010 年第一季度到 2010 年第二季度的銷售數據,或者是電子產品和日用品的銷售數據。 -
旋轉(Pivot)
:即維的位置的互換,就像是二維表的行列轉換,如圖中通過旋轉實現產品維和地域維的互換。
六、事實表和維度表#
事實表 (FactTable)#
-
事實表(FactTable)是指存儲有事實記錄的表,包含了每個事件的具體要素,以及具體發生的事情,如系統日誌、銷售記錄等。
-
在事實表裡沒有存放實際的內容,它是一堆主鍵的集合,這些 ID 分別能對應到維度表中的一條記錄。
-
事實表的記錄在不斷地動態增長,所以它的體積通常遠大於其他表。
-
發生在現實世界中的操作型事件,其所產生的可度量數值,存儲在事實表中。從最低的粒度級別來看,事實表行對應一個度量事件,反之亦然。
維度表 (DimensionTable)#
-
維表,有時也稱查找表(LookupTable),是對事實表中事件的要素的描述信息。
-
它保存了維度的屬性值,可以跟事實表做關聯;相當於將事實表上經常重複出現的屬性抽取、規範出來用一張表進行管理。
-
常見的維度表有:日期表(存儲與日期對應的周、月、季度等的屬性)、地點表(包含國家、省/州、城市等屬性)等。
-
每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外鍵,當然,維度表行的描述環境應與事實表行完全對應。維度表通常比較寬,是扁平型非規範表,包含大量的低粒度的文本屬性。
七、OLAP 和 OLTP#
OLAP(Online Analytical Process)#
-
聯機分析處理,以基於數據倉庫多維度模型的基礎上實現的面向分析的各類操作的集合,而且能夠彈性地提供上卷(Roll-up)、下鑽(Drill-down)和透視分析(Pivot)等操作,它是呈現集成性決策信息的方法,多用於決策支持系統、商務智能或數據倉庫。
-
功能在於方便大規模數據分析及統計計算,可對決策提供參考和支持。
-
OLAP 需要以大量歷史數據為基礎,再配合上時間點的差異,對多維度及匯整型的信息進行複雜的分析。
-
OLAP 需要用戶有主觀的信息需求定義,因此系統效率較佳。
OLAP 的概念,在實際應用中存在廣義和狹義兩種不同的理解方式。廣義上的理解與字面上的意思相同,泛指一切不會對數據進行更新的分析處理。但更多的情況下 OLAP 被理解為其狹義上的含義,即與多維分析相關,基於立方體(Cube)計算而進行的分析。
類型#
MOLAP (Multidimensional), 多維 OLAP#
-
將 OLAP 分析用到的多維數據物理上存儲為多維數組的形式,形成 “立方體” 的結構,維的屬性值被映射為多維數組的下標值或下標的範圍,而匯總數據作為多維數組的值存儲在數組的單元中。
-
此結構在得到高度優化後,可以最大程度地提高查詢性能。
-
由於採用了新的存儲結構,從物理層實現起,因此又被稱為物理 OLAP(Physical OLAP);而 RLOAP 主要通過一些軟件工具或中間軟件實現,物理上仍採用關係數據庫的存儲結構,因此稱為虛擬 OLAP(Virtual OLAP)。
-
MOLAP 的優勢在於由於經過了數據多維預處理,分析中數據運算效率高,主要的缺陷在於數據更新有一定延滯。
ROLAP (Relational),關係 OLAP#
-
表示基於關係數據庫的 OLAP 實現。以關係數據庫為核心,以關係型結構進行多維數據的表示和存儲。ROLAP 將多維數據庫的多維結構劃分為兩類表:一類是事實表,用來存儲數據和維關鍵字;另一類是維表,即對每個維至少使用一個表來存放維的層次、成員類別等維的描述信息。
-
維表和事實表通過主關鍵字和外關鍵字聯系在一起,形成了 “星型模式”。
-
對於層次複雜的維,為避免冗餘數據佔用過大的存儲空間,可以使用多個表來描述,這種星型模式的擴展稱為 “雪花模式”。
-
用作 RLOAP 存儲器的 RDBMS 也針對 OLAP 作相應的優化,比如並行存儲、並行查詢、並行數據管理、基於成本的查詢優化、位圖索引、SQL 的 OLAP 擴展(cube、rollup)等。
HOLAP (Hybrid) 混合型 OLAP#
表示基於混合數據組織的 OLAP 實現(Hybrid OLAP),用戶可以根據自己的業務需求,選擇哪些模型採用 ROLAP,哪些採用 MOLAP。
對比分析#
一般來說,會將非常用或需要靈活定義的分析使用 ROLAP 方式,而常用、常規模型採用 MOLAP 實現。如將明細數據保留在關係數據庫的事實表中,但是聚合後的數據保存在 Cube 中,聚合時需要比 RLOAP 更多的時間,查詢效率比 RLOAP 高,但低於 MLOAP。
OLTP (On-line Transaction Processing)#
-
數據量少,DML 頻繁,並行事務處理多,但是一般都很短。
-
聯機交易處理,更側重於基本的、日常的事務處理,包括數據的增刪改查。
OLAP 與 OLTP 區別#
類似於數據庫與數據倉庫的區別:
- 數據庫系統的設計目標是事務處理。數據庫系統是為記錄更新和事務處理而設計,數據的訪問的特點是基於主鍵,大量原子,隔離的小事務,並發和可恢復是關鍵屬性,最大事務吞吐量是關鍵指標,因此數據庫的設計都反映了這些需求。
- 數據倉庫的設計目標是決策支持。歷史的,摘要的,聚合的數據比原始的記錄重要的多。查詢負載主要集中在即席查詢和包含連接,聚合等操作的複雜查詢。相對於數據庫系統來說,查詢吞吐量和響應時間比事務處理吞吐量重要的多。
數據處理類型 | OLTP | OLAP |
---|---|---|
面向對象 | 業務開發人員 | 分析決策人員 |
功能實現 | 日常事務處理 | 面向分析決策 |
數據模型 | 關係模型 | 多維模型 |
數據量 | 幾條或幾十條記錄 | 百萬千萬條記錄 |
操作類型 | 查詢、插入、更新、刪除 | 查詢為主 |
八、元數據#
元數據(Meta Data)是關於數據的數據,當人們描述現實世界的現象時,就會產生抽象信息,這些抽象信息便可以看作是元數據,元數據主要用來描述數據的上下文信息。通俗的來講,假若圖書館的每本書中的內容是數據的話,那麼找到每本書的索引則是元數據。按其描述對象的不同可以劃分為三類元數據:技術元數據
、業務元數據
和管理元數據
:
技術元數據
: 技術元數據是描述數據系統中技術領域相關概念、關係和規則的數據,主要包括對數據結構、數據處理方面的特徵描述,覆蓋數據源接口、數據倉庫與數據集市存儲、ETL、OLAP、數據封裝和前端展現等全部數據處理環節;業務元數據
: 業務元數據是描述數據系統中業務領域相關概念、關係和規則的數據,主要包括業務術語、信息分類、指標定義和業務規則等信息;管理元數據
: 管理元數據是描述數據系統中管理領域相關概念、關係和規則的數據,主要包括人員角色、崗位職責和管理流程等信息。
具體參考鏈接: 聊一聊數據倉庫中的元數據管理系統