Sparkカーネル分析(3)Spark通信アーキテクチャーの原理分析

1. Spark通信アーキテクチャーの概要

Spark 2.xバージョンは、内部通信コンポーネントとしてNetty通信フレームワークを使用します。Nettyに基づく
ここに画像の説明を挿入
Sparkの新しいrpcフレームワークは、Akkaの設計に基づいています。次の図に示すように、Actorモデルに基づいています。Spark通信フレームワークの各コンポーネント(クライアント/マスター/ワーカー)1つずつ考えられ独立的实体、各エンティティは通信するメッセージ。様々な構成要素間の特定の関係は次の通りである:
ここに画像の説明を挿入
エンドポイント(クライアント/マスター/ワーカー)が1 个 InBox、そしてN 个 OutBox(N> = 1、Nおよびどの他の多くの現在のエンドポイントエンドポイントが通信または他のエンドポイント送信トレイの対応する一つとの通信に応じて)、Endpoint 接收到的消息被写入 InBox,发送出去的消息写入OutBox ,并被发送到其他 Endpoint 的 InBox 中

2、Spark通信アーキテクチャー分析

Spark通信アーキテクチャを次の図に示します:
ここに画像の説明を挿入
(1)RpcEndpoint:RPCエンドポイント、Sparkは各ノード(クライアント/マスター/ワーカー)をRpcエンドポイントと呼び、すべてRpcEndpointインターフェイスを実装します。内部設計は、エンドポイントのニーズに応じて異なります。メッセージやさまざまなビジネス処理、送信(照会)が必要な場合は、Dispatcherを呼び出します。

(2)RpcEnv:RPCコンテキスト環境。実行時に各RPCエンドポイントが依存するコンテキスト環境はRpcEnvと呼ばれます。

(3)Dispatcher:メッセージディストリビューター。リモートRPCから受信したメッセージまたはメッセージを送信する必要があるRPCエンドポイントの場合、それらを対応するコマンド受信ボックス/送信ボックスに配布します。指示の受信者が自分の場合は受信トレイに入れ、指示の受信者が自分でない場合は送信トレイに入れます。

(4)Inbox:命令メッセージの受信トレイ。ローカルのRpcEndpointは受信トレイに対応し、メッセージが受信トレイに格納されるたびにDispatcherが対応するEndpointDataを内部のReceiverQueueに追加し、Dispatcherが作成されるときに別のスレッドが開始されます。受信トレイメッセージを消費するようにReceiverQueueに問い合わせます。

(5)RpcEndpointRef:RpcEndpointRefは、リモートRpcEndpointへの参照です。特定のRpcEndpointにメッセージを送信する必要がある場合、通常はRpcEndpointへの参照を取得してから、アプリケーションを介してメッセージを送信する必要があります。

(6)OutBox:指示メッセージ送信ボックス。現在のRpcEndpointでは、1つのターゲットRpcEndpointが1つの送信ボックスに対応します。複数のターゲットRpcEndpointsに情報を送信する場合、複数のOutBoxがあります。メッセージが送信トレイに置かれると、TransportClientを介して送信されます。メッセージは送信トレイに入れられ、送信プロセスは同じスレッドで実行されます。

(7)RpcAddress:リモートRpcEndpointRef、ホスト+ポートのアドレスを表します。

(8)TransportClient:Netty通信クライアント、1つのOutBoxは1つのTransportClientに対応し、TransportClientはOutBoxを継続的にポーリングし、OutBoxメッセージの受信者情報に従って対応するリモートTransportServerを要求します。

(9)TransportServer:Netty通信サーバー。1つのRpcEndpointは1つのTransportServerに対応し、リモートメッセージを受信した後、Dispatcherが呼び出されて、対応する送受信ボックスにメッセージを配信します。

上記の分析に基づいて、Spark通信アーキテクチャの概要を次の図に示します。
ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/weixin_43520450/article/details/108607367