阿里吴永明：高可用大数据计算服务如何持续发布和演进！

【IT168 专稿】本文根据吴永明老师在2018年5月10日【第九届中国数据库技术大会】现场演讲内容整理而成。

讲师简介： 

吴永明，阿里巴巴高级技术专家。阿里巴巴通用大数据计算平台MaxCompute（原ODPS） 框架架构负责人。主要专注于大数据技术领域，对高可用分布式系统设计开发有多年经验。先后研发过阿里巴巴机器学习平台在线预测系统和通用大数据计算平台框架系统。

摘要：

服务化是大数据计算平台的发展趋势，其有效地降低了用户使用大数据的门槛和成本。但服务化一方面要求大数据计算平台要7x24小时高可靠、高可用、不间断地服务用户；另一方面随着大数据计算平台业务的增长，对于计算平台会不停地有新的需求，要计算平台跟着发展，从而能够去匹配业务的成长，这就要求服务持续迭代发布和演进提供更丰富的功能、更好的性能等。新的发布和演进对于服务来说是影响到稳定性、高可用的关键风险点，因此对于海量大数据服务来说如何处理和平衡好两者至关重要，也是业内公认的挑战难题。

分享大纲：

1、阿里巴巴大数据计算服务背景介绍

2、大数据计算服务演进面临的挑战

3、阿里巴巴的应对措施和解决方案

正文：

1、阿里巴巴大数据计算服务背景介绍

阿里巴巴的大数据计算服务平台叫MaxCompute，原名ODPS。通俗来讲，这就相当于阿里巴巴内部的Spark或者Hadoop平台。但是，MaxCompute与其他平台有一些不同之处。首先，MaxCompute完全是阿里巴巴内部团队自研的，从分布式存储系统、分布式调度系统到分布式协调服务，包括其上的各类计算框架全都是阿里自研的；其二，这是一个完全托管的PB/EB级数据仓库服务；其三，MaxCompute目前支持的机器规模可达到几万台，支撑了阿里内部90%以上的计算以及95%以上的存储，具备万台服务器扩展能力和跨地域容灾能力，是阿里巴巴内部旗舰级大数据计算平台，支撑每日百万级作业规模。当然，MaxCompute不仅服务于阿里内部，同样也对外开放，可有效降低企业成本并保障数据安全。

在技术层面，MaxCompute的架构与众多大数据体系架构图类似（如下图所示），最底层是分布式存储系统—盘古，功能类似于HDFS；其上是分布式调度系统—伏羲，功能类似于Yarn。 

 

基于这两大基础系统，我们在上面搭建了MaxCompute引擎，我们的整体定位是一个通用的大数据计算平台，所以支持典型的批处理、图计算、流计算、机器学习等场景。再往上，我们会向用户提供一些MaxCompute语言，说白了就是常用的SQL。此外，我们还会提供Spark API、Beam API、Hive API等常用API。在这个庞大、复杂的系统中，最关键的核心计算应用是什么呢？ 

 

如上图，整个架构中最关键、最核心的还是SQL应用，毕竟这是目前企业内部最通用的应用模式，其开发门槛并不像MapReduce之类的那么高，这也是SQL应用在MaxCompute上占了80%到90%的原因之一。上图主要显示了SQL应用在MaxCompute上的执行原理，MaxCompute SQL Script在FrontEnd接收之后经Compiler、Optimizer然后生成一个Runtime执行器，基本是这三大流程。

2、大数据计算服务演进过程面临的挑战

接下来，我主要介绍大数据计算服务相关配置信息以及我们在这个过程中遇到的一些挑战。目前，企业做大数据计算服务主要有两大套路，一是根据大数据的发行版本或者开源代码进行修改，当然可能还需要自己搭建和维护集群。二是直接选择成熟商用并开放的解决方案，这就将自己搭建和维护集群的成本进行了转移。随着时代的发展，第二种方式越来越受欢迎，企业对于服务化的接纳程度逐渐升高。

