简介《银行数据标准管理办法》是一份面向银行数据治理从业者的制度文档适合数据管理岗、信息项归口部门及IT项目组在标准制定、评审、发布、执行与变更等工作中参考。压缩包内仅1个docx文件大小约31KB正文围绕总则、组织与职责、数据标准制定、评审与发布等章节展开涵盖客户、产品、协议、交易、资产、财务、地址、组织、渠道、营销十个数据主题并区分业务规范与技术规范。目前已有152人学习可见该制度模板在银行同业中具有一定关注度。读者可从中获取数据标准管理的完整框架协调层与执行层的职责划分、信息项归口认定机制、IT项目组落地要求、标准准入原则以及评审参考维度便于用于制度起草、流程梳理或内部培训也可作为理解基础类数据标准与外部标准采纳顺序的参考样本。1. 银行数据标准管理办法不是文档工程而是字段级的对齐工程多数银行的《数据标准管理办法》都不缺篇幅缺的是可用性。三十到五十页正文一千多条数据元代码集若干指标口径几十个落在共享盘里季度填报时靠人工 Excel 核对一轮两周。反直觉的地方在于这份文档真正的风险不是写得不够全而是每一条条款都没法被机器读到——没有稳定编号没有版本和生效日期没有和物理表的对应关系评审会上只能靠人念、人记、人吵。它要解决的问题其实很具体新建系统的表结构和接口字段能不能在提交 DDL 前就被卡住存量系统的同义不同名字段能不能一次说清映射关系监管报送和内部报表的同名指标能不能确认口径一致。适合读这篇的是数据治理岗、数据平台与数仓开发、接口与报送开发以及做架构评审的同学。往下走重点不是文档怎么写而是条款怎么编号、怎么抽出来、怎么和元数据比对、怎么在流程里卡住。2. 管理办法的文档骨架数据元、代码集、指标、命名四条线2.1 四类对象各自的颗粒度与责任边界管理办法写崩最常见的原因是四类对象混在一起写。数据元是字段级的代码集是值域级的指标是统计口径级的命名是字符串规则级的它们的属性、责任部门、变更频率完全不同。混在一章里写结果是变更时没人知道该改哪一段落标稽核时也没法拆成不同的校验规则。对象颗粒度必须写清的属性常挂的责任方变更频率数据元字段中文名、英文名、类型、长度、精度、可空性、值域数据治理岗 业务部门低随业务新增代码集码值码表编号、码值、码值名称、生效日期、停用标记业务主管部门中监管类最频繁指标统计口径指标编号、口径描述、计算公式、维度、统计频度指标归口部门高季季在动命名命名对象前缀、分隔符、长度上限、大小写规则、保留字清单架构组极低定了就别动写的时候有个经验数据元和代码集必须能给到机器校验指标和命名至少要能给到人和脚本双读。指标口径如果只写一句「按监管口径统计」那这条等于没写稽核时还是各说各话。2.2 把条款写成可校验的元数据条目文档里的一条数据元标准落到可执行形态大概是这样一份 YAML。它是管理办法的机器可读镜像不是替代品——管理办法负责解释为什么这么定YAML 负责告诉脚本怎么查。# 银行数据标准管理办法 - 数据元条款的机器可读形态 standard_id: DS-CUST-0007 # 条款编号需求说明书、接口文档、DDL 注释统一引用它 version: V2 # 条款版本与管理办法正文的版本号一一对应 effective_date: 2024-07-01 # 生效日期早于此日期建的表按旧版条款判定 domain: CUST # 主题域代码用于统计分主题域的落标率 cn_name: 客户统一编号 en_name: cust_uid # 物理字段名比对时大小写不敏感 data_type: VARCHAR(32) # 类型必须完全匹配比对前会去掉空格并转大写 nullable: false # 该字段不允许为空 value_rule: ^[0-9A-Z]{1,32}$ # 值域正则落标稽核时按比例抽样逐行校验 code_set: null # 不是码值字段码值字段在这里填码表编号 owner: 零售业务部 # 变更申请必须由该部门发起几个参数值得展开说。standard_id是整个体系的锚点没有它需求文档里的「客户号」和数仓里的cust_uid之间就没有证据链。effective_date决定了存量表按哪一版判定这条在做存量整改时能省掉大量扯皮。value_rule不要写得太贪心一行正则最好控制在能覆盖 99% 以上正常数据的程度写得太严会把存量数据全部打成不达标最后反而推动不下去。code_set留空和填值要严格区分留空表示不做码值校验填了编号就必须能在码表清单里找到对应记录。2.3 条款编号规则与需求、接口、DDL 的锚点对齐编号规则要一眼能看出版本和主题域不然半年后自己都认不出来。常见做法是固定长度分段DS-主题域-四位顺序号-版本段位含义固定不允许跳段。段位含义取值规则示例1固定前缀恒为 DS表示数据标准DS2主题域代码2 到 6 位大写字母CUST3顺序号四位数字左补零不复用已停用编号00074版本号V 数字条款实质性变更才升版V2落到物理表上条款编号直接进字段注释这样任何人拿到一张表都能反查到它是按哪一版标准建的CREATE TABLE dwd_cust_info ( cust_uid VARCHAR(32) NOT NULL COMMENT DS-CUST-0007 客户统一编号, -- 引用条款编号 cust_name VARCHAR(200) NOT NULL COMMENT DS-CUST-0008 客户名称, cert_type CHAR(2) NOT NULL COMMENT DS-CUST-0012 证件类型, -- 码值字段走代码集校验 open_date DATE NOT NULL COMMENT DS-CUST-0020 开户日期, etl_batch_no VARCHAR(20) NOT NULL COMMENT ETL 批次号内部字段不纳入落标范围 );DDL 注释不是可选项。评审卡点脚本读的就是它注释里找不到DS-开头的编号这个字段就直接进「未引用标准」清单需要么补编号、么说明是内部字段并写进豁免清单。这一步做扎实后面所有的比对、统计、整改才有共同语言。3. 用 python-docx 把 .docx 抽成可执行的落标校验规则3.1 段落与表格的抽取脚本管理办法的正文通常是「编号 标题 属性段落」的结构数据元清单和码值清单则躺在表格里。所以抽取逻辑分两条路段落按编号正则切表格按表头映射成字典。别指望一次抽完就能用第一版抽出来的东西一定需要人工过一遍。from docx import Document import re import json DOC 银行数据标准管理办法.docx doc Document(DOC) items, cur [], None # 段落路径按 DS-XXX-0000 锚点切条款锚点后的段落都是这条的正文 for block in doc.paragraphs: text block.text.strip() if not text: continue m re.match(r^(DS-[A-Z]{2,6}-\d{4})(?:-(V\d))?\s*(.*)$, text) if m: cur {standard_id: m.group(1), version: m.group(2) or V1, title: m.group(3), body: []} items.append(cur) elif cur is not None: cur[body].append(text) # 表格路径表头当 key逐行转字典合并单元格会导致重复列名需要二次清洗 for tb in doc.tables: header [c.text.strip() for c in tb.rows[0].cells] if len(set(header)) ! len(header): print(警告表头存在重复列可能是合并单元格需人工确认) for row in tb.rows[1:]: cells [c.text.strip() for c in row.cells] if len(cells) ! len(header): continue items.append({table_row: dict(zip(header, cells))}) with open(std_items.json, w, encodingutf-8) as f: json.dump(items, f, ensure_asciiFalse, indent2) print(f抽出条款与表格行共 {len(items)} 条)逻辑和参数说明正则里的(?:-(V\d))?让版本号可选应付那些老条款没写版本的文档ensure_asciiFalse保证中文不转义方便人工抽查表格路径里对表头重复做了一次告警因为 Word 里跨行合并的表头在 python-docx 读出来是两个相同列名硬转字典会丢列。跑完这一步std_items.json里就是可以用脚本继续加工的原始素材正文段落还需要一轮人工确认为结构化字段别跳过。3.2 与 information_schema 做字段级比对标准有了、物理表结构有了比对本身是一条 SQL 的事。关键是把判定优先级定死否则同一行会同时命中多个规则、报表口径又不一样。-- 以标准清单为基准左连物理表逐字段给出判定结果 SELECT s.standard_id, s.en_name AS std_col, s.data_type AS std_type, c.column_name AS phys_col, c.column_type AS phys_type, CASE WHEN c.column_name IS NULL THEN 缺字段 WHEN UPPER(REPLACE(c.column_type, ,)) UPPER(REPLACE(s.data_type, ,)) THEN 类型不符 WHEN s.nullable false AND c.is_nullable YES THEN 可空性不符 ELSE 符合 END AS check_result FROM std_column s LEFT JOIN information_schema.columns c ON c.table_schema dwd AND c.table_name s.table_name AND LOWER(c.column_name) LOWER(s.en_name); -- 字段名大小写不敏感说明几点REPLACE去掉类型里的空格是因为VARCHAR(32)和VARCHAR (32)在建表语句里都合法但字符串比较会判成不等UPPER统一大小写避免同一类型被拆成两类。判定顺序不能乱——先判缺失再判类型最后判可空性反过来会让「缺字段」的行也报出类型不符噪声直接把报告淹掉。表名前缀、schema 名这类东西建议做成变量或用视图隔离别在脚本里写死。3.3 落标率、码值一致率的计算口径与阈值口径不统一落标率就是个玄学数字。建议在管理办法的附录里就把公式和阈值写死让治理、开发、评审三方用同一套算法。指标计算公式常见目标值备注字段落标率判定为「符合」的字段数 / 应落标字段数新系统不低于 95%分母不含豁免字段码值一致率抽样中取值命中码表的行数 / 抽样行数不低于 99%抽样比例建议 1% 或 1 万行封顶指标口径一致率口径一致的指标数 / 同一指标出现的系统数报送类 100%允许分母按报送口径收缩豁免率已批豁免字段数 / 应落标字段数控制在 10% 以内超过就要在治理会上说明阈值本身也是要调参的。新上线系统直接按 95% 卡存量核心系统第一年按 80% 起步、逐年抬是比较务实的做法。一刀切按 100% 的结果通常是把大量字段塞进豁免清单指标好看实际什么都没改。4. 落标执行准入卡点、存量映射与三类高频坑4.1 新表新接口的准入卡点脚本标准要生效就得卡在流程的必经之路上。最合适的点是 DDL 提交进代码仓库那一刻不通过直接让合并失败比事后发整改单有效得多。#!/usr/bin/env bash # DDL 提交前的落标卡点不达标直接非零退出阻断合并 set -euo pipefail DDL_FILE${1:?用法: std_gate.sh path/to/table.sql} python3 std_lint.py \ --ddl $DDL_FILE \ --std std_items.json \ # 由管理办法抽出的标准清单 --exempt exempt_list.csv \ # 已批豁免字段按编号表名匹配 --strict-type \ # 类型必须完全一致不做隐式兼容 --strict-null \ # 标准中不可空的字段物理表也必须 NOT NULL --min-rate 0.95 \ # 字段落标率门槛低于该值直接失败 --report lint_report.json # 退出码约定0 通过2 落标不达标3 文档解析失败通常是 DDL 语法问题 echo gate exit code: $?参数含义说清楚--strict-type打开后DECIMAL(18,2)和DECIMAL(20,4)会被判不符这对金额类字段是必要的--strict-null是争议最大的开关很多开发抱怨历史代码里 NULL 用得随意所以常见做法是新系统一律打开、存量改造分批开。--min-rate作为兜底阈值防止个别字段的争议拖住整张表的发布。退出码要固定下来并写进 CI 配置里别让运维靠猜。4.2 存量系统映射表与豁免清单存量系统不可能一夜改完靠的是映射表。映射表要写清四件事源系统字段、对应标准编号、映射类型、处理策略。映射类型决定了整改成本先分类再排期比按系统排队合理。系统物理字段标准编号映射类型处理策略核心系统CUST_NODS-CUST-0007同义不同名数仓视图层改名源头不动信贷系统CIF_IDDS-CUST-0007可直接映射DWD 层统一接口层做转换报表平台KHBMDS-CUST-0007值域不一致加转换规则同步补码值映射老外围系统无对应字段DS-CUST-0007无法改造申请豁免注明失效时间与替代方案豁免清单不是垃圾桶每一条都要有审批人、申请理由和到期复核日期默认有效期一年。到期不续批就自动失效重新变回不达标这样存量问题不会因为「反正豁免了」永久沉淀下来。4.3 码值漂移、精度与可空性这三类坑第一类是码值漂移。代码集在管理办法里只写了 20 个证件类型监管新增一类业务先在源系统上线标准后补中间这段时间所有新数据都不达标。常见做法是给码值校验留一个「未登记值」告警通道不做硬失败但每周出一次清单倒逼代码集及时更新。第二类是精度陷阱。金额字段标准写DECIMAL(18,2)物理表用NUMBER或FLOAT前两种在比对时都会判不符而FLOAT的问题更严重——它能过类型映射但计算时会出现 0.01 级别的偏差报送对不上账。所以金额字段建议直接禁用浮点类型这一条要写进管理办法的命名与类型章节。第三类是可空性。标准写NOT NULL物理表允许 NULL看起来只是约束差异实际上游一断下游指标就整段归零。处理办法是分批打开严格模式同时给 ETL 加一道空值兜底先把存量 NULL 补上默认值再收紧约束顺序反了会直接把任务打挂。命名大小写和保留字这两件小事也值得写进清单——order、user这类字段名在部分数据库里必须加引号评审时最容易漏。5. 版本演进与稽核看板让管理办法跟着系统一起升级5.1 变更类型决定版本号与生效方式管理办法最大的生命力在于能改而改的规则必须先定下来否则每次变更都是一场会议。经验是按变更类型映射升版方式和生效方式变更类型是否升版本生效方式存量表处理新增数据元新增编号不影响已有版本发布即生效不追溯类型或长度调整升小版本如 V2 到 V3设定过渡期如 3 个月过渡期内新旧并存码值新增不升版本更新码表生效日期发布即生效不追溯码值停用不升版本打停用标记发布即生效存量数据保留不校验条款废止保留编号并标注废止发布即生效转入历史清单要点是编号永不复用、废止也保留。编号一旦复用三年前的需求文档和现在的标准就会指向两个不同含义追查数据血缘时会彻底断链。过渡期的存在同样重要升版当天就要求所有存量表整改只会逼着大家集体申请豁免。5.2 稽核看板的最小指标集与调度看板不需要复杂能回答「哪个主题域在退步」就够了。最小指标集就三张表分主题域的字段落标率、码值一致率、豁免率趋势。-- 分主题域落标率把比对结果按 domain 聚合成趋势数据 SELECT s.domain, COUNT(*) AS total_cols, SUM(CASE WHEN r.check_result 符合 THEN 1 ELSE 0 END) AS pass_cols, ROUND(SUM(CASE WHEN r.check_result 符合 THEN 1 ELSE 0 END) / COUNT(*), 4) AS pass_rate, CURRENT_DATE AS stat_date FROM std_column s JOIN lint_result r USING (standard_id, table_name) WHERE s.standard_id NOT IN (SELECT standard_id FROM exempt_list WHERE status 生效) GROUP BY s.domain ORDER BY pass_rate ASC;聚合时把生效中的豁免字段排除掉否则豁免一多落标率反而虚高看板就失去意义。调度建议跑在每日凌晨落标率低于阈值时自动把前十条不一致明细推给对应主题域的责任人明细里带标准编号、物理字段、差异类型三列接到消息的人不用再回查管理办法。本文还有配套的精品资源点击获取