数据治理以及质量建设

数据治理以及质量建设

数仓建设真正的难点不在于数仓设计，而在于后续业务发展起来，业务线变得庞大之后的数据治理

数据治理的范围很广，包含数据本身的管理、数据安全、数据成本、元数据管理、数据建模等。

为什么要做数据治理？

因为在数据产生、采集、加工、存储、应用到销毁的全过程中，每个环节都可能会引入各种质量、效率或安全相关的问题。在公司早期的发展阶段，这些数据问题对公司发展的影响并不是很大，公司对问题的容忍度相对也比较高。但是，随着业务的发展，公司在利用数据资产创造价值的同时，对数据质量和稳定性要求也有所提升。此外，当数据积累得越来越多，公司对数据精细化运营程度的要求也随之提高，会逐渐发现有很多问题需要治理。

同时，在数据开发的过程中也会不断引入一些问题，而数据治理就是要不断消除引入的这些问题，保障数据准确、全面和完整，为业务创造价值，同时严格管理数据的权限，避免数据泄露带来的业务风险。因此，数据治理是数字时代很多公司一项非常重要的核心能力。

数据治理方式

数据生产->数据接入->数据存储->数据处理->数据输出->数据展示，每个阶段都需要质量治理，评价维度包括完整性、规范性、一致性、准确性、唯一性、关联性等

质量检查参考维度：

维度	衡量标准
完整性	业务指定必须的数据是否缺失，不允许为空字符或者空值等。例如，数据源是否完整、维度取值是否完整、数据取值是否完整等
时效性	当需要使用时，数据能否反映当前事实。数据必须及时，能够满足对数据时间的要求。例如处理（获取、整理、清洗、加载等）的及时性。
唯一性	在指定的数据集中数据值是否唯一
参照完整性	数据项是否在父表中有定义
依赖一致性	数据项取值是否满足与其他数据项之间的依赖关系
正确性	数据内容和定义是否一致
精确性	数据精度是否达到业务规则要求的位数
技术有效性	数据项是否按已定义的格式标准组织
业务有效性	数据项是否符合已定义的
可信度	根据客户调查或客户主动提供获得
可用性	数据可用的时间和数据需要被访问时间的比例
可访问性	数据是否便于自动化读取

规范治理

规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，统一按照最详细、可落地的方法进行规范建设。

1. 词根

词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。

• 普通词根：描述事物的最小单元体，如：交易-trade

• 专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。

2. 表命名规范

通用规范

• 表名、字段名采用
• 一个下划线分隔词根（示例：clienttype->client_type）。
• 每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。
• 表名、字段名需以字母为开头。
• 表名、字段名最长不超过 64 个英文字符。
• 优先使用词根中已有关键字（数仓标准配置中的词根管理），定期 Review新增命名的不合理性。
• 在表名自定义部分禁止采用非标准的缩写。
• 表名称 = 类型 + 业务主题 + 子主题 + 表含义 + 存储格式 + 更新频率 +结尾

3. 指标命名规范

结合指标的特性以及词根管理规范，将指标进行结构化处理。

• 基础指标词根
• 业务修饰次，用于描述业务场景的词汇
• 日期修饰词，用于修饰业务发生的时间区间
• 聚合修饰词，对结果进行聚集操作
• 基础指标，单一的业务修饰词+基础指标词根构建基础指标，例如交易金额-trade_amt。
• 派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数-install_poi_cnt。
• 普通指标命名规则，与字段命名规范一致，由词汇转换即可以。

修饰词 + 基础指标词根 + 基础指标

交易 + 金额 ——> 交易金额

|| || ||

trade + amt ——> trade_amt

架构治理

数据分层

APP：应用层，面向业务需求进行定制开发
DWA：汇总层，集中建设通用性维度和指标，降低业务需求开发成本
DWT	DIM：主题宽表层，对DWD各信息进行关联整合，输出主题宽表
DWD：明细层，对数据进行规范化，不做横向整合
ODS：存储层，仅以技术手段保留历史数据，不做任何转换，与业务侧DB实体保持同构

数据流向

稳定业务按照标准的数据流向进行开发，即ODS–>DWD–>DWA–>APP。非稳定业务或探索性需求，可以遵循ODS–>DWD–>APP或者ODS–>DWD–>DWT–>APP两个模型数据流。在保障了数据链路的合理性之后，又在此基础上确认了模型分层引用原则：

