想象你走进一座刚建成的超大型图书馆。书架上摆着几十万本“书”，它们是星河集团各部门生产的数据资产：销售订单、用户画像、推荐日志、模型特征……可这些书的书脊上，只有管理员随手写下的编号：有的写着“订单202401”，有的写着“odr_dt_03“，还有的根本没贴标签。想找一本书得翻遍全馆，两座分馆之间的书永远无法互通，读者借书全靠打听。书本身没问题，缺的是一套统一的”编目规则“。元数据标准要做的，正是给每本书颁发一张格式统一的”编目卡”——卡上写明这本书的内容摘要（业务元数据）、物理属性（技术元数据）和保管信息（管理元数据）。当所有书都按同一套规则编目，找书、跨馆借书、追踪流转全都顺畅了。AI 要取数训练时，也能像读者查目录一样，先看卡、再取书，又快又放心。接下来，我们跟着这座图书馆从混乱走向有序。

岗位关联

掌握元数据标准，是进入数据治理与 AI 平台建设的第一块敲门砖。它让你在设计数据目录、血缘系统与合规审计时拥有“内行”视角，成为团队里真正懂“数据语言”的人。

目录
  1. 可视化演示
  2. 1. 元数据概念：给数据资产发“编目卡”
  3. 2. 业务元数据：书的内容摘要
  4. 3. 技术元数据：书的物理属性
  5. 4. 管理元数据：书的保管档案
  6. 5. 统一标准设计：编目卡模板的诞生
  7. 6. 互操作与血缘：跨馆借书与流转追溯
  8. 7. 落地实施流程：从混乱到有序三步走
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示业务技术管理三类元数据的分类体系与字段示例、DCAT与CWM两种主流标准模型的实体结构对比、以及统一标准驱动的自动化血缘追踪从采集到图谱构建的全链路流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

元数据三分类体系 业务元数据描述业务术语与指标口径定义 技术元数据描述表结构与存储位置信息 3类 业务-技术-管理三分覆盖数据全生命周期

1. 元数据概念：给数据资产发“编目卡”

星河图书馆刚开馆时，管理员小星被问到“上个月华东区有多少退货订单”，他翻了三小时也没找到。因为每张表散落在不同部门，命名随意，字段含义靠猜。小星意识到：书很好，但没有一张书脊上的“编目标签”，一切检索都无从谈起。

数据世界里的“编目标签”就是元数据（Metadata），翻译过来是“关于数据的数据”。它不记录“订单金额=100元”这种明细，而是记录“这张表存什么、字段怎么定义、谁在维护、多久更新一次”。有了元数据，数据资产才能从一串二进制变为可检索、可理解、可信任的资源。

元数据标准首先规定“编目卡长什么样”，业内普遍将元数据分为三大类：业务元数据回答“What“——这张表在业务上是什么；技术元数据回答”How“——数据在技术上如何存储；管理元数据回答”Who/When“——谁负责、何时更新、质量如何。三张”小卡”合起来才是一张完整的编目卡。

第二天，小星把全馆书按统一格式贴上了标签，管理员们终于敢说：“这图书馆，开始有秩序了。”

M=Mbiz∪Mtech∪Mman\displaystyle \mathcal{M} = \mathcal{M}_{\text{biz}} \cup \mathcal{M}_{\text{tech}} \cup \mathcal{M}_{\text{man}}
一份完整的元数据 = 业务、技术、管理三类信息的并集；缺任何一类，编目卡就不完整。
  1. 业务元数据项记录数据的业务含义，如指标口径、业务术语和摘要说明。
    Mbiz={口径,术语,摘要}\displaystyle \mathcal{M}_{\text{biz}} = \{ \text{口径}, \text{术语}, \text{摘要} \}
  2. 技术元数据项记录数据的结构形态，如字段类型、存储格式和接口。
    Mtech={结构,存储,接口}\displaystyle \mathcal{M}_{\text{tech}} = \{ \text{结构}, \text{存储}, \text{接口} \}
  3. 管理元数据项记录数据的治理信息，如责任人、质量状态和生命周期。
    Mman={责任人,质量,生命周期}\displaystyle \mathcal{M}_{\text{man}} = \{ \text{责任人}, \text{质量}, \text{生命周期} \}
  4. 三类并集完整元数据是三个集合的并集，说明治理“三角”缺一不可。
    M=Mbiz∪Mtech∪Mman\displaystyle \mathcal{M} = \mathcal{M}_{\text{biz}} \cup \mathcal{M}_{\text{tech}} \cup \mathcal{M}_{\text{man}}

