分布式表格系统GoogleBigtable详解
分布式表格系统Google Bigtable详解
栖息近义词
关于国庆节的对联概述
bigtable系统由表格组成，每⾏有⼀个主键（Row Key），每⾏⼜包含很多列(Column)，某⼀⾏的某⼀列构成⼀个单元（Cell），每个单元包含多个版本的数据。整体上看，Bigtable是⼀个分布式多维映射表：
(row:string,column:string,timestamp:int64)−>string
另外，Bigtable引⼊了列族（column family）的概念。多个列形成⼀个列族。其由两部分组成：(column
h family qualifier)
Bigtable⽀持时间戳是⾕歌上层业务的需求。为了简化不同版本的数据管理，Bigtable提供了两种设置：
1. 保留最近的N个版本
2. 保留限定时间内的所有版本
Bigtable架构
Bigtable主要由以下⼏种服务组成：
1. Client对表格进⾏CRUD，通过Chubby获取⼀些控制信息
2. Master管理所有的⼦表，包括⼦表的分配、合并、接收从TabletServer传来的⼦表分裂消息、监控TabletServer，以及
TabletServer的负载均衡和故障恢复
3. Tablet Server⼦表服务器，完成所有存储相关操作，如CRUD，⼦表的合并与分裂，操作⽇志（每
条操作⽇志都有唯⼀的序号）和
sstable的操作。所有的表都是单副本。
4. Chubby：bigtable使⽤Chubby完成以下功能，如果Chubby不可⽤，则bigtable整个系统不可⽤，其主要提供了以下服务：
1. Master选主
2. 存储bigtable根表的位置信息
3. TabletServer注册服务
4. 存储bigtable schema信息
Bigtable主要提供了三种类型的表：
1. Ur Table：存储实际⽤户数据
2. Meta Table：存储⽤户表的元数据
每股净资产什么意思
3. Root Table：存储Meta Table的元数据。相当于跟表引导到元数据表再引导到⽤户表
数据分布
bigtable底层分为100M-200M的⼦表，通过⼀个根表和两级元数据表建⽴索引。我们假设平均⼀个⼦表为128M，每个⼦表的元数据信息
肠炎宁胶囊说明书
128M∗(128M/1K)∗(128M/1K)=2048PB
为1KB，那么两级元数据表能⽀持的数据量为
1. 客户端会缓存⼦表元数据，如果缓存为空或者缓存过期，则通过根表->⼀级⼦表->⼆级⼦表的查找顺序来读取⼦表的位置信息。
2. 使⽤prefetch(预取)技术，每次访问元数据表的时候，不仅读取所需⼦表的信息，⽽且读取连续多个⼦表数据，这样访问下⼀个⼦表
就不需要再次访问元数据表了。（mysql也有类似的优化）
保证
1. 通过Chubby提供跨进程锁，保证同⼀时间只有⼀个TabletServer访问⼀个⼦表，如果该TabletServer出现故障，Master需要等
TabletServer互斥锁失效，才能将其上的⼦表迁移到其他TabletServer上。
2. 由于bigtable底层使⽤GFS，GFS的追加写只保证“同⼀纪录⾄少成功写⼊⼀次”，所以bigtable使⽤了如下⽅法保证数据的安全：
1. 记录操作⽇志（redo log），每条操作⽇志都有唯⼀的序号，从⽽去除重复的操作⽇志，故障的时候⼀部分sstable数据由于存怎样才能长高女生
储在内存中丢失了，需要通过回放操作⽇志来恢复
2. 每个⼦表包含的sstable数据，bigtable以最后⼀条写⼊成功的sstable数据为准
3. 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，在⼯程上经常遇到以下问题：
1. 因为迁移会导致当前⼦表停⽌服务⼀秒以内，因此迁移不能经常操作。
2. 另外就是系统的负载热点不会⼀直集中在某点。他会随着时间的推移⽽变化。
存储
表的分裂与合并
⼀个table只存在于⼀个Tablet Server上。但是table太⼤或太⼩时需要分裂或合并。
expen1. 分裂操作由Tablet Server发起，需要修改元数据。
2. 合并由Master发起，两个表需要先迁移到同⼀个Tablet Server，再执⾏合并。
存储引擎
1. 分为memtable和sstable，数据在sstable中是有序存储的。读取的时候需要按从旧到新的的时间顺序合并SStable和Memtable的数
据
2. 写⼊memtable前要先持久化redo log，然后将数据写到memtable中
3. CRUD操作在sstable看来都是⼀样的，sstable中记录的只是操作，⽽不是最终的结果，只有到read操作的时候才会合并得到最终的
操作
4. 三种策略：Minor compaction、Merging Compaction、Major Compaction
1. Minor compaction是指将Memtable转储到GFS中
吃粮不管事2. Merging Compaction和Major Compaction都是将多个sstable合并成⼀个更⼤的sstable，区别在于Merging Compaction
合并的不完全，其结果可能包含⼀些删除、增加等操作，⽽Major Compaction会合并所有的sstable和memtable，⽣成最终的结果。
垃圾回收
蒿草的功效与作用compaction完成之后，原来的SSTable需要被回收掉。Master会定期执⾏垃圾回收任务。需要注意的是，对sstable执⾏compaction和修改sstable对应的元数据这两个操作不是原⼦的。需要注意这⾥⾯可能造成的数据不⼀致问题。
总结
Bigtable构造在GFS之上，其操作不⽤考虑底层数据的可⽤性等问题，并且GFS也⼤⼤增强了Bigtable的扩展性，让Bigtable的设计者可以不⽤考虑底层，更专注于上层的优化。但是也存在⼀些问题：
1. 由于table只存在于⼀个Tablet Server上，单个节点显然会有瓶颈。当然我们可以引⼊诸如分库分表、Shared Disk等概念缓解这个
瓶颈。
2. 整个系统构建在GFS上，并且很多实现依赖GFS的⽀持。两者之间有⼀定耦合。如果出现问题排查较为困难。
