NiFiノードがダウンした時のエラーハンドリングについて、2つパターン。
1)外部からNiFiにデータが入る。例えばListen***系
2)NiFi内部のデータをProcessor間で流れる
2つパターンの詳細は下記。
パターン1:外部からNiFiにデータが入る。
例えばListen***系。
Listen系の処理を NiFi Network Listening Processors 仕組みにまとめました。
要は、NiFiのListen系処理が間に合わなかったらデータが溢れる。
それを防ぐために、NiFiチューニングか、ハードウェアスケールが必要。
参考資料:
* At least once delivery vs exactly once delivery semantics in Apache NIFI
- NiFi/MiNiFi間のS2Sプロトコルでデータ伝送するなら、at least onceは問題無い。
- 更に、S2Sポートの後ろにDetectDuplicateを正しく使えば、Exactly onceも可能。
- それ以外のプロトコル、2-phase commitが対応出来るなら(例えばKafka)least onceは保証出来る ** support 2-phase commit未対応のプロトコル、例えばSyslog protocolなら、NiFiではleast onceの保証は出来ない、あくまでもat most onceレベル。
パターン2:NiFi内部のデータをProcessor間で流れる
NiFiプロセッサー毎にトランザクションがある。
https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/processor/AbstractProcessor.java
public final void onTrigger(final ProcessContext context, final ProcessSessionFactory sessionFactory) throws ProcessException {
final ProcessSession session = sessionFactory.createSession();
try {
onTrigger(context, session);
session.commit();
} catch (final Throwable t) {
session.rollback(true);
throw t;
}
}
- Session is started
- Flow file is obtained
- Operations performed
- Flow file is transferred or removed
- Session is committed
で、もしプロセッサーAから、プロセッサーBにデータを渡して、プロセッサーB(例えばPutHDFS or PutFile)が処理中に落ちたら、
Commitはしません。
再起動後、前回のところをもう一度やりますので、データの漏れは無いです。