谷歌的大数据之路，上半场以“三驾马车”（谷歌文件系统、MapReduce 和 BigTable）开始，却以被 Hadoop 开源生态系统全面山寨了自己的“三驾马车”而结束。

此后，开源社区不断推陈出新，推出了连谷歌都没有的开源项目，并将其融入了 Hadoop 生态系统。从此，Hadoop 生态系统成为了大数据领域事实上的标准，而谷歌也不得不在自己的云计算平台上提供对 Hadoop 开源山寨项目的兼容性支持。

最终，在大数据的上半场，随着 Hadoop 生态圈的崛起，谷歌在大数据领域的影响力荡然无存。

然而，谷歌也不是吃素的。在大数据的下半场，谷歌携带“黑科技”Spanner 数据库系统闪亮登场了。 在讲这个“黑科技”前，我们先来看看谷歌“三驾马车”里的 BigTable。虽然 BigTable 名字里面包含了“Table”，但实际上它并不是一个数据库的表，它只是一个键值存储系统（即 Key-Value Store）。

一方面，BigTable 虽然可以处理大规模高并发的查询，但是这个查询功能并不好用。在 BigTable 中用户无法使用 SQL 进行数据查询，而必须采用编程的方式，这就导致数据查询的用户体验非常不好。因此，应用程序开发者更愿意选择用他们熟悉的数据库系统，通过 SQL 完成数据访问和查询。

另外一方面，虽然谷歌的搜索系统构建在“三驾马车”上，但广告引擎并不是。在很长一段时间里，谷歌的广告引擎都是采用开源的关系数据库 MySQL。但是随着谷歌业务的发展，MySQL 越来越无法支撑谷歌广告业务的发展。

基于以上两方面的诉求，谷歌需要再开发一个数据库系统，这个系统既要有 BigTable 处理大规模高并发查询的能力，又要能够支持 SQL 查询和事务处理。这个系统就是今天的主角，后来赫赫有名的“黑科技”Spanner：谷歌的跨洲多数据中心的数据库。

那么，Spanner 到底是什么呢？

  • 首先，它是一个数据库，支持 SQL 查询，类似于 Oracle 或者微软的 SQL Server，以及开源的 MySQL、Postgres 等。
  • 其次，Spanner 跟其他数据库系统最大的不同是，它支持把数据存储在谷歌全球各地的不同的数据中心里，并且对这些数据进行查询。同时，它还能够保证这些跨洲多数据中心数据的一致性。

目前这个系统，全球只此一家别无分号。有传闻说，亚马逊屡次试图实现 Spanner 这样的系统，但是屡战屡败，屡败屡战，现在依旧没有什么进展。

众所周知，时间问题是分布式系统里面最难解决的问题。 每台机器上细小的时间差别，反应到全局的结果就是没有统一的时间观念。

在同一个数据中心，通过时间同步协议定期对所有机器进行时间同步，这个时间问题就可以迎刃而解了。但是，一旦数据中心跨洲后，通过同步协议进行定期更新的做法就不切实际了。因为，利用同步协议更新跨洲数据中心的时间所要耗费的时间本身，就已经可以产生了不可忽略的误差。而 Spanner 被称为“黑科技”的原因之一就是，它开创性地采用了原子钟和 GPS 全球定位系统，从而解决了这个跨洲的全球数据中心的时间同步问题。

在最开始，谷歌只做了 Spanner 的存储层实现，虽然解决了全球数据中心的时间同步问题，但是并不能满足谷歌广告引擎业务的需要。主要原因是，在 Spanner 中存储层的访问需要使用底层的 API，而广告系统是通过 SQL 访问 MySQL 集群的，这是一种高层的数据访问查询方式。而这时，谷歌将广告系统从 MySQL 集群迁移出来的需求也不断增长，于是就专门组建了一个技术团队，这个团队的任务就是基于 Spanner 的存储层开发一个新的数据库系统 F1。

