谷歌“三駕馬車”的出現，才真正把我們帶入了大數據時代，並指明瞭大數據的發展方向。

GFS 作為其中一駕寶車，解決了大數據存儲的難題。它能夠把大量廉價的普通機器，聚在一起，充分讓每台廉價的機器發揮光和熱。其中在《從谷歌 GFS 架構設計聊開去》中我們針對 GFS 進行了管中窺豹，體會到其中一斑，不得不說是人多力量大，團結就是力量的體現。

MapReduce 作為其中一座寶駕出現，主要解決海量數據計算的頭痛難題。在《悟懂MapReduce，不糾結！》中我們引入一個接地氣的“農村掰玉米”的案例進行了 MapReduce 思想的體會，大體意思是說， Map 就像人手掰一壠玉米（有個別生玉米+多數熟玉米），負責掰就行；Reduce 就像有專門收生玉米的；有專門收熟玉米的，然後各自進行彙總統計。

簡單去講，GFS 解決了分散式文件的存儲，MapReduce 解決了海量數據的計算。

但是天生好奇，心生疑問“實時線上應用的海量結構化數據該如何存儲呢？”那麼不得不提及谷歌的第三駕馬車“BigTable”。

背景？

眾所周知，Google 要存儲海量的網頁，而且要能夠存儲一個 URL 的不同時期的多個版本的網頁內容（因為網頁會不斷的更新，所以爬蟲也要不斷的針對同一個 URL 進行爬取）。

上圖是摘自 BigTable 的論文，老圖配新曲，在此處主要用來闡述 BigTable 產生的其中一個背景，從中我們能夠得出如下公式。

com.cnn.www + contents: + t3 => html網頁內容

com.cnn.www + contents: + t5 => html網頁內容

com.cnn.www + contents: + t6 => html網頁內容

那麼 Google 就需要設計一款類似以“URL +  contents + time stamp”為 key，以“html 網頁內容”為值的存儲系統，於是就有了 BigTable 這個鍵值系統的存在。

是啥？

Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers.

官方定義。Bigtable 是一個分散式的結構化數據存儲系統，它被設計用來處理海量數據：通常是分佈在數千台普通伺服器上的 PB 級的數據。

說清楚 BigTable 存儲啥樣子？一段話（一簞食）

A Bigtable is a sparse, distributed, persistentmulti-dimensionalsorted map.The map is indexed by a row key, column key, and a timestamp;each value in the map is an uninterpreted array of bytes.

• BigTable 是一個稀疏的、分散式的、持久化存儲的多維度排序的 Map.（寫過兩天代碼的都不陌生，Map 由 key 和 value 組成）;

• Map 的 key 是行關鍵字、列關鍵字以及時間戳組成；

• Map 的 value 都是一個未經解析的 byte 數組。

看透徹 BigTable 存儲啥樣子？一張圖（一瓢飲）

• 可以看出 BigTable 用三維（row 行關鍵字、column 列關鍵字、time 時間戳）方式定位數據，也就是以“行關鍵字、列關鍵字、時間戳”為 key 來定位數據；

• 我們也可以認為 BigTable 是屬於 key-Value 的 NOSQL 資料庫系列（為你在技術選型時再加一備選）。

一段話（一簞食）+ 一張圖（一瓢飲） = BigTable（足矣）。

好了，到這應該對 BigTable 懵懵懂，如果感覺蒙圈、迷茫了，建議動動手指分享轉發一下（言外之意：如果沒看懂，就忽略此篇分享，莫要影響心情，因為愉悅的心情真的很重要！！！）；如果感覺稍微有點意思或者豁然開朗，那就繼續往下追。

設計？

默默跟隨“一猿小講”腳步的應該都清楚，GFS 也好、MapReduce 也罷，參與者角色都採取了簡單就是美的大道至簡的思想設計，都秉承了“一人掌權，其他人辦事”的理念，那我們不妨看看 BigTable 背後是不是也是這樣的設計呢？

BigTable 主要參與者：鏈接到客戶程式中的庫、一個 Master 伺服器和多個 Tablet 伺服器（這不就是咱們之前說 GFS 的皇上~宰相模式）。

Master伺服器 （皇上）主要負責以下工作：

• 為 Tablet 伺服器分配 Tablets；

• 檢測新加入的或者過期失效的 Tablet 伺服器；

• 對 Tablet 伺服器進行負載均衡；

• 對保存在 GFS 上的文件進行垃圾收集；

• 對模式的相關修改操作，例如建立表和列族。

Tablet伺服器 （宰相）主要負責以下工作：

• 管理一個 Tablet 的集合（通常每個伺服器有大約數十個至上千個 Tablet）；

• 負責處理它所載入的 Tablet 的讀寫操作；

• 負責在 Tablets 過大時，對其進行分割。

運轉？

寫操作。

• Tablet 伺服器首先檢查這個操作格式是否正確、操作發起者是否有執行這個操作的許可權；

• 如果校驗通過，將寫請求提交到日誌 tablet log；

• 然後將數據寫入記憶體中的 memtable；

• 當 memtable 存到一定規模會被凍結，Bigtable 隨之創建一個新的 memtable，並將凍結的 memtable 寫入分散式文件系統 GFS。

讀操作。

• Tablet 伺服器首先進行完整性和許可權檢查；

• 然後將一系列 SSTable 和 memtable 的存儲內容組成一個

  大的視圖，然後從中進行讀取。

設計要點：讀也好，寫也罷，客戶程式其實直接和 Tablet 伺服器通信進行讀寫操作，所以 Master 伺服器的負載是很輕的。

技術棧？

BigTable 使用 Google 的分散式文件系統 GFS作為底層數據存儲。

BigTable 內部存儲數據的文件是 Google SSTable 格式的；（SSTable 是一個持久化的、排序的、不可更改的 Map 結構，點一首楊坤的“無所謂”送給你，該糾結時糾結，不該糾結時莫糾結，重要的是心情愉悅）。

BigTable 使用 Chubby 提供協同服務管理（若懵圈了，就想想 ZooKeeper）。

思考？

畫龍畫虎難畫骨！目前的一切還是浮於表象，有沒有更進一步的認識呢？那就讓時間來告訴我們吧！

好了，這篇分享都到這兒吧，希望你們能夠喜歡，如果感覺有點幫助，那就動動手指轉發分享一下吧。