MaxCompute的租户级别Information Schema从租户角度提供项目元数据及使用历史数据等信息，您可以一次性拉取您同一个元数据中心下所有Project的某类元数据，从而进行各类元数据的统计分析。我们在此推出系列元数据使用实践文章。
本文主要介绍通过元数据的“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”这个视图数据统计查看更多信息以便解决您的业务场景。
