Spark カーネル分析 - デプロイメントモード分析 8 (6)

1. 展開モードの分析

1.1 導入モードの概要

Spark でサポートされている主な 3 つの分散デプロイメント方法は、スタンドアロン、Spark on mesos、および Spark on YARN です。スタンドアロンモード、つまり独立モードには完全なサービスが付属しており、他のリソース管理システムに依存せずに独立してクラスターにデプロイできます。Spark によって実装されたリソーススケジューリングフレームワークで、主なノードはクライアントノード、マスターノード、ワーカーノードです。Yarn は統合されたリソース管理メカニズムであり、マップリデュース、ストームなどのコンピューティングフレームワークの複数のセットを実行できます。クラスター内のドライバーの位置に従って、Yarn クライアントと Yarn クラスターに分割されます。Mesos は、より強力な分散リソース管理フレームワークであり、yarn を含むさまざまなフレームワークをデプロイできるようになります。基本的に、Spark の実行モードは、SparkContext に渡される MASTER 環境変数の値に依存します。一部のモードでは、補助プログラムインターフェイスを一緒に使用することも必要です。現在サポートされているマスター文字列と URL は次のとおりです。

ここに画像の説明を挿入します
ユーザーが処理のためにタスクを Spark に送信すると、次の 2 つのパラメーターによって Spark の実行方法が決定されます。
· –master MASTER_URL: Spark タスクが処理のために送信されるクラスターを決定します。
· –deploy-mode DEPLOY_MODE: ドライバーの実行モードを決定します。オプションの値は、クライアントまたはクラスターです。

1.2スタンドアロンフレームワーク

スタンドアロンクラスタは 3 つの異なるレベルのノードで構成されます:
1) マスターコントロールノード (議長または舵取りに相当します。クラスタ全体で、アクティブ状態のマスターは最大 1 つあります。2
) ワーカーノード, これはマネージャーであり、副舵です。クラスター全体では、複数のワーカーが存在できます。ワーカーがゼロの場合は、何も実行できません。3
) 実行者はハードワークを実行し、ワーカーによって直接制御されます。1 つのワーカーが実行できます。複数のエグゼキュータを起動します。起動の数は、マシン内の CPU コアの数によって制限されます。
これら 3 つの異なるタイプのノードはそれぞれ、独自の JVM プロセスで実行されます。
スタンドアロンモードでは、クラスターの起動時にマスターとワーカーが含まれ、マスターはクライアントから送信されたジョブを受信し、ワーカーを管理します。ジョブの送信方法の違いに応じて、クライアント側のドライバーとワーカー側のドライバーに分けられます。以下の図 7 に示すように、上の図は作業モードのドライバーを示し、下の図はクライアントモードのドライバーを示しています。2 つのモードの主な違いは、ドライバーが配置される場所です。
スタンドアロンデプロイメントモードはクライアントモードとクラスターモードに分かれています。クライアントモードでは、ドライバーとクライアントは同じ JVM で実行され、ワーカーによって開始されません。JVM プロセスは、Spark アプリケーションが計算を完了して結果を返すまで終了しません。結果。以下に示すように。

ここに画像の説明を挿入します
クラスターモードでは、ドライバーはワーカーによって開始され、クライアントは Spark アプリケーションがクラスターに正常に送信されたことを確認した後、Spark アプリケーションの実行結果が返されるのを待たずに直接終了します。以下に示すように

ここに画像の説明を挿入します
デプロイメント図から、各 JVM プロセスのファイル依存関係が開始時にどのように満たされるかを分析します。
1) マスタープロセスが最も単純です。Spark jar パッケージを除いて、サードパーティライブラリの依存関係はありません。2
) Driver と Executor は実行時にサードパーティパッケージの依存関係がある可能性があります。個別に言うと、
3) ドライバーは比較的単純です。
4) Executor は Worker によって起動され、Worker は Executor の起動時に必要な jar ファイルをダウンロードする必要があるため、どこからダウンロードするかを指定します。

ここに画像の説明を挿入します

