分布式表格系統(tǒng)Google Bigtable詳解

• • 概述
  • Bigtable架構(gòu)
  • 數(shù)據(jù)分布
  • 保證
  • 副本位置與負(fù)載均衡
  • 存儲
  • • 表的分裂與合并
    • 存儲引擎
    • 垃圾回收
  • 總結(jié)

概述

bigtable系統(tǒng)由表格組成，每行有一個主鍵（Row Key），每行又包含很多列(Column)，某一行的某一列構(gòu)成一個單元（Cell），每個單元包含多個版本的數(shù)據(jù)。整體上看，Bigtable是一個分布式多維映射表：

$$(row:string,column:string,timestamp:int64)?>string$$

另外，Bigtable引入了列族（column family）的概念。多個列形成一個列族。其由兩部分組成：(columnh family qualifier)

Bigtable支持時間戳是谷歌上層業(yè)務(wù)的需求。為了簡化不同版本的數(shù)據(jù)管理，Bigtable提供了兩種設(shè)置：

保留最近的N個版本

保留限定時間內(nèi)的所有版本

Bigtable架構(gòu)

Bigtable主要由以下幾種服務(wù)組成：

Client對表格進(jìn)行CRUD，通過Chubby獲取一些控制信息

Master管理所有的子表，包括子表的分配、合并、接收從TabletServer傳來的子表分裂消息、監(jiān)控TabletServer，以及TabletServer的負(fù)載均衡和故障恢復(fù)

Tablet Server子表服務(wù)器，完成所有存儲相關(guān)操作，如CRUD，子表的合并與分裂，操作日志（每條操作日志都有唯一的序號）和sstable的操作。所有的表都是單副本。

Chubby：bigtable使用Chubby完成以下功能，如果Chubby不可用，則bigtable整個系統(tǒng)不可用，其主要提供了以下服務(wù)：

Master選主

存儲bigtable根表的位置信息

TabletServer注冊服務(wù)

存儲bigtable schema信息

Bigtable主要提供了三種類型的表：

User Table：存儲實際用戶數(shù)據(jù)

Meta Table：存儲用戶表的元數(shù)據(jù)

Root Table：存儲Meta Table的元數(shù)據(jù)。相當(dāng)于跟表引導(dǎo)到元數(shù)據(jù)表再引導(dǎo)到用戶表

數(shù)據(jù)分布

bigtable底層分為100M-200M的子表，通過一個根表和兩級元數(shù)據(jù)表建立索引。我們假設(shè)平均一個子表為128M，每個子表的元數(shù)據(jù)信息為1KB，那么兩級元數(shù)據(jù)表能支持的數(shù)據(jù)量為$128M?(128M/1K)?(128M/1K)=2048PB$

客戶端會緩存子表元數(shù)據(jù)，如果緩存為空或者緩存過期，則通過根表->一級子表->二級子表的查找順序來讀取子表的位置信息。

使用prefetch(預(yù)取)技術(shù)，每次訪問元數(shù)據(jù)表的時候，不僅讀取所需子表的信息，而且讀取連續(xù)多個子表數(shù)據(jù)，這樣訪問下一個子表就不需要再次訪問元數(shù)據(jù)表了。（mysql也有類似的優(yōu)化）

保證

通過Chubby提供跨進(jìn)程鎖，保證同一時間只有一個TabletServer訪問一個子表，如果該TabletServer出現(xiàn)故障，Master需要等TabletServer互斥鎖失效，才能將其上的子表遷移到其他TabletServer上。

由于bigtable底層使用GFS，GFS的追加寫只保證“同一紀(jì)錄至少成功寫入一次”，所以bigtable使用了如下方法保證數(shù)據(jù)的安全：

記錄操作日志（redo log），每條操作日志都有唯一的序號，從而去除重復(fù)的操作日志，故障的時候一部分sstable數(shù)據(jù)由于存儲在內(nèi)存中丟失了，需要通過回放操作日志來恢復(fù)

每個子表包含的sstable數(shù)據(jù)，bigtable以最后一條寫入成功的sstable數(shù)據(jù)為準(zhǔn)

