BI/數據倉庫/數據分析基礎入門：一些常見概念解釋

本文轉載自查看原文 2021-08-18 08:26 137 主數據

Preface：本文將會講述 BI/DW/DA 領域的一些常見概念，如：事實表、維度表、建模、多維分析、cube 等，但不涉及具體實例分析。

1、維（Dimension）

維是用於從不同角度描述事物特征的，一般維都會有多層（Level：級別），每個Level都會包含一些共有的或特有的屬性（Attribute），可以用下圖來展示下維的結構和組成：

Dimension

以時間維為例，時間維一般會包含年、季、月、日這幾個Level，每個Level一般都會有ID、NAME、DESCRIPTION這幾個公共屬性，這幾個公共屬性不僅適用於時間維，也同樣表現在其它各種不同類型的維。其中ID一般被視為代理主鍵（Agent），它只被用於作為唯一性標志，並且是多維模型中關聯關系的代理者，在業務層面並不具有任何意義；NAME一般是業務主鍵（Business），在業務層面限制唯一性，一般作為數據裝載（Load）時的關聯鍵；而DESCRIPTION則記錄了詳細描述信息，在多維展示和分析時我們都會選擇使用DESCRIPTION來表述具體含義。

多維數據模型是為了滿足用戶從多角度多層次進行數據查詢和分析的需要而建立起來的基於事實和維的數據庫模型，其基本的應用是為了實現OLAP（Online Analytical Processing）。
當然，通過多維數據模型的數據展示、查詢和獲取就是其作用的展現，但其真的作用的實現在於，通過數據倉庫可以根據不同的數據需求建立起各類多維模型，並組成數據集市開放給不同的用戶群體使用，也就是根據需求定制的各類數據商品擺放在數據集市中供不同的數據消費者進行采購。

2、Hierarchy 層次

因為上面這個結構的維是無法直接應用於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操作了。

3、事實表

實表是用來記錄具體事件的，也就是你要關注的內容，包含了每個事件的具體要素，以及具體發生的事情。事實表中以數字型為主，包含了度量信息。比如用戶交易流水表。

4、維表

維表則是對事實表中事件的要素的描述信息，就是你觀察該事務的角度，是從哪個角度去觀察這個內容的。維度表常以文本類型為主，常常被作為事實表的“上下文”。一般用來解釋事實表中關鍵字緯度的具體內容，為那些度量數值添加了業務意義。比如用戶屬性表。

5、圖解事實表與維度表

基於事實表和維表就可以構建出多種多維模型，包括星形模型、雪花模型和星座模型。這里不再展開了，解釋概念真的很麻煩，而且基於我的理解的描述不一定所有人都能明白，還是直接上實例吧：

Star-Schemas

這是一個最簡單的星形模型的實例。事實表里面主要包含兩方面的信息：維和度量，維的具體描述信息記錄在維表，事實表中的維屬性只是一個關聯到維表的鍵，並不記錄具體信息；度量一般都會記錄事件的相應數值，比如這里的產品的銷售數量、銷售額等。維表中的信息一般是可以分層的，比如時間維的年月日、地域維的省市縣等，這類分層的信息就是為了滿足事實表中的度量可以在不同的粒度上完成聚合，比如2010年商品的銷售額，來自上海市的銷售額等。
還有一點需要注意的是，維表的信息更新頻率不高或者保持相對的穩定，例如一個已經建立的十年的時間維在短期是不需要更新的，地域維也是；但是事實表中的數據會不斷地更新或增加，因為事件一直在不斷地發生，用戶在不斷地購買商品、接受服務。

注：雪花模型是當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其圖解就像多個雪花連接在一起，故稱雪花模型。雪花模型是對星型模型的擴展。相比星型模型，雪花模型的特點是貼近業務，數據冗余較少，但由於表連接的增加，導致了效率相對星型模型來的要低一些。

6、立方體 Cube

這里所說的立方其實就是多維模型中間的事實表（Fact Table），它會引用所有相關維的維主鍵作為自身的聯合主鍵，加上度量（Measure）和計算度量（Calculated Measure）就組成了立方的結構：

度量是用於描述事件的數字尺度，比如網站的瀏覽量（Pageviews）、訪問量（Visits），再如電子商務的訂單量、銷售額等。度量是實際儲存於物理表中的，而計算度量則沒有，計算度量是通過度量計算得到的，比如同比（如去年同期的月利潤）、環比（如上個月的利潤）、利率（如環比利潤增長率）、份額（如該月中某類產品利潤所占比例）、累計（如從年初到當前的累加利潤）、移動平均（如最近7天的平均利潤額）等，這些計算度量在Oracle中都可以借助分析函數直接計算得到，相信大部分的OLAP組件都會提供類似在時間序列上的分析功能。而這些計算度量往往對於分析而言更具意義，立方中借助與各個維的關聯關系從不同的角度和層面來展現這些度量。

