7
AWS Kinesisストリームに接続されたSpark Streamingを使用して、受信しているメトリックを集計し、その集約をinfluxdbに書き込んで利用できるようにしますリアルタイムのダッシュボード。Kinesisスパークストリーミング受信機のチェックポイントの動作
すべてうまくいっていますが、システムの展開や最終的な障害の中断をどのように管理するべきか検討中です。
ドキュメントでは、Kinesis統合ライブラリはすでに障害やチェックポイントなどのために準備されていると言われていますが、ここでチェックポイントがどのように機能しているかを明確にしたいと思います。
キネシス受信機は、Amazonのソフトウェアライセンス（ASL）の下でアマゾンが提供するキネシスクライアントライブラリ（KCL）を使用して入力DSTREAMを作成します。 KCLは、Apache 2.0ライセンスのAWSのJava SDKの上に構築され、労働者、チェックポイント、およびシャードリースの概念を介して負荷分散、フォールトトレランス、チェックポイントを提供します。
キネシスのチェックポイント間隔を定義できますが、ストリームのどのポイントまで測定基準を消費したかをマークするために使用されています。だから、スパークストリーミングのチェックポイント機能を使用する必要があります。
1分あたりのデータを集計するので、バッチ間隔は60秒ですが、60秒間はストリームからデータを継続的に受信しています。私は（仕事の新しいバージョンを展開するために）JavaStreamingContext.stop（...）を実行すると、受信機が停止され、
- チェックポイントは以下となります。ここでは
は私の質問です最後に更新されますか？
- スパークストリーミングチェックポイントはいつ発生しますか？仕事のたびに？前？
- 両方のチェックポイントが機能していると仮定すると、障害発生時の一貫性をどのように保証できますか？ストリーミングチェックポイントが発生するたびに、同時にキネシスにチェックポイントを設定する必要があります。そうしないと、同じデータをもう一度読み終えることができます。これをどうすれば処理できますか？
- 基礎となるサービス（この場合はinfluxdb）がダウンしている場合、どうすればよいですか？再試行メカニズムを実装しますか？その場合は、しばらくしてから再試行を停止する必要があります。そうしないと、Out of Memoryが実行されます。事前に
ありがとう！