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

タイムリーなストリーム処理 #

はじめに #

タイムリーなストリーム処理は、ステートフルストリーム処理の拡張で、時間が計算においてなんらかの役割を果たします。とりわけ、時系列分析を行う場合や、特定の期間に基づいて集計を行う場合(通常はウィンドウと呼ばれる)、イベントが発生した時刻が重要なイベント処理を行う場合です。

次のセクションでは、タイムリーな Flink アプリケーションを使う際に考慮すべきいくつかのトピックを取り上げます。

Back to top

時間の概念: イベント時間と処理時間 #

ストリーミングプログラムの中で時間を参照する場合(例えばウィンドウを定義するため)、時間の異なる表記を指示することができます。

• 処理時間: 処理時間は、それそれのオペレーションを実行しているマシンのシステム時間を指します。

  ストリーミングプログラムが処理時間で実行されう場合、全ての時間ベースのオペレーション(ウィンドウなど)は、それぞれのオペレータを実行するマシンのシステム時間を使います。1時間ごとの処理時間ウィンドウには、システムクロックが1時間を示した時間の間に特定のオペレータに到着した全てのレコードが含まれるでしょう。例えば、もしアプリケーションが 9:15am に実行を開始した場合、最初の1時間の処理時間ウィンドウは 9:15am と 10:00am との間に処理されるイベントを含み、次のウィンドウは 10:00am と 11:00am との間に処理されるイベントを含むでしょう。

  処理時間はもっとも単純な時間の概念で、ストリームとマシン間の調整を必要としません。最高のパフォーマンスと最低の遅延を提供します。However, in distributed and asynchronous environments processing time does not provide determinism, because it is susceptible to the speed at which records arrive in the system (for example from the message queue), to the speed at which the records flow between operators inside the system, and to outages (scheduled, or otherwise).

• イベント時間: イベント字あkンは、生成デバイス上で個々のイベントが発生した時間です。この時間は、レコードがFlinkに入る前に一般的にレコード内に埋め込まれ、タイムスタンプはそれぞれのレコードから取り出せます。イベント時間では、時間の進行は壁時計ではなくデータに依存します。イベント時間のプログラムは、イベント時間の進捗を知らせる仕組みであるイベント時間のウォーターマークを生成する方法を指定する必要があります。このウォーターマークの仕組みは、あとのセクションの以下で説明します。

  完全な世界においては、いつイベントが到着したかあるいはそれらの順番に関係無しに、イベント時間の処理は完全に一貫性と決定論的な結果を与えるでしょう。しかし、イベントが(タイムスタンプによって)順番に到着することが知られていない場合は、イベント時間処理は順番になっていないイベントを待つ間いくらかのレイテンシを招きます。有限な時間の間を待つことしかできないため、イベント時間のアプリケーションがどれだけ決定論的であるかに制限を与えます。

  データの全てが到着したと仮定すると、イベント時間のオペレーションは期待した通りに振る舞い、順番になっていない、あるいは遅れているイベントと連携、あるいは過去のデータを処理する場合でも、正しく一貫性のある結果を生成するでしょう。例えば、1時間ごとのイベント時間ウィンドウは、レコードが到着した順番、あるいはそれらが処理された時間に関係なく、その時間に分類されるイベント タイムスタンプを運ぶ全てのレコードを含むでしょう。(詳細な情報は、遅延を参照してください。)

  イベント時間のプログラムがリアルタイムでライブのデータを処理している時は、それらが直ちに進むことを保証できるようになんらかの 処理時間を使うだろう事に注意してください。

Back to top

イベント時間とウォーターマーク #

注意: Flink はデータフローモデルの多くの手法を実装しています。イベント時間とウォーターマークについては、以下の記事をご覧ください

• Streaming 101 by Tyler Akidau
• データフローモデルに関する論文

イベント時間をサポートするストリームプロセッサはイベント時間の進捗を計測する方法が必要です。例えば、1時間ごとのウィンドウを構築するウィンドウオペレータは、イベント時間が1時間の終わりを超えて過ぎた時に通知されて、オペレータが進捗中のウィンドウを閉じることができるようにする必要があります。

イベント時間は処理時間(壁時計で測定)とは独立して進行します。 clocks). 例えば、1つのプログラムで現在のオペレータのイベント時間が、同じスピードで両方とも処理しているにも関わらず、(イベントの受信の遅延が原因で)処理時間よりｗずかに遅れている可能性があります。一方で、他のストリーミングプログラムはKafkaトピック(あるいは他のメッセージキュー)内に既にバッファされた何らかの歴史的なデータを使って早送りすることで、数週間のイベント時間を通じて処理の数秒だけで進むかもしれません。

