[EuroSys2023 最優秀ポスター] 動的グラフ向けの超低遅延 GNN 推論サンプリング サービス

著者: 沈文廷

GraphLearn は、Alibaba Cloud 機械学習プラットフォームの PAI チームと DAMO アカデミーのインテリジェント コンピューティング研究所のグラフ コンピューティング チームが共同で構築した業界の大規模なグラフ ニューラル ネットワーク トレーニング フレームワークであり、DAMO アカデミーのグラフ学習エンジンでもあります。ワンストップのグラフ コンピューティング プラットフォーム GraphScope。GraphLearn の最新のオープンソース GNN オンライン推論リアルタイム サンプリング サービス (DGS) は、動的グラフ用です。DGS には、リアルタイムの高スループットのグラフ更新を処理する機能があり、低遅延、高同時実行性の推論サンプリング クエリ処理を保証できます。グラフ更新とサンプリング クエリのパフォーマンスは、分散環境で線形に拡張可能です。最近、GraphLearn チームと浙江大学が共同で公開した「大規模なリアルタイム GNN 推論のための動的グラフ サンプリング サービス」が EuroSys2023 の最優秀ポスターに選ばれました。

画像.png

ポスターのアドレス: https://2023.eurosys.org/docs/posters/eurosys23posters-final40.pdf
オープンソース プロジェクトのアドレス: GraphLearnGraphScope

背景紹介

GNN モデルは、グラフ構造を通じて高次の近傍情報を表現します。大規模な産業実装では、一般的なトレーニング方法は、分散型スケーラビリティを得るために近傍サンプリングを通じて通信と計算のオーバーヘッドを削減することです。同時に、推奨や金融詐欺対策などの実際のビジネス シナリオでは、グラフの構造とプロパティは時間の経過とともに動的に変化することが多く、GNN モデルはこれらの近傍の動的な情報をサンプリングして表現できる必要がありますリアルタイム。

オンライン学習はモデルのジッターを引き起こしやすいため、実際の運用アプリケーションでは、通常、モデルのデプロイメントは複雑な運用リンクを経由する必要があるため、デプロイメントにはニアライン モデルが一般的に使用されます。近傍情報をリアルタイムで表現する GNN モデルの推論プロセス中に、リアルタイムのサンプリング グラフの構造と属性を通じてリアルタイム推論

ユーザー エクスペリエンスを確保するために、このリアルタイム推論タスクのレイテンシ要件は非常に低く、サンプリング クエリのためのレイテンシ スペースはほとんど残されていません。同時に、産業用の大規模グラフのデータ規模とオンライン推論サービスの QPS により、単一マシンのストレージおよびコンピューティング能力を超えることがよくあります。したがって、大規模な動的グラフでの極めて低いレイテンシを保証し、分散環境で線形にスケーリングできる機能を備えた、GNN モデル推論用のリアルタイム サンプリング サービス (20 ミリ秒以内の P99) を提供する必要があります。

チャレンジ

リアルタイム グラフ サンプリング サービスの直感的な方法は、動的なグラフ ストレージおよびクエリ モジュールを維持し、推論リクエストが到着したときにリクエストされたポイントで近隣サンプリング計算と属性収集を実行し、サンプリング計算から取得したサンプルを推論のためのモデルサービスの入力。しかし、グラフデータの分散や推論サンプリングの負荷特性により、この直感的なアプローチでは分散動的グラフ上で安定した低遅延サンプリングを実現することが難しく、具体的には以下のような課題があります。

  1. 近傍サンプリングはすべての近傍を横断する必要があり、グラフの動的な変化により近傍は常に変化し、複雑なサンプリング計算の低遅延を確保することが困難であり、スーパー ポイントの存在により遅延も不安定になります。 。
  2. グラフ データの分散が不均衡であるため、各グラフ スライスのストレージとコンピューティングの負荷が不均一に分散され、その結果、サンプリング遅延が不安定になり、分散ダウンライン スケーリングが課題になります。
  3. 推論サンプリングは一般にマルチホップ サンプリングであり、頂点またはエッジの動的な属性を収集する必要があります。分散グラフでは、マルチホップ サンプリングと属性アクセスによって引き起こされるネットワークとローカル I/O のオーバーヘッドがレイテンシに大きな影響を与えます。 . .

キーデザイン

