This documentation is for an unreleased version of Apache Flink. We recommend you use the latest stable version.

用語 #

チェックポイントストレージ #

State Backendがチェックポイント中にスナップショットを保存する場所(JobManagerまたはファイルシステムのJava Heap)。

Flink アプリケーション クラスタ #

Flink アプリケーションクラスタは、1つの FlinkApplication から Flink ジョブだけを実行するFlink クラスタです。Flink クラスタのライフタイムは、Flink アプリケーションのライフタイムに制限されます。

Flink ジョブクラスタ #

Flink ジョブクラスタは、単一の Flink ジョブのみを実行する専用のFlink クラスタです。Flink クラスタのライフタイムは、Flink ジョブのライフタイムに束縛されます。 この配備モードは Flink 1.15 から非推奨になりました。

Flink クラスタ #

(通常)1つの JobManagerと1つ以上のFlink TaskManager プロセスで構成される分散システム。

イベント #

イベントは、アプリケーションによってモデル化されたドメインの状態の変化に関する報告です。イベントは、ストリームまたはバッチ処理アプリケーションの入力および/または出力です。 イベントは特別な種類のrecordsです。

ExecutionGraph #

Physical Graph を参照してください。

関数 #

関数はユーザによって実装され、Flink プログラムのアプリケーションロジックをカプセル化します。ほとんどの関数は対応するOperatorによってラップされています。

インスタンス #

instance という用語は、実行時に特定の型(通常はOperatorまたはFunction)の特定のインスタンスを説明するために使われます。Apache Flink は主に Java で記述されているため、これは Java のInstanceまたはObjectに対応します。Apache Flink の文脈では、parallel instance という用語も、並列で実行中の同じOperatorまたはFunctionの型の複数のインスタンスを強調するためによく使われます。

Flink アプリケーション #

Flink アプリケーションは、main()メソッド(またはその他の手段)から1つ以上のFlink Jobsを送信する Java アプリケーションです。ジョブの送信は通常、実行環境でexecute()を呼び出すことで行われます。

アプリケーションのジョブは、長時間実行される Flink セッションクラスタ、専用の Flink アプリケーションクラスタ、Flink ジョブクラスタに送信できます。

Flinkジョブ #

Flink ジョブは、Flink アプリケーションでexecute()を呼び出すことで作成、送信されるlogical graph(データフローグラフとも呼ばれることが多い)の実行時の表現です。

JobGraph #

Logical Graphを参照してください

Flink ジョブマネージャ #

JobManager はFlink クラスタのオーケストレーターです。3つの異なるコンポーネントが含まれます: Flink Resource Manager、Flink Dispatcher、実行中のFlink ジョブごとに1つのFlink JobMaster です。

Flink JobMaster #

JobMasters はJobManagerで実行されるコンポーネントです。JobMaster は単一のジョブのTasksの実行を監督する責任があります。

JobResultStore #

JobResultStore は、グローバルに終了した(つまり、完了、中止、失敗)ジョブの結果をファイルシステムに保持する Flink コンポーネントであり、終了したジョブよりも結果を存続できるようします。その後、これらの結果は、Flink によってジョブが高可用性クラスタでリカバリする対象になるかを決定するために使われます。

論理グラフ #

論理グラフは、ノードがOperatorsで、エッジが operator の入出力関係を定義し、データストリームまたはデータセットに対応する、有向グラフです。論理グラフはFlink アプリケーションからジョブを送信することで作成されます。

論理グラフはデータフローグラフとも呼ばれます。

管理状態 #

管理状態はフレームワークに登録されているアプリケーションの状態を示します。管理状態のために、Apache Flinkは徳に永続化と再スケールを処理します。

オペレータ #

論理グラフのノード。operator は特定の操作を実行します。これは通常 Function によって実行されます。ソースと真紅は、データの取り込みとデータの出力のための特別な Operator です。

オペレータ チェーン #

オペレータチェーンは、再パーティションが行われない2つ以上の連続する Operators で構成されます。同じオペレータチェーン内のオペレータは、シリアル化やFlinkのネットワークスタックを経由せずに、レコードを直接相互に転送します。

パーティション #

パーティションはデータストリームまたはデータセット全体の独立したサブセットです。データストリームまたはデータセットは、各recordを1つ以上のパーティションに割り当てることで、パーティションに分割されます。 データストリームまたはデータセットのパーティションは、実行時にTasks によって消費されます。データストリームまたはデータセットの分割方法を変更する変換は、多くの場合、再分割と呼ばれます。 repartitioning.

物理グラフ #

物理グラフは、分散ランタイムで実行できるように論理グラフを変換した結果です。ノードはタスク で、辺は入力/出力関係、データストリームあるいはデータセットの パーティションを示します。

レコード #

レコードはデータセットあるいはデータストリームの構成要素です。Operators と Functions は入力としてレコードを受け取り、出力としてレコードを出力します。

(ランタイム) 実行モード #

DataStream API プログラムは、BATCH または STREAMING の2つの実行モードのうちのいずれかで実行できます。詳細は、実行モードを参照してください。

Flink セッション クラスタ #

実行のために複数の Flink ジョブを受け付ける長時間実行中のFlink クラスタ。このFlinkクラスタの生存期間はどのFlinkジョブの生存期間にも束縛されていません。 以前は、Flinkセッションクラスタは、セッション モードのFlinkクラスタとしても知られていました。Flink アプリケーションクラスタと比べてみてください。

状態バックエンド #

ストリーム処理プログラムの場合、Flink ジョブの状態バックエンドによって、そのstateを各 TaskManager (TaskManagerまたは(組み込み)RocksDBの Java ヒープ)にどのように保存されるかが決定されます。

サブ タスク #

サブタスクはデータストリームのパーティションの処理に責任があるタスクです。“Sub-Task” という用語は、同じ Operator または Operator Chain に複数の並列タスクが存在することを強調しています。

テーブルプログラム #

Flink のリレーショナル API (Table API または SQL) で宣言んされたパイプラインの総称。

タスク #

物理グラフのノード。タスクは作業の基本単位で、Flinkのランタイムによって実行されます。タスクは、Operator または オペレータチェーンの確実に1つの並列インスタンスをカプセル化します。

Flinkタスクマネージャ #

TaskManagers はFlink クラスタのワーカープロセスです。Tasks は、実行のために TaskManagers にスケジュールされます。これらは互いに通信して、後続のタスク間でデータを交換します。

変換 #

Transformation は1つ以上のデータストリームまたはデータセットに適用され、1つ以上の出力データストリームまたはデータセットが生成されます。transformation では、レコードごとにデータストリームまたはデータセットを変更する必要がありますが、パーティション分割を変更したり、集計を実行したりするだけの場合もあります。Operators と Functions は Flink の API の “physical” 部分ですが、Transformations は API の概念にすぎません。具体的には、ほとんどの transformations は特定の Operators によって実装されます。

UID #

Operator の一意の識別子。ユーザによって定義されるか、ジョブの構造から決定されます。Application が送信されると、UID ハッシュに変換されます。

UID ハッシュ #

実行時の Operator の一意の識別子。“Operator ID” または “Vertex ID” とも呼ばれ、UID から生成されます。 これは通常、ログ、REST API、メトリクスで公開されますが、最も重要なのは savepoints 内でどのように識別されるかです。