このシリーズには次のものが含まれます。
- 【ビッグデータ】Flink詳しく解説(1):基礎編
- 【ビッグデータ】Flinkの詳細解説(2):コア編 前編
- 【ビッグデータ】Flink詳しく解説(3):コア編Ⅱ
- 【ビッグデータ】フリンク詳しく解説(4):コア編Ⅲ
- 【ビッグデータ】Flinkの詳しい解説(5):核心編IV
- 【ビッグデータ】Flinkの詳しい解説⑥:ソースコード編 前編
- 【ビッグデータ】Flinkの詳しい解説(7):ソースコードⅡ
Flink詳細解説(7):ソースコードⅡ
- 69. フロー図、操作図、実行図の違いは何ですか?
- 70. フロー図を紹介しますか?
- 71. 宿題の図について教えてください。
- 72. 実行図について教えてください。
- 73. Flink スケジューラの概念を紹介しますか?
- 74. Flink のスケジュール動作には何種類ありますか?
- 75. Flink にはスケジューリング モードがいくつありますか?
- 76. Flink のスケジューリング戦略は何種類ありますか?
- 77. Flink ジョブのライフサイクルにはどのような状態が含まれますか?
- 78. タスクのジョブライフサイクルにはどのような状態が含まれますか?
- 79. Flink のタスク スケジューリング プロセスについて説明してください。
- 80. フリンクのタスクスロットとはどういう意味ですか?
- 81. Flink スロット共有とは何を意味しますか?
69. フロー図、操作図、実行図の違いは何ですか?
現在、Flink はストリームとバッチの統合コードを実装しているため、Batch API は基本的に放棄されているため、あまり紹介しません。Flink DataStream API では、Graph の内部変換グラフは次のとおりです。
WordCount を例に挙げると、フロー グラフ、ジョブ グラフ、実行グラフ、物理実行グラフ間のタスク スケジューリングは次のようになります。
Flink ストリーム コンピューティング アプリケーションの場合、ユーザー コードを実行するときは、まず DataStream API を呼び出してユーザー コードを変換に変換し、次に次の 3 つのStreamGraph → JobGraph → ExecutionGraph
変換層 (これらは Flink の組み込みデータ構造です) を通過し、最後に Flink スケジューリング実行を通過します。 、Flink クラスター内 コンピューティング タスクを開始して、物理的な実行グラフを形成します。
70. フロー図を紹介しますか?
StreamGraph には、 StreamNodeとStreamEdgeという 2 つのコア オブジェクトがあります。
-
StreamNodeは Transformation から変換されたものであり、単純に理解すると、StreamNode は実体と仮想が存在し、複数の入出力を持つことができる演算子を表しており、最終的には実体 StreamNode が物理演算子となり、仮想的に StreamEdge の端に接続されます。
-
StreamEdgeは StreamGraph のエッジであり、2 つの StreamNode ポイントを接続するために使用されます。StreamEdge は複数の発信エッジ、着信エッジ、およびその他の情報を持つことができます。
71. 宿題の図について教えてください。
JobGraph は StreamGraph から最適化されています。OperationChain メカニズムを通じて演算子を結合します。実行中、それらは同じタスク スレッド上でスケジュールされ、スレッド間およびネットワーク間のデータ転送を回避します。
ジョブ グラフ JobGraph コア オブジェクトには次の 3 つが含まれます。
-
JobVertex ポイント: オペレーター融合の最適化後、条件を満たす複数の StreamNode を融合して JobVertex を生成できます。つまり、JobVertex には 1 つ以上のオペレーターが含まれ、JobVertex の入力は JobEdge、出力は IntermediateDataSet です。
-
JobEdge エッジ: JobEdge は JobGraph のデータ フロー チャネルを表し、その上流のデータ ソースは IntermediateDataSet、下流のコンシューマは JobVertex です。JobEdge におけるデータ分散モードは、実行時のタスク間のデータ接続関係がポイントツーポイント接続であるかフル接続であるかに直接影響します。
-
IntermediateDataSet Intermediate DataSet : Intermediate DataSet IntermediateDataSet は、JobVertex の出力、つまり JobVertex に含まれるオペレータによって生成されるデータ セットを表すために使用される論理構造です。実行モードが異なると、対応する結果パーティションのタイプも異なり、それによって実行時のデータ交換モードが決まります。
72. 実行図について教えてください。
ExecutionGraph は、ジョブ内のすべての並列実行タスク情報、タスク間の関連付け関係、およびデータ フロー関係を含む、Flink ジョブの実行をスケジュールするためのコア データ構造です。
StreamGraph と JobGraph はどちらも Flink クライアントで生成され、Flink クラスターに渡されます。JobGraph から ExecutionGraph への変換は JobMaster 内で完了します。変換プロセス中の重要な変更点は次のとおりです。
- 並列処理の概念が追加され、真にスケジュール可能なグラフ構造になりました。
- 生成された6 66つのコアオブジェクト。
実行グラフ ExecutionGraph コア オブジェクトには6 6が含まれます6 :
-
ExecutionJobVertex : このオブジェクトは、JobGraph の JobVertex に対応します。このオブジェクトには、ExecutionVertex のセットも含まれています。その数は、StreamNode の並列性が5 5であると仮定して、JobVertex に含まれる StreamNode の並列性と一致します。5の場合、ExecutionJobVertex にも5 55実行頂点。ExecutionJobVertex は、JobVertex を ExecutionJobVertex にカプセル化し、ExecutionVertex、Execution、IntermediateResult、IntermediateResultPartition を順番に作成して ExecutionGraph を強化するために使用されます。
-
ExecutionVertex : ExecutionJobVertex はジョブを並列化し、並列実行できるインスタンスを構築します。並列実行の各インスタンスは ExecutionVertex です。
-
IntermediateResult : IntermediateResult は中間結果セットとも呼ばれます。このオブジェクトは ExecutionJobVertex の出力を表す論理概念であり、JobGrap の IntermediateDalaSet に対応します。現在の JobVertex にあるエッジ (JobEdge) の数に応じて、同じ ExecutionJobVertex が複数の中間結果を持つことができます。 . .
-
IntermediateResultPartition : IntermediateResultPartition は中間結果パーティションとも呼ばれます。1 1を意味します1 ExecutionEdge に関連付けられた ExecutionVertex 出力結果。
-
ExecutionEdge : 上流で生成された IntermediateResultPartition に接続される ExecutionVertex の入力を示します。1 11実行は一意の1 11 つのIntermediateResultPartition と1 11実行頂点。1 11 つのExecutionVertex は複数の ExecutionEdge を持つことができます。
-
Execution : ExecutionVertex は各タスクのテンプレートに相当し、実際に実行される際には ExecutionVertex の情報が1 1としてパッケージ化されます1回の実行、1 つの ExecutionVertex の実行を 1 回試行。
JobManager と TaskManager 間のタスクのデプロイメントおよびタスクの実行ステータスの更新は、ExecutionAttemptID によって識別されます。
73. Flink スケジューラの概念を紹介しますか?
スケジューラは Flink ジョブ実行のコア コンポーネントであり、JobGraph から ExecutionGraph への変換、ジョブのライフ サイクル管理 (ジョブのリリース、キャンセル、停止)、ジョブのタスクのライフ サイクル管理 (タスクのリリース、キャンセル、停止)、リソースの適用と解放、ジョブとタスクのフェイルオーバーなど。
-
DefaultScheduler : Flink の現在のデフォルト スケジューラは、
SchedulerStrategy
スケジューリングの実装に使用される Flink の新しいスケジューリング設計です。 -
LegacySchedular : 過去のスケジューラは、独自の実行スケジューリング ロジックを実現していました。
74. Flink のスケジュール動作には何種類ありますか?
SchedulingStrategyインターフェイスは、 4 4を含むスケジューリング動作を定義します。4つの行動:
startScheduling
: スケジューリング エントリ。スケジューラのスケジューリング動作をトリガーします。restartTasks
: 実行に失敗したタスクを再起動します。これは通常、タスクの異常な実行が原因です。onExecutionStateChange
: 実行状態が変化したとき。onPartitionConsumable
: IntermediateResultPartition 内のデータが消費できる場合。
75. Flink にはスケジューリング モードがいくつありますか?
スケジュールモードには3 3が含まれます3種類: Eager モード、フェーズド モード (Lazy_From_Source
)、フェーズド スロット再利用モード (Lazy_From_Sources_With_Batch_Slot_Request
)。
-
積極的なスケジューリング: ストリーム コンピューティングに適しています。必要なリソースを一度に申請してください。リソースが不足している場合、ジョブは開始されません。
-
段階的スケジューリング:
LAZY_FROM_SOURCES
バッチ処理に適しています。スケジューリングはSourceTaskから段階的に開始されますので、リソースを申請する際は、この段階で必要なリソースを一度に申請してください。上流タスクの実行後、下流タスクのスケジュールと実行を開始し、上流データを読み込んでこのステージの計算タスクを実行し、実行完了後、次のステージのタスクをスケジュールしてスケジュールします。作業が完了するまで回してください。 -
段階的スロット再利用スケジューリング:
LAZY_FROM_SOURCES_WITH_BATCH_SLOT_REQUEST
バッチ処理に適しています。基本的にフェーズドスケジューリングと同じですが、リソース不足時にジョブを実行できるバッチリソース適用モードを使用する点が異なりますが、この段階ではジョブ実行中にシャッフル動作が発生しないようにする必要があります。
Eager
そのパターンと現在見ているパターンLAZY_FROM_SOURCES
のリソース適用ロジックは同じであり、LAZY_FROM_SOURCES_WITH_BATCH_SLOT_REQUEST
別のリソース適用ロジックです。
76. Flink のスケジューリング戦略は何種類ありますか?
スケジューリング戦略はすべてスケジューラに実装されておりSchedulingStrategy
、次の 3 つの実装があります。
-
EagerSchedulingStrategy : ストリーム コンピューティングに適しており、すべてのタスクを同時にスケジュールします。
-
LazyFromSourcesSchedulingStrategy : バッチ処理に適しており、入力データの準備ができた (上流の処理が完了した) ときに頂点のスケジューリングが実行されます。
-
PipelinedRegionSchedulingStrategy : パイプラインのローカル粒度でスケジュールを設定します。
PipelinedRegionSchedulingStrategy
は1.11 1.111.11で追加1.12 から 1.121.12以降、 の単位pipelined region
で
pipelined region
パイプライン化されたタスクのセットです。つまり、region
複数のストリーミング ジョブの場合、タスクのデプロイを開始する前にすべてのタスクがフェッチされるのを待つ必要がなくなりましたslot
。代わりに、いずれかregion
が十分なタスクを取得したら、slot
デプロイできます。バッチ ジョブの場合、タスクは割り当てられずslot
、タスクは個別に展開されません。代わりに、region
十分なクエストが取得されるslot
と、そのクエストは他のすべてのクエストと同じ地域に展開されます。
77. Flink ジョブのライフサイクルにはどのような状態が含まれますか?
Flink クラスターでは、JobMaster がジョブのライフサイクル管理を担当し、特定の管理動作はスケジューラーと ExecutionGraph に実装されます。
ジョブの完全なライフサイクル状態遷移を次の図に示します。
-
ジョブは最初に作成された状態 (
created
) にあり、次に実行状態 (running
) に切り替わり、すべての作業が完了すると完了状態 (finished
) に切り替わります。 -
失敗した場合、ジョブはまず失敗状態 (
failing
) に切り替わり、実行中のすべてのタスクがキャンセルされます。すべてのノードが最終状態に達し、ジョブを再起動できない場合、状態は失敗 (failed
) に遷移します。 -
ジョブを再開できる場合、ジョブは再開状態 (
restarting
) になります。再起動が完了すると、作成された状態( )に変わりますcreated
。 -
ユーザーがジョブをキャンセルすると、キャンセル状態 (
cancelling
) になり、現在実行中のすべてのタスクがキャンセルされます。実行中のすべてのタスクが最終状態に達すると、ジョブはキャンセルされた状態 (canceled
) に移行します。
完了状態(finished
)、キャンセル状態(canceled
)、失敗状態(failed
) はグローバルな終了状態を表し、クリーンアップをトリガーしますが、一時停止状態(suspended
) はローカルな終了状態のみです。ジョブの実行は対応する JobManager で終了しますが、クラスターの別の JobManager が永続 HA ストレージからこのジョブを回復し、再起動できることを意味します。したがって、一時停止状態にあるジョブは完全にはクリーンアップされません。
78. タスクのジョブライフサイクルにはどのような状態が含まれますか?
TaskManager はタスクのライフサイクル管理を担当し、ステータスの変化をジョブマスターに通知し、ExecutionGraph で実行のステータス変化を追跡します (1 つのタスクに対して 1 つの実行)。
タスクのライフサイクルは次のとおりです: 合計8 88州。
ExecutionGraph の実行中、各並列タスクは作成 ( created
) から完了 ( finished
) または失敗 ( failed
) までのいくつかの段階を経ます。上の図は、状態とそれらの間の可能な遷移を示しています。タスクは複数回実行できます (フェイルオーバーなど)。各実行は ExecutionVertex の実行を追跡し、各 ExecutionVertex には現在の実行 ( current execution
) と先行実行 ( prior execution
) があります。
79. Flink のタスク スケジューリング プロセスについて説明してください。
タスクのスケジュール設定のフローチャートは次のとおりです。
(1) Flink がエグゼキュータを実行すると、プログラム コードに従って DAG データ フロー グラフ、つまりジョブグラフが自動的に生成されます。
(2) ActorSystem は Actor を作成し、JobManager の Actor にデータ フロー グラフを送信します。
(3) JobManager は、有効な TaskManager を取得できるように、TaskManager のハートビート メッセージを受信し続けます。
(4) ジョブマネージャーは、スケジューラーを通じてタスクマネージャー内のタスクをスケジュールし、実行します (Flink では、最小のスケジューリング単位はタスクであり、スレッドに相当します)。
(5) プログラムの実行中、タスクとタスク間のデータ送信が可能です。
- ジョブクライアント
- 主な役割はタスクを送信することであり、送信後はプロセスを終了するか、結果を返すことができます。
- ジョブ クライアントは Flink プログラム実行の内部部分ではありませんが、タスク実行の開始点です。
- ジョブ クライアントは、ユーザーのプログラム コードを受け入れ、データ ストリームを作成し、その後の実行のためにデータ ストリームをジョブマネージャーに送信する責任があります。実行が完了すると、ジョブ クライアントは結果をユーザーに返します。
- ジョブマネージャー
- 主な責任は、作業をスケジュールし、チェックポイントを実行するタスクを調整することです。
- クラスター内には少なくとも 1 つのマスターが必要であり、マスターはタスクのスケジュール設定、チェックポイントの調整、およびフォールト トレランスを担当します。
- 高可用性設定では複数のマスターが存在できますが、1 つはリーダーであり、他のマスターはスタンバイである必要があります。
- ジョブ マネージャーには
Actor System
、Scheduler
、 、CheckPoint
という 3 つの重要なコンポーネントが含まれています。 - ジョブマネージャーはクライアントからタスクを受け取ると、まず最適化された実行プランを生成し、次にそれをタスクマネージャーにスケジュールして実行します。
- タスクマネージャー
- 主な役割は、JobManager からタスクを受信し、タスクをデプロイして開始し、アップストリーム データを受信して処理することです。
- タスクマネージャーは、JVM 内の 1 つ以上のスレッドでタスクを実行するワーカー ノードです。
- TaskManager は作成の開始時にスロットを設定しており、各スロットはタスクを実行できます。
80. フリンクのタスクスロットとはどういう意味ですか?
各タスクマネージャーは、異なるスレッドで 1 つ以上のサブタスクを実行できる JVM プロセスです。worker
が受信できる数を制御するためtask
。worker
によってtask slot
制御されます(1 つはworker
少なくとも 1 つありますtask slot
)。それぞれは、task slot
タスクマネージャーが所有するリソースの固定サイズのサブセットを表します。
一般に、割り当てるスロットの数は、8 8などの CPU のコアの数と同じです。8コアの場合は8 88スロット。Flink はプロセスのメモリを複数に分割しますslot
。写真には2 22 つのタスクマネージャー、各タスクマネージャーには3 33、slot
それぞれ1/3 1/3slot
を占めるメモリの1/3 。
メモリが異なる に分割されると、slot
次の利点が得られます。
- TaskManager が同時に実行できる制御可能なタスクは最大3 3 個です
slot
の数を超えることはできないため、 3 。タスク スロットの役割は、タスクの管理メモリを分離することであり、CPU の分離は発生しません。 slot
排他的なメモリ空間があるため、複数の異なるジョブを 1 つのタスクマネージャーで実行でき、ジョブは影響を受けません。
概要:task slot
の数は、task
並列実行できるタスクマネージャーの数を表します。
81. Flink スロット共有とは何を意味しますか?
デフォルトでは、Flink は、サブタスクが異なるタスクのサブタスクであっても、同じジョブからのものである限り、スロットを共有することを許可します。その結果、ジョブのパイプライン全体を保持できるスロットが作成されます。スロット共有を許可すると、次のような大きな利点があります。
-
ジョブ内の最高の並列処理度 (
parallelism
)を計算するだけですtask slot
。これを満たしていれば他の仕事も満たせます。 -
リソースの分配がより公平になります。自由時間が増えれば、
slot
より多くのタスクを割り当てることができます。図にタスク スロットの共有がない場合、負荷の低いソース/マップはsubtask
多くのリソースを占有し、負荷の高いウィンドウではsubtask
リソースが不足します。 -
タスク スロットの共有により、基本並列処理 ( ) を2 から 2
base parallelism
に変更できます。2 を6 6にレイズ6.スロット付きリソースの使用率が向上しました。同時に、subtask
割り当てslot
スキームがより公平であることも保証できます。