如何保证数据产出质量简述

• 数据质量的评估
• 数据质量的保障
• • • 数据产出流程&机制
    • • revire机制
    • 数据质量保障中的工具&规则
    • • SQLSCAN
      • DQC
      • 基线

数据质量可以从一下几个角度进行评估：

• 完整性：
  • 完整性是指数据的记录和信息是否完整，是否存在数据缺失情况。数据缺失主要包括记录的缺失和具体某个字段信息的缺失，两者都会造成统计结果不准确。
• 准确性
  • 准确性是指数据中记录的信息和数据是否准确、是否存在异常或者错误的信息。例如，成绩单中分数出现负数或订单中出现错误的买家信息等，这些数据都是问题数据。确保记录的准确性也是保证数据质量必不可少的一部分。
• 一致性
  • 一致性通常体现在跨度很大的数据仓库中。 例如，某公司有很多业务数仓分支，对于同一份数据，在不同的数仓分支中必须保证一致性。例如，从在线业务库加工到数据仓库，再到各个数据应用节点，用户ID必须保持同一种类型，且长度也要保持一致。因此，您需要设计数仓的公共层以确保数据的一致性
• 及时性
  • 保障数据的及时产出才能体现数据的价值。例如，决策分析师通常希望当天就可以看到前一天的数据。若等待时间过长，数据失去了及时性的价值，数据分析工作将失去意义。

• 事前：
  利用完善的流程和机制辅以工具对数据质量进行保障。
• 事后：
  同时对于重大事故进行复盘，不断通过一个个case完善工具和机制。

在建设中间层承接需求或到资产产出上调度之间，需要由一套完善的流程和机制来保障数据质量。

• 中间层建设：

建设前确保理解其中的业务逻辑，必要情况下建议对产品PRD、业务&数据流程图、E-R图、表&重点指标的使用说明、甚至状态机维护一份文档。

• APP层建设：

开发前：

理解当前资产的开发背景、意义以及目的（方便后续中间层沉淀），以数据视角给出建议，对不合理或者不准确的指标进行剔除或者修正。
确认维度和指标后，理解维度和每个指标的确切口径，与业务方和DS进行拉齐。重点复杂指标，如果DS已经进行过初步试验，建议给出示例SQL。将所有指标落文档，后续按照文档进行产出。

同时对于已有的口径要保证数据一致性。

1. 各个域的指标口径有各个域进行收口。对现有指标的加工，直接从对于域的中间层取值，而不从底层重新计算。避免底层数据统计逻辑变更导致的数据不一致性。如，商品对GMV进行汇总加工，直接取财务或订单侧的GMV，而不去关注GMV的底层统计逻辑。
2. 统一维护一份指标字典，对原子指标进行全覆盖，对衍生指标尽可能的覆盖。一个指标对外只有一个相同的名称，保证一个名称对应且只对应一个统计逻辑，进而保证数据的一致性。

开发中：

对风险严格把控，有指标口径问题或排期问题及时透传。

发布后上调度（交付）前：

对数据进行校验，同时提过review机制进行最后的把控

通过revire机制对脚本进行最后的把控，保证脚本质量和整条链路的稳定性。

review主要关注点：

1. 模型是否规范

2. 脚本是否规范

3. 监控配置是否规范

主要是指dqc相关的配置

下面通过产出的时间顺序做简单叙述

1. 脚本提交前：

   利用SQLSCAN定制不同规则对脚本进行校验，严重不合格的脚本不允许上线。

2. 脚本发布后、上线前：

   不同人员具有不同权限，脚本发布后需要被review后才可以发布

3. 数据产出前：

​ 利用DQC对脚本产出数据进行校验。不合格的数据不将数据灌入对应分区、不生产成功TAG。并根据资产的重要程度和影响范围利用不同的方式通知对应负责人。

4. 任务产出追踪：

   通过基线对产出中的资产进行追踪

• SQLSCAN一般是为了保证脚本治理在脚本提交前按照设置好的进行检测。