2. 业务元数据：书的内容摘要

编目卡上最重要的部分是“内容摘要”。同样一本书，如果摘要写“爱情小说”，读者绝不会借给要写代码的人；如果摘要写成“数据库性能优化案例”，想学技术的人会排队来借。摘要决定了书能否被“对的人”找到。

业务元数据就是数据的“摘要”，它包含三类信息：业务术语表（统一“成交额”与"GMV"这类近义词的定义）、数据字典（每个字段的业务含义）、口径与规则（统计时要不要剔除退款、单位是元还是万元）。

没有业务元数据，最典型的现象是“同名不同义”：财务说“销售额”含税，运营说“销售额”不含税，两个团队拿到同一个数字却给出两个结论。元数据标准要求每张表登记业务口径，把“可能打架”的定义在字典里钉死。

有了这三样，图书馆的“摘要栏”就写清楚了：任何读者翻开编目卡，都能判断“这书对我有没有用”。

Mbiz=(T, A, R)\displaystyle \mathcal{M}_{\text{biz}} = \left( \mathcal{T},\ \mathcal{A},\ \mathcal{R} \right)
业务元数据 = 术语表、属性字典、规则集三要素，构成“讲得清业务”的最小集合。
  1. 术语表统一业务名词，解决“同名不同义”。
    T={t1, t2, …, tk}\displaystyle \mathcal{T} = \{ t_{1},\ t_{2},\ \ldots,\ t_{k} \}
  2. 属性字典逐字段登记业务含义，让字段不再是天书。
    A={a1, a2, …, am}\displaystyle \mathcal{A} = \{ a_{1},\ a_{2},\ \ldots,\ a_{m} \}
  3. 规则集记录统计口径、单位换算与派生逻辑。
    R={r1, r2, …, rn}\displaystyle \mathcal{R} = \{ r_{1},\ r_{2},\ \ldots,\ r_{n} \}

3. 技术元数据：书的物理属性

编目卡上还有一行“物理信息”：精装还是平装、多少页、放在哪层书架。读者要借书，光知道内容好不行，还得知道上哪儿找、以什么形态借。

技术元数据回答的正是“数据在技术上长什么样”：表结构（有哪些字段、字段类型是什么、主外键关系）、存储与格式（存在 Hive 还是 MySQL，是 Parquet 还是 JSON）、接口与调度（通过什么接口读取、多久更新一次）。它让工程师能准确、高效地把数据读出来。

例如一张“用户画像表”，技术元数据会记录：user_id 是 STRING 且非空，age 是 INT 且允许为空，存储格式为 Parquet，分区字段为 dt。这些信息决定了工程师用什么方式解析、如何做分区裁剪，直接影响查询性能与正确性。

物理属性写清楚了，工程师就能像按书架号取书一样，按 Schema 精准地把数据取出来。

Schema={(fi, ti)∣i=1, 2, …, n}\displaystyle \text{Schema} = \left\{ \left( f_{i},\ t_{i} \right) \mid i = 1,\ 2,\ \ldots,\ n \right\}
表结构可看作“字段名—字段类型”的有序二元组集合，是技术元数据的核心骨架。
  1. 字段名表中每个列的唯一标识。
    fi\displaystyle f_{i}
  2. 类型约束该字段的数据类型，如 STRING、INT、DATE。
    ti\displaystyle t_{i}
  3. 二元组集合所有字段与其类型组合成的完整表结构。
    {(f1,t1), (f2,t2), …, (fn,tn)}\displaystyle \{ (f_{1}, t_{1}),\ (f_{2}, t_{2}),\ \ldots,\ (f_{n}, t_{n}) \}

4. 管理元数据：书的保管档案

