首次公开！单日600PB的计算力--阿里巴巴EB级大数据平台的进击

摘要： 每一年的双11以前，也是MaxCompute各类乾坤大挪移落定的时候，由于双11就是各类大折腾项目的天然deadline。在今年双11以前，一路向北迁移和在离线混部项目，将杭州集群除蚂蚁外总体迁移到张北，涉及了绝大部分的业务project、数据存储和计算任务，为今年双十一大数据计算服务的保障带来了挑战。

做者：阿里巴巴计算平台 高级技术专家 迎辉

MaxCompute做为阿里巴巴的主力计算平台，在2018年的双11中，再次不负众望，经受住了双11期间海量数据和高并发量的考验。为集团的各条业务线提供了强劲的计算力，不愧是为阿里巴巴历年双11输送超级计算力的核武器。

本文为你们介绍，MaxCompute基于多集群部署的几万台服务器，如何为集团急剧增加的业务提供护航和保障。

挑战
每一年的双11以前，也是MaxCompute各类乾坤大挪移落定的时候，由于双11就是各类大折腾项目的天然deadline。在今年双11以前，一路向北迁移和在离线混部项目，将杭州集群除蚂蚁外总体迁移到张北，涉及了绝大部分的业务project、数据存储和计算任务，为今年双十一大数据计算服务的保障带来了挑战。

体量

如今MaxCompute包括在离线混部集群在内有几万台服务器，数据总存储量在EB级，日均运行近几百万量级的做业，而天天全部做业处理的数据总量也在几百PB。集群分布三个地理区域，之间由长传链路相链接，因为集团数据业务固有的广泛联系特性，各个集群之间有着切不断的大量数据依赖，以及严重的带宽依赖。

成本

大量的服务器就是大量的成本，下降成本就要充分利用每一个集群的计算存储能力，提升资源利用率。同时，不一样业务有着不一样的特征，有的存储多计算少，有的计算多存储少，有的大规模ETL I/O繁忙，有的机器学习科学计算CPU密集。

怎样充分利用每一个集群的能力，提高CPU、内存、IO、存储各方面的利用率，同时均衡各集群负载，兼顾站点之间长传带宽的压力，在超高资源利用率下保障运行稳定，还要支持杭州总体搬迁这样量级的变动，这些挑战对于MaxCompute并非应对双11大促的一次重大战役，而是MaxCompute天天的平常。

如何应对这些挑战，下面将从各个角度为你们介绍 MaxCompute 所作的一些列工做。

集群迁移
今年，一路向北迁移和在离线混部项目，将杭州集群迁移到张北，同时也涉及了MaxCompute控制集群和计算集群的迁移。 物理资源上的大腾挪，也给MaxCompute的服务保障带来了一些列问题和挑战。

透明的Project集群迁移

可能不少同窗之前遇到过所在Project迁移集群时做业失败，出现 AllDenied 报错。以前在把Project迁到另外一个集群的时候，会对用户有影响，操做前须要先作通知，对用户对运维同窗都很困扰。
今年MaxCompute实现了迁移Project迁移过程当中做业运行和提交都正常不受影响，作到了对用户透明。

轻量化迁移

集群之间由于业务的差别，会出现计算和存储配比不均衡的状况，而正常的迁移须要目标集群的存储和计算空间都知足需求才能作，这样就会遇到有的集群存储水位比较高，但计算能力还没用满，却没办法迁移大的Project过去的状况。

今年上线的轻量化迁移机制，能够实现只迁移计算和部分热数据到新的集群，而老数据则留在原集群，可以达到既均衡了计算资源，又不会有太多跨集群读写的效果。

搬走动不了的OTS

MaxCompute 使用OTS存储系统的各类核心元数据，因此一旦OTS异常，MaxCompute的整个服务都会受到影响。更严重的是，MaxCompute服务对OTS的依赖长期没有主备热切换的支持，使得OTS集群变成了MaxCompute惟一动不了的一个点。

今年做为一路向北迁移规划的一部分，咱们仔细拟定和验证了OTS热切换方案，梳理了控制服务和OTS集群的依赖，目标不可是要作OTS的主备热切换，并且是从杭州直接切到张北。

尽管经历了一次弹内切换的失败，通过进一步优化和演练，最终咱们把切换时间从预约的分钟级别切换缩短到了若干秒级的切换，并在公共云线上环境也成功实施，实际切换过程无异常反馈，作到了用户无感知。

今后MaxCompute服务里最关键的一个点有了无损热切换的能力，大大下降了总体服务的全局性风险。