Spark スタンドアロンモード、つまり独立モードには完全なサービスが付属しており、他のリソース管理システムに依存せずに独立してクラスターにデプロイできます。このモードでは、ユーザーはマスターとワーカーを手動で起動することで、独立したクラスターを起動できます。このうちマスターはリソース管理の役割を果たし、ワーカーは計算ノードの役割を果たします。このモードでは、Spark Driver プログラムがクライアント (Client) 上で実行され、Executor が Worker ノード上で実行されます。
以下は、1 つのマスターノードと 2 つのワーカーノードを含む、スタンドアロンモードで実行される Spark タスクスケジューリングの対話型デプロイメントアーキテクチャ図です。

ここに画像の説明を挿入します
上記の Spark タスクスケジューリングプロセスから、次のことがわかります。
1) クラスター全体がマスターノードとワーカーノードに分割され、ドライバープログラムがクライアント上で実行されます。マスターノードは、ワーカーノード上のコンピューティングリソースをタスクに割り当てる役割を担っており、途中の赤い双方向矢印で示されているように、両者は相互に通信してリソースのステータスを同期します。
2) クライアントがタスクを開始すると、ドライバープログラムが実行され、SparkContext オブジェクトの初期化が完了し、マスターに登録されます。
3) 各ワーカーノードには 1 つ以上の ExecutorBackend プロセスが存在します。各プロセスにはスレッドプールを保持する Executor オブジェクトが含まれており、各スレッドプールはタスクを実行できます。ExecutorBackend プロセスは、クライアントノード上のドライバープログラムと通信し、タスクのステータスを報告する役割も担います。

1.2.1 スタンドアロンモードでのタスク実行プロセス

上記のプロセスは、スタンドアロンモードの Spark のクライアント、マスター、ワーカーノード間の全体的な対話を反映しています。タスクの特定の実行プロセスには、より詳細な分解が必要です。分解された実行プロセスは、図の小さい文字で示されています。
1. ユーザーは、bin/spark-submit デプロイメントツールまたは bin/spark-class を通じてアプリケーションのドライバープロセスを開始し、ドライバープロセスは SparkContext オブジェクトを初期化し、マスターノードに登録します。
1. マスターノードはドライバープログラムの登録を受け入れ、管理するワーカーノードを確認し、必要なコンピューティングリソース Executor をドライバープログラムに割り当てます。ワーカーノードはエグゼキュータの割り当てを完了すると、エグゼキュータのステータスをマスターに報告します。
2. Worker ノード上の ExecutorBackend プロセスが開始されると、Driver プロセスに登録されます。
2. ドライバープロセスは、DAG Schaduler、Stage Schaduler、Task Schaduler などのプロセスを介してタスク分割を完了した後、Worker ノード上の ExecutorBackend に TASK を割り当てます。
1.ExecutorBackend は TASK 計算を実行し、最後まで TASK ステータスを Driver に報告します。
2. すべてのタスクが処理された後、ドライバープロセスはマスターからログアウトします。

1.2.2 概要

Spark は、Spark 自体が提供する動作モードであるスタンドアロンモードで実行できます。ユーザーは、マスタープロセスとワーカープロセスを手動で開始して独立したクラスターを開始したり、テスト用のマシン上でこれらのデーモンプロセスを実行したりできます。スタンドアロンモードは運用環境で使用できるため、ユーザーが Spark フレームワークを学習してテストするコストを効果的に削減できます。
スタンドアロンモードは現在、アプリケーション全体にわたる単純な FIFO スケジューリングのみをサポートしています。ただし、複数の同時ユーザーを許可するために、各アプリケーションで使用されるリソースの最大数を制御できます。デフォルトでは、クラスタ内のすべての CUP コアの使用を要求します。
デフォルトでは、スタンドアロンタスクスケジューラはワーカーの失敗を許可します (この場合、失敗したタスクを他のワーカーに転送できます)。ただし、スケジューラはスケジュールにマスターを使用するため、マスターがクラッシュすると新しいアプリケーションが作成されなくなるという単一点の問題が生じます。この問題を解決するには、ZooKeeper の選択メカニズムを使用してクラスター内の複数のマスターを起動するか、ローカルファイルを使用して単一ノードの回復を実現します。