Flinkでイベント時間の進捗を測定する仕組みは、ウォーターマークです。 ウォーターマークはデータストリームの一部として流れ、タイムスタンプ t を運びます。Watermark(t) は、イベント時刻がストリームのの時刻 t に到着したことを宣言します。これは、タイムスタンプ t’ <= t (つまりタイムスタンプがウォーターマークより古いか等しいイベント)を持つストリームの要素がこれ以上存在しないことを意味します。

以下の図は、(論理)タイムスタンプとインラインで流れるウォーターマークを含むイベントのストリームを示しています。この例では、イベントは(タイムスタンプに関して)順番に並んでいて、ウォーターマークは単純にストリーム内の定期的なマーカーであることを意味します。

ウォーターマークは、以下に示すように、イベントがタイムスタンプで順番付けされていない、out-of-order ストリームにとって非常に重要です。一般に、ウォーターマークは、ストリーム内のその時点までに、特定のタイムスタンプまでのすべてのイベントが到着しているはずであるという宣言です。一旦ウォーターマークがオペレータに到達すると、オペレータは内部的なイベント時間の時計をウォーターマークの値まで進めることができます。

イベント時間は、新しく作成されたストリーム要素 (または複数の要素) によって、それらの要素を生成したイベント、またはそれらの要素の作成をトリガーしたウォーターマークから継承されることに注意してください。

並行ストリーム内のウォーターマーク #

ウォーターマークはソース関数で、あるいはすぐ後で、生成されます。ソース関数の各並列サブタスクは、通常ウォーターマークを個別に生成します。 これらのウォーターマークは特定の並行ソースでのイベント時間を定義します。

ウォーターマークがストリーミングプログラム内を流れるにつれて、ウォーターマークが到着したオペレータのイベント時間を進めます。オペレータがイベント時間を進めるたびに、後続のオペレータのために新しいウォーターマークを生成します。

幾つかのオペレータは複数の入力ストリームを消費します; 結合、あるいは例えば keyBy(…) または partition(…) 関数に続くオペレータ。そのようなオペレータの現在のイベント時間はその入力ストリームのイベント時間の最小値です。 入力ストリームはそれらのイベント時間を更新するため、オペレータも更新します。

以下の図は、並列ストリームを流れるイベントとウォーターマーク、およびイベント時間を追跡するオペレーターの例を示しています。

遅延 #

特定の要素がウォーターマークの条件に違反することがあります。つまり、Watermark(t) が発生した後でもタイムスタンプ t’ <= t を持つさらに多くの要素が発生することを意味します。実際、現実世界の多くの設定では、特定の要素が恣意的に遅延する可能性があり、特定のイベントのタイムスアンプの全ての要素が発生する時間を指定することは不可能です。 さらに、遅延を制限できる場合でも、ウォーターマークを遅らせすぎるとイベント時間ウィンドウの評価に過度の遅延が生じるため、多くの場合望ましくありません。

このため、ストリーミングプログラムは、明示的に何らかの late 要素を期待する場合があります。 遅延要素は、システムのイベントクロック(ウォーターマークによって通知される)が既に遅延要素のタイムスタンプ時間を過ぎた後に到着する要素です。イベント時間ウィンドウで遅延要素を操作する方法の詳細については、Allowed Latenessを参照してください。

ウィンドウ #

イベントの集約(例えば、counts, sums)は、ストリームではバッチと異なる動作をします。例えば、ストリームは一般に無限(無制限)であるため、ストリーム内の全ての要素をカウントすることは不可能です。その代わりに、ストリームの集計(counts, sumsなど)は、例えば、*“count over the last 5 minutes”または“sum of the last 100 elements”*のようなwindowsによってスコープが設定されます。

ウィンドウは、時間駆動 (例えば、30秒ごと)またはデータ駆動(例えば、100要素ごと)にすることができます。一般的に、タンブリングウィンドウ (オーバーラップ無し)、スライディングウィンドウ (オーバーラップあり)、セッションウィンドウ (非アクティブなギャップによって中断されます)のような、様々なタイプのウィンドウが区別されます。

ウィンドウの別の例については、このblog postを参照するか、DataStream APIのwindow documentationをご覧ください。

Back to top