pentaho 慢行进程

pentaho slow rows process

我有一个输入 table 有 170.000 条记录要在我的步骤中进行转换。 每条记录都有一个持续时间,特别是几天,JS 步骤检查这个持续时间,例如如果记录有 ini_date(2011/01/01) - end_date(2020/01/01) JS 将为该记录创建大约 3000 行 (输出带来 170.000不同范围的记录......其中一些有 9 年的持续时间)

  1. 转换几乎需要 5:30 小时才能完成。
  2. 在 JS STEP 上写入超过 100.000.000 行
  3. 然后将它们分组

起初我只使用 js 步骤来完成此任务,使用连接步骤、select 值步骤、排序行步骤和 stufs。然后一些 "Data transformations" 我将它们拆分为 usgin "calculator step",认为这会缩短处理时间但我得到了相同的处理时间

我只想将处理时间从 5 小时缩短到至少 1 或 2 小时,但转换中创建的行数太大而无法实现。请记住,如果一条记录有 9 年的时间,大约会生成 3000 行,而这只是其中的一个。知道输入步骤带来了 170.000 条记录和不同的范围。

如果您的 JS 步骤产生大约 1 亿行,您的 ETL 是 运行每秒大约 5.5k 行。速度不快,但也不慢。

我不明白你到底想达到什么目的,很高兴看到 group by 正在做什么。

但是,无论如何,这里有一些想法可以让它更快:

  1. 在JS中创建新行特别慢,应该避免。您最好使用计算器步骤计算日期之间的天数,然后使用克隆行创建所需的行副本。您可以添加一个 "clone number" 字段,它为每个重复的行提供一个计数器,以便后续的计算器步骤可以执行诸如将计数器添加到开始日期之类的操作。

  2. 如果您对行进行分组,则输入必须按组键排序,否则您会得到意想不到的结果。

  3. 当你运行转型的时候,瓶颈在哪里?您可以在步骤指标选项卡中看到 Input/Output 列,该列衡量每个步骤的输入和输出缓冲区的填充程度。通常通过查找具有完整输入缓冲区(默认为 10k 行)和空输出缓冲区的步骤来识别瓶颈。因此,如果 JS 步骤最慢,您将看到其输入缓冲区为 10k,并且上游的所有输入和输出缓冲区也显示 10k 行,而下游的所有输入和输出缓冲区将为空或几乎为空。

  4. 最后,如果您要写入数据库,预计输出永远不会像 PDI 内部处理行那样快。每秒 5k 行通常是一个很好的性能并且很难显着提高。但是,您可以停止使用 Table 输出步骤,而是使用批量加载程序。大多数数据库批量加载器需要将数据写入文件,但是 MySQL 可以与 FIFO 一起使用,在 Mac 或 Linux 中(在 [=37 中不起作用=])