分布式表格系統Google Bigtable詳解

• • 概述
  • Bigtable架構
  • 數據分布
  • 保證
  • 副本位置與負載均衡
  • 存儲
  • • 表的分裂與合并
    • 存儲引擎
    • 垃圾回收
  • 總結

概述

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

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

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

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

保留最近的N個版本

保留限定時間內的所有版本

Bigtable架構

Bigtable主要由以下幾種服務組成：

Client對表格進行CRUD，通過Chubby獲取一些控制信息

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

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

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

Master選主

存儲bigtable根表的位置信息

TabletServer注冊服務

存儲bigtable schema信息

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

User Table：存儲實際用戶數據

Meta Table：存儲用戶表的元數據

Root Table：存儲Meta Table的元數據。相當于跟表引導到元數據表再引導到用戶表

數據分布

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

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

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

保證

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

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

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

每個子表包含的sstable數據，bigtable以最后一條寫入成功的sstable數據為準

bigtable可以實現單行事務single-row transactions。這點可以支撐其上的MegaStore

副本位置與負載均衡

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

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

因為遷移會導致當前子表停止服務一秒以內，因此遷移不能經常操作。

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

存儲

表的分裂與合并

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

分裂操作由Tablet Server發起，需要修改元數據。

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

存儲引擎

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

寫入memtable前要先持久化redo log，然后將數據寫到memtable中

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

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

Minor compaction是指將Memtable轉儲到GFS中

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

垃圾回收

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

總結

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

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

整個系統構建在GFS上，并且很多實現依賴GFS的支持。兩者之間有一定耦合。如果出現問題排查較為困難。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。