聊起 BigTable，让你不再胆怯

Posted 2020-11-27 socoool

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

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

思考？

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

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