1. 概念
2. 分散ランタイム

分散ランタイム環境

• タスクとオペレータのチェーン
• ジョブ マネージャー、タスク マネージャー、 クライアント
• タスクスロットとリソース
• バックエンドの状態
• セーブポイント

タスクとオペレータのチェーン

分散実行について、Flinkはオペレータのサブタスクをタスクに繋ぎ込みます。各タスクは1つのスレッドによって実行されます。オペレータをタスクに繋ぎ込むことは、最適化に便利です: スレッドからスレッドへの移譲とバッファリングを減らし、レイテンシを減らす一方で全体のスループットを増加させます。繋ぎ込みの挙動はAPIで設定することができます。

以下の図のデータフローの例は5つのサブタスク、したがって5つの平行スレッドで実行されます。

上に戻る

ジョブ マネージャー、タスク マネージャー、 クライアント

Flinkのランタイムは二つの種類の処理から成ります。

• ジョブマネージャ (マスターとも呼ばれます) は分散実行を調整します。それらはタスクのスケジュール、チェックポイントの調整、障害時の再開の調整などを行います。

  常に少なくとも1つのジョブマネージャがあります。高可用性セットアップは複数のジョブマネージャを持つでしょう。そのうちの一つはleaderで、その他はstandbyです。

• タスクマネージャ (ワーカーとも呼ばれます) はデータフローのタスク (あるいはもっと明確にはサブタスク)を実行し、バッファしてデータストリームを交換します。

  常に少なくとも1つのタスクマネージャがあるべきです。

ジョブマネージャとタスクマネージャは様々な方法で開始することができます: 直接マシーン上で、コンテナを使って、あるいはYARNのようなリソースフレームワークを使って。タスクマネージャはジョブマネージャに接続し、それら自身を利用可能だと宣言し、作業を割り当てられます。

クライアント はランタイムおよびプログラムの実行の一部ではありませんが、データフローを準備しジョブマネージャに送信します。そのあとで、クライアントは切断、あるいは進捗レポートを受信するために接続したままでいることができます。クライアントは実行を開始するJava/Scalaのどちらの一部として実行するか、コマンドライン処理 ./bin/flink run ...の中で実行します。

上に戻る

タスクスロットとリソース

各ワーカー (TaskManager) はJVM プロセスで、個々のスレッドで1つ以上のサブタスクを実行するかもしれません。どれだけの数のタスクをワーカープロセスが受け付けるかを制御するために、ワーカーはタスク スロット (少なくとも1つ)と呼ばれるものを持ちます。

各タスク スロット はタスクマネージャーのリソースの固定のサブセットを表します。3つのスロットを持つTaskManagerは、管理しているメモリの1/3を各スロットに捧げるでしょう。リソースをスロットすることはサブタスクが管理されたメモリを他のジョブからのサブタスクと競い合うことを意味しますが、その代わりにある程度の予約された管理されたメモリを持ちます。CPUの分離はここでは起こりません; スロットは現在のところタスクの管理しているメモリを分割するだけであることに注意してください。

タスクスロットの数を調整することで、ユーザはサブタスクがお互いに隔離される方法を定義することができます。タスクマネージャーごとに1つのスロットを持つことは、各タスクグループが別個のJM内で実行することを意味します。(例えば、別個のコンテナ内で開始することができます)。複数のスロットを持つことは、多くのサブタスクが同じJVMを共有することを意味します。同じJVM内のタスクは(マルチプレクサを使って)TCP接続とハートビートメッセージを共有することを意味します。それらはデータセットとデータ構造も共有するかもしれません。したがってタスクあたりのオーバーヘッドを減らします。

デフォルトで、サブタスクが異なるタスクの部分集合の場合でも同じジョブからのものである場合、Flinkを使ってサブタスクがスロットを共有することができます。結果として1つのスロットがジョブのパイプライン全体を持つかもしれません。このスロットの共有 を認めることには、二つの主要な利益があります:

• ジョブ内で使われる最も高い並行度として、Flinkクラスタはタスクスロットと完全に同じ数を必要とします。プログラムが全体でどれだけの数の(異なる並行度の)タスクを含むかを計算する必要はありません。

• より良いリソースの利用をすることが容易です。Without slot sharing, the non-intensive source/map() subtasks would block as many resources as the resource intensive window subtasks. With slot sharing, increasing the base parallelism in our example from two to six yields full utilization of the slotted resources, while making sure that the heavy subtasks are fairly distributed among the TaskManagers.

APIは望ましくないスロットの共有を防ぐために使うことができるリソース グループ の仕組みも含みます。

経験則で、タスクスロットの良いデフォルト値はCPUのコア数です。ハイパースレッディングを使って、各スロットは2つ以上のハードウェアスレッドのコンテキストを取ります。

上に戻る

バックエンドの状態

キー/値 インデックスが格納されている正確なデータ構造は、選択された状態のバックエンドに依存します。ある状態バックエンドはインメモリのハッシュマップ内にデータを格納し、またある状態バックエンドはキー/値 ストアとしてRocksDBを使います。状態を保持するデータ構造の定義に加えて、状態バックエンドはキー/値 状態のある時点のスナップショットを取り、スナップショットをチェックポイントの一部として格納するロジックも実装します。

上に戻る

セーブポイント

データストリーム APIの中で書かれたプログラムはセーブポイントから実行を再開することができます。セーブポイントにより状態の喪失無しにプログラムおよびFlinkクラスタの両方の更新をすることができます。

セーブポイントは、プログラムのスナップショットを取り、それを状態バックエンドに書き出す、手動で引き起こされるチェックポイントです。このために通常のチェックポイントの仕組みを頼ります。実行中はプログラムは定期的にワーカーノード上でスナップショットされ、チェックポイントが生成されます。回復のためには、最後に完了したチェックポイントだけが必要で、古いチェックポイントは新しいものが完了するとすぐに安全に破棄することができます。

セーブポイントは、ユーザに引き起こされ、新しいチェックポイントが完了した時に自動的に期限切れにならない点を除いて、これらの定期的なチェックポイントに似ています。

上に戻る