简介这份PPT资料围绕集团数据资产管控展开数据治理建设方案面向企业数据管理负责人、数据治理咨询顾问及数字化转型团队用于解决数据标准不统一、质量难管控、安全与共享机制缺失等问题属于中高级方案设计参考。资源为单个pptx文件压缩包约5.93MB以44页图文方案呈现涵盖顶层设计、组织架构与流程规范等内容便于直接汇报或二次改编。文件虽仅1个但信息密度较高适合按目录模块逐页拆解学习。目前已积累158人浏览学习可作为方案落地前的横向参考。读者能够获取集团数据管控的One Company、One Meta、One BI三层视角理解数据战略委员会、数据质量组、数据安全组等组织职责划分以及数据质量评估、清洗标准化、权限审计、数据共享机制与资产运营考核等完整框架还可借鉴其管理驾驶舱、模型算法规划与项目立项审计思路用于搭建或优化自身企业的数据治理体系。1. 集团数据资产管控难在账本而不在工具集团型企业的数据治理项目开场往往是一次跨部门汇报IT 说平台已经采购到位业务说数据还是对不上财务说同一个收入指标有三个数。一份 44 页的建设方案之所以难写不在排版而在于要在一次会上把资产口径、管控流程、平台能力和考核机制同时讲清楚还要让各子公司认账。数据资产管控的核心动作只有一句话把数据从系统里跑着的记录变成有归属、有密级、有规则、有责任人的资产。它要解决的典型问题是同一客户在 CRM、ERP、财务系统里有三个编号同一张报表在不同部门算出三种结果。这套方案适合集团总部数据管理岗、即将牵头治理的 IT 负责人以及既要给领导汇报又要给子公司派活的人。往下按方案骨架、资产盘点、平台配置、汇报验收四段推进每段都给到能直接落地的表结构和命令。2. 数据治理车轮图怎么落成集团数据资产管控方案骨架2.1 车轮图的六根辐条和集团场景下必须补的第七根数据治理车轮图是业内最常用的组织框架中心是数据战略与治理目标辐条分别是组织与职责、制度与标准、数据质量、数据安全、元数据与主数据、数据生命周期轮辋是流程与考核整只轮子靠持续运营转起来。画在 PPT 上很好看落到集团往往就转不动原因通常不是辐条少而是权属不明。集团和单体公司最大的差别是法人边界。一份客户主数据总部想统一子公司担心影响自己的考核口径一个指标总部定义和子公司理解不同取数逻辑各写各的。常见做法是在六根辐条之外补一根资产权属与认责把每个数据域映射到业务归口部门 数据属主 数据管家三级责任人。责任人不落地后面所有标准都只是墙上文件。我一般会把车轮图的辐条直接做成一张责任矩阵横向是数据域客户、产品、组织、财务、供应链、人力纵向是七根辐条交叉格填具体交付物和责任人。一张表就能撑起方案 PPT 的核心章节也方便在会上逐格追问这件事谁签字。2.2 集中式、联邦式、混合式集团管控模式怎么选选型错了平台建得再好也推不动。三种模式的差别本质是标准和数据谁说话。模式标准与主数据业务明细数据适用条件主要代价集中式总部统一制定并落地全部上收总部子公司业务同质、法人数量少子公司配合意愿低变更响应慢联邦式总部只定框架各子公司自管多元化集团、并购频繁口径长期不统一横向对比难混合式总部定标准并直管主数据明细留在子公司按需汇聚大多数多法人集团需要一套强约束的认责与考核机制混合式是绝大多数集团的最优解把客户、产品、组织、科目这类主数据和指标口径收到总部把交易明细留在子公司通过数据服务接口按需调用。理由很直接——主数据决定全集团能不能对齐明细决定子公司的业务灵活性两者不能用同一套管控强度。2.3 方案总体架构的四层拆解方案 PPT 里那张架构图落到文字就四层每层说清楚放什么、谁负责。层次承载内容关键组件责任方源系统层37 类核心业务系统、共享盘、对象存储只读采集账号、日志留存各系统运维资产汇聚层元数据、血缘、资产目录、非结构化文件索引采集任务、指纹去重总部数据管理部管控服务层数据标准、质量规则、密级策略、指标注册规则引擎、权限引擎总部 业务归口部门消费层报表、数据 API、自助分析、资产地图服务网关、订阅审批业务部门 数据管家四层里最容易做薄的是资产汇聚层。很多方案把元数据采集当成一次性脚本上线后再没人维护半年后目录和实际库表就对不上了。可用的做法是把采集任务做成日调度增量按元数据的更新时间拉取采集失败进告警队列。2.4 一期三个月怎么排从调研到试点域上线阶段周期交付物验收口径现状调研与盘点4 周系统清单、责任矩阵、资产初册核心系统覆盖率 100%标准与目录建设4 周数据标准 200 项、指标口径 80 项主数据标准评审通过平台配置6 周权限、质量规则、血缘、资产地图试点域规则全部跑通试点域上线4 周一个域通常选客户或财务闭环问题闭环率 ≥ 90%试点域一定要选业务痛、范围小、领导关注的那个。客户域通常最合适数据量可控跨系统冲突明显做出来立刻能看见报表口径统一的效果。3. 数据资产盘点元数据采集与非结构化数据治理3.1 先把资产目录的表结构定下来盘点不是拉一张 Excel而是建一套能长期维护的目录。资产主表和字段级元数据表是底座。-- 资产目录主表一行代表一份可管理的集团数据资产 CREATE TABLE gov_asset_catalog ( asset_id BIGINT NOT NULL COMMENT 资产唯一编号, asset_code VARCHAR(64) NOT NULL COMMENT 资产编码规则域-系统-表, asset_name VARCHAR(128) NOT NULL COMMENT 资产中文名, asset_type TINYINT NOT NULL COMMENT 1表 2视图 3接口 4文件 5指标, domain_code VARCHAR(32) NOT NULL COMMENT 业务域CUST/PROD/FIN/SUP/HR, src_system VARCHAR(64) NOT NULL COMMENT 来源系统标识, owner_id VARCHAR(32) NOT NULL COMMENT 数据属主工号, steward_id VARCHAR(32) NOT NULL COMMENT 数据管家工号, security_level TINYINT DEFAULT 2 COMMENT 密级1公开 2内部 3秘密 4机密, lifecycle_days INT DEFAULT 1095 COMMENT 保留天数, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (asset_id), UNIQUE KEY uk_asset_code (asset_code), KEY idx_domain (domain_code) ) COMMENT集团数据资产目录; -- 字段级元数据表支撑列级血缘和敏感字段识别 CREATE TABLE gov_asset_column ( col_id BIGINT NOT NULL AUTO_INCREMENT, asset_id BIGINT NOT NULL COMMENT 所属资产编号, col_name VARCHAR(128) NOT NULL COMMENT 字段名, col_comment VARCHAR(255) COMMENT 字段中文含义, data_type VARCHAR(64) COMMENT 字段类型, is_primary_key TINYINT DEFAULT 0, is_sensitive TINYINT DEFAULT 0 COMMENT 是否敏感字段, std_code VARCHAR(64) COMMENT 关联数据标准编码, PRIMARY KEY (col_id), KEY idx_asset (asset_id) ) COMMENT数据资产字段元数据;asset_code用域-系统-表三段式是为了让后续的血缘、质量规则、权限策略都能用同一个键去关联避免每张表一套命名。security_level和lifecycle_days一定要在盘点阶段就填否则到了归档清理的时候没有依据只能靠人拍脑袋。3.2 用 Python 批量采集关系库元数据元数据采集必须是自动化的靠人工登记撑不过第二个月。下面这段脚本演示从信息架构视图拉取字段信息并落到数仓。from sqlalchemy import create_engine, text import pandas as pd # 采集范围集团登记在册的核心业务系统统一使用只读账号 SYSTEMS { crm: mysqlpymysql://reader:***10.0.1.11:3306/crm, erp: oraclecx_oracle://reader:***10.0.1.12:1521/?service_nameERP, } DW create_engine(mysqlpymysql://gov:***10.0.2.10:3306/govern) def collect(system_code, uri, schema): 按 schema 拉取字段级元数据Oracle 需把 information_schema 换成 all_tab_columns eng create_engine(uri, pool_pre_pingTrue) sql text( SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_schema :schema ) with eng.connect() as conn: rows conn.execute(sql, {schema: schema}).fetchall() return [ {src_system: system_code, table_name: r[0], col_name: r[1], data_type: r[2]} for r in rows ] records [] for code, uri in SYSTEMS.items(): records.extend(collect(code, uri, public)) df pd.DataFrame(records).drop_duplicates(subset[src_system, table_name, col_name]) df.to_sql(gov_asset_column_tmp, conDW, if_existsappend, indexFalse) print(f本次采集字段数{len(df)})几个参数值得说明pool_pre_pingTrue防止长连接被数据库侧断开采集账号必须是只读账号只授权information_schema或all_tab_columns的查询权限。真正常见的坑是 Oracle 侧的 schema 大小写all_tab_columns里OWNER通常是大写传小写会返回空结果排查时先单独跑一遍SELECT COUNT(1) FROM all_tab_columns WHERE OWNERCRM确认。3.3 非结构化数据治理共享盘和对象存储也要进目录非结构化数据治理最容易被跳过但它往往占了集团数据总量的七八成而且密级风险最高——一份带身份证号的客户清单躺在共享盘里谁都能下载。做法是先扫描、再打标、最后按密级收敛权限。import os, hashlib, pandas as pd from datetime import datetime ROOT /data/share # 共享盘挂载点或对象存储同步目录 EXCLUDE {.tmp, .lock, .part} # 临时文件不纳入资产目录 def scan(root): for dirpath, _, files in os.walk(root): for f in files: ext os.path.splitext(f)[1].lower() if ext in EXCLUDE: continue p os.path.join(dirpath, f) st os.stat(p) parts dirpath.strip(/).split(/) yield { asset_name: f, asset_type: 4, # 4 文件类资产 domain_code: parts[2] if len(parts) 2 else UNKNOWN, ext: ext, size_mb: round(st.st_size / 1024 / 1024, 2), last_modified: datetime.fromtimestamp(st.st_mtime).strftime(%Y-%m-%d), fingerprint: hashlib.md5(f{p}{st.st_size}.encode()).hexdigest(), } pd.DataFrame(scan(ROOT)).to_csv(unstructured_catalog.csv, indexFalse)路径按共享盘/部门/业务域/文件的层级约定domain_code直接从第三段路径取这样扫描出来的资产天然带上业务域归属。fingerprint用路径加文件大小做摘要用来识别同一文件被复制多份的情况——治理时先把副本清理掉再做密级收敛工作量能少一半。文件名里含客户名单薪酬身份证这类关键词的直接进敏感词库做二次人工确认。3.4 分类分级打标给每份资产一个密级分类典型资产判定依据默认密级主数据客户、产品、组织、科目跨系统共享、参与口径计算内部交易数据订单、支付、库存流水高频写入、按时间分区内部参考数据行政区划、行业代码变更频率低、可公开公开分析数据指标宽表、标签、报表由其他资产加工而来内部非结构化文档合同、扫描件、设计图含个人或商业敏感信息秘密分级的落地方式不是打一个标签就完事而是把密级写进权限引擎的过滤条件内部级默认本部门可见秘密级需要数据属主审批机密级只允许指定岗位下载且留痕。4. 数据资产管控平台的关键配置权限、质量、血缘、指标4.1 权限模型从 RBAC 到行级列级集团权限控制的难点是同一张表不同子公司只能看自己那一块。纯 RBAC 到菜单和表级就停了必须补行级和列级。层级控制对象实现方式典型场景功能级菜单、按钮角色-权限点映射谁能进资产地图对象级库、表、文件目录角色-资产授权子公司只能看本域表行级数据行视图或策略过滤按区域、法人隔离列级字段视图裁剪或动态脱敏手机号、身份证号行级控制在数仓侧最省事的做法是视图加映射表查询时自动带上用户所属区域-- 用户与可见区域的映射关系由组织主数据同步生成 CREATE TABLE gov_user_region ( user_id VARCHAR(32) NOT NULL, region_code VARCHAR(16) NOT NULL, PRIMARY KEY (user_id, region_code) ); -- 行级隔离视图不同账号看到不同区域的数据 CREATE VIEW v_sales_order AS SELECT order_id, customer_id, amount, region_code FROM dwd_sales_order WHERE region_code IN ( SELECT region_code FROM gov_user_region WHERE user_id CURRENT_USER() );CURRENT_USER()换成实际平台的身份函数即可部分引擎用session_user或自定义函数。这种写法的问题是每次查询都要走一次子查询数据量大时性能下降明显常见优化是把映射关系缓存到会话变量或者在建视图前先做物化。列级脱敏则优先用动态脱敏策略而非视图裁剪避免视图数量随权限组合爆炸。4.2 数据质量规则六类校验的写法与阈值质量规则按完整性、唯一性、有效性、一致性、及时性、准确性六类组织每条规则一个编号结果落到统一的结果表方便做趋势和闭环。-- 客户主数据完整性校验统一社会信用代码不能为空且长度必须为 18 INSERT INTO gov_dq_result (rule_id, asset_code, check_time, total_cnt, fail_cnt, pass_rate) SELECT DQ_CUST_001 AS rule_id, CUST-CRM-CUSTOMER AS asset_code, NOW() AS check_time, COUNT(1) AS total_cnt, SUM(CASE WHEN credit_code IS NULL OR CHAR_LENGTH(credit_code) 18 THEN 1 ELSE 0 END) AS fail_cnt, ROUND(1 - SUM(CASE WHEN credit_code IS NULL OR CHAR_LENGTH(credit_code) 18 THEN 1 ELSE 0 END) / COUNT(1), 4) AS pass_rate FROM ods_crm_customer WHERE dt DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY);规则类型校验示例常见阈值告警动作完整性关键字段非空率 99.5% 告警通知数据管家唯一性主键重复行数 0 即告警阻断下游调度有效性枚举值、正则格式 99% 告警通知源系统一致性跨系统同口径比对偏差 1% 告警拉口径评审及时性分区到达时间晚于 08:00 告警通知运维准确性与对账文件差额差额 ≠ 0 告警冻结报表发布阈值不要一次定死。上线初期先把所有规则设成只告警不阻断跑两周看基线再按实际分布收紧。直接上阻断规则的结果通常是业务停摆然后规则被人为关掉。4.3 血缘解析与影响分析血缘要解决的具体问题是改这张表之前先知道会影响谁。SQL 解析是主路径简单场景用 sqlparse 就能拿到输入输出表复杂语句再用更完整的解析器。import sqlparse from sqlparse.sql import Identifier, IdentifierList from sqlparse.tokens import Keyword def extract_tables(sql): 粗粒度提取 FROM / JOIN 后面的表名用于构建表级血缘 stmt sqlparse.parse(sql)[0] tables, from_seen [], False for token in stmt.tokens: if from_seen: if isinstance(token, IdentifierList): tables [i.get_real_name() for i in token.get_identifiers()] elif isinstance(token, Identifier): tables.append(token.get_real_name()) elif token.ttype is Keyword: from_seen False if token.ttype is Keyword and token.value.upper() in (FROM, JOIN): from_seen True return [t for t in tables if t] sql (INSERT INTO dws_cust_summary SELECT c.cust_id, SUM(o.amount) FROM ods_crm_customer c JOIN ods_order o ON c.cust_id o.cust_id GROUP BY c.cust_id) print(extract_tables(sql))这段函数只适合做表级血缘的快速验证遇到子查询、CTE、UNION 会漏。生产上一般换成语义更完整的解析库或者直接接调度平台的 SQL 解析结果。真正的价值不在解析本身而在拿到血缘后做三件事上游变更自动通知下游责任人、字段级血缘反查敏感数据流向、以及给每个指标标注它的取数链路让口径争议有据可查。4.4 指标口径注册一个指标一张身份证口径不统一本质是没有唯一的注册表。把指标当成资产来管每条记录包含编码、名称、口径表达式、维度、责任部门和更新频率。指标编码指标名称口径表达式维度责任部门更新频率M_FIN_001营业收入SUM(含税金额) - SUM(退货金额)组织、期间财务部日M_CUST_003有效客户数COUNT(DISTINCT 客户号) WHERE 近12月有交易区域、渠道市场部月M_SUP_002订单满足率按期交付行数 / 订单总行数供应商、品类供应链部周注册表的关键约束是同一指标编码只能有一条有效口径历史版本保留但标记失效。任何报表要引用指标必须写编码而不是自己写表达式这样口径变更时能一键定位所有受影响的报表。5. 44 页方案的页面分配与三个验收指标5.1 44 页怎么切给汇报留出决策页章节页数核心图汇报目标现状与问题8系统清单、问题清单让领导承认痛目标与范围6车轮图、责任矩阵定边界和责任人架构与选型10四层架构、模式对比说明为什么这么建实施路径8三个月路线图、里程碑争取资源和排期资产与管控示例6资产目录、质量规则、口径表证明可落地投入与收益4人力测算、量化收益拍板决策事项2待决清单当场定事汇报页不是文档页。44 页里有 30 页是给人看的细节真正的决策页只有最后 2 页把要人、要钱、要授权三件事写清楚前面所有内容都是为这两页做铺垫。资产与管控示例那 6 页一定要放真实截图和数据放架构概念图的方案在评审会上撑不过三个问题。5.2 用三个可量化指标验收方案方案写完要能自证否则第二年没人说得清治理到底做了没有。三个指标足够资产盘点覆盖率、口径一致率、质量问题闭环率。-- 口径一致率同一指标在不同系统中的取值偏差在 1% 以内的占比 SELECT ROUND( SUM(CASE WHEN ABS(a.val - b.val) / NULLIF(b.val, 0) 0.01 THEN 1 ELSE 0 END) / COUNT(1), 4) AS consist_rate FROM gov_metric_value a JOIN gov_metric_value b ON a.metric_code b.metric_code AND a.src_system b.src_system WHERE a.stat_date DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY);指标计算方式一期目标数据来源资产盘点覆盖率已登记资产数 / 核心系统实际表数≥ 95%元数据采集结果口径一致率跨系统指标偏差 ≤1% 的占比≥ 90%指标注册表比对质量问题闭环率已处理问题数 / 发现问题总数≥ 90%质量结果表三个指标都落在目录里已有的数据上不需要额外埋点这是设计上的取舍能自动算的指标才会被持续跟踪。覆盖率靠采集任务自己统计一致率靠指标比对脚本闭环率靠工单状态流转每个指标都能追到具体记录。5.3 汇报现场最容易被追问的三处第一处是这些资产谁来维护。回答必须是具体岗位和考核挂钩最好当场指出责任矩阵里哪几个格子已经落实到部门年度考核。第二处是和已有系统重复不重复。要能明确说清元数据、质量、权限三块能力复用了哪些现有组件增量建设了什么。第三处是什么时候能看到效果。没把握时给出试点域的可见成果日期而不是全集团上线日期。最后一件事把指标口径表的变更做成带审批的流程任何口径修改都要走数据管家提交、业务归口部门审核、总部数据管理部发布三步发布后自动触发受影响报表清单。这条链路跑通数据资产才真正从目录里的记录变成了有人管、改了有人知道的资产。本文还有配套的精品资源点击获取 集团数据资产管控：数据治理车轮图与平台落地
简介这份PPT资料围绕集团数据资产管控展开数据治理建设方案面向企业数据管理负责人、数据治理咨询顾问及数字化转型团队用于解决数据标准不统一、质量难管控、安全与共享机制缺失等问题属于中高级方案设计参考。资源为单个pptx文件压缩包约5.93MB以44页图文方案呈现涵盖顶层设计、组织架构与流程规范等内容便于直接汇报或二次改编。文件虽仅1个但信息密度较高适合按目录模块逐页拆解学习。目前已积累158人浏览学习可作为方案落地前的横向参考。读者能够获取集团数据管控的One Company、One Meta、One BI三层视角理解数据战略委员会、数据质量组、数据安全组等组织职责划分以及数据质量评估、清洗标准化、权限审计、数据共享机制与资产运营考核等完整框架还可借鉴其管理驾驶舱、模型算法规划与项目立项审计思路用于搭建或优化自身企业的数据治理体系。1. 集团数据资产管控难在账本而不在工具集团型企业的数据治理项目开场往往是一次跨部门汇报IT 说平台已经采购到位业务说数据还是对不上财务说同一个收入指标有三个数。一份 44 页的建设方案之所以难写不在排版而在于要在一次会上把资产口径、管控流程、平台能力和考核机制同时讲清楚还要让各子公司认账。数据资产管控的核心动作只有一句话把数据从系统里跑着的记录变成有归属、有密级、有规则、有责任人的资产。它要解决的典型问题是同一客户在 CRM、ERP、财务系统里有三个编号同一张报表在不同部门算出三种结果。这套方案适合集团总部数据管理岗、即将牵头治理的 IT 负责人以及既要给领导汇报又要给子公司派活的人。往下按方案骨架、资产盘点、平台配置、汇报验收四段推进每段都给到能直接落地的表结构和命令。2. 数据治理车轮图怎么落成集团数据资产管控方案骨架2.1 车轮图的六根辐条和集团场景下必须补的第七根数据治理车轮图是业内最常用的组织框架中心是数据战略与治理目标辐条分别是组织与职责、制度与标准、数据质量、数据安全、元数据与主数据、数据生命周期轮辋是流程与考核整只轮子靠持续运营转起来。画在 PPT 上很好看落到集团往往就转不动原因通常不是辐条少而是权属不明。集团和单体公司最大的差别是法人边界。一份客户主数据总部想统一子公司担心影响自己的考核口径一个指标总部定义和子公司理解不同取数逻辑各写各的。常见做法是在六根辐条之外补一根资产权属与认责把每个数据域映射到业务归口部门 数据属主 数据管家三级责任人。责任人不落地后面所有标准都只是墙上文件。我一般会把车轮图的辐条直接做成一张责任矩阵横向是数据域客户、产品、组织、财务、供应链、人力纵向是七根辐条交叉格填具体交付物和责任人。一张表就能撑起方案 PPT 的核心章节也方便在会上逐格追问这件事谁签字。2.2 集中式、联邦式、混合式集团管控模式怎么选选型错了平台建得再好也推不动。三种模式的差别本质是标准和数据谁说话。模式标准与主数据业务明细数据适用条件主要代价集中式总部统一制定并落地全部上收总部子公司业务同质、法人数量少子公司配合意愿低变更响应慢联邦式总部只定框架各子公司自管多元化集团、并购频繁口径长期不统一横向对比难混合式总部定标准并直管主数据明细留在子公司按需汇聚大多数多法人集团需要一套强约束的认责与考核机制混合式是绝大多数集团的最优解把客户、产品、组织、科目这类主数据和指标口径收到总部把交易明细留在子公司通过数据服务接口按需调用。理由很直接——主数据决定全集团能不能对齐明细决定子公司的业务灵活性两者不能用同一套管控强度。2.3 方案总体架构的四层拆解方案 PPT 里那张架构图落到文字就四层每层说清楚放什么、谁负责。层次承载内容关键组件责任方源系统层37 类核心业务系统、共享盘、对象存储只读采集账号、日志留存各系统运维资产汇聚层元数据、血缘、资产目录、非结构化文件索引采集任务、指纹去重总部数据管理部管控服务层数据标准、质量规则、密级策略、指标注册规则引擎、权限引擎总部 业务归口部门消费层报表、数据 API、自助分析、资产地图服务网关、订阅审批业务部门 数据管家四层里最容易做薄的是资产汇聚层。很多方案把元数据采集当成一次性脚本上线后再没人维护半年后目录和实际库表就对不上了。可用的做法是把采集任务做成日调度增量按元数据的更新时间拉取采集失败进告警队列。2.4 一期三个月怎么排从调研到试点域上线阶段周期交付物验收口径现状调研与盘点4 周系统清单、责任矩阵、资产初册核心系统覆盖率 100%标准与目录建设4 周数据标准 200 项、指标口径 80 项主数据标准评审通过平台配置6 周权限、质量规则、血缘、资产地图试点域规则全部跑通试点域上线4 周一个域通常选客户或财务闭环问题闭环率 ≥ 90%试点域一定要选业务痛、范围小、领导关注的那个。客户域通常最合适数据量可控跨系统冲突明显做出来立刻能看见报表口径统一的效果。3. 数据资产盘点元数据采集与非结构化数据治理3.1 先把资产目录的表结构定下来盘点不是拉一张 Excel而是建一套能长期维护的目录。资产主表和字段级元数据表是底座。-- 资产目录主表一行代表一份可管理的集团数据资产 CREATE TABLE gov_asset_catalog ( asset_id BIGINT NOT NULL COMMENT 资产唯一编号, asset_code VARCHAR(64) NOT NULL COMMENT 资产编码规则域-系统-表, asset_name VARCHAR(128) NOT NULL COMMENT 资产中文名, asset_type TINYINT NOT NULL COMMENT 1表 2视图 3接口 4文件 5指标, domain_code VARCHAR(32) NOT NULL COMMENT 业务域CUST/PROD/FIN/SUP/HR, src_system VARCHAR(64) NOT NULL COMMENT 来源系统标识, owner_id VARCHAR(32) NOT NULL COMMENT 数据属主工号, steward_id VARCHAR(32) NOT NULL COMMENT 数据管家工号, security_level TINYINT DEFAULT 2 COMMENT 密级1公开 2内部 3秘密 4机密, lifecycle_days INT DEFAULT 1095 COMMENT 保留天数, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (asset_id), UNIQUE KEY uk_asset_code (asset_code), KEY idx_domain (domain_code) ) COMMENT集团数据资产目录; -- 字段级元数据表支撑列级血缘和敏感字段识别 CREATE TABLE gov_asset_column ( col_id BIGINT NOT NULL AUTO_INCREMENT, asset_id BIGINT NOT NULL COMMENT 所属资产编号, col_name VARCHAR(128) NOT NULL COMMENT 字段名, col_comment VARCHAR(255) COMMENT 字段中文含义, data_type VARCHAR(64) COMMENT 字段类型, is_primary_key TINYINT DEFAULT 0, is_sensitive TINYINT DEFAULT 0 COMMENT 是否敏感字段, std_code VARCHAR(64) COMMENT 关联数据标准编码, PRIMARY KEY (col_id), KEY idx_asset (asset_id) ) COMMENT数据资产字段元数据;asset_code用域-系统-表三段式是为了让后续的血缘、质量规则、权限策略都能用同一个键去关联避免每张表一套命名。security_level和lifecycle_days一定要在盘点阶段就填否则到了归档清理的时候没有依据只能靠人拍脑袋。3.2 用 Python 批量采集关系库元数据元数据采集必须是自动化的靠人工登记撑不过第二个月。下面这段脚本演示从信息架构视图拉取字段信息并落到数仓。from sqlalchemy import create_engine, text import pandas as pd # 采集范围集团登记在册的核心业务系统统一使用只读账号 SYSTEMS { crm: mysqlpymysql://reader:***10.0.1.11:3306/crm, erp: oraclecx_oracle://reader:***10.0.1.12:1521/?service_nameERP, } DW create_engine(mysqlpymysql://gov:***10.0.2.10:3306/govern) def collect(system_code, uri, schema): 按 schema 拉取字段级元数据Oracle 需把 information_schema 换成 all_tab_columns eng create_engine(uri, pool_pre_pingTrue) sql text( SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_schema :schema ) with eng.connect() as conn: rows conn.execute(sql, {schema: schema}).fetchall() return [ {src_system: system_code, table_name: r[0], col_name: r[1], data_type: r[2]} for r in rows ] records [] for code, uri in SYSTEMS.items(): records.extend(collect(code, uri, public)) df pd.DataFrame(records).drop_duplicates(subset[src_system, table_name, col_name]) df.to_sql(gov_asset_column_tmp, conDW, if_existsappend, indexFalse) print(f本次采集字段数{len(df)})几个参数值得说明pool_pre_pingTrue防止长连接被数据库侧断开采集账号必须是只读账号只授权information_schema或all_tab_columns的查询权限。真正常见的坑是 Oracle 侧的 schema 大小写all_tab_columns里OWNER通常是大写传小写会返回空结果排查时先单独跑一遍SELECT COUNT(1) FROM all_tab_columns WHERE OWNERCRM确认。3.3 非结构化数据治理共享盘和对象存储也要进目录非结构化数据治理最容易被跳过但它往往占了集团数据总量的七八成而且密级风险最高——一份带身份证号的客户清单躺在共享盘里谁都能下载。做法是先扫描、再打标、最后按密级收敛权限。import os, hashlib, pandas as pd from datetime import datetime ROOT /data/share # 共享盘挂载点或对象存储同步目录 EXCLUDE {.tmp, .lock, .part} # 临时文件不纳入资产目录 def scan(root): for dirpath, _, files in os.walk(root): for f in files: ext os.path.splitext(f)[1].lower() if ext in EXCLUDE: continue p os.path.join(dirpath, f) st os.stat(p) parts dirpath.strip(/).split(/) yield { asset_name: f, asset_type: 4, # 4 文件类资产 domain_code: parts[2] if len(parts) 2 else UNKNOWN, ext: ext, size_mb: round(st.st_size / 1024 / 1024, 2), last_modified: datetime.fromtimestamp(st.st_mtime).strftime(%Y-%m-%d), fingerprint: hashlib.md5(f{p}{st.st_size}.encode()).hexdigest(), } pd.DataFrame(scan(ROOT)).to_csv(unstructured_catalog.csv, indexFalse)路径按共享盘/部门/业务域/文件的层级约定domain_code直接从第三段路径取这样扫描出来的资产天然带上业务域归属。fingerprint用路径加文件大小做摘要用来识别同一文件被复制多份的情况——治理时先把副本清理掉再做密级收敛工作量能少一半。文件名里含客户名单薪酬身份证这类关键词的直接进敏感词库做二次人工确认。3.4 分类分级打标给每份资产一个密级分类典型资产判定依据默认密级主数据客户、产品、组织、科目跨系统共享、参与口径计算内部交易数据订单、支付、库存流水高频写入、按时间分区内部参考数据行政区划、行业代码变更频率低、可公开公开分析数据指标宽表、标签、报表由其他资产加工而来内部非结构化文档合同、扫描件、设计图含个人或商业敏感信息秘密分级的落地方式不是打一个标签就完事而是把密级写进权限引擎的过滤条件内部级默认本部门可见秘密级需要数据属主审批机密级只允许指定岗位下载且留痕。4. 数据资产管控平台的关键配置权限、质量、血缘、指标4.1 权限模型从 RBAC 到行级列级集团权限控制的难点是同一张表不同子公司只能看自己那一块。纯 RBAC 到菜单和表级就停了必须补行级和列级。层级控制对象实现方式典型场景功能级菜单、按钮角色-权限点映射谁能进资产地图对象级库、表、文件目录角色-资产授权子公司只能看本域表行级数据行视图或策略过滤按区域、法人隔离列级字段视图裁剪或动态脱敏手机号、身份证号行级控制在数仓侧最省事的做法是视图加映射表查询时自动带上用户所属区域-- 用户与可见区域的映射关系由组织主数据同步生成 CREATE TABLE gov_user_region ( user_id VARCHAR(32) NOT NULL, region_code VARCHAR(16) NOT NULL, PRIMARY KEY (user_id, region_code) ); -- 行级隔离视图不同账号看到不同区域的数据 CREATE VIEW v_sales_order AS SELECT order_id, customer_id, amount, region_code FROM dwd_sales_order WHERE region_code IN ( SELECT region_code FROM gov_user_region WHERE user_id CURRENT_USER() );CURRENT_USER()换成实际平台的身份函数即可部分引擎用session_user或自定义函数。这种写法的问题是每次查询都要走一次子查询数据量大时性能下降明显常见优化是把映射关系缓存到会话变量或者在建视图前先做物化。列级脱敏则优先用动态脱敏策略而非视图裁剪避免视图数量随权限组合爆炸。4.2 数据质量规则六类校验的写法与阈值质量规则按完整性、唯一性、有效性、一致性、及时性、准确性六类组织每条规则一个编号结果落到统一的结果表方便做趋势和闭环。-- 客户主数据完整性校验统一社会信用代码不能为空且长度必须为 18 INSERT INTO gov_dq_result (rule_id, asset_code, check_time, total_cnt, fail_cnt, pass_rate) SELECT DQ_CUST_001 AS rule_id, CUST-CRM-CUSTOMER AS asset_code, NOW() AS check_time, COUNT(1) AS total_cnt, SUM(CASE WHEN credit_code IS NULL OR CHAR_LENGTH(credit_code) 18 THEN 1 ELSE 0 END) AS fail_cnt, ROUND(1 - SUM(CASE WHEN credit_code IS NULL OR CHAR_LENGTH(credit_code) 18 THEN 1 ELSE 0 END) / COUNT(1), 4) AS pass_rate FROM ods_crm_customer WHERE dt DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY);规则类型校验示例常见阈值告警动作完整性关键字段非空率 99.5% 告警通知数据管家唯一性主键重复行数 0 即告警阻断下游调度有效性枚举值、正则格式 99% 告警通知源系统一致性跨系统同口径比对偏差 1% 告警拉口径评审及时性分区到达时间晚于 08:00 告警通知运维准确性与对账文件差额差额 ≠ 0 告警冻结报表发布阈值不要一次定死。上线初期先把所有规则设成只告警不阻断跑两周看基线再按实际分布收紧。直接上阻断规则的结果通常是业务停摆然后规则被人为关掉。4.3 血缘解析与影响分析血缘要解决的具体问题是改这张表之前先知道会影响谁。SQL 解析是主路径简单场景用 sqlparse 就能拿到输入输出表复杂语句再用更完整的解析器。import sqlparse from sqlparse.sql import Identifier, IdentifierList from sqlparse.tokens import Keyword def extract_tables(sql): 粗粒度提取 FROM / JOIN 后面的表名用于构建表级血缘 stmt sqlparse.parse(sql)[0] tables, from_seen [], False for token in stmt.tokens: if from_seen: if isinstance(token, IdentifierList): tables [i.get_real_name() for i in token.get_identifiers()] elif isinstance(token, Identifier): tables.append(token.get_real_name()) elif token.ttype is Keyword: from_seen False if token.ttype is Keyword and token.value.upper() in (FROM, JOIN): from_seen True return [t for t in tables if t] sql (INSERT INTO dws_cust_summary SELECT c.cust_id, SUM(o.amount) FROM ods_crm_customer c JOIN ods_order o ON c.cust_id o.cust_id GROUP BY c.cust_id) print(extract_tables(sql))这段函数只适合做表级血缘的快速验证遇到子查询、CTE、UNION 会漏。生产上一般换成语义更完整的解析库或者直接接调度平台的 SQL 解析结果。真正的价值不在解析本身而在拿到血缘后做三件事上游变更自动通知下游责任人、字段级血缘反查敏感数据流向、以及给每个指标标注它的取数链路让口径争议有据可查。4.4 指标口径注册一个指标一张身份证口径不统一本质是没有唯一的注册表。把指标当成资产来管每条记录包含编码、名称、口径表达式、维度、责任部门和更新频率。指标编码指标名称口径表达式维度责任部门更新频率M_FIN_001营业收入SUM(含税金额) - SUM(退货金额)组织、期间财务部日M_CUST_003有效客户数COUNT(DISTINCT 客户号) WHERE 近12月有交易区域、渠道市场部月M_SUP_002订单满足率按期交付行数 / 订单总行数供应商、品类供应链部周注册表的关键约束是同一指标编码只能有一条有效口径历史版本保留但标记失效。任何报表要引用指标必须写编码而不是自己写表达式这样口径变更时能一键定位所有受影响的报表。5. 44 页方案的页面分配与三个验收指标5.1 44 页怎么切给汇报留出决策页章节页数核心图汇报目标现状与问题8系统清单、问题清单让领导承认痛目标与范围6车轮图、责任矩阵定边界和责任人架构与选型10四层架构、模式对比说明为什么这么建实施路径8三个月路线图、里程碑争取资源和排期资产与管控示例6资产目录、质量规则、口径表证明可落地投入与收益4人力测算、量化收益拍板决策事项2待决清单当场定事汇报页不是文档页。44 页里有 30 页是给人看的细节真正的决策页只有最后 2 页把要人、要钱、要授权三件事写清楚前面所有内容都是为这两页做铺垫。资产与管控示例那 6 页一定要放真实截图和数据放架构概念图的方案在评审会上撑不过三个问题。5.2 用三个可量化指标验收方案方案写完要能自证否则第二年没人说得清治理到底做了没有。三个指标足够资产盘点覆盖率、口径一致率、质量问题闭环率。-- 口径一致率同一指标在不同系统中的取值偏差在 1% 以内的占比 SELECT ROUND( SUM(CASE WHEN ABS(a.val - b.val) / NULLIF(b.val, 0) 0.01 THEN 1 ELSE 0 END) / COUNT(1), 4) AS consist_rate FROM gov_metric_value a JOIN gov_metric_value b ON a.metric_code b.metric_code AND a.src_system b.src_system WHERE a.stat_date DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY);指标计算方式一期目标数据来源资产盘点覆盖率已登记资产数 / 核心系统实际表数≥ 95%元数据采集结果口径一致率跨系统指标偏差 ≤1% 的占比≥ 90%指标注册表比对质量问题闭环率已处理问题数 / 发现问题总数≥ 90%质量结果表三个指标都落在目录里已有的数据上不需要额外埋点这是设计上的取舍能自动算的指标才会被持续跟踪。覆盖率靠采集任务自己统计一致率靠指标比对脚本闭环率靠工单状态流转每个指标都能追到具体记录。5.3 汇报现场最容易被追问的三处第一处是这些资产谁来维护。回答必须是具体岗位和考核挂钩最好当场指出责任矩阵里哪几个格子已经落实到部门年度考核。第二处是和已有系统重复不重复。要能明确说清元数据、质量、权限三块能力复用了哪些现有组件增量建设了什么。第三处是什么时候能看到效果。没把握时给出试点域的可见成果日期而不是全集团上线日期。最后一件事把指标口径表的变更做成带审批的流程任何口径修改都要走数据管家提交、业务归口部门审核、总部数据管理部发布三步发布后自动触发受影响报表清单。这条链路跑通数据资产才真正从目录里的记录变成了有人管、改了有人知道的资产。本文还有配套的精品资源点击获取