编目卡最底部是“保管信息”：这本书谁采购的、何时入库、破损率如何、是否允许外借。没有这栏，馆藏管理就成了“只进不出”的黑洞。

管理元数据记录数据的治理属性：责任归属（表负责人、数据产品经理是谁）、质量规则（完整性、准确性、及时性的达标阈值）和生命周期状态（原始 raw → 清洗 cleaned → 特征 feature → 归档 archived）。它回答“这数据能不能信、出了问题找谁”。

在 AI 工程中，管理元数据直接支撑“数据可信任”：模型上线前，算法工程师会检查训练集的完整性分数；数据出问题时，沿着责任人字段可以快速找到“这本书的保管员”。完整性分数是最常用的治理指标，定义为一个数据资产已填写的必填元数据项占应填写的比例。

保管档案齐全后，馆长终于敢对董事会承诺：“每本书都有主人，每个问题都有答案。”

Cmeta=NfilledNrequired×100%\displaystyle C_{\text{meta}} = \frac{N_{\text{filled}}}{N_{\text{required}}} \times 100\%
元数据完整性 = 已填写的必填项数量 ÷ 应填写的必填项数量。100% 表示这张“编目卡”没有任何空栏。
  1. 已填写项数对必填属性逐项检查，非空就算填了。
    Nfilled=∑j=1m1[aj≠∅]\displaystyle N_{\text{filled}} = \sum_{j=1}^{m} \mathbb{1}[a_{j} \neq \emptyset]
  2. 应填写项数标准规定的必填属性总数量。
    Nrequired=m\displaystyle N_{\text{required}} = m
  3. 比率换算两项相除并乘 100%，得到完整性百分比。
    Cmeta=NfilledNrequired×100%\displaystyle C_{\text{meta}} = \frac{N_{\text{filled}}}{N_{\text{required}}} \times 100\%

5. 统一标准设计：编目卡模板的诞生

有了三类信息，接下来要回答一个更关键的问题：这张“编目卡”长什么样才算合格？如果业务团队用 A4 表格，技术团队用 CSV，研发团队用 JSON，三张卡互相看不懂，规则就等于没定。

统一标准设计包含三层内容：元模型（Meta-Model）定义所有编目卡必须有的属性模板——哪些字段必填、哪些选填、取值类型是什么；命名规范统一表名、字段名的前缀与风格（如业务表以 t_ 开头）；编码与枚举统一状态码、地区码、币种等枚举值的定义，杜绝“1 代表成功、Y 也代表成功”。

衡量一张卡是否“合格”，可以用标准符合度打分：给每个必填项赋予权重，逐项检查是否符合标准（命名对了得 1 分，枚举值合规得 1 分），加权求和得到 0 到 1 之间的分数。这个分数正是治理报表上的“编目合格率”。

模板定稿那天，小星把样卡贴在每个书库门口：“以后每本书上架，必须按这张卡来。”规则有了，全馆才有了共同的“语言”。

Sconf=∑i=1nwi⋅ci,∑i=1nwi=1,ci∈{0,1}\displaystyle S_{\text{conf}} = \sum_{i=1}^{n} w_{i} \cdot c_{i}, \qquad \sum_{i=1}^{n} w_{i} = 1, \qquad c_{i} \in \{0, 1\}
标准符合度 = 各检查项的权重乘以是否合规的加权和。权重总和为 1，所以分数介于 0 和 1 之间。
  1. 检查项状态每个规则项的合规标记，合规为 1，否则为 0。
    ci∈{0,1}\displaystyle c_{i} \in \{0, 1\}
  2. 权重分配每个检查项的重要程度，全部权重加起来等于 1。
    ∑i=1nwi=1\displaystyle \sum_{i=1}^{n} w_{i} = 1
  3. 加权求和逐项相乘后累加，得到最终符合度。
    Sconf=∑i=1nwi⋅ci\displaystyle S_{\text{conf}} = \sum_{i=1}^{n} w_{i} \cdot c_{i}

6. 互操作与血缘：跨馆借书与流转追溯

统一标准最大的价值，不是在单馆里自娱自乐，而是让分馆之间能“互借”。过去，销售分馆和推荐分馆用各自的语言描述同一批数据，双方对接要写无数张映射表；现在按同一套编目卡，书一拿出来，对方立刻认得出。

