在构建数仓高质量指标体系时，面对众多线上任务和库表的依赖，如何安全落地成为挑战。通过任务名称规范，例行化统计资源消耗，以及战略性的任务改造，例如使用MapJoin、降低SQL复杂度等方法，逐步优化数仓性能。结果显示Spark任务占比增加，MapReduce减少，任务产出时长缩短，体现出了数仓质量的提升。
现在有了数仓质量的度量指标体系，新问题也来了。现有的任务及库表在线上运行及相互依赖引用极多，直接贸然改动可能引起线上问题！！！那该如何“落地”呢？
库表名称改动涉及的面太大，那可以 通过任务名称进行改动，例行化每天统计所有的任务消耗的资源；然后放长时间看趋势就可以观察到数据任务的变化趋势。
1、任务名称规范
所属于分层 + 最大引用层 + (主题)(模块)(任务) + 任务调用脚本
示例1：dws-dwd-事件轻度聚合表-dws_detail_app_log_di
2、例行化计算所有任务消耗资源
通过属于分层、最大引用层计算得出跨层引用，如：ads 直接依赖于dwd、ods 层则算跨层引用；
三、战略战术性进行任务改造
某个数仓任务改造效果示例：
最低0.47元/天 解锁文章
扫一扫
1714
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
