共计 9175 个字符，预计需要花费 23 分钟才能阅读完成。
简介： 本文次要介绍如何进行 MaxCompute 存储资源和计算资源的评估及布局治理。
一、MaxCompute 资源布局背景介绍
MaxCompute 资源次要有两类：存储资源、计算资源 (蕴含 cpu 和内存)。存储资源用于存储 MaxCompute 的库表数据，计算资源用于运行 sql、mr 等工作。最佳的 MaxCompute 资源布局计划可能达到以下几个目标：
• 数据存储资源足够，既可能存储以后的所有存量库表数据，也可能存储将来一段时间的增量数据；
• 计算资源短缺，然而不能节约。计算资源量可能满足所有数据计算工作，且尽可能减少资源节约状况。这样消耗的资源费用起码；
• 被解决的数据量微小、消耗计算资源较多的大型工作，可能会将 quota group 资源组耗尽，造成其余工作无奈获取到计算资源而阻塞。MaxCompute 资源布局计划必须可能尽量避免这种状况；
• 不同优先级的计算工作可能尽量互不烦扰，无限保障高优先级的工作获取到足够计算资源；
• 可能满足时段的差异化资源需要，满足对资源隔离（生产 / 开发 / 自助剖析）不同工作负载的能力，防止互相烦扰，同时更大化进步资源使用率。
MaxCompute 资源布局的最终目标就是可能满足上述几点需要，企业客户耗费最低资源费用的状况下，满足数据存储需要，以及数据处理工作对计算资源的需要。
本文内容次要基于阿里私有云 MaxCompute 环境。私有云和专有云环境的 MaxCompute 资源布局有比拟大的差别，比方：在私有云环境，存储资源和计算资源是应用整个阿里云区域的资源池，简直不必放心底层到底有多少台服务器进行撑持，能够近乎认为私有云底层的资源池是有限的；然而在专有云环境，整个专有云都是企业客户独享的资源，必须依据存储资源和计算资源量布局服务器数量 && 服务器规格。本文次要探讨私有云 MaxCompute 的资源布局。
二、MaxCompute 存储资源布局
2.1 计存比
在介绍存储计划抉择之前，先说一个罕用的概念：“计存比”。计存比就是计算 CU 数量和理论存储数量 TB 的比值。比方资源分配：50CU 计算资源，存储数据量是 10TB。那么，50CU/10TB=5，计存比 =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 cores，比方官网的例子：10 core 运行 5s，cost_cpu 为 10100*5=5000）。那么 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 量为 412 = 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
• 对于任意的子资源组的 maxDi，maxDi <= 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 外部的数据处理工作的优先级、工作之间依赖关系、工作错峰运行状况，还须要特地思考某些超大型数据计算工作是否有必要与其余一般工作进行资源组隔离。
原文链接
本文为阿里云原创内容，未经容许不得转载。