技术上这叫“跨系统互操作”：系统 A 导出的元数据，系统 B 不用人工翻译就能理解，因为双方的卡片模板、字段定义、枚举编码完全一致。在此基础上，自动化数据血缘追踪成为可能——当加工任务读取源表产出目标表时，系统自动记录一条“由谁到谁”的边，最终形成一张全链路的血缘图。

血缘图可以用有向图描述：节点是数据资产（表、视图、模型特征），边表示数据流向。当某张上游表字段被修改，血缘图能瞬间标出所有受影响的模型和报表；当 AI 模型效果异常，算法工程师沿血缘反向追踪，几分钟就能定位到“是哪本书被改坏了”。

分馆之间的书开始顺畅流转，借阅记录自动可查。馆长欣慰地说：“这才叫一个图书馆。”

Glineage=(V, E),eij=(vi→vj)  ⟺  vj 由 vi 加工得到\displaystyle \mathcal{G}_{\text{lineage}} = \left( \mathcal{V},\ \mathcal{E} \right), \qquad e_{ij} = (v_{i} \to v_{j}) \iff v_{j}\ \text{由}\ v_{i}\ \text{加工得到}
血缘图 = 节点集合与边集合的组合。存在一条从 vi 指向 vj 的边，表示 vj 由 vi 加工而来。
  1. 节点集合图中的节点是每份数据资产（表、视图、模型特征）。
    V={v1, v2, …, vp}\displaystyle \mathcal{V} = \{ v_{1},\ v_{2},\ \ldots,\ v_{p} \}
  2. 边集合边表示数据的流动方向。
    E={eij∣vi→vj}\displaystyle \mathcal{E} = \{ e_{ij} \mid v_{i} \to v_{j} \}
  3. 充分条件只有当 vj 由 vi 加工得到时才存在该边，保证血缘不掺假。
    eij=(vi→vj)  ⟺  vj 由 vi 加工得到\displaystyle e_{ij} = (v_{i} \to v_{j}) \iff v_{j}\ \text{由}\ v_{i}\ \text{加工得到}

7. 落地实施流程：从混乱到有序三步走

定标准容易，落地难。小星没有拿着一纸公文满世界宣贯，而是先把所有书架清点了一遍——这叫盘点存量资产。

实施元数据标准一般分三步：第一步盘点，梳理现有数据资产清单，给每张表登记基础信息；第二步定标准，结合企业实际设计元模型和命名规范，先覆盖核心资产再逐步扩展；第三步运营，在新资产上线时强制执行标准，对存量资产分批改造，并通过月度巡检持续修订标准。这三步不是一次性的，而是像图书馆编目那样反复迭代。

衡量实施效果，最常用的指标是“标准覆盖率”：已纳入标准管理的数据资产数占总资产数的比例。覆盖率从 0% 爬向 100% 的过程，就是图书馆从“有书无卡”走向“凡书必有卡”的过程。

一年后，星河图书馆成为全行业学习的样板。小星站在大厅里，看着读者刷一下目录就能找到想借的书，终于明白：标准不是束缚，而是一座图书馆通往聪明的“操作系统”。

Rcoverage=NstdNtotal×100%\displaystyle R_{\text{coverage}} = \frac{N_{\text{std}}}{N_{\text{total}}} \times 100\%
标准覆盖率 = 已纳入标准的资产数 ÷ 总资产数。它是元数据治理进度的“温度计”。
  1. 已纳入数已完成标准编目的数据资产数量。
    Nstd\displaystyle N_{\text{std}}
  2. 总资产数当前应纳入治理的全部数据资产数量。
    Ntotal\displaystyle N_{\text{total}}
  3. 覆盖率两者比值换算成百分比，用来跟踪治理进度。
    Rcoverage=NstdNtotal×100%\displaystyle R_{\text{coverage}} = \frac{N_{\text{std}}}{N_{\text{total}}} \times 100\%

AI 应用场景

1. 数据目录平台：让 AI 工程师“按卡找数”

阶段：数据准备阶段