1.3糸クラスターモード

Apache 糸は、Apache Hadoop オープンソースプロジェクトの一部です。これはもともと、mapreduce コンピューティングフレームワークのリソース管理の問題を解決するために設計されました。Haodoop 2.0 は、糸を使用して、mapreduce の分散コンピューティングとリソース管理を分離します。その導入により、Hadoop 分散コンピューティングシステムはプラットフォーム時代に入りました。つまり、さまざまなコンピューティングフレームワークがクラスター内で実行でき、リソース管理システム YRAN によって均一に管理およびスケジュールされるため、クラスター全体のリソースが共有され、リソースの使用率が向上します。
　　YARN には通常、マスター/スレーブアーキテクチャ (ResourceManager/NodeManager) があります。前者 (RM) は、各 NodeManager (NM) 上のリソースの統合管理とスケジューリングを担当します。コンテナはリソースの割り当てとスケジューリングの基本単位であり、メモリ、CPU、ディスク、ネットワークなどのマシンリソースをカプセル化します。各タスクにはコンテナが割り当てられます。タスクはコンテナ内でのみ実行および使用できます。カプセル化されたリソース。NodeManager の役割は、アプリケーションコンテナを受信して起動し、このノード上のアプリケーションコンテナの実行ステータスとリソース使用量を RM に報告することです。ApplicationMaster は特定のアプリケーションに関連しており、主に ResourceManager と交渉して適切なコンテナを取得し、これらのコンテナのステータスを追跡し、その進行状況を監視する役割を果たします。以下の図は糸クラスターの一般的なモデルを示しています。
ここに画像の説明を挿入します
Spark を糸クラスターにデプロイするには、糸クライアント (ドライバーがクライアント上で実行される) と糸クラスター (ドライバーがマスター上で実行される) の 2 つの方法があり、マスター上のドライバーを以下の図に示します。

