先來談談架構。

其實，我很反感本質這個詞。因為本質這個詞，抽象，模糊，不好定性。回答者好心傾囊相授，看的人卻以一句“ 你沒有明白我的意思，你說的本質和我說的，不一樣！我的意思是……”。

要說本質，就要有分門別類的標準，要把抽象細化下來，這非常考驗人的形象與歸納思維。人與人之間，理解有偏差，談話中對方跟不上，就容易造成誤解。這種事情太多了。

那麼我把這個題目改一改，問，數據庫與數據倉庫的應用區別是什麼？這樣就好多了。至少，我們明確了在應用這個方向上，討論“本質區別”。但事實上，這樣問也不夠好，還是模糊。這相當於問，“咖啡店與星巴克的區別是什麼”。是不是很奇怪，有誰會問這麼二的問題呢？

所以我說，問題本身就不夠明確。為什麼，你往下看就知道了。

既然談到了應用，那主體肯定是人，只有人，才是應用的驅動體。站在人的角度來看，兩者的區別就會清晰很多。

首先，我們來看下，數據的應用有哪些。

第一種應用，我買了電影票：

這類應用，特點都是實時交互，我付了款，立馬得到服務。比如購物，餐飲，交通等等。我們稱之為 OLTP，也就是傳統上所說的“關係型事務數據庫”應用。

第二種應用，我用記賬本：

這類應用，通常會涉及很長一段時間的數據讀取，最終的數據呈現會以多種維度組織，實時性不高，但維度一定不止一位。這類應用屬於數據倉庫的數據分析細分領域，也稱之為 OLAP。

理解了這兩類應用後，我們進一步歸類。無論是 OLTP 還是 OLAP，其實都是數據庫應用，都要以數據庫作為存儲和處理基礎。

OLAP 數據倉庫技術，不過是數據庫應用中的一種。但數據庫和數據倉庫是否一定要以關係型事務數據庫作為基礎呢，不是的。我們接着往下分析。

數據庫

剛才我們談到應用，繼而談到應用的主體，人。那麼談人的時候，有有必要從人經歷的歷史，來看人的發展。以下是半個世紀來，人們在使用數據庫上的歷史節點。

剛開始，人們在應用數據需求上，使用各類不同的數據模型，有 Network Model, Hierarchical Model,還有 Relational Model.

比較好理解的是，Hierarchical Model ：

有一對多的層級關係，最適合用來記錄上下級關係的數據。比如部門組織架構，會計分錄，工業製造常用的BOM(物料清單)等。

接下來，特殊應用就是網絡模型(Network Model):

20世紀50年代的計算機應用水平，還沒有互聯網概念。以現在發達的社交網絡來理解網絡模型，最合適不過。對，就是平常我們所說的社交網絡。

人與人之間的聯繫，就像一張網。兩兩認識的朋友，早晚也會成為朋友，用6度人脈來解釋，就是你要認識王XX，也只要找到關鍵的6個人帶你。

領銜數據庫發展潮流，霸榜半個世紀的理論，是關係型數據庫

1970 年開始，關係型數據庫論文《大型共享數據庫數據的關係模型》在ACM發表了。由此打開了關係型數據庫霸榜的序幕。

從1973年開始，數據庫廠商都開始以 IBM System R 為藍本，開發自己的商用版本。比如 Oracle, IBM DB2, SQL Server , PostgreSQL 等等。

以 NoSQL,NewSQL 展開數據庫新時代序幕

隨着手機，尤其是智能手機，智能平板，互聯網應用的發展，關係型數據庫在處理這些應用上逐漸吃力，因此 Redis, MongoDB, ElasticSearch 逐漸有了市場。

他們的操作語法，看似和關係型數據庫沒有相似之處，但在組成架構上卻還有些異曲同工，目的是把原來在關係型數據庫中不好處理的部分，經過結構規範化，存儲優化，索引優化等技術，使得這些非關係型結構化的數據處理，變得更加高效。

並不是說，傳統的應用中就沒有今天互聯網時代的應用，也有的。比如網站的打日誌，全網搜索等。

