2015-01-25 3 views
3

Мы хотим запланировать рабочий процесс на основе доступности данных, но нет особой частоты прихода данных. Также может быть несколько повторных запусков данных и, следовательно, несколько версий данных за день, прибывающий в любое время.Координатор Oozie с асинхронным набором данных

Как я понимаю из спецификации, в настоящее время обязательно указывать параметр частоты в координаторе.

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

Похоже, что это соответствует асинхронному набору данных. Поддерживает ли Oozie набор асинхронных данных?

+0

Вы решили это? У меня тоже есть аналогичное требование. спасибо –

ответ

0

Параметр частоты является обязательным, но Вы можете указать событие ввода, что-то вроде этого:

<datasets> 
    <dataset name="mydata" frequency="${coord:days(1)}" initial-instance="${initial_instance}" timezone="UTC"> 
     <uri-template>${hcat_uri}/${hcatDatabase}/${hcatTable}/dt=${YEAR}${MONTH}${DAY}</uri-template> 
    </dataset> 
</datasets> 
<input-events> 
    <data-in name="MYDATA_IN" dataset="mydata"> 
     <instance>${coord:current(0)}</instance> 
    </data-in> 
</input-events> 

https://oozie.apache.org/docs/3.1.3-incubating/CoordinatorFunctionalSpec.html#a6.1.4._Input_Events

Таким образом, определить относительно низкую частоту и содержательный блок, и он будет ждать доступность данных. Возможно, это имеет смысл указать тайм-аут для координатора, что меньше, чем частота:

<timeout>[TIME_PERIOD]</timeout> 

Или вы можете координат (начало) рабочий процесс непосредственно (без координатора) с, например: в cronjob, но это не приятно в все.

+0

Спасибо kecso за ваш ответ. Мы сконфигурировали нашего координатора с входными событиями так же, как вы упомянули. Существует таблица HCat с таблицей разделов (value_date, id). «id» - это идентификатор данных, предоставленных производителями данных. Поэтому координатор может ждать данных с id = xyz следующим образом: 'value_date = 2015-01-01; id = xyz' Теперь это работает отлично. А также, так как частота составляет 1 день, следующее действие координатора теперь ожидает прибытия данных на следующий день (2015-01-02). Однако раздел для 2015-01-01 может быть повторно создан в любое время производителями данных. –

+0

В идеале мы хотели бы добавить еще одну «версию» столбца в схему раздела, которая будет определять, какая версия тех же данных передается производителями данных. 'value_date = 2015-01-01; id = xyz; version =?' Однако проблема заключается в том, что координатор не знает, какую версию ждать. Производители данных могут отправлять данные следующими способами за один день: - отправить версию = v1 id = xyz в 7 вечера - отправить версию = v2 id = xyz в 9 вечера - отправить версию = v3 id = xyz в 21:30 , Как заставить координатора обрабатывать все это в реализации, управляемой событиями? –

+0

Так что, если вы обрабатываете триггер рабочего процесса самостоятельно, без координатора? Или создать отдельное действие (действие Fs), которое проверяет доступность данных и на основе маркера вызывает обработку или переходит к концу рабочего процесса? Координатор – kecso

Смежные вопросы