PDI или Kettle: лучше «добавить константу» или «буквальную строку» в таблицу ввода?

Question

В преобразовании Kettle / PDI мне нужно записать в таблицу значения из другой таблицы плюс другие статические строки.

1 Ввод таблицы: чтение записей;

2 Добавить константы: add "status" = "A"; (и другие статические строки)

3 Вывод таблицы: записать старые значения + состояние и другие константы

Лучше добавить литерал в таблицу для ввода "select" (выберите id, field1, 'A' в качестве статуса из ...) или лучше использовать шаг Add Constants?

Полагаю, лучше уменьшить количество шагов, потому что с помощью «Добавить константы» вам нужно создать новый шаг.

РЕДАКТИРОВАТЬ: для «лучше» я имею в виду быстрее и меньше потребляет памяти

Answer 1

Создание еще одного шага в преобразовании приведет к отдельному выделению потока, поскольку каждый шаг является отдельным потоком, поскольку выделение хотя бы одного BlockingQueue, поскольку строки между шагами распределяется в памяти через эти структуры.

Использование еще одного шага, даже такого простого, как добавление константы, приведет к дополнительному распределению ресурсов.

PDI все еще рад быть открытым исходным кодом.

Если вам интересно, как это делается, это реализация базового шага преобразования (была долгое время) -> https://github.com/pentaho/pentaho-kettle/blob/master/engine/src/main/java/org/pentaho/di/trans/step/BaseStep.java

Это пример кода, используемого для распределения строк по шагам -> https://github.com/pentaho/pentaho-kettle/blob/master/core/src/main/java/org/pentaho/di/core/BlockingRowSet.java#L54

Конечно, для простой константы добавления в sql запросе PDI будет лишним. Существует множество примеров того, как сделать некоторые операции более быстрыми или менее потребляющими память, но о GUI или любой другой функции, которой на самом деле известен PDI?

Answer 2

Мое мнение - сделать минимальное преобразование на шаге Input Table, потому что философия PDI заключается в том, чтобы сделать видимым все преобразования.

Теперь, если вы являетесь экспертом по SQL или у вас более 200 строк со сложными вычислениями, мой ответ будет другим.