从Google F1 看HTAP数据库的诞生（三）

天云数据

于 2020-03-25 10:58:24 发布

阅读量576

点赞数

文章标签：数据库

原文链接：https://mp.weixin.qq.com/s/8CTxVYz7B586SJkbZwaXEQ

版权

转载自微信公众号：BeagleData_

作者：张秋剑

近年来，互联网数据存储的信息量增长了成千上万倍，数据的环境千变万化，数据量爆炸式增长，用户的需求个性化，交互的增加和实时性，导致了传统的数据库，和传统的数据处理方案已经越来越难满足对数据的处理要求了。传统的数据库系统侧重在数据的一致性和可用性，性能、可扩展性相对来说都比较差，无法满足可扩展性和实时性的要求。

于是我们在上一篇中提到的TA融合，TA分离和TA融合两个时代，我们总结如下：

T/AP分离时代	T/AP融合时代
应用场景明确	一份数据
多份数据	面向多种场景
系统相互独立	系统统一

要实现以上要求，也就是我们既要一个具备ACID特性的关系型数据库，又要实现可扩展性、同步复制、多版本、外部一致性等。这对数据库界来说一直是困扰多年的争议话题。HTAP要在这两者之间兼顾，图谱CAP这个不可能突破，那么它需要一个强有力的理论基础作为后盾。那么这个理论基础来自哪里呢？我们来一起看看Google的F1/Spanner的发展。

Google F1 / Spanner

我们知道在Hadoop大行其道的大数据时代，其奠基者是Google的BigTable、GFS、MapReduce——传说中的谷歌分布式三驾马车。虽然谷歌没有公开具体实现代码，但却公布了相应论文，对分布式文件系统、大数据挖掘和NoSQL流行起了重大促进作用，开源界相对应产品是Hbase、HDFS、Hadoop MR。距谷歌这三篇论文发表已近10年，谷歌内部这三驾马车也在更新换代：

BigTable > F1/Spanner

GFS > Colossus

MapReduce > Percolator/Dremel

Colossus是GFS的第2代技术，也就是Colossus File System——CFS；MapReduce没有被替代，只是多了Percolator和Dremel这样的提供批处理和实时处理的额外补充方案。因为这两者不是本文的重点，所以对分布式文件系统Colossus和数据挖掘框架MapReduce等本文都不做讨论。我们重点看一下F1/Spanner。

我们知道，和众多互联网公司一样，在早期Google大量使用了Mysql。Mysql存在两大短板：

首先，Mysql是单机的，可以用Master-Slave来容错，分区来扩展。但是需要大量的手工运维工作，有很多的限制。因此Google开发了一个可容错可扩展的RDBMS——F1。和一般的分布式数据库不同，F1 对应RDMS应有的功能，ACID严格要求，丝毫不差。

其次，MySQL的扩展性一直被诟病，尤其是在Google这样的全球性的互联网科技巨头，FLAG四大巨头之一，对数据库的可扩展性、多版本、全球分布式、同步复制要求甚高。于是，Spanner在Google内部诞生，Spanner是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。

我们拿Google的AdWords这一Google的核心生产业务来举例子，看看F1/Spanner是如何取代MySQL，实现Google的分布式关系型数据库的。

Google的AdWords业务以前使用MySQL+手工Sharding来支撑，在扩展和可靠性上不能满足要求,而通过Spanner不仅在同步复制、外部一致性等方面做的很好,甚至达到了令人咋舌的全球级，可以扩展到数百万的机器，数以百计的数据中心，上万亿的行。除了夸张的扩展性之外，他还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。这一点是怎么做到的呢？AdWords团队在Spanner上层开发了混合型数据库F1(F1意味着:Filial 1 hybrid,混合着关系数据的丰富特性和NoSQL的扩展性),并于2012年在生产环境下替代MySQL支撑着AdWords业务(注意：F1和Spanner之间关系并不是MariaDB基于MySQL再开发的关系,而是类似InnoDB存储引擎和MySQL Server层的关系--F1本身不存储数据,数据都放在Spanner上)。

AdWords业务的用户经常需要使用复杂的query和join操作，这就需要设计shard规则时格外注意，尽量将相关数据shard到同一台MySQL上。扩容时对数据reshard时也需要尽量保证这一点，AdWords业务扩容比较艰难。在可用性方面老的系统做的也不够，尤其是整个数据中心挂掉的情况，部分服务将不可用或者丢数据。对于Google的系统来说，短暂的宕机服务不可用将带来重大的损失。为了解决扩容&高可用的问题，通过Google的F1这款基于Spanner的跨数据中心的分布式关系型数据库，支持ACID，支持全局索引，完成了完整关系型数据库所有功能和同样优越性能的表现。

这里我们就不再详细展开F1/Spanner的技术细节，有兴趣的读者可以延伸阅读Google的两篇Paper：

01 F1: A Distributed SQL Database That Scales

原文链接：http://static.googleusercontent.com/media/research.google.com/en/pubs/archive/41344.pdf

02 Spanner: Google’s Globally-Distributed Database

原文链接：http://static.googleusercontent.com/media/research.google.com/en/archive/spanner-osdi2012.pdf

我们接着来看，自2012年F1上线以来，F1还在进行着高速迭代，尤其在早已为Google的AdWords为代表的核心业务服务的基础上，在OLTP的能力之外，又进一步扩展了OLAP的能力。2018年，是非常重要的一年，Google发表了新论文：《F1 Query: Declarative Querying at Scale》。论文详细阐述了 Google 对于企业数据处理领域三大类需求的解决办法。这篇文章奠定了F1在处理ETL跑批处理，以及OLAP方面的理论创新。将自身在分析方面的短板实现了彻底补强。

从 F1 到F1 Query

Google F1团队在VLDB2018发表的《F1 Query: Declarative Querying at Scale》论文来详细阐述了一个叫做 F1 Query 的大数据处理系统的设计。F1 Query 是Google内部进行异构查询的引擎，它支持对各种不同的文件格式、各种不同的存储系统( Bigtable, Spanner, Google Spreadsheets ) 的数据进行联合查询。

这听起来就是实现了一款OLAP的分布式的 SQL 执行引擎，现在大数据领域流行的 Presto、Spark SQL、Hive 等等，都可以算在这个范畴里。类似地，F1 Query 也支持对各种不同数据源的查询，既可以是传统的关系表、也可以是 Parquet 这样的半结构化数据。这样一来，不同数据格式的壁垒也被打破了：你可以在一个系统里完成对不同数据源的 Join，无论数据以什么形式存放在哪里。商业上管这个叫 Federated Query 或者 DataLake。

不过，随着我们看得更深入一点就会发现，这篇论文的着重点完全不在于对多数据源的支持，它甚至完全没有描述是怎么做到支持多种不同异构数据源。F1 Query 的目标是：覆盖企业级大数据处理和分析领域所有数据处理需求。这里的“所有”惹人注目，因为常年被CAP所困的我们一向认为没有什么东西是完美的，那么 F1 Query凭什么说自己实现了“所有”呢？这里说的“所有”在企业级数据处理领域的主要指的三大类需求：

01 支持对小规模的 OLTP 式的数据进行高效查询。

02 支持低延迟地对大批量的(异构)数据进行快速即席查询。

03 支持对超大规模数据进行可靠的 ETL 处理。

可以看出一般的OLAP引擎只涵盖其中的第2项，第1项和第3项都是分析引擎所没有的。