一般的なグラフ データベースのワークロードとは異なり、動的グラフ推論サンプリング サービスが特定のモデルのオンライン推論を行う場合、対応するグラフ サンプリングには固定パターンがあります。たとえば、一般的なユーザー - アイテム、アイテム - アイテムの 2 部グラフ上の GraphSAGE モデルでは、このグラフのサンプリング パターンは通常、要求されたユーザー ID (feed_id) 用であり、最新の 2 つの購入済みアイテムの確率サンプリングとしてのタイムスタンプに従っています。これらの 2 つの商品については、相関係数が最も高い 2 つの商品をサンプリングします。GraphLearn が提供する GSL (グラフ サンプリング言語) を使用して、次のクエリを表現します。

画像.png

図 1: 2 ホップ サンプリング クエリ

この固定パターン クエリは、大規模な動的グラフ サンプリングに安定した低遅延サービスの機会を提供します。

DGS システム設計の重要なポイント:

  1. ストレージとコンピューティングの分離とクエリ対応キャッシュ

DGS は、グラフの保存とサンプリングの計算を分離します。サンプリング計算は一般に、ランダム サンプリング、最新の近傍サンプリング (topk タイムスタンプ)、またはエッジの重み (またはエッジ タイムスタンプ) による確率分布サンプリングを指します。最初の 2 種類のサンプリングの時間計算量は O(1) です。確率分布サンプリングは通常、エイリアス法を使用して実装されます。エイリアス テーブルは、ダイナミック グラフ内の変化する確率分布に対して繰り返し計算する必要があります。その時間と空間の複雑さは両方とも O(N). であり、N は頂点の近傍の数であり、変化し続けます。グラフストレージの単純な読み書きとは異なり、グラフサンプリングプロセスにはストレージの読み書きや複雑な計算が含まれるため、まずストレージとコンピューティングを分離し、コンピューティング側ではアクセスする必要のあるデータをシステムがキャッシュします。グラフ サンプリング計算の空間的局所性を改善するために、事前にサービスの特定のクエリを実行します。

  1. イベント駆動型のプリサンプリング

サンプリングリクエストへの応答を高速化するため、DGSはリクエスト入力時からグラフ更新イベント発生時までの各頂点のサンプリング計算を時間空間を利用して進め、列挙だけを完了すればよいようにします。サンプリング要求が発生したとき。同時に、発生からサンプル生成までのグラフ更新イベントの古さを軽減するために、DGS は、各更新が到着したときに、プリインストールされたクエリ、ストリーム サンプリングに従って、加重リザーバー サンプリング アルゴリズムによるフロー サンプリング方式を採用します。 。このグラフ更新イベント駆動型サンプリング プレサンプリング手法では、グラフ データの保存スペースと各頂点の計算時間が定数 *O(K) になります (K はリザーバーのサイズです)。課題 1 の問題は、グラフ サンプリングの計算結果をキャッシュに事前に保存することで解決されます。

  1. マルチホップの解体と遅延スプライシング

これまでのところ、DGS は入力頂点のリアルタイム ワンホップ サンプリングを解決してきました。ただし、DGS は主にマルチホップ サンプリングを行います。2 ホップ サンプリングを例に取ると、入力頂点の最初のホップの結果が更新された後、対応する 2 番目のホップの結果も更新する必要があります (同時に、収集された属性は更新されます)。ホップが多い場合、この連鎖反応によって生じる読み取りおよび書き込みのオーバーヘッドが指数関数的に増加し、サンプリング リクエストの遅延に大きな影響を与えます。DGS がこの問題を解決する方法は、事前にインストールされたクエリに従って各ホップに従ってグラフ サンプリングを逆アセンブルすることです。各ホップ サンプリングでは、グラフ内の対応する頂点タイプのすべての頂点が事前にサンプリングされ、対応して格納されます。たとえば、図 1 のクエリを図 2 に示すように分解し、イベント駆動型のプリサンプリングと組み合わせると、図 3 に示すように、各頂点に対応するサンプルがリザーバーに保存および更新されます。

さらに、DGS は、事前のスプライシング後の継続的な更新を回避するために、マルチホップ サンプルのスプライシングを、対応する推論サンプリング要求が発生する瞬間まで延期します (遅延スプライシング)。

画像.png

図 2: 2 ホップ サンプリング クエリの逆アセンブリ

画像.png

図 3: イベント駆動型の更新

  1. サブスクライブ・パブリッシュのメカニズム

