聊起 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）。

思考？

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

好了，这篇分享都到这儿吧，希望你们能够喜欢，如果感觉有点帮助，那就动动手指转发分享一下吧。