西安建站推广,正邦设计怎么样,北京百度推广排名优化,免费空间访客领取网站摘要#xff1a; 每年的双11之前#xff0c;也是MaxCompute各种乾坤大挪移落定的时候#xff0c;因为双11就是各种大折腾项目的自然deadline。在今年双11之前#xff0c;一路向北迁移和在离线混部项目#xff0c;将杭州集群除蚂蚁外整体迁移到张北#xff0c;涉及了绝大部…摘要 每年的双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%业务增长。转载于:https://blog.51cto.com/14031893/2327119