但那個時代並沒有那麼多流量，沒有那麼多人來訪問應用，所以使用關係型數據庫存儲和處理這些數據還綽綽有餘。但在流量爆發的今天，數據量早已不是當年可比。要存儲和處理這些大數據，必須採用新新技術。

比如MongoDB的數據分片，可以把用戶操作日誌放入操作日誌集群中，把搜索日誌放入搜索集群中；而用戶的搜索，可以單獨放入 ElasticSearch 中，使得搜索這種高吞吐量的操作不再佔用寶貴的 OLTP 服務器資源。

這些都是傳統的關係型數據庫在處理今天互聯網應用上逐漸吃力的表現。

功能上的缺陷，使得關係型數據庫丟失了一部分市場。可真正讓廠商焦慮的，是處理 OLTP 事務上的瓶頸。這才是關係型數據庫真正感到無力的地方。

比如淘寶每年的雙十一，OceanBase 最高峰值達到每秒 6100 萬。然而，傳統的數據庫，依據Oracle 的 TPC-C 打榜數據，只有 300萬，完全支撐不住。當然這是 Oracle 2009年的數據，現今的 O 記雲，能達到多少 QpmC，我們也不知道。

所以我說，真正讓傳統的RDBMS廠商感到恐慌的，應該是大吞吐量事務處理的無力。

至此，所有的應用，我們都可以稱之為數據庫應用。當然，也包括數據倉庫。20世紀70年代以來，市場上佔據主導地位的，還是關係型數據庫。

使用關係型數據庫搭建數據倉庫，完全順其自然，也合情合理。Kimball 與 Inmon 最初的數據倉庫理論，都以關係型數據庫作為底層存儲架構。

但 Google 的大數據三駕馬車出現後，情況開始變了。

FileSystem, BigTable, MapReduce 的出現，使得大吞吐量的數據倉庫不再遙不可及，原先的RDBMS解決方案是利用時間差，來解決複雜查詢的效率問題，但在數據量和吞吐量達到單台服務器容量極限後，再多的數據量也就難以負載了。

Google三駕馬車的出現，使得多台，甚至千台數據庫服務共同計算變成可能。一個人的力量是有限的，但一群人的力量就不可估量了。機器也是一樣，關鍵在於調度。

先討論早期的數據倉庫技術及產品

剛才談到，關係型數據庫技術，早期用來服務銀行，航空等行業。這些應用主要的功能是處理數據的輸入與輸出。能夠把數據做到準確，安全，一致，就已經達標了。這系列應用，我們稱之為 OLTP(在線聯機事務處理)

但，隨着輸入的增多，輸出就成為了瓶頸，最重要的就是數據分析變得吃力，響應需要等待很長時間，而且有時候結果甚至都出不來，還嚴重拖慢了數據輸入的功能。

因此，全世界都意識到，大量數據的分析，應該和數據的輸入系統，也就是業務系統分開來治理。這，就是數據倉庫思維的啟蒙。

進一步將數據模型優化成關係型數據模型與多維度數據模型概念的，是Kimball. 他的多維度數據模型雖然可以用關係型數據庫實現，但數據結構的組織，已經完全不同於OLTP的使用規範，而是更接近於 OLAP，也就是在線聯機分析處理。

正因為有了多維度數據模型，OLAP才有了新的產品。新的非關係型OLAP產品，與OLTP的關係型數據庫，完全就不是一個架構了。比如 SQL Server Cube, Hyperion Essbase,DB2 OLAP Server 等等.他們採用了一種叫做稀疏性矩陣的技術。

以分布式數據庫作為數據倉庫技術的新起點

半個世紀以來，數據庫世界一直都是關係型數據庫的天下。那麼多的業務系統都建立在RDBMS上，那麼順理成章，數據倉庫也以RDBMS為基建了。這樣一來，無論是硬件成本，還是人力成本，都可以減少到最少。

但摩爾定律一定是支配着信息產業的發展，每過18個個月翻番的，不僅僅是計算機硬件性能，對軟件也提出更高的要求，數據庫就更加嚴苛了。大家回憶下半年前，你們的數據庫有多大，再想想現在你們的數據庫有多大，就明白了。

所以，大小型機，受制於單台資源，在日益增大的數據面前，毫無應招之力，只能讓步於分布式數據庫。以Hadoop的橫空出世為起點，數據倉庫終於不再以RDBMS馬首是瞻，紛紛投奔分布式的非關係型數據庫。

