$WinREAgent文件夹是什么？Windows更新临时文件的安全删除指南
2026/9/20 19:32:19
简介：这份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": "mysql+pymysql://reader:***@10.0.1.11:3306/crm", "erp": "oracle+cx_oracle://reader:***@10.0.1.12:1521/?service_name=ERP", } DW = create_engine("mysql+pymysql://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_ping=True) 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", con=DW, if_exists="append", index=False) print(f"本次采集字段数：{len(df)}")几个参数值得说明：pool_pre_ping=True防止长连接被数据库侧断开；采集账号必须是只读账号，只授权information_schema或all_tab_columns的查询权限。真正常见的坑是 Oracle 侧的 schema 大小写，all_tab_columns里OWNER通常是大写，传小写会返回空结果，排查时先单独跑一遍SELECT COUNT(1) FROM all_tab_columns WHERE OWNER='CRM'确认。
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", index=False)路径按"共享盘/部门/业务域/文件"的层级约定，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 汇报现场最容易被追问的三处
第一处是"这些资产谁来维护"。回答必须是具体岗位和考核挂钩，最好当场指出责任矩阵里哪几个格子已经落实到部门年度考核。第二处是"和已有系统重复不重复"。要能明确说清元数据、质量、权限三块能力复用了哪些现有组件，增量建设了什么。第三处是"什么时候能看到效果"。没把握时给出试点域的可见成果日期，而不是全集团上线日期。
最后一件事，把指标口径表的变更做成带审批的流程：任何口径修改都要走数据管家提交、业务归口部门审核、总部数据管理部发布三步，发布后自动触发受影响报表清单。这条链路跑通，数据资产才真正从"目录里的记录"变成了"有人管、改了有人知道"的资产。
本文还有配套的精品资源，点击获取