简介《企业数字化转型数据治理解决方案》是一份面向企业CIO/CDO、数据管理岗与数字化推进人员的119页PPT方案可用于内部汇报、治理体系搭建与团队培训。内容以DAMA数据治理参考框架为主线依次梳理为什么进行数据治理、与数字化转型的关系、治理主要内容与实施路径并剖析数据孤岛、质量参差、通道不畅、职责缺位等典型问题。资源包体积精简共1个pptx文件约10.85MB页面结构完整既可直接放映也便于拆解复用与二次编辑。目前已有74人学习下载。读者可获取一套从价值认知到落地执行的完整治理叙事框架既有数据如石油、数据如血液等通俗类比帮助建立共识也有数据资产、管理组织、制度流程与工具管控的体系化梳理便于快速形成汇报提纲、制定治理路线图或直接用作数据治理培训课件。1. 119页PPT背后的真问题数据治理不是买一套工具一家年营收几十亿的制造企业2021年上线了数据中台两年后报表还在打架财务口径的活跃客户数比销售少两万库存金额三个系统给出三个答案。服务器没宕过任务没断过问题出在没人拍板客户到底以哪个系统为准、由谁负责改。这份119页的PPT第一章讲的就是这件事——三分技术、七分管理、十二分数据技术只是水面上的冰山一角真正决定转型成败的是水下的组织、标准与认责机制。整套材料按五章推进为什么治理、治理与数字化转型什么关系、DAMA参考模型怎么用、治理具体包含哪些内容、以及怎么实施。它不绑定任何厂商工具讲的是章法和顺序。适合三类人被口径和主数据折磨的数据平台开发、刚接手数据治理的CIO/CDO、以及需要把治理讲给业务听懂的数据分析师。读完至少要能回答一个问题下周一上班治理的第一件事该做什么。2. 从DAMA数据治理车轮图拆出可落地的治理域DAMA的车轮图是这个领域引用最多的一张图也是最容易被误读的一张。很多人把它当成十一个并列模块挨个立项结果一年做了六件事一件都没闭环。理解轮轴与辐条的关系比背下那几个名词重要得多。2.1 车轮图的两层结构轮轴上的治理与十个知识域车轮图的轮轴位置是数据治理其余十个知识域围绕它分布数据架构、数据建模与设计、数据存储与操作、数据安全、数据集成与互操作、文档与内容管理、参考数据与主数据、数据仓库与商务智能、元数据、数据质量。治理不在轮子上跟它们并列它是穿过所有辐条的轴——没有轴辐条转不起来只有轴没有辐条车子也走不动。外围还有一圈环境要素目标与原则、组织与文化、角色与职责、交付物、工具、活动、技术。实际项目里最容易漏的是交付物和角色与职责这两项。数据标准文档写完了放网盘没有评审记录、没有生效日期、没有责任人三个月后就和现状对不上。这解释了一个常见现象同样一套元数据采集工具A公司用出了数据地图B公司只得到一堆无人看的截图。差别在车轮外围——有没有人认领这些元数据有没有流程保证它随变更更新。提示把轮轴理解成建章立制的职能而不是一个项目是抓顺序的关键。治理先定规则其他域再按规则执行。2.2 十个治理域按企业现状排优先级十个域不可能同时开工。判断先做哪个看的不是理论重要性而是当前最疼的地方在哪里、以及哪个域能最快产出可被业务看见的成果。下面这张表是常见的排序依据。治理域典型症状首个可交付物什么情况下优先做元数据不知道仓库里有什么表、字段含义靠口口相传数据资产目录表字段注释责任人几乎总是第一个成本低、见效快数据质量报表口径反复被质疑但说不清错在哪核心表质量规则集与质量分看板已经上了数仓、业务天天对不上数参考数据与主数据客户、物料、组织编码各系统一套单一主数据源与分发接口多系统集成、跨部门对账困难数据标准同一指标十个SQL十种算法指标字典 命名规范指标平台或自助BI建设前数据安全谁都能查全量客户手机号分级分类清单 脱敏规则有合规审计或客户数据体量大数据架构每来一个需求就新建一张宽表分层规范ODS/DWD/DWS/ADS数仓规模过千张表文档与内容管理合同、工单散在共享盘查不到也用不上非结构化数据目录与标签体系有大量扫描件、PDF、工单文本数据集成抽取任务靠人肉排期失败无人知集成任务登记表 调度依赖图数据源超过十个数据仓库与BI指标口径不统一报表重复开发指标唯一口径 复用率统计报表数量失控时数据建模维度模型随意改历史数据无法追溯核心主题域模型与变更记录模型重构或中台建设期这张表的用法是先看第二列有没有中招再看第四列的条件是否成立。元数据与数据质量通常打头阵因为它们对业务干扰最小、产出物最直观主数据与数据标准动的是流程和权限需要高层背书宜放在治理机制跑顺之后。2.3 治理域落到组织、制度、流程三件套DGI对数据治理的定义里有一串问号谁Who能根据什么信息、在什么时间When和情况Where下、用什么方法How、采取什么行动What。这串问号翻译成可执行的物件就是三件套认责矩阵、制度清单、治理流程。认责矩阵最容易被写成PPT里的一张漂亮表格然后束之高阁。更实用的做法是把它放进代码仓库和表结构一起版本管理变更走合并请求评审。下面是一份用YAML描述的认责与规则声明采集脚本读它、质量任务读它、血缘解析也读它。# data_ownership.yaml —— 认责矩阵进仓库变更走评审避免和现状脱节 domains: customer: # 主题域客户 owner: role_crm_business_owner # 数据所有者对口径和标准拍板 steward: role_data_steward_crm # 数据管家对质量结果负责 systems: [CRM, OMS, BILLING] # 该域的权威系统清单 tables: - dwd_customer_df - dim_customer_level quality_rules: # 规则与阈值就地声明供调度任务读取 - {field: cust_id, rule: not_null, threshold: 0.999} - {field: cust_id, rule: unique, threshold: 1.0} - {field: cust_level, rule: enum, values: [01,02,03,04], threshold: 0.99}字段含义需要说清楚owner是业务侧的决策角色负责客户的定义是什么steward是执行角色负责把质量拉回阈值systems决定冲突时以谁为准threshold是告警阈值而非目标值一般取近三个月实际值的95分位再往上一档定得太高会天天误报定得太低等于没有约束。用岗位编码而不是人名是为了人员轮岗时文件不用重写。制度清单不用多五到八份就够数据标准管理办法、元数据管理办法、数据质量管理办法、主数据管理办法、数据安全分级分类办法、数据认责与考核办法。每份制度只回答三件事——谁做、按什么频率做、做不好怎么办。超过十页的制度基本没人看落不成动作。流程则围绕变更跑新增表或字段提交申请、评审命名与标准符合性、通过后写入标准库、采集任务自动纳入、质量规则同步生成。这条链路一旦跑顺治理就从运动式变成日常化。3. 元数据与数据标准落地从采集脚本到数据资产目录治理讲了半天如果最后没有一份能被查询的资产目录业务仍然感受不到变化。这一章把元数据采集、变更比对、标准校验和血缘四条线串成一个最小可用实现。3.1 元数据采集从 information_schema 到资产目录技术元数据不需要额外的商业工具也能起步关系型库的information_schema就能给出表名、字段名、类型和注释。下面这段SQL把库表级元数据一次性拉平落地成资产目录的底表。-- 采集库表级元数据落到 ods_meta_column 快照表按批次号区分 SELECT t.TABLE_SCHEMA AS db_name, t.TABLE_NAME AS table_name, t.TABLE_COMMENT AS table_comment, t.TABLE_ROWS AS row_estimate, -- InnoDB 下的行数估算值不是精确值 t.UPDATE_TIME AS last_update_time, c.COLUMN_NAME AS column_name, c.ORDINAL_POSITION AS col_index, c.DATA_TYPE AS data_type, c.COLUMN_TYPE AS column_type, -- 含长度与无符号信息判断变更更准 c.IS_NULLABLE AS is_nullable, c.COLUMN_COMMENT AS column_comment FROM information_schema.TABLES t JOIN information_schema.COLUMNS c ON c.TABLE_SCHEMA t.TABLE_SCHEMA AND c.TABLE_NAME t.TABLE_NAME WHERE t.TABLE_SCHEMA NOT IN (mysql,information_schema,performance_schema,sys) ORDER BY t.TABLE_SCHEMA, t.TABLE_NAME, c.ORDINAL_POSITION;几个参数要提前想清楚否则后面会返工。row_estimate在 InnoDB 里是采样估算用它做容量排名可以用它做行数考核会翻车真要精确值得走COUNT(*)或统计信息表。UPDATE_TIME对只读表可能是NULL判断数据新鲜度更可靠的做法是读取业务表里的分区字段或时间戳字段。另外要注意这条SQL拿到的是当前快照治理要的是变化所以采完必须打上批次号写入ods_meta_column历史快照是变更审计的唯一依据。采集频率一般是每天一次重点是核心库和大表对上千张表的仓库全量采集单次通常在几分钟量级不必做成实时。业务元数据的采集要另走一条路——表注释和字段注释的完备率本身就是一个治理指标缺失的字段应当自动生成待办派给数据管家而不是人工去催。3.2 变更比对与数据标准校验脚本有了快照第二天的比对就有了抓手。下面这段SQL把新增列、删除列和类型变更三类事件摘出来作为标准评审的输入。-- 与上一批次快照比对捞出结构变更交给标准评审 SELECT cur.table_name, cur.column_name, pre.data_type AS old_type, cur.data_type AS new_type, CASE WHEN pre.column_name IS NULL THEN ADD WHEN cur.column_name IS NULL THEN DROP WHEN pre.data_type cur.data_type THEN TYPE_CHANGE ELSE UNCHANGED END AS change_type FROM ods_meta_column cur LEFT JOIN ods_meta_column pre ON pre.table_name cur.table_name AND pre.column_name cur.column_name AND pre.batch_date DATE_SUB(cur.batch_date, INTERVAL 1 DAY) -- 上一批次 WHERE cur.batch_date CURRENT_DATE AND (pre.column_name IS NULL OR cur.data_type pre.data_type);这段逻辑的关键在比对维度以「表名字段名」为业务主键做左连接右侧为空的即新增类型不等即变更。若要捕捉删除把左右表位置对调再查一次或者用全连接MySQL不支持可用UNION拼。batch_date一定要有索引否则大表比对会扫全量。实际跑的时候建议顺手过滤掉临时表和临时字段比如以tmp_、bak_结尾的对象否则每天都会报一堆噪音变更。结构变更过了关再看内容层面的标准符合性。命名规范、字段长度、码值域这几类约束用脚本判最省事。import re import pandas as pd # 数据标准的三条硬约束分层命名、字段名规范、码值域 TABLE_PATTERN re.compile(r^(ods|dwd|dws|ads|dim)_[a-z0-9](_[a-z0-9])*$) NAME_PATTERN re.compile(r^[a-z][a-z0-9_]{2,30}$) CODE_SET {cust_level: {01, 02, 03, 04}} # 与标准库保持同源 def check_std(df: pd.DataFrame) - pd.DataFrame: issues [] for _, r in df.iterrows(): if not TABLE_PATTERN.match(r[table_name]): issues.append((r[table_name], r[column_name], 表名不符合分层前缀规范)) if not NAME_PATTERN.match(r[column_name]): issues.append((r[table_name], r[column_name], 字段名含大写或长度越界)) # 码值域校验依赖样本值样本值在采集阶段一并抓取 if r[column_name] in CODE_SET and r[sample_value] not in CODE_SET[r[column_name]]: issues.append((r[table_name], r[column_name], f码值越界{r[sample_value]})) return pd.DataFrame(issues, columns[table_name, column_name, reason]) # 用法check_std(meta_df).to_csv(std_issues.csv, indexFalse)说明几点正则里的分层前缀ods/dwd/dws/ads/dim要和公司实际分层对齐不能照抄字段名限制在3到31个字符之间是为了兼容多数数据库的大小写折叠行为全小写是硬要求。码值集合不要硬编码在脚本里应该从标准库的码值表读否则标准更新时脚本就成了新的孤岛。样本值抓取要注意脱敏手机号、身份证这类字段只存格式特征不存原值。3.3 表级血缘与数据地图的最小实现目录有了、标准有了还差一条这张表从哪来、到哪去。血缘分两种做法解析ETL脚本或SQL日志拿到表级依赖以及在调度系统里登记任务的上下游。前者覆盖面广、准确率一般后者准确但依赖人工维护。常见做法是两条腿走调度任务自动上报上下游关系到一张meta_lineage表同时用SQL解析补齐视图和临时脚本的依赖。表级血缘够用时不必强求字段级字段级血缘的维护成本往往是表级的五到十倍而业务真正高频问的是这个指标取自哪几张表不是这个字段经过哪几层转换。校验血缘有没有失真可以用一个笨办法随机抽十张核心表让数据管家手工比对一次。命中率低于八成说明自动采集的口径有问题多半是把带变量的动态SQL漏掉了。4. 数据质量规则与非结构化数据治理的工程化实现标准是应该长什么样质量是实际长什么样。两件事必须配套缺了前者质量告警没有判据缺了后者标准只是文档。4.1 数据质量六类规则与SQL模板业界常用的维度包括完整性、唯一性、准确性、一致性、及时性、有效性。落到SQL上前几个维度都能用一条聚合查询算出来。-- 一次扫描输出非空率、唯一率、值域合规率三个指标 SELECT COUNT(*) AS total_cnt, SUM(CASE WHEN cust_id IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS null_rate, 1 - COUNT(DISTINCT cust_id) / COUNT(*) AS dup_rate, SUM(CASE WHEN cust_level IN (01,02,03,04) THEN 1 ELSE 0 END) / COUNT(*) AS valid_rate, MAX(dt) AS max_partition_dt FROM dwd_customer_df WHERE dt 2024-05-02; -- 限定当日分区避免全表扫指标含义与阈值设定需要区分对待。null_rate是完整性主键和必填字段应贴近0允许值一般设在0.1%以内dup_rate是唯一性主键必须为0维度表可以放宽valid_rate是有效性反映码值越界比例通常要求99%以上。max_partition_dt用来算及时性——与调度计划时间差超过两小时就应当告警而不是等到业务来投诉。跑批写法上有两点经验。第一规则任务不要直接压在生产库上走从库或数仓副本单条规则加上分区过滤和超时控制。第二把每条规则的扫描行数、耗时一起落库规则数量涨到几百条时这些指标是判断哪条规则在拖慢调度的唯一依据。跨系统的一致性校验更麻烦因为要跨库比对。常见做法是每天把两边的关键字段以主键为粒度抽到一张对账表再跑差集-- 一致性对账CRM 与数仓的客户等级存在差异的行 SELECT c.cust_id, c.cust_level AS crm_level, d.cust_level AS dwd_level FROM ods_crm_customer c JOIN dwd_customer_df d ON d.cust_id c.cust_id AND d.dt 2024-05-02 WHERE c.cust_level d.cust_level;差集结果别只做统计要能下钻到具体客户编号业务才愿意跟进。对账表保留最近30天就能看出差异是持续存在的存量问题还是某天上线后的新增问题。4.2 质量分计算与告警分级单指标告警多了会麻木把多个维度加权成一个质量分更便于向上汇报。公式可以很简单满分100每个维度按偏离阈值的程度扣分权重按业务影响分配。维度权重阈值偏离扣分告警等级完整性30%空值率 ≤ 0.1%每超0.1个百分点扣5分严重唯一性25%重复率 0出现即扣20分严重有效性20%合规率 ≥ 99%每低1个百分点扣3分一般及时性15%延迟 ≤ 2小时每超1小时扣5分一般一致性10%差异率 ≤ 0.5%每超0.5个百分点扣2分提示权重不是拍脑袋定的参照标准是这张表挂了多少个下游应用。下游越多权重越高。质量分低于85触发部门内通报低于70升级到数据治理委员会——这条升级路径必须写进制度否则告警永远停在邮件里没人管。规则上线也别一次全开。先选五到十张核心表跑两周观察误报率把阈值调到合理区间再逐步扩表。误报太多的规则宁可先关掉带着噪音上线的监控最后会被所有人静音。4.3 非结构化数据治理目录、抽取、标签三层合同、工单、扫描件这类非结构化数据治理思路和技术元数据不同。建议按三层推进目录层先回答有哪些文件、归谁管、什么权限抽取层把关键要素变成结构化字段标签层再做分类与检索。跳过前两层直接上全文检索往往得到一堆没人维护的索引。抽取层用 Python 起步最快PDF 类合同可以用 pdfplumber 配合正则抽要素import re import pdfplumber PATTERNS { contract_no: re.compile(r合同编号[:]\s*([A-Z0-9\-]{6,20})), amount: re.compile(r合同金额[:]\s*([0-9,]\.?\d*)\s*元), sign_date: re.compile(r签订日期[:]\s*(\d{4})[-/年](\d{1,2})[-/月](\d{1,2})), } def extract(path: str) - dict: doc {file: path} with pdfplumber.open(path) as pdf: text \n.join((p.extract_text() or ) for p in pdf.pages) for field, pat in PATTERNS.items(): m pat.search(text) doc[field] m.group(1).replace(,, ) if m else None doc[text_len] len(text) # 文本极短说明是扫描件应转 OCR 通道 return doc逻辑说明先整篇抽文本再用预编译正则匹配要素PATTERNS用字典声明便于按文件类型切换模板采购合同和劳动合同的字段集本来就不一样。text_len是个便宜的判别器——正常合同文本长度在几千字符量级低于200基本可以判定为纯图片扫描件走OCR通道而不是反复调正则。金额字段抽取时要去掉千分位逗号否则后续入库会变成字符串。真正决定非结构化治理成败的是元数据不是抽取准确率。每份文件至少要登记文件类型、所属业务域、责任人、密级、保留期限、关联的业务对象比如合同对应的客户编号。有了这几项即使抽取准确率只有七成业务也能通过客户编号文件类型快速定位到目标文件没有这几项准确率做到九成也依然是个黑盒。5. 数据治理流程与组织机制成熟度评估与实施路线治理推进到一定阶段必须回答我们现在到什么水平、下一步往哪走。空泛地回答还在建设中没有意义需要一个能打分、能对比的评估框架。5.1 DAMA 成熟度评估怎么打分按能力成熟度模型把每个治理域分成五级评估项控制在八到十个每个域给出1到5分。打分时不要闭门造车方法上通常每个域准备三个证据问题有没有制度文件、有没有执行记录、有没有量化结果。说不出执行记录和量化结果的一律按低一级算。等级特征判定证据1 初始靠个人经验出问题临时处理无文档无固定责任人2 可重复有非正式做法能重复但未成文有脚本或表格换人就断3 定义有制度、有流程、有明确角色制度发布流程有记录4 管理有量化指标并能持续监控质量分看板、变更审计日志5 优化指标驱动持续改进有阈值调优记录和复盘机制评估的用途不是打分好看而是找出定义级到管理级之间的断点。多数企业的元数据停在3级因为有了目录但没有变更监控数据质量停在2级因为有校验脚本但没有质量分。这两个断点对应的投入并不大收益却很直接。5.2 分阶段路线与里程碑实施节奏建议按三阶段推进每阶段四到六个月不要试图一次性覆盖全部治理域。阶段重点关键交付物验收指标第一阶段元数据与数据标准资产目录、命名规范、标准库核心表注释完备率 ≥ 90%第二阶段数据质量与主数据质量规则集、质量分看板、主数据源核心表质量分 ≥ 85第三阶段数据安全与资产运营分级分类清单、脱敏规则、资产服务接口敏感字段100%分级目录月活达标第一阶段千万别碰指标体系那是最容易扯皮的部分。先把仓库里有什么讲清楚业务对治理的信任感就是从一份准确的目录开始的。第二阶段才动口径而且要有业务方在场拍板。5.3 一个具体技巧先锁定一份黄金主数据表如果只能做一件事我一般建议先锁定一份客户主数据表并且把它做成黄金记录一个客户一行来源字段带血缘标记冲突时按权威系统优先级取值所有下游分析强制走这张表。建表的取数逻辑可以写成优先级规则而不是简单的UNION-- 黄金记录按权威系统优先级取客户属性CRM 优先于 OMSOMS 优先于计费 SELECT cust_id, COALESCE(crm.cust_name, oms.cust_name, bill.cust_name) AS cust_name, COALESCE(crm.cust_level, oms.cust_level, bill.cust_level) AS cust_level, COALESCE(crm.mobile_masked, oms.mobile_masked) AS mobile_masked, CASE WHEN crm.cust_id IS NOT NULL THEN CRM WHEN oms.cust_id IS NOT NULL THEN OMS ELSE BILLING END AS primary_source -- 记录本次取值来自哪个系统便于回溯 FROM dim_cust_crm crm FULL JOIN dim_cust_oms oms ON oms.cust_id crm.cust_id FULL JOIN dim_cust_bill bill ON bill.cust_id COALESCE(crm.cust_id, oms.cust_id);COALESCE的顺序就是权威优先级改优先级只需要调整字段顺序不用改下游。primary_source这一列看起来多余实际是对账时的救命字段——业务问这个客户等级为什么变了查一下来源系统切换记录就能解释。这张表上线后下游所有报表统一指向它口径争议会立刻少一大半治理团队也终于有了第一个可以拿出去讲的成果。本文还有配套的精品资源点击获取
DAMA数据治理落地：元数据、数据质量与主数据实施路线
简介《企业数字化转型数据治理解决方案》是一份面向企业CIO/CDO、数据管理岗与数字化推进人员的119页PPT方案可用于内部汇报、治理体系搭建与团队培训。内容以DAMA数据治理参考框架为主线依次梳理为什么进行数据治理、与数字化转型的关系、治理主要内容与实施路径并剖析数据孤岛、质量参差、通道不畅、职责缺位等典型问题。资源包体积精简共1个pptx文件约10.85MB页面结构完整既可直接放映也便于拆解复用与二次编辑。目前已有74人学习下载。读者可获取一套从价值认知到落地执行的完整治理叙事框架既有数据如石油、数据如血液等通俗类比帮助建立共识也有数据资产、管理组织、制度流程与工具管控的体系化梳理便于快速形成汇报提纲、制定治理路线图或直接用作数据治理培训课件。1. 119页PPT背后的真问题数据治理不是买一套工具一家年营收几十亿的制造企业2021年上线了数据中台两年后报表还在打架财务口径的活跃客户数比销售少两万库存金额三个系统给出三个答案。服务器没宕过任务没断过问题出在没人拍板客户到底以哪个系统为准、由谁负责改。这份119页的PPT第一章讲的就是这件事——三分技术、七分管理、十二分数据技术只是水面上的冰山一角真正决定转型成败的是水下的组织、标准与认责机制。整套材料按五章推进为什么治理、治理与数字化转型什么关系、DAMA参考模型怎么用、治理具体包含哪些内容、以及怎么实施。它不绑定任何厂商工具讲的是章法和顺序。适合三类人被口径和主数据折磨的数据平台开发、刚接手数据治理的CIO/CDO、以及需要把治理讲给业务听懂的数据分析师。读完至少要能回答一个问题下周一上班治理的第一件事该做什么。2. 从DAMA数据治理车轮图拆出可落地的治理域DAMA的车轮图是这个领域引用最多的一张图也是最容易被误读的一张。很多人把它当成十一个并列模块挨个立项结果一年做了六件事一件都没闭环。理解轮轴与辐条的关系比背下那几个名词重要得多。2.1 车轮图的两层结构轮轴上的治理与十个知识域车轮图的轮轴位置是数据治理其余十个知识域围绕它分布数据架构、数据建模与设计、数据存储与操作、数据安全、数据集成与互操作、文档与内容管理、参考数据与主数据、数据仓库与商务智能、元数据、数据质量。治理不在轮子上跟它们并列它是穿过所有辐条的轴——没有轴辐条转不起来只有轴没有辐条车子也走不动。外围还有一圈环境要素目标与原则、组织与文化、角色与职责、交付物、工具、活动、技术。实际项目里最容易漏的是交付物和角色与职责这两项。数据标准文档写完了放网盘没有评审记录、没有生效日期、没有责任人三个月后就和现状对不上。这解释了一个常见现象同样一套元数据采集工具A公司用出了数据地图B公司只得到一堆无人看的截图。差别在车轮外围——有没有人认领这些元数据有没有流程保证它随变更更新。提示把轮轴理解成建章立制的职能而不是一个项目是抓顺序的关键。治理先定规则其他域再按规则执行。2.2 十个治理域按企业现状排优先级十个域不可能同时开工。判断先做哪个看的不是理论重要性而是当前最疼的地方在哪里、以及哪个域能最快产出可被业务看见的成果。下面这张表是常见的排序依据。治理域典型症状首个可交付物什么情况下优先做元数据不知道仓库里有什么表、字段含义靠口口相传数据资产目录表字段注释责任人几乎总是第一个成本低、见效快数据质量报表口径反复被质疑但说不清错在哪核心表质量规则集与质量分看板已经上了数仓、业务天天对不上数参考数据与主数据客户、物料、组织编码各系统一套单一主数据源与分发接口多系统集成、跨部门对账困难数据标准同一指标十个SQL十种算法指标字典 命名规范指标平台或自助BI建设前数据安全谁都能查全量客户手机号分级分类清单 脱敏规则有合规审计或客户数据体量大数据架构每来一个需求就新建一张宽表分层规范ODS/DWD/DWS/ADS数仓规模过千张表文档与内容管理合同、工单散在共享盘查不到也用不上非结构化数据目录与标签体系有大量扫描件、PDF、工单文本数据集成抽取任务靠人肉排期失败无人知集成任务登记表 调度依赖图数据源超过十个数据仓库与BI指标口径不统一报表重复开发指标唯一口径 复用率统计报表数量失控时数据建模维度模型随意改历史数据无法追溯核心主题域模型与变更记录模型重构或中台建设期这张表的用法是先看第二列有没有中招再看第四列的条件是否成立。元数据与数据质量通常打头阵因为它们对业务干扰最小、产出物最直观主数据与数据标准动的是流程和权限需要高层背书宜放在治理机制跑顺之后。2.3 治理域落到组织、制度、流程三件套DGI对数据治理的定义里有一串问号谁Who能根据什么信息、在什么时间When和情况Where下、用什么方法How、采取什么行动What。这串问号翻译成可执行的物件就是三件套认责矩阵、制度清单、治理流程。认责矩阵最容易被写成PPT里的一张漂亮表格然后束之高阁。更实用的做法是把它放进代码仓库和表结构一起版本管理变更走合并请求评审。下面是一份用YAML描述的认责与规则声明采集脚本读它、质量任务读它、血缘解析也读它。# data_ownership.yaml —— 认责矩阵进仓库变更走评审避免和现状脱节 domains: customer: # 主题域客户 owner: role_crm_business_owner # 数据所有者对口径和标准拍板 steward: role_data_steward_crm # 数据管家对质量结果负责 systems: [CRM, OMS, BILLING] # 该域的权威系统清单 tables: - dwd_customer_df - dim_customer_level quality_rules: # 规则与阈值就地声明供调度任务读取 - {field: cust_id, rule: not_null, threshold: 0.999} - {field: cust_id, rule: unique, threshold: 1.0} - {field: cust_level, rule: enum, values: [01,02,03,04], threshold: 0.99}字段含义需要说清楚owner是业务侧的决策角色负责客户的定义是什么steward是执行角色负责把质量拉回阈值systems决定冲突时以谁为准threshold是告警阈值而非目标值一般取近三个月实际值的95分位再往上一档定得太高会天天误报定得太低等于没有约束。用岗位编码而不是人名是为了人员轮岗时文件不用重写。制度清单不用多五到八份就够数据标准管理办法、元数据管理办法、数据质量管理办法、主数据管理办法、数据安全分级分类办法、数据认责与考核办法。每份制度只回答三件事——谁做、按什么频率做、做不好怎么办。超过十页的制度基本没人看落不成动作。流程则围绕变更跑新增表或字段提交申请、评审命名与标准符合性、通过后写入标准库、采集任务自动纳入、质量规则同步生成。这条链路一旦跑顺治理就从运动式变成日常化。3. 元数据与数据标准落地从采集脚本到数据资产目录治理讲了半天如果最后没有一份能被查询的资产目录业务仍然感受不到变化。这一章把元数据采集、变更比对、标准校验和血缘四条线串成一个最小可用实现。3.1 元数据采集从 information_schema 到资产目录技术元数据不需要额外的商业工具也能起步关系型库的information_schema就能给出表名、字段名、类型和注释。下面这段SQL把库表级元数据一次性拉平落地成资产目录的底表。-- 采集库表级元数据落到 ods_meta_column 快照表按批次号区分 SELECT t.TABLE_SCHEMA AS db_name, t.TABLE_NAME AS table_name, t.TABLE_COMMENT AS table_comment, t.TABLE_ROWS AS row_estimate, -- InnoDB 下的行数估算值不是精确值 t.UPDATE_TIME AS last_update_time, c.COLUMN_NAME AS column_name, c.ORDINAL_POSITION AS col_index, c.DATA_TYPE AS data_type, c.COLUMN_TYPE AS column_type, -- 含长度与无符号信息判断变更更准 c.IS_NULLABLE AS is_nullable, c.COLUMN_COMMENT AS column_comment FROM information_schema.TABLES t JOIN information_schema.COLUMNS c ON c.TABLE_SCHEMA t.TABLE_SCHEMA AND c.TABLE_NAME t.TABLE_NAME WHERE t.TABLE_SCHEMA NOT IN (mysql,information_schema,performance_schema,sys) ORDER BY t.TABLE_SCHEMA, t.TABLE_NAME, c.ORDINAL_POSITION;几个参数要提前想清楚否则后面会返工。row_estimate在 InnoDB 里是采样估算用它做容量排名可以用它做行数考核会翻车真要精确值得走COUNT(*)或统计信息表。UPDATE_TIME对只读表可能是NULL判断数据新鲜度更可靠的做法是读取业务表里的分区字段或时间戳字段。另外要注意这条SQL拿到的是当前快照治理要的是变化所以采完必须打上批次号写入ods_meta_column历史快照是变更审计的唯一依据。采集频率一般是每天一次重点是核心库和大表对上千张表的仓库全量采集单次通常在几分钟量级不必做成实时。业务元数据的采集要另走一条路——表注释和字段注释的完备率本身就是一个治理指标缺失的字段应当自动生成待办派给数据管家而不是人工去催。3.2 变更比对与数据标准校验脚本有了快照第二天的比对就有了抓手。下面这段SQL把新增列、删除列和类型变更三类事件摘出来作为标准评审的输入。-- 与上一批次快照比对捞出结构变更交给标准评审 SELECT cur.table_name, cur.column_name, pre.data_type AS old_type, cur.data_type AS new_type, CASE WHEN pre.column_name IS NULL THEN ADD WHEN cur.column_name IS NULL THEN DROP WHEN pre.data_type cur.data_type THEN TYPE_CHANGE ELSE UNCHANGED END AS change_type FROM ods_meta_column cur LEFT JOIN ods_meta_column pre ON pre.table_name cur.table_name AND pre.column_name cur.column_name AND pre.batch_date DATE_SUB(cur.batch_date, INTERVAL 1 DAY) -- 上一批次 WHERE cur.batch_date CURRENT_DATE AND (pre.column_name IS NULL OR cur.data_type pre.data_type);这段逻辑的关键在比对维度以「表名字段名」为业务主键做左连接右侧为空的即新增类型不等即变更。若要捕捉删除把左右表位置对调再查一次或者用全连接MySQL不支持可用UNION拼。batch_date一定要有索引否则大表比对会扫全量。实际跑的时候建议顺手过滤掉临时表和临时字段比如以tmp_、bak_结尾的对象否则每天都会报一堆噪音变更。结构变更过了关再看内容层面的标准符合性。命名规范、字段长度、码值域这几类约束用脚本判最省事。import re import pandas as pd # 数据标准的三条硬约束分层命名、字段名规范、码值域 TABLE_PATTERN re.compile(r^(ods|dwd|dws|ads|dim)_[a-z0-9](_[a-z0-9])*$) NAME_PATTERN re.compile(r^[a-z][a-z0-9_]{2,30}$) CODE_SET {cust_level: {01, 02, 03, 04}} # 与标准库保持同源 def check_std(df: pd.DataFrame) - pd.DataFrame: issues [] for _, r in df.iterrows(): if not TABLE_PATTERN.match(r[table_name]): issues.append((r[table_name], r[column_name], 表名不符合分层前缀规范)) if not NAME_PATTERN.match(r[column_name]): issues.append((r[table_name], r[column_name], 字段名含大写或长度越界)) # 码值域校验依赖样本值样本值在采集阶段一并抓取 if r[column_name] in CODE_SET and r[sample_value] not in CODE_SET[r[column_name]]: issues.append((r[table_name], r[column_name], f码值越界{r[sample_value]})) return pd.DataFrame(issues, columns[table_name, column_name, reason]) # 用法check_std(meta_df).to_csv(std_issues.csv, indexFalse)说明几点正则里的分层前缀ods/dwd/dws/ads/dim要和公司实际分层对齐不能照抄字段名限制在3到31个字符之间是为了兼容多数数据库的大小写折叠行为全小写是硬要求。码值集合不要硬编码在脚本里应该从标准库的码值表读否则标准更新时脚本就成了新的孤岛。样本值抓取要注意脱敏手机号、身份证这类字段只存格式特征不存原值。3.3 表级血缘与数据地图的最小实现目录有了、标准有了还差一条这张表从哪来、到哪去。血缘分两种做法解析ETL脚本或SQL日志拿到表级依赖以及在调度系统里登记任务的上下游。前者覆盖面广、准确率一般后者准确但依赖人工维护。常见做法是两条腿走调度任务自动上报上下游关系到一张meta_lineage表同时用SQL解析补齐视图和临时脚本的依赖。表级血缘够用时不必强求字段级字段级血缘的维护成本往往是表级的五到十倍而业务真正高频问的是这个指标取自哪几张表不是这个字段经过哪几层转换。校验血缘有没有失真可以用一个笨办法随机抽十张核心表让数据管家手工比对一次。命中率低于八成说明自动采集的口径有问题多半是把带变量的动态SQL漏掉了。4. 数据质量规则与非结构化数据治理的工程化实现标准是应该长什么样质量是实际长什么样。两件事必须配套缺了前者质量告警没有判据缺了后者标准只是文档。4.1 数据质量六类规则与SQL模板业界常用的维度包括完整性、唯一性、准确性、一致性、及时性、有效性。落到SQL上前几个维度都能用一条聚合查询算出来。-- 一次扫描输出非空率、唯一率、值域合规率三个指标 SELECT COUNT(*) AS total_cnt, SUM(CASE WHEN cust_id IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS null_rate, 1 - COUNT(DISTINCT cust_id) / COUNT(*) AS dup_rate, SUM(CASE WHEN cust_level IN (01,02,03,04) THEN 1 ELSE 0 END) / COUNT(*) AS valid_rate, MAX(dt) AS max_partition_dt FROM dwd_customer_df WHERE dt 2024-05-02; -- 限定当日分区避免全表扫指标含义与阈值设定需要区分对待。null_rate是完整性主键和必填字段应贴近0允许值一般设在0.1%以内dup_rate是唯一性主键必须为0维度表可以放宽valid_rate是有效性反映码值越界比例通常要求99%以上。max_partition_dt用来算及时性——与调度计划时间差超过两小时就应当告警而不是等到业务来投诉。跑批写法上有两点经验。第一规则任务不要直接压在生产库上走从库或数仓副本单条规则加上分区过滤和超时控制。第二把每条规则的扫描行数、耗时一起落库规则数量涨到几百条时这些指标是判断哪条规则在拖慢调度的唯一依据。跨系统的一致性校验更麻烦因为要跨库比对。常见做法是每天把两边的关键字段以主键为粒度抽到一张对账表再跑差集-- 一致性对账CRM 与数仓的客户等级存在差异的行 SELECT c.cust_id, c.cust_level AS crm_level, d.cust_level AS dwd_level FROM ods_crm_customer c JOIN dwd_customer_df d ON d.cust_id c.cust_id AND d.dt 2024-05-02 WHERE c.cust_level d.cust_level;差集结果别只做统计要能下钻到具体客户编号业务才愿意跟进。对账表保留最近30天就能看出差异是持续存在的存量问题还是某天上线后的新增问题。4.2 质量分计算与告警分级单指标告警多了会麻木把多个维度加权成一个质量分更便于向上汇报。公式可以很简单满分100每个维度按偏离阈值的程度扣分权重按业务影响分配。维度权重阈值偏离扣分告警等级完整性30%空值率 ≤ 0.1%每超0.1个百分点扣5分严重唯一性25%重复率 0出现即扣20分严重有效性20%合规率 ≥ 99%每低1个百分点扣3分一般及时性15%延迟 ≤ 2小时每超1小时扣5分一般一致性10%差异率 ≤ 0.5%每超0.5个百分点扣2分提示权重不是拍脑袋定的参照标准是这张表挂了多少个下游应用。下游越多权重越高。质量分低于85触发部门内通报低于70升级到数据治理委员会——这条升级路径必须写进制度否则告警永远停在邮件里没人管。规则上线也别一次全开。先选五到十张核心表跑两周观察误报率把阈值调到合理区间再逐步扩表。误报太多的规则宁可先关掉带着噪音上线的监控最后会被所有人静音。4.3 非结构化数据治理目录、抽取、标签三层合同、工单、扫描件这类非结构化数据治理思路和技术元数据不同。建议按三层推进目录层先回答有哪些文件、归谁管、什么权限抽取层把关键要素变成结构化字段标签层再做分类与检索。跳过前两层直接上全文检索往往得到一堆没人维护的索引。抽取层用 Python 起步最快PDF 类合同可以用 pdfplumber 配合正则抽要素import re import pdfplumber PATTERNS { contract_no: re.compile(r合同编号[:]\s*([A-Z0-9\-]{6,20})), amount: re.compile(r合同金额[:]\s*([0-9,]\.?\d*)\s*元), sign_date: re.compile(r签订日期[:]\s*(\d{4})[-/年](\d{1,2})[-/月](\d{1,2})), } def extract(path: str) - dict: doc {file: path} with pdfplumber.open(path) as pdf: text \n.join((p.extract_text() or ) for p in pdf.pages) for field, pat in PATTERNS.items(): m pat.search(text) doc[field] m.group(1).replace(,, ) if m else None doc[text_len] len(text) # 文本极短说明是扫描件应转 OCR 通道 return doc逻辑说明先整篇抽文本再用预编译正则匹配要素PATTERNS用字典声明便于按文件类型切换模板采购合同和劳动合同的字段集本来就不一样。text_len是个便宜的判别器——正常合同文本长度在几千字符量级低于200基本可以判定为纯图片扫描件走OCR通道而不是反复调正则。金额字段抽取时要去掉千分位逗号否则后续入库会变成字符串。真正决定非结构化治理成败的是元数据不是抽取准确率。每份文件至少要登记文件类型、所属业务域、责任人、密级、保留期限、关联的业务对象比如合同对应的客户编号。有了这几项即使抽取准确率只有七成业务也能通过客户编号文件类型快速定位到目标文件没有这几项准确率做到九成也依然是个黑盒。5. 数据治理流程与组织机制成熟度评估与实施路线治理推进到一定阶段必须回答我们现在到什么水平、下一步往哪走。空泛地回答还在建设中没有意义需要一个能打分、能对比的评估框架。5.1 DAMA 成熟度评估怎么打分按能力成熟度模型把每个治理域分成五级评估项控制在八到十个每个域给出1到5分。打分时不要闭门造车方法上通常每个域准备三个证据问题有没有制度文件、有没有执行记录、有没有量化结果。说不出执行记录和量化结果的一律按低一级算。等级特征判定证据1 初始靠个人经验出问题临时处理无文档无固定责任人2 可重复有非正式做法能重复但未成文有脚本或表格换人就断3 定义有制度、有流程、有明确角色制度发布流程有记录4 管理有量化指标并能持续监控质量分看板、变更审计日志5 优化指标驱动持续改进有阈值调优记录和复盘机制评估的用途不是打分好看而是找出定义级到管理级之间的断点。多数企业的元数据停在3级因为有了目录但没有变更监控数据质量停在2级因为有校验脚本但没有质量分。这两个断点对应的投入并不大收益却很直接。5.2 分阶段路线与里程碑实施节奏建议按三阶段推进每阶段四到六个月不要试图一次性覆盖全部治理域。阶段重点关键交付物验收指标第一阶段元数据与数据标准资产目录、命名规范、标准库核心表注释完备率 ≥ 90%第二阶段数据质量与主数据质量规则集、质量分看板、主数据源核心表质量分 ≥ 85第三阶段数据安全与资产运营分级分类清单、脱敏规则、资产服务接口敏感字段100%分级目录月活达标第一阶段千万别碰指标体系那是最容易扯皮的部分。先把仓库里有什么讲清楚业务对治理的信任感就是从一份准确的目录开始的。第二阶段才动口径而且要有业务方在场拍板。5.3 一个具体技巧先锁定一份黄金主数据表如果只能做一件事我一般建议先锁定一份客户主数据表并且把它做成黄金记录一个客户一行来源字段带血缘标记冲突时按权威系统优先级取值所有下游分析强制走这张表。建表的取数逻辑可以写成优先级规则而不是简单的UNION-- 黄金记录按权威系统优先级取客户属性CRM 优先于 OMSOMS 优先于计费 SELECT cust_id, COALESCE(crm.cust_name, oms.cust_name, bill.cust_name) AS cust_name, COALESCE(crm.cust_level, oms.cust_level, bill.cust_level) AS cust_level, COALESCE(crm.mobile_masked, oms.mobile_masked) AS mobile_masked, CASE WHEN crm.cust_id IS NOT NULL THEN CRM WHEN oms.cust_id IS NOT NULL THEN OMS ELSE BILLING END AS primary_source -- 记录本次取值来自哪个系统便于回溯 FROM dim_cust_crm crm FULL JOIN dim_cust_oms oms ON oms.cust_id crm.cust_id FULL JOIN dim_cust_bill bill ON bill.cust_id COALESCE(crm.cust_id, oms.cust_id);COALESCE的顺序就是权威优先级改优先级只需要调整字段顺序不用改下游。primary_source这一列看起来多余实际是对账时的救命字段——业务问这个客户等级为什么变了查一下来源系统切换记录就能解释。这张表上线后下游所有报表统一指向它口径争议会立刻少一大半治理团队也终于有了第一个可以拿出去讲的成果。本文还有配套的精品资源点击获取