• 正常流向：ODS>DWD->DWT->DWA->APP，当出现 ODS >DWD->DWA->APP 这种关系时，说明主题域未覆盖全。应将 DWD 数据落到 DWT 中，对于使用频度非常低的表允许 DWD->DWA。
• 尽量避免出现 DWA 宽表中使用 DWD 又使用（该 DWD 所归属主题域）DWT 的 表。
• 同一主题域内对于 DWT 生成 DWT 的表，原则上要尽量避免，否则会影响ETL 的效率。
• DWT、DWA 和 APP 中禁止直接使用 ODS 的表， ODS 的表只能被 DWD 引用。
• 禁止出现反向依赖，例如 DWT 的表依赖 DWA 的表。

元数据治理

技术元数据：为开发和管理数据仓库的IT人员使用，它描述了与数据仓库、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。

常见的技术元数据有：

• 存储元数据：如表、字段、分区等信息。
• 运行元数据：如大数据平台上所有作业运行等信息：类似于hive job日志，包括作业类型、实例名称、输入输出、SQL、运行参数、执行时间、执行引擎等。
• 数据开发平台中数据同步、计算任务、任务调度等信息：包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息 任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。
• 数据质量和运维相关元数据：如任务监控、运维报警、数据质量、故障等 信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。

业务元数据：为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。

常见的业务元数据有：

维度及属性(包括维度编码，字段类型，创建人，创建时间，状态等)、业务过程、指标(包含指标名称,指标编码，业务口径，指标类型，责任人，创建时间，状态，sql 等)，安全等级，计算逻辑等的规范化定义，用于更好地管理和使用数据。数据应用元数据，如数据报表、数据产品等的配置和运行元数据。

元数据治理主要解决的三个问题：

• 通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；
• 基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、 业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；
• 通过元数据建设，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。

安全治理

围绕数据安全标准，首先要有数据的分级、分类标准，确保数据在上线前有着准确的密级。第二，针对数据使用方，要有明确的角色授权标准，通过分级分类和角色授权，来保障重要数据拿不走。第三，针对敏感数据，要有隐私管理标准，保障敏感数据的安全存储，即使未授权用户绕过权限管理拿到敏感数据，也要确保其看不懂。第四，通过制定审计标准，为后续的审计提供审计依据，确保数据走不脱。

为什么要做数据质量？

很多刚入门的数据人，拿到数据后会立刻开始对数据进行各种探查、统计分析等，企图能立即发现数据背后隐藏的信息和知识。然而忙活了一阵才颓然发现，并不能提炼出太多有价值的信息，白白浪费了大量的时间和精力。比如和数据打交道的过程中，可能会出现以下的场景：

场景一：作为数据分析人员，要统计一下近 7 天用户的购买情况，结果从数仓中统计完发现，很多数据发生了重复记录，甚至有些数据统计单位不统一。

场景二：业务看报表，发现某一天的成交 gmv 暴跌，经过排查发现，是当天的数据缺失。 造成这一情况的一个重要因素就是忽视了对数据质量的客观评估，没有制定合理的衡量标准，导致没有发现数据已出现问题。所以，进行科学、客观的数据质量衡量标准是非常必要且十分重要的。

数据质量要求

• 数据完整性

完整性指的是数据信息是否存在缺失的状况，数据缺失的情况可能是整个数据记录缺失，也可能是数据中某个字段信息的记录缺失。

• 数据规范性

规范性指的是描述数据遵循预定的语法规则的程度，是否符合其定义，比如数据的类型、格式、取值范围等。

• 数据一致性

一致性是指数据是否遵循了统一的规范，数据集合是否保持了统一的格式。数据质量的一致性主要体现在数据记录的规范和数据是否符合逻辑，一致性并不意味着数值上的绝对相同，而是数据收集、处理的方法和标准的一致。常见的一致性指标有：ID 重合度、属性一致、取值一致、采集方法一致、转化步骤一致。

• 数据准确性

准确性是指数据记录的信息是否存在异常或错误。和一致性不一样，存在准确性 问题的数据不仅仅只是规则上的不一致，更为常见的数据准确性错误就如乱码， 其次异常的大或者小的数据也是不符合条件的数据。常见的准确性指标有：缺失值占比、错误值占比、异常值占比、抽样偏差、数据噪声。

