//
大數(shù)據(jù)：數(shù)據(jù)倉庫和數(shù)據(jù)庫的區(qū)別 - 簡書
http://www.itdecent.cn/p/3eab6a744a08

如果我們?nèi)斯みM(jìn)行手動分析，會發(fā)現(xiàn)這個要考慮的維度實(shí)在太多了，根本無法下手，何況這才四五個維度，要是更多了怎么辦？OLAP就是為了解決這樣的問題誕生的，但糟糕的是，傳統(tǒng)數(shù)據(jù)庫是無法滿足OLAP所需要的數(shù)據(jù)信息的。

數(shù)據(jù)庫的大規(guī)模應(yīng)用，使得信息行業(yè)的數(shù)據(jù)爆炸式的增長，為了研究數(shù)據(jù)之間的關(guān)系，挖掘數(shù)據(jù)隱藏的價值，人們越來越多的需要使用OLAP來為決策者進(jìn)行分析，探究一些深層次的關(guān)系和信息。但很顯然，不同的數(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ù)語：數(shù)據(jù)倉庫（Data Warehouse）。

我們可以不用管這個定義，簡單的理解，其實(shí)就是我們?yōu)榱诉M(jìn)行OLAP，把分布在各個散落獨(dú)立的數(shù)據(jù)庫孤島整合在了一個數(shù)據(jù)結(jié)構(gòu)里面，稱之為數(shù)據(jù)倉庫。這個數(shù)據(jù)倉庫在技術(shù)上是怎么建立的讀者朋友們并不需要關(guān)心，但是我們要知道，原來各個數(shù)據(jù)孤島中的數(shù)據(jù)，可能會在物理位置（比如沃爾瑪在各個州可能都有自己的數(shù)據(jù)中心）、存儲格式（比如月份是數(shù)值類型，但但天氣可能是字符類型）、商業(yè)平臺（不同數(shù)據(jù)庫可能用的是Oracle數(shù)據(jù)庫，有的是微軟SQL Server數(shù)據(jù)庫）、編寫的語言（Java或者Scale等）等等各個方面完全不同，數(shù)據(jù)倉庫要做的工作就是將他們按照所需要的格式提取出來，再進(jìn)行必要的轉(zhuǎn)換（統(tǒng)一數(shù)據(jù)格式）、清洗（去掉無效或者不需要的數(shù)據(jù)）等，最后裝載進(jìn)數(shù)據(jù)倉庫（我們所說的ETL工具就是用來干這個的）。這樣，拿我們上面紅牛的例子來說，所有的信息就統(tǒng)一放在了數(shù)據(jù)倉庫中了。

自從數(shù)據(jù)倉庫出現(xiàn)之后，信息產(chǎn)業(yè)就開始從以關(guān)系型數(shù)據(jù)庫為基礎(chǔ)的運(yùn)營式系統(tǒng)慢慢向決策支持系統(tǒng)發(fā)展。這個決策支持系統(tǒng)，其實(shí)就是我們現(xiàn)在說的商務(wù)智能（Business Intelligence）?？梢赃@么說，數(shù)據(jù)倉庫為OLAP解決了數(shù)據(jù)來源問題，數(shù)據(jù)倉庫和OLAP互相促進(jìn)發(fā)展，進(jìn)一步驅(qū)動了商務(wù)智能的成熟，但真正將商務(wù)智能賦予“智能”的，正是我們現(xiàn)在熱談的下一代技術(shù)：數(shù)據(jù)挖掘。

現(xiàn)在我們可以來講數(shù)據(jù)倉庫了。

從哲學(xué)上講，任何事物都是為了解決下一個問題而誕生的。所以從歷史的角度來看，數(shù)據(jù)倉庫就是為了解決數(shù)據(jù)庫不能解決的問題而提出的。（我們甚至可以意淫一下，以后保不齊還會冒出一個“數(shù)據(jù)工廠”或者“數(shù)據(jù)庫存”等等這樣的概念去解決數(shù)據(jù)倉庫不能解決的問題→_→）

那么數(shù)據(jù)庫無法解決什么樣的問題呢？這個我們得先說說什么是OLAP和OLTP（喂，你們不要一看到英文概念就關(guān)閉頁面啊，我會講的很簡單又清楚的=。=)

OLTP（On-Line Transaction Processing 聯(lián)機(jī)事務(wù)處理） 。對有相關(guān)專業(yè)知識的讀者們，說簡單一些，就是數(shù)據(jù)庫的增刪查改。舉個例子，你到銀行，去取一筆錢出來，或者轉(zhuǎn)賬，或者只是想查一下你還有多少存款，這些都是面向“事務(wù)”類型的操作。這樣的操作有幾個顯著的特點(diǎn)，首先要求速度很快，基本上都是高可靠的在線操作（比如銀行），還有這些操作涉及的數(shù)據(jù)內(nèi)容不會特別大（否則速度也就相應(yīng)的降低），最后，“事務(wù)”型的操作往往都要求是精準(zhǔn)操作，比如你去銀行取款，必須要求一個具體的數(shù)字，你是不可能對著柜臺員工說我大概想取400到500快之間吧，那樣人家會一臉懵逼。

很簡單吧，東西方技術(shù)的互相交融，造成一些名稱的英文翻譯容易讓人知難而退，殊不知，技術(shù)的真理往往都是非常簡單清晰的。下面我們來看OLAP。

OLAP（On-Line Analytical Processing 聯(lián)機(jī)分析處理）。這個東西又是上面發(fā)明關(guān)系型數(shù)據(jù)庫的科德發(fā)明的。OLAP略有復(fù)雜，但這里我舉一個簡單的例子，大家就很容易理解了。

