数据治理成熟度自评模型：你的团队现在在哪一级

一、为什么需要自评模型

7 月我走了几个团队做数据咨询，发现一个很有意思的现象：几乎每个团队都觉得自己"数据治理做得还行"，但一量化就发现到处都是窟窿。

"数据治理"这个词太大了，大到很多人觉得无从下手。所以我把数据治理拆成 5 个能力域，每个分 5 个成熟度等级，做成一个自评模型。用这个模型 10 分钟能完成自评，知道自己在哪里、下一步做什么。

二、五大能力域 × 五级成熟度详解

能力域一：元数据管理

L1 初始级：没有元数据管理系统。想知道一个字段是什么意思，只能去问当初建表的人（如果他还在这家公司的话）。

L2 可重复级：有一个 Excel/Confluence 文档记录了核心表的字段说明，但更新不及时。80% 的团队在这一级。

L3 已定义级：有专门的元数据管理平台（如 DataHub、Atlas），表结构变更自动同步。字段有 owner，指标有口径定义。

# L3 级别：元数据自动采集和同步 class MetadataCollector: """ 自动从数据库采集元数据，同步到元数据平台 关键能力： 1. 自动发现新表和字段变更 2. 记录每次变更的时间线和负责人 3. 提供 API 供下游系统查询 """ def collect_from_clickhouse(self): """从 ClickHouse 采集元数据""" sql = """ SELECT database, table, name AS column_name, type AS data_type, comment AS column_comment -- 建表时的 COMMENT FROM system.columns WHERE database NOT IN ('system', 'INFORMATION_SCHEMA') ORDER BY database, table, position """ return self.db.query(sql) def detect_changes(self, current, previous): """ 对比两次采集结果，发现变更 Returns: dict: 新增表、删除表、新增字段、修改字段类型 """ changes = { "new_tables": [], # 上周期没有，这周期有的表 "dropped_tables": [], # 上周期有，这周期没有的表 "new_columns": [], # 老表新增的字段 "type_changes": [] # 字段类型发生变化的 } # 检测逻辑省略... return changes

L4 已管理级：有血缘追踪——一个字段从哪个数据源来、经过哪些 ETL 加工、被哪些报表引用，一目了然。指标口径变更自动通知下游。

L5 优化级：AI 驱动的元数据管理。自动给字段打标签、自动发现指标重复定义、自动推荐数据资产给业务人员。

能力域二：数据质量管理

L1 初始级：数据质量靠运气。没有人专门管数据质量，出问题就手动修。典型表现：业务方报告说"昨天数据不对"时才开始排查。

L2 可重复级：有一些手动执行的 SQL 校验脚本，但不定期。关键报表上线前会跑一遍校验。

L3 已定义级：数据质量规则系统化。

-- L3 级别：数据质量规则定义和执行 -- 创建一个数据质量检查结果表 CREATE TABLE dq_check_results ( check_date Date, -- 检查日期 check_name String, -- 检查项名称 table_name String, -- 被检查的表 rule_type String, -- 规则类型: completeness/accuracy/uniqueness/timeliness rule_sql String, -- 检查 SQL expected_val Float64, -- 期望值（如 NULL 占比应 < 0.01） actual_val Float64, -- 实际值 passed UInt8, -- 是否通过: 1=通过, 0=不通过 error_detail String -- 未通过时的错误详情 ) ENGINE = MergeTree() ORDER BY (check_date, check_name); -- 示例检查规则：订单表 NULL 值检查 -- 每天自动执行，结果写入 dq_check_results INSERT INTO dq_check_results SELECT today() AS check_date, 'order_amount_null_check' AS check_name, 'dwd_order_detail' AS table_name, 'completeness' AS rule_type, 'NULL 值占比' AS rule_sql, 0.01 AS expected_val, -- 期望 NULL 占比 < 1% countIf(amount IS NULL) / count() AS actual_val, -- 实际 NULL 占比 actual_val <= 0.01 AS passed, -- 判断是否通过 multiIf(actual_val > 0.01, concat('NULL 占比过高: ', toString(round(actual_val * 100, 2)), '%'), '') FROM dwd_order_detail WHERE order_date = today();

L4 已管理级：有数据质量 SLA（Service Level Agreement）。每个核心表的完整性、准确性、时效性都有明确的量化指标。数据质量 Dashboard 实时可见，出问题自动告警。

L5 优化级：AI 驱动的数据质量。AI 自动学习数据分布模式，发现异常数据点时自动告警并给出修复建议。质量规则自动调整。

能力域三：数据安全与权限

L1 初始级：所有人共享一个数据库账号，没有权限管控。这是最危险的状态。

L2 可重复级：按角色分账号（只读、读写、管理员），但粒度粗。

L3 已定义级：列级别权限控制。PII（个人身份信息）字段脱敏。敏感数据访问有审计日志。

-- L3 级别：列级别脱敏 -- ClickHouse 中创建脱敏视图 CREATE VIEW v_users_safe AS SELECT user_id, -- 手机号脱敏：138****1234 concat(substring(phone, 1, 3), '****', substring(phone, -4)) AS phone_masked, -- 身份证号脱敏（中间 8 位生日替换为 ****） concat(substring(id_card, 1, 6), '********', substring(id_card, -4)) AS id_card_masked, register_date, user_level -- 不暴露：真实姓名、详细地址、银行卡号 FROM users;

L4 已管理级：动态数据脱敏 + 基于标签的访问控制。集成公司的 SSO/LDAP，权限自动同步。

L5 优化级：AI 驱动的异常访问检测。自动识别"某账号在半夜大量导数据"等异常行为。