跟RDBMS如出一轍，Hadoop一戰成名之後，後起之秀就越來越多，也越來越猛。原本 Hive 這樣的非實時數據倉庫，已經取得了很大的市場，但隨着實時數據技術的渴求與引入，Spark, Flink 這樣的分布式計算也日益得到人們的青睞。

真是“問世間，是否此山最高 或者另有高處比天高。”

計算機的世界就是這樣，你追我趕，你方唱罷，我方登場。總有軟件比你更快，更好，也總有人，比你更懂SQL

分布式數據庫的技術派別

分布式數據庫，在提高系統吞吐量，降低服務器高負載，提高作業系統性能等方面，均做出了很好的優化。數據在爆量的情況下，採用分布式數據庫系統又變得自然不過了。

那麼究竟有哪些分布式數據庫呢？

其實分布式數據庫自數據庫發展以來，就沒有停過。Oracle, SQL Server 在創立之初，就有各自實現分布式數據庫的方法。不過那個時候，我們傾向於把這些叫做產品功能，比如高可用，複製，鏡像技術，或者讀寫分離。

嚴格來說，這些分布式與我們今天所說的分布式，完全不一樣。最重要的一點，商業數據庫的分布式產品，都是高度自治的，那可真的是分布式，一台數據庫服務器，與另外的分布式數據庫服務器，不共享硬盤，也不共享內存與CPU.看上去完全無關，但邏輯上還是有聯繫，圍繞着同一個應用，一台服務器供寫入數據，另一台或者幾台則供查詢讀取。數據同步使用 CDC, BAT 腳本等方式完成。

但若繼續採用上面的架構，流量再翻10倍，100倍，肯定就頂不住了，因為單機作戰能力並不能無限升級，也就不能線性增長。這時，必須採用嚴格的分布式架構，使每一種數據，都落地在不同的數據庫服務器上。

這個時候， MPP 和 Hadoop 為代表的兩類分布式計算架構出現在市場，也算是應運而生了。當然這是另外的話題。

先來談談架構。

企業數據倉庫架構

關於數據倉庫，有一種簡單粗暴的說法，就是“任何數據倉庫都是通過數據集成工具連接一端的原始數據和另一端的分析界面的數據庫”。

數據倉庫用來管理企業龐大的數據集，提供轉換數據、移動數據並將其呈現給終端用戶的存儲機制。許多架構方法以這樣或那樣的方式擴展數據倉庫的能力，我們講集中討論最本質的問題，在不考慮過多技術細節的情況下，整個層次架構可以被劃分為4層：

• 原始數據層（數據源）
• 數據倉庫架構形態
• 數據的採集、收集、清洗和轉換
• 應用分析層

單層架構（直連）

大多數情況下，數據倉庫是一個關係型數據庫，包含了允許多維數據的模塊，或者分為多個易於訪問的多主題信息域，最簡單的數據倉庫只有一層架構。

單層架構就以為著數據倉庫與分析接口直接連接（直連），終端用戶可以直接查詢。但簡單有其弊端和適用性：

傳統上數據倉庫的存儲從 100GB 起，直連可能會導致數據查詢處理速度慢，因為要直接從數據倉庫查詢準確的數據，或者是準確的輸入，過程中要過濾掉很多非必要數據，這對數據庫以及前端BI工具的性能要求相當高，基本性能不會太高。

另外，在處理複雜維度分析時性能也受限，由於其緩慢性和不可預測性，很少應用在大型數據平台。要執行高級數據查詢，數據倉庫應該在低級實例下被擴展從而簡化數據查詢。

兩層數據架構（數據集市層）

兩層架構就是在前端應用層和 EDW 層增加了數據集市層。數據集市是包含特定主題域信息的低級別存儲庫。簡而言之，它是一個在特定主題（例如銷售、運營、市場等）下延伸了 EDW 的較小數據庫。

這種方式解決了部門級數據查詢和分析的問題，每個部門都更容易訪問到所需數據，因為每個集市僅包含給定域信息，另外，數據集市限制了終端用戶對數據的訪問範圍，設置了一道數據權限。但是創建數據集市層需要額外的硬件資源，並集成它與數據平台其他的數據庫。