比如說，沃爾瑪超市的數(shù)據(jù)庫里有很多張表格，記錄著各個商品的交易記錄。超市里銷售一種運(yùn)動飲料，我們不妨稱之為紅牛。數(shù)據(jù)庫鐘有一張表A，記錄了紅牛在一年的各個月份的銷售額；還有一張表B，記錄了紅牛每個月在美國各個州的銷售額：；甚至還有一張表C，記錄了這家飲料公司在每個州對紅牛飲料的宣傳資金投入；甚至后來沃爾瑪又從國家氣象局拿到了美國各個州的一年365天每天的天氣表。

好，最后問題來了，請根據(jù)以上數(shù)據(jù)分析紅牛在宣傳資金不超過三百萬的情況下，什么季節(jié)，什么天氣，美國哪個州最好賣？

憑借我們的經(jīng)驗(yàn)，可能會得出，夏季的晴天，在美國的佛羅里達(dá)，最好賣，而且宣傳資金投入越高銷售額應(yīng)該也會高。可能這樣的結(jié)論是正確的，但決策者想要看到的是確鑿的數(shù)據(jù)結(jié)論，而不是“可能”這樣的字眼。

科學(xué)是不相信直覺的，如果我們?nèi)斯みM(jìn)行手動分析，會發(fā)現(xiàn)這個要考慮的維度實(shí)在太多了，根本無法下手，何況這才四五個維度，要是更多了怎么辦？OLAP就是為了解決這樣的問題誕生的，但糟糕的是，傳統(tǒng)數(shù)據(jù)庫是無法滿足OLAP所需要的數(shù)據(jù)信息的。

現(xiàn)在我們可以回過頭來看數(shù)據(jù)倉庫了。

數(shù)據(jù)庫的大規(guī)模應(yīng)用，使得信息行業(yè)的數(shù)據(jù)爆炸式的增長，為了研究數(shù)據(jù)之間的關(guān)系，挖掘數(shù)據(jù)隱藏的價值，人們越來越多的需要使用OLAP來為決策者進(jìn)行分析，探究一些深層次的關(guān)系和信息。但很顯然，不同的數(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ù)語：數(shù)據(jù)倉庫（Data Warehouse）。

看到這里讀者朋友們可能要問了，然后呢？然后......然后就沒然后了。就在這個創(chuàng)世紀(jì)的術(shù)語誕生了之后，IBM就啞火了，只是將這個名詞作為市場宣傳的花哨概念，并沒有在技術(shù)領(lǐng)域有什么實(shí)質(zhì)性的研究和突破（可悲我大IBM=。=）。

然而，盡管IBM不為所動，其他企業(yè)卻在加緊對數(shù)據(jù)倉庫的研究和開發(fā)，大家都想在這個領(lǐng)域?qū)ふ业降谝煌敖?。終于，到了1992年，后來被譽(yù)為“數(shù)據(jù)倉庫之父”的比爾 恩門（Bill Inmon）給出了數(shù)據(jù)倉庫的定義，二十多年后的今天他的定義依然沒有被時代淘汰。我們來看看他是怎么定義的：“數(shù)據(jù)倉庫是一個面向主題的、集成的、相對穩(wěn)定的、反映歷史變化的數(shù)據(jù)集合，用于支持管理中的決策制定?！?/p>

我們可以不用管這個定義，簡單的理解，其實(shí)就是我們?yōu)榱诉M(jìn)行OLAP，把分布在各個散落獨(dú)立的數(shù)據(jù)庫孤島整合在了一個數(shù)據(jù)結(jié)構(gòu)里面，稱之為數(shù)據(jù)倉庫。這個數(shù)據(jù)倉庫在技術(shù)上是怎么建立的讀者朋友們并不需要關(guān)心，但是我們要知道，原來各個數(shù)據(jù)孤島中的數(shù)據(jù)，可能會在物理位置（比如沃爾瑪在各個州可能都有自己的數(shù)據(jù)中心）、存儲格式（比如月份是數(shù)值類型，但但天氣可能是字符類型）、商業(yè)平臺（不同數(shù)據(jù)庫可能用的是Oracle數(shù)據(jù)庫，有的是微軟SQL Server數(shù)據(jù)庫）、編寫的語言（Java或者Scale等）等等各個方面完全不同，數(shù)據(jù)倉庫要做的工作就是將他們按照所需要的格式提取出來，再進(jìn)行必要的轉(zhuǎn)換（統(tǒng)一數(shù)據(jù)格式）、清洗（去掉無效或者不需要的數(shù)據(jù)）等，最后裝載進(jìn)數(shù)據(jù)倉庫（我們所說的ETL工具就是用來干這個的）。這樣，拿我們上面紅牛的例子來說，所有的信息就統(tǒng)一放在了數(shù)據(jù)倉庫中了。

自從數(shù)據(jù)倉庫出現(xiàn)之后，信息產(chǎn)業(yè)就開始從以關(guān)系型數(shù)據(jù)庫為基礎(chǔ)的運(yùn)營式系統(tǒng)慢慢向決策支持系統(tǒng)發(fā)展。這個決策支持系統(tǒng)，其實(shí)就是我們現(xiàn)在說的商務(wù)智能（Business Intelligence）?？梢赃@么說，數(shù)據(jù)倉庫為OLAP解決了數(shù)據(jù)來源問題，數(shù)據(jù)倉庫和OLAP互相促進(jìn)發(fā)展，進(jìn)一步驅(qū)動了商務(wù)智能的成熟，但真正將商務(wù)智能賦予“智能”的，正是我們現(xiàn)在熱談的下一代技術(shù)：數(shù)據(jù)挖掘。