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

标签：感知   天都   ext   情况   临时   容量   type   roc   巴巴   

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

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%业务增长。

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

标签：感知   天都   ext   情况   临时   容量   type   roc   巴巴   

原文地址：http://blog.51cto.com/14031893/2327119