简介这份演示文稿围绕数据元、元数据、主数据、主数据管理、元数据管理及资源目录方案展开面向数据治理与数字化建设从业者及数据管理新人。内容从数据元“不可再分的最小数据单元”定义讲起结合“船舶种类代码”“船员登记号”等实例拆解对象、特性、表示三要素并通过数据元集信息示例说明字段命名与数据元对应关系接着区分元数据与主数据的定位说明元数据是“描述数据的数据”、是数据与用户之间的桥梁并解释MDM如何创建单一、一致、可靠的主数据视图以及元数据管理MM如何融入数据治理与质量控制。最后落到资源目录方案关联碳排放数字化建设与数字化驾驶舱建设等典型场景帮助读者把概念应用到实际项目中。压缩包内为单个演示文稿文件大小9.55MB结构紧凑。已有54人学习下载适合需要快速掌握上述核心概念或准备数据管理培训材料的人群参考。1. 数据元、元数据与主数据先分清三个“数据”再谈治理在做资源目录方案时我经常被问到同一个问题数据元、元数据、主数据到底有什么区别不少团队把这三样混在一个 Excel 里结果数据字典有模板接口字段却对不上主数据项目做了一年最后发现清理的其实是交易数据。实际上数据元是字段级的原子标准元数据是描述数据的数据主数据是企业跨系统共享的核心实体。这个顺序没理清后面建数据平台、做驾驶舱、搞碳排数字化都会返工。这些内容适合数据治理工程师、数据平台开发者和架构师。很多项目一开始就在纠结“主数据平台选型”其实应该先把数据元建模和元数据管理做扎实因为主数据治理的实体字段最终都要落在数据元上元数据血缘又决定了资源目录里“数据从哪来、到哪里去”能否被解释清楚。下面按数据元建模、元数据管理、主数据管理与资源目录落地的顺序拆解。2. 数据元建模把字段级标准做成可落地的数据字典2.1 数据元三要素对象、特性、表示数据元的核心结构有三个词对象、特性、表示。对象词回答“数据说的是谁”比如“船员”“船舶”“人”特性词回答“描述对象的哪个方面”比如“登记”“种类”“国籍”表示词回答“用什么形式写出来”比如“代码”“名称”“号”。三个部分合起来才能定义一个稳定的数据元。反过来如果只定义一个“姓名”对象、特性、表示都没有指明不同系统就会产生“person_name”“name_cn”“姓名全拼”之类的分裂字段。以资源里的“船员登记号”为例“船员”是对象词“登记”是特性词“号”是表示词。再比如“船舶种类代码”“船舶”是对象词“种类”是特性词“代码”是表示词。这种命名法让数据元名称本身可读而且能反推业务语义。数据元被定义为一组属性描述的数据单元标准依据是 GB/T 18391.1-2002核心特征是“不可再分”。一个组合表达式比如“姓名证件号码”就不是数据元。为什么“不可再分”如此重要因为数据模型追求稳定。同一个“公民身份号码”在源系统里可能是 18 位字符串在交换文件里可能是带大写 X 的编码但数据元的定义和值域必须只有一个版本。把不可再分的原子点找出来后续字段映射和值域校验才有依据。我在项目里常把数据元比作“字段的身份证号”一张表的列只是它的一个临时载体。2.2 数据元集的设计与字段映射数据元不是单独定义而是按“集”来管理。一个数据元集通常包含中文名称、标识符、英文名称、定义、对象类、特性、表示、格式、值域等属性。在船员/人员基本信息这类场景里常见的表结构如下中文名称标识符英文名称定义对象类特性表示格式姓名PAT00_100020Person-name由人的姓和名组成的字符串人姓名名称A[A(29)]性别代码PAT00_100031Person-sex, code男性与女性之间的生物学区分用代码表示人性别代码N(1)身份证件号码PAT00_100026Number of identity card表示个人的身份证件的号码人证件号码识别号N[N(18)]船员登记号CY010100001CrewRegNum船员的唯一识别号船员登记号an9标识符的写法也值得花时间。以“CY010100001”为例CY 是分类域01 是基本信息类0100 是序列编号001 是版本或子序号。实际项目中我一般把标识符设计成“域_分类_序号_版本”比如 CY_BASE_001_V1便于程序解析和人工识别。物理表字段名可以从数据元名称派生但不能直接叫 CY010100001否则可读性太差。所以还需要一层映射关系把物理列名、物理类型、数据元标识符关联起来。这个映射表就是资源目录里“字段级资产台账”的基础。2.3 用 SQL 落地数据元与字段的对应关系落地时第一步是把数据元集装载到元数据库再写查询去检查物理表是否遵守字典约束。下面是项目里常用的映射表 DDL-- 数据元映射表打通数据元与物理表字段 CREATE TABLE dim_meta.field_mapping ( data_element_id VARCHAR(32) NOT NULL COMMENT 数据元标识符如 CY010100001, data_element_name VARCHAR(64) NOT NULL COMMENT 数据元中文名称, table_schema VARCHAR(64) NOT NULL COMMENT 物理表所属库/Schema, table_name VARCHAR(64) NOT NULL COMMENT 物理表名, column_name VARCHAR(64) NOT NULL COMMENT 物理字段名, data_type VARCHAR(32) COMMENT 字段类型, format_rule VARCHAR(128) COMMENT 格式约束如 an9、N[N(18)], value_domain VARCHAR(256) COMMENT 值域或代码表名, source_system VARCHAR(64) COMMENT 来源系统, effective_date DATE COMMENT 生效日期, expired_date DATE COMMENT 失效日期, PRIMARY KEY (data_element_id, table_schema, table_name, column_name) );这段 DDL 的关键是复合主键。数据元与物理字段是多对多关系一个数据元可以被多张表引用一张表也能包含多个数据元的派生字段。如果不加这个主键同名同字段的加载任务会重复插入元数据资产台账就乱了。format_rule 字段建议后续改成 JSON比如{type:numeric,min:0,max:18}这样能直接在规则引擎里做数值范围校验而不是靠人工读字符型规则。第二步用 information_schema 找出那些没有被数据元覆盖的物理字段-- 检查未登记数据元的物理字段 SELECT c.table_schema, c.table_name, c.column_name, c.data_type, m.data_element_id FROM information_schema.columns c LEFT JOIN dim_meta.field_mapping m ON m.table_schema c.table_schema AND m.table_name c.table_name AND m.column_name c.column_name WHERE c.table_schema dwd AND c.column_name NOT IN (id, create_time, update_time, etl_time) AND m.data_element_id IS NULL ORDER BY c.table_name, c.ordinal_position;这里排除了一组 ETL 公共字段因为这些字段要交给技术元数据管理不需要登记为业务数据元。执行后如果返回多行说明开发建表时没有走数据元字典需要补充登记或重新评审模型。table_schemadwd要改成你的目标层名称如果用 Hive可以查 Hive Metastore 的COLUMNS_V2表或者使用 Hive 的information_schema。这样数据元定义就从文档变成了建表前检查项而不是一堆没人看的截图。3. 元数据管理实战分层采集与血缘梳理3.1 业务元数据、技术元数据、管理元数据的分层元数据管理最难的不是采集而是分类。如果把所有元数据都塞进一个大列表业务人员不知道填什么开发人员也不知道哪里要消费。比较稳妥的做法是先按业务、技术、管理三个层级切分。业务元数据描述业务概念、指标口径和规则。典型内容有业务术语、信息分类、指标定义、业务规则。技术元数据描述数据结构、处理过程和技术连接。典型内容有源系统 IP、数据库类型、源表名、目标表名、ETL 抽取规则、调度信息。管理元数据描述数据资产的治理角色和流程。典型内容有责任人员、岗位职责、更新周期、权限归属。用一张表概括获取方式和典型内容类型典型内容获取方式典型示例业务元数据业务术语、指标定义、信息分类、业务规则手工为主需版本化“船员违法记分”的统计口径技术元数据源系统连接、源表字段、ETL 规则、目标表结构、调度信息自动采集source_table.col1 target_table.col1管理元数据责任人、注册机构、更新周期、数据质量规则手工审批流程维护者、更新频率从实践来看业务元数据最容易变成没人维护的死文档原因是它没有和物理字段绑定。比较好的做法是在指标定义里增加“口径来源”字段任何改口径的操作都必须先改元数据再改计算脚本。技术元数据则相反必须强制自动采集因为源系统表结构随时在变靠人填一定滞后。管理元数据可以跟配置项系统结合职责变化时自动通知下游订阅方。3.2 ETL 元数据采集从 information_schema 到 Hive 元数据库技术元数据的采集要尽量自动化。PostgreSQL/MySQL 可以直接查 information_schemaHive 可以查 Metastore 或使用 Hive 的 information_schema。下面是一个典型的 MySQL 采集脚本输出 JSON 快照给元数据管理系统消费import pymysql import json # 使用只读元数据账号避免与业务请求争抢连接 conn pymysql.connect( host10.0.0.5, usermeta_reader, password********, databaseinformation_schema, connect_timeout5 ) cur conn.cursor() cur.execute( SELECT table_name, column_name, data_type, column_comment FROM columns WHERE table_schema dwd ORDER BY table_name, ordinal_position ) tables {} for table_name, column_name, data_type, comment in cur.fetchall(): tables.setdefault(table_name, []).append({ column: column_name, type: data_type, comment: comment, }) cur.close() conn.close() # 写入元数据文件供后续血缘分析模块读取 with open(/data/meta/dwd_columns.json, w, encodingutf-8) as f: json.dump(tables, f, ensure_asciiFalse, indent2)参数说明host、user、password 和 database 要根据实际环境替换强烈建议使用只读账号并且配置 connect_timeout防止元数据采集任务长时间卡死。脚本把表字段明细输出成 JSON元数据管理系统再用这个文件去比对上一日快照。如果发现表新增字段、字段类型变化、字段消失就生成告警事件。在实际项目中我会把这个脚本挂到 Airflow 或调度平台上每天凌晨执行一次输出结果写入专门的元数据库而不是本地文件。注意元数据账号不要使用应用账号否则采集任务可能拖慢核心业务查询。3.3 元数据质量问题排查NFO、Word、Dify 与 btrfs 的启示元数据不只存在于企业数据仓库。比如影音刮削库里的 NFO 文件本质就是视频的元数据如果 XML 编码或 title 字段缺失整个媒体库会展示成乱码Word 文档导出的报告如果不做元数据脱敏作者姓名和修订记录会跟着文件外发Dify 知识库加上元数据过滤后如果过滤字段设置错了检索会召回超出范围的段落btrfs 文件系统上元数据坏块更是会导致子卷无法挂载。这些场景看似无关其实都在验证同一件事元数据必须有校验、备份和版本回溯机制否则“数据的数据”会反过来拖垮业务。企业级元数据管理平台通常分四层获取层、存储层、功能层、应用层。获取层负责从数据字典、数据模型和 ETL 工具自动抽取技术元数据业务元数据和管理元数据通过手工或流程录入存储层用元模型约束三类元数据的结构功能层提供基本功能、血缘分析、质量管理和权限控制应用层面向具体场景比如指标库管理、术语学习、接口管理。在做资源目录时接口管理和血缘分析是使用频次最高的两个模块一个字段改名通过血缘能查到他影响哪几张报表比挨个问数据负责人高效得多。4. 主数据管理与资源目录方案从清洗到编目4.1 主数据的特征与主数据管理的建设目标主数据和数据元的重要区别在于数据元回答“字段应该长什么样”而主数据回答“核心业务实体是谁”。典型的航运海事场景里船员基础信息、船员证书信息属于基础型主数据船员服务资历、船员培训信息、船员记分信息属于动态数据但动态数据也要通过船员编号关联到主数据记录。在 SAP 系统中物料主数据的创建、修改、查看分别由 MM01、MM02、MM03 事务码完成项目里经常需要在这几个标准屏幕增强自定义字段这也是主数据管理常见的改造点。主数据管理MDM的建设目标不是“建一张大表”。好的 MDM 要同时满足清晰的主数据管理范畴、明确的主数据管理流程、良好的系统主数据质量、弹性的系统架构、通畅的交互接口、完善的功能。很多项目把 MDM 做成了又一个数据仓库只做采集和建模没有做合并规则、认责机制和接口管理结果主数据里“一人多码”“一码多船”更严重。4.2 主数据合并去重用 Python 做相似度匹配主数据合并的第一步是识别不同系统里指向同一实体的记录。最直接的方式是强字段匹配比如统一社会信用代码、船员服务簿号码但没有强字段时文本相似度兜底很关键。下面是一个基于 difflib 的预匹配示例from difflib import SequenceMatcher # 主数据预匹配找出不同系统里的同义名称 candidates [ (华东物流集团有限公司, 华东物流有限公司), (张三, 张 三), (ACME Shipping, ACME SHIPPING CO), ] def similarity(a, b): return SequenceMatcher(None, a, b).ratio() for a, b in candidates: score similarity(a, b) if score 0.8: print(f建议合并: {a} - {b}相似度 {score:.2%}) else: print(f需人工复核: {a} vs {b}相似度 {score:.2%})这个脚本的逻辑很简单SequenceMatcher 按字符顺序计算两个字符串的相似度score 高于 0.8 就进入合并建议池。参数上score 阈值不建议固定我会在 0.7 至 0.85 之间开一个“待确认池”因为真实场景里同一实体的名称可能只差一个“有限”“集团”后缀直接按相似度合并容易误伤。更稳妥的做法是先做名称标准化比如去掉“有限公司”“集团”等词再用证件号或唯一编码做强匹配。合并时必须保存 old_master_id 到 new_master_id 的映射否则下游系统引用旧编号的记录会全部失效。注意文本相似度只适合预匹配不要直接用相似度阈值做主数据合并的唯一依据。4.3 资源目录方案把主数据、数据元、元数据串起来有了数据元、元数据和主数据地图最后要落到资源目录。资源目录的本质是把“有什么数据、谁在用、谁能用、怎么取”变成一个可检索的清单。我常把资源目录设计成四级目录域、资源项、数据元集、物理实现。每一个资源项下面都要挂数据元标识、元数据描述和主数据实体编码。资源编号资源名称业务域数据元标识主数据实体源系统更新频率RSC-0001船员基础信息船员管理CY010100001船员主数据船员管理系统天RSC-0002船舶基础信息船舶管理SHIP010200002船舶主数据船舶登记系统月RSC-0003船员违法记分船员管理PEN030400003违法记分事实数据行政处罚系统实时这个表里的“违法记分”不是主数据但也要在资源目录里登记因为它引用船员主数据。换句话说资源目录不是主数据的专属目录而是所有共享数据的入口主数据定义“这个船员是谁”事实数据定义“这个船员做了什么”。资源目录还要同时记录访问权限和脱敏规则比如船员手机号、身份证号属于敏感数据目录里可以展示元数据标签但申请数据时必须走脱敏授权。5. 验证 MDM 发布用 SQL 检查资源目录的映射完整性5.1 新旧主数据映射的完整性校验在 MDM 发布主数据合并结果后第一件事不是看报表而是检查新旧编码映射是否完整。资源目录里的资源项可能仍引用旧主数据 ID如果不校验映射会出现历史数据读不到、新数据写不进的情况。下面这段 SQL 用来找出没有映射到新 ID 的资源项-- 校验 MDM 发布后资源目录的新旧主数据映射 SELECT src.source_system, src.old_master_id, src.rsc_name, COALESCE(m.new_master_id, MISSING) AS new_master_id, CASE WHEN m.new_master_id IS NULL THEN 映射缺失 ELSE 正常 END AS mapping_status FROM dim_meta.resource_catalog src LEFT JOIN mdm.master_mapping m ON src.master_id m.old_master_id WHERE src.data_version 2025-06-30 AND src.master_id IS NOT NULL ORDER BY mapping_status DESC, src.source_system;逻辑说明resource_catalog 是资源目录表master_id 保存着资源项引用的主数据旧编码master_mapping 维护旧编码到新编码的映射。通过 LEFT JOIN把映射缺失的记录全部暴露出来。参数上data_version 是资源目录数据版本号每次发布都要带版本便于回溯source_system 用来区分来源可以把问题记录精准反馈到对应系统负责人。如果返回结果中“映射缺失”数量很大说明 MDM 的合并规则没有覆盖全集不能发布需要回退清洗流程。我一般会把这条查询封装成一个带 batch_id 的存储过程同时统计所有下游接口调用频次生成一个“断链影响面”清单。实际发布时把这段 SQL 放进 CI/CD 的数据库变更脚本里遇到映射缺失就终止发布并回滚等补全映射后再放行。本文还有配套的精品资源点击获取 数据元、元数据与主数据：数据治理的三大核心概念实践
简介这份演示文稿围绕数据元、元数据、主数据、主数据管理、元数据管理及资源目录方案展开面向数据治理与数字化建设从业者及数据管理新人。内容从数据元“不可再分的最小数据单元”定义讲起结合“船舶种类代码”“船员登记号”等实例拆解对象、特性、表示三要素并通过数据元集信息示例说明字段命名与数据元对应关系接着区分元数据与主数据的定位说明元数据是“描述数据的数据”、是数据与用户之间的桥梁并解释MDM如何创建单一、一致、可靠的主数据视图以及元数据管理MM如何融入数据治理与质量控制。最后落到资源目录方案关联碳排放数字化建设与数字化驾驶舱建设等典型场景帮助读者把概念应用到实际项目中。压缩包内为单个演示文稿文件大小9.55MB结构紧凑。已有54人学习下载适合需要快速掌握上述核心概念或准备数据管理培训材料的人群参考。1. 数据元、元数据与主数据先分清三个“数据”再谈治理在做资源目录方案时我经常被问到同一个问题数据元、元数据、主数据到底有什么区别不少团队把这三样混在一个 Excel 里结果数据字典有模板接口字段却对不上主数据项目做了一年最后发现清理的其实是交易数据。实际上数据元是字段级的原子标准元数据是描述数据的数据主数据是企业跨系统共享的核心实体。这个顺序没理清后面建数据平台、做驾驶舱、搞碳排数字化都会返工。这些内容适合数据治理工程师、数据平台开发者和架构师。很多项目一开始就在纠结“主数据平台选型”其实应该先把数据元建模和元数据管理做扎实因为主数据治理的实体字段最终都要落在数据元上元数据血缘又决定了资源目录里“数据从哪来、到哪里去”能否被解释清楚。下面按数据元建模、元数据管理、主数据管理与资源目录落地的顺序拆解。2. 数据元建模把字段级标准做成可落地的数据字典2.1 数据元三要素对象、特性、表示数据元的核心结构有三个词对象、特性、表示。对象词回答“数据说的是谁”比如“船员”“船舶”“人”特性词回答“描述对象的哪个方面”比如“登记”“种类”“国籍”表示词回答“用什么形式写出来”比如“代码”“名称”“号”。三个部分合起来才能定义一个稳定的数据元。反过来如果只定义一个“姓名”对象、特性、表示都没有指明不同系统就会产生“person_name”“name_cn”“姓名全拼”之类的分裂字段。以资源里的“船员登记号”为例“船员”是对象词“登记”是特性词“号”是表示词。再比如“船舶种类代码”“船舶”是对象词“种类”是特性词“代码”是表示词。这种命名法让数据元名称本身可读而且能反推业务语义。数据元被定义为一组属性描述的数据单元标准依据是 GB/T 18391.1-2002核心特征是“不可再分”。一个组合表达式比如“姓名证件号码”就不是数据元。为什么“不可再分”如此重要因为数据模型追求稳定。同一个“公民身份号码”在源系统里可能是 18 位字符串在交换文件里可能是带大写 X 的编码但数据元的定义和值域必须只有一个版本。把不可再分的原子点找出来后续字段映射和值域校验才有依据。我在项目里常把数据元比作“字段的身份证号”一张表的列只是它的一个临时载体。2.2 数据元集的设计与字段映射数据元不是单独定义而是按“集”来管理。一个数据元集通常包含中文名称、标识符、英文名称、定义、对象类、特性、表示、格式、值域等属性。在船员/人员基本信息这类场景里常见的表结构如下中文名称标识符英文名称定义对象类特性表示格式姓名PAT00_100020Person-name由人的姓和名组成的字符串人姓名名称A[A(29)]性别代码PAT00_100031Person-sex, code男性与女性之间的生物学区分用代码表示人性别代码N(1)身份证件号码PAT00_100026Number of identity card表示个人的身份证件的号码人证件号码识别号N[N(18)]船员登记号CY010100001CrewRegNum船员的唯一识别号船员登记号an9标识符的写法也值得花时间。以“CY010100001”为例CY 是分类域01 是基本信息类0100 是序列编号001 是版本或子序号。实际项目中我一般把标识符设计成“域_分类_序号_版本”比如 CY_BASE_001_V1便于程序解析和人工识别。物理表字段名可以从数据元名称派生但不能直接叫 CY010100001否则可读性太差。所以还需要一层映射关系把物理列名、物理类型、数据元标识符关联起来。这个映射表就是资源目录里“字段级资产台账”的基础。2.3 用 SQL 落地数据元与字段的对应关系落地时第一步是把数据元集装载到元数据库再写查询去检查物理表是否遵守字典约束。下面是项目里常用的映射表 DDL-- 数据元映射表打通数据元与物理表字段 CREATE TABLE dim_meta.field_mapping ( data_element_id VARCHAR(32) NOT NULL COMMENT 数据元标识符如 CY010100001, data_element_name VARCHAR(64) NOT NULL COMMENT 数据元中文名称, table_schema VARCHAR(64) NOT NULL COMMENT 物理表所属库/Schema, table_name VARCHAR(64) NOT NULL COMMENT 物理表名, column_name VARCHAR(64) NOT NULL COMMENT 物理字段名, data_type VARCHAR(32) COMMENT 字段类型, format_rule VARCHAR(128) COMMENT 格式约束如 an9、N[N(18)], value_domain VARCHAR(256) COMMENT 值域或代码表名, source_system VARCHAR(64) COMMENT 来源系统, effective_date DATE COMMENT 生效日期, expired_date DATE COMMENT 失效日期, PRIMARY KEY (data_element_id, table_schema, table_name, column_name) );这段 DDL 的关键是复合主键。数据元与物理字段是多对多关系一个数据元可以被多张表引用一张表也能包含多个数据元的派生字段。如果不加这个主键同名同字段的加载任务会重复插入元数据资产台账就乱了。format_rule 字段建议后续改成 JSON比如{type:numeric,min:0,max:18}这样能直接在规则引擎里做数值范围校验而不是靠人工读字符型规则。第二步用 information_schema 找出那些没有被数据元覆盖的物理字段-- 检查未登记数据元的物理字段 SELECT c.table_schema, c.table_name, c.column_name, c.data_type, m.data_element_id FROM information_schema.columns c LEFT JOIN dim_meta.field_mapping m ON m.table_schema c.table_schema AND m.table_name c.table_name AND m.column_name c.column_name WHERE c.table_schema dwd AND c.column_name NOT IN (id, create_time, update_time, etl_time) AND m.data_element_id IS NULL ORDER BY c.table_name, c.ordinal_position;这里排除了一组 ETL 公共字段因为这些字段要交给技术元数据管理不需要登记为业务数据元。执行后如果返回多行说明开发建表时没有走数据元字典需要补充登记或重新评审模型。table_schemadwd要改成你的目标层名称如果用 Hive可以查 Hive Metastore 的COLUMNS_V2表或者使用 Hive 的information_schema。这样数据元定义就从文档变成了建表前检查项而不是一堆没人看的截图。3. 元数据管理实战分层采集与血缘梳理3.1 业务元数据、技术元数据、管理元数据的分层元数据管理最难的不是采集而是分类。如果把所有元数据都塞进一个大列表业务人员不知道填什么开发人员也不知道哪里要消费。比较稳妥的做法是先按业务、技术、管理三个层级切分。业务元数据描述业务概念、指标口径和规则。典型内容有业务术语、信息分类、指标定义、业务规则。技术元数据描述数据结构、处理过程和技术连接。典型内容有源系统 IP、数据库类型、源表名、目标表名、ETL 抽取规则、调度信息。管理元数据描述数据资产的治理角色和流程。典型内容有责任人员、岗位职责、更新周期、权限归属。用一张表概括获取方式和典型内容类型典型内容获取方式典型示例业务元数据业务术语、指标定义、信息分类、业务规则手工为主需版本化“船员违法记分”的统计口径技术元数据源系统连接、源表字段、ETL 规则、目标表结构、调度信息自动采集source_table.col1 target_table.col1管理元数据责任人、注册机构、更新周期、数据质量规则手工审批流程维护者、更新频率从实践来看业务元数据最容易变成没人维护的死文档原因是它没有和物理字段绑定。比较好的做法是在指标定义里增加“口径来源”字段任何改口径的操作都必须先改元数据再改计算脚本。技术元数据则相反必须强制自动采集因为源系统表结构随时在变靠人填一定滞后。管理元数据可以跟配置项系统结合职责变化时自动通知下游订阅方。3.2 ETL 元数据采集从 information_schema 到 Hive 元数据库技术元数据的采集要尽量自动化。PostgreSQL/MySQL 可以直接查 information_schemaHive 可以查 Metastore 或使用 Hive 的 information_schema。下面是一个典型的 MySQL 采集脚本输出 JSON 快照给元数据管理系统消费import pymysql import json # 使用只读元数据账号避免与业务请求争抢连接 conn pymysql.connect( host10.0.0.5, usermeta_reader, password********, databaseinformation_schema, connect_timeout5 ) cur conn.cursor() cur.execute( SELECT table_name, column_name, data_type, column_comment FROM columns WHERE table_schema dwd ORDER BY table_name, ordinal_position ) tables {} for table_name, column_name, data_type, comment in cur.fetchall(): tables.setdefault(table_name, []).append({ column: column_name, type: data_type, comment: comment, }) cur.close() conn.close() # 写入元数据文件供后续血缘分析模块读取 with open(/data/meta/dwd_columns.json, w, encodingutf-8) as f: json.dump(tables, f, ensure_asciiFalse, indent2)参数说明host、user、password 和 database 要根据实际环境替换强烈建议使用只读账号并且配置 connect_timeout防止元数据采集任务长时间卡死。脚本把表字段明细输出成 JSON元数据管理系统再用这个文件去比对上一日快照。如果发现表新增字段、字段类型变化、字段消失就生成告警事件。在实际项目中我会把这个脚本挂到 Airflow 或调度平台上每天凌晨执行一次输出结果写入专门的元数据库而不是本地文件。注意元数据账号不要使用应用账号否则采集任务可能拖慢核心业务查询。3.3 元数据质量问题排查NFO、Word、Dify 与 btrfs 的启示元数据不只存在于企业数据仓库。比如影音刮削库里的 NFO 文件本质就是视频的元数据如果 XML 编码或 title 字段缺失整个媒体库会展示成乱码Word 文档导出的报告如果不做元数据脱敏作者姓名和修订记录会跟着文件外发Dify 知识库加上元数据过滤后如果过滤字段设置错了检索会召回超出范围的段落btrfs 文件系统上元数据坏块更是会导致子卷无法挂载。这些场景看似无关其实都在验证同一件事元数据必须有校验、备份和版本回溯机制否则“数据的数据”会反过来拖垮业务。企业级元数据管理平台通常分四层获取层、存储层、功能层、应用层。获取层负责从数据字典、数据模型和 ETL 工具自动抽取技术元数据业务元数据和管理元数据通过手工或流程录入存储层用元模型约束三类元数据的结构功能层提供基本功能、血缘分析、质量管理和权限控制应用层面向具体场景比如指标库管理、术语学习、接口管理。在做资源目录时接口管理和血缘分析是使用频次最高的两个模块一个字段改名通过血缘能查到他影响哪几张报表比挨个问数据负责人高效得多。4. 主数据管理与资源目录方案从清洗到编目4.1 主数据的特征与主数据管理的建设目标主数据和数据元的重要区别在于数据元回答“字段应该长什么样”而主数据回答“核心业务实体是谁”。典型的航运海事场景里船员基础信息、船员证书信息属于基础型主数据船员服务资历、船员培训信息、船员记分信息属于动态数据但动态数据也要通过船员编号关联到主数据记录。在 SAP 系统中物料主数据的创建、修改、查看分别由 MM01、MM02、MM03 事务码完成项目里经常需要在这几个标准屏幕增强自定义字段这也是主数据管理常见的改造点。主数据管理MDM的建设目标不是“建一张大表”。好的 MDM 要同时满足清晰的主数据管理范畴、明确的主数据管理流程、良好的系统主数据质量、弹性的系统架构、通畅的交互接口、完善的功能。很多项目把 MDM 做成了又一个数据仓库只做采集和建模没有做合并规则、认责机制和接口管理结果主数据里“一人多码”“一码多船”更严重。4.2 主数据合并去重用 Python 做相似度匹配主数据合并的第一步是识别不同系统里指向同一实体的记录。最直接的方式是强字段匹配比如统一社会信用代码、船员服务簿号码但没有强字段时文本相似度兜底很关键。下面是一个基于 difflib 的预匹配示例from difflib import SequenceMatcher # 主数据预匹配找出不同系统里的同义名称 candidates [ (华东物流集团有限公司, 华东物流有限公司), (张三, 张 三), (ACME Shipping, ACME SHIPPING CO), ] def similarity(a, b): return SequenceMatcher(None, a, b).ratio() for a, b in candidates: score similarity(a, b) if score 0.8: print(f建议合并: {a} - {b}相似度 {score:.2%}) else: print(f需人工复核: {a} vs {b}相似度 {score:.2%})这个脚本的逻辑很简单SequenceMatcher 按字符顺序计算两个字符串的相似度score 高于 0.8 就进入合并建议池。参数上score 阈值不建议固定我会在 0.7 至 0.85 之间开一个“待确认池”因为真实场景里同一实体的名称可能只差一个“有限”“集团”后缀直接按相似度合并容易误伤。更稳妥的做法是先做名称标准化比如去掉“有限公司”“集团”等词再用证件号或唯一编码做强匹配。合并时必须保存 old_master_id 到 new_master_id 的映射否则下游系统引用旧编号的记录会全部失效。注意文本相似度只适合预匹配不要直接用相似度阈值做主数据合并的唯一依据。4.3 资源目录方案把主数据、数据元、元数据串起来有了数据元、元数据和主数据地图最后要落到资源目录。资源目录的本质是把“有什么数据、谁在用、谁能用、怎么取”变成一个可检索的清单。我常把资源目录设计成四级目录域、资源项、数据元集、物理实现。每一个资源项下面都要挂数据元标识、元数据描述和主数据实体编码。资源编号资源名称业务域数据元标识主数据实体源系统更新频率RSC-0001船员基础信息船员管理CY010100001船员主数据船员管理系统天RSC-0002船舶基础信息船舶管理SHIP010200002船舶主数据船舶登记系统月RSC-0003船员违法记分船员管理PEN030400003违法记分事实数据行政处罚系统实时这个表里的“违法记分”不是主数据但也要在资源目录里登记因为它引用船员主数据。换句话说资源目录不是主数据的专属目录而是所有共享数据的入口主数据定义“这个船员是谁”事实数据定义“这个船员做了什么”。资源目录还要同时记录访问权限和脱敏规则比如船员手机号、身份证号属于敏感数据目录里可以展示元数据标签但申请数据时必须走脱敏授权。5. 验证 MDM 发布用 SQL 检查资源目录的映射完整性5.1 新旧主数据映射的完整性校验在 MDM 发布主数据合并结果后第一件事不是看报表而是检查新旧编码映射是否完整。资源目录里的资源项可能仍引用旧主数据 ID如果不校验映射会出现历史数据读不到、新数据写不进的情况。下面这段 SQL 用来找出没有映射到新 ID 的资源项-- 校验 MDM 发布后资源目录的新旧主数据映射 SELECT src.source_system, src.old_master_id, src.rsc_name, COALESCE(m.new_master_id, MISSING) AS new_master_id, CASE WHEN m.new_master_id IS NULL THEN 映射缺失 ELSE 正常 END AS mapping_status FROM dim_meta.resource_catalog src LEFT JOIN mdm.master_mapping m ON src.master_id m.old_master_id WHERE src.data_version 2025-06-30 AND src.master_id IS NOT NULL ORDER BY mapping_status DESC, src.source_system;逻辑说明resource_catalog 是资源目录表master_id 保存着资源项引用的主数据旧编码master_mapping 维护旧编码到新编码的映射。通过 LEFT JOIN把映射缺失的记录全部暴露出来。参数上data_version 是资源目录数据版本号每次发布都要带版本便于回溯source_system 用来区分来源可以把问题记录精准反馈到对应系统负责人。如果返回结果中“映射缺失”数量很大说明 MDM 的合并规则没有覆盖全集不能发布需要回退清洗流程。我一般会把这条查询封装成一个带 batch_id 的存储过程同时统计所有下游接口调用频次生成一个“断链影响面”清单。实际发布时把这段 SQL 放进 CI/CD 的数据库变更脚本里遇到映射缺失就终止发布并回滚等补全映射后再放行。本文还有配套的精品资源点击获取