📚 课程目录第4章数据创建阶段管理

数据创建阶段管理：从源头把控数据质量

数据创建，是整个生命周期管理的起点。说实话，很多团队把精力都花在数据存储和归档上，却忽略了数据刚诞生时的管理。我见过太多案例——数据创建时没管好，后面再怎么清洗、治理，都像是在补救。今天我们就聊聊数据创建阶段的核心：质量标准、元数据、血缘追踪和合规标记。

数据质量标准：别让脏数据进门

数据质量不是事后检查出来的，是创建时就定好的。我个人习惯在数据创建入口就设置质量门禁，就像工厂的来料检验。

质量标准通常包含六个维度：

维度	说明	常见检查项
完整性	必填字段不能为空	NULL 检查、缺失率阈值
准确性	数据值与真实情况一致	格式校验、范围校验
一致性	同一实体在不同系统间一致	交叉验证、引用完整性
时效性	数据在预期时间内可用	时间戳延迟检查
唯一性	无重复记录	主键冲突检测
有效性	数据符合业务规则	枚举值校验、正则匹配

我的经验：别试图一次性覆盖所有维度。先抓完整性、唯一性和有效性，这三个最容易自动化。准确性和一致性往往需要业务规则配合，可以逐步迭代。

举个例子，用户注册场景：

-- 创建时的质量检查示例（伪代码）
CREATE TABLE user_registration (
    user_id      UUID PRIMARY KEY,
    email        VARCHAR(255) NOT NULL,
    phone        VARCHAR(20),
    created_at   TIMESTAMP NOT NULL DEFAULT NOW(),
    -- 质量标记字段
    quality_flag VARCHAR(10) DEFAULT 'PASS',
    check_reason TEXT
);

-- 质量门禁逻辑
INSERT INTO user_registration (user_id, email, phone)
VALUES ($uuid, $email, $phone)
-- 如果邮箱格式不对，直接拒绝写入
ON CONFLICT (user_id) DO NOTHING;

我曾经接手过一个项目，数据仓库里 30% 的用户记录邮箱格式错误。原因就是创建时没做校验，后面清洗成本高得吓人。嗯，从那以后我坚持在写入层做质量拦截。

元数据管理：给数据贴上身份证

元数据，说白了就是「关于数据的数据」。你想想看，如果一张表没有字段注释、没有创建时间、没有负责人信息，三个月后谁还敢用？

数据创建时，至少应该记录以下元数据：

技术元数据：表结构、字段类型、索引、分区信息
业务元数据：业务定义、数据来源、更新频率
管理元数据：创建人、创建时间、数据所有者、SLA 等级

核心原则：元数据必须在数据创建时同步写入，不要事后补录。事后补录的元数据，准确率通常不到 60%。

我习惯在数据库层面用注释或扩展属性来承载元数据：

COMMENT ON TABLE user_registration IS '用户注册表，来源：前端注册接口，更新频率：实时';
COMMENT ON COLUMN user_registration.email IS '用户邮箱，用于登录和通知，格式校验：RFC 5322';
COMMENT ON COLUMN user_registration.quality_flag IS '质量标记，PASS/FAIL，由写入触发器自动设置';

当然，更规范的做法是用元数据管理平台（如 Apache Atlas、DataHub）统一管理。但不管用什么工具，核心就一句话：数据创建时，元数据必须到位。

数据血缘追踪：知道数据从哪来、到哪去

数据血缘，就是记录数据的「家族史」。谁生成了它？经过了哪些转换？最终流向了哪里？

在数据创建阶段，血缘追踪主要做两件事：

记录数据源：标记数据来自哪个系统、哪个接口、哪个文件
记录转换逻辑：如果创建时经过了清洗或加工，要记录转换规则

我见过最头疼的场景：线上报表数据对不上，业务方和开发互相甩锅。后来一查，数据创建时从三个不同源合并，但血缘信息全丢了。你说这锅该谁背？

避坑指南：我曾经在金融项目里吃过亏——数据血缘只记录了表级别，没记录字段级别。结果某个字段值异常，查了两天才定位到是上游接口字段映射错了。从那以后，我要求血缘追踪必须细化到字段级。

下面这张图展示了数据创建阶段的血缘关系：

实际落地时，我推荐用 OpenLineage 或 Marquez 这类开源工具。它们能在数据创建时自动捕获血缘信息，不用手动维护。

数据创建时的合规标记：别等审计来了才后悔

合规，现在是个绕不开的话题。GDPR、CCPA、个人信息保护法……每个法规都在强调数据创建时的合规要求。

数据创建时，必须打上合规标记：

数据分类标记：公开、内部、敏感、高度敏感
数据主体标记：是否包含个人身份信息（PII）
保留策略标记：数据保留期限、删除规则
同意状态标记：用户是否同意数据被采集和使用

关键点：合规标记必须在数据创建时写入，不能依赖后续的批量扫描。因为数据一旦进入系统，再想追溯「当时用户是否同意」就难了。

举个例子，用户注册时采集的合规标记：

-- 合规标记字段设计
CREATE TABLE user_data (
    user_id          UUID PRIMARY KEY,
    email            VARCHAR(255),
    -- 合规标记
    data_class       VARCHAR(20) DEFAULT 'PII',        -- 数据分类：PII/Internal/Public
    consent_flag     BOOLEAN DEFAULT FALSE,             -- 用户是否同意
    consent_version  VARCHAR(10),                       -- 同意协议版本号
    retention_days   INT DEFAULT 365,                   -- 保留天数
    legal_basis      VARCHAR(50) DEFAULT 'user_consent',-- 法律依据
    created_at       TIMESTAMP DEFAULT NOW(),
    deleted_at       TIMESTAMP                          -- 软删除时间
);

我曾经帮一家电商公司做合规改造。他们之前所有用户数据都存着，没有标记哪些是 PII、哪些是行为日志。结果 GDPR 审计一来，光梳理数据就花了三个月。后来我们在数据创建入口加了合规标记，审计时直接按标记筛选，效率提升了 80%。

注意：合规标记不是一成不变的。比如用户撤回同意，你需要有机制更新 consent_flag。我建议用事件驱动的方式，在用户操作时触发标记更新，而不是跑批处理。

小结一下

数据创建阶段的管理，说白了就是四个字：源头治理。质量标准把脏数据挡在门外，元数据让数据可理解，血缘追踪让数据可追溯，合规标记让数据合法合规。这四个点做好了，后面的生命周期管理就轻松一大半。

嗯，这一章的内容就到这里。记住：数据创建时的每一分投入，都会在后续的数据治理中十倍回报给你。