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