読者です 読者をやめる 読者になる 読者になる

KZKY memo

自分用メモ.

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 files as input source

HDFSがソースならどんなFailureがおこってもデータロスはない(HDFSが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はロストする

まとめるとこのようになる.
f:id:KZKY:20141228040706p:plain

Semantics of output operations

RDDに対するTransformationのセマンティックスは1回になるが,Node Failureが起こった時の書込みのセマンティックスは一回以上になる.