ここに画像の説明を挿入します
(1) Spark Yarn クライアントは、アプリケーションマスタープログラム、アプリケーションマスターを開始するコマンド、Executor で実行する必要があるプログラムなどを含むアプリケーションを YARN に送信します;
(2) リソースマネージャーがリクエストを受信した後、いずれかのノードでアプリケーションはコンテナを割り当て、コンテナ内でアプリケーションのアプリケーションマスターを開始する必要があります。アプリケーションマスターは、sparkContext を初期化し、DAG スケジューラとタスクスケジューラを作成します。
(3) アプリケーションマスターはsparkContextの設定に基づいてリソースマネージャーにコンテナを申請すると同時に、アプリケーションマスターはリソースマネージャーに登録され、ユーザーはリソースマネージャーを通じてアプリケーションの実行状況を確認できるようになります。
(4) リソースマネージャーはクラスター内で適格なコンテナを検索します。ノードマネージャーはノードマネージャーでコンテナを起動し、コンテナにエグゼキューターの起動を要求します。
(5) エグゼキューターが起動すると、アプリケーションマスターに登録し、タスクを受け取ります。 (6)アプリケーション
が完了すると、アプリケーションマスターはリソースマネージャーにログアウトとシャットダウンを申請します。
クライアント上のドライバーは次の図に示されています。
ここに画像の説明を挿入します
(1) Spark Yarn クライアントは YARN のリソースマネージャーに適用され、アプリケーションマスターを起動します。同時に、SparkContent の初期化で DAG スケジューラと TASK スケジューラが作成されます
(2) リクエストを受信した ResourceManager は、クラスタ内の NodeManager を選択し、最初のコンテナをアプリケーションに割り当て、アプリケーションマスターの起動を要求します。 YARN-Cluster との違いは、ApplicationMaster が SparkContext を実行せず、リソース割り当てのために SparkContext に接続するだけであることです
(3) クライアント内の SparkContext が初期化された後、アプリケーションとの通信を確立します。マスタ、リソースマネージャに登録、タスク情報を基にリソースマネージャに報告リソースマネージャがリソースを申請（コンテナ）
(4) アプリケーションマスタがリソースを申請すると、ノードマネージャと通信して起動を依頼コンテナ
(5) コンテナが起動すると、ドライバのsparkContextに登録され、タスクに適用されます。
(6) アプリケーションが実行されます。完了後、クライアントのSparkContextがResourceManagerに適用され、ログアウトして閉じられます。
　　以下の図 11 からわかるように、Yarn クライアントモードと Yarn クラスターモードの比較では、Yarn クライアント (クライアント上のドライバー) では、アプリケーションマスターは Yarn からエグゼキューターへのリソースのみに適用され、その後クライアントは、ジョブをスケジュールするコンテナ。クライアントがクラスターから遠く離れている場合、この方法を使用することはお勧めできませんが、対話型操作にはこの方法が役立ちます。
ここに画像の説明を挿入します
Spark はクラスターの形式で実行でき、使用可能なクラスター管理システムには Yarn、Mesos などが含まれます。クラスターマネージャーの中核機能は、リソース管理とタスクスケジューリングです。Yarn を例にとると、Yarn はマスター/スレーブモードで動作し、リソースマネージャー (RM) はマスターノード上で実行され、クラスター全体のリソースとリソース割り当ての管理を担当します。スレーブノード上で実行されているノードマネージャー (NM) は、クラスター内のリソースを実際に所有する作業ノードです。ジョブを送信すると、ジョブを構成する複数のタスクが対応するノードマネージャにスケジュールされて実行されます。また、リソースはノードマネージャ上でコンテナの形で抽象化されており、コンテナにはメモリと CPU の 2 つのリソースが含まれます。
以下は、1 つのリソースマネージャーノードと 3 つのノードマネージャーノード (そのうち 2 つはワーカーノード、1 つのマスターノード) を含む、Yarn クラスター上で実行される Spark タスクスケジューリング Exchange デプロイメントアーキテクチャ図です。

ここに画像の説明を挿入します
上記の Spark タスクスケジューリングプロセス図からわかるように:
1) クラスター全体がマスターノードとワーカーノードに分割され、どちらもノードマネージャーノード上に存在します。クライアントがタスクを送信すると、タスクはタスクによって均一に割り当てられます。 Resource Manager: Driver プログラムを実行するノードは Master ノードと呼ばれ、特定のタスクを実行するノードは Worder ノードと呼ばれます。図の赤い双方向矢印で示されているように、ノードマネージャノード上のリソースの変更は、リソースマネージャに適時に更新される必要があります。
2) マスターデーモンはマスターノード (ドライバープログラム) に常駐します。SparkContext オブジェクトはドライバープログラムで作成され、各ワーカーノードの ExecutorBackend プロセスと通信し、ワーカーノード上のタスクを管理し、タスクの進行状況を同期します。実際、Yarn 内のノードマネージャ間の関係は等しいため、ドライバプログラムは任意のノードマネージャノードにスケジュールされます。
3) 各ワーカーノードには 1 つ以上の ExecutorBackend プロセスが存在します。各プロセスにはスレッドプールを保持する Executor オブジェクトが含まれており、各スレッドプールはタスクを実行できます。ExecutorBackend プロセスは、マスターノード上のドライバープログラムと通信し、タスクのステータスを報告する役割も担います。

1.3.1 クラスタ配下のタスク実行プロセス

