在每小时的 5 分钟标记处,我将过去一小时的数据加载到 hdfs 中。我想我可以设置一个协调器作业,使其在每小时 10 分钟标记处运行以处理此数据,同时检查该小时的目录是否存在。最终发生的事情是协调器将在提交时对过去一小时的数据执行正常,在接下来的 2 小时内继续正常工作,然后 future 的操作将从“等待”变为“超时”。我的猜测是对于一个 Action 可以停留在“等待”状态的时间有一个默认的最大限制。将超时限制应用于绝对 future 时间的所有操作似乎有点违反直觉。不管怎样,这是 coordinator.xml 的示例。我正在寻找关于如何以更有意义的方式设计它或如何提高默认超时的任何建议。
<datasets>
<dataset name="hourly_cl" frequency="${coord:hours(1)}" initial-instance="2016-02-08T11:10Z" timezone="PST">
<uri-template>hdfs://user/tzl/warehouse/incoming/logmessages.log.${YEAR}${MONTH}${DAY}/${HOUR}/</uri-template>
<done-flag></done-flag>
</dataset>
<dataset name="hourly_cl_out" frequency="${coord:hours(1)}" initial-instance="2016-02-05T11:10Z" timezone="PST">
<uri-template>hdfs://user/tzl/warehouse/output/logmessages.log.${YEAR}${MONTH}${DAY}/${HOUR}/</uri-template>
<done-flag></done-flag>
</dataset>
</datasets>
<input-events>
<data-in name="coordInput1" dataset="hourly_cl">
<instance>${coord:current(-1)}</instance>
</data-in>
</input-events>
<output-events>
<data-out name="clout" dataset="hourly_cl_out">
<instance>${coord:current(-1)}</instance>
</data-out>
</output-events>
<action>
<workflow>
<app-path>${appPath}</app-path>
<configuration>
<property>
<name>inputPath</name>
<value>${coord:dataIn('coordInput1')}</value>
</property>
<property>
<name>outputPath</name>
<value>${coord:dataOut('clout')}</value>
</property>
</configuration>
</workflow>
</action>
在查看日志时还注意到 oozie 每分钟都会检查每个数据目录。换句话说,在 18:01 它将检查这些是否存在 logmessages.log.20160208/18
日志消息.log.20160208/19
日志消息.log.20160208/20
日志消息.log.20160208/21
...
然后在 18:02 再次检查 logmessages.log.20160208/18
日志消息.log.20160208/19
日志消息.log.20160208/20
日志消息.log.20160208/21
...
这可能占用了不必要的 CPU 周期。我假设通过将频率设置为一个小时,当我将实例定义为过去一小时的数据时,它会足够聪明,不会浪费时间检查 future 的数据集:current(-1)
最佳答案
我通过简单的属性调整解决了这个问题。通过在 coordinator-app 下引入这个
<coordinator-app name="cl_test" frequency="${coord:hours(1)}" start="..." end="..." timezone="PST" xmlns="uri:oozie:coordinator:0.2">
<controls>
<timeout>1440</timeout>
<concurrency>2</concurrency>
<throttle>1</throttle>
</controls>
...
...
</coordinator-app>
具体来说,<throttle>
属性限制可以将多少个 Action 置于等待状态。因此,通过将其设置为 1,超时时间仅适用于处于“等待”状态的下一个 Action 。 <timeout>
还更改了“等待”操作的超时限制,而我相信 <concurrency>
限制一次可以运行多少个 Action 。
关于hadoop - Oozie 每小时协调员对 future 的行动超时,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35281633/