头条文章《企业数据资产管理核心框架：L1-L5分层架构解析》阅读汇报

来源：今日头条文章
标题：企业数据资产管理核心框架：L1-L5分层架构解析
发布时间：2026-05-27 11:02
作者：星语拾闻
整理时间：2026-05-28

一、文章核心内容

这篇文章讲的是企业如何用 L1-L5 五层结构管理数据资产。它的核心思想不是“多建几层目录”，而是把一个模糊的业务问题，逐步翻译成技术系统里可以查到的表和字段。

最简单的理解方式是：L1-L5 是一个从业务到数据的放大镜。

1
2
3
4
5
L1 业务域：公司在做哪一大块事
L2 主题域：这块业务里有哪些主题
L3 业务对象：这个主题里管理的核心东西是什么
L4 逻辑实体：这个东西在数据模型里拆成哪些表/实体
L5 属性：每张表/实体里有哪些字段

文章认为，这套分层结构来自数据仓库和企业架构实践，主要受维度建模、范式建模和企业架构框架影响。它要解决的是企业数据管理中常见的几个问题：数据孤岛、口径不一、业务人员看不懂、技术人员难复用、同名不同义、同义不同名。

二、L1-L5 到底是什么关系

L1-L5 不是五个并列分类，而是一条逐层变具体的链路：

1
大业务 -> 小主题 -> 业务对象 -> 数据实体/表 -> 字段

换句话说：

  • L1-L3 更偏业务语言，是业务人员能理解的说法。
  • L4-L5 更偏技术语言，是数据系统里真正落地的表和字段。
  • L1-L5 的价值，就是把业务语言翻译成技术语言。
层级 通俗问题 解释 例子
L1 业务域 这是哪块大业务？ 企业最高层的业务范围 教学管理、一卡通、收费、科研、人事
L2 主题域 这块业务下哪个主题？ 对业务域继续细分 学生管理、交易管理、收费管理、论文成果
L3 业务对象 业务人员关心的东西是什么？ 业务中的核心名词 学生、交易流水、收费单、论文
L4 逻辑实体 系统里用什么实体/表承载？ 业务对象在数据模型里的结构化表达 std_bksjw_xsbjxx、dwd_ykt_jylsxx
L5 属性 表里具体有哪些字段？ 字段、数据项、代码值 学号、姓名、交易金额、交易时间

三、两个直观例子

例子一：学生基本信息。

1
2
3
4
5
L1 教学管理
  -> L2 学生管理
    -> L3 学生
      -> L4 学生基本信息实体
        -> L5 学号、姓名、性别、学院、专业、班级

这条链路表达的是：用户问“学生信息在哪里”，系统不要直接猜表名，而是先理解这是“教学管理”下面“学生管理”主题里的“学生”对象，然后再找到承载学生对象的逻辑实体和字段。

例子二：一卡通交易流水。

1
2
3
4
5
L1 一卡通业务
  -> L2 交易管理
    -> L3 交易流水
      -> L4 ods_ykt_jylsxx / dwd_ykt_jylsxx
        -> L5 jylsh、jyje、jysj、khxm、kh

这条链路表达的是：用户说“一卡通交易流水和交易金额”，系统应该识别出业务对象是“交易流水”，再找到 ODS/DWD 中对应的交易流水表，最后定位交易金额、交易时间、卡号、姓名等字段。

四、自然语言问题如何拆成 L1-L5

假设用户问：

1
审计上报的一卡通交易流水和交易金额字段在哪里？

用 L1-L5 拆解后就是：

1
2
3
4
5
L1：一卡通业务
L2：交易管理
L3：交易流水
L4：dwd_ykt_jylsxx / ods_ykt_jylsxx
L5：jyje、jysj、jylsh、kh、khxm 等字段

这就是 L1-L5 对 AI 检索最重要的价值：AI 不再直接从一句话里猜表，而是先判断业务对象，再用业务对象去约束候选表和字段。这样返回结果更稳定，也更容易解释“为什么命中这张表”。

五、文章提到的平台化能力

文章以数据资产管理平台为例，说明 L1-L5 可以通过平台功能落地：

能力 说明
层级属性管理 每层目录可以维护不同属性，例如所属部门、责任人、是否必填、维护方式等。
分层架构管理 支持业务域、主题域、业务对象、逻辑实体、属性之间的级联关系。
批量发布 对实体表数量很大的场景，支持整库发布、批量发布，便于初始化资产目录。
分层查询与审计 支持目录查询、发布、下线和变更审计，便于追踪资产目录生命周期。

文章的结论是：只有被清楚定义、标准化和治理的数据，才能成为可复用、可信任、可运营的数据资产。

六、对 data-skill-schema-minerpro 的参考价值

D:\AGENT\data-skill-schema-minerpro 当前已经有很多和 L1-L5 思路相近的能力：

  • mcp/data/catalog.json 承载业务资源目录。
  • mcp/data/standard-dictionary*.json 承载标准业务概念、别名、优先表、字段关键词和关系。
  • mcp/src/standard-dictionary.js 已实现自然语言到标准概念的 grounding、术语扩展、目录重排和关系扩展。
  • get_ai_business_context、business_search、standard_business_search 已经在做“业务问题 -> 候选表/字段/血缘证据”的转换。
  • docs/full-dictionary-review-pack.html 已经具备人工复核闭环的雏形。

文章给这个项目最大的启发是：当前项目不要只把标准字典当作“检索增强词表”，而可以进一步把它升级成 L1-L5 数据资产语义路径。

也就是说，项目最终不只是回答：

1
这张表在哪里？

而是回答：

1
2
3
4
5
6
这个数据属于哪个业务域？
属于哪个主题？
描述的是哪个业务对象？
由哪些逻辑实体/真实表承载？
关键字段有哪些？
为什么这些表和字段可信？