三層架構（OLAP）

在數據集市層之上，我們通常會使用聯機分析（OLAP）處理多維數據集（cube）。OLAP 數據集是一類從多維度描述數據的特定數據庫。關係型數據庫只能表示二維數據，而 OLAP 允許在多維度下編譯數據並且在維度之間移動。

OLAP專用於維度建模數據的分析，然後通過BI將OLAP的結果以圖表的方式展現出來。

OLAP 的業務價值在於允許對數據進行切片、切片以多維度分析，以提供對所有企業數據或特定數據集市的訪問，現在基本已成為主流的架構應用。

以下這張架構圖使用最廣泛的體系結構，它由頂層、中層和底層組成。

底層：數據倉庫服務器的數據庫作為底層，通常是一個關係數據庫系統，使用後端工具將數據清理、轉換並加載到該層。

中間層：數據倉庫中的中間層是使用ROLAP或MOLAP模型實現的OLAP服務器。對於用戶，此應用程序層顯示數據庫的抽象視圖，這一層還充當最終用戶和數據庫之間的中介。

頂層：頂層是前端應用層，連接數據倉庫並從數據倉庫獲取數據或者API，通常的應用包括數據查詢、報表製作、BI數據分析、數據挖掘還有一些其他的應用開發。

從功能應用和技術架構來展開，以下是一張中大型企業的很詳細的數據倉庫架構圖了。

數據倉庫的4層核心組件：底層源數據庫（數據存儲方案）、ETL、前端應用、還有OLAP服務。

數據倉庫數據庫

底層的數據倉庫服務器通常是一個關係數據庫系統(各種表關聯的sql統計會更方便一些，非關係型數據庫目前在這方面還是有所區別)。常用的方案有Oracle、db2、sqlserve 還有essbase、greenplum、teredata等數據倉庫專業解決方案。

1、採用傳統關係型數據庫，或經過功能擴展的MPP數據庫

① 傳統的關係型數據庫有：oracle、mysql、DB2

② 大規模並行處理數據庫：Vertica、Teradata(商業)、Greenplum (開源)

Teradata老江湖了，銀行業使用較多，但成本也是真的貴，目前我們做項目較多的是用Greenplum，算是業界最快和最高性價比的高端數據倉庫解決方案，Greenplum是基於PostgreSQL的，於2015年開源。我知道的國內四大行有3家在用，5大物流公司有4家在用，不少公司在從Teradata 遷移到 GP。

2、大數據平台架構：Hadoop+Hive

這套方案有多通用不用多說了，通常是這樣的組合：TB級數據用PG，百TB級數據用GP，PB級i上數據用Hadoop。

下面整理了一張傳統數據倉庫架構、GP還有Hadoop大數據平台的對比圖。

採集、收集、清洗和轉換工具(ETL)

數據來源、轉換和遷移工具用於執行將數據轉換為數據倉庫中的統一格式所需的所有轉換、摘要和所有更改，它們也稱為提取、轉換和加載工具。其功能包括:

1、抽取

全量抽取：適用於數據量小且不容易判斷其數據發生改變的諸如關係表，維度表，配置表等

增量抽取：適用於數據量大，為了節省抽取時間而採用的抽取策略

2、清洗

空值處理：將空值替換為特定值或直接過濾掉

驗證數據正確性：把不符合業務含義的數據做統一處理

規範數據格式：比如把所有日期都規範成YYYY-MM-DD的格式

數據轉碼：把一個源數據中用編碼表示的字段通過關聯編碼表轉換成代表其真實意義的值

數據標準統一：比如在源數據中表示男女的方式有很多種，在抽取的時候直接根據模型中定義的值做轉化。

3、轉化和加載

轉換：用ODS中的增量或者全量數據來刷新DW中的表

加載：每insert數據到一張表都可以稱為數據加載

關於ETL工具的選型，這裡羅列了一張對比表，基本囊括常用的ETL工具。

前端應用工具

數據倉庫平台的搭建，最終是為了梳理出有用數據、提供有價值信息，幫助業務做出正確決策。