上記のプロセスは、リソースマネージャーノードとノードマネージャーノード間の全体的な対話、および Spark クラスターモードでのマスターとワーカー間の対話を反映しています。タスクの特定の実行プロセスには、より詳細な分解が必要です。分解された実行プロセスは、図の小さい文字で示されています。
1) ユーザーは、bin/spark-submit デプロイメントツールまたは bin/spark-class を通じてアプリケーションを Yarn クラスターに送信します。
2) Yarn クラスターのリソースマネージャーは、送信されたアプリケーションのノードマネージャーノードを選択し、最初のコンテナーを割り当て、ノードのコンテナーで SparkContext オブジェクトを開始します。
3) SparkContext オブジェクトは、Yarn クラスターのリソースマネージャーからのリソースに適用され、Executor を実行します。
4) Yarn クラスターのリソースマネージャーは SparkContext オブジェクトにコンテナーを割り当てます。SparkContext は関連するノードマネージャーと通信し、取得したコンテナー上で ExecutorBackend デーモンを起動します。ExecutorBackend の起動後、SparkContext への登録とタスクの適用を開始します。。
5) SparkContext は実行のためにタスクを ExecutorBackend に割り当てます。
6) ExecutorBackend はタスクの実行を開始し、適時に実行ステータスを SparkContext に報告します。
タスクの実行が終了すると、SparkContext はリソースをノードマネージャーに返し、ログアウトします。

1.4mesosクラスターモード

Mesos は、Apache のオープンソース分散リソース管理フレームワークです。これはカリフォルニア大学バークレー校で生まれ、後に Twitter によって普及し使用されました。Mesos にはさまざまな分散フレームワークを展開できます。Mesos のアーキテクチャ図を以下の図 12 に示します。ここで、フレームワークとは、Hadoop、Mesos などの外部コンピューティングフレームワークを指します。これらのコンピューティングフレームワークは、登録を通じて Mesos に接続できます。 Mesos は統合管理とリソース割り当てを実行できることを示しています。

ここに画像の説明を挿入します
図 12 Mesos の一般的な展開図
　　Mesos 上で実行されるフレームワークは 2 つの部分で構成されます。1 つはスケジューラで、マスターに登録することでクラスターリソースを取得します。もう 1 つはスレーブノード上で実行されるエグゼキュータプロセスで、フレームワークのタスクを実行できます。マスターは各フレームワークに提供するリソースの数を決定し、フレームワークのスケジューラが提供されるリソースを選択します。フレームワークは、提供されたリソースに同意すると、マスター経由でタスクを送信し、リソースを提供するスレーブ上で実行します。Mesos のリソース割り当て図は図 13 に示すとおりです。
ここに画像の説明を挿入します
図 13 Mesos のリソース割り当て図
(1) スレーブ 1 は、4 つの CPU と 4 GB のメモリが利用可能であることをマスターに報告します
(2) マスターは、リソースオファーを Framework1 に送信して、スレーブ 1 が利用可能なリソースの数を説明します
(3) FrameWork1 の FW スケジューラがマスターに応答します, Slave1 で実行する必要がある 2 つのタスクがあります。1 つのタスクには <2 CPU、1 GB メモリ=""> が必要で、もう 1 つのタスクには <1 CPU、2 GB メモリ=""> が必要です (
4) 最後に、マスターこれらのタスクを Slave1 に送信します。その後、Slave1 にはまだ使用されていない 1 CPU と 1 GB のメモリがあるため、割り当てモジュールはこれらのリソースを Framework2 に提供できます。Spark は
　　分散フレームワークの 1 つとしてメソにデプロイできます。デプロイメント図は一般的なフレームワークと似ていますメソの展開図は次のとおりです。図 14 はここでは繰り返しません。
ここに画像の説明を挿入します

1.5Spark の 3 つの展開モードの違い

