第1章タイムセマンティクス
Flinkには、イベント時間、取り込み時間、処理時間の3つの時間セマンティクスが定義されています。
フロー計算プロセス全体で、これらはイベントが発生した時間、データが最初にFlinkに入った時間、およびデータがFlinkオペレーターによって処理された時間を表します。
イベント時間：イベントが発生した時間、実際にデータが生成された時間。データストリームが送信と計算のプロセスにどれだけの時間を費やしても、EventTimeは変更されず、いつ発生するかが決定されます。
取り込み時間：データがFlinkに入る最も早い時間、つまりデータがソースに到着する時間。取り込み時間は、内部オペレーターの計算やデータ送信効率の影響も受けません。
処理時間：データが各オペレーターに入力されるとき、オペレーターが配置されているマシンの現地時間。処理時間は、現在のオペレーターがいるマシンのシステムクロックにのみ依存します。
第2章タイムスタンプ
EventTimeモードでは、Flinkがソースから流入するすべてのデータにTimestampが含まれます。ここで、Timestampはイベントが発生した時刻を表します。もちろん、カスタムタイムスタンプにすることもできます。ただし、タイムスタンプの増分を確認する必要があります。
たとえば、ビジネスでは、ウィンドウ計算を使用して、特定の期間内のインシデントの数を計算する必要があります。過去2週間の各地域で確認されたケースの数を計算し、過去1時間の各モジュールの訪問数とユーザークリック数を計算します。ボリュームなど...これらはすべて、EventTImeモードでウィンドウ計算を行うためにTimestampを使用する必要があります。
Flinkでは、Timestampは8バイトの長さの値として定義されます。各オペレーターがデータを取得すると、デフォルトでミリ秒の精度でUnixタイムスタンプを使用してlong値を解析します。これは、1970-01-01 00：00：00.000からのミリ秒数です。もちろん、カスタムオペレータはタイムスタンプの解析方法を定義できます。
ただし、時間ベースのアプリケーションの場合、各コンピューティングユニットのコンピューティング機能が異なるため、ネットワーク伝送速度も異なり、今日のビッグデータシステムはすべて分散アーキテクチャです。これらのさまざまな理由により、データがソースおよび各コンピューティングユニットに到着するときにある程度の不確実性があります。これは時間の乱れの問題です。次に、Flinkがこのデータ障害の問題をどのように解決するかを見てみましょう：ウォーターマーク。
第3章ウォーターマーク
Flinkは、通常のデータと一緒にオペレーター間で送信されるデータ要素StreamElementであるWatermarkを定義します。本質的に長いタイプのタイムスタンプであり、グローバルな進捗指標です。
ウォーターマークは、ソースの場所で発行することも、ストリーミングの任意のオペレーターで生成して、トポロジー内のオペレーターを介して伝播することもできます。
FLinkストリームの計算プロセスでは、データの送信が遅れ、データの順序が乱れるため、ウィンドウの計算をいつトリガーする必要がありますか？別の言い方をすれば、ウィンドウによって計算されたすべてのデータがオペレーターに到達することを確認するために、どのくらい待つ必要があるかをどのように知ることができますか？
上の写真を見てみましょう。Flinkはデータストリームに散在するウォーターマークを使用します。ウォーターマークは、オペレーターにウィンドウ計算を実行するトリガーとなる遅延イベントがないことを確認します。実際、ウォーターマークの後、このウィンドウのデータは失われますか？上の図はすでにこの質問に答えています：あるかもしれません。ウォーターマークで定義された遅延が小さい場合、省略の可能性が高くなります。ウォーターマーク遅延で定義された遅延が大きいほど、省略の可能性は小さくなりますが、これはウィンドウトリガーの遅延が長くなることも意味します。
したがって、通常の状況では、ウォーターマークは、平衡値に到達するために、自身のビジネスに従って実際のテスト調整を実行する必要があります。場合によっては、計算の遅延を減らすために、ユーザーがウォーターマークによって除外されたデータを直接破棄したくない場合は、データをログに書き込んだり、以前の結果を修正するために使用したりできます。
最後にもう1つ、処理時間に基づくウィンドウ計算にはウォーターマークは必要ありません。