前端應用工具主要就是和數據倉庫不同環節的數據交互，這些應用一般可以分為4類：

• 數據查詢和報表工具
• BI即席分析工具
• 數據挖掘工具
• 各種基於數據倉庫或數據集市的應用開發工具

其中數據分析工具主要針對OLAP服務器，報表工具、數據挖掘工具主要針對數據倉庫。

1、數據查詢和報表工具

通常用來生成一些固定類報表，自動化報表，支持打印和計算等大批量批處理作業。

流行的報表工具，在舊數據倉庫時代主要是IBM的BO、Oracle的BIEE、還有微軟和cognos，整體打包在數據倉庫解決方案里，報表作為一個組件存在。但是隨着傳統型數倉，架構重成本貴，很多公司在項目上會自己考慮設計架構，而不是直接強套昂貴的解決方案，包括很多開源組件/平台的使用。

有關報表工具，現在項目上用的比較多的是帆軟FineReport，針對不同企業數倉架構以及報表需求的適用性較廣。比如對接各種數據庫直接生成報表；對採集整理後的數據進行多維報表展現，支撐業務分析報表；對接集團性數據倉庫，構建數據中心平台，形成決策分析平台。

2、BI即席分析工具

BI一般都集成了OLAP服務器和報表展示功能。分析型BI基於多維數據庫的概念，能多維視角分析數據，通常是從數據倉庫中抽取詳細數據的一個子集並經過必要的聚集存儲到OLAP存儲器中供前端BI分析工具讀取。

BI在前端通過拖拽數據字段，多維度實施展現數據，最終生成各種分析報告。常用的BI工具有PowerBI、Tableau、FineBI，還有開源的superset。個人使用多用前兩者，企業項目上選型多用FineBI，因為要考慮性能、服務方案等。剩餘就是自研或者開源，superset算是比較公認的開源BI。

BI工具做什麼的不多說了，在項目選型的時候主要考慮上手難度（考慮沒技術基礎的業務用），數據處理性能，其他就是技術選型的事，還有成本。

3、數據挖掘工具

OLAP是將數據多維視角呈現分析，數據挖掘則是應用的算法來揭示數據的規律性，比如相關性、模式和趨勢等。數據挖掘工具就是做這個的，它能讓一些算法和過程自動化。

舉個例子，比如銀行里數據倉庫以面向“客戶”為主題進行數據的存儲，OLAP可以實現數據按照客戶的基本信息、儲蓄賬戶信息、歷史餘額信息、銀行交易日誌等，以報表或者可視化的方式呈現分析，多方面掌握客戶動態，發現數據的問題，更好的針對不同類型用戶進行特定性營銷。而數據挖掘則是通過歷史數據建立模型，在擬合歷史的基礎上，分析未來趨勢，判斷哪些因素的改變將很可能意味着客戶的最終流失，進而避免其發生。

常用的數據挖掘工具，R、Python還有SPSS，基本都是開源個人可用的。和BI和報表不同，市面上少有為客戶提供定製化數據分析和挖掘的商業工具或者項目服務，因為行業性太強，需要非常熟悉業務、數據、平台，所以我見過基本都是自己養數據分析團隊或者挖這類的人才。

4、應用開發

以上報表型、分析型的數據產品，但也會有延申出來的各種特定業務的數據決策系統，比如銀行業基於管理層監控的的行長駕駛艙、零售業基於門店數據經營的決策系統，以及電商平台的營銷參謀（輸入營銷目標及參數，比如要開展雙十一母嬰市場的促銷活動，系統可以基於以往海量數據計算出應該選擇什麼品類的商品，在什麼用戶群中，以什麼形式開展活動效果會更佳），都是基於這樣的邏輯——基於業務深度應用。此時數倉就是提供一個服務平台的角色，比如現在很火的數據中台也大體是這個邏輯，將數據服務化，具體不懂就不班門弄斧了。

這樣的服務，當然需要自己開發。

在這三層之間其實還有中間層OLAP服務器，典型實現為ROLAP模型或MOLAP模型。現在很多成熟的BI工具都是集成了OLAP服務器的，所以通常我們只需要選擇ETL工具以及存儲方案和可視化BI方案即可，所以OLAP本文也就不多講了。