最终，F1 研发成功了。F1 的成功主要体现在两个方面。

  • 首先，F1 是一个完整的数据库，可以兼容 MySQL，广告部门基本上不需要改代码就可以通过 SQL 访问 F1 数据库。
  • 其次，F1 的扩展性非常好，可以进行任意的扩展，包括跨地域的扩展，因此广告部门再也不需要因为流量的增加而手动扩展 MySQL 集群了。

因此，谷歌终于有了属于自己的跨地域的全球性数据库。这个数据库提供了极大的便利性，从此谷歌的广告业务终于可以脱离 MySQL 了，谷歌也因此获得了许多新的收入。

然而，虽然 F1 系统解决了谷歌广告业务受制于 MySQL 的问题，但是这个系统有一个最大的问题：它完全是为谷歌的广告业务定制的，也因此无法应用在谷歌的其他项目上。

比如，F1 数据库把表按照广告客户 ID 进行分区，数据在这些静态分区之间没法进行迁移。其他的项目都有自己的数据库表方式，而改造成 F1 数据库表方式是一个非常巨大的工作量，这也就导致了非广告业务无法实施在 F1 数据库系统上。

这时，谷歌内部对构建一个通用的数据库系统的诉求愈发强烈。一方面，F1 数据库和广告业务紧紧耦合，且 F1 的团队也没时间做解耦来消除这种局限性；另一方面，Spanner 团队发现他们需要在存储层上开发一些新的东西。

在这样的背景下，Spanner 团队开始自己做执行层的开发。这样一来，Spanner 被开发地越来越像是一个完备的数据库。经过几年的演变以后，Spanner 最终成为了一个完备的数据库。

这样，谷歌内部就有了两套基于 Spanner 存储层的数据库了：Spanner 团队自己开发的和广告组开发的 F1 数据库。 这两套系统在谷歌内部开展了广泛的竞争，最终的结果就是：非广告业务都采用 Spanner 组开发的系统，而广告业务部则用 F1。而在外界，很多人被谷歌这两套系统搞蒙了，大家一直误会 F1 和 Spanner 是同一个产品，但事实上它们是功能和适用范围都不同的两个系统。

  • F1 开发得比较早，是针对广告部门定制的数据库系统。这个系统在广告相关业务上性能非常好，但缺失了很多支撑其他业务必要的功能，所以通用性很差。
  • Spanner 团队则开发了一个通用的数据库系统，具备了数据库系统的所有功能。但是这个系统没有专门针对广告业务进行优化，因此应用在广告系统上的性能要差一些。

虽然有这些小插曲，但是自从有了 Spanner，谷歌的底气就不一样了。这个黑科技支持的数据库，使谷歌第一次做到了进行全球范围的事务处理，这确实是史无前例的。鉴于开放“三驾马车”架构时的保守性，让谷歌丧失了在大数据时代的先发优势，这次谷歌决定把 Spanner 放到云上供大家使用，并将其命名为 Cloud Spanner。

谷歌试图通过 Cloud Spanner 这个高大上的“黑科技”来推动云端大数据产品的销售，但是却没有达到预期效果。在我看来，Cloud Spanner 发展不顺利的原因主要有两个：

  1. Spanner 收费非常昂贵，对用户来说不够经济实惠；
  2. 大部分用户都没有谷歌那么大的数据量，跨大洲、跨大洋的数据库功能对他们来说，多少有点华而不实。

虽然 Spanner 在云端客户上发展并不顺利，但是有些情况也只有 Spanner 这样的数据库才可以从容应对。比如，中国的金融行业需要两地三中心的架构，这种架构目前主要通过高端机器实现。即便如此，金融机构也无法避免真正可能发生的灾难。但是，如果换成 Spanner，金融机构不但能够更好地自动应对故障的发生，而且可以降低成本。

无论结果怎样，Spanner 让谷歌再次在大数据领域吸引了很多关注。谷歌通过无与伦比的技术实力告诉大家，它才是大数据技术真正的推动者。但是 Spanner 这个“黑科技”也只对谷歌这种规模的数据有现实意义，而对其他企业来说并不是刚需。所以，Spanner 终究还是落得了“叫好不叫座”的结局。