定做网站建设,网站建设与开发是什么岗位,学科网站建设标准,多伦网站建设简介#xff1a; 本文主要介绍如何进行MaxCompute存储资源和计算资源的评估及规划管理。
一、MaxCompute资源规划背景介绍
MaxCompute资源主要有两类#xff1a;存储资源、计算资源(包含cpu和内存)。存储资源用于存储MaxCompute的库表数据#xff0c;计算资源用于运行sql、…简介 本文主要介绍如何进行MaxCompute存储资源和计算资源的评估及规划管理。
一、MaxCompute资源规划背景介绍
MaxCompute资源主要有两类存储资源、计算资源(包含cpu和内存)。存储资源用于存储MaxCompute的库表数据计算资源用于运行sql、mr等任务。最佳的MaxCompute资源规划方案能够达到以下几个目的 • 数据存储资源足够既能够存储当前的所有存量库表数据也能够存储未来一段时间的增量数据 • 计算资源充足但是不能浪费。计算资源量能够满足所有数据计算任务且尽可能减少资源浪费情况。这样耗费的资源费用最少 • 被处理的数据量巨大、耗费计算资源较多的大型任务可能会将quota group资源组耗尽造成其他任务无法获取到计算资源而阻塞。MaxCompute资源规划方案必须能够尽量避免这种情况 • 不同优先级的计算任务能够尽量互不干扰有限保证高优先级的任务获取到足够计算资源 • 能够满足时段的差异化资源需求满足对资源隔离生产/开发/自助分析不同工作负载的能力避免相互干扰同时更大化提高资源使用率。MaxCompute资源规划的最终目标就是能够满足上述几点需求企业客户消耗最低资源费用的情况下满足数据存储需求以及数据处理任务对计算资源的需求。 本文内容主要基于阿里公有云MaxCompute环境。公有云和专有云环境的MaxCompute资源规划有比较大的差异比如在公有云环境存储资源和计算资源是使用整个阿里云区域的资源池几乎不用担心底层到底有多少台服务器进行支撑可以近乎认为公有云底层的资源池是无限的但是在专有云环境整个专有云都是企业客户独享的资源必须根据存储资源和计算资源量规划服务器数量服务器规格。本文主要探讨公有云MaxCompute的资源规划。
二、MaxCompute存储资源规划
2.1 计存比
在介绍存储方案选择之前先说一个常用的概念“计存比”。计存比就是计算CU数量和实际存储数量TB的比值。比如资源分配50CU计算资源存储数据量是10TB。那么50CU/10TB5计存比5。
2.2 存储资源规划建议
对于存储资源MaxCompute提供两种计费方式 • 按量付费MaxCompute以小时级别采集每个项目空间下当前的存储并以 project 项目空间为基本单位计算项目空间当天的存储平均值。然后再乘以单价(元/GB/天)最后的得到每天的存储费用。
• 套餐资源MaxCompute包年包月套餐包含预留的计算资源和存储资源每种套餐固定计算资源CU量和存储资源。套餐中的存储资源是指每天固定的存储资源超过的部分另外按量计费。套餐资源目前只支持固定的几个套餐见下图所示
阿里云提供的第二种方案三种套餐的计存比是固定的而且计存比都在1左右。这种固定资源套餐的计存比偏低适合存储量大、计算任务较少的企业客户。固定资源套餐的计算资源CU量是固定的无法应对计算资源需求量猛增的情况。比如企业平时的数据批量处理任务可以正常运行在双11、618等大促活动期间的数据批量处理任务就会出现严重阻塞。 对于存储资源规划笔者建议 • 当预估企业客户未来一段时间的数据存储总量比较大100TB以上、计算任务少计存比小于1.5选择阿里云的固定套餐资源 • 当客户需要更加灵活的存储资源空间同时计算资源CU量不受存储空间限制建议选择按量付费方式。使用多少存储空间消耗多少存储费用。至于计算资源CU规划按照企业客户的实际需求单独进行规划。
三、MaxCompute计算资源规划
3.1 MaxCompute计算资源简介
对于计算资源规划笔者首先建议在项目测试阶段全部都采用按量付费方式。因为开发测试阶段消耗的计算资源CU数量不多采用按量付费方式更加便宜。关于MaxCompute计算资源按量付费的计费规则读者可以详细参考官网文档https://help.aliyun.com/document_detail/112752.html 项目开发完成正式进入到上线阶段建议购买包年包月的计算资源CU配额因为是固定的CU配额不会在阿里云公共计算资源池去抢占计算资源可以顺利地为企业客户预留足够的CU资源。计费方式如下所示
本章节主要介绍项目上线之后如何购买合适的包年包月固定CU数量。对于计算资源规划本文介绍在项目实践中常用的两种方案方法1 按照以往经验先确定计存比然后预估数据容量最后得到计算计算资源CU量方法2 选择在项目正式上线前、或者在项目正式上线运行一小段时间之后评估计算资源CU消耗的CPU总时长然后再根据不同任务单独消耗的CPU时长、任务的优先级、企业客户要求每天所有任务必须在哪个时间段运行完成综合考虑这几个因素最后得到计算资源CU量的最小最大值用数学表达式表示就是
本文分两个章节分别介绍这两种常用的计算资源预估方法。
3.2按照计存比方法预估计算资源
第一步评估存储容量 按照3年项目周期计算存储容量 当前数据存量 每月预估数据增量*月数。当前数据存量很容易得到在数据上云完成之后就可以得到当前数据存量。每月预估数据增量需要在数据上云之后两三个月根据增量总值除以月数得到每月预估增量平均值。当然如果还要考虑未来数据中台承载更多业务、每月数据增量会变大等因素可以将当前计算得到的每月预估数据增量值乘以倍数。 建议每半年预估一次存储总容量然后每半年调整一次计算资源CU量。第二步预估计存比 按照项目开发测试阶段、以及上线运行一两个月的情况可以大概预估计存比。根据实际情况计存比一般配置2-10。如果客户每天运行的数据批量处理任务很多且sql程序计算复杂度高,计存比可以选择10如果客户每天运行的数据批量处理任务比较少且sql程序计算复杂度不高计算比可以选择2如果客户每天运行的数据批量处理任务适中sql程序计算复杂度也适中计存比可以选择2-10之间的合适值。 建议每半年评估一次计存比然后每半年调整一次计算资源CU量。第三步预估计算资源CU量 按照第一步预估的每半年存储资源总量结合每半年评估的计存比值存储资源总量 *计存比 计算资源CU总量。 预估得到计算资源CU总量进而每半年利用该企业主账号调整一次MaxCompute计算资源CU总量。 按照计存比预估企业项目需要消耗的计算资源CU总量有很多需要预估的变量包括数据存储总量、计存比很可能预估不准确。因此该方法要求项目的技术负责人拥有较多的项目实施经验能够在每一步预估都尽可能准确。
3.3按照项目实际消耗CU量进行资源划分
选择在项目正式上线前、或者在项目正式上线运行一小段时间之后评估计算资源CU消耗的CPU总时长然后再根据不同任务单独消耗的CPU时长、任务的优先级、企业客户要求每天所有任务必须在哪个时间段运行完成综合考虑这几个因素最后得到计算资源消耗费用最少的最佳CU数量。
3.3.1查看计算资源消耗情况
在进行资源规划之前需要首先搞清楚过去一段时间MaxCompute计算资源的消耗情况。读者可以参考https://help.aliyun.com/document_detail/135432.html 详细介绍如何开通和查看MaxCompute的information_schema信息。MaxCompute元数据表有很多本文只需要利用到一张表TASKS_HISTORY。这张元数据表记录了所有MaxCompute 计算任务的资源消耗情况。读者可以参考 https://help.aliyun.com/document_detail/135433.html#title-r2c-tak-zfi 详细介绍元数据表TASKS_HISTORY的字段信息其中最重要的字段信息是cost_cpu 和 cost_mem分别表示
本文主要借助CPU消耗量(也就是上图的cost_cpu字段对应的每个任务消耗的cpu数量)进行计算资源CU数量的规划。需要注意的是cost_cpu字段的含义MaxCompute计算任务作业的CPU消耗量。100表示1 core*s比如官网的例子10 core运行5scost_cpu为10*100*55000。那么cost_cpu字段表示的是“cpu核数消耗量 *100 *任务运行时间秒”。因为cost_cpu按照秒统计对于实际项目评估太过于精细我们通常将cost_cpu 除以 100、然后再除以3600得到cores *h (cpu核数 *小时)。这样方便评估实际项目在规定时间段内运行完所有任务需要quota group资源组的最少计算资源CU数量。 如下如所示某个MaxCompute project 的MaxCompute计算任务的资源消耗情况
3.3.2 规划计算资源CU数量
通过3.3.1章节的内容我们可以查看到MaxCompute project某一天运行的所有计算任务消耗的CPU核数*小时。 计算资源CU数量规划的细则Step1 首先计算得到平均每天运行所有任务消耗的cost_cpu总和(需要除以100才能得到真正的cpu核数 *秒然后再除以 3600得到消耗的 “cpu核数 *小时”)。举个例子MaxCompute project平均每天需要运行1000个任务这些任务消耗的cost_cpu分别是 W1、W2 …… W1000。那么需要将W1 W2 …… W1000 得到每天运行所有任务消耗的cost_cpu总和Wz。注意数据中台一般会划分6个MaxCompute project分别是 • ods_dev贴源层开发测试project • ods_prod贴源层生产project • cdm_dev公共层开发测试project • cdm_prod公共层生产project • ads_dev应用层开发测试project • ads_prod应用层生产project 需要将这6个MaxCompute project的所有数据计算任务的cost_cpu相加得到cost_cpu总和Wz。 当然大部分读者使用MaxCompute进行数据处理并非需要建设数据中台。任何需要使用MaxCompute进行数据处理的应用场景都可以按照实际划分的MaxCompute project将这些MaxCompute project涵盖的所有数据处理任务消耗的cost_cpu相加得到总和Wz。Step2 按照上述介绍的阿里云官网详情介绍cost_cpu需要除以100才是真正消耗的CPU核数。同时cost_cpu按照秒进行度量我们一般会按照小时进行度量。因此需要将cost_cpu总和Wz除以100、再除以3600最后得到平均每天运行所有任务消耗 “cpu核数 *小时”本文假设这个值为W。Step3 咨询客户数据批量处理任务需要在每天的哪些时间段运行完成。举个例子客户要求在深夜零点之后、凌晨6点之前必须将所有数据批量处理任务运行完成。那么每天能够运行的总时长都是6个小时。本文假设所有任务必须在N个小时运行完成。Step4 利用上述得到的每天所有任务[cpu核数 *小时 / 任务运行时长N个小时]就可以得到该客户的MaxCompute project需要分配的计算资源CU数量的最小值W/N。 W/N的前提是数据处理任务的cost_cpu很稳定而且在这N个小时内所有任务都随时在运行不存在任何空闲的时间。但是实际项目可能会因为某些原因导致数据计算任务运行时间延长比如参与计算的数据量增加相当于W会变大同时由于DataWorks/Dataphin调度任务还会产生很多延迟时间、任务获取CU资源也会耽误很多时间这部分延迟时间会加大任务之间运行的时间间隔真正用于运行任务的时间会小于N。 W/N的分母实际变大、分子实际变小进而变相地要求增加计算资源以便让任务获取更多资源进而运行地更加快速。因此一般情况下会在上述得到的W/N结果基础上增加一倍。 按照上述4个步骤可以预估计算得到企业可以需要购买的CU数量。
3.3.3举例规划计算资源CU数量
某企业实施数据中台项目划分8个MaxCompute project。除了3.3.2章节介绍的6个MaxCompute project之外还单独规划了两个专门做数据清洗的MaxCompute project。当然正如前文所述读者需要按照实际规划的若干个MaxCompute project进行计算。Step1 和 Step2 按照3.3.1章节介绍的方法统计过去15天平均每天8个MaxCompute project消耗的“cpu核数 *小时”的总量为202 CPU核数 *小时。Step3 因为客户的业务系统空闲时间在晚上1点到早上6点而且每天早上7点之前需要出每天数据批量任务的运行结果。在6点到7点之间主要产出报表因此只有5个小时可以运行批量任务。Step4 得到MaxCompute计算资源CU数量202 CPU核数 *小时 / 5小时 40.2 cores核数也就是至少需要41 CU。因此建议客户购买计算资源CU量为 41*2 82 CU数量。 根据预估计算结果我们为客户推荐购买的包年包月固定CU量为82个。先开通MaxCompute 计算资源quota group 资源组的包年包月固定CU资源 然后配置总CU量为82个。
四、浅谈MaxCompute group quota 资源划分方法
笔者在第3章节详细介绍如何根据最近一段时间的CU消耗情况预估得到MaxCompute 计算资源CU数量。购买的MaxCompute quota group资源属于“默认预付费Quota”类似于开源hadoop yarn的root资源队列。在实际项目开发过程中还需要将“默认预付费Quota”再细分为若干个“子quota group资源组”。当然一般情况下建议1个MaxCompute project 划分1个子quota group资源组。如何将“默认预付费Quota”划分为若干个子quota group资源组这是本章节需要详细介绍的内容。
4.1 fuxi伏羲资源调度系统原理简介
为了便于读者理fuxi调度系统关于资源组的资源分配和资源抢占机制本文以开源hadoop yarn资源队列进行类比。MaxCompute的“默认预付费Quota”类似于yarn的root资源队列这部分计算资源属于“总计算资源组”需要将总资源组进行细分。 假设我们购买的“默认预付费Quota”包含Dt个CU资源然后“默认预付费Quota”被划分了n个子资源组D1、D2 …… Dn 。这n个资源组必须设置两个重要参数资源组的“预留CU最小配额”minD1、minD2……minDn以及“预留CU最大配额” maxD1、maxD2……maxDn。这n个资源组必须满足以下条件 •** minD1 minD2 …… minDn Dt • 对于任意的子资源组的maxDimaxDi Dt** 我们划分子资源组必须满足上述两个条件。其中每个MaxCompute project的min资源量表示该子资源组最低预留的CU数量无论是否有任务提交这个子资源组就会占用这么多CU量每个MaxCompute project的max资源量表示该子资源组能够获取到的最大CU数量哪怕其他资源组全部都没有任务运行这个子资源组最多也只能占用max的CU量。 如下图所示170个CU资源量的“默认预付费Quota”划分了两个子资源组
从上图我们看到划分的两个子资源组yong_quota_group 和 fixed_quota_group设置的最小CU配额、最大CU配额满足上述两个条件。
4.2 MaxCompute计算资源抢占机制
按照4.1介绍的内容若干个子资源组的max最大CU配额都可以设置为“默认预付费Quota”那么一旦所有资源组对应的MaxCompute project都疯狂地运行任务那么必然存在资源抢占的问题。按照默认规则MaxCompute资源组的资源抢占按照“fair scheduling”公平调度机制先提交的任务优先获取CU资源。那么如果某个MaxCompute project提交超大型任务必然将会把CU资源消耗殆尽。此时其他资源组对应的MaxCompute project提交的任务将会因为无法获取到CU资源而被阻塞。 如何更加完美地划分quota group资源组并且为每个资源组分配最合理的 min资源配额、max资源配额 如何结合实际项目需求合理安排任务运行的先后顺序、以及任务运行调度的依赖关系这是划分子quota group资源组需要考虑的重点因素。
4.3 quota group资源组划分
在第3章节详细介绍如何预估计算企业客户需要购买的包年包月预留CU量也就是 “默认预付费Quota”比如3.3.3章节的实际案例里面介绍的170个CU。下一步就是创建子quota group资源组并为每个quota group分配 min、max资源量。笔者结合多年hadoop yarn资源分配经验以及使用MaxCompute的一些经验总结了一些实际的经验。第1条方法 每个MaxCompute project 对应1个独立的quota group子资源组第2条方法 每个quota group子资源组的min 资源量不小于 “默认预付费Quota”的5%建议也不大于“默认预付费Quota”的20%。具体原因如果将子资源组的min资源量设置太大比如超过20%那么各个资源组的min资源量之和就会接近或者超过“默认预付费Quota”那么划分子资源组将会失去意义最终造成资源大量浪费。第3条方法 每个quota group子资源组的max 资源量不小于“默认预付费Quota”的40%当然最大可以设置到“默认预付费Quota”。如果子资源组的max 资源量设太小在集群运行任务空闲的时候资源会造成极大浪费。 除了上述三条基本方法之外还有几个比较实用的方法第4条方法 对于企业客户划分的多个MaxCompute project需要统计每个project 的cost_cpu消耗量“cpu核数 *小时”并按照消耗量进行排序。消耗量最大的MaxCompute project对应的子资源组的max资源量可以设置为“默认预付费Quota”的80%以上其他project对应的子资源组按照排序设置的max资源量以此减少直到最后的子资源组的max资源量不小于“默认预付费Quota”的40%。第5条方法考虑任务调度与依赖关系 对于很多企业客户使用DataWorks/Dataphin需要做任务调度。任务调度就必然有父子任务关系。比如笔者在本文列举的实际案例对于数据中台项目划分了8个MaxCompute project分别是数据清洗的两个project、ods贴源层的两个project、cdm公共层的两个project、ads应用层的两个project。每个project分配一个独立的quota group子资源组。数据分层有严格的先后顺序数据清洗的任务是ods层任务的父任务ods层任务是cdm层任务的父任务cdm层任务是ads层任务的父任务他们之间的任务调度关系如下所示
对于这类常见的不同MaxCompute project的任务之间有严格的调度依赖关系不能简单的按照上述的方法设置资源组的min资源量和max资源量。因为上一个层次有几百个任务需要运行、下一个层次也有几百个任务需要运行而且这些任务之间是混合运行的。比如某个工作流的几十个ods层任务运行完成那么接下来将会运行对应的几十个cdm层任务与此同时数据清洗层和ods层还会运行新的任务cdm层和ads层也会运行所有上游都运行完成的任务。这些任务之间混合在一起运行为资源组划分资源量添加了很多变数。此时需要根据实际项目经验为这些资源组分配min资源量和max资源量。 比如笔者这边的项目情况如下数据清洗层因为涉及很多业务系统原始数据表的join操作非常消耗CU资源ods层经常是导入清洗之后的数据即可不需要消耗太多资源cdm层规范建模任务运行方法比较固定因为我们在数据清洗层已经将数据做规范化处理因此cdm层消耗的CU资源也很少最后将cdm的派生指标融合进ads层需要做很多复杂的join操作因此消耗的CU资源非常多。并且从晚上1点到凌晨7点之间这四个层次对应的项目运行消耗的资源量呈现“错峰”情况。下图是我们在进行测试环节统计的情况
可以明显看出来四个层次运行任务的数量呈现“错峰”情况每个层次出现的任务高峰会以此延后一段时间该层次MaxCompute project消耗的资源量也是呈现错峰。鉴于上述场景分析我们考虑在第4条方法的基础上将不同层次“错峰”高峰运行的因素也考虑在内。尽可能让消耗资源多的项目分配的max资源量更大但是因为“错峰”运行因素消耗资源少的项目分配的max资源量也不能太小尽可能分配大一些让资源得到合理应用。笔者为该项目设计4个quota 资源组 • 数据清洗层project对应的quota 资源组min资源量为“默认预付费Quota”的10%max资源量为“默认预付费Quota”的70% • ods贴源层project对应的quota 资源组min资源量为“默认预付费Quota”的10%max资源量为“默认预付费Quota”的50% • cdm公共层project对应的quota 资源组min资源量为“默认预付费Quota”的10%max资源量为“默认预付费Quota”的50% • ads应用层project对应的quota 资源组min资源量为“默认预付费Quota”的10%max资源量为“默认预付费Quota”的80%。
五、总结
当然实际如何为MaxCompute project划分资源组每个资源组的min/max资源量占据“默认预付费Quota”的百分比多少需要综合考虑不同MaxCompute project内部的数据处理任务的优先级、任务之间依赖关系、任务错峰运行情况还需要特别考虑某些超大型数据计算任务是否有必要与其他普通任务进行资源组隔离。 原文链接 本文为阿里云原创内容未经允许不得转载。
