著者は紹介します
西安（チー・マウンテン）から秋、 2018はコアエンジンの開発FLINKに注力し、アリババのコンピューティングプラットフォーム部門をApacheの寄稿FLINK、中南大学、修士入社、主にFLINK州立＆チェックポイント関連の研究開発に従事。
我々はすべて知っているように、FLINKは現在、フォールトトレラントで、チェックポイント機構を使用して最も広く使用されている計算エンジン、の一つである[1]に、チェックポイントは、後で復元するための分散ストレージシステムにスナップショット・バックアップを述べるであろう。内部アリババでは、我々はHDFSを保存するために主に使用され、ジョブのクラスタで一定数に達した後、HDFSは大きな圧力が発生しますと、この論文では、実質的にHDFSの圧力を低下させるための方法を説明する - 小さなファイルをマージします。
背景
かかわらず、ときFsStateBackend、RocksDBStateBackendまたはNiagaraStateBackend、FLINKのチェックポイントの間に、TMは、分散ファイルシステム状態のスナップショットに書き込まれ、その後、ファイルハンドルJMを送信されます、JM完全なグローバルチェックポイントスナップショットストレージ、以下のように：
チェックポイントの合計額については、各チェックポイントデータ内のTMは、同じファイルに書き込まれ、及び[2] RocksDBStateBackend / NiagaraStateBackend増分チェックポイントのために、それがファイルに各SST分散システムを書き込まれますファイル内。作業大量の、大きな同時操作は、根底にあるHDFS上の非常に大きな圧力を形成する場合：1）以下に示すように）（応答時間に影響を与えるRPC RPC要求の多数; 2）ファイルの名前ノードの多数圧力のメモリたくさん。
FLINK ByteStreamStateHandleが文書[3]の少数の問題を解決しようとしていたでは、状態はTM側に小さなファイルの発生を回避するように、特定の閾値を分散ファイルによって書かれた統一JM、JMに直接送信され未満です。プログラムは、いくつかの制限があり、閾値が小さすぎる設定され、生成された多数の小さなファイルがあるでしょう。しかし、閾値が大きすぎる設定されている、それがOOMの大量のメモリ消費JMリスクにつながります。
小さなファイルの合併計画
上記の問題のために我々は解決策を提案 - 小さなファイルをマージします。
元の実装では、各SSTファイルはCheckpointOutputStream、各CheckpointOutputStream FSDataOutputStreamに対応する開き、分散ファイルにローカルファイルを書き込み、次に閉じFSDataOutputStreamは、StateHandleを生成します。下図のように：
ファイルサイズが予め設定された閾値に達するまで合成オープンFSDataOutputStream小さなファイルは、各ファイルは、最終的な複数のSST DFSファイルの部分を占め、他の言葉でSST複数のファイルを同一のDFSファイルに再利用され、再利用されます以下のようにStateHandleは、物理的なファイルを共有します：
次のセクションに入れ、我々は重要な考慮事項が含まれている、実装の詳細を説明します：
1）同時のチェックポイントをサポート
FLINKは、本質的に複数のファイルのプログラムは、我々はプログラムの正しさを確保するための仕組みを持っている必要がありますので、適切と考えるならば、データが文字列を書かれたり破損します、分散ストレージで同じファイルに書き込みます小さなファイルをマージ、同時チェックポイントをサポートしています2.1を参照して詳細に説明します。
2）誤って削除したファイルを防ぎます
私たちは、ファイルが誤って削除されていない、我々は2.2に記載されていることを確認する方法を、専用ファイルの参照カウントが削除するには、誤ってファイルを削除した可能性があるかどうかをゼロ裁判官に低下し、ファイルの使用を記録するために参照カウントを使用します。
3）空間的増幅を低減します
使用され、全体の分散ファイルを削除することはできませんので、より多くのスペースを取るだろう、小さなファイルをマージ使用した後、限りstatehandleファイルがあるとして、我々は、この問題に対する2.3溶液中で詳細に説明します。
4）例外処理
我々は2.4で例外や状況JM TMの異常を含む例外を処理する方法を説明します。
チェックポイントは、スナップ端子TMをキャンセルする方法、キャンセルまたは失敗した後に2.5を詳細に説明するスナップショットの終わり場合、TMがキャンセルされていない、マルチエンド実際のTMスナップショット比の正常な動作をもたらすであろう。
第3節合併計画の既存のプログラムの小さなファイルの互換性のSet述べ、最後に第5節では、我々は、本番環境で達成された結果を示し、第4節では、利点と小さなファイルの欠点は、プログラム記述をマージされます。
第二に、設計と実装
このセクションでは、詳細に小さなファイルの合併、ならびにこれらの点の設計の全体の内容を説明します。
ここでは、プロセス終了の約TMスナップショットを思い出します。
- TM整列エンド障壁
- TMスナップショット同期動作
- TMスナップショット、非同期操作
前記チェックポイント、同時に可能のチェックポイントファイルのアップロード複数アップロードするために、同じファイル、上記第三の工程において、分散ストレージ・システムへSSTアップロードファイル。
1、同時のチェックポイントをサポートしています
FLINKは、本質的に同時のチェックポイントをサポートしていますので、小さなファイルの合併計画はまた、同時のチェックポイントをサポートできるようにする必要があり、異なるSSTファイルを同時に分散ファイルに書き込む場合は、チェックポイントは、ファイルから復元することができませんでし従って、ファイルの内容に損傷を与えるだろう。
[4] 11937 FLINK-の提案では、チェックポイントの状態のそれぞれにファイルを書き込みます同じ文書をHDFS、異なるHDFSに書き込まれたチェックポイントファイルの異なる状態 - 他の言葉では、チェックポイントHDFSのファイル共有を横断していませんしたがって、複数のクライアントが同時に同じファイルに書き込む事態を回避することができます。
私たちは、フォローアップのクロスチェックポイントファイル共有プログラムを推進していきます、もちろん、チェックポイントファイル共有プログラム間で、並列チェックポイントは異なるHDFSファイルに書き込みます。
誤って削除したファイルを防ぐために2、
参照の数がファイルにゼロに低下したときに、基礎となるファイルを多重化した後、我々は参照カウント使用追跡ファイル、削除ファイルを使用します。しかし、いくつかのケースでは、ファイル参照番号は0で、ファイルは、そのファイルを誤って削除する可能性があり、使用され続けないという意味ではありません。ここでは、後になって、同時のチェックポイントは、偶然のファイルの削除だけでなく、ソリューションにつながる可能性を詳細に説明します。
以下の図、例えば、maxConcurrentlyCheckpoint = 2：
CHK-1が完了したチェックポイントを、上記の3枚の画像、CHK-2、CHK-3は、ベースとなるCHK-1、CHK-2が完了する前に、CHK-3であり、CHK-3は、登録4.sstの時間で見出されましたCHK-2は、既に登録されているに見出さ4.sstは、処理されたCHK-3、CHK-2は、その後4.sstに登録CHK-3をキャンセルし、そしてstateHandle削除対応4.sstにstateHandleを再利用します4.sst後、分散ファイルはstateHandleは今回ファイルを配布し削除した場合、それはまた、フォローアップするためにCHK-3から回収することができないリード、コンテンツを対応する5.sst削除されます、ゼロに参照カウントを対応します。
ここでの問題は、もし本当に、stateHandleが、それは全体のプロセスがチェックポイントの後に完了されるように、ファイルを参照していき、その後、分散ファイル削除するかどうかを決定するかどうかを右裁判官に対応する分散ファイルで0までの時間カウントを参照する方法でありますチェックポイントファイルは、安全に削除、または削除することはできません、完全な参照が見つかりません。
図3に示すように、空間的増幅を低減します
下に示すような小さなファイルを使用してスキームを組み合わせた後、セグメントに対応する各ファイルは、ファイルを分散SST：
ファイルは、すべてのセグメントがもはや使用されている4つのセグメント上の図は、セグメントのみ-4を使用している場合にのみ削除することができないが、セグメント[1]〜[3]の空間が浪費されているファイル全体を削除することができません1.6から1.3倍の全体的なスペース（実空間は/本物の便利なスペースを占有する）ことを実際の運用環境ショーからのデータ。
スペース増幅の問題を解決するには、TM、非同期スレッド倍率ファイルの到達は、圧縮のしきい値を超えています。そして唯一の圧縮ファイルは閉じられています。
次のように全体の圧縮プロセスは、次のとおりです。
- ファイルごとに算出した倍率
- 倍率が小さい場合は、ステップ7に進みます
- 倍率文書Aがしきい値を超えた場合は、対応する新しいファイルA「を生成（このプロセスは、洗浄作業の責任TMによって、ファイルの作成に失敗した場合）
- マッピング関係で記録し、A」
- 文書A StateHandle JMに送信Xが落ちる次のチェックポイントで、情報を生成する際に使用される新しいStateHandle JMに送信されA`
- チェックポイントXが完了した後、我々は「参照カウント0 Aファイルに縮小Aの参照カウントは、（Aの参照カウントであればJM増削除させていただきます減らすA」を追加し、異常、最後に成功したからだろう、参照をチェックポイントは、全体の参照カウンタを再構築）
- ファイル圧縮が完了しています
4、例外処理
チェックポイント時には、主な2つの異常がある：JM TMが異常と異常が、私たちは説明した状況を分割します。
1）JM異常
JMメイン基準端子と、ファイルレコードのStateHandleカウントは、参照カウントデータは、フェイルオーバーJM伝送であれば、直接、最新のものから、とても特別な処理は、他のトランザクション関連の操作を考慮する必要がなく、外部メモリに永続化する必要はありません完全なチェックポイントの復旧、復興とは、カウントを参照することができます。
2）TM異常
ファイルは、チェックポイントの前に、JMに報告されていることを）1; 2）ファイルはJMに報告されていない、我々はポイントを詳しく説明します：TM異常は、2つのタイプに分けることができます。
①ファイルはJMに報告されています
JMは、ファイルに報告された参照カウントを削除し、そのため、ファイルが最後にJM JMによって制御されていたファイルの参照カウントが0になったファイルを、持っている、ファイルはJMに削除されます。
②ファイルはJMに報告されていません
ファイルはJMに報告されていない、ファイルはもはや使用されていない、それはJM、孤立したファイルを認識されることはありません。この状況は一時的にクリーンアップに、周辺ツールを統一しました。
5、最後には、TMをキャンセルスナップショット
前の章のような以前、我々はFLINKは、対応する最適化された追跡には、対応する通知メカニズム、今FLINK-8871 [5]ではないが、我々は、内部的に関連する実装が増加している、スナップショットTM側をキャンセルするチェックポイント・タイムアウト/障害に必要チェックポイントは、データのRPC TMを送信するために失敗した場合、TMは、RPCメッセージを対応することにより終了、対応するスナップショットがキャンセルされます。
第三に、互換性
小さなファイルは、以前のバージョンから上の機能がサポートシームレスな移行をマージします。前のチェックポイントからのステップを復元し、次のとおりです。
- 状態を復元するために割り当てられた各TMは、彼らのニーズに対応します
- リモートからのダウンロードデータを、対応するTM状態ハンドル
- ローカルからの復元
小さなファイルは、主な効果は、全体的な互換性に影響しないため、リモートの時間からダウンロード異なるStateHandle対応するデータに適応し、ステップ2で、マージします。
第四に、長所と短所
利点：HDFSの圧力の大幅な削減：RPC圧力、圧力と名前ノードのメモリを含みます。
不十分：状態はマルチスレッドアップロード機能を（国家アップロードのボトルネックの一時的なチェックポイントではない）をサポートしていません。
第五に、オンライン環境の結果
オンラインプログラムの後、を介して取得することを確認し、名前ノード上の圧力が大幅にデータ、ファイルの作成から、オンライン生産クラスターから下に、スクリーンショットを軽減し、閉じRPCは、RPCの応答時間も大幅に短縮され、大幅に減少しました二から一一。
参考資料
- [1] https://ci.apache.org/projects/flink/flink-docs-stable/ops/state/checkpoints.html
- [2] https://flink.apache.org/features/2018/01/30/incremental-checkpointing.html
- [3] https://www.slideshare.net/dataArtisans/stephan-ewen-experiences-running-flink-at-very-large-scale
- [4] https://issues.apache.org/jira/browse/FLINK-11937
- [5] https://issues.apache.org/jira/browse/FLINK-8871
