前幾篇聊了Google三駕馬車中的：

《GFS經(jīng)典架構(gòu)設(shè)計》

《MapReduce經(jīng)典架構(gòu)設(shè)計》

很多朋友讓我聊聊第三部分，Google BigTable。

BigTable，很多人對它耳熟能詳，但其工程架構(gòu)并沒有什么巨大的創(chuàng)新，今天和大家聊聊，Google為什么要發(fā)明BigTable，它究竟要解決什么問題呢？

什么是BigTable？

Google BigTable是一個分布式，結(jié)構(gòu)化數(shù)據(jù)的存儲系統(tǒng)，它用來存儲海量數(shù)據(jù)。該系統(tǒng)用來滿足“大數(shù)據(jù)量、高吞吐量、快速響應(yīng)”等不同應(yīng)用場景下的存儲需求。

畫外音：本質(zhì)上，BigTable是一個存儲系統(tǒng)。

有BigTable之前，Google面臨什么問題？

Google并不是一群人坐在辦公室開會，想出來的系統(tǒng)，Google面臨著很實(shí)際的業(yè)務(wù)問題。

畫外音：有些公司的基礎(chǔ)架構(gòu)部，是坐在辦公室開會，想出來的東西，然后強(qiáng)推業(yè)務(wù)線使用。

典型場景一：網(wǎng)頁存儲

Google每天要抓取很多網(wǎng)頁：

• 新出現(xiàn)的網(wǎng)頁，新URL；
• 舊網(wǎng)頁，舊URL；

對一個已抓取的網(wǎng)頁，舊URL為啥要反復(fù)抓取？

因?yàn)椋W(wǎng)頁會更新，例如新浪首頁：

sina.com.cn/index.html

URL雖然沒有變，但依然會抓取。

畫外音：我去，相當(dāng)于，被抓取的URL集合，只會無限增大，趨近無窮。

這里，對于存儲系統(tǒng)的需求，是要存儲：不同URL，不同時間Time，的內(nèi)容Content。

畫外音：URL+”Content”+Time => Binary。

網(wǎng)頁的實(shí)際內(nèi)容Binary，是Spider抓取出來的。

典型場景二：Google Analytics

Google Analytics要給站長展示其網(wǎng)站的流量PV，獨(dú)立用戶數(shù)UV，典型訪問路徑等，以幫助站長了解站點(diǎn)情況，優(yōu)化站點(diǎn)。

這里，對于存儲系統(tǒng)的需求，是要存儲，不同URL，不同時間Time，的PV和UV。

畫外音：

URL+”PV”+Time => $count
URL+”UV”+Time => $count

PV和UV的值，是MapReduce離線任務(wù)計算出來的。

不管是“網(wǎng)頁存儲”還是“站點(diǎn)統(tǒng)計”存儲，它們都有幾個共同的特點(diǎn)：

• 數(shù)據(jù)量極大，TB，PB級別；
• 和時間維度相關(guān)；
• 同一個主鍵，屬性與值有映射；

畫外音：

• 主鍵是URL，屬性是“Content”，值是網(wǎng)頁Binary；
• 主鍵是URL，屬性是“PV”和“UV”，值是計數(shù)count。

這是Google曾經(jīng)遇到的難題，面對這些難題，典型的解決方案又有哪些呢？

畫外音：不是一上來就搞新方案，最先肯定是想用現(xiàn)有的技術(shù)要如何解決。

最容易想到的主鍵，屬性，值的存儲系統(tǒng)是什么？

沒錯，就是關(guān)系型數(shù)據(jù)庫：

如上圖所示，用戶表

User(uid PK, name, gender, age, sex)

就是一個典型的主鍵，屬性，值的存儲模型：

• 主鍵，不同用戶的uid；
• 屬性，schema的列名；
• 值，不同主鍵的各個列名，對應(yīng)的值；

使用excel來舉例是很直觀的，這是一個二維table。

畫外音：屎黃色的主鍵是一個維度，橙色的屬性是一個維度。

用二維table能不能解決Google網(wǎng)頁存儲的問題呢？

如上圖所示，如果沒有時間維度Time，似乎是可以的：

• 主鍵，使用URL；
• 屬性，schema的列名，例如content，author等；
• 值，不同URL的內(nèi)容與作者等值；

但是，一旦加入時間維度Time，二維table似乎就不靈了。

畫外音：

• 增加一個time屬性是沒有用的；
• 增加一個time屬性，只能記錄同一個URL，某一個time的content，不能記錄多個time的多個content；
• 增加一個time屬性，聯(lián)合主鍵，URL就不是KEY了；

能不能用二維table存儲三維數(shù)據(jù)呢？

似乎可以通過trick的手段，在key上做文章，用key+time來拼接新key來實(shí)現(xiàn)。

如上圖所示，仍然是二維table，通過URL+Time來瓶裝key，也能夠?qū)崿F(xiàn)，存儲同一個URL，在不同Time，的不同content、author。

但是，這種trick方案存在的問題是：

(1) 沒法實(shí)現(xiàn)URL查詢

畫外音：key上無法進(jìn)行%like%查詢。

(2) 大量空洞，浪費(fèi)存儲空間

這并不是一個好的方案。

況且，當(dāng)數(shù)據(jù)量達(dá)到TB、PB級別時，傳統(tǒng)單機(jī)關(guān)系型數(shù)據(jù)庫，根本無法滿足Google的業(yè)務(wù)需求。

BigTable解決什么問題？

傳統(tǒng)二維small table，無法解決Google面臨的存儲問題，于是Google搞了一個big table來解決。

Google對這些業(yè)務(wù)模型進(jìn)行分析，在二維table的基礎(chǔ)上擴(kuò)充，抽象了一個新的“三維table”：

• 主鍵，使用URL；
• 屬性，schema的列名，例如content，author等；
• 時間，timestamp；
• 值，不同URL的內(nèi)容與作者等值；

如上圖所示：

• 第一維：key（屎黃色）；
• 第二維：屬性（橙色）；
• 第三維：time（藍(lán)色）；

同一個key，不同屬性，不同時間，會存儲一個value。

不像以行為單位進(jìn)行存儲的傳統(tǒng)關(guān)系型數(shù)據(jù)庫，這個三維的大表格BigTable是一個稀疏列存儲系統(tǒng)。

畫外音：能夠壓縮空間。

它的數(shù)據(jù)模型的本質(zhì)是一個map：

key + column + time => value

的一個超級大map。

畫外音：

• 很多業(yè)務(wù)符合這一個模型；
• Google的東西能解決業(yè)務(wù)問題，所以用的人多，這一點(diǎn)很重要。

總結(jié)

BigTable是一個稀疏的、分布式的、持久化的、多維度排序的、大數(shù)據(jù)量存儲系統(tǒng)，它能夠解決符合上述map數(shù)據(jù)模型業(yè)務(wù)的存儲問題。

畫外音：

• GFS是文件系統(tǒng)；
• MapReduce是計算模型；
• BigTable是存儲系統(tǒng)。

有了這三套技術(shù)底座，再加上后來的分布式鎖服務(wù)，Google率先實(shí)現(xiàn)技術(shù)的突破，業(yè)務(wù)也直接起飛了。

知其然，知其所以然。

思路比結(jié)論更重要。