Google F1

在 Spanner 项目开始的同时,Google 启动了另外一个和 Spanner 配套使用的分布式 SQL 引擎的项目 F1,底层有那么一个强一致高性能的 Spanner,那么就可以在上层尝试将 OLTP 和部分的 OLAP 打通。F1 其实论文题目说是一个数据库,但是它并不存储数据,数据都在 Spanner 上,它只是一个分布式查询引擎,底层依赖 Spanner 提供的事务接口,将用户的 SQL 请求翻译成分布式执行计划。

Google F1 提供了一种可能性,这是在其他的数据库中一直没有实现过的:OLTP 与 OLAP 融合的可能性。因为 Google F1 设计目标是给 Google 的广告系统使用,广告投放系统这类系统一是对于一致性要求很高,压力也很大,是典型的 OLTP 场景;第二是可能会有很多复杂的广告投放效果评估的查询,而且这类的查询越是实时越好,这又有点实时 OLAP 的意思。

传统的做法是 OLTP 的数据库将数据每隔一段时间同步一份到数据仓库中,在数据仓库中离线的进行计算,稍微好点的使用一些流式计算框架进行实时计算。第一种使用数据仓库的方案,实时性是比较差的,倒腾数据是很麻烦的事情;至于使用流式计算框架的方案,一是灵活性不好,很多查询逻辑需要提前写好,没法做很多 Ad-hoc 的事情,另外因为两边是异构的存储,导致 ETL 也是很麻烦的工作。

F1 其实依靠 Spanner 的 ACID 事务和 MVCC 的特性实现了 100% 的 OLTP,并且自身作为一个分布式 SQL 引擎,可以利用集群的计算资源实现分布式的 OLAP 查询。这带来的好处就是并不需要额外在设置一个数据仓库进行数据分析,而是直接在同一个数据库里实时分析,另外由于 Spanner 的 MVCC 和多副本带来的 Lock-free snapshot read 的特性,这类 OLAP 查询并不会影响正常 OLTP 的操作。

对于 OLTP 来说,瓶颈经常出现在 IO 上。对于 OLAP 来说,瓶颈反而经常出现在 CPU 也就是计算上。其实看上去是能融合起来,提升整个集群的资源利用率,这也是我看好 Google F1 + Spanner 这个组合的原因,未来的数据库可能会融合数据仓库,提供更完整且更实时的体验。

(其实这个下面的 GFS 不太准确,现在应该是 Colossus)