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