整體流程概覽

（1）資料倉庫（Data WareHouse，簡稱DW）：

資料倉庫是一種資訊系統的資料儲存理論，主要功能乃是將組織透過資訊系統之聯機交易處理（OLAP）經年累月所累積的大量資料，透過資料倉庫理論所特有的資料儲存架構，作一有系統的分析整理，以利各種分析方法，例如線上分析處理及資料探勘之進行，並且進而支援例如決策支援系統及主管資訊系統之建立，幫助決策者能快速有效的自大量資料中，分析出有價值的資訊，以利決策擬定及快速回應外在環境變動，幫助建構商業智慧。

（2）資料模型：

資料模型是抽象描述現實世界的一種工具和方法，是通過抽象的實體及實體之間聯絡的形式，來表示現實世界中事務的相互關係的一種對映

有別於一般聯機交易處理(OLTP)系統，資料模型設計是一個數據倉庫設計的地基，當前兩大主流理論分別為採用正規方式(normalized approach)或多維方式(dimensional approach)進行資料模型設計。 資料模型可以分為邏輯與實體資料模型。邏輯資料模型陳述業務相關資料的關係，基本上是一種與資料庫無關的結構設計，通常均會採用正規方式設計。實體資料模型則與資料庫管理系統有關，是建置在該系統上的資料架構，故設計時需考慮資料型別(data type)、空間及效能相關的議題。

整個資料倉庫得建模過程中，我們需要經歷一般四個過程：

業務建模，生成業務模型，主要解決業務層面的分解和程式化。

領域建模，生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型。

邏輯建模，生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關係進行資料庫層次的邏輯化。

物理建模，生成物理模型，主要解決，邏輯模型針對不同關係型資料庫的物理化以及效能等一些具體的技術問題。

實現方式：

資料倉庫是一個過程而不是一個專案。

資料倉庫系統是一個資訊提供平臺，他從業務處理系統獲得資料，主要以星型模型和雪花模型進行資料組織，併為使用者提供各種手段從資料中獲取資訊和知識。

從功能結構劃分，資料倉庫系統至少應該包含資料獲取（Data Acquisition）、資料儲存（Data Storage）、資料訪問（Data Access）三個關鍵部分。

（3）元資料

描述資料倉庫內資料的結構和建立方法的資料。可將其按用途的不同分為兩類，技術元資料和商業元資料。

技術元資料：

是資料倉庫的設計和管理人員用於開發和日常管理資料倉庫使用的資料。包括：資料來源資訊；資料轉換的描述；資料倉庫內物件和資料結構的定義；資料清理和資料更新時用的規則；源資料到目的資料的對映；使用者訪問許可權，資料備份歷史記錄，資料匯入歷史記錄，資訊釋出歷史記錄等。

商業元資料：

從商業業務的角度描述了資料倉庫中的資料。包括：業務主題的描述，包含的資料、查詢、報表；

元資料為訪問資料倉庫提供了一個資訊目錄（informationdirectory），這個目錄全面描述了資料倉庫中都有什麼資料、這些資料怎麼得到的、和怎麼訪問這些資料。是資料倉庫執行和維護的中心，資料倉庫伺服器利用他來存貯和更新資料，使用者通過他來了解和訪問資料。

（4）資料集市

為了特定的應用目的或應用範圍，而從資料倉庫中獨立出來的一部分資料，也可稱為部門資料或主題資料（subjectarea）。在資料倉庫的實施過程中往往可以從一個部門的資料集市著手，以後再用幾個資料集市組成一個完整的資料倉庫。需要注意的就是在實施不同的資料集市時，同一含義的欄位定義一定要相容，這樣在以後實施資料倉庫時才不會造成大麻煩。

（5）資料倉庫建模

目前業界較為流行的資料倉庫的建模方法非常多，這裡主要介紹正規化建模法，維度建模法，實體建模法等幾種方法，每種方法其實從本質上講就是從不同的角度看我們業務中的問題。

正規化建模法：

正規化建模法其實是我們在構建資料模型常用的一個方法，是Inmon提出的集線器的自上而下（EDW-DM）的資料倉庫架構。操作型或事務型系統的資料來源，通過ETL抽取轉換和載入到資料倉庫的ODS層，然後通過ODS的資料建設原子資料的資料倉庫EDW，EDW不是多維格式的，不方便上層應用做資料分析，所以需要通過彙總建設成多維格式的資料集市層。優勢：易於維護，高度整合；劣勢：結構死板，部署週期較長。主要解決關係型資料庫得資料儲存，利用的一種技術層面上的方法。目前，我們在關係型資料庫中的建模方法，大部分採用的是第三正規化（Third Normal Form）建模法。

ODS和EDW？

ODS簡單的理解為 Operational Data Store, 可操作的資料倉庫。ODS在資料倉庫中是可選擇的一部分，但不是必須的。隔離倉庫環境和業務環境；ODS作為資料緩衝層，保留的是所有的資料，理論上粒度和源系統保持一致，同時不丟資料，業務DB基本上是直接同步過來，LOG主要是做結構化。