これら 3 つのデプロイメントモードのうち、Spark に付属する分散デプロイメントモードであるスタンドアロンは、最も単純かつ基本的な Spark アプリケーションデプロイメントモードであるため、ここでは詳しく説明しません。ヤーンとメソの違いは次のとおりです。
(1) 2 つのフレームワーク自体に関する限り、ヤーンフレームワークはメソにデプロイできます。Yarn はより一般的な展開フレームワークであり、テクノロジーはより成熟しています。
(2) Mesos デュアルレイヤースケジューリングメカニズムは複数のスケジューリングモードをサポートできますが、Yarn は Resource Manager を通じてクラスターリソースを管理し、1 つのスケジューリングモードのみを使用できます。Mesos の 2 層スケジューリングメカニズムは次のとおりです。mesos は、yarn などの分散デプロイメントフレームワークに接続できますが、Mesos では、アクセス可能なフレームワークに、フレームワーク内のタスクのスケジューリングを担当するスケジューラモジュールが必要です。フレームワークが Mesos にアクセスしたい場合、Mesos に登録し、Mesos によって割り当てられたリソースを取得するようにスケジューラーを変更する必要があり、その後、そのスケジューラーがフレームワーク内のタスクにこれらのリソースを割り当てる、つまり Mesos システム全体が採用すると言われています。 2 層のスケジューリングフレームワーク: 第 1 レベルでは、Mesos がフレームワークにリソースを割り当て、第 2 レベルでは、フレームワーク自体のスケジューラがリソースを独自の内部タスクに割り当てます。
(3) Mesos は、大まかなリソーススケジューリングと詳細なリソーススケジューリングを実装し、リソースを動的に割り当てることができますが、Yarn は静的なリソース割り当てのみを実装できます。粗粒度
　　モード: プログラムを実行する前に、必要なさまざまなリソース (各エグゼキュータが占有するリソースの数、および内部で実行できるエグゼキュータの数) を申請する必要があります。運用中に変更することはできません。
　　詳細モード: リソースの無駄を防ぐために、リソースはオンデマンドで割り当てられます。粗粒度モードと同様に、アプリケーションの起動時に実行プログラムが最初に起動されますが、各実行プログラムが占有するリソースは自身の動作に必要なリソースのみであり、実行されるタスクを考慮する必要はありません。その後、Mesos は各エグゼキューターに動的に割り当てます。リソースが割り当てられるたびに、新しいタスクを実行できます。単一のタスクの実行後、対応するリソースはすぐに解放されます。各タスクは Mesos スレーブと Mesos マスターにステータスを報告し、よりきめ細かい管理とフォールトトレランスを促進します。このスケジューリングモードは、MapReduce スケジューリングモードに似ています。各タスクは完全に独立しています。利点は、リソースの制御と分離が容易になることです。 , しかしデメリットも明らかで、短いジョブの実行遅延が大きくなります。
　　ヤーンとメソの違いから、それぞれに独自の長所と短所があることがわかります。したがって、実際の使用において、どのフレームワークを選択するかは企業の実際のニーズに依存し、既存のビッグデータの生態環境を考慮することができます。例えば、当社ではSparkのデプロイにyarnを使用していますが、これは当社がすでに比較的成熟したHadoopフレームワークを持っているためであり、使い勝手を考慮してyarnモードのデプロイを採用しています。

1.6 異常シナリオ分析

上記は通常時の各ノードのメッセージ配信内容です。では、運用中にクラスター内の一部のノードに問題が発生した場合でも、クラスター全体はアプリケーション内のタスクを正常に処理できるのでしょうか?

1.6.1 例外解析 1: ワーカーが異常終了する

ここに画像の説明を挿入します
Spark の実行中によく発生する問題は、ワーカーが異常終了することです。ワーカーが終了すると、クラスター全体にどのようなストーリーが起こりますか? 以下の詳細な説明を参照してください
1) ワーカーが異常終了します。ワーカーの強制終了
2) ワーカーが終了する前に、ワーカーが制御するすべての若いエグゼキュータを強制終了します
3) ワーカーはマスターへのハートビートメッセージを定期的に改善する必要がありますワーカープロセスが完了したので、ハートビートメッセージがないため、マスターはタイムアウトプロセス中に、「サブ舵」の 1 つが離れたことが認識されました。
4) マスターは非常に悲しんでいました。悲しんだマスターは、対応するドライバーに状況を報告しました。
5)ドライバーは、自身に割り当てられたエグゼキューターが残念ながら 2 つの側面を経て離脱したことを確認しました。1 つはマスターが送信した通知であり、2 番目の通知は、ドライバーが指定された時間内にエグゼキューターの StatusUpdate を受信しなかったため、ドライバーは登録されたエグゼキューターを削除します。

