大数据驱动下的谷歌云平台运维

本文整理自 DevOpsDays2017.上海站演讲实录《大数据驱动下的谷歌云平台运维》

作者简介

刘靖

英文名: Jeff liu, 目前在 Google
做DevOps软件工程师,主要负责大数据平台的支持，以及大数据分析系统的稳定支持。在过去十年左右的时间,先后在Google几家规模不同的公司做关于运维和服务稳定性的工作。曾在 Twitter 做后端分布式系统的运维、在Splunk作为云服务创始团队的一员、在Dell负责亚洲和欧美数据中心的建设。

前言

本文将与大家分享过去一段时间我在硅谷做运维的经验和体会，希望给大家带来一些收获和启发。

一，DevOps 的发展

我们先回顾一下过去十几年来Devops的发展，以及在新的技术环境下，Devops工作面临新的变化和挑战。

大家知道2008年，Patrick在敏捷性会议上第一次提出了敏捷系统，之后敏捷系统在过去的几年里，在不同行业不同规模的企业都取得了发展。

从互联网初创公司开始，敏捷性系统帮助初创公司大大缩短了产品开发周期，能够最短时间内推出产品并为用户提供服务，而且及时地收集用户的反馈信息，并且快速有效地实现到新产品和服务当中去。

很快，敏捷性系统文化所带来高效运营得到了传统企业的亲睐，敏捷性系统和Devops文化不断深入到包括金融、运输、媒体、服装等各种类型的公司。

在这里，我们不难发现，敏捷性系统的目的就是软件即服务，重要意义在于其融合了产品的功能性和操作性，让用户得到了一个无缝链接的完整的服务体验。

不仅如此，商业客户期待一个高质的功能和操作性的同时，也希望能够在这样的高质量的平台上，不断地持续地得到服务和产品的更新，来满足更多的用户需求。

这种需求就必然要求一个完全不同的软件交付方式，功能和操作就很自然的与开发、与运维结合在一起。

Devops在软件开发各个环节所建立起来的团队之间的相互信任关系，与敏捷性系统为软件开发产品所做出的努力是一致的。敏捷性系统最大的特点是让软件开发和商业发展保持高度一致。而Devops的文化，则让运维和产品的开发保持高度的一致，并且大大的增加了开发的灵活性。

我认为需求是决定一切。Devops的发展是与企业的业务需求直接联系的。无论是传统企业，还是新兴的互联网企业，在如何更好更快的为用户提供产品服务上都在不断的努力和尝试。

企业的不断追求也为软件的开发和服务的提供，提出了新的挑战。例如在2010年美国骑士资本公司的股票系统在一次服务器软件更新的过程中，一名技术员拷贝代码时遗忘了一段程序，造成了发生45分钟的交易混乱，使得该公司损失4.4亿美元资产。

这个事故以后就让很多公司开始思考，如何在缩短产品开发周期的同时，能够有效控制服务更新造成的风险；如何在不损害现有用户利益的同时，更好的为新用户的新需求做出服务。恰好Devops和敏捷系统在这里提供了一个非常可行的解决方案。

今天我们可以看到越来越多的公司开始接受Devops文化，敏捷性系统也开始逐渐在公司内实施开来，Devops团队的价值也为很多公司的管理层认可。大环境的变化，使得Devops团队成功的可能性越来越大。

但是我们不可忽视的是面对这样一个机会的同时，Devops团队作为软件开发团队的一部分，他不可避免的受到软件开发以及新技术发展的挑战，这些挑战最基本的包括软件开发环境和技术本身发展所带来的挑战。我们只有在多样的企业环境中解决好这些问题，才能真正实现Devops的价值。

二，新的挑战，新的技术

在今天的技术环境里，有很多挑战，那么显而易见的我觉得云/平台、微服务的软件构架、大数据和机器学习是其中非常重要的一部分主导的力量，接下来，我就从这几个方面和大家探讨一下。

2.1 云/平台

云大家都很熟悉，在过去十年左右的时间，云一直是推动IT行业革新的最大动力，云本身也包括基于云的服务平台，例如亚马逊、微软云还有Google云。

最初我们认为云是一种节省成本的方式，将资本的支出转换成运营的支出，后来慢慢发现，其实云真正的价值在于可以更快、更有效的将产品和服务提供到用户面前，并且减少在此过程中产生的一切可能的浪费和消耗。

