关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的

摘要:12月20日的北京云栖大会上,由云栖社区主办的开发者技术进阶峰会再度开启(报名请戳这里,输入邀请码yqsqz3)。在此之前,我们整理了2017杭州云栖大会开发者技术进阶专场上的精彩分享内容,第一篇是阿里巴巴通用计算平台负责人关涛的分享:演讲内容讲述了他是如何带领团队迎接各种挑战,并从阿里大数据平台Maxcompute开始谈起,重点分享了登月项目带来的挑战以及尝试,最后作了简要总结。

以下是精彩视频内容整理:

阿里巴巴大数据平台的前世今生

关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的

MaxCompute是阿里巴巴和阿里云大数据的旗舰计算平台,该平台承接了阿里内部99%存储 + 95%计算,阿里内部所有数据最终都汇集到此平台上;对内用户数为1.4万人,每天作业数为300万+;该平台规模庞大,有超过6万台服务器在四个数据中心10+集群中,具备跨DC调度容灾能力;Maxcompute对外也提供公共云服务,每年大概有200%的业务增长;除了在公共云提供服务,我们还在专有云提供服务。作为大数据旗舰平台,专有云部署到各行各业超过50套,涵盖安全、军工、税务和水利等。

MaxCompute架构如图所示,计算平台接入DataHub数据总线系统,中间是开发套件和数据服务,上层是应用层,所有的数据和运算都落地到此。

关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的

上图为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,回归测试,基于真实数据脱敏的模拟测试集合)。但是由于业务非常复杂,系统非常复杂,完全靠测试穷举不能完全覆盖。而且功能上线时间点不可控(质量问题会导致回滚),团队疲于救火。

关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的

我们对故障原因进行了分析,发现真正的不稳定因素70%来自于变更,也有硬件、用户作业触发等导致的。对此,我们使用互联网在线测试方式进行了如下尝试:

1.       我们做了线上端到端数据正确性校验机制,可以使得“沉默的”正确性问题马上被发现,我们称为DQC,它可以让用户定制很多规则;

2.       Playback + Flighting,线下测试不能把所有case都覆盖到,我们可以把用户跑得所有作业都记录下来,比如让系统同时跑多个版本,可以把跑过的作业在线上重新跑一次,将以前结果和计算出来的结果作对比,通过线上验证的方式查看系统稳定性;

3.       基于平台做灰度发布,通过先切1%不重要的流量方式一步步把系统掀过来,避免震荡带来影响;

4.       我们把专门的稳定性团队拆成全员值班制度,让所有开发人员去线上看客户的问题,切身体会客户情况。

通过以上尝试,我们的故障分在2017年收敛了4倍左右,在专有云领域,我们被评为最稳定的产品,团队对发布更有信心,相对更准时。

挑战二:业务增长超过资源投入

数据爆炸真实的发生在阿里巴巴,如何在有限硬件投入的情况满足每年100%+的计算能力的增长?更深层次的问题是,几年前的设计架构无法满足业务需求和跳跃性的优化要求。

关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的

对此,我们启动了MaxCompute 2.0项目。我们从多个维度对项目进行了分析和定位,具体包括:高性能/低成本是计算平台的一个核心指标;大的性能提升需要架构升级的配合;随软件、硬件的发展,架构需要持续进化;架构方面的投入要有决心:我们投入50%的研发资源,耗时1年。

这次架构升级是为今后2-5年铺路。第一期升级完毕,性能提升1倍,平均线上水位从70%+压到50%-,对内成本30%-50%。

挑战三:平台型系统如何做到开放

一个优秀的平台系统不一定是开源的,但是一定是开放的。那么,如何让用户迁云更容易,如何满足所有业务方的需求,如何与其他系统融为一体?

关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的

开放分为五个层次,包括工具层面、开发语言、引擎层面、系统联动层面和社区合作。我们启动了联合计算平台项目,我们做到了资源统一、数据统一、元数据统一和账号体系和安全统一管理。我们在工具层面和语言层面都支持很多,可以和OSS等作对接,也可以与HBase和Mysql等作对接。

挑战四:商业和技术的平衡点

当业务需求呼声很高,高优先级的业务需求经常打乱既有的计划;当业务需求很多样,内部、公共云、专有云各有不同,哪些做哪些不做?当业务需求并不在技术的主路径上,是否应该单开分支来支持?

关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的

对此,我们先明确一件事情:技术拓展商业边界和商业体现技术价值并不矛盾,产生矛盾的是中短期内的工作优先级和不同需求对技术的“牵引”。

具体的尝试做法如下:

对于V1之后的平台系统,坚持2:8原则;

对于V1之后的平台系统,共性的抽取和模块化设计变得越来越重要(架构螺旋上升);

加快迭代速度(2个月);

可以有例外,但控制非标版本输出,回归周期不能超过2个发布;

明确不做什么,同时赋能上层。

从效果上来看,目前平台开发主线可控,满足各个业务线需求的同时,可以做到架构升级和性能优化;同时,专有云50+套(多种业务形态),研发线1.5资源投入。

总结

经历了这么多的挑战和尝试,我们总结出以下几点:

1.数据安全要从设计之初做起,数据是一种资产,需要发现、管理和优化;

2.开发效率和系统效率同样重要,当规模达到一定程度,你一定会“遇到鬼”,兜底方案(例如监控,自动扫描和清理)需要准备好;

3.系统需要智能化(自动)处理问题,但不能全部依赖自动化,需要定义清晰的范围,定义不清楚就用白名单的方式;

4.时刻关注硬件的升级,软硬结合是大势所向。同时要与人工智能密切结合;

5.打造一个企业级的平台系统,需要业务,技术和人三方面的锤炼。


推荐阅读:

人工智能进阶心得:在战斗中学习,在学习中战斗

上一篇:专访鄢志杰:地铁进入语音购票时代,深度解读下一代人机语音交互技术


下一篇:SQLServer 列出每个表的列和属性