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

锌媒体报道 2023-10-20 15:55

作者：石玉阳人力家高级数据研发工程师

业务简介

人力家是由阿里钉钉和人力窝共同投资成立，帮助客户进入人力资源数字化，依靠产品技术创新驱动战略的互联网公司。公司主要提供包括人事管理、薪酬管理、社保管理、增值服务在内的人力资源SaaS服务，加速对人力资源领域赋能，实现人力资源新工作方式。目前已服务电子商务、零售服务等领域的多行业客户。

人力家是一家典型的创业公司，目前处于一个竞争激烈的市场环境中，公司具有多产品性质，每个产品的数据具有独立性，同时为了配合内部CRM数据需求，更好地把数据整合，对于数仓团队来说是一个不小的挑战，对于数仓团队要求的是稳，准，及时响应。需要数仓团队既要满足内部的数据需求，也需要在计算的成本上实现优化。

业务痛点

MaxCompute作为一款优秀的大数据产品，其不仅可以高性价比分析处理海量数据，同时MaxCompute支持开发接口和生态，为数据、应用迁移、二次开发提供灵活性。QuickBI可以直连MaxCompute产出报表数据供公司内部分析、统计、决策。因为公司开通的MaxCompute是按量付费规格，所以计算任务和QuickBI 报表每次不同的查询都会耗费计算资源导致MaxCompute计算费用增加，在过去的一段时间，MaxCompute每个月的成本波动较大，不符合期望值，且不能有效、及时的发现一些高成本sql和多频访问报表数据集。

具体原因分析

分析 MaxCompute 账单发现费用波动是因为大计算任务和QuickBI报表数据集的自定义sql，主要为以下五点。

1、单SQL查询费用较高

MaxCompute计算和部分QuickBI报表按照时间维度来进行查询数据，但是有些时间查询跨度较大，或者基表数据量大从而形成一条大查询sql。

2、分区不合理

部分MaxCompute计算逻辑和报表数据集设置不合理，有些查询是直接查询近3年分区的数据，造成计算成本费用增加。

3、报表访问频率高，筛选项不同

部分QuickBI报表的数据集成本其实很低，但是每天访问的次数确实很大，由于重复执行造成MaxCompute计算作业量增加，从而导致计算费用增加。

4、兼容报表增加维表数据

部分报表数据集为了兼容数据产出，需要增加部分维表数据来进行关联，但有些维表数据集其实很大，最后也会形成一条大查询sql。

5、运行时间较长

MaxCompute部分计算sql和QuickBI报表数据集计算时间较长，影响整体业务运行时间和报表数据产出。

基于Information Schema分析项目作业

MaxCompute元数据服务Information Schema提供了项目元数据及使用历史数据等信息。在ANSI SQL-92的Information Schema基础上，添加了面向MaxCompute服务特有的字段及视图。

租户级别Information Schema是原项目级别Information Schema的升级版，是在每个阿里云账号下创建名为SYSTEM_CATALOG的项目，并内置Information Schema，通过访问该内置Schema提供的只读视图，查询当前用户所有项目的元数据信息以及使用历史信息。元数据视图列表如下

对于以上部分视图元数据信息，我们更关心的是Information_Schema.TASKS_HISTORY表中每日任务计算的时间、成本和次数。

分析SQL脚本

这里我们使用的是租户级别的 Information Schema，相比于项目级别的 Information Schema，租户级别的只需要创建一个计算节点就可以计算所有 project 的任务，而项目级别的 Information Schema 每个 project 都需要一个计算节点，这里更推荐租户级别的 Information Schema。