Google：BigTable究竟要解决什么问题？（第90讲，收藏）

《架构师之路：架构设计中的100个知识点》

90.Google BigTable

前几篇聊了Google三驾马车中的：

《GFS经典架构设计（第84讲）》

《MapReduce经典架构设计（第85讲）》

很多朋友让我聊聊第三部分，Google BigTable。

BigTable，很多人对它耳熟能详，但其工程架构并没有什么巨大的创新，今天和大家聊聊，Google为什么要发明BigTable，它究竟要解决什么问题呢？

什么是BigTable？

Google BigTable是一个分布式，结构化数据的存储系统，它用来存储海量数据。该系统用来满足“大数据量、高吞吐量、快速响应”等不同应用场景下的存储需求。

画外音：本质上，BigTable是一个存储系统。

有BigTable之前，Google面临什么问题？

Google并不是一群人坐在办公室开会，想出来的系统，Google面临着很实际的业务问题。

画外音：有些公司的基础架构部，是坐在办公室开会，想出来的东西，然后强推业务线使用。

典型场景一：网页存储

Google每天要抓取很多网页：

1. 新出现的网页，新URL；

2. 旧网页，旧URL；

对一个已抓取的网页，旧URL为啥要反复抓取？

因为，网页会更新，例如新浪首页：

sina.com.cn/index.html

URL虽然没有变，但依然会抓取。

画外音：我去，相当于，被抓取的URL集合，只会无限增大，趋近无穷。

这里，对于存储系统的需求，是要存储：不同URL，不同时间Time，的内容Content。

画外音：URL+”Content”+Time => Binary。

网页的实际内容Binary，是Spider抓取出来的。

典型场景二：Google Analytics

Google Analytics要给站长展示其网站的流量PV，独立用户数UV，典型访问路径等，以帮助站长了解站点情况，优化站点。

这里，对于存储系统的需求，是要存储，不同URL，不同时间Time，的PV和UV。

画外音：

URL+”PV”+Time => $count

URL+”UV”+Time => $count

PV和UV的值，是MapReduce离线任务计算出来的。

不管是“网页存储”还是“站点统计”存储，它们都有几个共同的特点：

1. 数据量极大，TB，PB级别；

2. 和时间维度相关；

3. 同一个主键，属性与值有映射；

画外音：

主键是URL，属性是“Content”，值是网页Binary；

主键是URL，属性是“PV”和“UV”，值是计数count。

这是Google曾经遇到的难题，面对这些难题，典型的解决方案又有哪些呢？

画外音：不是一上来就搞新方案，最先肯定是想用现有的技术要如何解决。

最容易想到的主键，属性，值的存储系统是什么？

没错，就是关系型数据库：

图片

如上图所示，用户表

User(uid PK, name, gender, age, sex)

就是一个典型的主键，属性，值的存储模型：

1. 主键，不同用户的uid；

2. 属性，schema的列名；

3. 值，不同主键的各个列名，对应的值；

使用excel来举例是很直观的，这是一个二维table。

画外音：屎黄色的主键是一个维度，橙色的属性是一个维度。

用二维table能不能解决Google网页存储的问题呢？

图片

如上图所示，如果没有时间维度Time，似乎是可以的：

1. 主键，使用URL；

2. 属性，schema的列名，例如content，author等；

3. 值，不同URL的内容与作者等值；

但是，一旦加入时间维度Time，二维table似乎就不灵了。

画外音：

增加一个time属性是没有用的；

增加一个time属性，只能记录同一个URL，某一个time的content，不能记录多个time的多个content；

增加一个time属性，联合主键，URL就不是KEY了；

能不能用二维table存储三维数据呢？

似乎可以通过trick的手段，在key上做文章，用key+time来拼接新key来实现。

图片

如上图所示，仍然是二维table，通过URL+Time来瓶装key，也能够实现，存储同一个URL，在不同Time，的不同content、author。

但是，这种trick方案存在的问题是：

1. 没法实现URL查询

画外音：key上无法进行%like%查询。

2. 大量空洞，浪费存储空间

这并不是一个好的方案。

况且，当数据量达到TB、PB级别时，传统单机关系型数据库，根本无法满足Google的业务需求。

BigTable解决什么问题？

传统二维small table，无法解决Google面临的存储问题，于是Google搞了一个big table来解决。

Google对这些业务模型进行分析，在二维table的基础上扩充，抽象了一个新的“三维table”：

1. 主键，使用URL；

2. 属性，schema的列名，例如content，author等；

3. 时间，timestamp；

4. 值，不同URL的内容与作者等值；

图片

如上图所示：

1. 第一维：key（屎黄色）；

2. 第二维：属性（橙色）；

3. 第三维：time（蓝色）；

同一个key，不同属性，不同时间，会存储一个value。

不像以行为单位进行存储的传统关系型数据库，这个三维的大表格BigTable是一个稀疏列存储系统。

画外音：能够压缩空间。

它的数据模型的本质是一个map：

key + column + time => value

的一个超级大map。

画外音：

很多业务符合这一个模型；

Google的东西能解决业务问题，所以用的人多，这一点很重要。

总结

BigTable是一个稀疏的、分布式的、持久化的、多维度排序的、大数据量存储系统，它能够解决符合上述map数据模型业务的存储问题。

画外音：

GFS是文件系统；

MapReduce是计算模型；

BigTable是存储系统。

有了这三套技术底座，再加上后来的分布式锁服务，Google率先实现技术的突破，业务也直接起飞了。

知其然，知其所以然。

思路比结论更重要。

==全文完==