Spark Streaming 4
Fault-tolerance Semanticsについての話．
基本はここのまとめ
Spark RDDのfalut-tolerence semantics
Spark RDDのfalut-tolerence semanticsのおさらい．
- イミュータブルで決定的に再計算可能で分散化されており，自分の決定的操作の系譜を覚えている．
- ワーカーノードがFailしてRDDのパーティションがなくなった時，データレプリカ(e.g., HDFSなら)と系譜を元に再計算．
- RDDのすべての操作は決定的とされてるので，最終的な操作結果は，スパーククラスタのFailureに関係なく同じになる．
Sparkアプリのインプットソースはほとんどがfault-toleranceなソース(e.g., HDFS, S3)からなのでそこから生成されるRDDもfault-tolerance．しかしSpark Streamingに関しては，データソースがネットワークになると思われるのでそうではないので次の２つを考える．
- Data received and replicated
- この場合は，1つのワーカーノードがFailしてもデータは生きている．
- Data received but buffered for replication
- データはもう復帰できない．もう一回データを送ってもらうしかない．
どのノードがFailかも考慮する必要がある．
- Failure of a Worker Node
- このノード上にあるデータはFail．リシーバ上のバッファーもそう．
- Failure of the Driver Node
- SparkContextがなくなるのだから，Executorもそれ上のIn-MemoryデータもFail．
Semantics with input sources based on receivers
インプットソースはReceiverベースなので，FailureシナリオとReceiverタイプ両方考える必要がある．
- Reliable Receiver
- Worker FailureならReceiverにあるbuffered dataはロストしない．ワーカー再起動でインプットソースはもう一度データを送る．Driver FailureではIn-Memory dataはロストする
- Unreliable Receiver
- Driver/Worker FailureでReceiverにあるbuffered dataとIn-Memory dataはロストする
まとめるとこのようになる．
Semantics of output operations
RDDに対するTransformationのセマンティックスは１回になるが，Node Failureが起こった時の書込みのセマンティックスは一回以上になる．