解决的问题：传统方式下，算法工程师找一份“用户近 30 天活跃度”数据，要请问一圈同事、翻十几个文档，还可能拿到口径不一致的版本。基于元数据标准建成的数据目录平台，把每张表当作带编目卡的书，支持按业务术语检索、按数据质量打分筛选，数据科学家像查图书馆目录一样快速定位可信数据集。

具体案例：某电商推荐团队在目录平台搜索“用户活跃”，系统返回 5 张相关表，并按业务元数据标注了各自口径：“日活=当日有登录行为的用户”。团队选择了完整性分数最高的表，将取数时间从 2 天缩短到 2 小时。

2. 血缘追踪：模型效果下滑的“破案神器”

阶段：模型运维与迭代

解决的问题：模型上线后 AUC 突然下跌，传统方式要在几十张表、上百个任务里手工排查“哪个上游变了”。基于元数据标准自动构建的血缘图，把每张特征表的前世今生记录成可导航的图，数分钟内定位变更源头。

具体案例：某风控团队发现贷前评分模型分数分布偏移，沿血缘图从模型特征表逐级上溯，定位到一张上游源表的“年龄”字段由 INT 改为 STRING 且部分值为空。修复后模型效果次日恢复。

3. 合规审计：面对监管的“一键自证”

阶段：数据合规与安全

解决的问题：监管要求解释“模型用了哪些数据、数据从哪来、是否取得授权”，传统方式靠人工整理邮件和文档，审计一次耗时数周。统一元数据标准加上血缘和责任人信息，让合规团队一键导出数据来源、加工链路、责任人及授权记录。

具体案例：某金融公司在年度监管检查中，通过元数据平台导出所有 AI 模型的数据血缘清单，附上各环节责任人签名，将审计准备时间从三周压缩到三天。

Python 演示