能力域四：数据生命周期管理

L1 初始级：数据永远不删，磁盘满了就加盘。或者反过来，不定期手动删数据，可能误删重要数据。

L2 可重复级：有基本的 TTL 策略，但不一定严格执行。

L3 已定义级：热温冷数据分层，自动归档。有数据保留策略文档。

-- L3 级别：ClickHouse 冷热分层 + TTL CREATE TABLE event_log ( event_time DateTime, event_data String ) ENGINE = MergeTree() PARTITION BY toYYYYMM(event_time) ORDER BY event_time TTL event_time + INTERVAL 30 DAY TO VOLUME 'cold', -- 30天后移到冷存储 event_time + INTERVAL 365 DAY DELETE; -- 365天后自动删除

L4 已管理级：每种数据有明确的保留期限和归档方案。存储成本可视化。定期审计数据保留策略的执行情况。

L5 优化级：基于数据访问频率自动调整冷热分层。AI 判断"这份数据 3 个月没被访问过，移到冷存储"。

能力域五：数据标准与规范

L1 初始级：没有命名规范。同一个东西表 A 叫user_id，表 B 叫uid，表 C 叫userId。时间格式有的用 UTC，有的用北京时间。

L2 可重复级：有一些约定俗成的规范，但没有文档。新同事靠口口相传来学习。

L3 已定义级：有正式的数据标准文档。命名规范、数据类型规范、时间规范、编码规范都有明确约定。

L4 已管理级：规范自动执行。建表 DDL 不符合规范自动拒绝。监控不规范的使用。

L5 优化级：AI 自动检测不符合规范的数据，并给出修复建议。自动生成规范遵从度报告。

三、自评工具

# 数据治理成熟度自评工具 class DataGovernanceMaturityAssessor: """ 数据治理成熟度自评工具 用法： assessor = DataGovernanceMaturityAssessor() result = assessor.self_evaluate() print(result['maturity_level']) """ def __init__(self): # 5 个能力域，每个域 5 个等级的问题 self.domains = { "元数据管理": [ "是否有元数据管理系统？", "核心表字段是否有注释说明？", "是否有字段级别的数据血缘？", "指标口径是否有统一字典？", "是否支持元数据的自动发现和同步？" ], "数据质量管理": [ "是否有数据质量监控？", "核心指标是否有质量 SLA？", "数据质量问题是否有闭环处理流程？", "是否有数据质量 Dashboard？", "异常数据是否自动告警？" ], "数据安全与权限": [ "是否有分角色权限控制？", "敏感数据是否脱敏处理？", "数据访问是否有审计日志？", "权限审批是否有流程？", "是否有异常访问检测？" ], "数据生命周期": [ "是否有数据保留策略？", "是否有 TTL 自动清理？", "是否有冷热数据分层？", "是否有数据归档方案？", "存储成本是否可量化？" ], "数据标准与规范": [ "是否有命名规范？", "是否有数据类型规范？", "时间/编码是否有统一标准？", "规范是否自动执行（非靠人遵守）？", "是否有规范遵从度报告？" ] } def self_evaluate(self) -> dict: """ 自评：每个问题回答 YES（1分）或 NO（0分） 返回总分和各域分数 """ scores = {} for domain, questions in self.domains.items(): score = 0 print(f"\n=== {domain} ===") for i, q in enumerate(questions, 1): answer = input(f" L{i}. {q} (y/n): ") if answer.lower() == 'y': score += 1 scores[domain] = score total = sum(scores.values()) max_score = len(self.domains) * 5 # 25 # 成熟度判定 if total <= 5: level = "L1 初始级：数据治理刚刚起步，先做好元数据管理和基础规范" elif total <= 10: level = "L2 可重复级：有基本意识，但靠人治。下一步把规则系统化" elif total <= 15: level = "L3 已定义级：有标准流程，继续推进量化监控" elif total <= 20: level = "L4 已管理级：不错！关注 AI 驱动的持续优化" else: level = "L5 优化级：行业标杆，继续保持！" return { "domain_scores": scores, "total_score": total, "maturity_level": level, "gap_analysis": self._analyze_gaps(scores) } def _analyze_gaps(self, scores): """ 差距分析：找出最薄弱的领域，给出建议 """ sorted_domains = sorted(scores.items(), key=lambda x: x[1]) weakest = sorted_domains[0] strongest = sorted_domains[-1] return { "最弱领域": weakest[0], "最弱得分": weakest[1], "最强领域": strongest[0], "建议": f"优先提升「{weakest[0]}」，从 L{weakest[1]+1} 级别开始建设" } # 使用示例 # assessor = DataGovernanceMaturityAssessor() # result = assessor.self_evaluate() # print(f"\n你的团队数据治理成熟度：{result['maturity_level']}")

四、常见自评结果解读

五、总结

数据治理不是一朝一夕的事，但也不需要一步到位。用这个模型先做自评，找到最短的板，集中资源补上。

几个实操建议：

1. 不要五个域同时搞，选最痛的那一个域先做。比如业务方天天投诉"数据不准"，就先做数据质量
2. L1→L2 是最关键的一步：从"什么都没"到"有基本规范"，这一步的 ROI 最高
3. L3 以上需要组织保障：只靠一两个人的热情撑不久的，需要流程和制度支撑
4. 每月自评一次，追踪进步趋势。数据治理是基础设施，做对了是润物细无声的效果

把你的自评结果贴在评论区，一起看看大家都在哪一级。

7 月复盘系列第 7 篇，完整系列请查看 22zhuling 博客首页。

资料说明

本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。