Discretized Streams: Fault-Tolerant Streaming Computation at Scale
2014年7月4日 Katsunori Kanda
紹介する論文について• SOSP’13
• Author: Matei Zaharia et al. (UCB)
• CTO@databricks
• Assistant Professor@MIT
• Contributor of Apache Spark
概要• 新しいストリーム処理モデル(D-Streams)の提案
• 特徴1: parallel recovery
• 特徴2: スループットがスケール(100nodes)
• 特徴3: latencyが数秒~数百ミリ秒
• Spark Streamingとして実装
Apache Sparkとは?
Spark ModelWrite programs in terms of transformations on distributed datasets !
Resilient Distributed Datasets (RDDs) • Collections of objects that can be stored in memory or disk across a cluster • Parallel functional transformations (map, filter, …)
• Automatically rebuilt on failure
2. Goals and Background• 対象とするアプリケーションの例
• Site activity statistics: 10^6 events/s
• Cluster monitoring
• Spam detection
• 0.5-2 sec latency(not target: high-frequency trading)
2.1 Goals1. Scalability to hundreds of nodes
2. Minimal cost beyond base processing
3. Second-scale latency
4. Second-scale recovery from faults and stragglers
2.2 既存の処理モデル
• continuous operator model
• 生存期間が長い状態を持ったオペレータに分割して計算する。入力値によって状態が更新される。
2.2 Previous Processing Models: Replication
• 同じ入力を二つのシステムが同時に受け取る。二つのシステムは、同期が必要になる(DB等が典型例)
2.2 Previous Processing Models: Upstream Backup
• 各ノードはあるチェックポイント以降に送られてきたメッセージのコピーを保持する
• ノードがfailした場合、待機系のノードがfailしたノードの状態を再構築する。この再構築のコストは高い。
• 例: MapReduce Online, Storm
Handle stragglers• 既存のモデルでは、stragglerの問題に対処できない
• replication: stragglerが発生すると全体が遅くなる(同期が必要のため)
• upstream backup: failureとして扱うことになるが、リカバリーが高コスト(前述)
3. Discretized Streams (D-Streams)
• D-Streamsは、
• 小さい(short)
• 状態を持たない(stateless)
• 決定論的タスク(deterministic tasks)
3.1. Computation Model• 短い間隔の決定論的な連続したバッチ計算
3. Computation Model: Recovery from faults
• partition単位で再計算される
• 無限に再計算されることを避けるために、一定間隔で非同期レプリケーションが行われRDDの状態が保存される
• 再計算は、並列実行可能
3.2. Timing Considerations
• 順番通りにデータが到着しない問題への対応
• 余裕時間(slack time)の間はバッチの開始を待つ
• アプリケーションレベルで遅れてきたレコードを処理する方法を提供
3.3. D-Stream API(1/3)
• Transformations: 新しいD-Streamを作る
• paris = words.map(w => (w, 1))
• counts = pairs.reduceByKey((a, b) => a + b)
Stateless API
3.3. D-Stream API(2/3)Stateful API
ex. pairs.reduceByWindow(“5s”, (a,b) => a + b) pairs.reduceByWindow(“5s”, (a,b) => a + b, (a,b) => a - b)
Incremental aggregation:
3.3. D-Stream API(3/3)Stateful API
sessions = events.track( (key, ev) => 1, (key, st, ev) => ev == Exit ? null : 1, “30s”) count = sessions.count()
state tracking:
3.4. Consistency Semantics
• nodeによって処理の進行状況が違うと整合性の問題が生じる
• 既存システム: 同期で解決、または無視
• D-Streams: 時間が区切られているので明確
3.5. Unification with Batch & Interactive Processing
• Batchと同じ計算モデルを使っているのでBatchと組み合わせやすい
• 特徴1: バッチの結果とjoinできる
• 特徴2: 過去データを計算できる
• 特徴3: 対話的な問い合わせができる
• counts.slice(“21:00”, “21:05”).topK(10)
3.6. Summary
4. System Architecture
• Master: D-Streamの系統グラフの管理、タスクスケジューリング、RDD partitionの作成
• Worker nodes: dataを受け取る、partitionへの入力と計算されたRDDの保存、タスク実行
• Client Library: システムにデータを送る
4.2. Optimization for Stream Processing
• Network communication: 非同期I/Oを導入。reduceが速くなった。
• Timestamp pipelining: Sparkのスケジューラーを次の時間の処理を先に登録できるように修正した
• Task scheduling
• Storage layer: 非同期チェックポイントの追加。RDDがimmutableなのでブロックしなくていい。zero-copy I/Oも実装。
• Lineage cutoff: チェックポイント作成後に削除するようになっった
• Master recovery: マスターの状態復帰機能を実装
4.3 Memory Management
• LRUでデータをdiskに書き出している
5.1. Parallel Recovery
5.2. Straggler Mitigation
• simple threshold to detect straggler:
• タスク処理時間の中央値の1.4倍
• 1秒以内にはstragglerを解消できている
5.3. Master Recovery1. 各時間の処理開始前に計算の信頼度記録
2. マスターがfailした場合、各workerが保持しているRDD partitionを新しいマスターに報告する
重要なのは・・・ 同じRDDを二回計算しても問題ないこと
5.3. D-Streamsのメタデータ• D-Streamsのメタデータ@HDFS
• ユーザーのD-Streamグラフ、ユーザー定義関数
• 最後のチェックポイント作成時刻
• RDDのID(チェックポイント以降)
6.1. Performance
6.1. Comparison with S4 and Storm
6.2. Varying the Checkpoint Interval
6.2. Varying the Number of Nodes
6.2. Struggler Mitigation