大数据

元数据管理与数据质量规则的关系

Posted by

元数据管理和数据质量规则管理是数据治理中紧密衔接的两个核心环节。
元数据管理提供了数据的“描述信息”（如业务含义、技术属性），而数据质量规则管理则基于这些信息，制定具体的校验逻辑，确保数据符合预期标准。

1. 元数据管理与数据质量规则的关系

1.1 输入与输出

  • 元数据管理的输出：
    • 业务规则（如“客户年龄≥18岁”）
    • 技术属性（如字段类型INT、是否可为空NOT NULL）
  • 数据质量规则管理的输入：
    • 基于元数据中的业务规则和技术属性，配置可执行的质量校验逻辑（如SQL规则age >= 18）。

1.2 协同流程

2. 数据质量规则管理的核心内容

2.1 规则类型（需覆盖的校验维度）

规则类型示例关联的元数据
完整性字段非空、唯一键不重复技术元数据（是否可为空、主键定义）
有效性手机号格式、枚举值范围业务元数据（数据字典、业务规则）
一致性跨表数据一致（如订单金额=合同金额）血缘元数据（表间关联关系）

2.2 规则配置方式

方案1：人工配置（你的需求）

  • 操作路径：
    1. 在元数据系统中浏览字段详情（如客户年龄）。
    2. 点击“添加质量规则”按钮，跳转到规则配置页。
    3. 手动选择规则类型（如“数值范围”），输入参数（如最小值=18）。
  • 界面设计建议：

方案2：半自动生成（辅助人工）

  • 实现逻辑：
    • 系统根据元数据中的业务规则（如“年龄≥18岁”），自动推荐规则模板（如“数值范围校验”），人工只需确认或调整参数。
    • 示例：
# 元数据中的业务规则
business_rule = "年龄≥18岁"

# 系统自动解析为质量规则
if "≥" in business_rule:
    min_value = business_rule.split("≥")[1].strip("岁")
    generate_rule(type="min_value", value=min_value)

3. 技术实现标准

3.1 数据模型设计

需在数据库中建立质量规则表，并与元数据关联

CREATE TABLE quality_rules (
    rule_id INT PRIMARY KEY,
    metadata_id INT,              -- 关联元数据表的字段ID
    rule_type VARCHAR(50),         -- 如"completeness", "validity"
    rule_expression JSON,          -- 存储规则逻辑（如{"min": 18}）
    severity VARCHAR(10),          -- P0/P1/P2
    FOREIGN KEY (metadata_id) REFERENCES metadata_fields(id)
);

3.2 接口设计

  • 获取元数据接口：
    GET /api/metadata/{field_id}
{
  "field_name": "age",
  "business_rule": "年龄≥18岁",
  "data_type": "INT"
}

提交质量规则接口：
POST /api/quality-rules

{
  "metadata_id": 123,
  "rule_type": "min_value",
  "rule_expression": {"min": 18},
  "severity": "P0"
}

4. 执行与反馈

4.1 规则执行方式

  • 手动触发：在治理平台点击“立即校验”按钮。
  • 定时任务：通过调度系统（如Airflow）每日凌晨执行。

4.2 结果反馈

  • 存储结果：在元数据系统中标记字段的质量状态（如✅通过、❌失败）。
  • 告警通知：
    • P0错误：短信/钉钉通知责任人。
    • P1错误：邮件通知。

5. 示例全流程

场景：为“客户年龄”字段配置质量规则

  1. 浏览元数据：
    • 字段名：age
    • 业务规则：年龄≥18岁
  2. 跳转配置页：点击“添加质量规则”，系统自动推荐“数值范围”规则。
  3. 人工调整：设置最小值=18，严重等级=P0。
  4. 规则生效：次日ETL任务执行校验，发现5条非法数据（年龄<18），告警数据Owner。

6. 与传统方案的对比

