フリンク主成分分析

1.フリンクとは

Flinkは新世代の分散ストリーミングコンピューティングエンジンであり、大量のデータのリアルタイム処理とコンピューティングに使用されます。高速な障害耐性（各メッセージを1回だけ処理することをサポート）、ストリームバッチ統合、待ち時間が短く、順序が正しくないデータをサポートします。

Flinkの主なアプリケーションシナリオは次のとおりです。

• データ分析シナリオ：従来のバッチベースのコンピューティングプラットフォームと比較して、ストリーミングコンピューティングプラットフォームの最大の利点はリアルタイムパフォーマンスです。典型的なアプリケーションシナリオは、Taobaoのダブルイレブン大画面と、リアルタイム要件の高い一部のデータウォッチクラスです。
• イベント駆動型シナリオ：MetaQまたは他のメッセージキューと比較して、Flinkは、ユーザーの行動に基づいてリスク制御アラームをトリガーするなど、FlinkSqlまたは他のAPIに基づいていくつかの複雑な計算またはフィルタリング操作を実行できます。
• ETLシナリオ：これは理解しやすいです。従来のETLツールと比較して、点滅はより柔軟です。

2.設計原理

フォールトトレランス

バッチ処理プラットフォームと比較して、分散環境のストリーム処理プラットフォームにとって非常に重要な問題は、障害と回復の後に分散コンピューティングノードの最終的なコンピューティング結果が正しいことを確認する方法です。バッチモードでは、データが制限され、タスクを開始する前に計算する必要のあるすべてのデータを取得できます。ノードに障害が発生した場合、最悪の場合、データセットのみを再計算する必要がありますが、ストリーミングではモードの場合、データは継続的に生成され、制限がなく、ノードの回復に失敗した後、データを最初から再計算することはできません。

分散スナップショット

ネットワークサービスでは、スナップショットは一般的なフォールトトレラントメカニズムです。たとえば、RedisにはRDBに基づくデータ回復戦略があり、flinkの高速フォールトトレラントメカニズムもスナップショットに基づいて実装されています。スタンドアロン環境では、スナップショットの保存は比較的簡単です。特定の時点でタスク処理を一時停止し、現在の状態を維持するだけで済みます。ただし、分散システムでは、グローバルクロックがないため、すべてのコンピューティングノードのデータを同時に制御するために必要です。状態の保存は困難です（詳細については、付録：分散システムのクロックを参照してください）。これを実装する最も簡単な方法は、すべてのノードタスクを停止し、2PCと同様の方法で状態を保存し、最終的にそれらを均一に報告することですが、この方法でワールドを停止すると、計算の遅延が大幅に増加し、スループットが低下します。flinkの最終的な解決策は、Chandy-Lamportアルゴリズムに基づく改良された非同期バリアスナップショットアルゴリズムです。

チャンディ・ランポート

チャンディランポートアルゴリズムのコアアイデアは、分散システムを有向グラフに抽象化し、各分散ノードを頂点として、ノード間の通信チャネルを有向エッジ（入力チャネル、出力チャネル）として抽象化することです）、スナップショットが開始されると、各ノードは独自の状態と入力チャネルの状態を記録し、最終的にグローバルに一貫性のあるスナップショットを取得できます。これについては、以下の例で詳しく説明します。

下の図に示すように、分散システムには2つのノードP1とP2があり、2つのノードにはそれぞれX、Y、Zの3つの状態があります。メッセージはC12とC12の2つのチャネルを介して相互に送信できます。 C21。

まず、P1はスナップショット操作を開始し（同時に、グローバルスナップショット調整システムに報告できます）、最初に自身の状態[X1：0、Y1：0、Z1：0]を保存し、ダウンストリームの特殊メッセージマーカー。スナップショット操作も実行するようにダウンストリームノードに通知するために使用されます。同時に、P2はC21を介してP1にビジネスメッセージを送信します。

現時点では、P1がスナップショットを完了しているため、P2ノードがスナップショットを完了するまでメッセージ処理を実行できません。そうしないと、最終的に生成されるグローバルスナップショットに一貫性がなくなります。このとき、チャネルC21にすべてのメッセージを入力する必要があります。 （現在はM1のみ）スナップショットにも付加されると同時に、P2はP1からマーカー情報を受信し、スナップショット操作も行います。

最後に、P1はP2からマーカー情報を受け取ります。この時点で、両方のノードのスナップショットが保存されており（スナップショット操作の終了を通知するためにグローバルスナップショット調整システムに報告することもできます）、それを考慮することができますグローバルスナップショットが正常に生成されたこと。

