第四章：数据治理基础：合规数据分类、数据血缘、元数据管理与数据质量框架
各位同学，欢迎来到第四章。说实话，数据治理这个话题，在金融科技圈里经常被讲得很玄乎。什么“数据是新时代的石油”、“数据治理是数字化转型的基石”……这些都对，但咱们做实战的，得落地。
我个人习惯把数据治理看作是合规体系的“地基”。你想想看，监管报送、反洗钱、风控模型，哪一样离得开干净、可靠的数据？如果地基没打好，上面盖的楼再漂亮，也是危房。今天，我们就来聊聊这个地基怎么打。
4.1 合规数据分类：给数据贴上“身份证”
数据分类，说白了就是给数据分门别类。但合规场景下的分类，目的性非常强——为了满足监管要求。
为什么要分类？
我遇到过一家公司，所有客户数据都堆在一个大池子里。结果监管要求报送“高净值客户”的交易记录时，他们花了整整两周去清洗数据。为什么？因为没有分类，你根本不知道哪些数据属于哪个监管范畴。
怎么分？
我个人建议，从两个维度入手：
- 按数据敏感性分： 这是最基础的。比如个人身份信息（PII）、账户信息、交易信息、生物特征信息等。不同敏感度的数据，存储、加密、访问控制策略完全不同。
- 按监管要求分： 这是合规特有的。比如反洗钱（AML）相关数据、客户尽职调查（CDD）数据、市场风险数据、信用风险数据等。每个监管领域都有自己的数据定义和报送要求。
实战小贴士： 分类不是一次性的工作。监管规则会变，业务也会变。我建议建立一个动态的分类矩阵，定期（比如每季度）review一次。
举个例子，一个简单的合规数据分类表可能长这样：
| 数据类别 | 子类别 | 敏感度等级 | 关联监管要求 |
|---|---|---|---|
| 客户身份信息 | 姓名、身份证号、住址 | 高 | 《个人信息保护法》、反洗钱 |
| 交易信息 | 交易金额、时间、对手方 | 中 | 反洗钱、大额交易报送 |
| 风险评级信息 | 客户风险等级、评分 | 中 | 客户风险分类管理 |
| 系统日志 | 操作日志、登录日志 | 低 | 信息安全、审计 |
4.2 数据血缘：追踪数据的“前世今生”
数据血缘，听起来很学术，其实就是搞清楚数据从哪里来、经过了哪些处理、最终去了哪里。为什么合规需要它？
场景一：监管问询。 监管机构问：“你报送的这个‘可疑交易金额’是怎么算出来的？”如果你没有数据血缘，你只能摊手说“系统算的”。有了血缘，你可以清晰地展示：原始交易数据 -> 清洗 -> 聚合 -> 规则引擎匹配 -> 生成可疑交易报告。每一步都有据可查。
场景二：问题溯源。 我记得有一次，一个风控模型跑出来的结果突然异常。我们花了三天时间排查，最后发现是上游一个数据源的表结构改了，但下游的ETL脚本没同步更新。如果有数据血缘，我们就能在几分钟内定位到问题源头。
如何构建？
嗯，这里要注意，数据血缘不是靠手工画图就能搞定的。你需要工具和规范。
- 工具层面： 可以使用Apache Atlas、DataHub、或者商业化的Informatica等工具。它们能自动解析SQL、ETL脚本，生成血缘关系图。
- 规范层面： 我建议在开发规范里强制要求：每个数据处理任务（比如存储过程、Spark Job）都必须声明输入表和输出表。这是最基础的血缘元数据。
避坑指南： 我曾经见过一个团队，把血缘图做得极其复杂，连中间临时表都画上去了。结果图太大，根本没法看。我的建议是：聚焦于“关键数据资产”，比如监管报送字段、核心风控指标。粒度太细，反而失去了实用价值。
下面我用一个简单的SVG图来展示数据血缘的核心逻辑：
4.3 元数据管理：数据的“说明书”
元数据，就是“关于数据的数据”。你可以把它想象成超市里商品上的标签——上面写着生产日期、产地、成分、保质期。没有标签，你根本不知道这个商品是什么、能不能用。
在合规场景下，元数据管理尤其重要。监管机构问“你这个字段是什么意思？”、“这个数据是什么时候采集的？”、“数据保留期限是多久？”——这些问题的答案，都藏在元数据里。
元数据分三类：
- 技术元数据： 表结构、字段类型、索引、分区信息、ETL脚本等。这是给数据工程师看的。
- 业务元数据： 字段的业务含义、计算逻辑、数据来源、数据质量规则等。这是给业务人员和合规人员看的。
- 管理元数据： 数据所有者、数据管理员、创建时间、修改时间、数据保留策略等。这是给数据治理团队看的。
我的经验： 很多公司只重视技术元数据，忽略了业务元数据。结果就是，数据字典里全是“col1”、“col2”这种名字，业务人员根本看不懂。我建议在数据建模阶段，就强制要求填写业务描述。哪怕只是简单的一句话，也比没有强。
一个规范的元数据条目，大概长这样：
| 元数据项 | 内容 |
|---|---|
| 表名 | t_customer_risk_level |
| 业务描述 | 客户风险等级评定结果表 |
| 字段名 | risk_level |
| 字段类型 | varchar(10) |
| 业务含义 | 客户风险等级，取值范围：高、中、低 |
| 数据来源 | 风控模型评分结果 |
| 更新频率 | 每日凌晨2点 |
| 数据所有者 | 风险管理部 - 张三 |
| 保留期限 | 5年 |
4.4 数据质量框架：守住合规的“生命线”
数据质量，是合规的生命线。你想想看，如果报送的数据是错的，轻则被监管通报批评，重则面临巨额罚款。我见过太多因为数据质量问题导致的合规事故了。
数据质量的六个维度：
- 完整性： 数据有没有缺失？比如客户身份证号是不是必填的？
- 准确性： 数据是否真实反映了现实？比如交易金额是不是对的？
- 一致性： 不同系统间的数据是否矛盾？比如CRM系统和核心系统的客户姓名是否一致？
- 及时性： 数据是否在要求的时间内可用？比如监管报送必须在T+1日完成。
- 唯一性： 数据有没有重复？比如同一个客户是不是有多个ID？
- 有效性： 数据是否符合业务规则？比如年龄字段不能是负数。
如何搭建数据质量框架？
我个人习惯分三步走：
- 定义规则： 针对每个关键数据字段，定义质量规则。比如“身份证号必须为18位”、“交易金额必须大于0”。
- 自动化监控： 用工具（比如Great Expectations、Deequ）自动运行这些规则，生成质量报告。我建议每天跑一次，发现问题立刻告警。
- 问题闭环： 发现问题后，要有明确的处理流程。谁负责修复？修复时限是多久？修复后如何验证？
警告： 千万不要试图一次性解决所有数据质量问题。我曾经犯过这个错误，结果项目搞了半年，什么都没做成。我的建议是：先聚焦于监管报送相关的核心数据，把它们的质量搞上去。其他的，可以慢慢来。
下面是一个简单的数据质量监控代码示例（伪代码），展示如何定义和运行一个质量规则：
# 定义数据质量规则
quality_rules = {
"customer_id_not_null": {
"description": "客户ID不能为空",
"table": "t_transaction",
"column": "customer_id",
"rule_type": "not_null",
"severity": "critical"
},
"transaction_amount_positive": {
"description": "交易金额必须大于0",
"table": "t_transaction",
"column": "amount",
"rule_type": "greater_than",
"threshold": 0,
"severity": "high"
},
"id_card_length_check": {
"description": "身份证号必须为18位",
"table": "t_customer",
"column": "id_card",
"rule_type": "length_equals",
"expected_length": 18,
"severity": "medium"
}
}
# 运行质量检查
def run_quality_check(rules):
for rule_name, rule in rules.items():
result = execute_rule(rule) # 执行规则
if result.failed_count > 0:
alert_team(rule_name, result) # 告警
log_issue(rule_name, result) # 记录问题
else:
log_success(rule_name) # 记录成功
好了，这一章的内容就到这里。数据治理是个慢工出细活的事情，急不得。但只要你把分类、血缘、元数据、质量这四个基础打牢了，后面的合规体系建设就会顺畅很多。