那么云服务本身包括云和基于云的服务平台，我们可以看到在过去几年里，传统基于虚拟机的云服务的方式，已经逐渐地被替代。

在过去两年，亚马逊IWC业务的增长率已经连续7个季度走低，同期微软和Google的云服务通过提供新的业务，并未出现走低的现象。这就说明用户对云服务的要求正在发生不断的变化。除了云服务以外，我觉得最大的一个技术发展就是基于微服务的软件构架。

2.2 微服务

微服务的软件构架是整体应用对比而言的，在目前软件开发领域是一个非常重要的发展方向，它不仅仅是企业内部IT部门功能性的变化，它更是一个企业内部的整体数据转型。

微服务概念源自于2014年Martin的一篇文章，尽管里面没有作出精确的定义，但是提出一些共性：微服务要围绕业务组织服务；需要支持自动化部署；对语言和数据要进行去集中化的控制等。这其中就在说明微服务的一些优点。

它的优点包括：

1，每个服务相对简单，只关注一个业务功能；微服务的构架方式非常松散，它可以提供非常高的灵活性。
2，微服务可以通过最佳和最适合的编程语言和工具进行开发，每个微服务可以由不同的团队相对独立的进行开发，使产品可以以最快的速度推到市场。
3，微服务是持续交付的最大的推动力，它可以在允许频繁不断地更新业务，更新系统部件的同时，保持系统其它部件的可用性和稳定性。

2.3 大数据和机器学习

除了云和微服务以外，那么过去几年最大的技术变化就是大数据和人工智能机器学习的发展。

人工智能的技术在过去的几年里得到了迅速的成熟。技术的成熟大大推动了人工智能包括数据挖掘、大数据处理在各个行业的应用。

企业用户等了很长的时间后终於找到了一个非常有效的处理企业大数据的技术。驱动大数据的技术，也同时是驱动企业业务增长点的技术。

从软件方面来看，随之而来的就是与大数据处理相关的微服务在应用中的比例越来越大，对于数据流处理的实时性和稳定性要求越来越高。

大数据的分析不再只是公司高管所关心的问题，他们在关心商业运行分析的同时，在各个业务部门，业务经理们也开始慢慢关注大数据分析的结果。因为越来越多的业务层都开始依赖大数据分析的结果。

这样的变化就使得对大数据的分析提出了新的要求。过去我们可以看到有的大数据的处理过程需要几天甚至几个月才能完成，在今天这样的环境里，由于业务的需求我们需要这样的数据处理流程在几个小时内或者在实时情况下进行计算并完成结果。

刚才我讲到了云\平台、微服务以及大数据和大数据的一些发展。这些技术的发展受到了直接冲击的就是云服务的提供商。云服务的提供商必须不断地推出新的服务项目来帮助企业用户完成向新技术和新的构架的转变。

三，DevOps 在 Wiki，亚马逊和Google

这里我列出不同时期Wiki、亚马逊和Google对DevOps概念的解释。从这些解释里面，我们可以看到Devops在过去十年是在一直发生变化的。

首先Wiki认为Devops是一个软件开发工程，是一个重视产品、技术还有运维相互交流、相互协作的软件开发工程。

亚马逊认为Devops是一种文化，也是一个实践，他是一个不断提高企业产品开发速度的非常有效的工具。

但是到了近几年，Google在自己的网页上对Devops做出这样的定义，Google认为Devops是所有应用开发的开始。这句话当然是在肯定Devops的重要性，但是其实我觉得他也充分说明在今天这样的新技术和新的平台下，Devops不再只是一个可以在产品后期或者是中后期才需要介入的流程，Devops对于产品的设计已经初步具有主导性的作用。

为什么这么说,我就想利用这个机会跟大家分享一下在Google云上，Google提供了哪些服务，以及他们的特性，然后具体理解一下在新的技术和平台下，Google是怎样通过这些工具和服务，能够帮助Devops完成对微服务构架，完成对大数据处理和机器学习的转型。

3.1 云／平台

这里是目前Google云平台上提供的主要服务。今年4月份在美国旧金山，Google云全球大会之后，Google云在分布式数据库、网络安全、人工智能、大数据处理上都得到大幅升级。

