摘要：12月20日的北京云栖大会上，由云栖社区主办的开发者技术进阶峰会再度开启（报名请戳这里，输入邀请码yqsqz3）。在此之前，我们整理了2017杭州云栖大会开发者技术进阶专场上的精彩分享内容，第一篇是阿里巴巴通用计算平台负责人关涛的分享：演讲内容讲述了他是如何带领团队迎接各种挑战，并从阿里大数据平台Maxcompute开始谈起，重点分享了登月项目带来的挑战以及尝试，最后作了简要总结。
以下是精彩视频内容整理：
阿里巴巴大数据平台的前世今生
MaxCompute是阿里巴巴和阿里云大数据的旗舰计算平台，该平台承接了阿里内部99%存储 + 95%计算，阿里内部所有数据最终都汇集到此平台上；对内用户数为1.4万人，每天作业数为300万+；该平台规模庞大，有超过6万台服务器在四个数据中心10+集群中，具备跨DC调度容灾能力；Maxcompute对外也提供公共云服务，每年大概有200%的业务增长；除了在公共云提供服务，我们还在专有云提供服务。作为大数据旗舰平台，专有云部署到各行各业超过50套，涵盖安全、军工、税务和水利等。
MaxCompute架构如图所示，计算平台接入DataHub数据总线系统，中间是开发套件和数据服务，上层是应用层，所有的数据和运算都落地到此。
上图为Maxcompute作业的简单例子，左侧为SQL作业，中间为SQL作业翻译得到的DAG图，每个方块是由若干个workers作业的stage，不同stage间组成有向无环图，从上向下运行，最终会得到两个输出。右侧为基线作业关键路径列表，当我们真正将一个大数据平台上线后，通常不是由一个作业完成所有工作，是多个作业组合完成的，右图即为其中淘宝商户账单列表。
发展历程
阿里云大数据平台的发展历程如下：
2009.09阿里云成立，开始要做云平台这样的事情；
2010.10自主研发平台开始运行，云计算平台飞天的第一个集群稳定运行，ODPS作为核心运算引擎；
2012.10开始建立统一数据平台，数据统一存储，数据标准统一，数据安全统一管理；
2013具备超大规模海量数据处理能力，单集群规模可以达到5K台服务器；
2014~2015 大数据平台开始日趋成熟，可以支撑双十一海量交易、支撑阿里金融业务创新，开始启动登月项目。
那么，什么是登月？为什么要登月呢？
登月项目是一个统一的过程。登月原因主要有两点：
1. 技术发展初期并不会马上诞生一个平台性系统，一般都是在统一的数据中心和硬件基础上（IaaS），集团存在大大小小数十个垂直计算平台，很难打通；
2. 技术上，阿里集团内部的技术发展路线上曾经是双“强”并立：支撑淘宝、支付宝等业务的以Hadoop为底层的云梯1和支撑阿里云、阿里金融等业务的以自主研发“飞天”及MaxCompute为底层的云梯2，当两个系统都很强大时，就需要做一个统一的平台。
登月是一个“漫长”和“昂贵”的过程。
阿里巴巴集团层面牵头，“登月计划”共有24+个项目，将所有数据、计算和硬件资源统一到一起，涉及阿里巴巴和小微金服所有的事业部，覆盖集团全部数据人员，其牵扯人员、资源之多，在集团内部罕见。
2014年1月9日，【登月计划】核心团队正式Kick Off，2015年6月30日，【登月计划】项目集正式Close，历时一年半。
统一后打造了集团统一的大数据平台，其特点体现在安全性、可管理、能开放。
安全性：不仅仅是ODPS本身产品的安全特性，登月过程中还启动并执行了数据分级打标、数据脱敏、ODPS授权流程、虚拟域接入在云端查询版……
可管理：数据管理平台不断优化，统一任务调度中心、统一数据同步工具、统一数据地图管理、统一生命周期；
能开放：开放数据处理服务（ MaxCompute ）作为云产品家族的一部分正式开放给全社会使用……
四个挑战和尝试
我们的团队面临了许多挑战，具体总结为以下四部分：
挑战一：稳定性
稳定性是首先要接受考验的，偶尔会发生集群级别不可用、部分作业系统原因失败等问题，也会有数据永久丢失的可能，当时我们该做的测试也做了（比如UT，FunctionalTest，回归测试，基于真实数据脱敏的模拟测试集合）。但是由于业务非常复杂，系统非常复杂，完全靠测试穷举不能完全覆盖。而且功能上线时间点不可控（质量问题会导致回滚），团队疲于救火。
我们对故障原因进行了分析，发现真正的不稳定因素70%来自于变更，也有硬件、用户作业触发等导致的。对此，我们使用互联网在线测试方式进行了如下尝试：
1. 我们做了线上端到端数据正确性校验机制，可以使得“沉默的”正确性问题马上被发现，我们称为DQC，它可以让用户定制很多规则；
2. Playback + Flighting，线下测试不能把所有case都覆盖到，我们可以把用户跑得所有作业都记录下来，比如让系统同时跑多个版本，可以把跑过的作业在线上重新跑一次，将以前结果和计算出来的结果作对比，通过线上验证的方式查看系统稳定性；
3. 基于平台做灰度发布，通过先切1%不重要的流量方式一步步把系统掀过来，避免震荡带来影响；
4. 我们把专门的稳定性团队拆成全员值班制度，让所有开发人员去线上看客户的问题，切身体会客户情况。
通过以上尝试，我们的故障分在2017年收敛了4倍左右，在专有云领域，我们被评为最稳定的产品，团队对发布更有信心，相对更准时。
挑战二：业务增长超过资源投入
数据爆炸真实的发生在阿里巴巴，如何在有限硬件投入的情况满足每年100%+的计算能力的增长？更深层次的问题是，几年前的设计架构无法满足业务需求和跳跃性的优化要求。
对此，我们启动了MaxCompute 2.0项目。我们从多个维度对项目进行了分析和定位，具体包括：高性能/低成本是计算平台的一个核心指标；大的性能提升需要架构升级的配合；随软件、硬件的发展，架构需要持续进化；架构方面的投入要有决心：我们投入50%的研发资源，耗时1年。
这次架构升级是为今后2-5年铺路。第一期升级完毕，性能提升1倍，平均线上水位从70%+压到50%-，对内成本30%-50%。
挑战三：平台型系统如何做到开放
一个优秀的平台系统不一定是开源的，但是一定是开放的。那么，如何让用户迁云更容易，如何满足所有业务方的需求，如何与其他系统融为一体？
开放分为五个层次，包括工具层面、开发语言、引擎层面、系统联动层面和社区合作。我们启动了联合计算平台项目，我们做到了资源统一、数据统一、元数据统一和账号体系和安全统一管理。我们在工具层面和语言层面都支持很多，可以和OSS等作对接，也可以与HBase和Mysql等作对接。
挑战四：商业和技术的平衡点
当业务需求呼声很高，高优先级的业务需求经常打乱既有的计划；当业务需求很多样，内部、公共云、专有云各有不同，哪些做哪些不做？当业务需求并不在技术的主路径上，是否应该单开分支来支持？
对此，我们先明确一件事情：技术拓展商业边界和商业体现技术价值并不矛盾，产生矛盾的是中短期内的工作优先级和不同需求对技术的“牵引”。
具体的尝试做法如下：
对于V1之后的平台系统，坚持2:8原则；
对于V1之后的平台系统，共性的抽取和模块化设计变得越来越重要（架构螺旋上升）；
加快迭代速度（2个月）；
可以有例外，但控制非标版本输出，回归周期不能超过2个发布；
明确不做什么，同时赋能上层。
从效果上来看，目前平台开发主线可控，满足各个业务线需求的同时，可以做到架构升级和性能优化；同时，专有云50+套（多种业务形态），研发线1.5资源投入。
总结
经历了这么多的挑战和尝试，我们总结出以下几点：
1.数据安全要从设计之初做起，数据是一种资产，需要发现、管理和优化；
2.开发效率和系统效率同样重要，当规模达到一定程度，你一定会“遇到鬼”，兜底方案（例如监控，自动扫描和清理）需要准备好；
3.系统需要智能化（自动）处理问题，但不能全部依赖自动化，需要定义清晰的范围，定义不清楚就用白名单的方式；
4.时刻关注硬件的升级，软硬结合是大势所向。同时要与人工智能密切结合；
5.打造一个企业级的平台系统，需要业务，技术和人三方面的锤炼。
推荐阅读：