Шаг ввода таблицы Pentaho с параллельным запуском больших данных

Я относительно новичок в Пентахо. Я работаю над заданием с 35 параллельными преобразованиями, каждое преобразование считывает около 1 миллиона данных из базы данных MySQL и сохраняет их в другой базе данных (MSSQL).

Но через несколько минут он выходит из строя и показывает: java.lang.OutOfMemoryError: GC overhead limit exceeded.

Я хотел знать, как я могу упростить этот процесс и есть ли способ прочитать данные пакетным методом или я могу использовать цикл в преобразовании, чтобы данные считывались фрагментом (скажем, 5000) в каждом преобразовании .

Кроме того, как лучше всего читать большие данные из таблицы, когда так много преобразований выполняется параллельно? И как значение «Число строк в наборе строк» ​​влияет на производительность для огромных данных.

Я попробовал кое-что из форума, но заметных улучшений не получил.

http://forums.pentaho.com/showthread.php?160467-how-to-improve-performance-of-Table-input-Table-output-step

http://forums.pentaho.com/showthread.php?85626-Kettle-4-2-0-Stable-Table-Input-does-full-table-read

http://forums.pentaho.com/showthread.php?59364-Optimum-Nr-of-Rows-in-Rowset

Пожалуйста, дайте мне знать, если я могу поделиться более подробной информацией для лучшего объяснения.

Заранее спасибо!


mysql transformation pentaho-spoon pentaho kettle
person user2595861    schedule 27.04.2017    source источник
comment
Вы пробовали запускать каждое преобразование отдельно? Может быть только один с огромными полями данных или какой-то шаг, занимающий всю память. Если все они завершат работу без ошибок, вы можете начать добавлять их вместе и посмотреть, когда он начнет выходить из строя.   -  person Cyrus    schedule 27.04.2017

Ответы (1)


arrow_upward
4
arrow_downward

Раньше я использовал PDI в аналогичных сценариях, но с разными базами данных.

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

Насколько я понимаю, каждый переход в преобразовании представляет собой буфер строк, который по умолчанию содержит до 10 тыс. Строк. Они видны в показателях как буферы ввода / вывода шагов и хранятся в памяти. Это означает, что чем больше у вас рядов и чем больше шагов, тем больше вам потребуется памяти.

В самом простом случае (ввод таблицы -> вывод таблицы) у вас будет один буфер строк размером 10 КБ. Если строки в среднем составляют 100 байт, вам потребуется более ... 1 МБ. Если у вас 11 шагов (10 буферов) и размер строки 32 КБ, вам может потребоваться более 3,2 ГБ, если все буферы заполнены.

Существуют также шаги для особых случаев, когда необходимо сохранить много строк или даже все строки, прежде чем они смогут начать вывод строк. Group By, Sort, Blocking Step являются примерами. Некоторые из них имеют возможность записывать промежуточные данные на диск, другие - нет. Избегайте этих массовых операций или уделяйте особое внимание потоку данных, чтобы оптимизировать его.

Если ваша целевая база данных не успевает за этим (распространенный сценарий, поскольку записи обходятся дороже), все буферы могут быстро заполниться. Одновременная запись большого количества преобразований в базу данных также может повлиять на производительность.

Есть много аспектов оптимизации такого рода операций, поэтому я не могу перечислить их все, но они уже решали проблемы для меня в прошлом:

  • Увеличьте количество строк на фиксацию, это может улучшить пропускную способность в целевой базе данных.
  • Увеличьте размер кучи Java (параметр -Xmx в файле запуска).
  • Сделайте сортировку в исходной базе данных.
  • Сделайте группировку в базе данных, если это хорошо (MySQL дал мне плохие результаты).
  • Если у вас есть много шагов до вывода таблицы и буферы заполнены, разделите преобразование. Поместите вывод в текстовый файл вместо вывода таблицы, поскольку он обычно выполняется молниеносно. Во втором преобразовании вы помещаете только ввод текстового файла и вывод таблицы.
person Cyrus    schedule 27.04.2017
comment
да, просто увеличьте Xmx. По умолчанию очень-очень низкий. - person Codek; 27.04.2017