フローバッチ統合生産アプリケーション！Bigoリアルタイムコンピューティングプラットフォーム構築の実践

はじめに： この記事は、Bigoコンピューティングプラットフォームの責任者であるXu Shuaiによって共有され、主にBigoリアルタイムコンピューティングプラットフォームの構築方法を紹介します。

この記事は、Bigoコンピューティングプラットフォームの責任者であるXu Shuaiによって共有され、主にBigoリアルタイムコンピューティングプラットフォームの構築方法を紹介します。コンテンツが含まれます：

1. Bigoリアルタイムコンピューティングプラットフォームの開発履歴
2. 機能と改善
3. ビジネスシーン
4. 効率の改善
5. 要約見通し

1.Bigoリアルタイムコンピューティングプラットフォームの開発履歴

本日は、主にBigoリアルタイムコンピューティングプラットフォームの構築プロセス、構築プロセス中に解決した問題のいくつか、および私たちが行った最適化と改善について説明します。最初に、Bigoリアルタイムコンピューティングプラットフォームの開発履歴である最初の部分を入力します。

ビゴの事業を簡単に紹介します。主にLive、Like、Imoの3つの主要なアプリがあります。その中で、Liveはグローバルユーザーにライブ放送サービスを提供しています。Likeeは、快手やDouyinと非常によく似た、短い動画を作成して共有するためのアプリです。Imoはグローバルな無料コミュニケーションツールです。これらの主要な製品はすべてユーザーに関連しているため、私たちのビジネスは、ユーザーのコンバージョン率と保持率を改善する方法に焦点を当てる必要があります。基本プラットフォームとしてのリアルタイムコンピューティングプラットフォームは、主に上記のビジネスに対応します。Bigoプラットフォームの構築では、上記のビジネスシナリオに関連するエンドツーエンドのソリューションも実行する必要があります。

ビゴのリアルタイムコンピューティングの開発プロセスは、大きく3つの段階に分かれています。

• 2018年以前は、リアルタイムの仕事はほとんどありませんでした。SparkStreamingを使用して、リアルタイムのビジネスシナリオを実行しました。
• 18年から19年にかけて、Flinkの台頭により、誰もがFlinkが最高のリアルタイムコンピューティングエンジンであると一般に信じていたため、ディスクリート開発にFlinkを使用し始めました。各ビジネスラインは、簡単に使用できるFlinkを構築します。
• 2019年から、Flinkを使用するすべてのビジネスをBigoリアルタイムコンピューティングプラットフォームに統合しました。2年間の構築後、すべてのリアルタイムコンピューティングシナリオは現在Bigoプラットフォームで実行されています。

下の図に示すように、これはBigoのリアルタイムコンピューティングプラットフォームの現状です。データソース側では、データはすべて、主にAPPとクライアントからのユーザー行動ログです。MySQLに保存されているユーザー情報もいくつかあります。

この情報はメッセージキューを通過し、最終的にプラットフォームで収集されます。メッセージキューは主にKafkaを使用しており、現在はPulsarが徐々に採用されています。MySQLログは、主にBDPを介してリアルタイムコンピューティングプラットフォームに入ります。リアルタイムコンピューティングプラットフォームでは、最下層も動的リソースを管理するために一般的に使用されるHadoopエコシステムに基づいています。上記のエンジンレイヤーはFlinkに統合されており、独自の開発と最適化を行っています。この開発、運用、保守、監視のワンストッププラットフォーム上に、BigoFlow管理プラットフォームを社内で構築しました。ユーザーはBigoFlowで開発、デバッグ、監視できます。最後に、データストレージに関しては、Hive、ClickHouse、HBaseなどともドッキングしました。

2.Bigoリアルタイムコンピューティングプラットフォームの機能と改善

次に、Bigoコンピューティングプラットフォームの特徴と私たちが行った改善点を見てみましょう。開発会社として、私たちのプラットフォーム構築の焦点は、ビジネスマンができるだけ簡単に使用できるようにすることです。事業の発展を促進し、規模を拡大するため。開発、運用、保守、監視のためのワンストッププラットフォームを構築したいと考えています。

まず第一に、ユーザーはBigoFlowで非常に便利に開発できます。この分野で開発している機能と改善点は次のとおりです。

1. 強力なSQLエディター。
2. グラフィカルなトポロジー調整と構成。
3. ワンクリックのマルチクラスター展開。
4. バージョンの統合管理と可能な限りの収束。

また、運用・保守分野においても、以下の点で多くの改善を行いました。

1. 完璧なセーブポイント管理メカニズム。
2. ログはESに自動的に収集され、一般的なエラーのトラブルシューティングルールが組み込まれています。
3. タスク履歴は、簡単な比較と問題追跡のために保存されます。

最後はモニタリングです。私たちの機能は次のとおりです。