EDW簡單理解為 Enterprise Data Warehouse, 企業級資料倉庫。屬於分析型資料。隨著資料爆炸，資料量呈爆發式增長，機器學習與資料探勘方法的不斷改進，EDW在企業中處於越來越重要的位置。ODS的資料經過規範化、解析、整合和篩選之後，進入EDW。EDW中的資料是全公司的資料，根據業務做主題梳理建設之後，需要能方便地滿足對於全公司資料的分析，同時又能滿足各業務部門資料集市的需求，它需要作為各個部門分析資料的來源，保證資料一致性。這裡應該放的比較穩定和公司層面比較通用的資料。

ODS是資料倉庫的一個擴充套件，它也是一個企業級的資料儲存模式，它的構造也是面向主題的。ODS是企業中執行系統釋出資訊的地方，這些資訊是實時或接近實時的，這些資訊可以被企業中的其它系統使用，包括資料倉庫。但ODS與資料倉庫不完全一樣，主要區別有四點：

1.ODS存放的資料是實時的、可動態重新整理的，而資料倉庫儲存的資料是非實時的、靜態的；

2.ODS主要儲存當前執行系統的資料，而資料倉庫除了儲存當前資料，還需要儲存大量的歷史資料；

3.ODS主要儲存明細資料，而資料倉庫需要同時儲存明細和彙總資料；

4.ODS中的資料可以用於日常分析，而資料倉庫中的資料主要用於戰略分析。

一般對於ODS設計有如下幾個作用：

1.在業務系統和資料倉庫之間形成一個隔離層。

2.轉移一部分業務系統細節查詢的功能。

3.完成資料倉庫中不能完成的一些功能。

如圖展示資料庫，ODS和EDW之間的關係：

其中，ADB為傳統的關係型資料庫，A,B,C表示不同型別的資料流轉。A環節表示生產環境中不同資料庫之間直接交換資料，例如mysql,sqlserver,oracle等DB直接通過Informatic等工具交換資料。B表示生產環境中的應用資料通過ODS進行資料交換。C表示資料進行到EDW中。具體可以參見https://blog.csdn.net/bitcarmanlee/article/details/51013474這篇部落格的說明。

什麼是第三正規化？

設計關係資料庫時，遵從不同的規範要求，設計出合理的關係型資料庫，這些不同的規範要求被稱為不同的正規化，各種正規化呈遞次規範，越高的正規化資料庫冗餘越小。

第一正規化（1NF）：指在關係模型中，對域新增的一個規範要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子資料項，而不能是集合，陣列，記錄等非原子資料項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一正規化（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一正規化就是無重複的域。

第二正規化（2NF）：在第一正規化（1NF）的基礎上建立起來的，即滿足第二正規化（2NF）必須先滿足第一正規化（1NF）。第二正規化（2NF）要求資料庫表中的每個例項或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關係中，沒有對其身份證號進行儲存，而姓名可能會在資料庫執行的某個時間重複，無法區分出實體時，設計闢如ID等不重複的編號以實現區分，被新增的編號或ID選作主鍵。（該主鍵的新增是在ER（Entity Relationship Diagram，實體-聯絡圖)設計時新增，不是建庫時隨意新增）。簡而言之，第二正規化就是在第一正規化的基礎上屬性完全依賴於主鍵。

第三正規化（3NF）：在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）。簡而言之，第三正規化（3NF）要求一個關係中不包含已在其它關係已包含的非主關鍵字資訊。例如，存在一個部門資訊表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等資訊。那麼在員工資訊表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的資訊再加入員工資訊表中。如果不存在部門資訊表，則根據第三正規化（3NF）也應該構建它，否則就會有大量的資料冗餘。

因此，正規化建模法需要滿足

每個屬性值唯一，不具有多義性 ;

每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;

每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去。

正規化建模法的最大優點就是從關係型資料庫的角度出發，結合了業務系統的資料模型，能夠比較方便的實現資料倉庫的建模。但其缺點也是明顯的，由於建模方法限定在關係型資料庫之上，在某些時候反而限制了整個資料倉庫模型的靈活性，效能等，特別是考慮到資料倉庫的底層資料向資料集市的資料進行彙總時，需要進行一定的變通才能滿足相應的需求。

維度建模法：

Kimball提出的匯流排式的自下而上（DM-DW）的資料倉庫架構。同樣的，操作型或事務型系統的資料來源，通過ETL抽取轉換和載入到資料倉庫的ODS層，然後通過ODS的資料，利用維度建模方法建設一致維度的資料集市。通過一致性維度可以將資料集市聯絡在一起，由所有的資料集市組成資料倉庫。優勢：構建迅速，最快的看到投資回報率，敏捷靈活；劣勢：作為企業資源不太好維護，結構複雜，資料集市整合困難。常見的模型：星型模型和雪花模型

星型模型：

