元数据管理

元数据是描述数据资源特征、背景、结构、来源、管理方式和使用条件的信息，常被概括为“关于数据的数据”。对一份销售记录，元数据可以说明字段含义、采集系统、更新周期、适用时间、责任人、语言、访问限制和版本。元数据管理则是制定这些说明如何产生、维护、关联、查找和验证的一套流程与工具。它不是给文件加几个关键词就结束，也不等同数据本身或一份静态数据字典。良好的元数据让人和机器理解一项数据是什么、谁负责、怎样解释、何时更新、在哪里使用以及有何限制，是数据目录、治理、集成和知识发现的基础。

描述性元数据帮助发现和辨认资源，如标题、摘要、主题词和语言；结构性元数据描述资源如何组织，如数据库表与字段关系、文件序列、分区或产品变体层级；管理性元数据支持创建、使用和维护，可再细分为技术信息、权利与权限、来源与变更记录等。类别是分析视角，不一定要在系统中拆成独立仓库。同一个字段可同时承担多种角色：数据集“更新时间”既帮助用户判断新旧，也参与调度；图像的语言、版权和替代文本则分别支持检索、使用授权与无障碍呈现。分类时关注实际问题及责任归属，比争论某字段只能归属一个类别更重要。

数据字典通常解释字段名称、类型、定义、允许值和示例；术语库围绕概念及多语表达组织专业词汇；数据目录把数据集、报表、接口或模型等资源登记为可查找的资产；元数据覆盖这些资源和各类治理信息。它们有交集但不能互相替代。目录页面的描述字段本身也是元数据，术语库可以控制主题标签的用词，数据字典则说明某字段表示什么。比如“净销售额”需在字典中定义计算和币种，在术语库中管理多语言名称，在目录中指向权威数据集及负责人。若只建一个全局自由文本搜索框，用户仍无法区分字段定义、主题词、来源和访问限制。

稳定标识用于跨文件、目录和系统引用资源及字段；显示名称便于人阅读，不能承担唯一身份功能。DCMI建议为元数据术语分配唯一URI，并维护相应术语声明；W3C DCAT使用标准词汇描述目录、数据集、分发形式、数据服务和版本关系。采用通用词汇可减少映射摩擦，但标准并不覆盖所有行业需求。实施时要约定命名空间、属性映射、允许扩展、版本升级与弃用方式。相同标签也可能有不同定义：一个系统里的“客户数”可能数订单账户，另一个数法律主体。只有标识、定义、范围和计算方式可检索，消费者才能知道同名字段是否相同。

元数据模型定义可描述哪些对象及彼此关系，应用规范（application profile）则说明组织如何组合已有词汇、哪些字段必填、字段约束和如何序列化。DCMI Metadata Terms包含多种属性、类别和编码方案，允许与兼容词汇组合；DCAT描述数据目录中的数据集、数据服务、分发形式及记录。组织无需采用RDF才能从这些定义获得设计参考，但若使用JSON、表格或关系数据库，应保留对应语义和映射文档。模型宜从关键用例反推：发现数据集需主题、摘要与访问位置；复现分析还需要版本、更新日期、来源与代码依赖。不要先收集大量字段，再期待用户猜出它们的价值。

元数据需回答资源来自哪里、何时创建、何时发布、最近何时修改、修改由谁发起以及是否替换旧版。对周期性数据集，数据覆盖期、发布时间和目录登记时间是不同时间概念；W3C DCAT专门区分数据集属性和目录记录登记信息，并支持版本关系。每次刷新可以新增版本，也可以在规则允许时更新原记录，但必须留存消费者能理解的历史。一个“最后更新时间”字段不足以解释数据本身有多新：目录可能刚被整理，底层销售记录仍是上月数据。元数据应连接到相应数据快照、发布批次、处理流程或源系统版本，避免“刚更新”造成误导。

数据血缘记录数据从来源经过哪些转换、连接和筛选，最终进入哪些报表、产品或模型。它与普通关联链接不同，强调产生和依赖路径。记录表到仓库视图再到季度报告的血缘，可以在源字段改变时评估受影响的消费者，也能在数字异常时找到转换环节。血缘粒度可从系统级、表级到字段级，不是所有用途都需要逐行追踪。关系应表明边的含义，例如派生自、使用、替代、属于产品、发布到接口；仅存一个通用related链接无法回答传播方向。自动提取的血缘也要标注工具、扫描时间和解析覆盖范围，未扫描到并不证明不存在依赖。

技术元数据描述表名、字段类型、主键、分区、文件格式、接口路径和作业依赖；业务元数据解释术语、使用场景、指标口径、责任团队、敏感级别和审批规则。二者连接后，工程师可以看到底层结构如何对应业务含义，业务用户也能追踪指标在管道中的位置。只自动扫描schema能提供结构，却无法知道“已完成订单”是否包含退款单；只写业务说明又无法判断哪个字段实现该定义。对关键指标，应链接定义、SQL或转换逻辑、源字段、数据版本和负责人。业务口径变化时同时检查技术实现，避免目录仍描述旧含义而报表已采用新算法。