根据重要程度可以设置不同的检测强度：

1. “检测强度-强”：失败不允许提交。一般平台级别的都设置为“强”
2. “检测强度-弱”：失败给与提醒，但是可以提交。项目级别的可以根据项目内部定义设置“强”或“弱“

根据影响范围可以设置不同的分类级别：

1. 平台级
   1. 分区剪裁失败：SQL查询解析执行计划判断是否进行了分区裁剪
   2. SQL是否包含limit限制：sql是否包含limit限制
   3. 分区数超过上限1000：检查sql中涉及的某个表的分区数是否超过10000个
2. 项目级别
   1. 表命名规范：开启规范将按照数仓规范来校验表名,
   2. 不能有select *：检测SQL中是否有select * 的写法
   3. SQL是否包含日期常量：检查sql是否包含日期常量的字符串
   4. 禁止代码中含DDL语句：禁止在代码中使用drop table、create table、rename table、change column等DDL语句
   5. 是否存在读写dev库表：检查代码中是否依赖了dev库表，或是否写入了dev库表
   6. 是否存在反向依赖：检查代码中是否存在dwd依赖app层的反向依赖
   7. 数据质量规则：检查任务产出表是否有配置数据质量规则
   8. 是否存在跨层依赖：检查代码中是否存在如app层直接依赖ods层的跨层依赖

• DQC（Data Quality Center）主要关注数据质量，通过配置数据治理监控规则，自动在数据产出的过程中进行监控。

根据重要程度可以分为

1. 强规则：强规则会阻断任务的进行（数据不写入对应分区、任务置为失败阻断下游）
2. 若规则：给出告警，但并不阻断下游任务

根据监控范围可以分为：

1. 表级规则监控。常见监控规则如下
   1. 总行数不为空
   2. 主键不重复
      • select goods_id,count() from test.dwd_goods_df where dt = ‘2021-12-12’ group by goods_id having count() > 1;
2. 字段级规则监控
   1. 重要字段非空监控。设常见默认值为（0,-999,-1）
      • Select state from test.dim_test where dt = ‘2021-12-12’ group bu state and (state is null or state in (0,-999.-1))
   2. 枚举值是否异常
   3. 字段级阈值监控。如：某个重要字段的空值是否大于1%

其他监控规则：

1. 数据波动监控（监控近3天数据是否在一个量级）

   • select dt,sum(onsale_cnt) from test.dim_gos_goods
     where dt >= ‘2021-12-12’ and dt <= ‘2021-12-15’
     group by dt;

2. 业务相关指标的漏斗是否存在

   • select sum(case when is_td_sale then 1 else 0 end ) as onsale_cnt --当日上架商品数

     ,select sum(case when is_td_sold then 1 else 0 end) as sold_cnt --当日动销商品数

     from test.dim_gos_goods where dt = ‘2021-12-12’

3. 业务相关指标勾稽关系是否满足（设gmv = discoupon_gmv+coupon_gmv）

   • select sum(gmv) as gmv

     ,sum(coupon_gmv) as coupon_gmv

     ,sum(discoupon_gmv) as discoupon_gmv

     from test.dwd_fin_di where dt = ‘2021-12-12’

基线一般用于保障重要生产链路的时效。当基线中任务未在预期产出时间产出或者报错后，触达资产负责人，由人工介入处理任务保障基线正常产出。

基线的设置：

• 结合业务的影响程度，对不同资产进行资产等级划分。同时根据不同的时效要求，将资产划分到对应的基线中。如：默认非重要资产基线、核心决策8点基线、宽表10点基线等
• 重要基线所含资产建议设置DQC强校验，任务未能如期产出时，第一时间触达资产负责人。

基线的保障机制：

• 根据不同基线的重要程度不同，设置不同的保障机制。
  • 非重要基线可以通过邮件、工作群触达。
  • 重要基线通过电话触达，规定时间内资产负责人未响应或未处理完成，触达目标升级至其leader。并且每日配备至少主、副两位基线负责人对基线中异常情况进行追踪。