七、建议的项目映射方式

可以把当前项目中的对象按 L1-L5 重新解释和补强：

L1-L5 层级 当前项目中的可能承载位置 建议补强点
L1 业务域 catalog.json 中的业务分类、部门、系统域；标准字典中的 domain 明确区分“组织部门”“业务域”“系统来源”，避免混用。
L2 主题域 标准字典概念分组、资源目录类别 增加 subjectArea 字段，表示教学、科研、收费、一卡通、图书、人事等主题。
L3 业务对象 standard-dictionary 中的概念 id、label、aliases 把概念设计成业务对象优先，而不是表名优先，例如“学生”“收费单”“交易流水”。
L4 逻辑实体 preferredTables、Hive 真实表、DataRiver 逻辑表或 process 节点 区分“业务对象”与“逻辑实体/表”的一对多关系，支持实体组整体前置。
L5 属性 Hive 字段、字段注释、fieldKeywords、AI 字段上下文 增加字段级标准定义、代码值、同义字段、敏感级别和质量规则。

更适合本项目的目标链路是：

1
2
3
4
5
6
7
自然语言问题
  -> 识别 L3 业务对象
  -> 补齐 L1/L2 业务上下文
  -> 找到 L4 逻辑实体/真实表
  -> 定位 L5 字段语义、字段标准、字段证据
  -> 合并 Hive + DataRiver + catalog 证据
  -> 返回可解释结果，并进入人工复核闭环

这里把 L3 放在前面，是因为用户自然语言里最常说的通常不是“业务域”，而是业务对象。例如用户会说“学生”“一卡通交易流水”“收费退款”“科研论文”，这些词更接近 L3。系统识别出 L3 后，再向上补齐 L1/L2，向下找到 L4/L5。

八、可落地改进建议

1. 在标准字典中增加 L1-L5 路径字段

建议在 standard-dictionary*.json 的概念结构中增加类似字段：

1
2
3
4
5
6
7
{
  "businessDomain": "教学管理",
  "subjectArea": "学生管理",
  "businessObject": "学生",
  "logicalEntities": ["std_bksjw_xsbjxx", "std_yjsjw_xsjbxx"],
  "attributeGroups": ["身份信息", "学籍信息", "院系专业信息"]
}

这样 grounding 结果不仅能告诉用户“命中了哪个概念”，还可以告诉用户“它处在什么业务域、主题域、对象和实体路径下”。

2. 把 domain 从单一字段升级为层级模型

当前标准字典里的 domain 更像粗粒度分类。可以逐步迁移为：

1
2
domainPath = [业务域, 主题域, 业务对象]
entityPath = [逻辑实体, 字段]

这会让检索结果更可解释，也更利于后续做目录树、复核页面和评测。

3. 增加 L1-L5 路径准确率评测

现有评测关注 P@K、R@K、MRR、conceptRecall、relationAccuracy。可以增加：

  • domainAccuracy：业务域是否识别正确。
  • subjectAccuracy：主题域是否识别正确。
  • objectAccuracy：业务对象是否识别正确。
  • entityRecall：逻辑实体/表是否召回。
  • attributeRecall：关键字段是否召回。
  • pathCompleteness：是否返回完整 L1-L5 路径。

这能让项目从“表检索效果评测”升级为“数据资产语义路径评测”。

4. 在人工复核页中加入分层审核

当前项目已有 full-dictionary-review-pack.html，后续可以把复核项拆成：

  • 业务域是否正确。
  • 主题域是否正确。
  • 业务对象是否正确。
  • 逻辑实体/表是否正确。
  • 字段语义是否正确。
  • 关系扩展是否有误导。

这样人工复核不只判断结果是否命中，还能沉淀出可回写字典的治理信息。

5. 把 DataRiver 血缘用于补强 L4 逻辑实体关系

文章中的 L4 强调实体关系。当前项目已经能查 DataRiver 顶点和血缘，因此可以把 DataRiver 的 process、logical table、field 节点转化为 L4 关系证据。例如：

1
2
3
业务对象：一卡通交易流水
逻辑实体：ods_ykt_jylsxx、dwd_ykt_jylsxx
关系证据：ODS -> DWD 清洗链路、字段映射、process 节点

这比单纯维护 preferredTables 更接近“数据资产模型”。

九、需要注意的局限

这篇文章是方法论和产品化介绍，偏框架说明，不包含具体的数据结构设计、算法、评测方法或开源实现。因此对 data-skill-schema-minerpro 的价值主要是“架构命名与治理方向参考”，不能直接替代当前项目已经形成的标准字典、MCP 工具、DeepSeek 混合评测和人工复核流程。

更合理的做法不是照搬文章的产品功能，而是把文章中的 L1-L5 分层思想，嫁接到当前项目已有的业务目录检索、标准字典 grounding、Hive 表字段元数据、DataRiver 血缘、LLM 运行时过滤和人工复核评测中。

十、结论

这篇文章对 data-skill-schema-minerpro 的最大参考价值，是帮助项目从“自然语言找表/找字段”进一步升级为“基于 L1-L5 语义路径的数据资产理解系统”。

短期可以先做三件事：

  1. 给标准字典概念增加 L1-L5 分层字段。
  2. 在 grounding 和检索结果中返回 domainPath、entityPath 和字段证据。
  3. 在评测和人工复核中加入 L1-L5 路径准确性。

中期再把这些分层结果沉淀为资产目录治理能力，使 MCP/Skill 不仅能回答“数据在哪张表”，还能解释“它属于哪个业务域、哪个主题、哪个业务对象、哪些逻辑实体和哪些标准字段”。