星型模是一種多維的資料關係，它由一個事實表和一組維表組成。每個維表都有一個維作為主鍵，所有這些維的主鍵組合成事實表的主鍵。強調的是對維度進行預處理，將多個維度集合到一個事實表，形成一個寬表。這也是我們在使用hive時，經常會看到一些大寬表的原因，大寬表一般都是事實表，包含了維度關聯的主鍵和一些度量資訊，而維度表則是事實表裡面維度的具體資訊，使用時候一般通過join來組合資料，相對來說對OLAP的分析比較方便。

雪花模型：

當有一個或多個維表沒有直接連線到事實表上，而是通過其他維表連線到事實表上時，其圖解就像多個雪花連線在一起，故稱雪花模型。雪花模型是對星型模型的擴充套件。它對星型模型的維表進一步層次化，原有的各維表可能被擴充套件為小的事實表，形成一些區域性的 "層次 " 區域，這些被分解的表都連線到主維度表而不是事實表。雪花模型更加符合資料庫正規化，減少資料冗餘，但是在分析資料的時候，操作比較複雜，需要join的表比較多所以其效能並不一定比星型模型高。（雪花模型可以理解為，為了獲取更“深”或更“細”一級的資訊）

優缺點：

雪花模型可以精確表示層次化的資料，但還是應該避免使用雪花模式，因為對商業使用者來說，理解雪花模式並在其中查詢是非常困難的，雪花模式還會影響查詢效能

從查詢效能角度來看，在OLTP-DW環節，由於雪花型要做多個表聯接，效能會低於星型架構；但從DW-OLAP環節，由於雪花型架構更有利於度量值的聚合，因此效能要高於星型架構。

從模型複雜度來看，星型架構更簡單。

從層次概念來看，雪花型架構更加貼近OLTP系統的結構，比較符合業務邏輯，層次比較清晰。

從儲存空間角度來看，雪花型架構具有關係資料模型的所有優點，不會產生冗餘資料，而相比之下星型架構會產生資料冗餘。

根據我們的專案經驗，一般建議使用星型架構。因為我們在實際專案中，往往最關注的是查詢效能問題，至於磁碟空間一般都不是問題。 當然，在維度表資料量極大，需要節省儲存空間的情況下，或者是業務邏輯比較複雜、必須要體現清晰的層次概念情況下，可以使用雪花型維度。

在複合式的資料倉庫架構中，操作型或事務型系統的資料來源，通過ETL抽取轉換和載入到資料倉庫的ODS層，然後通過ODS的資料，利用正規化建模方法，建設原子資料的資料倉庫EDW，然後基於EDW，利用維度建模方法建設資料集市。

應用場景：

星型模型的設計方式主要帶來的好處是能夠提升查詢效率，因為生成的事實表已經經過預處理，主要的資料都在事實表裡面，所以只要掃描事實表就能夠進行大量的查詢，而不必進行大量的join，其次維表資料一般比較少，在join可直接放入記憶體進行join以提升效率，除此之外，星型模型的事實表可讀性比較好，不用關聯多個表就能獲取大部分核心資訊，設計維護相對比較簡答。

雪花模型的設計方式是比較符合資料庫正規化的理念，設計方式比較正規，資料冗餘少，但在查詢的時候可能需要join多張表從而導致查詢效率下降，此外規範化操作在後期維護比較複雜。

星座模型：

由多個事實表組合，維表是公共的，可以被多個事實表共享。星座模型是資料倉庫最常使用的模型。

總結：

資料倉庫大多數時候是比較適合使用星型模型構建底層資料Hive表，通過大量的冗餘來提升查詢效率，星型模型對OLAP的分析引擎支援比較友好，這一點在Kylin中比較能體現。而雪花模型在關係型資料庫中如MySQL，Oracle中非常常見，尤其像電商的資料庫表。在資料倉庫中雪花模型的應用場景比較少，但也不是沒有，所以在具體設計的時候，可以考慮是不是能結合兩者的優點參與設計，以此達到設計的最優化目的。

實體建模法：

實體建模法並不是資料倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關係組成。那麼我們在資料倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關係，以及針對這些關係的說明就是我們資料建模需要做的工作。

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件和說明，如下圖所示：

上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述的是一個業務過程，我們在這裡可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。

從上面的舉例我們可以瞭解，我們使用的抽象歸納方法其實很簡單，任何業務可以看成 3個部分：

實體，主要指領域模型中特定的概念主體，指發生業務關係的物件。

事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程。

說明，主要是針對實體和事件的特殊說明。

由於實體建模法，能夠很輕鬆的實現業務模型的劃分，因此，在業務建模階段和領域概念建模階段，實體建模法有著廣泛的應用。從筆者的經驗來看，再沒有現成的行業模型的情況下，我們可以採用實體建模的方法，和客戶一起理清整個業務的模型，進行領域概念模型的劃分，抽象出具體的業務概念，結合客戶的使用特點，完全可以創建出一個符合自己需要的資料倉庫模型來。

但是，實體建模法也有著自己先天的缺陷，由於實體說明法只是一種抽象客觀世界的方法，因此，註定了該建模方法只能侷限在業務建模和領域概念建模階段。因此，到了邏輯建模階段和物理建模階段，則是正規化建模和維度建模發揮長處的階段。