MaxComputer最初的定位就不仅仅是一个简单的系统，而是要做服务并开放给用户使用，因此提供365（天）X24（小时）的高可靠、高可用共享大数据计算服务是必要的。此外，我们需要自主把控服务内部引擎以及各种关键技术，在满足客户各种需求的情况下进一步降低成本，提高效率。

在持续改进和发布过程中，我们总结了遇到的挑战并给出了应对方案。我们所面临的主要挑战如下：一是每天都有百万级的作业，整个升级过程必须保证足够平稳安全，用户应该是无感知的；其次，我们需要保证新版本的稳定性；然后，性能层面不能出现回退；最后，出现问题时，我们需要快速止损。二是处理测试和数据安全之间的矛盾，数据安全对企业而言至关重要，在平时的计算服务中，数据安全性不会受到很大影响，最容易出现问题的往往是测试环节。

3、阿里巴巴的应对措施和解决方案 

针对上述两大类问题，我们提出了相应的解决方案，主要开发了三大工具：一是MaxCompute Playback；二是MaxCompute Flighting；三是MaxCompute灰度上线。

3.1 MaxCompute Playback工作原理介绍

首先是Playback工具，该工具主要用来检测编译器和优化器是否存在问题。在系统不断向前演进的同时，编译器、优化器以及Runtime均属于核心功能，所以我们需要重点检测。如果我们需要添加新功能，通常做法是写一条简单的SQL语句进行检测，验证最终结果是否符合预期来判断新功能是否存在问题，但这种方式可覆盖的测试范围非常有限，无法覆盖客户所有可能的使用情况。在我们的系统中，每天会有几百万个job且每天都在变化，人工分析的话每个script需要两分钟，时间上根本不允许，因此我们需要利用大数据计算平台的运算能力自我验证新的编译优化器。

接下来具体说一下MaxCompute编译器Playback的原理，这是一个基于AST的编译器，整体采用Visitor模型（如下图）。

 

使用Visitor模型的好处在于我们可以根据需要一遍遍更改各个数据，进而验证整体功能是否存在问题。从上图的SQL语句依次向后可以看出，整个编译器呈现树状结构，对应于最后一列的各个阶段。当然，这还不足以解决上述提到的测试覆盖面较低的问题，毕竟每天几百万的作业不可能光靠人工校验。对大数据系统而言，数据量一定不是问题，这也是大数据系统最初诞生的原因——处理大规模复杂计算任务。 

 

我们的解决思路是使用Playback Sql Script构造分析任务，如果我需要验证某个功能是否有问题，我可以将前一天的几百万作业抓取出来放到新版的编译器和优化器之中运行，将最终跑出来的结果用Visitor模型进行验证，如果有问题，我就写到最终的结果报告中；如果没有问题，我就可以通过该方法大规模提高测试覆盖面。

通过这种自我验证，我可以利用MaxCompute灵活的UDF支持且良好的隔离方案，在UDF中拉起待测的编译器进行编译，之后再进行详细的结果分析。整个过程都在MaxCompute完善的安全体系保护之下，保障用户的知识产权。

此外，我也可以精确得知道新的优化规则的特点，其实说白了就是哪些作业使用了发行的新功能，精确制导找到触发新的优化规则的query，验证其查询优化是否符合预期。 另外，我们在语义上也对用户查询进行了整体数据分析，对相应用户发warning推动用户下线过时的语法；对query整体进行分析来确定下一步开发的重点；评估新版本在查询优化在执行计划上的提高程度。

3.2 MaxCompute Flighting工作原理介绍

接下来说一下我们开发的第二个工具——Flighting工具。Flighting工具主要用于验证Runtime理念以及在新功能加入之后，保证MaxCompute运行器正确执行并保证数据的安全性。

在介绍Flighting工具的工作原理之前，我们先来讨论一些传统做法。如果我们需要验证Runtime执行器新添加的某项功能，传统的做法通常是搭建一个测试集群，在上线之前先测试将各种坑都踩一遍，否则根本达不到测试效果。但是，用测试集群来验证存在三方面的问题：

