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に関しては,データソースがネットワークになると思われるのでそうではないので次の2つを考える.
- 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のセマンティックスは1回になるが,Node Failureが起こった時の書込みのセマンティックスは一回以上になる.