跨集群调度
多样的全局做业调度机制

集群之间由于做业类型或业务特征等因素，可能会有各类计算资源使用的不充分，好比：业务的全天资源高峰时段及持续时间不一样；申请大块资源的任务类型所在集群有空隙能够超卖小做业填充；甚至有些特殊状况会有临时的资源借用需求。

为此MaxCompute提供了一些全局做业调度机制，能够把指定的一批做业调度到指定的集群运行，或者在当前集群资源繁忙的时候，系统自动去看若是其它集群资源有空闲，就调度到空闲集群运行。

除了均衡资源利用率，这些机制也提供了人工调控的灵活性，而且还在进行与数据排布相结合的调度机制开发，以根据集群实时的状态进行调度。

拓扑感知、数据驱动的桥头堡

做业要访问其它集群的表数据有两个选择，一个是从本集群直接读远程集群（直读），一个是先把远程的数据复制一份到本集群（等复制）。这两种方式各有优缺点及其适用的场景。 同时，集群之间的网络拓扑（是异地长传仍是同城同核心）也会影响直读和等复制策略的选择。异地长传带宽成本高，容量小，同城的网络带宽则相对容量较大，但在大数据的流量下，高峰期都是同样的可能拥堵，因此须要既利用同城带宽优点，又不能把瓶颈转移到同城，须要全局的策略调配。

由于天天业务都在变化，数据的依赖关系也在变化，咱们利用对历史任务的分析数据持续优化和更新复制策略，在每一个区域选择桥头堡集群接收长传的复制，而后在区域内实施链式复制或者近距离直读。 经过桥头堡2.0项目，咱们实现了将2个地域间的数据复制流量下降了30%+。

新机型的新问题
一朝天子一朝臣，一代机型一代瓶颈。

如今MaxCompute的集群规模仍然是万台标准，但今天的万台已经不是几年前的万台，单机的CPU核数从曾经的24核、32核，再到新集群的96核，一台顶过去3台。但无论单机多少核，在MaxCompute的集群里，天天CPU老是能持续几个小时满负荷运行，整体日均CPU利用率达到65%。

不变的除了CPU利用率，还有磁盘数，咱们的数据IO能力仍然是由不变的单机机械硬盘提供。虽然硬盘充起了氦气，单盘容量是之前的3倍，但单盘的IOPS能力却相差无几，DiskUtil就变成了很是大的瓶颈。

通过一系列的优化措施，今年大量96核集群的上线没有了去年面对64核时的狼狈不堪，把DiskUtil维持在了比较可控的水平。

透明的文件合并
跑做业时遇到报错FILE_NOT_FOUND重跑又能过，或者扫描长时间分区范围的做业反复重跑也无法跑过，这个状况相信不少人都遇到过。

为了缓解集群文件数的压力，平台的后台自动文件合并停一两天都有触顶的危险，但长期以来这个动做为了保证数据一致性和效率，都无法避免打断正在读的做业，只能选择只合并比较冷的分区，但一方面文件数的压力迫使把冷的断定阈值从一个月压缩到两周到更短，另外一方面总会有很多做业仍然会去读早些时间的分区而被合并操做打断。

今年平台实现了新的合并机制，会给已经在运行的做业留必定的时间仍能读合并以前的文件，从而再也不受影响，能够很大程度上解决这个顽固问题。

目前新的机制在公共云取得了很好的效果，集团内也在灰度试运行中。

平台性能提高
做为一个计算平台，MaxCompute以计算力为核心指标，经过不断的提高计算力，支撑起集团飞速的业务增加。 对比2017双十一，今年双十一当天MaxCompute做业数几乎有了成倍的增加。 过去一年中，MaxCompute经过在NewSQL+富结构化+联合计算平台+AliORC多个方向上发力，持续构建高可用、高性能、高自适性的大数据平台，提高平台计算力。 9月云栖大会发布中，TPC-BB的测评结果在10TB规模上超越开源系统3倍以上；100TB规模评分从去年的7800+提高到18000+，世界领先。

总结MaxCompute 在2018双十一又一次平滑经过了大促的考验，同时咱们也看到， 平台须要不断提高分布式计算下多集群的综合能力，不断提高计算力，保障大规模计算下的稳定性，来支撑起持续高速增加的业务。 经过持续的引擎能力优化、开发框架建设、智能数仓建设等维度，MaxCompute 向智能化的、开放的、生态平台发展，来支撑起下一个100%业务增加。