数仓实践：构建数仓高质量建设指标体系_数仓开发 相同维度多个指标

大家好，我是云祁。

一个企业的数据仓库或者数据中台建设，往往都需要经历前期混沌摸索的阶段，踩过无数的坑之后，才会逐渐建设完善，形成适合自己的一套数仓体系和建设规范。

今天就和大家分享一篇构建高质量数仓的踩坑好文章～

一、 大数据仓库较差的建设

先来回忆一下数仓建设经常遇到的一些坑或现象。

二、构建数仓建设质量指标体系

还在为如何评估数仓建设质量而犯愁么？

本文在常规的分层建设、划分主题外将带大家一起探索出了一条可在大、小团队均可实施落地的数仓建设质量体系构建之路。

为此，从 完善度、复用度、规范度、资源度 全面衡量数仓建设质量。那问题来了，如何构建这4个核心指标呢。如下表所示：

现在有了数仓质量的度量指标体系，新问题也来了。现有的任务及库表在线上运行及相互依赖引用极多，直接贸然改动可能引起线上问题！！！那该如何“落地”呢？

库表名称改动涉及的面太大，那可以 通过任务名称进行改动，例行化每天统计所有的任务消耗的资源；然后放长时间看趋势就可以观察到数据任务的变化趋势。

1、任务名称规范

所属于分层 + 最大引用层 + (主题)(模块)(任务) + 任务调用脚本

示例1：dws-dwd-事件轻度聚合表-dws_detail_app_log_di

2、例行化计算所有任务消耗资源

通过属于分层、最大引用层计算得出跨层引用，如：ads 直接依赖于dwd、ods 层则算跨层引用；

三、战略战术性进行任务改造

某个数仓任务改造效果示例：

Tip1: 小表广播，MapJoin加快产出

Tip2: 降低SQL 嵌套层数，加快产出

Tip3: 降低Group By 维度，加快产出

Tip4: MapReduce 升级为 Spark，加快产出

四、通过数仓质量度量体系建设成果

如下图：

Spark 任务占比逐步提升；

MapReduce 任务占比逐渐递减；

任务平均产出时长在逐步缩短；

数据体系构建