要約: この記事は、Flink Forward Asia 2022 プラットフォーム構築の特別セッションで、Ant Group のシニア テクニカル エキスパートであり、Ant Group のフロー コンピューティング プラットフォームの責任者である Li Zhigang の共有からまとめられています。この記事の内容は、主に次の 4 つの部分に分かれています。
- 主な課題
- 建築計画
- コア技術紹介
- これからの計画
1. 主な課題
1.1 財務シナリオのビジネス機能の紹介
最初の部分は適時性です。財務シナリオは適時性を追求します。特に一部のリスク管理ビジネスはそうです。まず第一に、ダウンタイムであろうとその他のリスク状況であろうと、ビジネスへの影響は数秒以内である必要があります。第 2 に、ビジネス ロジックは頻繁に変更され、適時性に影響を与えることができません。最後に、金融ビジネスの上流と下流の依存関係は特に複雑であり、適時性が影響を受けないようにする必要があります。
2番目の部分は正しさです。財務データ いずれにせよ、計算されたデータは 100% 正確でなければなりません。データエラーは、障害やその他の問題によって発生することはありません. データエラーが発生すると、ビジネスは受け入れられなくなります. 現在、多くの企業は最初に一連のオフライン データ モデルを開発し、次にリアルタイム データ モデルを開発していますが、両者が異なるエンジンを使用すると、データの検証が非常に困難になります。データに問題がある場合は、JAVA コードや C++ コードを記述して問題を見つけて修正するなど、より便利なデバッグ技術が必要です。
3番目の部分は安定性です。Ant サービスは、オンライン サービス、オフライン サービス、リアルタイム サービスなど、大規模な物理クラスターに混在しています。このような複雑で変化しやすい混合分散環境では、リアルタイム サービスの安定性を確保する必要があり、リアルタイム サービスは K8s コンポーネントやクラウド環境内の他のコンポーネントの影響を受けません。特に大規模なポッド リソースを申請すると、時間が非常に長くなり、リアルタイム ビジネスの第 2 レベルの基準を満たすことができなくなります。金融シナリオのこれらの特性により、革新的なソリューションを提案します。
1.2 アントフローコンピューティング事業の基本状況
ストリーム コンピューティングの規模は約 78w コア、1.2w+ ストリーム ジョブであり、すべてのクラスターはクラウドネイティブ クラスターで実行されます。毎年15以上の大きなプロモーションをサポートしています。プロモーション ビジネスは頻繁に変化するため、動的で柔軟なコンピューティング機能が必要です。
1.3 ストリーム コンピューティング サービスの主な課題
近年、リアルタイム コンピューティング技術は安定期にあり、弾力性の面での課題は次のとおりです。
- プロモーションが正規化された後、クラスターはいつでも拡張および縮小できます。
- 混合分散環境でリアルタイム サービスの安定性を確保する方法。リアルタイム コンピューティングの安定性は、他のビジネスの影響を受けません。
- ストリーム コンピューティングのコア テクノロジは、状態のパフォーマンスを最適化することです。大規模なデータ結合またはウィンドウの場合にパフォーマンスの問題がないように、状態のパフォーマンスを極限まで最適化する方法。
使いやすさに関する課題には、次の要素があります。
- 金融サービスまたは BI サービスは、いつでも変更される可能性があります。変更があった場合にジョブをすばやく再開する方法。
- SQLジョブデバッグの難問をどう解決するか。
- バッチ フローの統合を実現する方法。
1.4 課題へのアプローチ
使いやすさに関しては、当社のソリューションは次のとおりです。
- リアルタイム コンピューティング プラットフォームを変革し、ホット スタート テクノロジを提案して、クラウド環境でのスロー スタートの問題を解決します。
- SQL コードのデバッグは、IDEA での Java コードのデバッグに似ており、難しいデータのトラブルシューティングの問題を解決します。
- Flink ベースのストリームバッチ統合開発プラットフォームが提案されています。
柔軟性の面では、非常に多くのプロモーション活動があるため、いつでも拡張および縮小する必要があります。したがって、私たちの解決策は次のとおりです。
- K8sをベースにした総合ミキシング。
- Flink のネイティブ K8s モードを変換し、クラウドネイティブな Flink クラスター モードを提案して、K8s の問題によるリアルタイムのビジネスの安定性への影響を回避します。
2.建築計画
Ant リアルタイム コンピューティング プラットフォームのアーキテクチャ図
最下層は K8s プラットフォームで、上位層は Ant Stream Computing のコア技術である Flink ランタイム ストリーム バッチ処理の統合です。K8s クラスター モードが提案され、オープン ソース コミュニティの DophinScheduler がワークフロー スケジューリングの実装に使用されます。
コア テクノロジーには、メモリの最適化、ウィンドウの最適化、複雑で変化しやすいクラウド環境でのインテリジェントな診断 (問題の発見方法、問題の特定方法など) が含まれますが、ストリーム コンピューティング操作のパラメーターを調整することは困難であるため、AI ベースの学習パラメータ調整問題を自動で解決するアルゴリズムを提案 ; コミュニティ版RocksDBの状態の性能が良くない場合がある. RocksDBに比べて2倍の性能向上を持つ状態格納AntKVを作成した.
Java コードのデバッグと同じくらい便利な SQL のデバッグ機能を提案します; ホット スタートは遅いジョブの起動の問題を解決します; ユーザーは一連の SQL ジョブを記述し、実行モードまたはバッチ モードを指定するだけで、ユーザーが抱える問題を解決する必要があります。コードと他の開発の 2 つのセットを記述する必要はありません 問題。
3. コア技術紹介
3.1 ホットスタート技術
第一部、なぜホットスタート技術が必要なのか?
まず、リアルタイム ジョブを開発する人なら誰でも、メモリや同時実行性などのジョブ パラメータを変更した後、ジョブ全体を再起動するには時間がかかることを知っています。特にクラウドネイティブ環境では、ジョブの投入、Pod の申請、Pod の送信、イメージのプルアップに数分かかります。リアルタイムの金融ビジネスには受け入れがたい。
2 つ目はトラフィックの急激な変化で、大きなプロモーションの際にはトラフィックが変化することがよくあります。この変化に直面して、私たちはそれに迅速に適応する必要があり、並行性、メモリ、および UDF の変更が頻繁に発生します。Flink のネイティブ バージョンを使用する場合、プロセスは特に長くなります。平均して、変更から提出、リソースの実際のダウンタイム、および宿題の開始までのプロセスに 4 分かかる場合があります。
どうすれば解決できますか？
私たちは、ユーザーがフロントエンドインターフェースで休息サービスを要求することを技術原理とするホットスタート技術を提案しました。次に、変更された実行計画パラメーターを残りに提供し、いくつかの事前チェックを行います。次に、事前に検証されたパラメーターと実行計画を参照して、既に実行されているジョブを実行します。新しい実行計画を取得すると、古い実行計画を一時停止してキャンセルし、回復後にゆっくりと作成します。
一般に、新しい実行計画を作成し、古い実行計画を一時停止してから、新しい実行計画に基づいて新しい展開モードを生成します。これを行う利点は、Jar パッケージをダウンロードする SQL などの複雑なプロセスを含む SQL コンパイルの前の段階をバイパスし、Pod アプリケーションの時間を節約し、ジョブの再起動操作が数秒で完了することです。
ホットスタート技術の処理の流れ
まず、持ち込まれた新しい JobGragh を古い JobGragh とマージし、Jar パッケージ、リソース、ファイルなどを含む、古い JobGragh の再利用可能なデータを新しい JobGragh にバックフィルします。
次に、新しい実行計画が生成された後、古いタスクと中間のチェックポイント コーディネーターの間の調整ノードが中断されます。
3 番目に、すべての一時停止の後、新しい JobGragh をスケジュールし、新しい状態をロードします。新しい実行計画のスケジューリングが失敗した場合、ユーザー エクスペリエンスの使いやすさを確保するために、以前の通常の状態にロールバックするロールバック テクノロジが必要です。
ホットスタート効果
ホットスタート技術により、稼働時間を 90% 以上短縮できます。つまり、以前はほとんどのスタートアップ ジョブに 300 秒かかっていましたが、ホット スタート テクノロジを使用すると、現在は 2 秒または 1 秒しかかかりません。
3.2 K8S クラスターモード
第 2 部、なぜ K8s クラスター モードが必要なのですか?
- 上の図の右側は、オープン ソース コミュニティ バージョンによって提供される Flink ジョブのネイティブ K8s サブミッション メソッドです。まず、K8s Client は K8s API Server を見つけて K8s Service を申請します. K8s は K8s のデプロイを開始し、次に Master ロールをプルアップし、Flink が必要とする Pod を Master で申請し、TaskManager およびその他のプロセスをマスターで開始しますポッド。これらの複雑なプロセスはすべて、API サーバーや K8s マスターなどの K8s コンポーネントに依存しており、これが単一点につながります。API サーバーのアップグレードや障害が発生すると、ジョブの投入、運用、保守などに影響が生じます。Ant の実践では、歴史上多くの問題がありました.K8s クラスターのアップグレードに遭遇すると、リアルタイムジョブを送信、操作、および維持できません。
- 大規模なリソース Pod を申請する場合、時間は特に長く、5 分にもなり、ユーザー エクスペリエンスに特に悪影響を及ぼします。
- 32 コアと 64 GB の大きな Pod の申請は、しばしば失敗します。
- リアルタイムの事業推進活動中に、事業の新しいリソース要件を動的に満たすことは不可能です。
- K8s API サーバーのパフォーマンスがボトルネックです。一度に何百もの Pod をバッチで作成すると、非常に遅くなり、タイムアウトしやすくなります。
上記の問題を解決するために、K8s クラスターモードを提案します。
K8s クラスタ モード
基本的な考え方は、まず Operator を通じて K8s から大量のリソースを申請し、次に ClusterManager がリソースを保持することです。ジョブを送信した後、K8s API サーバーまたはマスターにアクセスして、サービスやデプロイなどのリソースを申請する必要はありません。
それは何が良いですか？
まず第一に、API Server と Master を処理する必要がなくなるか、または削減できます。第 2 に、Pod は既にマシンに適用されているため、ジョブが送信されるたびに新しい Pod を適用する必要がなく、時間を大幅に節約できます。
上の図からわかるように、K8s コンポーネントによって引き起こされる問題は直接 95% 減少します。ジョブの起動時間は、以前は 100 秒以上かかっていましたが、現在は 50 秒に短縮され、ホット スタート技術により、1 ～ 2 秒でジョブを開始できます。リソース使用率が 5% 増加しました。
3.3 フローバッチ統合技術
第三部、なぜフローバッチ統合技術が必要なのですか?
800 個のインジケーターを使用して BI レポートを開発する場合、そのうち 750 個をオフラインで開発する必要があり、650 個を Flink でリアルタイムで開発する必要があり、500 個を繰り返す必要があることがわかります。繰り返しとは、一連の SQL をオフラインで実行する必要があり、一連の SQL をリアルタイムで実行する必要があることを意味しますが、実際にはそのビジネス ロジックはまったく同じです。これは、データ開発の過程で多くの作業の重複につながります。例えば、バッチエンジンでセットを開発し、次にFlinkリアルタイムエンジンでセットを開発すると、両者のSQL構文が異なるため、チェックするのが非常に困難です。現在のビジネス開発の問題点を解決するために、Ant のストリーム バッチ統合テクノロジが提案されました。
上の図に示すように、フローバッチ統合テクノロジの最下層も K8s 上にあります。次のレベルでは、Flink ランタイムを使用します。
上位レベルには、プラグイン シャッフル サービス、プラグイン スケジューリング、およびプラグイン ステータスがあります。
- プラグインシャッフルサービス。シャッフル サービスは、バッチ コンピューティングにおいて非常に重要です. たとえば、シャッフル サービスを使用して、クラウド環境での小さなローカル ディスクの問題を解決できます.
- プラグインのスケジューリング。ストリームとバッチは別々にスケジュールされ、スケジュールもプラグインできます。
- プラグインの状態。たとえば、RocksDB、メモリ、および AntKV タイプの状態タイプです。
上がホームの統一入口。ユーザーは、統合ポータルで SQL のセットを一様に作成することを選択してから、実行中またはバッチを指定できます。これにより、SQL の 2 つのセットを作成する問題が解決されます。
Flink デバッグ技術
開発時には、SQL のバッチを作成して SQL をストリーミングする必要がある場合があります。データに問題が頻繁に発生する場合は、JAVA コードと C++ コードの書き方を知っており、IDE や GDB などのツールを使用してシングルステップ デバッグを実行します。SQL コードのシングルステップ デバッグ手法を提案します。2 つの解決策があります。最初の解決策は、バッチ オペレーターとフロー オペレーターを含む、Flink コード内のすべてのオペレーターを変更することです。次に、入口でトレース コードを追加します。つまり、入口で入力データを出力し、出力で出力データを出力します。しかし、このソリューションには問題があります。ネイティブの Flink エンジン コードに侵入し、非常に洗練されていないコードになります。2 番目のオプションは、バイトコード拡張です。
では、バイトコード拡張技術はどのようにそれを行うのでしょうか? Java コードまたはその他のコードを IDE からデバッグする場合、最下層は実際には JAVA エージェント テクノロジによってデバッグされることをご存知かもしれません。JAVA エージェントは、クラスを委任できるテクノロジです。つまり、クラスを実行する前に新しいクラスをモックし、新しいクラスの動作を自分で制御します。したがって、JAVA エージェントは実行中のクラスをプロキシし、次にプロキシを介して実際に実行中のクラスを実行します。上の図の右側からわかるように、基礎となる Flink エンジンのコードは変更されません。したがって、プロキシによって、書き換えられた新しいクラスは、クラスがロードされる前に JAVA エージェントを介してプロキシされます。
新しいクラスは主に 2 つの部分に分かれており、最初の部分は Stream Operator です。Stream Operator の実行後、入力メソッドと出力メソッドが挿入されるため、オペレータの入力データと出力データを出力できます。つまり、Byte Buddy を介してクラスの書き換えを実現できます。
ここで問題があります. Flink コードには多くの codegen コードがあり、いくつかの関数呼び出しを 1 つの関数にまとめて実行する操作中に、いくつかの動的コードが自動的に生成されます。しかし、JAVA エージェントの Byte Buddy を介してクラスを書き換えると、内部メソッドが呼び出されると問題が発生します。
上の図からわかるように、codegen は JAVA エージェント技術によって書き換えられています。最初に codegen コードのコピーをダウンロードしてローカルに保存し、次に Byte Buddy を介して書き直してから、入力コードと出力コードを挿入して、オペレーターの入力と出力を確認できるようにします。JAVAコードをデバッグするのと同じように、何が入力で、何が出力で、何が次のノードの入力で、何が次のノードの出力であるか、すべて詳細に出力できます。
4. 今後の予定
まず、Flink のバッチ パフォーマンスを最適化し、完全なベクトル化されたコンピューティングをサポートします。業界には完全なベクトル化コンピューティングを行っているエンジンも数多くあります.Databricks の完全なベクトル化コンピューティング エンジンなどの一部のオープン ソース テクノロジにより、そのパフォーマンスは 2 倍以上向上しています。
2 つ目は、機械学習に基づく自動チューニングです。ストリームコンピューティングはパラメータ数が多く、ユーザーが使いこなすのは難しいですが、機械学習を用いてパラメータの自動調整の問題を解決していきます。
3 つ目は、Flink ベースのレイク ウェアハウス テクノロジを開発することです。ストリーミング バッチが統合された後、ストレージ、コンピューティング、およびプラットフォームが統合されるため、1 つのエントリでユーザー バッチ、ストリーミング、AI、および学習のすべてのコンピューティング ニーズを解決できます。
4 つ目は、クラウド環境でのインテリジェントな診断です。クラウド環境は比較的複雑で、問題が発生したときに特定の問題を解決することは困難です。マシン、IP アドレス、マシンの負荷など、基盤となるクラウド環境を診断して、ユーザーが問題をすばやく見つけるのに役立つインテリジェントな診断ツールを提案します。
第 5 に、ストリームとバッチの混合展開により、タイムシェアリング スケジューリングが可能になり、使用率が向上します。フローバッチはエンジンの統合だけでなく、統合後のリソース利用率もさらに向上するので、今後も利用率向上の方向で頑張っていきます。