リクエストが発生するまでマルチホップ スプライシングを遅らせますが、マルチホップの結果は異なるシャードに保存されることが多く、マシン間通信により多くのネットワーク通信オーバーヘッドが生じます。したがって、DGS は、特定のシャーディング アルゴリズムに従って、要求された ID を対応するサービス マシンにルーティングする一連のサブスクリプション発行メカニズムを設計し、マシンはこれらの ID とそのマルチホップ ネイバーの更新をサブスクライブします。近隣関係が変化すると、サブスクリプション テーブルは常に更新されます。

  1. 読み書き分離

上記のシステム設計によれば、サンプリング リクエストが発生すると、DGS はそれを指定されたワーカーにルーティングし、ローカル クエリを実行してマルチホップ サンプリング結果を取得します。読み取りのレイテンシと書き込みの失効性を同時に保証することを優先するために、DGS は読み取りタスクと書き込みタスクをスケジュールするときに優先スケジューリングを実行します。同時に、システム アーキテクチャの観点からは、頻繁に計算とストレージの更新を行うタスク (書き込み) と、サンプリング要求に応答するタスク (読み取り) を別のマシンに配置し、読み取りと書き込みを分離します。

システム構造

DGS システムのコア コンポーネント アーキテクチャを次の図に示します。主にサンプリング ワーカー コンポーネントとサーバー ワーカー コンポーネントです。

画像.png

図 4: DGS システムのコア アーキテクチャ

グラフの更新は、キー (頂点 ID など) の断片化に従って、サンプリング ワーカーの対応するパーティションに送信されます。各サンプリング ワーカーは特定のパーティションを担当します。ワンホップ プリサンプリングを実行し、結果をサービング ワーカーに送信します。各サービング ワーカーは、サンプリング ワーカーから受信した K 個のワンホップ クエリのサンプリング結果をキャッシュし、グラフ全体の特定のスライスの頂点の推論サンプリング リクエストに応答します。

サンプリング ワーカーとサービング ワーカーは独立して弾力的なスケーリングを実行して、グラフの更新や推論リクエストにおける負荷の変化に対処できます。完全な K ホップ サンプリング結果を生成する際の遅延を最小限に抑えるために、DGS は頂点 $V_{i}$ のすべての K ホップ サンプリング結果を、$V_{i}$ 推論リクエストに応答するサービング ワーカーに事前に送信します。 K ホップ グラフのサンプリング計算は、Serving Worker 上のローカル キャッシュにアクセスするだけで済む操作に変換されます。これを実現するために、各サンプリング ワーカーは、ワン ホップ クエリごとにサブスクリプション テーブルを維持し、ワン ホップ クエリの結果をサブスクライブするサービング ワーカーのリストを記録します。たとえば、頂点

$V_{i}$ のワンホップ サンプルから $V_{j}$ を追加または削除すると、メッセージがトリガーされて、$V_{j}$ を含むパーティションのサンプリング ワーカーにイベントが送信され、$ が更新されます。 V_{j} に応じて $ のサブスクリプション情報。

この設計により、DGS は、同時推論サンプリングの負荷が高くても非常に安定した遅延パフォーマンスを発揮できます。

パフォーマンス

実際の Alibaba e-commerce データセットでの実験では、DGS が推論リクエスト (2 ホップのランダム サンプリング クエリ) の P99 レイテンシーを 20 ミリ秒以内に維持でき、単一のサービング ワーカーの QPS が約 20,000 で、線形的に拡張できることが示されています。グラフデータ更新のスループットは109MB/sに達し、これも直線的に拡張できます。

画像.png

図 5: 実験構成とパフォーマンス データ

エピローグ

このペーパーでは、DGS の技術的解釈を提供し、DGS コア モデルの設計アイデアを紹介します。実際、DGS にはサービスとして、サービス プルアップ モジュール、高可用性モジュール、データ ロード モジュール、モデル サービスに接続されたクライアントも含まれています。DGS の助けを借りて、ユーザーは最新のサービスを推論して入手できます。リアルタイムに変化するグラフの構造と特性に基づくグラフ。GraphLearn ベースのトレーニング、モデルのデプロイメント、DGS に基づくオンライン推論のためのエンドツーエンドのチュートリアルを提供しています。ぜひ試してみてください。詳細については、ソース コード技術ドキュメントを参照してください。

{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/5583868/blog/9866623