简介DGI数据治理框架中文版是一份面向数据管理、数据治理相关从业者的专业参考文档旨在厘清数据治理的目标、范围与权责帮助组织将抽象概念转化为可执行的行动框架。整个资源包为单个PDF文件大小约607KB格式规整便于阅读和归档。目前已有1024人学习此资源。内容完整呈现Gwen Thomas所著框架的核心内容包括数据治理与IT治理的区分、典型侧重领域、数据治理生命周期DGLC方法以及规则、人员与企业团队等具体组成部分同时还给出框架的应用场景与一般步骤涵盖目标设定、范围界定、权责分配和成果衡量等关键环节可作为企业规划数据治理结构、制定问责制度与衡量标准时的落地参考。对于希望系统理解DGI框架、参与数据治理项目或设计治理制度的读者这份中文编译材料具有很强的操作指引价值。1. 数据治理框架 PDF 只是入口真正要交付的是四张可执行清单很多团队都下载过名为「数据治理框架-中文.pdf」的这类文档文件名的构成很直白主题是数据治理框架语种是中文载体是 PDF。但绝大多数人的阅读终点是最后一页。某公司数据团队曾经拿到一份几十页的框架文档看完觉得句句都对合上之后数据还是老样子字段没人认领、口径互相对不上、表越建越乱。问题不在框架写得不好而在框架是管理模型不是操作手册。数据治理框架的真正意义是把数据从产生、加工、消费到归档的生命周期拆成可指认的模块每个模块对应明确的角色、流程和工具。它适合数据平台负责人、数仓工程师和数据产品经理。你不需要把 PDF 背下来你需要把它拆成四张表角色表、规则表、流程表、指标表。本文就按这个顺序讲透。2. 拆解数据治理框架六大模块各自管什么、漏掉哪个会先翻车拿到框架先别急着通读先找三样东西模块清单、角色清单、度量指标。主流框架的分法五花八门但核心跑不掉六件事让数据有名字叫数据标准让人知道数据长什么样叫元数据管理让数据过关叫数据质量让数据不越权叫数据安全合规让数据不死不活叫数据生命周期让数据能跨系统流动叫数据集成与交换。模块管什么典型产出最容易翻车的地方数据标准统一命名、编码、口径标准字典、口径字典标准写出来没人执行元数据管理表结构、血缘、责任人数据字典、血缘地图只有字典没有血缘数据质量完整性、准确性、一致性质量规则、质检报告规则太多成告警风暴数据安全合规分级、脱敏、授权分级清单、访问策略只定级不控制数据生命周期归档、清理、下线保留策略、下线清单清理任务被误停数据集成与交换接口、同步、对账数据流向图、对账记录接口没人维护六个模块里我通常先动四个元数据、质量、安全、生命周期。标准和集成不是不重要而是标准太依赖组织共识集成太偏工程实现都不是数据问题最先卡脖子的地方。下面把四个最容易出偏差的模块展开讲。2.1 元数据管理治理的地基不是“建个字典”元数据是把数据黑匣子打开的第一把钥匙。技术元数据回答“库里有哪些表”业务元数据回答“这个字段人话是什么意思”管理元数据回答“谁能动它”。大多数框架文档把这三层写得很清楚但落地时很多团队只做了技术元数据的采集——把表结构导出来就宣称有元数据平台了。真正的关键是血缘。我曾在某公司遇到字段口径对不上两边的数各说各话扯皮一个月才在调度依赖里找到来源表。有了血缘才能回答“这个数到底是从哪算出来的”。第一步先把技术元数据采集闭环跑起来。如果你的数仓基于通用 Hive 体系可以直接查底层的元数据存储SELECT t.tbl_name AS table_name, t.tbl_type AS table_type, t.owner AS table_owner, p.prm_value AS table_comment FROM metastore_db.tbls t LEFT JOIN metastore_db.table_params p ON t.tbl_id p.tbl_id AND p.prm_key comment WHERE t.tbl_type MANAGED_TABLE AND t.tbl_name NOT LIKE tmp% AND t.tbl_name NOT LIKE test%;这条语句把表名、表类型、建表人、表注释一次性拉全。tbl_name 是表名owner 是建表人comment 通常是建表时写的业务说明。过滤条件里我加了“只取 MANAGED_TABLE”和“排除临时表”这是为了让初始资产清单干净一点不让业务部门看到几百张 tmp 表就失去信心。提示不同 Hive 版本的元数据库名不完全一样有的叫 hive有的叫 metastore字段也可能带前缀但思路一致——从元数据存储直接取表属性比挨个连 JDBC 快得多。采集之后要做三件事给关键表补业务注释、识别核心表的血缘依赖、把 owner 字段落到元数据表里。这三个做完元数据管理才算从“建字典”进到“可定位”。我在实践中发现血缘可以先只做一层上游表是谁、下游表是谁。不需要一开始就做全链路否则采集脚本写一个月业务价值还是零。2.2 数据质量从口号到规则五个维度别一把抓框架文档里数据质量写得很学术完整性、准确性、一致性、及时性、唯一性。我不建议五个维度一次性铺开。先做三个最容易被数据团队感知的完整性对应空值率唯一性对应主键重复波动性对应行数异常。波动性最容易被忽略但它最能第一时间暴露调度挂掉和数据重复写入。准确性最后做因为它依赖业务口径沟通成本最高规则也最难写对。质量规则要写成代码不能只写在 Word 里。我习惯用 YAML 描述规则存进规则库由统一的质检任务读取执行。一个最小可用的规则配置长这样rules: - table: dwd_order_detail rule: row_count_within_range baseline: 7d_median upper_ratio: 1.2 lower_ratio: 0.8 - table: dwd_order_detail rule: column_not_null_ratio column: order_id min_ratio: 0.999 - table: dwd_order_detail rule: primary_key_unique column: order_id - table: dim_user_tag rule: column_value_in_set column: tag_type allowed_values: [new, active, churn]参数说明baseline 用近 7 天中位数做基准比平均值抗尖峰某天双十一流量暴增不会把基线带偏。upper_ratio 和 lower_ratio 是波动上下限初次配置建议设成 1.5 和 0.5跑两周观察模式只记录不告警看到真实波动范围之后再收紧。min_ratio 的 0.999 表示每 1000 行最多允许 1 个空 order_id这是订单表的底线不允许放宽。allowed_values 只用在维度表和枚举字段不要用在自由文本上否则一天能告警几百次。这里有个血泪经验规则不是越多越好。我见过某团队一口气配了一百多条规则第一周告警群爆掉第二周全员屏蔽第三周连生产事故告警都没人响应。质量规则的增量要跟着团队处理能力走先配 10 张核心表、每表 3 到 5 条跑顺了再扩。2.3 数据安全与合规分级分类是治理的分水岭框架里的安全模块通常先讲合规要求再讲分级分类。落地顺序要反着来先分级再按级定控制手段合规检查自然顺理成章。分级不能拍脑袋我常用“丢失或泄露后的影响程度”来分四级公开、内部、敏感、机密。判断标准很简单——字段值能定位到具体个人或者泄露会给业务带来实质损失就至少是敏感级。第一步先用字段名做初筛。很多元数据平台支持直接在元数据表上写正则下面这段在通用元数据表上就有用SELECT schema_name, table_name, field_name FROM metadata_fields WHERE field_name ~* (^|\_)(mobile|phone|tel)(\_|$) OR field_name ~* (^|\_)(id\_card|idno|identity)(\_|$) OR field_name ~* (^|\_)(bank\_card|acct\_no)(\_|$);这段 SQL 的作用是找出命名中带手机号、身份证、银行卡特征的字段。~* 是大小写不敏感的正则匹配前缀后缀用(^|\_)和(\_|$)是为了避免把 user_id 这种字段误判成身份证。注意身份证的匹配我没用id$因为 user_id、address_id 全都会命中误报率会高到没法看。但字段名正则只是第一轮。我遇到过有人在名叫 remark 的字段里存了整段明文手机号正则漏了个干净最后还是抽样数据时发现的。所以命中正则的字段要抽样本数据人工复核复核结果回填到分级清单形成“初筛—抽样—复核—回填”的闭环。不要一开始就上机器学习识别敏感数据样本量不够时模型比正则更玄学。先靠规则把确定性的筛掉再慢慢补模型这条路最稳。2.4 数据生命周期清理比归档更重要框架对生命周期的描述通常是从产生到归档的全过程方向是对的但落地最容易卡在“不知道哪些表该死”。不干活的表不清理集群只涨不跌存储账单越来越难看最后治理报告写得再好成本这边也会被打脸。我给一个保守的三级保留策略适合大多数数仓场景层级定义保留周期说明热数据最近 90 天被读写的表长期随业务滚动T1 任务依赖的核心表不设硬性下线温数据90 天无读写但季度报表可能用到12 个月保留分区可以推到冷介质冷数据1 年以上无读写6 个月后评估下线或归档下线前先做恢复演练具体操作上靠审计日志统计读写时间不要看表目录的修改时间——分区更新也会改目录时间会误判成“还在用”。第一步先把一年没有读写的表找出来生成“待归档清单”给业务方两周窗口认领。没人认领的表先归档归档后再给一个月缓冲期然后正式下线。这个“预告—认领—归档—缓冲—下线”五步流程是后来补的因为第一次直接下线把业务的一张月度报表搞挂了凌晨两点被人打电话叫起来恢复数据。从那之后任何下线动作都强制走五步流程没有例外。3. 从 PDF 到落地数据资产盘点、标准先行与最小闭环框架落地不是从买平台开始也不是从定制度开始而是从一个问题开始我到底有哪些数据这步做不扎实后面所有模块都是空中楼阁。3.1 第一步数据资产盘点先盘核心域盘点范围要收敛。全公司几百套系统全量盘点是最理想的状态我的建议是先盘“支撑月报、周报、核心业务看板的 30 到 50 张表”。范围定了之后盘出来的资产清单至少要有下面这些列字段组字段谁来填基础信息表名、所属库、主题域、系统来源数仓工程师业务信息业务含义、统计口径业务分析师治理信息责任人、敏感级别、保留周期责任人认领治理负责人定级工程信息日增行数、最近写入时间、存储大小元数据采集自动得出这张清单是后面所有工作的主数据。质量规则挂到哪张表、安全分级覆盖到哪张表、生命周期归档从哪张表开始都从这份清单里筛选。第一批盘点只要保证四件事每张表都有 owner、都有主题域、都有敏感级别、都有更新频率。这四列填满盘点就算过关。不要追求一次把十几个字段全填满先让存量表从“三不管”变成“有人管”再逐步补细节。盘点的另一个要点是拉上业务分析师一起看。数仓工程师知道表结构但说不清“这个字段在业务上到底算什么”只有业务分析师能把口径讲清楚。某公司第一次盘点就是只让数仓自己填结果填出来的业务含义全是“用户标识”“交易金额”这类废话等于没填。第二次改成两人一组结对盘点质量立刻不一样。3.2 第二步定标准与分级从两件小事开始框架里的数据标准往往厚厚一本包含命名、编码、口径、模型规范。我见过翻车最狠的团队按框架原版做了一个全量标准库评审通过后半年没人用。原因很简单标准是给新表和改造表用的存量表根本背不动。所以标准落地先做两件小事。第一件是字段命名规范。小到什么程度先定一条所有时间字段必须叫 xxx_time 或 xxx_date二选一不允许同时存在报表字段必须带单位后缀金额带 amt、数量带 cnt。这一条就够拦住大部分“用拼音缩写命名”的问题。第二件是指标口径字典。先收入前 10 个吵架最多的指标用户数、订单数、GMV 这类。口径不统一是数据治理里最典型的矛盾来源。我一般这样写口径表指标业务定义计算公式来源表与过滤条件更新频率责任人GMV支付成功订单金额合计sum(pay_amount)dwd_order_detail where pay_status success日更某分析师活跃用户数当日有登录行为的用户去重数count(distinct user_id)dwd_login_log where login_time 当前日日更某分析师口径表有一个关键机制如果口径要改必须走变更流程旧口径保留版本号不能直接覆盖。某公司曾经因为新旧口径在同一个报表里交替使用被审计问询过。从那之后“口径只增不改”成了硬规矩。分级分类不建议按“全公司一张表”来做。我习惯按主题域建分级子表因为同一个字段在不同域可能不同级。比如手机号在风控域和客服域都是敏感但备注字段在客服域经常混着手机号“元数据看着不敏感、数据里全是敏感”的情况只能靠第 2.3 节的抽样复核来兜底。3.3 第三步搭最小工具链跑通第一个月不要一上来就上重型治理平台。我建议用现有工具拼一个“最小闭环”调度系统负责跑任务监控系统负责告警发布流程负责卡点。四个步骤就能跑起来在调度系统里注册一个每日元数据扫描任务把资产清单里的表逐一扫描更新行数、空值率、最近写入时间。在监控系统里挂上质量规则每条规则对应一个告警通道只推给表 owner不要推给全组。在数仓发布流程里加三道卡点没有 owner 禁止发布、没有敏感级别禁止发布、没有保留周期禁止发布。每周五出一份治理简报贴在团队看板上不单独发邮件。这三道卡点是框架落地最关键的地方。治理规则能不能活下去不看规则文件写得多好看发布流程卡不卡得住。如果没有流程控制权所有治理动作都是运动式的做完即停。我在某公司经历过两轮“运动式治理”第一轮建了全量标准第二轮配了质量规则都因为发布流程不设防三个月后新表照样裸奔。检查卡点有没有生效一条 SQL 就够了SELECT c.table_name FROM core_table_register c LEFT JOIN metadata_owner m ON c.table_id m.table_id WHERE m.owner IS NULL OR m.owner ;返回空代表核心表都有人认领。这条 SQL 可以直接挂在 CI 上每次发布先跑一遍有返回值就 fail 掉把“必须填 owner”变成技术上的硬约束。这个最小闭环里最难的不是写规则是让人在新表上线前填三行信息。我后来把这三行信息做成建表工单的必填字段填不上工单提交不了事情才真正顺了。填三行必填信息比任何宣贯都有效。注意流程卡点必须由发布系统强制校验不能靠口头提醒。口头提醒在月底和年底永远失效因为大家都在赶进度。4. 数据治理框架落地避坑五条现象、原因与解法框架落地不是纯技术活是组织活。下面五条属于踩坑踩出来的经验每条按现象、原因、解决三段写可以直接对照自查。现象一框架评审会开完三个月后没有一件事落地。会上人人都说框架好会后该用临时表还是临时表该口径打架还是打架。原因很简单框架是管理模型不是操作手册直接拿来用缺了一层“动作翻译”。没有人把“加强元数据管理”这种话拆成“谁在哪个系统、做什么事、验收标准是什么”。解决方法是每个模块最多挑三件事写成“责任人、截止时间、所在系统、验收标准”四要素卡片。我一般把框架的六个模块翻译成十二张卡片挂在项目看板上。每张卡片就是一个动作不开工不画勾。框架里的每一句话落到行动卡片上才有意义。现象二质量规则配了一百多条第一周告警群直接爆炸。第二周全员屏蔽告警群第三周连生产事故告警都没人响应。原因有两个阈值靠拍脑袋规则没有分优先级。以为规则越多治理越到位实际是规则越多噪音越大最后核心告警和垃圾告警混在一起。解决方法是先选 10 张核心表每张表挂 3 到 5 条规则阈值用近 7 天历史数据算分位数来定不要靠感觉填 1.2 和 0.8规则先跑两周“观察模式”只记录不打扰人等波动基线摸清再打开告警。规则扩容的速度必须跟着团队处理告警的能力走。现象三认责 Excel 上有名字系统里没字段。质检报告显示“已认责”真出数据问题时打电话过去对方一脸茫然说“我没认过”。根因是责任写在 Excel 或框架文档里建表流程没有强校验治理系统的认责表和实际发布流程是两张皮。解决方法是把 owner 做成核心表元数据的必填字段写入发布卡点。用一条 SQL 查“哪些核心表 owner 为空”空值表直接不允许发布。责任只有落到系统字段里才叫认责否则就是写在纸上的模棱两可。我后来还把 owner 有效性做成每月自动校验和人事系统对一遍离职员工的表自动转给直属上级。现象四敏感数据识别用正则一把梭漏报和误报齐飞。用正则扫出来的“敏感表”里一半不是敏感数据另一半真正敏感的因为字段名叫 remark 漏掉了。原因很简单正则只认识字段名不认识数据本身。叫 phone 的字段可能存的是加密串叫 remark 的字段可能存了一整段明文手机号名字和数据是两回事。解决方法是字段名正则只做初筛。命中之后抽 20 到 50 条样本数据做人工复核复核结果回填到分级清单。形成“初筛—抽样—复核—回填”闭环。这个闭环里人工复核是必须的宁可多复核一百条不能漏掉一条真正敏感的数据。靠自动化一步到位在敏感识别这件事上不现实。现象五存量表刚治理完增量又陷入三不管。存量表的 owner、敏感级别人天收拾完了下个月新上线的表又是老样子。根因是治理动作没有前置到研发流程里盘点是一次性运动没有变成“新表上线必须通过”的日常关卡。解决方法是把三张必填信息——owner、敏感级别、保留周期——做成建表工单的必填项填不全不允许发版。再配一条 SQL 每周扫一次核心表登记表发现新表未登记就自动发提醒。增量管住了存量治理才有复利否则每个月都在重复同一个周期。5. 验证框架是否跑通用覆盖率、通过率与季度审计说话领导问“数据治理得怎么样了”不要抱着 PDF 去汇报拿三个数说话覆盖率、通过率、认责率。治理有没有效果不能靠感觉也不能靠玄学要靠趋势。5.1 三个核心指标怎么算覆盖率回答“该管的表管起来没有”通过率回答“管的表数据合格没有”认责率回答“出事的表找得到人没有”。三个指标配合使用缺一个都会产生盲区。指标含义计算口径健康线核心表覆盖率核心表纳入元数据和质量监控的比例已注册核心表数 / 核心表总数≥ 0.8质量规则通过率当日通过的规则数 / 总规则数按天统计次日回看≥ 0.95认责率核心表有有效 owner 的比例有 owner 且联系方式有效的核心表 / 核心表总数100%覆盖率的计算可以直接落到 SQL 上。假设核心表登记表叫 core_table_register元数据快照表叫 metadata_snapshotSELECT c.total_core_tables, COALESCE(m.registered, 0) AS registered_tables, ROUND(COALESCE(m.registered, 0)::numeric / c.total_core_tables, 4) AS coverage_rate FROM (SELECT COUNT(*) AS total_core_tables FROM core_table_register) c, (SELECT COUNT(DISTINCT table_id) AS registered FROM metadata_snapshot WHERE snapshot_date CURRENT_DATE AND quality_rules_enabled TRUE) m;这段 SQL 的逻辑是核心表的数量从资产登记表来真正纳入监控的数量从元数据快照表来两者相除就是覆盖率。注意 registered 的统计加了两个条件snapshot_date 是当天quality_rules_enabled 必须为真。有些表虽然被扫过但没挂质量规则不能算“已治理”。这三个指标每两周算一次画成趋势图。不追求一个月内全部达标但趋势必须往上。覆盖率下滑比通过率下滑更严重覆盖率下滑代表没人维护治理本身这是一切归零的开始。5.2 治理周报的固定三块治理周报不要写成流水账固定三个板块就够了异常项、遗留项、下周计划。模板可以照这个走板块内容示例异常项本周告警及处理结果dwd_order_detail 行数低于下限原因是调度延迟已重跑遗留项连续两周未关闭的事项20 张存量表未回填敏感级别责任人 A计划月底前完成下周计划3 到 5 件事不超过 5 件完成接口域分级、上线字段命名检查、复核 50 个敏感字段这个模板每周花半小时就能填完。管理层看异常项团队看遗留项自己看下周计划。千万不能写“本周无异常”数据治理里“无异常”通常等于“没监控”。如果连续三周异常项为空第一反应应该是检查监控任务是不是挂了而不是庆祝。5.3 季度抽查用审计验证框架还活着季度抽查是最后一道闸目的不是抓人是验证框架是不是还在真实运行。每季度随机抽 10 张核心表两个人交叉检查检查项固定如下检查对象检查内容通过标准表结构字段命名是否符合规范抽查 20 个字段违规不超过 2 个字段注释字段是否有业务注释100% 覆盖ownerowner 非空且联系方式有效100%敏感级别与分级清单一致100%血缘关键口径字段能否找到来源核心字段可追溯质量规则表上是否挂了至少 3 条规则100%保留周期有明确的归档和清理策略有书面策略抽查不合格的表做两件事锁写入权限改成只读同时发起整改工单。某团队曾经抽查发现一张核心表的 owner 填的是一个已离职同事连改三版名单都没发现因为认责表从没和人事系统同步过。这件事之后owner 有效性校验改成了每月自动跑一遍离职人员的表自动转给其直属上级不再等人来改。季度审计的结果直接决定下季度治理计划的优先级。某类问题连续两个季度出现说明对应的框架模块没有真正落地下一个季度就得把它挪到最前面。6. 进阶技巧把框架翻译成一张 RACI 矩阵让每页都有归属如果你把前面几步都做完大概会有一种感觉框架里的每一条都对但它不会自己动起来。我现在的习惯是拿到任何一份新的数据治理框架第一件事不是通读而是先把它翻译成一张 RACI 矩阵。RACI 四个字母的含义R 是 Responsible负责干活A 是 Accountable对结果拍板C 是 Consulted必须被咨询I 是 Informed知情即可。翻译规则有两条硬约束一行一项活动一列一个角色每个活动有且只能有一个 A。治理活动治理负责人数仓工程师业务分析师安全管理员数据标准制定ARCI元数据采集ARCI质量规则配置ARCI敏感数据复核ACIR生命周期归档ARCI季度审计ARIC这张表是我常用的简化版实际角色可以根据组织情况调整但原则不能动每行只能有一个 A。如果一行里出现两个 A这个活动大概率会互相观望最后没人拍板。矩阵做好之后贴在治理看板边上比贴框架原文有用得多。任何人接到任务看一眼矩阵就知道自己负责哪一行、要咨询谁、向谁汇报。还有一个配套动作给矩阵里的每个 A 配一条验收标准。比如“质量规则配置”这一行的验收标准是“核心表规则覆盖率 ≥ 0.8 且告警响应率 ≥ 0.9”。有了这条框架 PDF 里的每一段描述就都变成了可检查的动作。到这一步你手里已经有了第 1 章说的四张表角色表就是 RACI 矩阵规则表是质量规则库流程表是发布卡点指标表是覆盖率、通过率、认责率。我带团队的前两年拿到框架只会从头读到尾读完就忘。后来改成先翻译矩阵、再拆动作才真正治住了一次又一次的返工。现在抽屉里还有几份没读完的框架 PDF但每一份都对应着墙上至少一张矩阵和十几张动作卡片。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取