ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

【中台·数据篇】数据治理：元数据管理、数据血缘与数据质量监控

2026/9/23 12:00:29 拓冰建站 浏览量
【中台·数据篇】数据治理：元数据管理、数据血缘与数据质量监控 前言数据中台最容易被忽视但最致命的问题不是技术而是治理。数据不可信、不可找、不可用是数据中台失败的核心原因。本篇详解数据治理的三大支柱——元数据管理、数据血缘、数据质量监控。一、数据治理全景┌──────────────────────────────────────────────────────────────┐ │ 数据治理体系 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ 元数据 │ │ 数据血缘 │ │ 数据质量 │ │ 数据安全 │ │ │ │ 管理 │ │ 追踪 │ │ 监控 │ │ 管理 │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 数据标准 │ │ 生命周期 │ │ │ │ 管理 │ │ 管理 │ │ │ └──────────┘ └──────────┘ │ │ │ │ 目标数据可找、可信、可用、安全 │ └──────────────────────────────────────────────────────────────┘二、元数据管理元数据类型元数据 描述数据的数据 技术元数据 - 表名、列名、数据类型 - 分区信息、存储格式 - 索引信息 - 位置信息HDFS 路径 业务元数据 - 业务含义amount 订单金额单位元 - 业务口径GMV 已支付订单的总金额 - 数据责任人 - 业务域分类 操作元数据 - 数据产生时间 - 最后修改时间 - 访问记录 - ETL 执行记录Apache Atlas# 部署 Atlas docker run -d \ --name atlas \ -p 21000:21000 \ -e METASTORE_URIthrift://hive-metastore:9083 \ -e KAFKA_SERVERSkafka:9092 \ apache/atlas:2.3.0Hive Hook 自动采集!-- hive-site.xml -- property namehive.exec.post.hooks/name valueorg.apache.atlas.hive.hook.HiveHook/value /property property namehive.exec.pre.hooks/name valueorg.apache.atlas.hive.hook.HiveHook/value /property数据字典-- 元数据查询 -- 查看表结构 DESCRIBE FORMATTED dwd_orders; -- 查看分区 SHOW PARTITIONS dwd_orders; -- 查看列信息 SELECT col_name, data_type, comment FROM (DESCRIBE dwd_orders) t WHERE col_name IS NOT NULL;业务元数据管理-- 建表时加注释 CREATE TABLE dwd_orders ( order_id BIGINT COMMENT 订单ID, user_id BIGINT COMMENT 用户ID, amount DECIMAL(10,2) COMMENT 订单金额元, status STRING COMMENT 订单状态PAID-已支付,CANCELLED-已取消,REFUNDED-已退款, create_time TIMESTAMP COMMENT 创建时间 ) COMMENT 订单明细表 - DWD层 PARTITIONED BY (dt STRING COMMENT 日期分区 yyyy-MM-dd);数据目录数据目录 Web UI ├── 业务域 │ ├── 交易域 │ │ ├── ODS 层 │ │ │ └── ods_orders原始订单 │ │ ├── DWD 层 │ │ │ └── dwd_orders清洗明细 │ │ └── DWS 层 │ │ └── dws_user_daily用户日汇总 │ └── 用户域 │ └── ... └── 技术域 └── ...三、数据血缘血缘的作用数据血缘 数据的来龙去脉 场景 1影响分析 修改 ods_orders 的 amount 字段类型会影响哪些下游表 → 血缘告诉你ods_orders → dwd_orders → dws_user_daily → ads_daily_sales 场景 2根因分析 ads_daily_sales 的 total_amount 异常问题出在哪 → 血缘告诉你ads_daily_sales ← dws_user_daily ← dwd_orders ← ods_orders → 逐层排查 场景 3合规审计 用户数据从哪个表流转到哪个报表 → 血缘提供完整数据流Atlas 血缘追踪# Hive Hook 自动记录血缘 # 当执行 INSERT INTO ... SELECT ... 时 # Atlas 自动解析 SQL记录字段级血缘 # 查看血缘 curl http://atlas:21000/api/atlas/v2/lineage/guid/entity_guid// 血缘 API 返回 { guidEntityMap: { table1: {typeName: hive_table, attributes: {name: ods_orders}}, table2: {typeName: hive_table, attributes: {name: dwd_orders}} }, relations: [ {fromEntityId: table1, toEntityId: table2, relationshipType: INPUT_TO} ] }字段级血缘# 用 SQL 解析库提取字段级血缘 from sqllineage.runner import LineageRunner sql INSERT INTO dwd_orders SELECT order_id, user_id, amount, status, create_time FROM ods_orders WHERE dt 2024-01-15 result LineageRunner(sql).source_tables() # [ods_orders] result LineageRunner(sql).target_tables() # [dwd_orders] # 字段级 result LineageRunner(sql).column_lineage() # ods_orders.order_id → dwd_orders.order_id # ods_orders.user_id → dwd_orders.user_id # ...血缘可视化血缘图示例 ods_orders.amount ──────→ dwd_orders.amount ──────→ dws_user_daily.total_amount ──────→ ads_daily_sales.total_amount │ │ │ │ ods_orders.status ──────→ dwd_orders.status ──────→ dws_user_daily.order_count ──────→ ads_daily_sales.total_orders四、数据质量监控质量维度数据质量六大维度 1. 完整性 → 数据是否有缺失 - 记录完整该有的行有没有 - 字段完整该有的列有没有 2. 准确性 → 数据是否正确 - 值域准确amount 0 - 格式准确日期格式 yyyy-MM-dd 3. 一致性 → 数据是否一致 - 表间一致订单总金额 明细之和 - 跨域一致用户ID 在多表一致 4. 及时性 → 数据是否新鲜 - 数据延迟当天数据是否到位 - 产出时效ETL 是否按时完成 5. 唯一性 → 数据是否去重 - 主键唯一order_id 不重复 - 记录唯一同一维度无重复行 6. 有效性 → 数据是否在有效范围 - 枚举值status ∈ {PAID, CANCELLED, REFUNDED} - 范围值age ∈ [0, 150]质量检查规则-- 1. 完整性检查行数波动 SELECT row_count_check AS rule_name, dt, COUNT(*) AS row_count, LAG(COUNT(*)) OVER (ORDER BY dt) AS prev_count, (COUNT(*) - LAG(COUNT(*)) OVER (ORDER BY dt)) * 100.0 / NULLIF(LAG(COUNT(*)) OVER (ORDER BY dt), 0) AS change_pct FROM dwd_orders GROUP BY dt ORDER BY dt DESC LIMIT 7; -- 2. 空值检查 SELECT null_check AS rule_name, SUM(CASE WHEN order_id IS NULL THEN 1 ELSE 0 END) AS null_order_id, SUM(CASE WHEN user_id IS NULL THEN 1 ELSE 0 END) AS null_user_id, SUM(CASE WHEN amount IS NULL THEN 1 ELSE 0 END) AS null_amount, COUNT(*) AS total_rows FROM dwd_orders WHERE dt 2024-01-15; -- 3. 值域检查 SELECT range_check AS rule_name, SUM(CASE WHEN amount 0 THEN 1 ELSE 0 END) AS non_positive_amount, SUM(CASE WHEN amount 100000 THEN 1 ELSE 0 END) AS too_large_amount, COUNT(*) AS total_rows FROM dwd_orders WHERE dt 2024-01-15; -- 4. 唯一性检查 SELECT uniqueness_check AS rule_name, COUNT(*) AS total_rows, COUNT(DISTINCT order_id) AS distinct_orders, COUNT(*) - COUNT(DISTINCT order_id) AS duplicates FROM dwd_orders WHERE dt 2024-01-15; -- 5. 一致性检查 SELECT consistency_check AS rule_name, a.total_amount AS ads_amount, b.dws_amount AS dws_amount, a.total_amount - b.dws_amount AS diff FROM ads_daily_sales a JOIN ( SELECT SUM(total_amount) AS dws_amount FROM dws_user_daily WHERE dt 2024-01-15 ) b WHERE a.dt 2024-01-15; -- 6. 及时性检查 SELECT freshness_check AS rule_name, MAX(create_time) AS latest_data_time, CURRENT_TIMESTAMP AS check_time, TIMESTAMPDIFF(MINUTE, MAX(create_time), CURRENT_TIMESTAMP) AS lag_minutes FROM dwd_orders WHERE dt 2024-01-15;Great Expectations# Python 数据质量框架 import great_expectations as gx # 创建数据上下文 context gx.get_context() # 创建数据源 batch context.get_batch({ datasource_name: warehouse, table_name: dwd_orders, batch_filter_parameters: {dt: 2024-01-15} }) # 定义期望质量规则 expectations [ batch.expect_table_row_count_to_be_between(min_value1000, max_value1000000), batch.expect_column_values_to_not_be_null(columnorder_id), batch.expect_column_values_to_not_be_null(columnuser_id), batch.expect_column_values_to_be_unique(columnorder_id), batch.expect_column_values_to_be_between(columnamount, min_value0, max_value100000), batch.expect_column_values_to_be_in_set( columnstatus, value_set[PAID, CANCELLED, REFUNDED, PENDING] ), batch.expect_column_values_to_match_regex( columncreate_time, regexr^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}$ ), ] # 验证 for exp in expectations: result exp if not result.success: send_alert(fQuality check failed: {result})质量告警# 质量告警规则 groups: - name:># 表命名层级_主题_实体_时间粒度 命名格式: 层级_主题_实体[_时间粒度] 示例: ods_orders # ODS 层订单 dwd_trade_orders # DWD 层交易域订单 dws_trade_user_daily # DWS 层交易域用户日汇总 ads_daily_sales # ADS 层日销售指标 dim_province # DIM 层省份维度 # 字段命名 下划线分隔: order_id, user_id, create_time 统一后缀: _id主键, _code编码, _name名称, _time时间 金额统一: *_amount金额, *_count计数, *_rate比率指标口径# 统一指标口径 指标定义: GMV: 全称: Gross Merchandise Volume 定义: 已支付订单的总金额 口径: SUM(amount) WHERE status PAID 单位: 元 负责人: 数据团队 DAU: 全称: Daily Active Users 定义: 当日活跃用户数 口径: COUNT(DISTINCT user_id) WHERE 活跃时间在当日 单位: 人 负责人: 用户团队 转化率: 定义: 下单用户数 / 访问用户数 口径: COUNT(DISTINCT 下单user_id) / COUNT(DISTINCT 访问user_id) 单位: 百分比要点回顾治理维度核心内容工具元数据表/列/业务含义Atlas / Hive Comments数据血缘数据流向追踪Atlas Hook / SQL 解析数据质量六大维度检查Great Expectations数据标准命名/口径统一文档 流程数据安全脱敏/权限Ranger / 审计元数据是数据治理的基础让数据可找血缘解决影响分析和根因分析质量监控六大维度完整/准确/一致/及时/唯一/有效指标口径不统一是最大的数据质量问题治理不是一次性项目需要持续运营下一篇预告下一篇【中台·数据篇】数据服务层数据 API 化与 OneService 统一服务将讲解数据如何以 API 形式对外提供。