企业官网建设流程全解析

OpenMetadata Learning Resources：产品内情境化学习资源体系的端到端实现解析

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata

OpenMetadata 的 Learning Resources（学习资源）系统是一套内嵌在产品页面中的情境化学习内容体系：管理员把文章（Markdown）、视频（YouTube/Vimeo）或交互式演示（Storylane）关联到具体的页面/组件上下文（pageId+componentId），用户在 Glossary、Domain、Data Product 等页面头部点击灯泡图标（💡）即可按需调阅对应的学习材料。本文基于 OpenMetadata 仓库中的设计文档 LEARNING_RESOURCES_DESIGN.md，结合实体 Schema、JDBI3 仓库层、REST 资源、SQL 迁移脚本与前端组件源码，完整拆解该系统的架构设计、数据模型、上下文匹配机制、API 契约、种子资源与页面集成方式，帮助读者理解 OpenMetadata 如何将“内容投放”建模为一种标准元数据实体。

1. 设计目标与核心原则

Learning Resources 的设计文档（v1.0，2025-12-26，状态为 Production Ready）开篇即明确了五条关键原则，这些原则直接决定了后文看到的全部实现形态：

• 用户主动触发（User-Initiated）：资源只在用户点击灯泡图标时出现，绝不自动内联展示；
• 情境化（Contextual）：资源被匹配到具体页面（glossary、domain、dataProduct 等），并可选地细化到组件 ID（如glossary-header）；
• 多格式（Multi-Format）：支持 Article（Markdown）、Video（YouTube/Vimeo）、Storylane（交互式演示）三类；
• 简单（Simple）：不做进度追踪、不发徽章、不做游戏化，只做内容分发；
• 管理员管控（Admin-Managed）：提供完整的 CRUD 管理界面来创建和维护学习资源。

其中“简单”并非功能缺失，而是明确的取舍：v0.x 版本曾包含进度追踪、完成度阈值（completionThreshold）、徽章（badge）与游戏化机制，v1.0 全部移除，只保留内容投递能力。这一演替过程在后文“移除清单”一节中有完整记录。

2. 系统架构与用户体验流

设计文档给出的整体交互架构是三级联动：页头灯泡图标 → 侧边抽屉列表 → 全屏内容播放器。

┌─────────────────────────────────────────────────────────────┐ │ User Interface │ ├─────────────────────────────────────────────────────────────┤ │ Page Header │ │ ┌──────────────────────────────────────────────────┐ │ │ │ [Page Title] 💡 (3) [Other Btns] │ │ │ └──────────────────────────────────────────────────┘ │ │ │ Click │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ LearningDrawer │◄──── Fetches resources by pageId │ │ │ (Side Panel) │ │ │ │ • Resource 1/2/3 │ │ │ └─────────────────────┘ │ │ │ Click Resource │ │ ▼ │ │ ┌────────────────────────────────────┐ │ │ │ ResourcePlayerModal (Full Screen) │ │ │ │ [Article | Video | Storylane] │ │ │ └────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘

对应的用户工作流为：

1. 用户浏览 Glossary、Domain 或 Data Product 页面；
2. 在页头看到带资源数量角标（badge count，如“3”）的灯泡图标；
3. 点击灯泡，右侧滑出 LearningDrawer 侧边抽屉；
4. 抽屉内按当前页面上下文过滤后列出相关资源；
5. 点击某个资源，打开全屏 ResourcePlayerModal；
6. 根据resourceType渲染不同播放器：Article 以完整 Markdown 格式渲染，Video 嵌入 YouTube/Vimeo 播放器，Storylane 以 iframe 内嵌交互演示；
7. 关闭模态框后仍可回到抽屉继续浏览其他资源。

文档同时记录了关键 UX 决策：不自动展示（无用户动作不出现任何资源）、角标计数（未点击即告知资源数量）、侧边抽屉承载列表（非侵入、可与浏览共存）、全屏模态承载内容（沉浸式观看）、不做进度追踪（不制造“完成”压力）。

3. 数据模型与实体 Schema

3.1 LearningResource 实体

