【聲明】本文章來自穆晨 - 博客園，記錄于此方便后期的學習和查閱

一、前言

閱讀本文前，請先回答下面兩個問題：

• 數(shù)據(jù)庫和數(shù)據(jù)倉庫有什么區(qū)別？
• 某公司Hadoop Hive里的關(guān)系表，不完全滿足完整/參照性約束，也不完全滿足范式要求，甚至第一范式都不滿足。這種情況正常嗎？

如果不能在五秒內(nèi)給出答案，那么本文應(yīng)該是對您有幫助的。

二、數(shù)據(jù)庫"分家"

隨著關(guān)系數(shù)據(jù)庫理論的提出，誕生了一系列經(jīng)典的RDBMS，如Oracle、MySQL、SQL Server等。這些RDBMS被成功推向市場，并為社會信息化的發(fā)展做出了重大貢獻。

隨著數(shù)據(jù)庫使用范圍的不斷擴大，目前已逐步劃分為兩個基本類型：

1. 操作型數(shù)據(jù)庫

主要用于業(yè)務(wù)支撐。一個公司往往會使用并維護若干個數(shù)據(jù)庫，這些數(shù)據(jù)庫保存著公司的日常操作數(shù)據(jù)，比如商品購買、酒店預(yù)訂、學生成績錄入等。

2. 分析型數(shù)據(jù)庫

主要用于離線(歷史)數(shù)據(jù)分析。基于歷史業(yè)務(wù)數(shù)據(jù)，進行單獨的數(shù)據(jù)庫存儲，用于對公司各主題域，進行數(shù)據(jù)統(tǒng)計和分析；

數(shù)據(jù)庫"分家"是必然趨勢。隨著數(shù)據(jù)庫使用范圍的不斷擴大、數(shù)據(jù)量級的激增，如果基于同一套數(shù)據(jù)庫系統(tǒng)，很容易造成操作型任務(wù)和分析型任務(wù)的資源沖突，另外在功能、技術(shù)、組成等層面也有很多不同。

三、操作型數(shù)據(jù)庫 VS 分析型數(shù)據(jù)庫

1. 數(shù)據(jù)組成差別

• 數(shù)據(jù)時間范圍差別
  通常，操作型數(shù)據(jù)庫只會存放90天以內(nèi)的數(shù)據(jù)，而分析型數(shù)據(jù)庫存放的則是數(shù)年內(nèi)的數(shù)據(jù)。這點也是將操作型數(shù)據(jù)和分析型數(shù)據(jù)進行物理分離的主要原因。

• 數(shù)據(jù)細節(jié)層次差別
  1）操作型數(shù)據(jù)庫存放的主要是細節(jié)數(shù)據(jù)，而分析型數(shù)據(jù)庫中雖然既有細節(jié)數(shù)據(jù)，又有匯總數(shù)據(jù)，但對于用戶來說，重點關(guān)注的是匯總數(shù)據(jù)部分。
  2）實際上，操作型數(shù)據(jù)庫中也有匯總需求，但匯總數(shù)據(jù)本身不存儲而只存儲其生成公式。這是因為操作型數(shù)據(jù)是動態(tài)變化的，因此匯總數(shù)據(jù)會在每次查詢時動態(tài)生成。
  3）對于分析型數(shù)據(jù)庫來說，因為匯總數(shù)據(jù)比較穩(wěn)定不會發(fā)生改變，而且其計算量也比較大(因為時間跨度大)，因此它的匯總數(shù)據(jù)可考慮事先計算好，以避免重復計算。

• 數(shù)據(jù)時間表示差別
  操作型數(shù)據(jù)通常反映的是現(xiàn)實世界的當前狀態(tài)；而分析型數(shù)據(jù)庫既有當前狀態(tài)，還有過去各時間的快照。分析型數(shù)據(jù)庫的使用者可以綜合所有快照對各個歷史階段進行統(tǒng)計分析。

2. 技術(shù)差別

