我們生活在一個互聯(lián)網(wǎng)時代，無論是想搜索最佳的火雞菜譜，還是送媽媽什么樣的生日禮物，都希望能夠通過互聯(lián)網(wǎng)迅速地檢索到問題的答案，同時希望查詢到的結(jié)果有用，而且非常切合我們的需要。
因此，很多公司開始致力于提供更有針對性的信息，例如推薦或在線廣告，這種能力會直接影響公司在商業(yè)上的成敗?，F(xiàn)在類似Hadoop ① 這樣的系統(tǒng)能夠為公司提供存儲和處理PB級數(shù)據(jù)的能力，隨著新機器學(xué)習(xí)算法的不斷發(fā)展，收集更多數(shù)據(jù)的需求也在與日俱增。
以前，因為缺乏劃算的方式來存儲所有信息，很多公司會忽略某些數(shù)據(jù)源，但是現(xiàn)在這樣的處理方式會讓公司喪失競爭力。存儲和分析每一個數(shù)據(jù)點的需求在不斷增長，這種需求的增長直接導(dǎo)致各公司電子商務(wù)平臺產(chǎn)生了更多的數(shù)據(jù)。
過去，唯一的選擇就是將收集到的數(shù)據(jù)刪減后保存起來，例如只保留最近N天的數(shù)據(jù)。然而，這種方法只在短期內(nèi)可行，它無法存儲幾個月或幾年收集到的所有數(shù)據(jù)，因此建議：構(gòu)建一種數(shù)學(xué)模型覆蓋整個時間段或者改進一個算法，重跑以前所有的數(shù)據(jù)，以達到更好的效果。
對于海量數(shù)據(jù)的重要性，Ralph Kimball博士指出 ② ：
“數(shù)據(jù)資產(chǎn)會取代20世紀(jì)傳統(tǒng)有形資產(chǎn)的地位，成為資產(chǎn)負債表的重要組成部分。”
還指出：
“數(shù)據(jù)的價值已經(jīng)超越了傳統(tǒng)企業(yè)廣泛認同的價值邊界。”
Google和Amazon是認識到數(shù)據(jù)價值的典范，它們已經(jīng)開始開發(fā)滿足自己業(yè)務(wù)需求的解決方案。例如，Google在一系列的技術(shù)出版物中描述了基于商業(yè)硬件的可擴展的存儲和處理系統(tǒng)。開源社區(qū)利用Google的這些思想實現(xiàn)了開源Hadoop項目的兩個模塊：HDFS和MapReduce。
Hadoop擅長存儲任意的、半結(jié)構(gòu)化的數(shù)據(jù)，甚至是非結(jié)構(gòu)化的數(shù)據(jù)，可以幫助用戶在分析數(shù)據(jù)的時候決定如何解釋這些數(shù)據(jù)，同樣允許用戶隨時更改數(shù)據(jù)分類的方式：一旦用戶更新了算法，只需要重新分析數(shù)據(jù)。
目前Hadoop幾乎是所有現(xiàn)有數(shù)據(jù)庫系統(tǒng)的一種補充，它給用戶提供了數(shù)據(jù)存儲的無限空間，支持用戶在恰當(dāng)?shù)臅r候存儲和獲取數(shù)據(jù)，并且針對大文件的存儲、批量訪問和流式訪問做了優(yōu)化。這使得用戶對數(shù)據(jù)的分析變得簡單快捷，但是用戶同樣需要訪問分析后的最終數(shù)據(jù)，這種需求需要的不是批量模式而是隨機訪問模式，這種模式相對于在數(shù)據(jù)庫系統(tǒng)來說，相當(dāng)于一種全表掃描和使用索引。
通常用戶在隨機訪問結(jié)構(gòu)化數(shù)據(jù)的時候都會查詢數(shù)據(jù)庫。RDBMS在這方面最為突出，但是也有一些少量的有差異的實現(xiàn)方式，比如面向?qū)ο蟮臄?shù)據(jù)庫。大多數(shù)RDBMS一直遵守 科德十二定律 (Codd’s 12 rules) ③ ，這個定律對于RDBMS來說是剛性標(biāo)準(zhǔn)，并且由于RDBMS的底層架構(gòu)是經(jīng)過仔細研究的，所以在相當(dāng)長的一段時間里這種架構(gòu)都不會有明顯的改變。近年來出現(xiàn)的各種處理方法，如 列式存儲 的(column-oriented)數(shù)據(jù)庫和 大規(guī)模并行處理 (Massively Parallel Processing，MPP)數(shù)據(jù)庫，表明業(yè)界重新思考了技術(shù)方案以滿足新的工作負載，但是大多數(shù)解決方案仍舊是基于科德十二定律來實現(xiàn)的，并沒有打破傳統(tǒng)的法則。
列式存儲數(shù)據(jù)庫
列式存儲數(shù)據(jù)庫以列為單位聚合數(shù)據(jù)，然后將列值順序地存入磁盤，這種存儲方法不同于行式存儲的傳統(tǒng)數(shù)據(jù)庫，行式存儲數(shù)據(jù)庫連續(xù)地存儲整行。圖1形象地展示了列式存儲和行式存儲的不同物理結(jié)構(gòu)。
列式存儲的出現(xiàn)主要基于這樣一種假設(shè)：對于特定的查詢，不是所有的值都是必需的。尤其是在分析型數(shù)據(jù)庫里，這種情形很常見，因此需要選擇一種更為合適的存儲模式。
在這種新型的設(shè)計中，減少I/O只是眾多主要因素之一，它還有其他的優(yōu)點：因為列的數(shù)據(jù)類型天生是相似的，即便邏輯上每一行之間有輕微的不同，但仍舊比按行存儲的結(jié)構(gòu)聚集在一起的數(shù)據(jù)更利于壓縮，因為大多數(shù)的壓縮算法只關(guān)注有限的壓縮窗口。
像增量壓縮或前綴壓縮這類的專業(yè)算法，是基于列存儲的類型定制的，因而大幅度提高了壓縮比。更好的壓縮比有利于在返回結(jié)果時降低帶寬的消耗。
圖1 列式存儲結(jié)構(gòu)與行式存儲結(jié)構(gòu)
值得注意的是，從典型RDBMS的角度來看，HBase并不是一個列式存儲的數(shù)據(jù)庫，但是它利用了磁盤上的列存儲格式，這也是RDBMS與HBase最大的相似之處，因為HBase以列式存儲的格式在磁盤上存儲數(shù)據(jù)。但它與傳統(tǒng)的列式數(shù)據(jù)庫有很大的不同：傳統(tǒng)的列式數(shù)據(jù)庫比較適合實時存取數(shù)據(jù)的場景，HBase比較適合鍵值對的數(shù)據(jù)存取，或者有序的數(shù)據(jù)存取。