1. 監視は自動的に追加され、ユーザーは基本的に手動で構成する必要はありません。
2. リソースの使用状況を自動的に分析し、ユーザーに適切なリソース割り当てを推奨します。

メタデータストレージには主に3つの場所があります。それらは、Kafka、Hive、およびClickHouseです。現在、ストレージシステムのすべてのメタデータを完全に開くことができます。これにより、ユーザーは大幅に使いやすくなり、使用コストも削減されます。

• Kafkaのメタデータを開いた後、一度インポートして、DDLなしで無期限に使用できます。
• FlinkとHiveも完全に接続されています。ユーザーがHiveテーブルを使用する場合、DDLは不要であり、直接使用できます。
• ClickHouseも同様で、Kafkaトピックを自動的に追跡できます。

実際、私たちが今日提供しているのはプラットフォームであるだけでなく、一般的なシナリオでエンドツーエンドのソリューションも提供します。ETLシナリオでは、ソリューションには次のものが含まれます。

1. ユニバーサル管理は、アクセスするために完全に自動化されています。
2. ユーザーはコードを開発する必要はありません。
3. データはハイブに入ります。
4. メタを自動的に更新します。

監視エリアでは、私たちの機能は次のとおりです。

1. データソースは自動的に切り替えられます。
2. 監視ルールは変更されません。
3. 結果は自動的にプロメテウスに保存されます。

3番目のシナリオはABTestシナリオです。従来のABTestはオフラインで実行され、結果は別の日以降にのみ生成されます。そこで本日は、ABTestをリアルタイム出力に変換し、統合されたフローとバッチ方式によってABTestの効率を大幅に向上させます。

Flinkの改善は、主に次の側面に反映されています。

• まず、コネクタレベルでは、多くのコネクタをカスタマイズし、会社が使用するすべてのシステムをドッキングしました。
• 次に、データフォーマットのレベルで、Json、Protobuf、およびBainaの3つのフォーマットを完全にサポートしました。ユーザーが自分で分析する必要はなく、直接使用するだけです。
• 第三に、会社のすべてのデータは直接Hiveに分類されます。これは、Hiveの使用においてコミュニティよりも進んでいます。ストリーミング読み取り、EventTimeサポート、ディメンションテーブルパーティションフィルタリング、Parquet複合型サポートなどが含まれます。
• 第4に、州レベルでもいくつかの最適化を行いました。SSDサポートとRocksDB最適化を含みます。

3、Bigoの典型的なビジネスシナリオ

従来の倉庫保管は、Kafkaを経由してFlume、次にHive、最後にClickHouseになります。もちろん、ClickHouseのほとんどはHiveからインポートされ、一部はKafkaを介して直接書き込まれます。

このリンクは非常に古いリンクであり、次の問題があります。

• まず、不安定です。水路が異常になると、データの損失や重複が頻繁に発生します。
• 第二に、スケーラビリティが低い。突然のトラフィックのピークに直面して、拡大することは困難です。
• 第三に、ビジネスロジックの調整は簡単ではありません。

したがって、Flinkを構築した後、私たちは多くの作業を行いました。元のFlumeからHiveへのプロセスを置き換えます。現在、すべてのETLはKafkaを通過し、次にFlinkを通過します。すべてのRBIは、データが失われないように、履歴保存としてHiveオフラインデータウェアハウスに入ります。同時に、多くのジョブはリアルタイム分析を必要とするため、別のリンクにアクセスし、分析のためにFlinkからClickHouseリアルタイムデータウェアハウスに直接入ります。

このプロセスでは、3つの主要な部分に分けられたいくつかのコア変換を行いました。まず第一に、ユーザーアクセスの分野では、私たちの変革には以下が含まれます：

1. できるだけシンプルにしてください。
2. 一般的な管理は完全に自動化されています。
3. メタ情報はDDLなしで通過します。

さらに、Flink自体では、変換には次のものが含まれます。

1. 寄木細工の書き込みの最適化。
2. 並行性の調整。
3. SSDディスクを介した大規模な操作をサポートします。
4. RocksDBは、メモリをより適切に制御するように最適化されています。

最後に、データシンクでは、Hiveをサポートするだけでなく、ClickHouseをドッキングするなど、多くのカスタマイズされた開発を行いました。

第四に、Flinkがビジネスにもたらす効率の改善

以下では、主にABTestシナリオで行ったいくつかの変換を紹介します。たとえば、すべてのデータがHiveに分類された後、オフライン計算が開始されます。数え切れないほどのワークフローの後、最終的に大きな幅の広いテーブルが作成されます。テーブルには多くのディメンションがあり、グループ化実験の結果が記録されている場合があります。データアナリストは結果を取得した後、どちらの実験が優れているかを分析します。