• 查詢數(shù)據(jù)總量和查詢頻度差別
  操作型查詢的數(shù)據(jù)量少而頻率多，分析型查詢則反過來，數(shù)據(jù)量大而頻率少。要想同時實現(xiàn)這兩種情況的配置優(yōu)化是不可能的，這也是將兩類數(shù)據(jù)庫物理分隔的原因之一。
• 數(shù)據(jù)更新差別
  操作型數(shù)據(jù)庫允許用戶進行增、刪、改、查；分析型數(shù)據(jù)庫用戶則只能進行查詢。
• 數(shù)據(jù)冗余差別
  1）分析型數(shù)據(jù)庫中沒有更新操作。因此，減少數(shù)據(jù)冗余也就沒那么重要了。
  2）現(xiàn)在回答開篇提到的第二個問題：Hive里的關(guān)系表不完全滿足完整/參照性約束，也不完全滿足范式要求，甚至第一范式都不滿足。這種情況正常嗎？，答案是正常的。
  3）因為Hive是一種數(shù)據(jù)倉庫，而數(shù)據(jù)倉庫和分析型數(shù)據(jù)庫的關(guān)系非常緊密(后文會講到)。它只提供查詢接口，不提供更新接口，這就使得消除冗余的諸多措施，不需要被特別嚴格地執(zhí)行。

3. 功能差別

• 數(shù)據(jù)用戶差別
  操作型數(shù)據(jù)庫的使用者是業(yè)務(wù)環(huán)境內(nèi)的各個角色，如用戶，商家，進貨商等；分析型數(shù)據(jù)庫則只被少量用戶用來做綜合性決策。
• 數(shù)據(jù)定位差別
  操作型數(shù)據(jù)庫是為了支撐具體業(yè)務(wù)的，因此也被稱為"面向應(yīng)用型數(shù)據(jù)庫"；分析型數(shù)據(jù)庫則是針對各特定業(yè)務(wù)主題域的分析任務(wù)創(chuàng)建的，因此也被稱為"面向主題型數(shù)據(jù)庫"。

四、數(shù)據(jù)倉庫(data warehouse)定義

分析型數(shù)據(jù)庫中的操作都是查詢，因此可以不需要嚴格滿足完整性/參照性約束以及范式設(shè)計要求，而這些卻正是關(guān)系數(shù)據(jù)庫的精華所在。在這樣的情況下，再將它稱為數(shù)據(jù)庫，很容易引起大家混淆，畢竟在絕大多數(shù)人心中，數(shù)據(jù)庫是可以與關(guān)系型數(shù)據(jù)庫畫等號的。

數(shù)據(jù)倉庫，最簡潔的定義就是：面向分析的存儲系統(tǒng)

數(shù)據(jù)倉庫不依賴傳統(tǒng)關(guān)系數(shù)據(jù)庫來實現(xiàn)，因為關(guān)系數(shù)據(jù)庫最少也要求滿足第1范式，而數(shù)據(jù)倉庫里的關(guān)系表，可以不滿足第1范式，即同樣的記錄在一個關(guān)系表里可以出現(xiàn)N次。

由于大多數(shù)的數(shù)據(jù)倉庫，其表的統(tǒng)計分析還是用SQL語言來實現(xiàn)，因此很容易讓人把它和關(guān)系數(shù)據(jù)庫搞混。

• 面向主題：數(shù)據(jù)倉庫和操作型數(shù)據(jù)庫的根本區(qū)別。操作型數(shù)據(jù)庫是為了支撐各種業(yè)務(wù)而建立，而分析型數(shù)據(jù)庫則是為了對從各種繁雜業(yè)務(wù)中抽象出來的分析主題(如用戶、成本、商品等)進行分析而建立；

• 集成性：數(shù)據(jù)倉庫會將不同源數(shù)據(jù)庫中的數(shù)據(jù)匯總到一起；

