Oozie Behavior с несогласованным стартом

Question

Я заметил, что если я начну координатор Oozie с временем начала много «итераций» (с точки зрения частоты), предшествующего текущему времени, тогда координатор будет последовательно запускать рабочие процессы несколько раз, игнорируя назначенной частоты. Однако для меня важнее, чтобы рабочий процесс/действие выполнялось на заданной частоте, чем для рабочего процесса/действия, чтобы запустить правильное количество раз в заданной точке.

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

Answer 1

Очевидным способом избежать побочных эффектов из «прошлых» дат начала является ... установить фактическую дату начала в момент представления как «сейчас».

Это, как мы делаем это в моей команде:

• на локальной файловой системе, запишите «Корд-template.xml» с заполнителем, такие как старт = «% Теперь%»

• только перед отправкой, генерировать фактические "Coordinator.xml" с

  СЭД "s /% Теперь%/$ (дата --utc '+% FT% TZ') /" коорд-template.xml > coordinator.xml

• загрузить определение координатора для HDFS затем представить его через Oozie CLI

~~~~~~~~~~~~

Aternative: если вы используете "основной" частоты (не CRON типа планирования) вы можете попробовать эти < управления >, чтобы Oozie создать казни для всех «прошлых» временных интервалов, но отказаться от них сразу:

<throttle>1</throttle> 

и/или

<execution>LAST_ONLY</execution> 

cf. Oozie 4.x reference

Правила также будут применяться в случае, координатор приостанавливается затем возобновляется, или в случае, если служба Oozie получает остановки и перезапуска, или в случае ПРЯЖА имеет в очередь новые рабочие места для очень долго (потому что кластер занят на 100%).

Answer 2

Oozie улучшилось в последнее время, поэтому есть более доступное решение, чем принятый в настоящее время ответ. Начиная с версии Oozie 4.1, существует «NONE» исполнение. Это пропускает итерации, которые происходят в прошлом, более или менее. Вот фрагмент документа:

НЕТ: Подобно LAST_ONLY, за исключением всех старых материализаций, пропускается. Когда NONE установлено, действие, которое ОЖИДАЕТСЯ или ГОТОВЫ, будет ПРОПУСКАЕТ, когда текущее время больше определенного определенного количества минут (допуск) за номинальное время действия. По умолчанию порог составляет 1 минуту. Например, предположим, что действия 1 и 2 оба ОЖИДАЮТ, текущее время равно 5:20 вечера, а номинальное время обоих действий - до 17:19. Оба действия станут SKIPPED, если они не переходят к SUBMITTED (или состоянию терминала) до этого.Другой способ задуматься об этом заключается в том, чтобы рассматривать его так же, как установка таймаута, равного 1 минуте, которая является наименьшей единицей времени, за исключением того, что статус SKIPPED не приводит к тому, что задание координатора в конечном итоге становится DONEWITHERROR и может фактически стать SUCCEEDED (т.е. это «хорошая» версия TIMEDOUT).

Oozie 4.1 doc

Я испытал это, и он работает с частотами CRON. Он превосходит исполнение LAST_ONLY в вашем случае, потому что LAST_ONLY по-прежнему будет выполнять самую последнюю итерацию в прошлом (с несогласованным временем), в дополнение к текущим и будущим итерациям.

<execution>NONE</execution>