前幾篇聊了Google三駕馬車(chē)中的：

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

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

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

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

什么是BigTable？

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

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

有BigTable之前，Google面臨什么問(wèn)題？

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

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

典型場(chǎng)景一：網(wǎng)頁(yè)存儲(chǔ)

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

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

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

因?yàn)?，網(wǎng)頁(yè)會(huì)更新，例如新浪首頁(yè)：

sina.com.cn/index.html

URL雖然沒(méi)有變，但依然會(huì)抓取。

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

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

畫(huà)外音：URL+”Content”+Time => Binary。

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

典型場(chǎng)景二：Google Analytics

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

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

畫(huà)外音：

URL+”P(pán)V”+Time => $count
URL+”UV”+Time => $count

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

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

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

畫(huà)外音：

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

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

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

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

沒(méi)錯(cuò)，就是關(guān)系型數(shù)據(jù)庫(kù)：

如上圖所示，用戶表

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

就是一個(gè)典型的主鍵，屬性，值的存儲(chǔ)模型：

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

使用excel來(lái)舉例是很直觀的，這是一個(gè)二維table。

畫(huà)外音：屎黃色的主鍵是一個(gè)維度，橙色的屬性是一個(gè)維度。

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

如上圖所示，如果沒(méi)有時(shí)間維度Time，似乎是可以的：

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

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

畫(huà)外音：

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

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

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

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

但是，這種trick方案存在的問(wèn)題是：

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

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

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

這并不是一個(gè)好的方案。

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

BigTable解決什么問(wèn)題？

傳統(tǒng)二維small table，無(wú)法解決Google面臨的存儲(chǔ)問(wèn)題，于是Google搞了一個(gè)big table來(lái)解決。

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

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

如上圖所示：

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

同一個(gè)key，不同屬性，不同時(shí)間，會(huì)存儲(chǔ)一個(gè)value。

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

畫(huà)外音：能夠壓縮空間。

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

key + column + time => value

的一個(gè)超級(jí)大map。

畫(huà)外音：

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

總結(jié)

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

畫(huà)外音：

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

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

知其然，知其所以然。

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