• 数据唯一性

唯一性指的是数据库的数据不存在重复的情形。比如真实成交 1 万条，但数据表有 3000 条重复了，成了 1.3 万条成交记录，这种数据不符合数据唯一性。

• 数据及时性

及时性是指数据从产生到可以查看的时间间隔，也叫数据的延时时长。比如一份数据是统计离线今日的，结果都是第二天甚至第三天才能统计完，这种数据不符合数据及时性。

数据质量管理流程

数据资产等级

等级定义

根据当数据质量不满足完整性、规范性、一致性、准确性、唯一性、及时性时，对业务的影响程度大小来划分数据的资产等级。

• 毁灭性：数据一旦出错，会引起巨大的资产损失，面临重大收益受损等。标记为 L1
• 全局性：数据用于集团业务、企业级效果评估和重要决策任务等。标记为L2
• 局部性：数据用于某个业务线的日常运营、分析报告等，如果出现问题会给该业务线造成一定的影响或影响其工作效率。标记为 L3
• 一般性：数据用于日常数据分析，出现问题的带来的影响很小。标记为 L4
• 未知性质：无法追溯数据的应用场景。标记为 Lx

重要程度：L1>L2>L3>L4>Lx。如果一份数据出现在多个应用场景中，则根据其最重要程度进行标记。

等级划分

定义数据资产等级后，我们可以从数据流程链路开始进行数据资产等级标记，完成数据资产等级确认，给不同的数据定义不同的重要程度。

举例：

假设公司有统一的订单服务中心。应用层的应用业务是按照业务线，商品类型和地域统计公司的订单数量和订单金额，命名为 order_num_amount。

假设该应用会影响到整个企业的重要业务决策，我们可以把应用定级为 L2，从而整个数据链路上的表的数据等级，都可以标记为L2-order_num_amount，一直标记到源数据业务系统。

数据加工过程卡点校验

在线系统数据校验

在线业务复杂多变，总是在不断地变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，及时做到数据的准确性。

基于此，在线业务的变更如何高效地通知到离线数据仓库，同样也是需要考虑的问题。为了保障在线数据和离线数据的一致性，我们可以通过工具+人员管理并行的方式来尽可能的解决以上问题：既要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。

离线系统数据校验

数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗、加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。如何保障数据加过程中的质量，是离线数据仓库保障数据质量的一个重要环节。

• 代码提交核查：

  开发相关的规则引擎，辅助代码提交校验。规则分类大致为：

  • 代码规范类规则：如表命名规范、字段命名规范、生命周期设置、表注释等；
  • 代码质量类规则：如分母为 0 提醒、NUll 值参与计算提醒等；
  • 代码性能类规则：如大表提醒、重复计算监测、大小表 join 操作提醒等。

• 代码发布核查：

  加强测试环节，测试环境测试后再发布到生成环境，且生成环境测试通过后才算发布成功。

• 任务变更或重跑数据：

  在进行数据更新操作前，需要通知下游数据变更原因、变更逻辑、变更时间等信息。下游没有异议后，再按照约定时间执行变更发布操作。

数据处理风险监控

风险点监控主要是针对数据在日常运行过程中容易出现的风险进行监控并设置报警机制，主要包括在线数据和离线数据运行风险点监控。

在线业务系统的数据生产过程需要保证数据质量，主要根据业务规则对数据进行监控。

比如交易系统配置的一些监控规则，如订单拍下时间、订单完结时间、订单支付 金额、订单状态流转等都配置了校验规则。订单拍下时间肯定不会大于当天时间，也不会小于业务上线时间，一旦出现异常的订单创建时间，就会立刻报警，同时报警给到多人。通过这种机制，可以及时发现并解决问题。

随着业务负责程度的提升，会导致规则繁多、规则配置的运行成本增大，这时可以按照我们之前的数据资产等级有针对性的进行监控。

离线数据风险点监控主要包括对数据准确性和数据产出及时性的监控。对数据调度平台上所有数据处理调度进行监控。

总结：

明确业务需求并从需求开始控制数据质量，并建立数据质量管理机制。

从业务出发做问题定义，由工具自动、及时发现问题，明确问题责任人，通过邮件、短信等方式进行通知，保证问题及时通知到责任人。跟踪问题整改进度，保证数据质量问题全过程的管理。