大數(shù)據(jù)分析技術(shù)最初起源于互聯(lián)網(wǎng)行業(yè)。網(wǎng)頁(yè)存檔、用戶點(diǎn)擊、商品信息、用戶關(guān)系等數(shù)據(jù)形成了持續(xù)增長(zhǎng)的海量數(shù)據(jù)集。這些大數(shù)據(jù)中蘊(yùn)藏著大量可以用于 增強(qiáng)用戶體驗(yàn)、提高服務(wù)質(zhì)量和開(kāi)發(fā)新型應(yīng)用的知識(shí)，而如何高效和準(zhǔn)確的發(fā)現(xiàn)這些知識(shí)就基本決定了各大互聯(lián)網(wǎng)公司在激烈競(jìng)爭(zhēng)環(huán)境中的位置。首先，以 Google為首的技術(shù)型互聯(lián)網(wǎng)公司提出了MapReduce的技術(shù)框架，利用廉價(jià)的PC服務(wù)器集群，大規(guī)模并發(fā)處理批量事務(wù)。

利用文件系統(tǒng)存放非結(jié)構(gòu)化數(shù)據(jù)，加上完善的備份和容災(zāi)策略，這套經(jīng)濟(jì)實(shí)惠的大數(shù)據(jù)解決方案與之前昂貴的企業(yè)小型機(jī)集群+商業(yè)數(shù)據(jù)庫(kù)方案相比，不僅沒(méi) 有丟失性能，而且還贏在了可擴(kuò)展性上。之前，我們?cè)谠O(shè)計(jì)一個(gè)數(shù)據(jù)中心解決方案的前期，就要考慮到方案實(shí)施后的可擴(kuò)展性。通常的方法是預(yù)估今后一段時(shí)期內(nèi)的 業(yè)務(wù)量和數(shù)據(jù)量，加入多余的計(jì)算單元（CPU）和存儲(chǔ)，以備不時(shí)只需。

這樣的方式直接導(dǎo)致了前期一次性投資的巨大，并且即使這樣也依然無(wú)法保證計(jì)算需求和存儲(chǔ)超出設(shè)計(jì)量時(shí)的系統(tǒng)性能。而一旦需要擴(kuò)容，問(wèn)題就會(huì)接踵而 來(lái)。首先是商業(yè)并行數(shù)據(jù)庫(kù)通常需要各節(jié)點(diǎn)物理同構(gòu)，也就是具有近似的計(jì)算和存儲(chǔ)能力。而隨著硬件的更新，我們通常加入的新硬件都會(huì)強(qiáng)于已有的硬件。這樣， 舊硬件就成為了系統(tǒng)的瓶頸。為了保證系統(tǒng)性能，我們不得不把舊硬件逐步替換掉，經(jīng)濟(jì)成本損失巨大。其次，即使是當(dāng)前最強(qiáng)的商業(yè)并行數(shù)據(jù)庫(kù)，其所能管理的數(shù) 據(jù)節(jié)點(diǎn)也只是在幾十或上百這個(gè)數(shù)量級(jí)，這主要是由于架構(gòu)上的設(shè)計(jì)問(wèn)題，所以其可擴(kuò)展性必然有限。

而MapReduce+GFS框架，不受上述問(wèn)題的困擾。需要擴(kuò)容了，只需增加個(gè)機(jī)柜，加入適當(dāng)?shù)挠?jì)算單元和存儲(chǔ)，集群系統(tǒng)會(huì)自動(dòng)分配和調(diào)度這些資 源，絲毫不影響現(xiàn)有系統(tǒng)的運(yùn)行。如今，我們用得更多的是Google MapReduce的開(kāi)源實(shí)現(xiàn)，即Hadoop。除了計(jì)算模型的發(fā)展，與此同時(shí)，人們也在關(guān)注著數(shù)據(jù)存儲(chǔ)模型。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)由于其規(guī)范的設(shè)計(jì)、友好 的查詢語(yǔ)言、高效的數(shù)據(jù)處理在線事務(wù)的能力，長(zhǎng)時(shí)間地占據(jù)了市場(chǎng)的主導(dǎo)地位。

然而，其嚴(yán)格的設(shè)計(jì)定式、為保證強(qiáng)一致性而放棄性能、可擴(kuò)展性差等問(wèn)題在大數(shù)據(jù)分析中被逐漸暴露。隨之而來(lái)，NoSQL數(shù)據(jù)存儲(chǔ)模型開(kāi)始風(fēng)行。 NoSQL，也有人理解為Not>