在大数据存储上，除了之前的Datastore和Bigtable以外，最近推出非常高效地数据查询引擎——Big Query，还推出全球分布式数据库服务——Cloud Spanner，还有基于手机应用端的Cloud  Fibase数据库系统。

这些为结构性数据，尤其是大数据，时间序列性数据，NoSQL数据提供了高效、可靠的存储方案。

在机器学习方面，可以看到Google云开放了自己的语言、视频、语音服务，同时开放了在线机器学习服务。企业用户不再需要花费大量的时间和资金去搭建自己的机器学习平台。我们都知道，机器学习平台对机器资源消耗是非常大的，而且整个开发过程也是相当长的。现在用户可以直接把数据导入Google云的服务中，立刻对自己的大数据进行分析和学习，以最快的速度将大数据技术和数据转换成公司所需要的业务增长。

那么在所有的这些Google云的服务中，越来越凸显出一些重要的特性，其一就是许多这样的服务都是针对微服务构架而提供的解决方案。比如说Pub/Sub消息订阅发布系统，这是常用的微服务之间进行信息沟通的工具。第二点也是一个非常重要的发展方向，就是无服务器模式。应用开发者已经不再需要去配置服务器的数量和环境，也不再需要花费很长的时间做网络设置和系统设置。

Google云作为云服务的提供商，充分利用自己几十年的云服务的经验，相应开发出一套完善的工具，为云服务的用户承担了底层系统维护和拓展工作。所以对于开发者来说这是非常好的事情，因为开发者现在可以直接把资源集中在实现业务代码上，从开发者的角度来说,云平台的发展变得更加简单和快捷。服务质量也得到了很大提高，产品的开发周期大大缩短。

3.2 大数据

在大数据上，在Google云的大数据产品线里面有一个非常重要的产品就是Dataflow。这是Google云提供的非常强大的数据处理引擎，就是数据流服务。

我们花点时间了解一下Dataflow这个服务。要了解这个服务，我们首先了解一下其由来和特性。2004年，Google向全世界介绍了MapReduce框架，这个框架将应用程序分解成许多并行计算指令，跨越大量的计算节点进行超大数据集的计算。

今天MapReduce成为并行分布式系统领域高度流行的基础设施和编程的模型。它也是Hadoop的基础，被很多知名厂商使用，来为客户提供高质量的数据服务。但是今年年初的Google IO大会上，Google宣布抛弃MapReduce的框架，转而使用一个新的云数据分析系统，这个系统就是Dataflow系统。

Google之所以抛弃MapReduce引入Dataflow的根本因为是分析的数据量发生了非常大的变化。换句话说，当数据量达到PB 级别后MapReduce就变得非常难以处理。那么相反由于Dataflow的构架优势并没有像MapReduce那样的扩展限制，Google云将Dataflow放在云平台上作为一种的服务提供给开发者，它比现在市场上所有的数据处理系统效率都要高和快，而且拓展性也是更强的。

3.3 Apache Beam

接下来，我介绍一下Apache Beam，这个开源项目。可能有些朋友会问,我们企业内部已经实施了一个非常大的Spark分布式处理集群，能否用Dataflow这一强大的数据处理功能来处理我们的数据呢？那答案是,可以的。

为什么说是可以的，因为我们有Apache Beam。这里简单介绍一个Apache Beam，它是一个开源项目。

2016年2月 Google将Dataflow开源给Apache基金会，更名为Apache Beam。这个项目整合了Google自己的Cloud Dataflow和目前常用的开源系统，包括Spark、Flume、Flink、Gearpump。

Apache Beam的优点是统一的编程框架，能够统一处理批量数据和流数据。做过数据开发的人都了解，在以前的技术框架下，批处理和流处理两种不同的数据要用不同的方式去处理，即便处理的逻辑非常相似，但是在Apache Beam，这一劣势就没有了。

Apache Beam第二个优点是前端开发非常灵活，可以选择Java、Python和其它的语言。用户可以根据自己的实际情况选择自己的开发语言进行开发，不需要对现有程序进行大量的重写。

后端可以看到Apache Beam同时支持Google的Dataflow，也可以支持Spark和Flink这些常用的大数据并行处理系统。用户不需要更改太多的代码，直接将数据处理程序放在不同的平台上运行，非常地方便。

