【ビッグネームがやってくる 第12話】eスポーツデータ処理プラットフォームにおけるAIとビッグデータシステムの応用

[51CTO.comより引用] eスポーツは近年最も急速に発展した競技スポーツのユニークな分野として、多くの社会的注目と注目を集めています。他の競技スポーツと同様に、e スポーツにはデータの分析と応用に関する独自の要件があります。 eスポーツでは、プロ選手とアマチュア選手の距離が近く、アマチュア選手がプロジェクトに深く関与するため、従来のスポーツに比べてゲームデータの量やデータ分析の技術的要件が飛躍的に増加しています。

今回の「ビッグネームがここに」では、VPGame CTO の Yu Yuanyuan (Y3) 氏を招き、「ゲームから科学へ: AI と e スポーツ」というテーマで講演していただき、最先端のテクノロジーを使用して大量の e スポーツ データを処理、保存、分析する方法に焦点を当てました。

FunData ビッグデータシステム

e スポーツのデータ量は従来の競技スポーツよりもはるかに多いのですが、VPGame ではどのような技術的フレームワークを使用してデータを処理しているのでしょうか?以下では、FunData ビッグデータ システムとその ETL 層、インターフェイス層、データ処理層などの具体的な詳細を紹介します。次の図は、FunDataビッグデータシステムの一般的なアーキテクチャを示しています。

FunData ビッグデータ システムは 4 つのレイヤーに分かれています。ETL レイヤーはデータの抽出、クリーニング、フィルタリング、ロードを担当します。インターフェイス レイヤーはフロントエンド製品アプリケーションにサービスを提供します。データ処理レイヤーはストリーム コンピューティング、バッチ コンピューティングなどの方法を使用して生データを抽出し、最終的に高可用性の概要データを取得します。ストレージ レイヤーはデータを分類し、ストレージ用のさまざまな技術ソリューションを選択します。

FunData ビッグデータ システム ETL パラダイム

次の図は、FunData ETL の全体的なパラダイムを示しています。

メーカーのデータ インターフェイス、ライブ ビデオ、ビデオ ファイルなどのチャネルから取得されたデータ ソースは、外部メッセージ キューを介してデータ レポート モジュールにプッシュされます。内部メッセージ キューは、さまざまなデータ クリーニングおよび分析システムに通知して、元のデータをさまざまなカテゴリにアーカイブして保存します。その後、データは内部メッセージ キューを介して段階的にさまざまな基盤ストレージ サービスに読み込まれたり保存されたりします。

FunData ビッグデータ システム インターフェース レイヤー

次の図は、Kubernetes に基づく Elastic API システム アーキテクチャを示しています。

データはどのように使用すべきでしょうか? VPGame アプリケーションを提供する場合でも、サードパーティ アプリケーションを提供する場合でも、すべて Kubernetes 上に構築された API クラスターを通じて実装されます。 API システム アーキテクチャは静的ではありません。他のゲーム IP への深化や拡張が進むにつれて、多くの最適化が同時に実行されます。同じゲームでも、段階によって豊富さが異なる API が提供されます。もちろん、拡張プロセス全体がスムーズでなければなりません。 API システム アーキテクチャには、ゲーム中の API リクエストの急増に対応できる柔軟な拡張機能が必要です。

FunDataビッグデータシステムのデータ処理層

データ処理層の課題は、ゲームごとに、あるいは同じゲームでもシナリオごとにデータロジックが異なることです。そのため、仮想マシンに基づく単一のプログラム設計を採用すると、弾力性のあるトラフィックに適応することが非常に難しくなります。次の図は、データ処理層の動作ロジックを示しています。

VPGame のデータ処理ロジックは、サーバーレスの柔軟なフレームワーク上に構築されており、急増するデータをリアルタイムで処理および計算します。フレームワーク全体において、ビジネス側はビジネス ロジックを記述するだけでよく、キャパシティ プランニングの問題を心配する必要はありません。

以下は、VM システムとサーバーレス アーキテクチャの比較表です。

VM システムとサーバーレス アーキテクチャには、主にリソースの使用率、リソースの仮想化、コンピューティング能力の点で明らかな違いがあります。 VM システムの場合、トラフィックが増加すると、運用保守担当者に連絡してマシンを追加する必要があります。トラフィックが正常に戻ったら、再度運用保守担当者に連絡してマシンの数を減らします。サーバーレスアーキテクチャーでは、実際のリクエスト量やマシンの状態に応じて動的に分散し、運用保守や業務関係者の介入を必要とせず、Vfunctions によって一元管理することができます。また、時間の経過とともにゲームデータの量が急増し、人気時期（大会/休日）にはゲーム数が急増します。従来のVMベースのデータ処理方法では、大量のデータ処理タスクが蓄積され、システム負荷が急上昇し、一部の処理タスクがタイムアウトし、容量拡張のために手動でアクセスする必要が生じます。サーバーレス アーキテクチャに変更します。新しいデータを受信すると、サーバーレス スケジューラはワーカーをランダムに割り当て、データの処理と抽出のための対応するアルゴリズム コンテナを開始します。

データ処理層が直面するもう 1 つの問題は、異なる次元とレベルのデータにはリアルタイム パフォーマンスの要件が異なり、リソースと時間の計算と処理の要件も異なることです。ここでは、処理モジュールをHadoop（データバッチ処理）とFlink（データストリーム処理）に大まかに分ける必要があります。

バッチデータは、一般的にはゲームに登場するヒーローの数、その装備、スキル選択などのグローバル統計データです。これらのデータは比較的詳細で、アクセス頻度が比較的低いため、適時性に対する要件は比較的低くなります。ただし、1 つのゲームの基本データはホット データであり、ゲーム終了後すぐに処理する必要があります。ここでは、データを受信して​​から数秒以内にデータ結果が生成されるようにするために、ストリーム処理フレームワークが必要です。 DOTA2 の 1 つのゲームの個人データ処理を例に挙げます。詳細については、下の図を参照してください。

メッセージ キューから入ってくるデータ信号により、これらの ID に対して新しいゲームが生成されたことが分かります。次に、フィルターは無効なゲーム ID をフィルターし、データ構造の一部をさらに変換し、不要なフィールドをクリーンアップし、これらの処理フローを異なる次元の演算子に書き込み、最後に Reduce 演算子を使用して集計を行います。

まとめると、ビッグデータ システムに関するコンテンツは、この共有の最初の部分です。OCR と機械学習に基づく FunData の大規模ストレージとデータ認識およびマイニングに関するさらに 2 つの興味深いコンテンツがあります。ビデオをクリックしてください: http://aix..com/activity/10021.html

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]