python75 行
#!/usr/bin/env python3# -*- coding: utf-8 -*-# 元数据标准检查器: 模拟图书馆编目规则, 校验数据资产的元数据 COMPLETE_STANDARD = {    "required_attrs": ["name", "biz_term", "tech_type", "owner", "quality_level", "lifecycle"],    "field_type_whitelist": {"string", "int", "float", "date", "boolean"},    "lifecycle_levels": {"raw", "cleaned", "feature", "archived"},}  class DataAsset:    def __init__(self, name, biz_term, tech_type, owner, quality_level, lifecycle):        self.name = name        self.biz_term = biz_term        self.tech_type = tech_type        self.owner = owner        self.quality_level = quality_level        self.lifecycle = lifecycle        self.field_list = []     def add_field(self, field_name, field_type, nullable):        self.field_list.append({"name": field_name, "type": field_type, "nullable": nullable})  def completeness_check(asset):    filled = 0    for attr in COMPLETE_STANDARD["required_attrs"]:        if getattr(asset, attr, "") not in (None, ""):            filled += 1    return filled / len(COMPLETE_STANDARD["required_attrs"])  def conformance_score(asset):    score = 0.0    if asset.name and asset.name.startswith("t_"):        score += 0.3    if asset.biz_term and asset.tech_type:        score += 0.3    if asset.owner:        score += 0.2    if asset.lifecycle in COMPLETE_STANDARD["lifecycle_levels"]:        score += 0.2    return score  def field_check(asset):    bad_fields = []    for field in asset.field_list:        if field["type"] not in COMPLETE_STANDARD["field_type_whitelist"]:            bad_fields.append(field["name"])    return bad_fields  def main():    user_table = DataAsset(        "t_user_profile", "用户画像", "hive_table", "王小明", "medium", "cleaned"    )    user_table.add_field("user_id", "string", False)    user_table.add_field("age", "int", True)    user_table.add_field("tags", "array", True)     order_table = DataAsset(        "t_order_2023", "", "mysql_table", "李思思", "high", "feature"    )     for table in (user_table, order_table):        comp = completeness_check(table)        conf = conformance_score(table)        bad = field_check(table)        print("[%s] 完整性: %.0f%% 符合度: %.2f 非法字段: %s" % (table.name, comp * 100, conf, bad))  if __name__ == "__main__":    main()
目的：实现一个元数据标准检查器，对两张数据表（模拟“书”）做“体检”，分别输出完整性、标准符合度和非法字段清单，对应正文中的完整性公式与符合度公式。
  1. COMPLETE_STANDARD = {定义“编目规则”字典，相当于图书馆的统一编目规则文件。
  2. "field_type_whitelist": {"string", "int", "float", "date", "boolean"},字段类型白名单，杜绝“类型裸奔”。
  3. def __init__(self, name, biz_term, tech_type, owner, quality_level, lifecycle):每本“书”必须登记的六个必填项，缺一不可。
  4. self.field_list = []用 _list 后缀命名字段明细集合，避免与后续方法重名。
  5. return filled / len(COMPLETE_STANDARD["required_attrs"])完整性 = 已填项 ÷ 必填项，对应正文公式。
  6. if asset.name and asset.name.startswith("t_"):命名规范校验：业务表名必须以 t_ 开头。
  7. if asset.lifecycle in COMPLETE_STANDARD["lifecycle_levels"]:生命周期状态必须在枚举集合中才算合规。
  8. bad_fields.append(field["name"])收集类型不合法的字段，用于后续整改。
  9. for table in (user_table, order_table):对两张表做“全身体检”，一好一坏形成对比。
  10. print("[%s] 完整性: %.0f%% 符合度: %.2f 非法字段: %s" % (...))输出治理报表，一屏看清差距。

常见误区

误区“只要我们做出一张《元数据登记表.xlsx》，规定每张表填哪些列，元数据标准就算建成了。剩下的事就是把模板发给各部门填一遍。”

正解模板只是标准的一个“快照”。真正的元数据标准由元模型（属性定义与类型约束）、命名规范、编码枚举、校验规则和运营流程共同构成，还要落在元数据管理平台里持续执行。就像图书馆的编目规则，不只是墙上贴的一张样卡，而是馆员每天的登记、核对与修订动作。

为何常见：人们习惯把“产出文档”误认为“治理落地”，忽略了标准需要工具化、流程化才能真正发挥作用。

误区“等公司的元数据标准发出来，第二天所有系统之间就能自动识别对方的数据了，不用再做人肉翻译。”

正解标准要在存量系统上生效，需要对历史资产做盘点、映射和批量改造；系统之间还要开发符合标准的元数据同步接口。这是一个分批接入的过程，就像老图书馆改造编目系统，要把几十万本旧书分批重新贴卡。

为何常见：低估了存量资产改造与系统对接的工程成本，把“定标准”与“落实现”画了等号。

误区“训练模型嘛，我只要知道表名、字段名和类型就够了，业务口径那套东西是业务部门的事，跟写代码没关系。”

正解训练数据的业务口径直接决定模型学到什么。销售口径含税不含税、用户是否剔测试账号，这些定义错了，模型在离线指标上再好看，上线也会翻车。业务元数据帮算法工程师确认“这本书记载的故事是不是我要的”。

为何常见：技术出身的人容易只关注结构信息，忽视了数据语义对模型效果的深远影响。

误区“要想让各系统数据互认，干脆把数据都搬到同一个数据仓库里，物理上统一了，元数据自然就统一了。”

正解互操作靠的是标准化的元数据描述与交换接口，而非物理集中。各系统数据可以留存在原地，只要按统一标准输出元数据，就能实现“逻辑统一、物理分散”。强制集中存储反而带来成本和安全隐患。

为何常见：把“逻辑标准化”误解为“物理集中化”，混淆了“数据搬家”与“数据打标签”两个不同动作。

面试题

Q1. 元数据的本质是什么？

单选题 · easy

  • A.描述数据的数据← 正确答案
  • B.承载数据的磁盘
  • C.加密数据的密钥
  • D.传输数据的协议

答案：A。元数据是关于数据的数据，像书脊上的编目标签，描述表的定义、口径与责任，而不承载数据本身。磁盘是存储介质，密钥负责安全，协议负责传输，都与“描述数据”无关。

Q2. 下列哪项属于业务元数据？

单选题 · easy

  • A.字段的存储类型
  • B.指标的统计口径← 正确答案
  • C.数据表的存储引擎
  • D.任务调度的运行时长

答案：B。统计口径描述“销售额含不含税”这类业务含义，属于业务元数据。存储类型和存储引擎属于技术元数据，任务调度的运行时长属于运维指标，不在业务元数据范畴。

Q3. 技术元数据主要描述数据资产的哪个方面？

单选题 · mid

  • A.业务术语与口径规则
  • B.责任人与质量标准
  • C.表结构存储与接口← 正确答案
  • D.数据安全合规等级

答案：C。技术元数据回答“数据在技术上怎么存、怎么取”，包括字段类型、存储格式、接口信息。业务术语是业务元数据，责任人与质量是管理元数据，安全合规等级属于管理范畴。

Q4. 管理元数据最核心的用途是什么？

单选题 · mid

  • A.编制业务数据字典
  • B.记录责任质量生命周期← 正确答案
  • C.设计数仓分层模型
  • D.优化 SQL 查询性能

答案：B。管理元数据记录“这本书的保管员、破损率和借阅状态”，也就是责任归属、质量规则和生命周期，支撑数据可信与问题定位。数据字典、数仓分层、SQL 优化都不是管理元数据的核心职责。

Q5. 统一元数据标准最直接的价值是什么？

单选题 · mid

  • A.显著降低数据存储成本
  • B.大幅提升 CPU 利用率
  • C.实现跨系统数据互认← 正确答案
  • D.替代所有数据加密方案

答案：C。标准让不同系统用同一套“编目语言”描述数据，系统间无需人肉翻译即可交换元数据，这是互操作的基础。存储成本和 CPU 利用率与元数据标准无直接关系，加密则由安全体系负责。

Q6. 关于数据血缘与元数据的关系，正确的说法是？

单选题 · hard

  • A.血缘是元数据体系的产物← 正确答案
  • B.血缘与元数据互不相关
  • C.血缘可完全替代元数据
  • D.血缘只描述存储结构

答案：A。血缘描述数据从上游到下游的流动关系，是元数据体系在“流转视角”上的产物，需要统一元数据标准支撑。说它与元数据无关、可以替代元数据或只描述存储结构都不准确。

Q7. 元模型在元数据标准设计中的作用是什么？

单选题 · mid

  • A.定义编目卡属性模板← 正确答案
  • B.存储全部业务明细数据
  • C.取代数据仓库的存储
  • D.自动完成所有报表开发

答案：A。元模型是“关于元数据的数据”的模型，规定每张编目卡必须有哪些属性、类型与约束，是标准的核心骨架。它不存储业务明细，也不能取代仓库或自动开发报表。

Q8. 下列哪些属于元数据标准落地的必要步骤？

多选题 · easy

  • A.盘点现有数据资产← 正确答案
  • B.设计统一元模型← 正确答案
  • C.建立持续运营机制← 正确答案
  • D.删除所有历史无用数据

答案：ABC。实施标准需要先盘点存量资产，再设计元模型与命名规范，最后靠持续运营保证新资产合规、旧资产分批改造。删除历史数据不是标准落地步骤，且属于高风险操作。

Q9. 元数据标准缺失或不统一，可能在组织中造成哪些问题？

多选题 · mid

  • A.同名指标出现不同口径← 正确答案
  • B.跨系统数据难以集成← 正确答案
  • C.数据血缘链路出现断裂← 正确答案
  • D.数据库查询速度变快

答案：ABC。标准缺失时，同一名词各系统定义不一，集成时要做大量映射，血缘也因缺乏统一的加工记录而断链。查询变快与标准无关，选项 D 是干扰项。

Q10. 关于元数据完整性与标准符合度，下列理解正确的有哪些？

多选题 · extreme

  • A.完整性衡量必填项是否填齐← 正确答案
  • B.符合度衡量是否按规范执行← 正确答案
  • C.两者是完全相同的指标
  • D.两者都是治理量化工具← 正确答案

答案：ABD。完整性关注“有没有填”，符合度关注“填得对不对”，两者视角不同但互补，都是治理报表上的关键指标。说两者完全相同是错的，因为符合度还涉及命名、枚举等规则校验。