• 企業(yè)范圍：數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)是面向公司全局的。比如某個主題域為成本，則全公司和成本有關(guān)的信息都會被匯集進來；

• 歷史性：較之操作型數(shù)據(jù)庫，數(shù)據(jù)倉庫的時間跨度通常比較長。前者通常保存幾個月，后者可能幾年甚至幾十年；

• 時變性：數(shù)據(jù)倉庫包含各歷史時間段的數(shù)據(jù)快照。有了這些數(shù)據(jù)快照，用戶便可將其匯總，生成各歷史階段的數(shù)據(jù)分析報告。

五、數(shù)據(jù)倉庫組件

• 業(yè)務(wù)系統(tǒng)：包含各種源數(shù)據(jù)庫，這些源數(shù)據(jù)庫既為業(yè)務(wù)系統(tǒng)提供數(shù)據(jù)支撐，同時也作為數(shù)據(jù)倉庫的數(shù)據(jù)源(注：除了業(yè)務(wù)系統(tǒng)，數(shù)據(jù)倉庫也可從其他外部數(shù)據(jù)源獲取數(shù)據(jù))；
• ETL：也叫目標系統(tǒng)，包括：提取extraction、轉(zhuǎn)換transformation、加載load
  提取過程：操作型數(shù)據(jù)庫搜集指定數(shù)據(jù)；
  轉(zhuǎn)換過程：將數(shù)據(jù)轉(zhuǎn)化為指定格式并進行數(shù)據(jù)清洗保證數(shù)據(jù)質(zhì)量；
  加載過程：將轉(zhuǎn)換過后滿足指定格式的數(shù)據(jù)加載進數(shù)據(jù)倉庫。
• 前端應(yīng)用：和操作型數(shù)據(jù)庫一樣，數(shù)據(jù)倉庫通常也提供具有直接訪問數(shù)據(jù)倉庫功能的前端應(yīng)用，這些應(yīng)用也被稱為BI(商務(wù)智能)應(yīng)用。

六、數(shù)據(jù)集市(data mart)

數(shù)據(jù)集市可以理解為是一種"小型數(shù)據(jù)倉庫"，它只包含單個主題，且關(guān)注范圍也非全局。

數(shù)據(jù)集市可以分為兩種：

• 獨立數(shù)據(jù)集市(independent data mart)，這類數(shù)據(jù)集市有自己的源數(shù)據(jù)庫和ETL架構(gòu)；
• 非獨立數(shù)據(jù)集市(dependent data mart)，這種數(shù)據(jù)集市沒有自己的源系統(tǒng)，它的數(shù)據(jù)來自數(shù)據(jù)倉庫。

當用戶或者應(yīng)用程序不需要、不必要、不允許用到整個數(shù)據(jù)倉庫的數(shù)據(jù)時，非獨立數(shù)據(jù)集市就可以簡單為用戶提供一個數(shù)據(jù)倉庫的"子集"。

七、數(shù)據(jù)倉庫開發(fā)流程

較之數(shù)據(jù)庫系統(tǒng)開發(fā)，數(shù)據(jù)倉庫開發(fā)只多出ETL工程部分。通常，該部分可能是整個數(shù)據(jù)倉庫開發(fā)流程中最為耗時、耗資源的一個環(huán)節(jié)。

因為該環(huán)節(jié)要整理各大業(yè)務(wù)系統(tǒng)中雜亂無章的數(shù)據(jù)，并協(xié)調(diào)元數(shù)據(jù)上的差別，所以工作量很大。在很多公司都專門設(shè)有ETL工程師這樣的崗位，大的公司甚至專門聘請ETL專家。

在大數(shù)據(jù)時代，數(shù)據(jù)倉庫的重要性更勝以往。Hadoop平臺下的Hive，Spark平臺下的Spark SQL都是各自生態(tài)圈內(nèi)應(yīng)用最熱門的配套工具，而它們的本質(zhì)就是開源分布式數(shù)據(jù)倉庫。