cube 一般是經過大量聚類運算好的而加以用特定方式存貯的多維報表，多拉幾個維度構成的報表雖然也有分析功能，但是它是死的，而cube可以進行任意維度角度組合去看待數據，分析的味道更濃一些。對於cube, 你可以把它想像成一個魔方的客觀形態(其實cube的維數一般比魔方的三維要多);而數據OLAP就是要從中抽取數據; 一個cube基於一個主題, 並且分為幾個維, 維是圍繞主題的;
舉例：基於銷售的方體(cube) 主題是銷售，維是city; item; day; buyer; 等等，基於 cube，我們可以快速抽取和計算數據。

7、數據模型與數據建模

模型是對現實世界的抽象，設計數據庫系統時，一般會事先用抽象的圖表（ER圖）反映數據彼此之間的關系，稱為建立數據模型。數據模型是數據庫管理系統用來表示實體與實體間聯系的方法。在設計數據庫時，對業務進行分析、抽象、並從中找出內在聯系，進而確定數據庫的結構，這一過程就稱為數據建模。

數據模型與數據建模的過程就是用標准來定義、規范數據。合理的業務模型設計對ETL至關重要。數據倉庫是企業惟一、真實、可靠的綜合數據平台。數據倉庫的設計建模一般都依照三范式、星型模型、雪花模型，無論哪種設計思想，都應該最大化地涵蓋關鍵業務數據，把運營環境中雜亂無序的數據結構統一成為合理的、關聯的、分析型的新結構，而ETL則會依照模型的定義去提取數據源，進行轉換、清洗，並最終加載到目標數據倉庫中。
模型的重要之處在於對數據做標准化定義，實現統一的編碼、統一的分類和組織。標准化定義的內容包括：標准代碼統一、業務術語統一。ETL依照模型進行初始加載、增量加載、緩慢增長維、慢速變化維、事實表加載等數據集成，並根據業務需求制定相應的加載策略、刷新策略、匯總策略、維護策略。

8、數據模型的定義

數據模型按不同的應用層次分成三種類型：分別是概念數據模型、邏輯數據模型、物理數據模型。概念數據模型（Conceptual Data Model）簡稱概念模型，是面向數據庫用戶的實現世界的模型，主要用來描述世界的概念化結構，它使數據庫的設計人員在設計的初始階段，擺脫計算機系統及DBMS的具體技術問題，集中精力分析數據以及數據之間的聯系等，與具體的數據管理系統（Database Management System，簡稱DBMS）無關。概念數據模型必須換成邏輯數據模型，才能在DBMS中實現。邏輯數據模型是業務抽象到DBMS中，物理數據模型是邏輯數據模型的具體實現。

數據倉庫的物理模型較常見的操作型數據庫的物理模型有很大不同。最明顯的區別是：操作型數據庫主要是用來支撐即時操作，對數據庫的性能和質量要求都比較高，為了防止“garbage in，garbage out”，通常設計操作型數據庫的都要遵循幾個范式的約束，除非少數情況下為了性能進行妥協，才可能出現冗余。而數據倉庫的建立並不上為了支撐即時操作，或者說，數據倉庫的數據是來源於即時操作產生的數據，而不是直接來源於即時操作。所以它的數據質量是由操作性系統來保證的，而不是由幾個范式來保證的。而且為了更好的跟蹤歷史信息，以及更快的產生報表，數據倉庫的物理模型中存在着大量冗余字段。
數據倉庫的物理模型分為星型和雪花型兩種。所謂星型，就是將模型中只有一個主題，其他的表中存儲的都是主題的一些特征。比如貨物銷量的主題倉庫中，每次出售記錄是事實表，而時間，售貨員，商品是維度，都和事實表有聯系，組織起來就是星型。而如果更細化來看，商品是有種類，產地，價格等特征的，從這個角度來看，有兩個主題，一個是商品出售，一個是商品本身。組織起來就是雪花型。實際項目中，由於操作型系統業務的復雜性導致本身產生了大量的數據，所以，組織起來也以雪花型居多。

9、事實表和維度表的分界線

