从VLDB论文看谷歌广告部门的F1数据库的虚虚实实

最近因为工作需要对VLDB的一些论文进行了阅读。其中包括谷歌新发表的F1数据库的分析。解读谷歌论文一直都是不太容易的。因为谷歌向来都是说一半藏一半。这篇论文相对来说还是写的比较开放的，还是不能免俗。

这篇论文是谷歌2013年VLDB发表的F1：A Distributed SQL Database that Scales的后续，全面阐述了谷歌的F1数据库这些年来发展的情况。本文详细讨论一下这篇论文。

F1和竞争对手的背景知识

我们先回顾一下F1的历史。F1是一个支持多数据源的数据查询系统。它最初诞生于谷歌的广告部门。其一开始的主要目的是为了取代当时广告系统的mySQL集群。F1从一开始就定位成一个查询引擎，实行严格的计算存储分离原则。底下对接的存储系统则是当时并行开发的BigTable下一代产品Spanner。

之后2014年VLDB谷歌发表了Mesa—一个全球跨多数据中心的数据仓库系统。Mesa成为F1主要对接的第二个系统。F1发展到今天，已经成为了一个可以支持多个数据源，从CSV文件到BigTable到Spanner等的数据联邦查询(federated query)的系统。

经过了这么多年的发展之后，谷歌内部也形成了很多套数据处理系统。这些数据库系统本身有很强的竞争关系。换句话来说，我能从你这里抢过来一个客户，我的队伍就会更庞大。F1作为一个在谷歌内部不断发展壮大的系统，也是这种竞争关系中的胜出者。

了解这些数据库的历史和服务对象，对我们更深刻的理解F1系统的业务支持和技术选型，有很重要的作用。所以下面我对和理解F1这篇论文相关的一些谷歌其他数据库系统做一个介绍。

F1最初的定位是为谷歌的Ads部门取代mySQL集群而开发的。Spanner作为F1的底层系统，是一个支持事务处理(使用2 phase locking实现)的存储层，F1作为计算引擎存在。

但是Spanner队伍本身在开发完存储层以后，自己也开始作数据查询，开发了一个内部叫做Spandex的查询系统。Spanner怎么样演变成为一个完整的SQL系统论文发表于SIGMOD 2017。这导致了F1和Spanner之间有了竞争关系。时至今日，这两个队伍在谷歌内部的竞争关系依旧激烈。

Dremel是谷歌内部的一个数据仓库系统。谷歌对外商用化了Dremel，取名叫BigQuery。Dremel采用了半结构化的数据模型，存储格式是列式存储，其第一代格式是ColumnIO。

对外商用化以后引入了第二代格式Capactior。这两种格式都是F1支持的外部数据源。Dremel在谷歌内部异常的成功。迄今为止，BigQuery依然是谷歌云上最为成功的大数据产品。

Flume是谷歌内部MapReduce框架的升级产品。最初只在Java上开发，所以最初叫做FlumeJava，后来也有C++的版本。Flume改变了MapReduce框架里面写Map和Reduce的开发模式，引入了更多高层的API，它的开发模式比较像Spark。

在底层的执行环境下，Flume也改变了MapReduce的死板模式，可以支持Map-Reduce-Reduce这样的模式。它的好处是可以很灵活的写出各种各样的数据处理pipeline，坏处是简单的事情也要写很多的code，不像SQL那么简单。

F1的业务定位

F1系统支持三种不同的数据查询方式：

1. 只影响几条记录的OLTP 类型的查询

2. 低延迟的涉及到大量数据的OLAP查询

3. 大规模的ETL Pileline

F1的论文并没有给出对这三种不同的数据查询方式的分析。我结合2013年的F1论文和其他背景知识来给大家分析一下F1支持者三种不同数据查询方式的原因。

OLTP类型的查询起源于F1的最初目标：在广告业务中取代mySQL集群。根据2013年的F1论文，其OLTP的支持是有局限性的。在F1系统里的一个OLTP查询是读若干操作跟着0到1个写操作。F1系统的OLTP的事务处理能力，依赖于Spanner底层对事物处理的支持。

在2018年的论文里，作者没有对OLTP类型的查询进行详细的介绍。但是按照常理分析，一个无状态的查询引擎如果需要支持事务处理，离不开底层存储对事物的支持。所以F1引擎显然无法做到对任何它连接的数据源都可以实现事务处理。鉴于Spanner自己也实现了数据查询引擎，并且也有对事物处理的支持。在这方面F1和Spanner有明确的竞争关系。

低延迟并且涉及到大量数据的OLAP查询，其定位很类似于BigQuery。其实现上也颇有BigQuery实现的方式，主要通过pipeline的方式来查询并返回数据结果。

从本文Related work介绍自己和谷歌内部其他竞争对手的分析看，早年谷歌的一个叫做Tenzing的系统关停以后，业务被迁移到了Bigquery或者F1。我们可以理解在这一类查询上BigQuery和F1是竞争对手关系。从实际表现来看，BigQuery更成功。