聊起 BigTable，让你不再胆怯
【这是一猿小讲的第 66 篇原创分享】
谷歌“三驾马车”的出现，才真正把我们带入了大数据时代，并指明了大数据的发展方向。
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）。
思考？
画龙画虎难画骨！目前的一切还是浮于表象，有没有更进一步的认识呢？那就让时间来告诉我们吧！
好了，这篇分享都到这儿吧，希望你们能够喜欢，如果感觉有点帮助，那就动动手指转发分享一下吧。
推荐阅读：
从谷歌 GFS 架构设计聊开去
悟懂MapReduce，不纠结！
这部技术葵花宝典真的很硬核
苦涩的技术我该怎么学？Akka 实战