こんばんは、

できるかどうかわからないので質問したかったのです。Simple HTML DOM で作成したスクレイピング プログラムがあります。

このプログラムは、さまざまな Web サイトからデータを抽出します。

だから私の質問は：

プログラムが失敗した場合に自動再起動できるようにプログラムを自動化することは可能ですか?

そして私はさらに進みます...

たとえば、特定のポイントからプログラムを再起動します。

プログラムが 2 の処理に失敗した場合は、チェックポイントから作業を再開したいと考えています。

不可能な場合は、その旨を伝えて質問を削除してください。問題ない。

どうもありがとう。

計算科学の典型的な状況は、数日/数週間/数か月連続して実行されるプログラムを持つことです。ハードウェア/OS の障害は避けられないため、通常はチェックポイントを利用します。つまり、プログラムの状態を時々保存します。失敗した場合は、最新のチェックポイントから再起動します。

チェックポイントを実装するPythonicの方法は何ですか?

たとえば、関数の変数を直接ダンプできます。

または、そのような関数をクラスに変換することを考えています（下記参照）。関数の引数は、コンストラクターの引数になります。アルゴリズムの状態を構成する中間データは、クラス属性になります。モジュールpickleは（非）シリアル化に役立ちます。

このソース コードのこのバージョンからドッカーを構築しています:
https://github.com/boucher/docker/tree/cr-combined

コードを複製した後：

CDドッカー

そして、結果のファイル @./bundles/../docker を usr/bin ディレクトリにコピーしました。ターミナルを再度開いて、docker エンジンを再起動した後。自分でビルドしたバージョンを使用していることを示していますが、このバージョンには、ビルドしたバージョンには表示されない 2 つの主要な docker コマンドが必要です。1- チェックポイント 2- 復元

どこが間違っていたのか教えてください

h2o.deeplearning を 2 回実行しようとしています。2 つのトレーニング セットでチェックポイント パラメーターを使用します (異なるエポックを除いて同じパラメーターを使用)。次のエラーが表示されます。

エラー: 'トレーニング データの列は、チェックポイントされたモデルと同じでなければなりません

ただし、両方のセットには同じ列があります。関連するコードの下に添付:

ありがとう、エリ。

ドキュメントには、Hadoop API と互換性のあるファイル システム ( HDFS 、 S3 など) をチェックポイント ディレクトリとして使用できることが記載されています。

私の質問は、HDFS と S3 以外に、Kafka と Cassandra を使用した Spark ストリーミング アプリケーションの実用的な代替手段は何かということです。

ありがとう

説明

Scala に Spark Streaming 1.5.2 アプリケーションがあり、Kinesis Stream から JSON イベントを読み取り、いくつかの変換/集約を行い、結果をさまざまな S3 プレフィックスに書き込みます。現在のバッチ間隔は 60 秒です。1 秒あたり 3000 ～ 7000 のイベントがあります。集計が失われないように、チェックポイントを使用しています。

しばらくの間、例外やクラスターの再起動から回復しており、うまく機能しています。最近、Spark Streaming 1.6.0 のコードを再コンパイルし、build.sbtファイルのライブラリ依存関係のみを変更しました。コードを Spark 1.6.0 クラスターで数時間実行した後、次のことに気付きました。

1. 1.6.0 では、「入力レート」と「処理時間」のボラティリティが大幅に増加しました (下のスクリーンショットを参照)。
2. 数時間ごとに、「レコードの書き込み中に例外がスローされます: BlockAdditionEvent ... が WriteAheadLog に記録されます。java.util.concurrent.TimeoutException: Futures timed out after [5000 milliseconds] 例外 (以下の完全なスタック トレースを参照) は、特定のバッチ (分) の 0 イベント/秒への低下と一致しています。

掘り下げた後、2番目の問題はこのプルリクエストに関連しているように見えます。PR の最初の目標: 「S3 を WAL のディレクトリとして使用すると、書き込みに時間がかかりすぎます。複数のレシーバーが AddBlock イベントを ReceiverTracker に送信すると、ドライバーは非常に簡単にボトルネックになります。この PR は、レシーバーが長時間ドライバーによってブロックされないように、ReceivedBlockTracker にイベントのバッチ処理を追加します。」</p>

Spark 1.5.2 の S3 でチェックポイントを行っており、パフォーマンスや信頼性の問題はありません。S3 およびローカル NAS で Spark 1.6.0 のチェックポイントをテストしましたが、どちらの場合もこの例外が発生しています。バッチのチェックポイントに 5 秒以上かかると、この例外が発生し、そのバッチのイベントが永久に失われることを確認しました。

質問

• Spark Streaming 1.6.0 で予想される「入力レート」と「処理時間」のボラティリティの増加はありますか? また、それを改善する既知の方法はありますか?

• これら2以外の回避策を知っていますか?:

  1) チェックポインティング シンクがすべてのファイルを書き込むのに 5 秒未満かかることを保証するため。私の経験では、小さなバッチであっても、S3 でそれを保証することはできません。ローカル NAS の場合は、インフラストラクチャの担当者によって異なります (クラウド プロバイダーでは難しい)。

  2) spark.streaming.driver.writeAheadLog.batchingTimeout プロパティの値を増やします。

• 説明されているシナリオでイベントが失われると思いますか? バッチ チェックポイントが失敗した場合、シャード/レシーバーのシーケンス番号は増加せず、後で再試行されると思います。

Spark 1.5.2 統計 - スクリーンショット

Spark 1.6.0 統計 - スクリーンショット

完全なスタック トレース

ソースコードの抜粋