2.2 元数据管理机制

2.2 元数据管理机制

你画的图到底存在了哪里

本篇是第 2 章第 2 节，承接运行时，回答「设计产物如何保存与协作」，直接影响团队怎么多人维护同一套管道。

Kettle 的元数据就是那份 XML：步骤、跳、参数、连接都在里面。最朴素的方式是存成本地 .ktr/.kjb 文件，好处是能用 Git 做版本管理、做代码评审。我们团队目前主推文件加 Git，因为资源库在灾备时反而多一个依赖点。

资源库（repository）把元数据存进专用数据库表，Spoon 里可以直接浏览、搜索、权限控制。适合不愿碰 Git 的业务同学参与编辑。但它的代价是：元数据被锁进一张表，迁移和备份都要单独处理，我们曾在一次机房搬迁中为资源库导出费了不少劲。

还有一种是企业版的内容存储服务，把元数据托管到中心。我们没用，因为引入它就多了一个必须在线才能设计的系统，和「本地也能画」的诉求冲突。对中小团队，文件加 Git 足够且最省心。

无论哪种存法，参数和连接最好外置。我们在文件里只放 ${db_host} 这类变量，真正的值写在服务器上的 kettle.properties，这样同一份 .ktr 在测试和生产指向不同库，不用改图。这个习惯从第二章就要养成，第四章会系统讲参数。

元数据版本化还有个隐性好处：回滚。文件进 Git 后，某次改动把转换跑挂了，git revert 一下就能恢复。我们用资源库时这一招很麻烦，因为要手动比对表记录。所以「可回滚」是我们选文件存储的关键理由之一。

关键代码与配置

下面这段 text 给出了可直接落地的配置，输入来自上一步、输出写入目标端：

# 2.2 元数据管理机制
DB_HOST=10.0.3.21
DB_PORT=3306
DB_USER=etl_rw
DB_PASS=******
ETL_DAY=2026-08-25
​

把敏感连接信息和环境差异外置到 properties，文件本身保持干净。我们规定 properties 绝不提交仓库，只由配置管理下发。

# 用 Git 管理元数据文件的标准动作
git pull
# 在 Spoon 里修改 demo.ktr 后保存
git add demo.ktr
git commit -m 'fix: 表输出增加批量提交'
git push
​

文件即代码，评审 diff 能看清别人改了哪个步骤。我们强制转换文件走 PR，避免直接在主分支上乱存。

背景

团队曾全面改用数据库资源库，结果一次主库扩容导致 Spoon 连不上，所有人当天无法设计。

操作

我们决定把资源库导出为文件，全面切到 .ktr+.kjb 加 Git 工作流。

# 从资源库批量导出到文件
./kitchen.sh /export /rep:old_repo /user:admin /pass:admin /dir:/ /file:/backup/
# 之后所有设计改为本地文件 + Git
​

结果

设计不再依赖一个在线数据库，断网也能画图；回滚用 git revert 秒级完成。

解读

根因是「设计可用性」被错误地绑定到了资源库的在线状态。文件存储把可用性还给了本地，更符合我们小团队的实际。

变式

若以后需要权限管控，可在 Git 仓库层做分支保护，而不是依赖资源库的账号体系，两者目标一致手段不同。

常见误区与工程取舍

误区：把连接密码写进 .ktr。文件可能进 Git，密码泄露；务必用变量加 properties 外置。

误区：资源库一定比文件高级。它增加可用性风险，小团队未必需要。

取舍：要版本与回滚选文件+Git；要免学习成本选资源库。按团队习惯定。

深入：元数据到底存在哪

Kettle 的元数据（转换/作业的定义）最常见的载体是文件系统里的 .ktr（转换）与 .kjb（作业），它们本质是 XML 文本。文本化的好处是直接进 Git、可 diff、可 code review。但多团队协同时，文件散落各人机器会导致版本混乱，于是有了「资源库（Repository）」——把元数据存进专用数据库（如 Pentaho 资源库或企业版仓库），集中管理与权限控制。小团队用文件足够，团队规模上来再迁资源库，迁移成本远低于一开始强行上重方案。

<!-- .ktr 文件头：name 即转换名， connection 引用共享连接（输入：设计器保存；输出：可被 Pan 加载的 XML） -->
<trans>
  <name>orders_sync</name>
  <connection>
    <name>dw_prod</name>   <!-- 引用连接库里的共享连接，而非把账号密码写死在文件 -->
  </connection>
  ...
</trans>
​

⚠️ 常见坑（元数据管理）

• 把账号密码明文写进 .ktr：应引用共享连接或用变量注入，否则凭据随文件泄露。
• 多人各存各的文件：版本无法合并，建议早用资源库或至少统一 Git 目录。
• 手动改 XML 破坏结构：手工编辑要小心标签闭合，最好回设计器校验一次。

💡 关键直觉

• 元数据即代码：把 .ktr 当源码对待，纳入版本控制是工程化的起点。
• 文件 vs 资源库不是优劣问题，是团队规模的匹配问题——小用文件，大用仓库。

工程实录：元数据进 Git

团队各存各的 .ktr，改错无法回滚，离职带走知识。

把 .ktr/.kjb 纳入 Git，引用共享连接而非写死密码。

<connection><name>dw_prod</name></connection>
<!-- 引用连接库里的共享连接，凭据由变量注入，文件本身不含秘密码 -->
​

每次改动可 diff、可 review、可回滚，元数据成为团队资产。

元数据即代码，文本化是工程化的起点。

团队扩大到多组时，迁到资源库做集中权限管理。

参数与阈值速查

共享连接与变量作用域

Spoon 里的连接可另存为共享文件（.shared.xml），多个转换引用同一份定义，改库地址或密码只改一处。变量作用域自低到高有三级：转换内参数、作业内参数、kettle.properties，同名时内层覆盖外层。我们约定：环境级配置（账号、根目录）放 kettle.properties，作业级（日期、批次号）放作业参数，转换内只放与步骤强相关的局部值。层级清晰后，跨环境切换与多人协作才不会各自为政——这也是「参数外置」习惯在工程层面的落地。