097 | 谷歌的大数据路:谷歌的“黑科技”

097 | 谷歌的大数据路:谷歌的“黑科技”

朗读人:秭明    08′31′′ | 4.53M

谷歌的大数据之路,上半场以“三驾马车”(谷歌文件系统、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 终究还是落得了“叫好不叫座”的结局。

版权归极客邦科技所有,未经许可不得转载

通过留言可与作者互动