2. 生产数据资产盘点与质量基线建立

数据治理最容易失败的方式，是一上来就对全库全表做质量规则。生产环境里表动辄上万张，字段几十万个，如果平均用力，既跑不完也修不完。真正可落地的做法是：先做数据资产盘点，识别出核心数据域、关键数据元素（CDE）和业务影响链路，再用 profiling 与采样为这些关键对象建立可量化的质量基线。基线不是"感觉数据还行"，而是一组带阈值、带时间戳、可对比的数字。

一、从业务影响链路反推核心数据域

核心数据域不能靠技术同学拍脑袋，而应从业务影响链路倒推。所谓业务影响链路，是指"某个数据出错后，会沿着哪条路径影响业务结果"。以电商为例：订单域 → 支付域 → 履约域 → 结算域 构成一条主链路，订单金额错了，会传导到支付对账、发货金额、财务结算。链路越靠上游、被引用次数越多、出错后影响面越大，其数据域优先级越高。

实操中可以用三个维度给数据域打分：业务关键度（是否直接支撑收入、合规、客户体验）、下游依赖度（被多少张表、多少个报表、多少个接口引用）、故障历史（近半年是否发生过数据事故）。三项加权后排序，取前 20% 作为核心数据域。这一步的产出是一张"数据域优先级清单"，而不是全量表清单。

二、识别关键数据元素（CDE）

在核心数据域内，进一步识别关键数据元素。CDE 的判定标准通常是：该字段一旦为空、重复、越界或口径不一致，会直接导致业务判断错误或下游任务失败。典型 CDE 包括：订单主键 order_id、支付金额 pay_amount、用户标识 user_id、时间戳 create_time、状态码 order_status 等。

识别 CDE 时建议同时记录四类元信息：所属域、业务定义、技术类型与约束、下游消费方。例如 pay_amount 属于支付域，业务定义为"用户实付金额（含税，单位元，两位小数）"，技术类型为 decimal(18,2)，约束为非空且 ≥0，下游消费方包括对账系统、财务报表、风控模型。这份 CDE 台账是后续质量基线的锚点。

三、用 profiling 与采样建立质量基线

Profiling（数据剖析）是对字段做统计扫描，得到分布、空值率、唯一值数、极值、枚举分布等。生产大表全量 profiling 成本高，因此采用分层采样：对分区表按最近 N 个分区抽样，对超大表用 TABLESAMPLE 或按主键哈希取 1%~5% 样本。采样比例需保证关键指标（如空值率）的置信区间足够窄，一般 1% 采样对百万级表已能稳定估计空值率。

基线指标建议固定为六类，每类都给出"当前值 + 阈值 + 采集时间"：

这些阈值不是拍出来的，而是先用 profiling 跑出"当前真实分布"，再结合业务容忍度设定。例如某表 pay_amount 空值率实测 0.03%，业务可接受上限是 0.1%，则基线定为 0.1%，留出波动空间。基线一旦确定，就写入质量规则库，由调度每日/每小时跑一次，输出"当前值 vs 基线"的偏差。

四、把盘点结果串成可执行链路

整个流程可以概括为：业务影响链路 → 核心数据域 → CDE 台账 → profiling/采样 → 六类基线指标 → 规则库与监控。下图展示了这一关系，其中左侧是识别与盘点，右侧是量化与基线，中间通过 CDE 台账衔接。

五、基线的使用与迭代

基线建立后，日常运行中关注的是"偏差"而非绝对值。例如 pay_amount 空值率基线 0.1%，今天跑到 0.35%，连续两天超阈值，就应触发排查：是上游新增了未填字段，还是某渠道订单结构变化。偏差告警要区分突发型（单日跳变，多为故障）和趋势型（缓慢上升，多为业务漂移），两者处理方式不同。

最后要强调：盘点与基线是持续动作。数据域优先级会随业务战略调整，CDE 会随表结构演进增减，基线阈值会随业务容忍度变化。建议把"数据域清单、CDE 台账、基线指标"作为三份活文档，纳入版本管理，每次变更留痕。这样质量治理才不是一次性运动，而是可审计、可追溯的常态机制。