全体的なアルゴリズムは比較的単純で理解しやすいことがわかりますが、このアルゴリズムでは、ネットワークの送信が秩序正しく信頼できるものである必要があり（TCPプロトコルを考えるのは簡単です）、メッセージとマーカーが送信された順序で他のノードに確実に届くようにするために必要です。

非同期バリアスナップショット

Chandy-Lamportの理解は複雑ではありませんが、2つの大きな問題があります。1.スナップショットを作成する場合、ノードは自身の状態を保存するだけでなく、入力チャネルにすべてのメッセージを保存する必要があります。これにより、スナップショットの量が比較的多くなり、スナップショットに基づいて復元する際の効率が低下します。システム全体の運用効率は、最も低速なコンピューティングノードに依存します。flinkはChandy-Lamportアルゴリズムに基づいて改善されており、そのコアアイデアは次のとおりです。

グローバルスナップショットを生成する必要がある場合は常に、ストリームのソースがバリアと呼ばれるIDを持つ特別なメッセージを挿入します。同時に、ソースはスナップショット生成操作が開始されたことをスナップショットコーディネーターに報告します。オフセット（フェイルバック後のストリーム再生に使用）、これらのバリアはデータストリーム全体を異なるデータセットに分割します。ダウンストリーム処理ノードがバリアを処理すると、スナップショットがローカルに保存され、さらにダウンストリームにブロードキャストされます。同じIDのバリアで、シンク（ストリームの出力端）もバリアを処理すると、コーディネーターはスナップショットが正常に生成されたことをコーディネーターに報告します。例を挙げて説明します。

図に示すように、アップストリームノードのスナップショットが正常に保存され、グラフのタスクノードに2つのデータストリームが出力されています。データストリーム1の処理速度が速いため、バリアNがタスクに到達します。ノードがデータストリーム1のメッセージの処理を一時的に停止し、メッセージをローカルバッファーに保存する必要がある場合、データストリーム2のバリアNもタスクに到達すると、タスクは最初にローカル状態を保存します（スナップショット）。バリアNをダウンストリームにブロードキャストします。この操作はバリアの調整と呼ばれます。最終シンク（出力）もバリアと調整された後、スナップショットコーディネーターはグローバルスナップショットの生成が成功したことを報告します。この時点で、グラフ内のタスクノードとアップストリームノードによって保存されたスナップショットを含む分散システム全体一貫性があります。つまり、バリアNの前のメッセージの処理ステータスのみが含まれます。障害が発生した場合、ステータスは次のようになります。各ノードのスナップショットを読み込み、ソースバリアNのオフセットでメッセージ再生を行うことができます。

非同期バリアスナップショットアルゴリズムは、余分なメッセージを保存する問題を解決しますが、Chandy-Lamportアルゴリズムと同様に、分散システム全体の計算効率は、システム全体で最も遅いノードによって制限されるため（バリアアライメントが必要）、Blink / Flinkバリアアライメントのクローズをサポートします。このモードでは、データストリーム1のバリアが最初に到着した場合、タスクはデータストリーム1の後続のデータを処理し続けますが、データストリーム2のバリアが到着すると、2回処理します。処理されたメッセージはスナップショットに一緒に保存されます。Blinkでは、スナップショットはチェックポイントと呼ばれます

バッチ処理とサポートの順不同

Flinkの時間とウィンドウ

Flinkでは、バッチデータ処理はバッチを制限付きストリームとして処理することで実現され（逆に、スパークはストリームをストリーム処理用のミニチュアバッチとして処理します）、変換に時間が使用されますストリームをバッチに変換するための重要なツールです。リアルタイムコンピューティングアプリケーションでの時間ベースのコンピューティングシナリオ。たとえば、過去5分間に購入者が毎分送信したメッセージの数をカウントします。瞬く間に、使用できる時間は3種類あります。

• イベント時間：イベントを生成したデバイスでイベントが発生する時間を示します。これは、Blinkコンピューティングプラットフォームに入るときに決定され、変更できず、Blinkに入る遅延、マシン時間、およびさまざまなコンピューティングのコンピューティング効率の影響を受けません。ノード。影響。イベントのシーケンスを正確に反映できます。
• 処理時間：各コンピューティングノードがイベントを処理する時間。各ノードの環境とパフォーマンスの違いにより、一定期間内のデータを計算する場合、計算結果は不安定になります。これは、Blinkでイベントが処理される順序を反映しています。
• 取り込み時間（イベントエントリイベント）：イベントがBlinkに入る時間を指し、ソースで生成されます。ProcessTimeと比較すると、コンピューティングノードの環境の影響を受けず、イベントがBlinkに入るときに決定されます。これは、イベントが点滅に入る順序を反映しています。

