资源规划及规格选型

最佳资源规划方案可以达到如下目的：

• 存储资源

  资源充足，既能够存储当前的所有存量数据，也能够存储未来一段时间的增量数据。

• 计算资源

  • 资源充足，且无浪费，能够满足所有计算作业的资源需求。

  • 不同优先级的作业可以互不干扰，优先保证高优先级的作业获取到足够的计算资源。

  • 当某些作业需要处理庞大的数据量且耗费计算资源较多时，可以同时确保其他作业能获取到计算资源且不会阻塞运行。

  • 能够满足不同时段的差异化资源需求，根据不同项目的资源使用情况按照时段划分资源，提高资源利用率。

按照计存比规划计算资源的流程如下：

1. 预估存储容量。

   存储容量=当前数据存储量+每月预估数据增量×月数。

   在项目上线之后就可以得到当前数据存储量。每月预估数据增量需要在项目上线两到三个月后，根据每月增量之和除以月数得到。如果还要考虑未来数据中台会承载更多业务、每月数据增量会变大等因素，可以将当前计算得到的每月预估数据增量值乘以倍数。

2. 预估计存比。

   按照项目开发测试阶段、以及上线运行一两个月的情况，预估计存比。

   计存比一般规划为2~10，后续根据规划的计存比及预估存储容量购买计算资源：

   • 如果项目每天运行的批量处理作业很多，且SQL程序计算复杂度高，计存比推荐规划为10。

   • 如果项目每天运行的数据批量处理作业比较少，且SQL程序计算复杂度不高，计存比推荐规划为2。

   • 如果项目每天运行的数据批量处理作业适中，SQL程序计算复杂度也适中，计存比可以规划为2~10之间的值。

3. 预估计算资源数量。

   根据预估的存储容量、计存比值预估计算资源数量。计算资源数量=预估存储容量×预估计存比。

   说明

   按照计存比预估项目会消耗的计算资源数量时，存储容量、计存比都属于预估项，不够精准。因此，该方法要求项目的技术负责人需要拥有较多的项目实施经验，能够在每一步预估都尽可能保证准确。

按照项目实际消耗的计算资源数量规划计算资源的流程如下：

1. 查看项目的CPU消耗量。

   Information Schema提供的TASKS_HISTORY视图记录了MaxCompute项目中所有计算作业消耗的计算资源情况。您可以通过MaxCompute客户端查询TASKS_HISTORY视图中的cost_cpu字段，基于该字段进一步计算消耗的资源数量。查询TASKS_HISTORY视图的命令示例如下：

   select * from information_schema.tasks_history where ...;

   cost_cpu代表MaxCompute计算作业的CPU消耗量。例如10 core运行5s，cost_cpu为10（CPU核数消耗量）×100（1 core×s）×5（任务运行时间，单位为秒）=5000。

2. 规划计算资源数量。

   1. 计算账户下所有项目平均每天运行所有作业消耗的cost_cpu总和。

      假设某个MaxCompute项目平均每天会运行1000个作业，这些作业消耗的cost_cpu分别是W1~W1000。计算W1~W1000的和即可得到平均每天运行所有作业消耗的cost_cpu总和，假设总和为Wz。

      说明

      通常，数据中台一般会划分如下6个MaxCompute项目：

      • ods_dev：贴源层开发测试项目

      • ods_prod：贴源层生产项目

      • cdm_dev：公共层开发测试项目

      • cdm_prod：公共层生产项目

      • ads_dev：应用层开发测试项目

      • ads_prod：应用层生产项目

      该情况下，您需要计算上述6个项目的所有计算作业的cost_cpu总和。

   2. 基于计算得到的cost_cpu总和进行换算。

      因为cost_cpu按照秒统计，对于实际项目评估过于精细，通常将cost_cpu除以100，然后再除以3600，得到core×h（CPU核数消耗量×小时）。这样方便评估实际项目在规定时间段内运行完所有作业需要的最少计算资源数量。假设该值为W。

   3. 确认作业需要在每天的哪些时间段完成运行。

      例如，客户要求在00:00:00~06:00:00间所有数据批量处理作业必须完成运行。即每天能够运行的总时长是6个小时。本文假设所有作业必须在N个小时内完成运行。

   4. 预估需要购买的计算资源最小值。

      基于前两步得到的值（W和N）进行运算：W（CPU核数消耗量×小时）/N（作业运行时长N个小时），即可得到MaxCompute项目需要购买的计算资源数量的最小值。

      计算W/N的前提是数据处理作业的cost_cpu很稳定，而且在这N个小时内，所有作业都随时在运行，不存在任何空闲的计算资源。但是，实际项目可能会因为某些原因导致作业运行时间延长（例如参与计算的数据量增加），相当于W会变大。同时，由于通过DataWorks或Dataphin运行调度作业还会产生很多延迟时间、作业获取计算资源也会耽误很多时间，这部分延迟时间会加大作业之间运行的时间间隔，真正用于运行作业的时间会小于N。W/N的分母实际变大、分子实际变小，进而变相地要求增加计算资源，以便让作业获取更多资源进而运行更加快速。因此，建议您在W/N结果基础上增加一倍。