实体定义位于 learningResource.json，是一个标准的 OpenMetadata 实体（@om-entity-type），关键约束如下：

• 必填字段：id、name、resourceType、source、contexts、categories（Schema 中required数组明确列出）；
• resourceType：枚举Storylane/Video/Article；
• categories：枚举数组且minItems: 1，当前 Schema 枚举值为Discovery、Administration、DataGovernance、DataQuality、Observability、AI——从源码看，AI是设计文档成文后新增的第六个分类；
• difficulty：Intro/Intermediate/Advanced；
• source：内嵌对象，含url（format: uri，必填）、provider（来源系统，如 YouTube）、embedConfig（透传给 UI 的提供方专属配置，additionalProperties 任意）；
• contexts：minItems: 1，每项含必填pageId、可选componentId，Schema 中还定义了可选整数priority（最小 0），用于同一上下文中多资源匹配时的相对排序权重——这是设计文档未展开、但 Schema 中已预留的字段；
• status：Draft/Active/Deprecated，默认Active；
• 另有tags、owners、reviewers、followers、软删除标记deleted、version、updatedAt/updatedBy、href、extension等实体通用字段；
• 实体级additionalProperties: false，即不允许 Schema 之外的字段。

设计文档给出的标准示例（一个 Article 资源）：

{ "name": "Intro_GlossaryBasics", "displayName": "Glossary Basics: Building Your Business Vocabulary", "description": "Learn the fundamentals of creating and managing glossaries...", "resourceType": "Article", "categories": ["Discovery", "DataGovernance"], "difficulty": "Intro", "source": { "url": "https://www.getcollate.io/learning-center/resource/Intro_GlossaryBasics", "provider": "Collate", "embedConfig": { "content": "# Glossary Basics\n\nMarkdown content here..." } }, "estimatedDuration": 720, "contexts": [ { "pageId": "glossary", "componentId": "glossary-header" } ], "status": "Active" }

其中estimatedDuration以秒为单位；Article 类型的正文 Markdown 存放在source.embedConfig.content，这是 ArticleViewer 前端组件读取内容的唯一来源。

3.2 前端 TypeScript 数据模型

前端接口定义在 learningResourceAPI.ts（设计文档中写作src/rest/learningResourceAPI.ts，实际位于 UI 工程的openmetadata-ui/src/main/resources/ui/目录下），核心是两个接口：