回到DataFlow 服务本身，我们刚才谈到在开发数据流程的时候，前端可以使用Dataflow的SDK或者是开源的Apache Beam进行开发。在后台，我们有多种选择。

作为Dataflow  服务本身，它有一些非常显著的优点：第一个优点它是完全托管的服务，可以自动地优化、管理和拓展，所有的处理资源在程序运行时自动生成，在处理的过程中会根据数据量的大小和延时进行自动调整，在工作结束后所有的资源自动归还给Google云平台，这样处理大数据管道的机器成本得到了非常有效的控制，用户只需要花费他们所需要花费的资源，来处理他们的数据。

第二个优势就是它是动态的。表现在它可以自动检测和处理资源的不足，检测到处理资源不足的处理单元，然后自动地调整资源分配，以减少整个处理进程所需要的时间。

3.4 案例分享

简单跟大家分享一个具体的例子，这里是Dataflow具体的程序代码，这里有10行的代码，实现了从一个实时的数据流，读入数据进行分析处理,然后统计,最后输出到数据仓库当中，这里我选择了Google云的Pub/sub服务，你也可以换成常用的 kafka等系统。

当你写完这段代码以后只需要运行这样一段代码，Dataflow的客户端SDK，就会把生成代码的bin文件，以及运行这段代码所需要的参数信息自动提交到Google云的平台上，短短几分钟就可以看到数据处理的程序状态以及它的处理结果。

从运维的角度来看，对于这样的数据程序，我们应该怎样进行流量控制、监测和报警这些与运维息息相关的工作呢？

我们的解决方案是，在这里我选择了一个实时监测系统，是Google云自己提供的Stackdriver，这是在线的实时监测和报警的服务，它可以同时采集多种用户指标，然后输出到后台的服务器端，在后台的服务器端建立自己的dashboard、报警等系统来监测你的系统。

如果想要检测这段代码，我们只要简单地将服务的SDK，客户端的程序嵌入代码中去，这样当数据处理管道在运行时，就可以实时收集到关于数据处理管道本身的状态信息，然后在后端，我们的运维团队就可以实时监测处理管道的实时情况。

除了监测、报警以外我们还有容量管理，还有安全各方面的与运维息息相关的工作，我们都可以以同样的方式将代码加入其中。

四，运维是对整个应用生态环境统一的监控

我想说的是到最后，一个微服务的框架中，我们看到的是什么？

越来越多的运维服务他们本身已经作为一种服务，提供给了其他的微服务，具体到技术上，运维本身通过一套统一的SDK，在前端嵌入其他的微服务，在后端通过一整套的服务，来进行监测,日志管理、流量分配、流量控制，报警、容量检测、自动调整，来达到对整个应用生态环境统一的监控。

所以我想说的就是我们看到软件的交互方式在过去几年发生了很大的变化，无论是应用软件、基础构架还是业务流程以及包括运维这些服务都汇集到了一起，以一切皆服务的方式提供给所有业务部门。

这种服务化的模式为企业带来了一系列可使用、可拓展、可消费的服务，他们依托数据分析、云计算、自动化等技术 ,切实产生了很多的业务成果，运维级服务是在平台级服务还有基础构架服务上发展起来的一个新型服务，在微服务越来越普及的情况下，运维作为一种服务提供给业务部门，这将成为能够管理非常复杂的微服务应用生态环境的一个非常有效的方式。

这是一幅漫画，对于做运维工作的人都不陌生，运维是非常辛苦的工作，难度也非常高。我想跟大家分享的是美国前总统J.F.K在阿波罗登月计划前在赖斯大学演讲中提到的：

   We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.  ——- J.F.K, September 12, 1962

“我们决定在这十年间登上月球并实现更多梦想，并非它们轻而易举，而是它们困难重重。因为这个目标将促进我们实现最佳的组织并测出我们最佳的能力，因为这个挑战我们乐于接受，因为这个挑战我们不愿推迟，因为这个挑战我们志在必得，其他的挑战也是如此。”

END

更多相关文章阅读

第八届全球运维大会

即 GOPS2017·上海站将于2017年11月17日-18日在上海举行

各种精彩等您发掘。

独乐乐不如众乐乐，DevOps 时代社区长期欢迎原创作者投稿，DevOps 时代社区愿陪伴您共同成长。投稿邮箱：[e-mail]

点击阅读原文关注GOPS2017.上海站活动官网