维度你的方案（人工配置）全自动化方案
灵活性支持复杂规则（需人工判断）仅支持预定义规则模板
实施成本需开发配置界面需训练规则生成模型
适用场景业务规则多变或需专家介入规则简单且稳定

总结

你的设计将元数据作为质量规则的输入源，通过人工配置实现精准治理，适合以下场景：

  • 业务规则复杂（如金融、医疗行业的合规性校验）。
  • 需要人工审核规则合理性（避免自动化误判）。

下一步可细化：

  1. 界面原型（规则配置表单的UI/UX设计）。
  2. 规则引擎选型（如Great Expectations、自研SQL解析器）。
  3. 权限控制（如限制业务用户只能查看结果，治理专员可配置规则）。

为什么规则类型只有三种（完整性、有效性、一致性）实际上，数据质量规则的分类并没有固定标准，不同框架和行业实践可能有不同的划分方式。

你可能是参考了某些资料（如DAMA-DMBOK或DCMM）的简化分类，而更完整的规则类型通常包括6类或更多（例如：完整性、有效性、一致性、准确性、时效性、唯一性等）。

1. 为什么常见“三分类”？

(1) 简化逻辑，覆盖核心问题

许多框架将规则归为三大类，是因为它们能覆盖数据质量的最基础、最普适的问题：

  • 完整性：数据是否缺失（如空值、字段不全）。
  • 有效性：数据是否符合格式或业务逻辑（如手机号格式、年龄≥18岁）。
  • 一致性：数据在不同场景下是否矛盾（如跨系统金额不一致）。

这三类是数据质量的“底线要求”，适合快速落地。

(2) 其他规则可归并到这三类

例如：

  • 唯一性（如主键重复）可视为完整性的子集。
  • 准确性（如数据与真实值一致）可归入有效性或一致性。
  • 时效性（如数据更新延迟）可能被归类为一致性（时间维度的一致性）。

2. 更完整的规则类型（6类或更多）

如果需更精细化管理，可以参考以下扩展分类（结合ISO 8000、IBM Data Quality等标准）：

规则类型定义示例关联的元数据
完整性数据是否缺失或不可用字段非空、记录完整技术元数据（是否可为空）
有效性数据是否符合预定义的格式或业务规则手机号格式、枚举值范围业务元数据（数据字典、业务规则）
一致性数据在跨系统、跨表中是否逻辑一致订单金额=合同金额血缘元数据（表间关联）
准确性数据是否与真实世界一致用户地址是否真实存在外部数据源（如地图API）
唯一性数据是否重复主键或业务键唯一（如身份证号不重复）技术元数据（唯一约束）
时效性数据是否在有效时间范围内数据更新延迟≤1小时技术元数据（更新时间戳）

3. 如何选择分类方式？

(1) 简单场景：三分类

  • 适用情况：初期治理、中小规模数据、快速验证。
  • 优点：逻辑清晰，易于实施。

(2) 复杂场景：六分类（或更多）

  • 适用情况：金融、医疗等强合规行业，或数据量庞大、规则复杂的场景。
  • 优点：精细化管控，覆盖更多维度。

4. 结合你的需求（人工配置规则）

无论采用哪种分类，关键是通过元数据驱动规则配置：

  1. 在元数据中标记规则类型（如字段mobile的业务规则是“符合手机号格式”，则归类为有效性）。
  2. 在规则配置界面提供分类筛选（如下拉框选择“有效性规则”）。
  3. 根据分类动态生成输入表单（如选择“有效性”后，显示“正则表达式”输入框）。

5. 示例：规则分类的界面设计

总结

  • 三分类是核心简化版，适合快速启动。
  • 六分类更全面，适合复杂场景。
  • 最终选择取决于你的数据治理成熟度和行业需求。

如果你的业务需要更细粒度的规则（如金融行业需严格区分“准确性”和“有效性”），可以采用扩展分类；如果目标是快速验证，三分类完全足够。

下一篇
字典表与元数据管理
上一篇 元数据管理方案