Big Data是近來的一個技術(shù)熱點，但從名字就能判斷它并不是什么新詞。畢竟，大是一個相對概念。歷史上，數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)集市等信息管理領(lǐng)域的技術(shù)，很大程度上也是為了解決大規(guī)模數(shù)據(jù)的問題。被譽為數(shù)據(jù)倉庫之父的Bill Inmon早在20世紀90年代就經(jīng)常將Big Data掛在嘴邊了。
然而，Big Data作為一個專有名詞成為熱點，主要應(yīng)歸功于近年來互聯(lián)網(wǎng)、云計算、移動和物聯(lián)網(wǎng)的迅猛發(fā)展。無所不在的移動設(shè)備、RFID、無線傳感器每分每秒都在產(chǎn)生數(shù)據(jù)，數(shù)以億計用戶的互聯(lián)網(wǎng)服務(wù)時時刻刻在產(chǎn)生巨量的交互……要處理的數(shù)據(jù)量實在是太大、增長太快了，而業(yè)務(wù)需求和競爭壓力對數(shù)據(jù)處理的實時性、有效性又提出了更高要求，傳統(tǒng)的常規(guī)技術(shù)手段根本無法應(yīng)付。
在這種情況下，技術(shù)人員紛紛研發(fā)和采用了一批新技術(shù)，主要包括分布式緩存、基于MPP的分布式數(shù)據(jù)庫、分布式文件系統(tǒng)、各種NoSQL分布式存儲方案等。
10年前，Eric Brewer提出著名的CAP定理，指出：一個分布式系統(tǒng)不可能滿足一致性、可用性和分區(qū)容忍性這三個需求，最多只能同時滿足兩個。系統(tǒng)的關(guān)注點不同，采用的策略也不一樣。只有真正理解了系統(tǒng)的需求，才有可能利用好CAP定理。
架構(gòu)師一般有兩個方向來利用CAP理論。
Key-Value存儲，如Amazon Dynamo等，可以根據(jù)CAP理論靈活選擇不同傾向的數(shù)據(jù)庫產(chǎn)品。
領(lǐng)域模型+分布式緩存+存儲，可根據(jù)CAP理論結(jié)合自己的項目定制靈活的分布式方案，但難度較高。
對大型網(wǎng)站，可用性與分區(qū)容忍性優(yōu)先級要高于數(shù)據(jù)一致性，一般會盡量朝著A、P的方向設(shè)計，然后通過其他手段保證對于一致性的商務(wù)需求。架構(gòu)設(shè)計師不要將精力浪費在如何設(shè)計能滿足三者的完美分布式系統(tǒng)，而應(yīng)該懂得取舍。
不同的數(shù)據(jù)對一致性的要求是不同的。SNS網(wǎng)站可以容忍相對較長時間的不一致，而不影響交易和用戶體驗；而像支付寶這樣的交易和賬務(wù)數(shù)據(jù)則是非常敏感的，通常不能容忍超過秒級的不一致。
Cache篇
緩存在Web開發(fā)中運用越來越廣泛，mem-cached是danga.com（運營LiveJournal的技術(shù)團隊）開發(fā)的一套分布式內(nèi)存對象緩存系統(tǒng)，用于在動態(tài)系統(tǒng)中減少數(shù)據(jù)庫負載，提升性能。
memcached具有以下特點：
協(xié)議簡單；基于libevent的事件處理；內(nèi)置內(nèi)存存儲方式；memcached不互相通信的分布式。
memcached處理的原子是每一個（Key，Value）對（以下簡稱KV對），Key會通過一個hash算法轉(zhuǎn)化成hash-Key，便于查找、對比以及做到盡可能的散列。同時，memcached用的是一個二級散列，通過一張大hash表來維護。
memcached由兩個核心組件組成：服務(wù)端（ms）和客戶端（mc），在一個memcached的查詢中，ms先通過計算Key的hash值來確定KV對所處在的ms位置。當ms確定后，mc就會發(fā)送一個查詢請求給對應(yīng)的ms，讓它來查找確切的數(shù)據(jù)。因為這之間沒有交互以及多播協(xié)議，所以memcached交互帶給網(wǎng)絡(luò)的影響是最小化的。
MemcacheDB是一個分布式、Key-Value形式的持久存儲系統(tǒng)。它不是一個緩存組件，而是一個基于對象存取的、可靠的、快速的持久存儲引擎。協(xié)議與memcached一致（不完整），所以很多memcached客戶端都可以跟它連接。MemcacheDB采用Berkeley DB作為持久存儲組件，因此很多Berkeley DB的特性它都支持。
類似這樣的產(chǎn)品也很多，如淘寶Tair就是Key-Value結(jié)構(gòu)存儲，在淘寶得到了廣泛使用。后來Tair也做了一個持久化版本，思路基本與新浪MemcacheDB一致。
分布式數(shù)據(jù)庫篇
支付寶公司在國內(nèi)最早使用Greenplum數(shù)據(jù)庫，將數(shù)據(jù)倉庫從原來的Oracle RAC平臺遷移到Greenplum集群。Greenplum強大的計算能力用來支持支付寶日益發(fā)展的業(yè)務(wù)需求。
Greenplum數(shù)據(jù)引擎軟件專為新一代數(shù)據(jù)倉庫所需的大規(guī)模數(shù)據(jù)和復(fù)雜查詢功能所設(shè)計，基于MPP（海量并行處理）和Shared-Nothing（完全無共享）架構(gòu)，基于開源軟件和x86商用硬件設(shè)計（性價比更高）。
分布式文件系統(tǒng)篇
談到分布式文件系統(tǒng)，不得不提的是Google的GFS?；诖罅堪惭b有Linux操作系統(tǒng)的普通PC構(gòu)成的集群系統(tǒng)，整個集群系統(tǒng)由一臺Master（通常有幾臺備份）和若干臺TrunkServer構(gòu)成。GFS中文件備份成固定大小的Trunk分別存儲在不同的TrunkServer上，每個Trunk有多份（通常為3份）拷貝，也存儲在不同的TrunkServer上。Master負責維護GFS中的 Metadata，即文件名及其Trunk信息?？蛻舳讼葟腗aster上得到文件的Metadata，根據(jù)要讀取的數(shù)據(jù)在文件中的位置與相應(yīng)的TrunkServer通信，獲取文件數(shù)據(jù)。
圖3 引自Facebook工程師的Hive與Hadoop關(guān)系圖
在Google的論文發(fā)表后，就誕生了Hadoop。截至今日，Hadoop被很多中國最大互聯(lián)網(wǎng)公司所追捧，百度的搜索日志分析，騰訊、淘寶和支付寶的數(shù)據(jù)倉庫都可以看到Hadoop的身影。
Hadoop具備低廉的硬件成本、開源的軟件體系、較強的靈活性、允許用戶自己修改代碼等特點，同時能支持海量數(shù)據(jù)存儲和計算任務(wù)。
Hive是一個基于Hadoop的數(shù)據(jù)倉庫平臺，將轉(zhuǎn)化為相應(yīng)的MapReduce程序基于Hadoop執(zhí)行。通過Hive，開發(fā)人員可以方便地進行ETL開發(fā)。
如圖3所示，引用一張Facebook工程師做的Hive和Hadoop的關(guān)系圖。
NoSQL篇
隨著數(shù)據(jù)量增長，越來越多的人關(guān)注NoSQL，特別是2010年下半年，F(xiàn)acebook選擇HBase來做實時消息存儲系統(tǒng)，替換原來開發(fā)的Cassandra系統(tǒng)。這使得很多人開始關(guān)注HBase。Facebook選擇HBase是基于短期小批量臨時數(shù)據(jù)和長期增長的很少被訪問到的數(shù)據(jù)這兩個需求來考慮的。
HBase是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用HBase技術(shù)可在廉價PC Server上搭建大規(guī)模結(jié)構(gòu)化存儲集群。HBase是BigTable的開源實現(xiàn)，使用HDFS作為其文件存儲系統(tǒng)。Google運行MapReduce來處理BigTable中的海量數(shù)據(jù)，HBase同樣利用MapReduce來處理HBase中的海量數(shù)據(jù)；BigTable利用Chubby作為協(xié)同服務(wù)，HBase則利用Zookeeper作為對應(yīng)。
圖4 線上應(yīng)用系統(tǒng)與數(shù)據(jù)平臺的無縫融入
總結(jié)篇
近來NoSQL數(shù)據(jù)庫的使用越來越普及，幾乎所有的大型互聯(lián)網(wǎng)公司都在這個領(lǐng)域進行著實踐和探索。在享受了這類數(shù)據(jù)庫與生俱來的擴展性、容錯性、高讀寫吞吐外（盡管各主流NoSQL仍在不斷完善中），越來越多的實際需求把人們帶到了NoSQL并不擅長的其他領(lǐng)域，比如搜索、準實時統(tǒng)計分析、簡單事務(wù)等。實踐中一般會在NoSQL的外圍組合一些其他技術(shù)形成一個整體解決方案。
準實時的統(tǒng)計分析
傳輸時統(tǒng)計分析，Stream Processing技術(shù)：FlumeBase、S4。
FlumeBase：可參考 http://flumebase.org/documentation/0.1.0/UserGuide.html中的quick start和architecture兩部分。
S4：Yahoo!開源數(shù)據(jù)來流計算實時框架，可參考http://labs.yahoo.com/files/KDCloud%202010%20S4.pdf。
查詢時統(tǒng)計分析，結(jié)果集較小時，可以直接在返回前做統(tǒng)計分析處理。
比如買家消費記錄查詢的HBase實現(xiàn)，Schema設(shè)計，rowkey=uid，column=搜索詞和查詢值，version=交易id。
搜索相關(guān)
充分利用NoSQL（比如HBase）內(nèi)部數(shù)據(jù)的有序性、Row Key、Column Family、Version Timestamp。
我們用“HBase+二次索引”來實現(xiàn)實時營銷的解決方案。也可以參考Facebook Message的解決方案：http://blog.bluedavy.com/?p=258。
構(gòu)建一個外圍系統(tǒng)完成索引建立。
Google MegaStore：原文鏈接為http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf，中文譯文鏈接為http://cloud.csdn.net/a/20110216/291968.html。
也有人開始嘗試基于HBase的MegaStore實現(xiàn)，鏈接為https://github.com/drevell/megalon。
簡單事務(wù)
事務(wù)處理服務(wù) + NoSQL存儲。
淘寶開發(fā)的千億級海量數(shù)據(jù)庫Oceanbase，通過update server角色執(zhí)行將寫操作限制在一臺機器上，實現(xiàn)事務(wù)。參考鏈接為：http://www.nosqlnotes.net/archives/170。
Google MegaStore通過為用戶提供機制，根據(jù)應(yīng)用特點劃分entity group，將事務(wù)涉及的數(shù)據(jù)分布到一臺機器上，實現(xiàn)事務(wù)