一是浪费巨大，调度或者scalability等方面的改进往往需要建立一个相同规模的测试集群，如果线上可以达到一万台机器，线下测试时自然需要达到同样的集群数量，否则根本无法达到测试效果。

二是没有相应的任务负载，无法构造对应场景。在线上的实际运行场景中，我们的CPU、内存等资源通常都非常满，各种脏数据很容易出现，但线下往往很难达到这个效果；

三是数据安全问题，我们需要脱敏的方式从生产集群拖数据。在测试过程中，人为制造数据既简单又测不到位，如果从生产运营库里拉数据，我们必须解决数据安全问题。整个过程很容易因为人为疏忽造成数据泄露；脱敏数据可能造成用户程序crash，并且往往不能反映用户运行场景；整个测试过程冗长，不能达到测试目的。

既然使用线下集群数据进行测试如此麻烦，那我们不如直接使用线上数据进行测试，所以我们的思路是把99%的机器资源用来做线上版本运行生产作业，把1%的资源用来跑程序员上载的测试版本进行验证，如下图所示： 

 

通过这种方式，我们解决了很多问题，比如我们不需要再搭建额外的测试集群，虽然99%的机器资源供给线上用户使用，但这部分机器资源不可能一直处于忙碌状态，因此相比于单独搭建测试集群，这种方式在成本上还是有所节省的。此外，由于该测试所承受的集群负载以及压力完全来源于线上，所以该结果具备较高可信度。

这种方式听起来似乎不错，但实施难度较高，首要做好的就是资源隔离，毕竟测试与真正的生产跑在同一个集群中，如果做不好资源隔离，生产方面很容易出现问题。在CPU/Memory层面，我们需要增强cgroup，划分任务优先级；在Disk层面，我们需要进行统一的存储管理，并划分存储优先级；在Network层面是Scalable Traffic Control （万兆网）；最后是Quota管理，对资源进行人为干预。我们要在能够保障线上核心业务需求不受影响的情况下进行flighting测试。

为了提高测试的覆盖面，我们会主动抓取用户制定好的新数据以及各种SQL脚本，放到新的Runtime执行器中运行，并将最终结果与真正生产环境中的Runtime执行器跑出来的数据进行对比，如果结果一致，则证明新功能没有问题。整个过程不需要人工干预进行数据脱敏，因为这些数据在机器里面都是自动化完成的。Flighting的任务结果也不落盘，而是直接对接分析任务产生测试报告，我们可以验证结果的正确性，比如MD5计算，浮点等不确定性类型的处理，也可以对执行性能进行分析，比如straggler，data-skew。

3.3 MaxCompute灰度上线机制工作原理介绍

接下来介绍灰度上线机制。前两大功能一是为了解决编译器及优化器的问题，二是为了解决执行器Runtime的问题，一旦这些测试工作完成，我们就有机会上线了。灰度上线的工作原理是根据任务的重要性进行分级，比如最关键的任务等级为1，次关键任务等级为2，非关键任务等级为3,；每一级都可细粒度进行发布，并且支持瞬时回滚，可将风险控制到最小，比如上线时从等级为3的非关键任务开始，如果该等级任务在进度条完成10%时出现故障，我们可瞬时回滚并重新执行，只有当前等级任务的进度条显示为100%时才会进入下一等级，当所有等级均显示为100%之时，则表示上线成功。 

 

因此，总结整个持续开发验证以及迭代过程（如下图）。开发阶段，我们需要Playback和Flighting进行验证和测试，如果没有问题，我们就会进入灰度上线层面。

 

在整个流程中，两个Sprint之间其实是存在部分交集的，所有回归工作则是通过自动化的方式完成。两个Sprint交替进行让整个过程以流水线的形式向前推进，提高了整个开发上线过程的效率。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31077337/viewspace-2212554/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31077337/viewspace-2212554/