MaxCompute的租户级别Information Schema从租户角度提供项目元数据及使用历史数据等信息，您可以一次性拉取您同一个元数据中心下所有Project的某类元数据，从而进行各类元数据的统计分析。我们在此推出系列元数据使用实践文章。

• MaxCompute元数据使用实践--项目信息统计
• MaxCompute元数据使用实践 -- 数据下载审计

本文主要介绍通过元数据的“TASKS_HISTORY”视图进行作业的相关统计。

在此之前，您如果没还使用过租户级别Information Schema，需要您先详细阅读下租户级别Information Schema文档的背景信息、功能介绍、费用介绍、费用介绍、使用限制和注意事项，避免您在使用过程中遇到不必要的问题。

统计分析作业CU时消耗

场景

当前使用MaxCompute的是按量付费，想评估下是否适合转成包年包月，适合的话需要购买多少包年包月CU合适。

解决方案：

这个场景主要是出于节约成本角度出发，那么考虑到MaxCompute的按量计费模式下，SQL作业的计费方式不是按CU计费，因此我们无法直接按最终的费用来换算，可以通过租户级别的SYSTEM_CATALOG.INFORMATION_SCHEMA.TASKS_HISTORY视图统计过去作业的CU消耗分布进行参考评估。

思路如下：

1）统计最近1个月（元数据默认只有最近15日的数据，若必须，需要您提前每日自行转存到其他普通project中）所有需要转预付的Project每日cost_cpu消耗总和。SYSTEM_CATALOG.INFORMATION_SCHEMA.TASKS_HISTORY中cost_cpu原始单位为core.s，需转换成CU.时（cost_cpu/100/3600）。找出正常消费中最高消费的那一天。

2）对正常消费最高的那一天按小时分别统计所有任务CU时消耗。

3）按业务划分时间段，取最高时间段进行分析。如业务是0-7点为业务高峰期划分为“ETL夜间高峰段”，其他的使用都很低则为一个时间段。

4）汇总高峰期时间段CU时总量/时间，得出该时间段内需要的CU量。如：0-7点这8个小时，CU时为800，则需要100CU跑8个小时才能跑完800CU时的计算量。当然这个是最理想的状态，任务不都是很平均，所以需要根据情况设置一定的冗余。另外还有比较极端的情况， 比如有些任务有依赖关系到5点的时候才需要超大量的CU量，但是这个时候用100CU来跑即使跑3个小时也跑不完，所以这种情况就要结合业务需求，如果这个实在不能延迟时间，要么加大CU量，要么这个Project不适合用包年包月资源。

5）建议不要一次性转所有Project，逐步转，每转一个Project需要通过MaxCompute管家监控资源使用情况，看情况进行扩容/缩容。

相关代码如下：

SET odps.namespace.schema = true; --若您当前租户已经开启租户级别的schema语法开关，则无需执行这个flag。
SELECT  task_catalog
        ,SUBSTR(end_time,1,13) end_time
        ,SUM(cost_cpu / 100 / 3600) cuh
FROM    SYSTEM_CATALOG.INFORMATION_SCHEMA.TASKS_HISTORY
WHERE   ds <= xxx --输入您需要统计的时间，最大只有最近15天数据。注意如果跑当天的数据会有比较大的计算消耗,使用后付费计算资源时需慎重。
GROUP BY task_catalog
         ,SUBSTR(end_time,1,13)
;

如果您通过MaxCompute控制台的 SQL分析执行，可以直接对结果进行简单分析如下：

从上图来看，CU时消耗分布不均匀，每日就只有一个小时是消耗非常高，从这单看不和适合所有项目都使用包年包月CU，但可以按项目分析，评估部分项目数据。

统计每个作业消费

如果您使用MaxCompute的是按量付费，有费用核对审计需求、或基于但作业费用优化需求，您可以通过SYSTEM_CATALOG.INFORMATION_SCHEMA.TASKS_HISTORY视图统计相关的费用，此处为你推荐“人力家”用户如何通过这个数据合理治理费用的展示案例：

【深入MaxCompute】人力家：借助Information Schema合理治理费用

常用的统计分析

统计作业量

统计各个项目每日个类型作业量趋势：

SET odps.namespace.schema = true; --若您当前租户已经开启租户级别的schema语法开关，则无需执行这个flag。
SELECT  ds
        ,task_catalog
        ,task_type
        ,COUNT(inst_id) inst_id_cnt
FROM    SYSTEM_CATALOG.INFORMATION_SCHEMA.TASKS_HISTORY
WHERE   ds <= xxx --输入您需要统计的时间，最大只有最近15天数据。注意如果跑当天的数据会有比较大的计算消耗,使用后付费计算资源时需慎重。
GROUP BY ds
         ,task_catalog
         ,task_type
;

作业类型取值如下：

• SQL：SQL作业
• CUPID：Spark或Mars作业
• SQLCost：SQL预估作业
• SQLRT：查询加速SQL作业
• LOT：MapReduce作业
• PS：PAI的Parameter Server
• AlgoTask：机器学习作业

如果您通过MaxCompute控制台的 SQL分析执行，可以直接对结果进行简单分析如下：

查看某个表数据是被谁查看

查看某个表数据是被谁查看或写入

SET odps.namespace.schema = true; --若您当前租户已经开启租户级别的schema语法开关，则无需执行这个flag。
SELECT  task_catalog
        ,task_type
        ,inst_id
        ,owner_name
        ,start_time
        ,end_time
        ,input_tables
        ,output_tables
        ,operation_text
        ,ext_platform_id
        ,ext_node_id
        ,ext_node_onduty
FROM    SYSTEM_CATALOG.INFORMATION_SCHEMA.TASKS_HISTORY
WHERE   ds =xxxx   --输入您需要查看的时间，只有最近15天数据。注意如果跑当天的数据会有比较大的计算消耗,使用后付费计算资源时需慎重。
AND input_tables LIKE 'dwd_github_events_odps'
;

• task_catalog：作业所属项目。
• owner_name：可以查看真正执行MaxCompute作业的owner名称。有些情况下可能某个业务都是一个账号，这样无法找到作业真正的开发者，如DataWorks生产项目会指定一个账号执行MaxCompute作业。
• - operation_text：SQL内容。
• ext_platform_id：作业是从上游哪个端发起的，需要上游发起作业的时候传入这个信息，目前DataWorks和Dataphin 部分作业有传入，其他没传入无法获取到。
• ext_node_id：作业在上游端发起的具体名称
• ext_node_onduty：上游端作业的负责人uid，您可以尝试用这个id和SYSTEM_CATALOG.INFORMATION_SCHEMA.USERS表关联获取user name。

小结

以上只是给出了常见的几个场景，实际上您还可以通过“SYSTEM_CATALOG.INFORMATION_SCHEMA.TASKS_HISTORY”这个视图数据统计查看更多信息以便解决您的业务场景。