1.6.1.1 結果の分析

ワーカーの異常終了による影響は何ですか?
1) エグゼキューターの終了により、サブミットされたタスクは正常に終了できず、再度実行のためにサブミットされます
2) すべてのワーカーが異常終了すると、クラスター全体が使用できなくなります
3) 対応するプログラムワーカープロセス (supervisord または runit の使用など) を再起動する必要があります。

1.6.1.2 テスト手順

1) マスターを開始します。
2) ワーカーを開始します。
3) スパークシェルを開始します
。 4) ワーカープロセスを手動で強制
終了します。 5) jps または ps -ef|grep -i java を使用して、開始中の Java プロセスを表示します。

1.6.1.3 異常終了時のコード処理

ExecutorRunner.scala で定義された開始関数

def start() {
    
    
  workerThread = new Thread("ExecutorRunner for " + fullId) {
    
    
    override def run() {
    
     fetchAndRunExecutor() }
  }
  workerThread.start()
  // Shutdown hook that kills actors on shutdown.
  shutdownHook = new Thread() {
    
    
    override def run() {
    
    
      killProcess(Some("Worker shutting down"))
    }
  }
  Runtime.getRuntime.addShutdownHook(shutdownHook)
}

killProcess の処理は、対応する CoarseGrainedExecutorBackend のプロセスを停止します。
ワーカーを停止する場合は、まず開始した Executor を停止する必要があります。

1.6.1.4 概要

特に、ワーカーが Executor を開始するときは、ExecutorRunner を介して実行されることに注意してください。ExecutorRunner は独立したスレッドであり、Executor と 1 対 1 の関係にあり、これは非常に重要です。Executor は独立したプロセスとして実行されますが、ExecutorRunner によって厳密に監視されます。

1.6.2 例外解析 2: executor が異常終了する

ここに画像の説明を挿入します
Executor は、スタンドアロンクラスター展開モードの最下位レベルの従業員として、異常終了した場合にどのような影響を及ぼしますか?
Executor が異常終了しました。ExecutorRunner は例外に気づき、ExecutorStateChanged を通じてマスターに状況を報告しました。
通知を受けたマスターは非常に不機嫌でした。逃げたい弟がいたけど、大丈夫でした。 Executor が属する Worker に再起動を依頼しました。Worker
は LaunchExecutor コマンドを受け取りました。Executor を再度起動します。

1.6.2.1 テスト手順

1) マスターを開始します
2) ワーカーを開始します
3) スパークシェルを開始します
4) CoarseGrainedExecutorBackend を手動で終了します

1.6.2.2 fetchAndRunExecutor

fetchAndRunExecutor は、特定の Executor を起動し、その実行ステータスを監視する役割を果たします。具体的なコードロジックは次のとおりです。

def fetchAndRunExecutor() {
    
    
  try {
    
    
    // Create the executor's working directory
    val executorDir = new File(workDir, appId + "/" + execId)
    if (!executorDir.mkdirs()) {
    
    
      throw new IOException("Failed to create directory " + executorDir)
    }

    // Launch the process
    val command = getCommandSeq
    logInfo("Launch command: " + command.mkString("\"", "\" \"", "\""))
    val builder = new ProcessBuilder(command: _*).directory(executorDir)
    val env = builder.environment()
    for ((key, value)  {
    
    
      logInfo("Runner thread for executor " + fullId + " interrupted")
      state = ExecutorState.KILLED
      killProcess(None)
    }
    case e: Exception => {
    
    
      logError("Error running executor", e)
      state = ExecutorState.FAILED
      killProcess(Some(e.toString))
    }
  }
}

1.6.3 例外解析 3: マスターが異常終了する

ここに画像の説明を挿入します
ワーカーとエグゼキューターが異常終了するシナリオについてはすでに説明しましたが、マスターが死亡した場合はどうすればよいでしょうか?
主役の兄弟がいなくなったらどうなるでしょうか？
1) ワーカーには報告する対象がない、つまり実行者が再び逃げた場合、ワーカーは実行者を起動しない、上司からの指示がない
2) 新しいタスクをクラスタに投入できない
3) さえも古いタスクが終了すると、古いタスクが占有します。リソースのクリア指示はマスターによって発行されるため、リソースをクリアできません。

