我有几个转换，它们在实际的ETL处理之前和之后都执行类似的功能：
- 查看某些目录以查看是否出现了要集成的新文件(数据库中维护的目录(
- 在数据库中将找到的文件标记为"正在使用"(并存储其他几个文件属性(
- 将文件移动到"正在使用"子目录
- 运行 ETL 过程
- 将文件标记为"已完成">
- 将文件移动到"已完成"的子目录
这些步骤是业务需求，并且对于基于文件输入的每个 ETL 过程是 100% 相同的(除了用于搜索目录列表和注册文件的不同数据库表(。维护这个几乎相同的过程的 X 个副本(如果必须更改，则更新所有副本似乎并不理想(
因此，我创建了一个"骨架"转换来完成所有这些工作，并通过将变量传递到转换的位置来"注入"运行 ETL 过程"部分。这样，"注入"转换不需要知道文件处理步骤，并且文件处理步骤与实际的 ETL 过程分离。
由于我对PDI相当缺乏经验，我想知道通常如何解决此类问题以及我的方法是否有任何好处。
您的方法符合最佳实践。在存档目录中移动已处理的文件是要走的路，并且在可从外部访问的数据库中保持状态"使用中"/"已完成"非常方便。
传统上，您将在转换的参数中定义文件名和其他属性，而不是在数据库中定义。但是，将它们存储在数据库中允许您从外部访问它，甚至可以制作一个小型 Web 应用程序来显示状态。
您还可以在单独的转换中提取预处理和后处理 ETL，并在作业中编排整个过程。
我想您没有忘记在其他几个属性中包含文件大小(行数(。并且您有一个命名约定来帮助您在失败时重新运行该过程而不会令人头疼。
最后，我建议您还跟踪数据库中的日志。只需单击任意位置，选择Properties/Parameters/Transformation，定义database connection+table，logging interval2(秒(，然后按SQL按钮。 您在表Step metrics底部看到的所有内容(输入，输出,...(都将保存在数据库中。当您发现上周出现问题时很有用。
你做对了。猜猜您正在使用映射步骤来重用转换的常见部分：
https://wiki.pentaho.com/display/EAI/Mapping