FLINK意義ストリーム処理アーキテクチャは非常に重要であり、カフカは、持続性のメッセージ、および処理データ、および完了するために、FLINKを頼らなければならない時を旅するにも能力を作る能力を持っています。
では、将来Streaming-ビッグデータ記事では、ストリーミング、正確性、時間的推論ツールのための最も重要な二つのことを知っています。FLINKは、両方のための非常に良いサポートしています。
正しさのためFLINK保証
私たちがまだ到着してイベントを扱っているような連続イベントストリームデータについては、今のラインオフ高レイテンシは、計算の正確性を保証取られ、だけでなく、低レイテンシーを犠牲にして一般的な方法によって影響を受けたデータの正しさにつながる可能性があります。
FLINKは不自然として生成計算ウィンドウデータの精度の定義に反映しました。たとえば、クリックストリームイベント、トラック訪問3人のユーザA、B、Cのを。私たちは、データがセッション・ウィンドウでギャップを、持っている可能性があることがわかります。
マイクロバッチモード（点線ウィンドウが計算され、実線の会話ウィンドウを）SparkStreaming、ウィンドウが計算され、セッション・ウィンドウとの合意を達成することは困難です。FLINKは、ストリーム処理APIを使用するには、柔軟なウィンドウ計算を定義することができます。この値は、イベントを超えて考えられている場合たとえば、あなたは、値を設定することができます。
プロセスフローとは異なり、正確に有用であるFLINKイベント時間を使用することができます。
障害の発生の正確さを保証するために、コンピューティングの状態を追跡する必要があり、時間のほとんどは、現在開発者によって完了状態を保証することであるが、連続ストリーム処理コンピューティングは終わりではありません。FLINKチェックポイントは、この問題を解決するための技術を-checkpoint。各検査点において、システムは、障害が発生したときに正確にリセットするために、中間記録状態を計算します。このアプローチは、システムがフォールトトレランスにする低コストの方法を持つことができます - すべてが正常である場合には、システム上のチェックポイントのメカニズムへの影響は非常に小さいです。
計算をトレースする作業を含め、提供し、また正確性を保証するもので運用・保守および開発作業を、簡素化し、ストリーミングやバッチ処理を実現するために同じ技術を使用するFLINKインターフェース。
処理のためのFLINK時間
それは時間とバッチ処理の最大の違いの流れに対処することです。
バッチ処理アーキテクチャを使用して
このアーキテクチャでは、我々は、HDFSの存在のような規則的な間隔でデータを格納することができ、タイミングはスケジューラによって実行し、結果を出力します。
このアーキテクチャは可能であるが、いくつかの問題があります。
あまりにも多くの別々の部分。イベントデータの数、あまりにも多くのシステム・アーキテクチャの使用を計算するために。各システムは、学習コストや管理コスト、またバグが存在することがあります。
処理時間は明らかではありません。あなたは30分ごとにカウントするとします。DevOpsチームの問題は、ビジネスニーズと混同しているように、この変更は、ワークフローのスケジューリングロジック（いないアプリケーションのコード・ロジック）を必要とします。
警告。毎時間のカウントと仮定に加えて、だけでなく、可能な限り早期に警告を数える（例えばオーバー10回のアラームイベントの数として）を受信する必要があります。これを行うには、メッセージ・フローをキャプチャするために、定期的にバッチジョブのうち、導入嵐を実行することができます。時速正確なカウントを提供するために、リアルタイムでのおおよその数、バッチジョブを襲撃。しかし、この方法では、我々は、システムのアーキテクチャを高め、新しいプログラミングモデルに関連付けられています。アーキテクチャの上にラムダアーキテクチャと呼ばれます。
- イベントの順序の流れのうち。現実の世界では、イベントの流れのほとんどは順不同であり、そのため、データセンターに記録されたイベントの実際の配列は同じではありません。これは、イベントの前群のこの部分が誤って現在のバッチとして分類することができることを意味します。バッチアーキテクチャは、この問題を解決することは困難である、ほとんどの人はそれを無視することを選びました。
- バッチジョブの境界が明確ではありません。時間のスプリットポイントは前のグループに分類することができる前と後のイベントは、それはまた、現在のバッチに含まれていてもよいです。
ストリーム処理を使用します
まず、メッセージングシステムメッセージセットがカフカ書き込まれ、イベントストリームは、メッセージングシステム、及び単一FLINKジョブ処理によって提供されます。
タスクのグループに時間単位でイベントストリームは、このロジックは、完全にアプリケーションロジックFLINKプログラムに埋め込まれています。警告は、同じプログラムによって生成され、注文イベントのうち、FLINK自身によって処理されます。生成されたパケットデータに基づいて一定期間からのパケットは、単にFLINKにプログラムウィンドウの定義を変更することができます。アプリケーションコードは変更がある場合に加えて、単純にカフカのテーマを再生するには、アプリケーションを再生することができます。かなり、学び管理し、システムコードを記述する必要性を減らすことができ、ストリーム処理アーキテクチャを使用します。FLINKサンプルアプリケーションコード：
DataStream<LogEvent> stream = env
// 通过Kafka生成数据流
.addSource(new FlinkKafkaConsumer(...))
// 分组
.keyBy("country")
// 将时间窗口设为60分钟
.timeWindow(Time.minutes(60))
// 针对每个时间窗口进行操作
.apply(new CountPerWindowFunction());ストリーム処理では、時間の二つの概念は主にあります。
イベント時間、実際のイベントである時間。より正確には、すべてのイベントは、それに関連付けられたタイムスタンプを持っており、タイムスタンプは、データ・レコードの一部です。
処理されている処理時間、タイムイベント。時間は、実際に測定された時間イベント処理の機械処理です。
例えば、「スターウォーズ」の映画、と。まず、（これはイベント時である）直列4、5、6は、それらが（これは処理時間である）1977年、1980年と1983年にリリースされた3枚の作品をリリースしました。処理時間に対応するイベント時間によって解放最初のセクション1,2,3,7、後に1999年、2002年、2005年と2015年でした。このように、一連のイベントの流れは混沌とすることができる（ただし、一般的ではない混乱時系列）
そして、通常、第3の時間概念、摂取のすなわち時間、また、エントリの時間と呼ばれます。これは、ストリーム処理にイベントの時間枠を指します。最初、それは時間だ見たリアルタイムのイベントデータのストリームプロセッサの欠如は、プロセッサをストリーミングするタイムスタンプを伴うことになる（この操作は、ソース機能によって完成され、それはプログラムの最初の加工点です）。
イベントの時間と処理時間のずれが（存在するように現実の世界では、多くの要因（接続が一時的に中断されるなどの、ネットワーク遅延の異なる原因が、分散システムクロックが同期していないが、データレートは、急激に物理的な理由、または不運の増加しました）そのイベントの時間偏差）。時系列と注文処理時間のイベントは、イベントが注文フロープロセッサから到着することを意味し、通常は矛盾しています。
FLINK精度とセマンティックイベント選択時、処理時間、または摂取定義されたウィンドウの時間の所望の要件にユーザーを可能にします。
窓
時間ウィンドウは、最も簡単で便利なウィンドウです。これは、転がりと滑りサポートしています。
例えば、1分、最後の1分が収集されたウィンドウ値を転がり、そして1分の最後に合計を出力します。
1分、最後の1分の窓の合計値を移動するが、それぞれの半分分の時間をスライドし、その結果を出力します。
次のようにFLINKでは、1分ローリング・ウィンドウが定義されています。
stream.timeWindow(Time.minutes(1))1分以下のスライディングウインドウをスライディングハーフ分（すなわち、30秒）のそれぞれに示されているように。
stream.timeWindow(Time.minutes(1), Time.seconds(30))FLINKは、カウントウィンドウと呼ばれるもう一つの一般的なウィンドウをサポートしています。カウントウィンドウを使用している場合、パケットは、タイムスタンプに基づいて、もはやありませんが、要素の数。
スライディングウィンドウカウントウィンドウは、4つの要素として解釈され、その都度2つのスライド素子であってもよいです。ローリングと以下のように定義されているカウントウィンドウをスライディング。
stream.countWindow(4)
stream.countWindow(4, 2)カウントウィンドウは便利ですが、厳密な時間窓を定義するので、注意して、それを使用することをお勧めしますが。時間が停止しない、との時間ウィンドウは、常に「閉」になります。しかし、ウィンドウをカウントするという点で、また、無駄なメモリウィンドウによって占め、100として定義される要素の数、及び100に到達しないように対応するキー要素は、ウィンドウが閉じたことはないと仮定します。
別の有用なウィンドウFLINKサポートは、会話ウィンドウです。セッションウィンドウには、セッションが終了したと考えてどのくらいの時間を待つしたいタイムアウトで設定します。
例としては、次のとおりです：
stream.window(SessionWindows.withGap(Time.minutes(5))トリガー
ウィンドウに加えて、FLINKはまた、トリガ機構を提供します。重合の内容及び結果をユーザに戻ったときトリガ制御結果は、すなわち、時間窓を生成しました。各ウィンドウには、デフォルトのトリガーを持っています。例えば、イベントの時間を利用して時間ウィンドウは、透かしを受け取ると発生します。ユーザーの場合、透かしの受信時に完全に生成することに加えて、正確な結果は、カスタム・トリガーを実装することができます。
戻る時間で
中核能力ストリーム処理アーキテクチャは、時間の機構を後戻りされています。データストリームは、現在の時刻までのプロセスまでのハンドラを再起動して、過去の時間に戻って落ちたことを意味します。カフカはこの機能をサポートしています。
リアルタイムストリーム処理は、最新のデータ（すなわち、図「現在の時刻」のデータ）の過程で常にある、歴史は過去からのストリーミングを開始し、現在までに処理することができます。ストリームプロセッサは、データ・フローは、データの同じセットで同じプログラムを「巻き戻し」と再実行することを意味イベントの時間を、サポートしている、あなたは同じ結果を得ます。
透かし
FLINK時間は透かしてイベントを推進しています。透かしは、従来の記録、時間内の特定のポイントは、透かしを通過しなければならない計算プログラムのストリームに埋め込まれています。ウィンドウには、すべてのタイムスタンプに達している以下のイベントの時と同じであるので、表示され記録された時間よりも早く存在しません知っている透かしを受け取ります。この場合、ウィンドウが計算され、安全な結果（和）を与えることができます。ウォーターマーク時間イベントは、処理時間とは何の関係もありません。（処理時間の面での観点から、「遅」）と後期透かしは、結果の有効性には影響を与えませんが、結果のみの領収書の速度に影響します。
ウォーターマークは、通常、それぞれの分野のいくつかの知識を持っている必要があり、アプリケーション開発者によって生成されます。パーフェクトウォーターマークは間違っていることはできません。イベントの時に透かしを入れる未満のタイムスタンプが再び発生しません。
透かしが遅長すぎるため、速度は結果が非常に遅くなります受け取ることができる場合は、解決策は、ウォーターマーク（FLINKを達成することができる）に到達する前に、出力結果を近似することです。透かしがあまりにも早く到着した場合は、誤った結果を受け取ることがありますが、FLINK後半のデータ処理機構は、この問題を解決することができます。
関連記事：
ビッグデータStreaming-の未来
大規模なデータ処理礎石-Googleデータフローのリアルタイム計算
将来のデータアーキテクチャ - ストリーム処理アーキテクチャに
FLINKは、処理のために多くの時間、よりリアルタイムに計算され、FLINK、カフカやその他の関連技術ボーエン、次のように算出したリアルタイムストリーミングへようこそ注意：