これらの3回に基づいて、Flinkは次の時間枠を提供します（当面はCountWindowは言うまでもありません）：

• 固定ウィンドウ：1日のデータの統計など、特定の時点で分割されたウィンドウ
• スライディングウィンドウ：ウィンドウサイズとスライディング期間によって定義されます。たとえば、過去5分間に購入者から送信されたメッセージの数は、上記のように1分ごとにカウントされます。
• セッションウィンドウ：タイムアウトで定義されたものなど、データのサブセットに対する一定期間のアクティビティをキャプチャします。たとえば、ユーザーがイベントなしで30分間ログインすると、タイムアウトになり、ログインごとに送信されるメッセージの数が計算されます。

順不同のデータの処理

前述のように、Blinkは3種類の時間をサポートします。そのうち、データの乱れの問題は、取り込み時間（イベントエントリ時間）とEventTime（イベントイベント）を計算に使用する場合、つまり、各ノードが存在するネットワーク環境が原因で発生する可能性があります。が配置されている、ハードウェアパフォーマンスなどの場合、イベントの実際の計算時間の順序は、実際に発生するか、点滅するイベントの順序と一致しない場合があります。

図に示す 順序が正しくないデータを処理する場合、ウィンドウベースの計算は間違っている可能性があります。その理由は、データフローが故障している場合、ノードは、タイムウィンドウの最後にタイムウィンドウに元々配置されていたデータがあるかどうかを確認できないためです。

図に示すように、Flinkは、イベント4の到着後に以前のイベントがあるかどうかを確認できません。この問題を解決するために、Flinkはウォーターマーク（水位メカニズム）を導入します。つまり、ウォーターマークはWhenFlinkを定義します。データは、以前のデータを待機する必要があるかどうか、および待機する必要がある時間の順序が正しくありません。上の図のシナリオを例にとると、ノードは、ウィンドウ時間が経過する前に一定期間待機することを選択できます。ウィンドウ計算をトリガーします。ある程度、以前のデータが処理されないようにします。もちろん、透かしの選択には注意が必要です。待機時間が長すぎると、以前のイベントを見逃す可能性は低くなりますが、キャッシュする必要のあるイベントと待機時間が長くなり、レイテンシが低下します。時間が短すぎると、以前のイベントを見逃す可能性が高くなる可能性があります。ただし、いずれの場合も、データの欠落は避けられません。ブリンクはウィンドウ計算後に発生するイベントを呼び出し、水位より前のイベントはレイトイベントと呼ばれます。レイトデータは個別に処理できます。ブリンクは次の3つの戦略を提供します。

• 閉じたウィンドウを再度アクティブにして、修正結果を再計算します
• シングルリード処理のためにレイトイベントを収集する
• 遅いイベントをドロップ

Flinkのデフォルトの処理方法は[遅延イベントを破棄]です

3.技術アーキテクチャ

Flinkの2つのコア原則を理解した後、最後に全体的な技術アーキテクチャを紹介します。フリンクは全体としてマスタースレーブモードに基づいており、JobManagerはマスターと同等であり、TaskManagerはスレーブです。コンピューティングタスク（StreamAPIまたは他のAPIに基づいて開発されたコード）は、クライアントがJobGraphに変換された後にJobManagerに送信されます（マルチノードチェーンはノードであり、異なるノード間のデータフローによって引き起こされるパフォーマンスの低下を軽減します） 、およびJobManagerはそれを実行可能実行グラフ（主にJobGraphを並列化）に変換し、最後に特定の実行タスクをタスクマネージャーにスケジュールして、リソースマネージャーを介して実行します。JobManagerは、checkPoint（つまり、前述のグローバルスナップショット）のトリガーも担当します。

もちろん、このモードのJobManagerにはシングルポイントの問題があります。Flinkは2つの高可用性モードを提供します。1つはスタンドアロンです。このモードでは、複数のJobManagerが同時に開始され、マスターが選択されます。 Zookeeper。JobManagerが発生した場合障害が発生した場合、新しいマスターが選出されます。2つ目は、JobMangerを開始し、障害が発生すると自動的に再起動するYarnベースのモードです。