第一篇：數據倉庫概述
前言
閱讀本文前，請先回答下面兩個問題：
1. 數據庫和數據倉庫有什麼區別？
2. 某大公司Hadoop Hive裏的關係表不完全滿足完整/參照性約束，也不完全滿足範式要求，甚至第一範式都不滿足。這種情況正常嗎？
如果您不能五秒內給出答案，那麼本文應該是對您有幫助的。
注：如果您還不清楚完整參照性約束，請參考《數據庫關係建模》：，如果您還不瞭解範式，請參考《更新異常與規範化設計》。
數據庫的"分家"
隨着關係數據庫理論的提出，誕生了一系列經典的RDBMS，如Oracle，MySQL，SQL Server等。這些RDBMS被成功推向市場，併爲社會信息化的發展做出的重大貢獻。然而隨着數據庫使用範圍的不斷擴大，它被逐步劃分爲兩大基本類型：
1. 操作型數據庫
主要用於業務支撐。一個公司往往會使用並維護若干個數據庫，這些數據庫保存着公司的日常操作數據，比如商品購買、酒店預訂、學生成績錄入等；
2. 分析型數據庫
主要用於歷史數據分析。這類數據庫作爲公司的單獨數據存儲，負責利用歷史數據對公司各主題域進行統計分析；
那麼爲什麼要"分家"？在一起不合適嗎？能不能構建一個同樣適用於操作和分析的統一數據庫？
答案是NO。一個顯然的原因是它們會"打架"......如果操作型任務和分析型任務搶資源怎麼辦呢？再者，它們有太多不同，以致於早已"貌合神離"。接下來看看它們到底有哪些不同吧。
操作型數據庫 VS 分析型數據庫
因爲主導功能的不同(面向操作/面向分析)，兩類數據庫就產生了很多細節上的差異。這就好像同樣是人，但一個和尚和一個穆斯林肯定有很多行爲/觀念上的不同。
接下來本文將詳細分析兩類數據庫的不同點：
1. 數據組成差別 - 數據時間範圍差別
一般來講，操作型數據庫只會存放90天以內的數據，而分析型數據庫存放的則是數年內的數據。這點也是將操作型數據和分析型數據進行物理分離的主要原因。
2. 數據組成差別 - 數據細節層次差別
操作型數據庫存放的主要是細節數據，而分析型數據庫中雖然既有細節數據，又有彙總數據，但對於用戶來說，重點關注的是彙總數據部分。
操作型數據庫中自然也有彙總需求，但彙總數據本身不存儲而只存儲其生成公式。這是因爲操作型數據是動態變化的，因此彙總數據會在每次查詢時動態生成。
而對於分析型數據庫來說，因爲彙總數據比較穩定不會發生改變，而且其計算量也比較大(因爲時間跨度大)，因此它的彙總數據可考慮事先計算好，以避免重複計算。
3. 數據組成差別 - 數據時間表示差別
操作型數據通常反映的是現實世界的當前狀態；而分析型數據庫既有當前狀態，還有過去各時刻的快照，分析型數據庫的使用者可以綜合所有快照對各個歷史階段進行統計分析。
4. 技術差別 - 查詢數據總量和查詢頻度差別
操作型查詢的數據量少而頻率多，分析型查詢則反過來，數據量大而頻率少。要想同時實現這兩種情況的配置優化是不可能的，這也是將兩類數據庫物理分隔的原因之一。
5. 技術差別 - 數據更新差別
操作型數據庫允許用戶進行增，刪，改，查；分析型數據庫用戶則只能進行查詢。
6. 技術差別 - 數據冗餘差別
數據的意義是什麼？就是減少數據冗餘，避免更新異常。而如5所述，分析型數據庫中沒有更新操作。因此，減少數據冗餘也就沒那麼重要了。
現在回到開篇是提到的第二個問題"某大公司Hadoop Hive裏的關係表不完全滿足完整/參照性約束，也不完全滿足範式要求，甚至第一範式都不滿足。這種情況正常嗎？"，答曰是正常的。因爲Hive是一種數據倉庫，而數據倉庫和分析型數據庫的關係非常緊密(後文會講到)。它只提供查詢接口，不提供更新接口，這就使得消除冗餘的諸多措施不需要被特別嚴格地執行了。
7. 功能差別 - 數據讀者差別
操作型數據庫的使用者是業務環境內的各個角色，如用戶，商家，進貨商等；分析型數據庫則只被少量用戶用來做綜合性決策。
8. 功能差別 - 數據定位差別
這裏說的定位，主要是指以何種目的組織起來。操作型數據庫是爲了支撐具體業務的，因此也被稱爲"面向應用型數據庫"；分析型數據庫則是針對各特定業務主題域的分析任務創建的，因此也被稱爲"面向主題型數據庫"。
數據倉庫(data warehouse)定義
聰明的讀者應該已經意識到這個問題：既然分析型數據庫中的操作都是查詢，因此也就不需要嚴格滿足完整性/參照性約束以及範式設計要求，而這些卻正是關係數據庫精華所在。這樣的情況下再將它歸爲數據庫會很容易引起大家混淆，畢竟在絕大多數人心裏數據庫是可以關係型數據庫畫上等號的。
那麼爲什麼不乾脆叫"面向分析的存儲系統"呢？
Bingo！~這就是關於數據倉庫最貼切的定義了。事實上數據倉庫不應讓傳統關係數據庫來實現，因爲關係數據庫最少也要求滿足第1範式，而數據倉庫裏的關係表可以不滿足第1範式。也就是說，同樣的記錄在一個關係表裏可以出現N次。但由於大多數數據倉庫內的表的統計分析還是用SQL，因此很多人把它和關係數據庫搞混了。
知道了什麼是數據倉庫後，再來看看它有哪些特點吧。某種程度上來說，這也是分析型數據庫的特點：
1. 面向主題
面向主題特性是數據倉庫和操作型數據庫的根本區別。操作型數據庫是爲了支撐各種業務而建立，而分析型數據庫則是爲了對從各種繁雜業務中抽象出來的分析主題(如用戶、成本、商品等)進行分析而建立；
2. 集成性
集成性是指數據倉庫會將不同源數據庫中的數據彙總到一起；
3. 企業範圍
數據倉庫內的數據是面向公司全局的。比如某個主題域爲成本，則全公司和成本有關的信息都會被彙集進來；
4. 歷史性
較之操作型數據庫，數據倉庫的時間跨度通常比較長。前者通常保存幾個月，後者可能幾年甚至幾十年；
5. 時變性
時變性是指數據倉庫包含來自其時間範圍不同時間段的數據快照。有了這些數據快照以後，用戶便可將其彙總，生成各歷史階段的數據分析報告；
數據倉庫組件
數據倉庫的核心組件有四個：各源數據庫，ETL，數據倉庫，前端應用。如下圖所示：
1. 業務系統
業務系統包含各種源數據庫，這些源數據庫既爲業務系統提供數據支撐，同時也作爲數據倉庫的數據源(注：除了業務系統，數據倉庫也可從其他外部數據源獲取數據)；
2. ETL
ETL分別代表：提取extraction、轉換transformation、加載load。其中提取過程表示操作型數據庫蒐集指定數據，轉換過程表示將數據轉化爲指定格式並進行數據清洗保證數據質量，加載過程表示將轉換過後滿足指定格式的數據加載進數據倉庫。數據倉庫會週期不斷地從源數據庫提取清洗好了的數據，因此也被稱爲"目標系統"；
3. 前端應用
和操作型數據庫一樣，數據倉庫通常提供具有直接訪問數據倉庫功能的前端應用，這些應用也被稱爲BI(商務智能)應用；
數據集市(data mart)
數據集市可以理解爲是一種"小型數據倉庫"，它只包含單個主題，且關注範圍也非全局。
數據集市可以分爲兩種，一種是獨立數據集市(independent data mart)，這類數據集市有自己的源數據庫和ETL架構；另一種是非獨立數據集市(dependent data mart)，這種數據集市沒有自己的源系統，它的數據來自數據倉庫。當用戶或者應用程序不需要/不必要/不允許用到整個數據倉庫的數據時，非獨立數據集市就可以簡單爲用戶提供一個數據倉庫的"子集"。
數據倉庫開發流程
在數據庫系列的第五篇中，曾詳細分析了數據庫系統的開發流程。數據倉庫的開發流程和數據庫的比較相似，因此本文僅就其中區別進行分析。
下圖爲數據倉庫的開發流程：
較之數據庫系統開發，數據倉庫開發只多出ETL工程部分。然而這一部分極有可能是整個數據倉庫開發流程中最爲耗時耗資源的一個環節。因爲該環節要整理各大業務系統中雜亂無章的數據並協調元數據上的差別，所以工作量很大。在很多公司都專門設有ETL工程師這樣的崗位，大的公司甚至專門聘請ETL專家。
小結
在大數據時代，數據倉庫的重要性更勝以往。Hadoop平臺下的Hive，Spark平臺下的Spark SQL都是各自生態圈內應用最熱門的配套工具，而它們的本質就是開源分佈式數據倉庫。
在國內最優秀的互聯網公司裏(如阿里、騰訊)，很多數據引擎是架構在數據倉庫之上的(如數據分析引擎、數據挖掘引擎、推薦引擎、可視化引擎等等)。不少員工認爲，開發成本應更多集中在數據倉庫層，不斷加大數據建設的投入。因爲一旦規範、標準、高性能的數據倉庫建立好了，在之上進行數據分析、數據挖掘、跑推薦算法等都是輕鬆愜意的事情。反之如果業務數據沒梳理好，各種髒亂數據會搞得人焦頭爛額，苦不堪言。
