процесс медленных строк в Пентахо - PullRequest
Новая
       20

процесс медленных строк в Пентахо

1 голос
/ 12 июля 2019

У меня есть входная таблица с 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, чтобы выполнить эту задачу, используя шаг соединения, выбрать шаг значения, шаг сортировки строк и Stufs. Затем некоторые из «Преобразований данных» я разделил, используя «шаг калькулятора», думая, что это улучшит время процесса, но я получил то же время обработки

Я просто хочу, чтобы время обработки было меньше - от 5 часов до 1 или 2, но количество созданных строк в преобразовании слишком велико, чтобы сделать это. Помните, если запись имеет 9-летний период, генерирует 3000 строк приблизительно, и это только для одного. зная, что шаг ввода приносит 170 000 записей и различных диапазонов.

enter image description here

1 Ответ

2 голосов
/ 15 июля 2019

Если ваш шаг JS дает около 100 миллионов строк, ваш ETL работает со скоростью около 5,5 тысяч строк в секунду. Это не быстро, но и не так медленно.

Я не совсем понимаю, чего вы пытаетесь достичь, было бы неплохо посмотреть, чем занимается группа.

Но, независимо от этого, вот несколько идей, чтобы сделать это быстрее:

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

  2. Если вы группируете строки, входные данные должны быть отсортированы по групповым ключам, в противном случае вы получите неожиданные результаты.

  3. Когда вы запускаете преобразование, где узкое место? Вы можете видеть на вкладке метрики шага столбец ввода / вывода, который измеряет, насколько заполнены входной и выходной буферы каждого шага. Узкое место обычно выявляется путем поиска шага с полным входным буфером (по умолчанию 10 000 строк) и пустым выходным буфером. Таким образом, если шаг JS самый медленный, вы увидите его входной буфер в 10k, и все входные и выходные буферы в восходящем направлении также показывают 10k строк, тогда как все входные и выходные буферы в нисходящем направлении будут пустыми или почти пустыми.

  4. В конце концов, если вы пишете в базу данных, ожидается, что вывод никогда не будет таким быстрым, как внутренняя обработка строк в PDI. 5 тыс. Строк в секунду - это, как правило, хорошая производительность, и ее сложно значительно улучшить. Однако вы можете прекратить использовать шаг вывода таблицы и вместо этого использовать массовый загрузчик. Большинству массовых загрузчиков баз данных нужны данные для записи в файл, но MySQL можно использовать с FIFO, в Mac или Linux (не работает в Windows)

...