export interface LearningResource { id: string; name: string; fullyQualifiedName?: string; displayName?: string; description?: string; resourceType: 'Article' | 'Video' | 'Storylane'; categories: string[]; difficulty?: 'Intro' | 'Intermediate' | 'Advanced'; source: { url: string; provider?: string; embedConfig?: { content?: string; // Article 类型专用：Markdown 正文 [key: string]: unknown; }; }; estimatedDuration?: number; // 秒 contexts: Array<{ pageId: string; componentId?: string; }>; status?: 'Draft' | 'Active' | 'Deprecated'; owners?: EntityReference[]; reviewers?: EntityReference[]; version?: number; updatedAt?: number; updatedBy?: string; href?: string; } export interface CreateLearningResource { name: string; displayName?: string; description?: string; resourceType: 'Article' | 'Video' | 'Storylane'; categories: string[]; difficulty?: 'Intro' | 'Intermediate' | 'Advanced'; source: { url: string; provider?: string; embedConfig?: { content?: string; [key: string]: unknown } }; estimatedDuration?: number; contexts: Array<{ pageId: string; componentId?: string }>; status?: 'Draft' | 'Active' | 'Deprecated'; owners?: EntityReference[]; reviewers?: EntityReference[]; }

3.3 上下文匹配逻辑（Context Matching）

资源与页面的匹配采用分层策略，这决定了“某个资源在哪出现”：

1. 精确匹配：pageId+componentId均相等——如{pageId: "glossary", componentId: "glossary-header"}的资源只出现在词条表头；
2. 页面匹配：pageId相等且资源未指定componentId——如只有{pageId: "glossary"}的资源在整个 Glossary 页面范围内生效；
3. 广义匹配：资源应用于整个页面。

即componentId是可选的收窄锚点：不填则资源覆盖整页，填写则缩小到具体组件。

4. 后端实现

4.1 实体 Schema 之外的补充

当前 createLearningResource.json API 请求 Schema 中仍保留了completionThreshold（number，0–100）字段定义，而实体 Schema 中该字段已不存在。从源码结构看，这属于简化过程中 API 层尚未清理的历史残留，实体落库模型（additionalProperties: false）才是当前事实模型。

4.2 LearningResourceRepository：校验与种子合并

仓库层实现位于 LearningResourceRepository.java，继承EntityRepository<LearningResource>。

**写前校验（prepare()，见 L134-L139）**按顺序执行四条规则，任一失败即抛出BadRequestException：

• validateSource()：source与source.url均不可为空（L170-L174）；
• ensureCategories()：至少一个分类，同时对分类去重（保持原顺序的LinkedHashSet）；
• validateContexts()：至少一个上下文，每个上下文的pageId非空，且以pageId::componentId为键做重复检测，重复即拒绝（L187-L205）；
• validateDuration()：estimatedDuration为 null 或 ≥ 0。

可 PATCH/UPDATE 的字段由UPDATE_FIELDS常量声明：owners,reviewers,tags,contexts,categories,difficulty,source,estimatedDuration,status。另有一个实现细节：构造函数中supportsSearch = false，即学习资源不进入搜索索引，仅走关系型存储。

启动期种子合并（initSeedDataWithMerge()，L63-L95）：与默认“跳过已存在实体”的初始化不同，该方法在应用启动时（受SeedDataGate开关控制）逐个读取种子 JSON：实体不存在则创建（生成随机 UUID、updatedBy设为 admin）；已存在则比对displayName、description、resourceType、categories、contexts、difficulty、source、status八个关键字段，有差异才走createOrUpdate更新。这解释了第 8 节种子资源可随版本升级自动刷新的机制。

双数据库 JSON 过滤（LearningResourceFilter，L213-L404）：由于实体表是“JSON 文档 + 生成列”结构，contexts等嵌套数组的过滤按数据源方言动态生成 SQL——MySQL 用JSON_SEARCH(json, 'one', :pageId, NULL, '$.contexts[*].pageId') IS NOT NULL，PostgreSQL 用EXISTS (SELECT 1 FROM jsonb_array_elements(COALESCE(json->'contexts', '[]'::jsonb)) ctx WHERE ctx->>'pageId' = :pageId)。过滤器支持pageId（支持逗号分隔多值，多值在 MySQL 下展开为多个JSON_SEARCH ... OR）、componentId、category（同样支持多值）、difficulty、resourceType（IN 列表）、status（IN 列表）、search（对name与 JSON 内displayName做大小写不敏感的 LIKE 匹配）七种条件。这一层是“按上下文取资源”查询在 SQL 层面的真实实现。

4.3 LearningResourceResource：REST 端点契约

REST 资源位于 LearningResourceResource.java，类级路径/v1/learning/resources（即完整 URL 前缀/api/v1/learning/resources），集合名learning/resources。initialize()中调用repository.initSeedDataWithMerge()完成种子装载（L80-L84）。

结合源码，端点全集如下（设计文档列出的GET /context/{pageId}端点在当前实现中未单独存在，上下文过滤统一由列表接口的pageId/componentId查询参数实现，功能等价）：

POST/PUT请求体为CreateLearningResource（见第 3.2 节接口），toEntity()将其转换为实体并透传resourceType、categories、difficulty、source、estimatedDuration、contexts、status等字段。

4.4 数据库表结构与迁移脚本

learning_resource_entity表由 1.12.0 版本迁移脚本创建：

• MySQL：bootstrap/sql/migrations/native/1.12.0/mysql/schemaChanges.sql（-- Create Learning Resource Entity Table段）
• PostgreSQL：bootstrap/sql/migrations/native/1.12.0/postgres/schemaChanges.sql

以 MySQL 版本为例，遵循 OpenMetadata 典型的“JSON 文档表”模式：

CREATE TABLE IF NOT EXISTS learning_resource_entity ( id varchar(36) GENERATED ALWAYS AS (json_unquote(json_extract(`json`,'$.id'))) STORED NOT NULL, name varchar(3072) GENERATED ALWAYS AS (json_unquote(json_extract(`json`,'$.fullyQualifiedName'))) VIRTUAL, fqnHash varchar(256) CHARACTER SET ascii COLLATE ascii_bin NOT NULL, json json NOT NULL, updatedAt bigint UNSIGNED GENERATED ALWAYS AS (json_unquote(json_extract(`json`,'$.updatedAt'))) VIRTUAL NOT NULL, updatedBy varchar(256) GENERATED ALWAYS AS (json_unquote(json_extract(`json`,'$.updatedBy'))) VIRTUAL NOT NULL, deleted TINYINT(1) GENERATED ALWAYS AS (IF(json_extract(json,'$.deleted') = TRUE, 1, 0)) VIRTUAL, PRIMARY KEY (id), UNIQUE KEY fqnHash (fqnHash) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

要点：id/updatedAt/updatedBy/deleted都是从json列抽取的生成列，fqnHash（由fullyQualifiedName计算的哈希）承担唯一约束与name查询的落点；PostgreSQL 版本结构一致，使用jsonb与->>生成列。设计文档同时说明：早期迁移文件（1.10.5）中曾定义的learning_badge_entity与learning_resource_progress_entity两张表实际从未落库，已从迁移中移除。

5. 前端组件实现

前端代码位于 UI 工程openmetadata-ui/src/main/resources/ui/src/下（设计文档中的src/...路径均相对该目录）。

5.1 LearningIcon：灯泡按钮

文件：LearningIcon.component.tsx（含 LearningIcon.test.tsx）。点击灯泡即打开 LearningDrawer；特性包括显示可用资源数量角标、hover 时才懒加载计数（优化首屏请求）、支持small/medium/large三种尺寸与可选 label 文本。Props 契约：

interface LearningIconProps { pageId: string; componentId?: string; className?: string; size?: 'small' | 'medium' | 'large'; label?: string; tooltip?: string; placement?: 'top' | 'bottom' | 'left' | 'right'; }

用法示例：

<LearningIcon pageId="glossary" size="small" />

5.2 LearningDrawer：侧边资源列表

文件：LearningDrawer.component.tsx。从右侧滑出，标题形如 "Learning Resources for {page}"，以卡片列表呈现当前上下文匹配到的资源；打开时自动按上下文拉取数据（对应getLearningResourcesByContextAPI 调用），拉取中显示 loading，无资源时显示空态。Props 契约：

interface LearningDrawerProps { open: boolean; pageId: string; componentId?: string; onClose: () => void; }

5.3 ResourcePlayerModal：内容播放器路由

文件：ResourcePlayerModal.component.tsx。全屏模态，按resourceType路由到三种播放器，并展示资源元数据（标题、描述、难度、时长、分类）：

switch (resource.resourceType) { case 'Video': return <VideoPlayer resource={resource} />; case 'Storylane': return <StorylaneTour resource={resource} />; case 'Article': return <ArticleViewer resource={resource} />; }

5.4 VideoPlayer：YouTube/Vimeo 智能 URL 转换

文件：VideoPlayer.component.tsx（样式见 video-player.less）。核心能力是把各种分享 URL 归一化为可嵌入地址：

• youtube.com/watch?v=abc123→youtube.com/embed/abc123
• youtu.be/abc123→youtube.com/embed/abc123
• vimeo.com/123456→player.vimeo.com/video/123456

容器采用 16:9 响应式比例（padding-bottom: 56.25%技巧），加载期间显示 spinner，iframe 携带完整权限（autoplay、fullscreen 等）。

5.5 StorylaneTour 与 ArticleViewer

• StorylaneTour.component.tsx（样式 storylane-tour.less）：无边框 iframe 嵌入 Storylane 演示，固定 600px 高度，支持全屏，加载期显示 spinner；URL 形如https://app.storylane.io/share/xxxxxxxxxx。
• ArticleViewer.component.tsx：复用 OpenMetadata 既有的RichTextEditorPreviewer渲染 Markdown，内容取自resource.source.embedConfig.content，enableSeeMoreVariant={false}即不做“查看更多”截断，完整支持标题、列表、代码块、链接等语法。

5.6 LearningResourceCard

文件位于src/components/Learning/LearningResourceCard/（LearningResourceCard.test.tsx 等）。抽屉中每个资源的卡片形态：类型图标 + 标题 + 描述 + 难度徽标 + 预估时长 + 分类标签，整卡可点击打开播放器。

6. 管理端 UI 与 API 客户端封装

6.1 管理页与表单

管理入口为 Settings → Preferences → Learning Resources（路由/settings/preferences/learning-resources，仅管理员可访问）。管理表（LearningResourcesPage）以表格展示全部资源，列包括：名称、类型（带颜色标签）、难度、分类（多标签）、上下文（pageId:componentId对）、时长（秒换算为分钟）、状态，以及 Preview / Edit / Delete 操作（删除带确认模态；Preview 直接打开 ResourcePlayerModal 预览），分页 20 条/页。

编辑表单（LearningResourceForm）为模态表单，字段与校验规则：

• Name（必填，唯一标识）、Display Name、Description；
• Resource Type 下拉（Article/Video/Storylane）；Categories 多选；Difficulty 下拉；
• Source URL（必填，格式校验）+ Provider 文本；
• Embedded Content：仅 Article 类型显示，富文本编辑器输入 Markdown；
• 预估时长以分钟输入、提交时换算为秒；
• Contexts 为动态Form.List：Page ID 从预定义列表选择 + 可选 Component ID 文本框，可增删多组；
• Status 下拉（Draft/Active/Deprecated）。

表单内常量（与设计文档一致）：

const RESOURCE_TYPES = ['Article', 'Video', 'Storylane']; const DIFFICULTIES = ['Intro', 'Intermediate', 'Advanced']; const CATEGORIES = ['Discovery', 'Administration', 'DataGovernance', 'DataQuality', 'Observability']; const STATUSES = ['Draft', 'Active', 'Deprecated']; const PAGE_IDS = ['glossary', 'glossaryTerm', 'domain', 'dataProduct', 'dataQuality', 'table', 'dashboard', 'pipeline', 'topic', 'explore', 'governance'];

（从源码看，后端 Schema 的resourceCategory枚举已额外包含AI，前端常量是否同步扩展可结合 Learning.constants.ts 进一步确认。）

6.2 API 客户端函数

learningResourceAPI.ts 封装了与后端的交互：

// 创建新资源 export const createLearningResource = (data: CreateLearningResource): Promise<LearningResource>; // 列表（可选过滤） export const getLearningResourcesList = (params?: { limit?: number; fields?: string; category?: string; difficulty?: string; }): Promise<{ data: LearningResource[]; paging: Paging }>; // 按上下文取资源（抽屉打开时调用） export const getLearningResourcesByContext = ( pageId: string, params?: { componentId?: string; limit?: number; fields?: string; } ): Promise<{ data: LearningResource[]; paging: Paging }>; // 更新 / 删除 export const updateLearningResource = (id: string, data: CreateLearningResource): Promise<LearningResource>; export const deleteLearningResource = (id: string): Promise<void>;

此外，管理页还配有 Playwright E2E 用例 LearningResources.spec.ts 与页面对象 LearningResourceClass.ts，用于回归验证资源管理流程。

7. API 使用示例

创建资源

POST /api/v1/learning/resources Content-Type: application/json { "name": "Intro_GlossaryBasics", "displayName": "Glossary Basics", "resourceType": "Article", "categories": ["Discovery"], "source": { "url": "https://example.com/resource", "provider": "Collate" }, "contexts": [ { "pageId": "glossary" } ] }

按上下文过滤列表

GET /api/v1/learning/resources?pageId=glossary&componentId=glossary-header&limit=10

（等价于设计文档中记录的GET /api/v1/learning/resources/context/{pageId}语义，见第 4.3 节说明；pageId与category还支持逗号分隔多值，如?pageId=glossary,domain。）

获取、更新、删除

GET /api/v1/learning/resources/{uuid} GET /api/v1/learning/resources/name/Intro_GlossaryBasics GET /api/v1/learning/resources?limit=100&fields=categories,contexts,difficulty PATCH /api/v1/learning/resources/{uuid} Content-Type: application/json-patch+json [ { "op": "replace", "path": "/difficulty", "value": "Advanced" } ] DELETE /api/v1/learning/resources/{uuid}

8. 种子资源与页面集成点

8.1 种子资源

内置学习资源存放于 openmetadata-service/src/main/resources/json/data/learningResource/，由第 4.2 节描述的initSeedDataWithMerge()在启动时合并入库。设计文档成文时记录为 15 个（14 篇 Article + 1 个 Storylane 占位）；当前仓库中该目录已有26 个种子 JSON，覆盖更多主题与页面上下文。两个典型样例：

• DataProducts_Storylane.json：Storylane 交互演示，挂载到dataProduct与domain两个页面上下文，URL 指向 Storylane 分享链接；
• CollateClues_GovernanceWorkflows.json：YouTube 视频（provider: "YouTube"），同时挂载到governanceWorkflows、domain、dataProduct三个上下文——直观展示了“一个资源、多上下文投放”的用法。

文档记录的分布统计（成文时点）：按分类，DataGovernance 7 个最多，Discovery 5、DataQuality 3、Administration 1、Observability 1；按页面上下文，glossary 6 个最多，glossaryTerm 4、table 3、domain 3、explore 2、dataProduct 2、dataQuality 1、governance 1。

8.2 页面集成点

LearningIcon 被嵌入以下页面头部（设计文档给出对应代码片段，均以<LearningIcon pageId=... size="small" />形式放入ButtonGroup）：

1. 所有数据资产页头：src/components/DataAssets/DataAssetsHeader/DataAssetsHeader.component.tsx，以pageId={entityType}动态传参，覆盖 Table、Pipeline、Dashboard、Topic、Container、MlModel、SearchIndex 等全部数据资产实体类型；
2. Glossary 页：src/components/Glossary/GlossaryHeader/GlossaryHeader.component.tsx，按isGlossary在glossary/glossaryTerm两个上下文间动态切换；
3. Domain 页：src/components/Domain/DomainDetails/DomainDetails.component.tsx，pageId="domain"；
4. Data Product 页：src/components/DataProducts/DataProductsDetailsPage/DataProductsDetailsPage.component.tsx，pageId="dataProduct"。

给新页面接入 LearningIcon 的标准写法（附录代码）：

import { LearningIcon } from 'components/Learning/LearningIcon/LearningIcon.component'; // In your page header component: <ButtonGroup className="spaced" size="small"> <LearningIcon pageId="your-page-id" // e.g., "table-details" componentId="optional-component-id" // optional size="small" /> {/* other header buttons */} </ButtonGroup>

9. 设计决策记录与 v1.0 移除清单

9.1 关键决策及其理由

为什么不做进度追踪：原设计包含进度、完成阈值、徽章与游戏化，最终全部砍掉。理由有四：复杂度与价值不匹配；“完成任务”的压力与学习初衷相悖；追踪用户行为存在隐私顾虑；纯内容投递更易维护，把注意力留给内容质量本身。

为什么选择页头灯泡图标：对比过“页面顶部自动横幅”“正文内联面板”“角落悬浮控件”等方案后选择页头灯泡，因为其非侵入、可发现、由用户掌控节奏、符合帮助/文档图标的通用心智，且角标计数能在不点击的情况下传递“有 N 个资源可用”的信息。

为什么列表用抽屉、内容用全屏模态：抽屉可与页面浏览并存、便于随时收起且保留了页面语境；内容观看则需要沉浸式全屏（视频/演示需要完整视觉空间），清晰区分“浏览模式”与“观看模式”。

为什么只有三种资源类型：Article 自包含、可检索、可版本化，适合参考文档；Video 适合教程与概览且平台熟悉；Storylane 提供免环境、破坏不了任何东西的真实产品 UI 交互体验。PDF 被排除（浏览器阅读体验差、不响应式），外链被排除（跳出产品体验割裂），网络研讨会被排除（太长且有排期问题）。

9.2 v1.0 移除的功能清单

设计文档完整记录了简化过程中移除的内容，作为演进证据：

• 实体与后端：LearningBadge（含 Schema、Repository、Resource、Test）、LearningResourceProgress（同构四件套）；LearningResource 上的completionThreshold字段从 Schema、校验、转换、测试及 14 个种子 JSON 中全部移除；
• 前端：VideoPlayer 移除 YouTube API 消息处理与时间追踪；ArticleViewer 移除滚动追踪与进度计算；StorylaneTour 移除计时进度；ResourcePlayerModal 移除进度条、完成百分比与“Mark Complete”按钮；useLearningResourcePlayerhook 整文件删除；LearningCenterBadge与InlineLearningPanel创建后即被移除；
• 数据库：learning_badge_entity、learning_resource_progress_entity从 1.10.5 迁移文件（mysql/postgres）中移除——文档特别说明这两张表“定义了但从未真正创建”；
• API：/api/v1/learning/badges/*与/api/v1/learning/progress/*全部端点下线。

10. 构建验证、文件索引与国际化

10.1 构建命令

# Backend mvn clean compile -pl openmetadata-service -DskipTests mvn spotless:apply -pl openmetadata-service mvn test-compile -pl openmetadata-service # Frontend cd openmetadata-ui/src/main/resources/ui yarn lint:fix yarn build

10.2 关键文件位置索引

技术依赖方面，后端复用 OpenMetadata 标准实体框架（JDBI3 访问数据库、Jackson 序列化、标准 EntityResource 模式）；前端为 React + TypeScript + Ant Design（Table/Form/Modal/Drawer/Badge/Button 等），国际化使用 react-i18next，Markdown 渲染复用既有RichTextEditorPreviewer。

国际化键分两档：代码库中已存在的label.learning-resources、label.difficulty、label.duration、message.learning-resources-available（含 count 参数）、message.no-learning-resources-available等；设计文档还列出了一组可能需要新增的键，如label.page-id、label.embedded-content、label.source-url、label.estimated-duration-minutes、message.write-markdown-content、server.learning-resources-fetch-error等。

11. 未来方向与度量

文档明确了三条未实现但已规划的路径：其一，资源管理运营——审阅更新文章内容、确保外链有效、为覆盖不足的上下文补充资源；其二，度量（Metrics）——在不追踪个体进度的前提下，可通过后端日志统计灯泡点击率、资源浏览次数、模态平均停留时长与复访率，用于识别热门主题、指导内容生产优先级；其三，检索与推荐——在 LearningDrawer 中加入按关键词（标题/描述/分类）的搜索框，以及基于分类/难度的相关资源推荐（“喜欢 X 的话，试试 Y”）。

此外，种子资源层面有一个遗留待办：早期的 Storylane 占位资源需要替换为真实的https://app.storylane.io/share/xxxxxxxxxx链接，并以此为模板扩充 Data Governance、Data Lineage、Data Quality、Table Discovery 等演示。

小结

OpenMetadata Learning Resources 的本质是把“内容投放”建模为一种标准元数据实体：contexts数组定义投放位置，source定义内容载体，status定义发布生命周期，而 JSON 文档表 + 双方言 SQL 过滤则让“按页面/组件取内容”成为一次普通的关系型查询。对希望在自己的数据产品中实现类似“情境化帮助/教程系统”的开发者而言，这套方案的价值在于：实体化的 Schema 与 CRUD API 让内容管理天然获得版本历史、软删除、审计与权限能力；而 UI 侧的三级组件（Icon → Drawer → PlayerModal）与按resourceType路由的播放器设计，则为后续扩展新的内容类型（如 PDF、外链文档）保留了清晰的插入点。

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata