很多人對這兩個名詞有一定的概念，然而也就停留在了概念的階段。網(wǎng)絡上對這兩個名詞的區(qū)別其實講的很多，但我覺得都不好理解。這里我們不涉及技術，只講故事，非常適合非相關專業(yè)的讀者朋友閱讀。
首先我們來講一下你可能覺得不需要講的東西，那就是數(shù)據(jù)庫，不講數(shù)據(jù)庫，也無法講數(shù)據(jù)倉庫。什么是數(shù)據(jù)庫？
有的讀者朋友們可能會說：臥槽？！數(shù)據(jù)庫你還要講？沒錯（手動滑稽，麻蛋簡書你什么時候可以出一套表情包）
學過計算機發(fā)展史的朋友們都知道，我們現(xiàn)在所有的計算機都是基于馮諾依曼體系結構的。馮諾依曼這家伙其實不是什么計算機學家，這貨是個數(shù)學家，但他之所以被稱之為”計算機之父“，就是因為他第一個明確了數(shù)據(jù)這個抽象的東西在計算機內部的組織形式，也就是我們現(xiàn)在知道的二進制?，F(xiàn)在的很多小學生因為接觸計算機很早，很多也都知道，數(shù)據(jù)在計算機內部都是0和1兩種形態(tài)存在。
至于為什么計算機采用二進制而不是用我們生活中熟悉的十進制，大家有興趣可以自行百度。
數(shù)據(jù)庫顧名思義就是用來存放數(shù)據(jù)庫的（很顯然數(shù)據(jù)倉庫自然也是存放數(shù)據(jù)的），大約在20世紀60年代時候數(shù)據(jù)庫已經(jīng)在計算機中應用，但這個階段的數(shù)據(jù)庫結構主要是網(wǎng)狀或者層級的（感興趣的讀者們可以翻閱計算機發(fā)展史），這些結構非常復雜多變。我們知道計算機上層都是軟件，軟件包括數(shù)據(jù)和程序，而此時的數(shù)據(jù)庫在這方面區(qū)分的很不好，所以那個年代軟件中的數(shù)據(jù)和程序之間你中有我，我中有你，彼此具備非常強的依賴性。
盡管計算機科學家一直在努力研究數(shù)據(jù)在計算機中的最佳組織形式，但直到1970年（人類第一臺計算機出現(xiàn)在1946年，就是我們中學歷史書上看得不想再看的那張在美國費城占據(jù)了整個房間的那臺龐大的電子管計算機），IBM的研究員埃德加 科德發(fā)明了關系型數(shù)據(jù)庫（這就是我們現(xiàn)在通常說的數(shù)據(jù)庫），才真正徹底把軟件中的數(shù)據(jù)和程序分開來，可能他自己也沒想到關系型數(shù)據(jù)庫的誕生成為了軟件發(fā)展歷史上一個跨越的里程碑。（這里要強調一下，層次型數(shù)據(jù)庫和網(wǎng)狀數(shù)據(jù)庫并沒有就此消失，在特定的應用場景下依然具有不可替代的使用性）科德后來也拿到了1981年的圖靈獎。
那么什么是關系型數(shù)據(jù)庫呢？關系數(shù)據(jù)庫本質上是一個二元關系，說的簡單一些，就是一個二維表格，對普通人來說，最簡單的理解就是一個Excel表格。這種數(shù)據(jù)庫類型，具有結構化程度高，獨立性強，冗余度低等等優(yōu)點，一下子就促進了計算機的發(fā)展。
這里不妨說個題外話，為什么后來Oracle成為了數(shù)據(jù)庫的第一巨頭，IBM落寞了呢？看過吳軍博士《浪潮之巔》的朋友們應該知道，IBM在巔峰的時候，確實在計算機等IT領域一手遮天，但是很遺憾，組織一旦龐大，內部之間對技術或者產(chǎn)品的路線就開始分歧，而且官僚氣息越來越嚴重，以及包括IBM重視理論對產(chǎn)品較為保守等等各種原因，使得IBM不僅在數(shù)據(jù)庫，也在其他很多領域錯失了一系列巨大的黃金機會，感興趣的同學可以閱讀《浪潮之巔》并了解一下Oracle的發(fā)展歷史。
好，打住，關于數(shù)據(jù)庫，知道這些就足夠了，其他東西講多了就沒意義了，也不容易接受?？吹竭@里，我覺得讀者朋友們基本上都能看的很明白。
現(xiàn)在我們可以來講數(shù)據(jù)倉庫了。
從哲學上講，任何事物都是為了解決下一個問題而誕生的。所以從歷史的角度來看，數(shù)據(jù)倉庫就是為了解決數(shù)據(jù)庫不能解決的問題而提出的。（我們甚至可以意淫一下，以后保不齊還會冒出一個“數(shù)據(jù)工廠”或者“數(shù)據(jù)庫存”等等這樣的概念去解決數(shù)據(jù)倉庫不能解決的問題→_→）
那么數(shù)據(jù)庫無法解決什么樣的問題呢？這個我們得先說說什么是OLAP和OLTP（喂，你們不要一看到英文概念就關閉頁面啊，我會講的很簡單又清楚的=。=)
OLTP（On-Line Transaction Processing 聯(lián)機事務處理） 。對有相關專業(yè)知識的讀者們，說簡單一些，就是數(shù)據(jù)庫的增刪查改。舉個例子，你到銀行，去取一筆錢出來，或者轉賬，或者只是想查一下你還有多少存款，這些都是面向“事務”類型的操作。這樣的操作有幾個顯著的特點，首先要求速度很快，基本上都是高可靠的在線操作（比如銀行），還有這些操作涉及的數(shù)據(jù)內容不會特別大（否則速度也就相應的降低），最后，“事務”型的操作往往都要求是精準操作，比如你去銀行取款，必須要求一個具體的數(shù)字，你是不可能對著柜臺員工說我大概想取400到500快之間吧，那樣人家會一臉懵逼。
很簡單吧，東西方技術的互相交融，造成一些名稱的英文翻譯容易讓人知難而退，殊不知，技術的真理往往都是非常簡單清晰的。下面我們來看OLAP。
OLAP（On-Line Analytical Processing 聯(lián)機分析處理）。這個東西又是上面發(fā)明關系型數(shù)據(jù)庫的科德發(fā)明的。OLAP略有復雜，但這里我舉一個簡單的例子，大家就很容易理解了。
比如說，沃爾瑪超市的數(shù)據(jù)庫里有很多張表格，記錄著各個商品的交易記錄。超市里銷售一種運動飲料，我們不妨稱之為紅牛。數(shù)據(jù)庫鐘有一張表A，記錄了紅牛在一年的各個月份的銷售額；還有一張表B，記錄了紅牛每個月在美國各個州的銷售額：；甚至還有一張表C，記錄了這家飲料公司在每個州對紅牛飲料的宣傳資金投入；甚至后來沃爾瑪又從國家氣象局拿到了美國各個州的一年365天每天的天氣表。
好，最后問題來了，請根據(jù)以上數(shù)據(jù)分析紅牛在宣傳資金不超過三百萬的情況下，什么季節(jié)，什么天氣，美國哪個州最好賣？
憑借我們的經(jīng)驗，可能會得出，夏季的晴天，在美國的佛羅里達，最好賣，而且宣傳資金投入越高銷售額應該也會高?？赡苓@樣的結論是正確的，但決策者想要看到的是確鑿的數(shù)據(jù)結論，而不是“可能”這樣的字眼。
科學是不相信直覺的，如果我們人工進行手動分析，會發(fā)現(xiàn)這個要考慮的維度實在太多了，根本無法下手，何況這才四五個維度，要是更多了怎么辦？OLAP就是為了解決這樣的問題誕生的，但糟糕的是，傳統(tǒng)數(shù)據(jù)庫是無法滿足OLAP所需要的數(shù)據(jù)信息的。
現(xiàn)在我們可以回過頭來看數(shù)據(jù)倉庫了。
數(shù)據(jù)庫的大規(guī)模應用，使得信息行業(yè)的數(shù)據(jù)爆炸式的增長，為了研究數(shù)據(jù)之間的關系，挖掘數(shù)據(jù)隱藏的價值，人們越來越多的需要使用OLAP來為決策者進行分析，探究一些深層次的關系和信息。但很顯然，不同的數(shù)據(jù)庫之間根本做不到數(shù)據(jù)共享，就算同一家數(shù)據(jù)庫公司，數(shù)據(jù)庫之間的集成也存在非常大的挑戰(zhàn)（最主要的問題是龐大的數(shù)據(jù)如何有效合并、存儲）。
1988年，為解決企業(yè)的數(shù)據(jù)集成問題，IBM（臥槽，又是IBM）的兩位研究員（Barry Devlin和Paul Murphy）創(chuàng)造性地提出了一個新的術語：數(shù)據(jù)倉庫（Data Warehouse）。
看到這里讀者朋友們可能要問了，然后呢？然后......然后就沒然后了。就在這個創(chuàng)世紀的術語誕生了之后，IBM就啞火了，只是將這個名詞作為市場宣傳的花哨概念，并沒有在技術領域有什么實質性的研究和突破（可悲我大IBM=。=）。
然而，盡管IBM不為所動，其他企業(yè)卻在加緊對數(shù)據(jù)倉庫的研究和開發(fā)，大家都想在這個領域尋找到第一桶金。終于，到了1992年，后來被譽為“數(shù)據(jù)倉庫之父”的比爾 恩門（Bill Inmon）給出了數(shù)據(jù)倉庫的定義，二十多年后的今天他的定義依然沒有被時代淘汰。我們來看看他是怎么定義的：“數(shù)據(jù)倉庫是一個面向主題的、集成的、相對穩(wěn)定的、反映歷史變化的數(shù)據(jù)集合，用于支持管理中的決策制定?！?/p>
我們可以不用管這個定義，簡單的理解，其實就是我們?yōu)榱诉M行OLAP，把分布在各個散落獨立的數(shù)據(jù)庫孤島整合在了一個數(shù)據(jù)結構里面，稱之為數(shù)據(jù)倉庫。這個數(shù)據(jù)倉庫在技術上是怎么建立的讀者朋友們并不需要關心，但是我們要知道，原來各個數(shù)據(jù)孤島中的數(shù)據(jù)，可能會在物理位置（比如沃爾瑪在各個州可能都有自己的數(shù)據(jù)中心）、存儲格式（比如月份是數(shù)值類型，但但天氣可能是字符類型）、商業(yè)平臺（不同數(shù)據(jù)庫可能用的是Oracle數(shù)據(jù)庫，有的是微軟SQL Server數(shù)據(jù)庫）、編寫的語言（Java或者Scale等）等等各個方面完全不同，數(shù)據(jù)倉庫要做的工作就是將他們按照所需要的格式提取出來，再進行必要的轉換（統(tǒng)一數(shù)據(jù)格式）、清洗（去掉無效或者不需要的數(shù)據(jù)）等，最后裝載進數(shù)據(jù)倉庫（我們所說的ETL工具就是用來干這個的）。這樣，拿我們上面紅牛的例子來說，所有的信息就統(tǒng)一放在了數(shù)據(jù)倉庫中了。
自從數(shù)據(jù)倉庫出現(xiàn)之后，信息產(chǎn)業(yè)就開始從以關系型數(shù)據(jù)庫為基礎的運營式系統(tǒng)慢慢向決策支持系統(tǒng)發(fā)展。這個決策支持系統(tǒng)，其實就是我們現(xiàn)在說的商務智能（Business Intelligence）?？梢赃@么說，數(shù)據(jù)倉庫為OLAP解決了數(shù)據(jù)來源問題，數(shù)據(jù)倉庫和OLAP互相促進發(fā)展，進一步驅動了商務智能的成熟，但真正將商務智能賦予“智能”的，正是我們現(xiàn)在熱談的下一代技術：數(shù)據(jù)挖掘。
講完，收工。