事實表是用來存儲主題的主干內容的。以日常的工作量為例，工作量可能具有如下屬性：工作日期，人員，上班時長，加班時長，工作性質，是否外勤，工作內容，審核人。那么什么才是主干內容？很容易看出上班時長，加班時長是主干，也就是工作量主題的基本內容，那么工作日期，人員，工作性質，是否外勤，工作內容是否為主干信息呢？認真分析特征會發現，日期，人員，性質，是否外勤都是可以被分類的，例如日期有年-月-日的層次，人員也有上下級關系，外勤和正常上班也是兩類上班考勤記錄，而上班時長和加班時長則不具有此類意義。所以一般把能夠分類的屬性單獨列出來，成為維度表，在事實表中維護事實與維度的引用關系。
在上述例子中，事實表可以設計成如下
WorkDate EmployeeID，WorkTypeID，Islegwork，Content，
而時間，員工，工作類型，是否外勤則歸為維度表。
總的來看，和其他建立主外鍵關系的表也都一樣。但是維度表的建立是需要有層次的（雖然不是必須，但是也是典型特征），而事實表的建立是針對已經發生的事實的，是歷史數據的存檔，也就是說是不應該修改的。以測試部測試軟件的Bug為例。每個Bug都是一個事實。這個Bug的狀態在數據字典里可能設計成新建，轉派，修復，拒絕等等。那么在事實表中Bug表中有一個字段為Status。當測試員或者開發人員改變了這個狀態的值，事實表中該如何更新呢？是直接更新Status還是什么其他的方式？顯然，為了能夠追蹤這個Bug的歷史信息，應該是重新插入一條新的記錄（這里可以參考歷史拉鏈表的etl刷新策略）。那么這和以往的數據庫設計有什么區別呢？可以看出對於原始記錄和新插入的記錄，其他字段全部是相同的，也就是全部冗余的。如果以BugID作為主鍵，這時候會發現主鍵都是冗余的（當然，插入之前只能刪除主鍵）。所以可以看出，事實表一般是沒有主鍵的。數據的質量完全由業務系統來把握。
總的說來，事實表的設計是以能夠正確記錄歷史信息為准則，維度表的設計是以能夠以合適的角度來聚合主題內容為准則。

10、鑽取

鑽取是改變維的層次，變換分析的粒度。它包括向上鑽取（roll up）和向下鑽取（drill down）。roll up是在某一維上將低層次的細節數據概括到高層次的匯總數據，或者減少維數；是指自動生成匯總行的分析方法。通過向導的方式，用戶可以定義分析因素的匯總行，例如對於各地區各年度的銷售情況，可以生成地區與年度的合計行，也可以生成地區或者年度的合計行。
而drill down則相反，它從匯總數據深入到細節數據進行觀察或增加新維。例如，用戶分析“各地區、城市的銷售情況”時，可以對某一個城市的銷售額細分為各個年度的銷售額，對某一年度的銷售額，可以繼續細分為各個季度的銷售額。通過鑽取的功能，使用戶對數據能更深入了解，更容易發現問題，做出正確的決策。
鑽取允許你駕御一個報表內的不同層次的信息。在你的商業模式中，我們定義不同層次的信息，這些定義方式也代表着你的商業構建方法。
你能夠從一個信息層到有細節的更低層或更高層進行提取。例如，假如你的數據是被區域、市場、和商店所組織的，並且你能夠運行一個顯示區域銷售的報表，那么你就可以從一個區域層鑽取數據以便顯示組成該區域的市場的銷售。反之，你能從從商店中鑽取數據去瀏覽商店所屬的市場狀況。

11、交叉分析

交叉分析是指對數據在不同維度進行交叉展現，進行多角度結合分析的方法，彌補了獨立維度進行分析沒法發現的一些問題。交叉分析以多維模型和數據立方為基礎，也可以認為是一種特殊的細分方式，但跟細分的概念有點差異，如果有興趣可以先閱讀下之前的文章——數據立方體與OLAP。細分的方法更多的是基於同一維度的縱深展開，也就是OLAP中的鑽取（Drill-down），比如從月匯總的數據細分來看每天的數據，就是在時間維度上的細分，或者從省份的數據細分查看省份中各城市的數據，是基於地域維的下鑽。交叉分析不再局限於一個維度，就像數據立方體與OLAP文章中的立方體，是基於不同維度的交叉，時間維、地域維和產品維交叉在一起分析每個小立方的數據表現，可以通過OLAP的切片（Slice）和切塊（Dice）操作查看例如上海市在3月份的電子產品的銷售情況，這會幫助我們發現很多在單個維度中無法發現的問題。所以，交叉分析是基於不同維度橫向地組合交叉，而不是細分在同一維度的縱向展開。大體大樣式如下：

pivot-table-layout