元数据同样会过期。数据集改名、接口迁移、负责人离职、权限变化和业务口径调整，都可能使目录中的链接或说明失效。每类字段需明确由系统自动生成还是业务人员维护，自动内容也需确认扫描范围和刷新时点。可设置更新频率、失效提示和复核任务，对重要资产定期检查描述、负责人、访问方式、版本状态和敏感分类。元数据质量可检查必填覆盖率、链接可达、标识唯一、日期先后逻辑、字段定义完整和词表值有效。完整登记不意味着描述准确，因此高风险资产仍应由熟悉业务的人审核实际语义与限制。

元数据提升可发现性时，也可能暴露不应公开的信息。数据集名称、字段名、项目摘要甚至存在性，都可能泄露客户、员工、交易或未公开产品计划的线索。目录设计应区分公开元数据、组织内部元数据和受限元数据，并与数据本体的权限模型一致。对敏感字段可公开类别和责任人，而隐藏样本值、原始路径或个人识别信息；使用者可先看到申请渠道和用途条件，再通过授权取得数据。还需说明数据授权、允许用途、保留期限、区域处理和访问审核要求。简单加密元数据字段不能代替角色权限、最少披露和审计策略。

元数据本身也会本地化。数据集标题、摘要、主题词和字段说明可按语言维护，但应保留稳定的资源标识与各语言版本关系，避免翻译页面被误建成新数据集。语言标签、地区范围和分类代码需单独记录；“本地销售额”如不说明市场、币种和时间周期，不同使用者会套用不同含义。检索系统可结合首选词、别名、分类层级和机器可读代码，支持用户以不同语言找到同一资源。主题标签可辅助发现，却不等于字段事实，也不应把相近词自动当等义词。对缩写和产品内部名词，应链接到受控术语定义并显示适用范围。

检索增强生成和机器代理需要的不只是文档正文，还需知道文档属于什么实体、版本、语言、来源、适用场景与授权条件。元数据可帮助检索器过滤过时或无权使用的资源，帮助生成结果附上数据来源和更新时间；字段说明与单位信息有助于防止把数值理解错。但元数据必须跟正文保持一致，人工标签和自动抽取应区分，并标记可信状态。将未经审查的机器摘要写回目录，可能把推断伪装成官方说明。机器可读的元数据能改善发现与追溯条件，却不会自动保证系统遵循权限、正确归纳或引用某一资源。应通过查询测试、输出审核和变化监控验证实际效果。

元数据项目宜先选一类高频资产，例如商品属性、分析指标或跨境内容页面。梳理当前目录、数据库说明、表格清单和接口文档，确定资源身份、必要字段、维护者、词汇和版本策略。先覆盖用途最明确的字段，再与数据扫描、权限管理、术语库和血缘工具集成。效果可用关键资产可发现率、描述复核及时率、坏链比例、字段定义覆盖、重复资产数、血缘解析覆盖、权限申请处理时长及错误使用反馈衡量。按资产类型拆分指标，说明统计口径和更新周期。元数据治理应帮助人减少猜测、帮助系统准确关联资源；若字段无人使用且无人维护，应重新评估必要性。

信息架构组织用户如何浏览资源，分类法规定主题或类别的层级，元数据则提供每个资源可检索、可解释的描述及与分类概念的链接。比如一份“厨房空气炸锅安装说明”可以出现在网站的产品支持分类中，也可关联到“使用指南”“安全说明”主题，并以元数据注明型号、语言、发布日期和受众。分类层级解决概念的归属与导航问题，单个资源的元数据描述它自身；把二者混写会导致类别名称被当作产品属性，或同一内容只能在一个路径下被找到。可控词表要有概念标识、首选词及层级关系，资源记录则引用这些概念，并保留自由摘要以解释具体内容。

W3C《数据目录词汇表 DCAT 3》描述目录、数据集、数据服务、分发形式和版本关系；DCMI《元数据术语》定义可组合使用的属性、类别及编码方案；W3C《数据质量词汇表》示范质量信息及其来源如何附着到数据资源。来源：https://www.w3.org/TR/vocab-dcat-3/ ；https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ ；https://www.w3.org/TR/vocab-dqv/。 DCMI《DCMI命名空间政策》说明符合其抽象模型的术语使用唯一URI；美国国会图书馆《METS概览》介绍描述性、管理性及结构性元数据及其组织关系。来源：https://www.dublincore.org/specifications/dublin-core/dcmi-namespace/ ；https://www.loc.gov/standards/mets/METSOverview.v2.html。

84 container