Spark StreamingとKafkaデータの整合性

@Author  : Spinach | GHB
@Link    : http://blog.csdn.net/bocai8058

文書ディレクトリ

1信頼性の高いデータソースおよび信頼性の高い受信機

2メタデータ永続化(Metadata checkpointing)

3は、データが失われたシーン

がある可能性がある.

4 WAL(Write ahead log)

5 At-least-onceセマンティック

6 WALの欠点

7 Kafka direct API

Spark Streamingを正しく導入すると、Spark Streamingが提供するデータ損失ゼロメカニズムを使用できます.この重要な特性を体験するには、次のいくつかの前提条件を満たす必要があります.

入力データは、信頼性の高いデータソースおよび信頼性の高い受信機から入力される.

アプリケーションのmetadataはアプリケーションのdriverによって永続化された(checkpointed).

WALプロパティ(Write ahead log)を有効にします.

以下、これらの前提条件を簡単に紹介します.
1信頼性の高いデータソースと信頼性の高い受信機
Kafkaなどのいくつかの入力データソースについて、Spark Streamingは受信したデータを確認することができる.入力したデータは、まず受信機(receivers)によって受信され、Sparkに格納される(デフォルトでは、2つのアクチュエータに格納され、フォールトトレランスを行う).データがSparkに格納されると、受信機はそれを確認することができる(例えば、Kafka内のデータを消費する際にZookeeper内のオフセット量を更新することができる).このメカニズムは、受信機が突然停止した場合でもデータが失われないことを保証している.データは受信されているが、永続化されていない場合は確認メッセージが送信されないため、受信機が回復したときにデータを元の端で再送信することができる.

2メタデータ持続化(Metadata checkpointing)
信頼性の高いデータ・ソースと受信機により、受信機から切り離された状態でリカバリできます.(または受信機で実行されているExectuorとサーバをシャットダウンしてもよい).しかし、さらに厄介な問題は、Driverがシャットダウンした場合にどのようにリカバリするかということです.開発者たちは、Driverを失敗からリカバリするために多くの技術を導入しています.1つは、アプリケーションのメタデータに対してCheckpintを実行することです.この特性を利用して、Driverはアプリケーションの重要なメタデータを永続化することができますHDFS、S 3などの信頼性の高い記憶において、その後、Driverはこれらの永続化されたデータを利用してリカバリすることができます.メタデータは次のとおりです.

構成;

コード;

キューにおいてまだ処理されていないbatch(これらのbatchのデータではなくメタデータのみを保存する)

.

メタデータのCheckpintがあるため、Driverは彼らを利用してアプリケーションを再構築することができ、Driverが停止したときにアプリケーションがどこまで実行されるかを計算することができます.
3データ消失の可能性があるシーン
驚くべきことに、信頼性の高いデータソース、信頼性の高い受信機、およびメタデータのCheckpintであっても、潜在的なデータ損失を阻止するには十分ではありません.次のような悪い場面を想像することができます.

の2つのExectuorは、受信機から入力データを受信し、Exectuorのメモリにキャッシュした.

受信機は、入力ソースデータが受信されたことを通知する.

Exectuorは、アプリケーションのコードに従ってキャッシュされたデータの処理を開始する.

この時Driverが突然切れた.

設計の観点から見ると、Driverが切れると、メンテナンスされているExectuorもすべてkillされます.

すべてのExectuorがkillされた以上、それらのメモリにキャッシュするデータも失われる77.Exectuorのメモリにキャッシュされているため、データが失われているため、キャッシュ時にリカバリすることはできません.

これは多くの重要なアプリケーションにとって非常に悪いのではないでしょうか.
4 WAL(Write ahead log)
上記の悪いシナリオを解決するために、Spark Streaming 1.2はWALメカニズムを導入し始めた.
WALメカニズムが有効になっているので、受信したデータは、HDFSやS 3のようなフォールトトレランス記憶に書き込まれる.WAlメカニズムを採用しているため、Exectuorのメモリのデータが失われても、Driverは失敗した点からデータを再読み込みできます.この簡単な方法の下で、Spark StreamingはDriverが削除してもデータ損失を回避できるメカニズムを提供しています.

5 At-least-onceの意味
WALは、データが失われないことを保証しますが、すべてのデータソースに対してexactly-onceの意味を保証することはできません.Spark Streaming統合Kafkaで発生する可能性のある悪いシーンを想像してみてください.

受信機は入力データを受信し、WALに格納する.

受信機は、ZookeeperにおけるKafkaのオフセット量を更新する前に突然停止した.

Spark Streamingは、WALに書き込まれているため、入力データが正常に受信されたと仮定するが、Kafkaは、対応するオフセット量がZookeeperで更新されていないため、データが消費されていないと判断する.

がしばらくすると、受信機は失敗から回復します.

WALに保存されたが処理されていないデータが再読み取りされる.

WALからすべてのデータが読み出されると、受信機は、Kafkaからデータの消費を開始する.受信機はKafkaのHigh-Livel Consumer APIを用いて実現されているため、Zookeeperが現在記録しているオフセット量からデータの読み取りを開始するが、受信機が停止したときにオフセット量がZookeeperに更新されなかったため、いくつかのデータが2回処理された.

6 WALの欠点
WALには、上記のシーンに加えて、無視できない2つの欠点があります.

WALは、受信したデータが信頼できる分散ファイルシステムに保存されなければならないため、受信機のスループットを低減する.

は、いくつかの入力ソースについて同じデータを繰り返します.たとえば、Kafkaからデータを読み込む場合は、Kafkaのbrokersにデータを保存し、Spark Streamingに保存する必要があります.

7 Kafka direct API
WALによって導入された性能損失を解決し、exactly-onceの意味を保証するために、Spark Streaming 1.3にはKafka direct APIという名前が導入されている.
この考えはこの特性に対して非常に賢明である.Spark driverは、次のbatchがKafka中のオフセット量を処理する必要がある範囲を簡単に計算し、その後、Spark ExectuorにKafka対応するTopicのパーティションから直接データを消費するように命令するだけである.言い換えれば、この方法はKafkaをファイルシステムと見なし、ファイルを読むようにTopicのデータを消費する.

このシンプルで強力なデザインでは、

はKafka受信機を必要とせず、ExectuorはSimple Consumer APIを直接採用してKafkaからデータを消費する.

WALメカニズムは必要ありません.私たちは依然として失敗から回復した後、Kafkaからデータを再消費することができます.

exactly-onceの意味は保存され、WALから重複するデータは読み込まれません.

参照:https://www.csdn.net/article/2015-06-21/2825011 | https://www.iteblog.com/archives/1591.html