2. ワードカウントプログラムの動作原理を覗いてみる

2.1Spark の scala は wordcount を実装します

Spark で scala を使用して wordcount (統計的な単語出現モデル) を実装する方が簡単で、Java コードよりも簡潔で、関数型プログラミングの思考ロジックもより直感的です。

package com.spark.firstApp

import org.apache.spark.{
    
    SparkContext, SparkConf}

/**
  * Created by atguigu,scala实现wordcount
  */
object WordCount1 {
    
    
  def main(args: Array[String]) {
    
    
    if (args.length == 0) {
    
    
      System.err.println("Usage: WordCount1 <file1>")
      System.exit(1)
    }
    /**
      * 1、实例化SparkConf；
      * 2、构建SparkContext,SparkContext是spark应用程序的唯一入口
      * 3. 通过SparkContext的textFile方法读取文本文件
      */
    val conf = new SparkConf().setAppName("WordCount1").setMaster("local")
    val sc = new SparkContext(conf)

    /**
      * 4、通过flatMap对文本中每一行的单词进行拆分（分割符号为空格），并利用map进行函数转换形成(K,V)形式，再进行reduceByKey，打印输出10个结果
      *    函数式编程更加直观的反映思维逻辑
      */
    sc.textFile(args(0)).flatMap(_.split(" ")).map(x => (x, 1)).reduceByKey(_ + _).take(10).foreach(println)
    sc.stop()
  }
}

2.2 原則

Spark クラスターで wordcount プログラムを実行する主なビジネスロジックは比較的単純で、次の 3 つのプロセスをカバーします:
1) ストレージメディア上のテキストファイルの読み取り (通常は HDFS に保存されています)、
2) テキストファイルの内容を解析し、ワードプロセッサを実行します。グループ統計サマリ;
3) プロセス 2 のグループ化結果を記憶媒体に保存します。(通常、HDFS または RMDB に保存されます)
ワードカウントのビジネスロジックは非常に単純ですが、Spark でのそのアプリケーションの実行プロセスは、Spark の核心である分散型弾性データセット、メモリ反復、関数型プログラミングを巧みに反映しています。次の図は、Spark テクノロジの原理の理解を深めるために、Spark クラスター内のワードカウントの実行プロセスを分析しています。

ここに画像の説明を挿入します
図は水平に分割されており、wordcount の scala コアプログラムの実装を以下に示します。Spark クラスターでのこのプログラムの実行プロセスには、主に textFileRDD、 flatMapRDD、mapToPairRDD、shuffleRDD (reduceByKey) などのいくつかのコア RDD が含まれます。
アプリケーションは、textFile メソッドを通じて hdfs 上のテキストファイルを読み取ります。データは断片化され、上の図に示すように、統合モードとして RDD を使用して、ノード 1、ノード 2 ～ノード n、および A シリーズを通じて異なる物理ノードにロードされます。 flatMap を使用してテキストファイル内の対応するデータ行を分割し (テキストファイル内の単語はスペースで区切られます)、各単語をコアとする新しいデータセット RDD を形成し、MapRDD による変換を継続するなどのデータ変換(K, V) データフォームは、reduceByKey メソッドをさらに使用するために形成されます。このメソッドは、シャッフル動作をトリガーし、対応するノードでさまざまな単語が集計され、カウントされるように促します (実際には、データはデータの前にローカルでシャッフルされます)自慢ノードでシャッフルされ、同じ単語がマージされて蓄積され、単語数の統計結果が形成され、最終的にデータは saveAsTextFile メソッドを通じて HDFS に保存されます。具体的な動作ロジックの原理とプロセスを上の図に示します。