聊起 BigTable，让你再也不胆怯

谷歌“三驾马车”的出现，才真正把咱们带入了大数据时代，并指明了大数据的发展方向。

GFS 做为其中一驾宝车，解决了大数据存储的难题。它可以把大量廉价的普通机器，聚在一块儿，充分让每台廉价的机器发挥光和热。其中在《从谷歌 GFS 架构设计聊开去》中咱们针对 GFS 进行了管中窥豹，体会到其中一斑，不得不说是人多力量大，团结就是力量的体现。

MapReduce 做为其中一座宝驾出现，主要解决海量数据计算的头痛难题。在《悟懂MapReduce，不纠结！》中咱们引入一个接地气的“农村掰玉米”的案例进行了 MapReduce 思想的体会，大致意思是说， Map 就像人手掰一垅玉米（有个别生玉米+多数熟玉米），负责掰就行；Reduce 就像有专门收生玉米的；有专门收熟玉米的，而后各自进行汇总统计。

简单去讲，GFS 解决了分布式文件的存储，MapReduce 解决了海量数据的计算。

可是天生好奇，心生疑问“实时在线应用的海量结构化数据该如何存储呢？”那么不得不说起谷歌的第三驾马车“BigTable”。

背景？

众所周知，Google 要存储海量的网页，并且要可以存储一个 URL 的不一样时期的多个版本的网页内容（由于网页会不断的更新，因此爬虫也要不断的针对同一个 URL 进行爬取）。

上图是摘自 BigTable 的论文，老图配新曲，在此处主要用来阐述 BigTable 产生的其中一个背景，从中咱们可以得出以下公式。

com.cnn.www + contents: + t3 => html网页内容

com.cnn.www + contents: + t5 => html网页内容

com.cnn.www + contents: + t6 => html网页内容

那么 Google 就须要设计一款相似以“URL +  contents + time stamp”为 key，以“html 网页内容”为值的存储系统，因而就有了 BigTable 这个键值系统的存在。

是啥？

Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers.

官方定义。Bigtable 是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：一般是分布在数千台普通服务器上的 PB 级的数据。

说清楚 BigTable 存储啥样子？一段话（一箪食）

A Bigtable is a sparse , distributed , persistentmulti-dimensionalsorted map . The map is indexed by a row key, column key, and a timestamp ; each value in the map is an uninterpreted array of bytes.

• BigTable 是一个稀疏的、分布式的、持久化存储的多维度排序的 Map.（写过两天代码的都不陌生，Map 由 key 和 value 组成）;

• Map 的 key 是行关键字、列关键字以及时间戳组成；

• Map 的 value 都是一个未经解析的 byte 数组。

看透彻 BigTable 存储啥样子？一张图（一瓢饮）

• 能够看出 BigTable 用三维（row 行关键字、column 列关键字、time 时间戳）方式定位数据，也就是以“行关键字、列关键字、时间戳”为 key 来定位数据；

• 咱们也能够认为 BigTable 是属于 key-Value 的 NOSQL 数据库系列（为你在技术选型时再加一备选）。

一段话（一箪食）+ 一张图（一瓢饮） = BigTable（足矣）。

好了，到这应该对 BigTable 懵懵懂，若是感受蒙圈、迷茫了，建议动动手指分享转发一下（言外之意：若是没看懂，就忽略此篇分享，莫要影响心情，由于愉悦的心情真的很重要！！！）；若是感受稍微有点意思或者豁然开朗，那就继续往下追。

设计？

默默跟随“一猿小讲”脚步的应该都清楚，GFS 也好、MapReduce 也罢，参与者角色都采起了简单就是美的大道至简的思想设计，都秉承了“一人掌权，其余人办事”的理念，那咱们不妨看看 BigTable 背后是否是也是这样的设计呢？

BigTable 主要参与者：连接到客户程序中的库、一个 Master 服务器和多个 Tablet 服务器（这不就是我们以前说 GFS 的皇上~宰相模式）。

Master服务器 （皇上）主要负责如下工做：

• 为 Tablet 服务器分配 Tablets；

• 检测新加入的或者过时失效的 Tablet 服务器；

• 对 Tablet 服务器进行负载均衡；

• 对保存在 GFS 上的文件进行垃圾收集；

• 对模式的相关修改操做，例如创建表和列族。

Tablet服务器 （宰相）主要负责如下工做：

• 管理一个 Tablet 的集合（一般每一个服务器有大约数十个至上千个 Tablet）；

• 负责处理它所加载的 Tablet 的读写操做；

• 负责在 Tablets 过大时，对其进行分割。

运转？

写操做。

• Tablet 服务器首先检查这个操做格式是否正确、操做发起者是否有执行这个操做的权限；

• 若是校验经过，将写请求提交到日志 tablet log；

• 而后将数据写入内存中的 memtable；

• 当 memtable 存到必定规模会被冻结，Bigtable 随之建立一个新的 memtable，并将冻结的 memtable 写入分布式文件系统 GFS。

读操做。

• Tablet 服务器首先进行完整性和权限检查；

• 而后将一系列 SSTable 和 memtable 的存储内容组成一个

  大的视图，而后从中进行读取。

设计要点：读也好，写也罢，客户程序其实直接和 Tablet 服务器通讯进行读写操做，因此 Master 服务器的负载是很轻的。

技术栈？

BigTable 使用 Google 的分布式文件系统 GFS做为底层数据存储。

BigTable 内部存储数据的文件是 Google SSTable 格式的；（SSTable 是一个持久化的、排序的、不可更改的 Map 结构，点一首杨坤的“无所谓”送给你，该纠结时纠结，不应纠结时莫纠结，重要的是心情愉悦）。

BigTable 使用 Chubby 提供协同服务管理（若懵圈了，就想一想 ZooKeeper）。

思考？

画龙画虎难画骨！目前的一切仍是浮于表象，有没有更进一步的认识呢？那就让时间来告诉咱们吧！

好了，这篇分享都到这儿吧，但愿大家可以喜欢，若是感受有点帮助，那就动动手指转发分享一下吧。