この構造は単純ですが、プロセスが長すぎ、結果が遅く、寸法を大きくするのは簡単ではありません。主な問題は実際にはSparkにあります。このジョブには実行するワークフローが無数にあり、一方のワークフローはもう一方が実行されるまでスケジュールできません。また、オフラインリソースについてはあまり良い保証はありません。これまでの最大の問題は、ABTestの前日の結果が翌日の午後まで出力されないことです。データアナリストは、午前中に仕事をすることができず、午後にほとんど仕事を休んでいるときにのみ分析を開始できると報告することがよくあります。 。

そこで、Flinkのリアルタイムコンピューティングパワーを使用して、適時性の問題を解決し始めました。最後の結果が出力されるのを待たなければならないSparkタスクとは異なり、FlinkはKafkaから直接消費します。基本的に、結果は午前中に発行できます。しかし、そのとき、最終出力の結果には多くの次元があるため、数百の次元が存在する可能性があります。このとき、状態は非常に大きく、OOMに遭遇することがよくあります。

そのため、変換プロセスの最初のステップで妥協しました。Flinkを直接使用して1つのジョブのすべてのディメンションを結合する代わりに、複数のジョブに分割しました。各ジョブはディメンションの一部を計算し、HBaseを使用してこれらの結果を結合し、結合の結果をClickHouseにインポートします。

変革の過程で、問題が見つかりました。宿題はロジックを頻繁に調整する必要があるかもしれません。調整後、結果が正しいかどうかを確認する必要があります。その場合、1日の時間枠が必要になります。履歴データを直接読み取る場合、Kafkaは長期間データを保存する必要があります。履歴データを読み取る場合、ディスク上で読み取る必要があるため、Kafkaに大きなプレッシャーがかかります。ゼロ点しかトリガーできないため、履歴データを読み取らない場合は、ロジックが今日変更され、結果が表示されるまで1日待つ必要があります。これにより、デバッグの反復が非常に遅くなります。 。

前述のように、すべてのデータはHiveにあります。その時点では、バージョン1.9のままでした。Hiveからのストリーミングデータをサポートしていました。これらのデータはすべてEventTimeによってトリガーされるため、HiveでトリガーするEventTimeをサポートしています。バッチフローを統合するために、ここではSparkは使用されません。これは、ジョブの検証にSparkを使用する場合、2セットのロジックを維持する必要があるためです。

Flinkでストリームバッチ統合アプローチを使用して、オフラインデータの補足またはオフラインジョブの検証を行います。リアルタイムのものは、日常業務の生産に使用されます。

先ほど申し上げたように、これはHBaseに依存しており、Flinkの機能を十分に活用できないため、実際には妥協案です。そこで、HBaseへの依存を完全に取り除くために、2回目の変換を実行しました。

2回目の反復の後、今日Flinkで大型時計の日レベルのウィンドウ取引を処理することができました。ストリーミングバッチ用のこの統合ソリューションがリリースされました。Flinkを直接使用して完全な大幅テーブルを計算します。毎日のウィンドウがトリガーされた後、結果はClickHouseに直接書き込まれ、基本的に早朝に結果を生成できます。

プロセス全体を通じて、Flinkの最適化には次のものが含まれます。

1. 状態はSSDディスクをサポートします。
2. ストリーミング読み取りHive、EventTimeをサポートします。
3. ハイブディメンションテーブルの結合、パーティションパーティションのロードをサポートします。
4. ClickHouseSinkerを完了します。

最適化後、1時間ごとのタスクが遅れることはなくなり、日レベルの完了時間が午後から作業前に進むため、反復効率が大幅に向上します。

V.まとめと展望

ビゴのリアルタイムコンピューティングの現状を要約します。まず第一に、それはビジネスに非常に近いです。第二に、会社で使用されているすべてのエコシステムとシームレスに接続し、基本的にユーザーが開発を行う必要をなくします。さらに、リアルタイムのデータウェアハウスが形成されました。最後に、私たちのシーンは大きな工場に比べて十分に豊かではありません。一部の一般的なリアルタイムシナリオでは、ビジネス要件がそれほど高くないため、多くの企業は実際にはリアルタイムシナリオに切り替えていません。

私たちの開発計画には2つの主要な分野があります。

• 最初の部分は、より多くのビジネスシナリオを拡大することです。リアルタイムの機械学習、広告、リスク管理、リアルタイムのレポートが含まれます。これらの分野では、リアルタイムコンピューティングの概念をさらに推進し、ビジネスとのつながりを深める必要があります。
• もう1つは、Flink自体に関するもので、内部で実行するシナリオが多数あります。たとえば、大規模なHiveディメンションテーブル結合、自動リソース構成、CGroup分離などのサポート。上記は、私たちが将来行う作業の一部です。

元のリンク

この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。