bigtable可以實現(xiàn)單行事務(wù)single-row transactions。這點可以支撐其上的MegaStore

副本位置與負(fù)載均衡

Table Server會定期向Master匯報負(fù)載狀態(tài)，如果Master發(fā)現(xiàn)某個Table Server負(fù)載過重，會自動對其進(jìn)行負(fù)載均衡。負(fù)載由很多指標(biāo)構(gòu)成，也考慮了很多現(xiàn)實中遇到的問題（可以在論文中行收balanc了解）。負(fù)載均衡就是將該Table Server中的某些子表遷移到其他Table Server上。

首先Bigtable是構(gòu)建在GFS之上的，所以子表自己不存在replication。子表的遷移實質(zhì)上是當(dāng)前Table Server將所有的mutable數(shù)據(jù)持久化到GFS中，然后掛載到另一個Table Server中（有點像Shared Disk中的備升主）。理所應(yīng)當(dāng)?shù)?#xff0c;遷移的過程中會有短暫的IO停頓。子表遷移前原有的Table Server會對其執(zhí)行Minor Compaction操作（為了縮短停止服務(wù)的時間，可能會有兩次Minor Compaction），然后遷移。當(dāng)然了，發(fā)生遷移最頻繁的場景我認(rèn)為還是recovery，因為文中提到了，遷移子表的這種負(fù)載均衡策略并不是Silver Bullet，在工程上經(jīng)常遇到以下問題：

因為遷移會導(dǎo)致當(dāng)前子表停止服務(wù)一秒以內(nèi)，因此遷移不能經(jīng)常操作。

另外就是系統(tǒng)的負(fù)載熱點不會一直集中在某點。他會隨著時間的推移而變化。

存儲

表的分裂與合并

一個table只存在于一個Tablet Server上。但是table太大或太小時需要分裂或合并。

分裂操作由Tablet Server發(fā)起，需要修改元數(shù)據(jù)。

合并由Master發(fā)起，兩個表需要先遷移到同一個Tablet Server，再執(zhí)行合并。

存儲引擎

分為memtable和sstable，數(shù)據(jù)在sstable中是有序存儲的。讀取的時候需要按從舊到新的的時間順序合并SStable和Memtable的數(shù)據(jù)

寫入memtable前要先持久化redo log，然后將數(shù)據(jù)寫到memtable中

CRUD操作在sstable看來都是一樣的，sstable中記錄的只是操作，而不是最終的結(jié)果，只有到read操作的時候才會合并得到最終的操作

三種策略：Minor compaction、Merging Compaction、Major Compaction

Minor compaction是指將Memtable轉(zhuǎn)儲到GFS中

Merging Compaction和Major Compaction都是將多個sstable合并成一個更大的sstable，區(qū)別在于Merging Compaction合并的不完全，其結(jié)果可能包含一些刪除、增加等操作，而Major Compaction會合并所有的sstable和memtable，生成最終的結(jié)果。

垃圾回收

compaction完成之后，原來的SSTable需要被回收掉。Master會定期執(zhí)行垃圾回收任務(wù)。需要注意的是，對sstable執(zhí)行compaction和修改sstable對應(yīng)的元數(shù)據(jù)這兩個操作不是原子的。需要注意這里面可能造成的數(shù)據(jù)不一致問題。

總結(jié)

Bigtable構(gòu)造在GFS之上，其操作不用考慮底層數(shù)據(jù)的可用性等問題，并且GFS也大大增強了Bigtable的擴(kuò)展性，讓Bigtable的設(shè)計者可以不用考慮底層，更專注于上層的優(yōu)化。但是也存在一些問題：

由于table只存在于一個Tablet Server上，單個節(jié)點顯然會有瓶頸。當(dāng)然我們可以引入諸如分庫分表、Shared Disk等概念緩解這個瓶頸。

整個系統(tǒng)構(gòu)建在GFS上，并且很多實現(xiàn)依賴GFS的支持。兩者之間有一定耦合。如果出現(xiàn)問題排查較為困難。

總結(jié)

以上是生活随笔為你收集整理的分布式表格系统Google Bigtable详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。