私はアプリケーションを開発していますSpark / Spark-Streamingですが、これまでは常にファイルストレージにHDFSを使用していました。ただし、HDFSを使用せずに（運用中、24時間年中無休で）実行できるかどうかを調査する段階に達しました。 Sparkユーザーグループをふるいにかけましたが、具体的な答えはまだ見つかりませんでした。私はチェックポイントとステートフルストリーム処理を使用していることに注意してください updateStateByKey.
回答：
回答№1は1ストリーミングに応じて（私はKafkaを使用しています）、チェックポイントなどを使用する必要はありません。
Spark 1.3以降、彼らは非常に多くの利点を持つ直接的なアプローチを実装しています。
簡素化された並列処理： 複数の入力Kafkaストリームを作成する必要はありません そしてそれらを結合します。 directStreamを使用すると、Spark Streamingは次のように作成されます。 消費するKafkaパーティションがあるため、多くのRDDパーティション すべてがKafkaから並行してデータを読み取ります。一対一です KafkaとRDDパーティション間のマッピング。 理解して調整します。
効率： 必要な最初のアプローチでゼロデータ損失を達成する Write Ahead Logに保存されるデータ。さらに複製されます。 データ。データが効率的に取得されるため、これは実際には非効率的です 2回複製-Kafkaが1回、Write Aheadが2回 ログ。この2番目のアプローチでは、問題がないため、 レシーバー、およびそれゆえ先書きログの必要はありません。
必ず1回のセマンティクス： 最初のアプローチでは、Kafkaの高レベルAPIを使用します Zookeeperで消費されたオフセットを保存します。これが伝統的な方法です Kafkaからデータを消費します。このアプローチ（と組み合わせて 先書きログ）は、データの損失をゼロにできます（つまり、少なくとも1回） セマンティクス）、一部のレコードが消費される可能性がわずかにあります いくつかの障害で2回。これは矛盾のために発生します Spark Streamingが確実に受信したデータと追跡されたオフセットの間 Zookeeperによって。したがって、この2番目のアプローチでは、単純なKafka APIを使用します Zookeeperを使用せず、Sparkのみによって追跡されるオフセット チェックポイント内でのストリーミング。これにより不整合が解消されます Spark StreamingとZookeeper / Kafkaの間で、各レコードは 障害にもかかわらず、Spark Streamingによって1回だけ効果的に受信されます。
Kafkaを使用している場合は、こちらで詳細を確認できます。 https://spark.apache.org/docs/1.3.0/streaming-kafka-integration.html
アプローチ2。