Как получить все результаты из результатов, установленных в входной таблице шага пентаго-чайника?

У меня есть простое преобразование, состоящее из 2 шагов. Шаг 1 (входная таблица) делает запрос к БД, а шаг 2 (класс Java) обрабатывает результаты. 2 шаг занимает много времени (это нормально в моем случае), но через 1 час я получаю ошибку закрытого набора результатов

Сервер закрыл соединение. Если результирующий набор содержит огромное количество данных, Сервер ожидает, что клиент относительно быстро прочитает результирующий набор. В этом случае рассмотрите возможность увеличения переменной сеанса net_wait_timeout. / обработка вашего набора результатов быстрее (дополнительную информацию см. в документации по потоковым наборам результатов) 2017/10/02 13:12:06 - Получение ячеек данных .0 -

Я думаю, что должен быть какой-то промежуточный шаг (или какой-то другой вариант), чтобы получить относительно быстрый результат с 1 шага. Не могли бы вы помочь мне с этим?


person palandlom    schedule 10.10.2017    source источник
comment
У меня есть (не очень) глупый вопрос: действительно ли это связано с шагом класса java? Я имею в виду, что Input table часто блокируется по другим причинам. Можете ли вы заменить шаг 2 на шаг Dumy и посмотреть, блокируется ли он по-прежнему.   -  person AlainD    schedule 10.10.2017
comment
Другой (не очень) глупый вопрос: может ли ваш класс Java заблокировать базу данных? Использует ли он какие-либо JDBC?   -  person AlainD    schedule 10.10.2017
comment
Да, он использует - (класс java в некоторых случаях может отправлять запросы UPDATE в БД). Так может ли это привести к закрытию соединения (и соответствующего набора результатов) на 1 шаг?   -  person palandlom    schedule 10.10.2017


Ответы (1)


Я предполагаю, что ваш шаг 2 блокирует ту же таблицу, что и на шаге 1.

Это один из недостатков в остальном эффективной архитектуры PDI. Все этапы начинаются одновременно, и те, кто быстрее всего дает результаты, переходят к следующим этапам. С этой стратегией "сначала делать быстрее" вы иногда превосходите сам оптимизатор sql, когда есть много объединений по суммам или средним значениям (пропорционально).

Основной ловушкой в ​​этом отношении является чтение таблицы, выполнение некоторых преобразований и переписывание результата в той же таблице с отмеченным truncate table. В этом случае усечение выполняется за несколько миллисекунд до выбора входной таблицы, что запускает бесконечную тупиковую блокировку. Спустя долгое время вы решаете убить ETL, но в это время данные были утеряны.

Решения:

  • Рекомендуется переписать шаг 2 с использованием шагов PDI, а не использовать готовый класс Java. Это путь, который я настоятельно рекомендую в долгосрочной перспективе, но у вас могут быть причины не следовать ему.

  • Если ваша таблица маленькая, вы можете поставить blocking step между вводом и выводом.

  • Если ваша таблица большая, вы можете использовать шаг sort row вместо шага блокировки. Вы действительно не хотите сортировать, но PDI должен просмотреть последнюю строку, чтобы убедиться, что сортировка завершена, прежде чем выдавать результаты для следующего шага. Сортировка будет разбивать данные на временные фрагменты на жестком диске, и вы можете иметь определенный контроль над тем, где и как хранятся данные tmp.

  • Вы можете скопировать свою таблицу в таблицу tmp (или файл), обработать и удалить ее после. Используйте для этого задание, потому что в задании, в отличие от преобразования, процесс является последовательным.

person AlainD    schedule 11.10.2017
comment
Спасибо, за подробное объяснение! Надеюсь, я правильно понял - я убрал код выполнения UPDATE-запроса из java-класса и добавил шаг 3 (шаг INSERT/UPDATE), который получает какое-то поле из шага 2 и делает запрос UPDATE. - person palandlom; 12.10.2017
comment
Поздравляю. Искренне. Мертвые блокировки никогда не бывают легкими ошибками. - person AlainD; 12.10.2017