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

思考?

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

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

 

posted on 2020-04-04 09:04  一猿小讲  阅读(471)  评论(0编辑  收藏  举报