VLDB 2023 賞が発表、清華大学、4Paradigm、NUS の共同論文が最優秀産業論文賞を受賞

VLDB 2023 国際会議がカナダのバンクーバーで無事開催されました。 VLDB 会議は、データベース分野で長い歴史を持つ 3 つのトップ会議の 1 つであり、正式名称は International Large-Scale Database Conference です。各カンファレンスは、データベース研究の現在の最先端の方向性、業界の最新技術、さまざまな国の研究開発レベルを展示することに重点を置いており、世界トップの研究機関からの応募が集まります。

カンファレンス システムの革新性、完全性、実験計画などに関して非常に高い要件が求められます。 VLDB の論文採択率は一般に約 18% と低く、貢献度の高い論文のみが採択される可能性があります。今年も競争はさらに激化している。公式データによると、今年はスタンフォード大学、カーネギーメロン大学、Microsoft Research、VMware Research、Meta、その他の世界的に有名な大学、研究機関、テクノロジー大手からの論文を含む、合計 9 件の VLDB 論文が最優秀論文賞を受賞しました。

その中で、4Paradigm、清華大学、シンガポール国立大学が共同で完成させた論文「FEBench: A Benchmark for Real-Time Relational Data Feature Extraction」が、最優秀産業論文の次点賞を受賞しました。

この論文は、4Paradigm、清華大学、シンガポール国立大学の共同研究です。この論文では、機械学習に基づくリアルタイムの意思決定システムを評価するために使用される、業界における実際のシナリオの蓄積に基づくリアルタイム特徴計算テスト ベンチマークを提案しています。

次のリンクで「論文を表示」をクリックしてください: https://github.com/decis-bench/febench/blob/main/report/febench.pdf

##プロジェクトアドレス: https://github.com/decis-bench/febench 書き換える必要がある内容は次のとおりです。プロジェクトのアドレスは https://github.com/decis-bench/febench

• プロジェクトの背景

• 人工知能に基づく意思決定システムは、多くの業界シナリオで広く使用されています。その中には、金融業界の不正行為防止や小売業界のリアルタイムのオンライン レコメンデーションなど、リアルタイム データに基づく計算が含まれるシナリオが数多くあります。機械学習によって駆動されるリアルタイム意思決定システムには、通常、機能とモデルという 2 つの主要なコンピューティング リンクが含まれます。ビジネス ロジックの多様性と、オンラインでの低遅延および高同時実行性の要件により、特徴量の計算が意思決定システム全体のボトルネックになることがよくあります。したがって、利用可能で安定した効率的なリアルタイム特徴計算プラットフォームを構築するには、多くのエンジニアリング実践が必要です。以下の図 1 は、不正行為対策アプリケーションの一般的なリアルタイム特徴計算シナリオを示しています。オリジナルのカードスワイプ記録テーブルに基づいて特徴量計算を実行することで、新しい特徴量（過去 10 秒間のカードスワイプ量の最大/最小/平均など）が生成され、リアルタイムで下流モデルに入力されます。推論

書き直された内容: 図 1. 不正行為対策アプリケーションにおけるリアルタイム特徴計算の応用

一般的に言えば、リアルタイム特徴計算プラットフォームは、次の 2 つの基本要件を満たす必要があります:

オンラインとオフラインの一貫性: 機械学習アプリケーションは通常、オンラインとオンラインの 2 つのプロセスに分けられます。履歴データと、データからのリアルタイム推論に基づくトレーニング。したがって、オンラインとオフラインの最終的なビジネス結果の一貫性を確保するには、オンラインとオフラインの特徴計算ロジックの一貫性を確保することが重要です。

オンライン サービスの効率: オンライン サービスは、リアルタイムのデータと計算を目的としており、低遅延、高同時実行性、高可用性のニーズを満たします。

#図 2. リアルタイム特徴量計算プラットフォームのアーキテクチャとワークフロー

• 図 2 に示すように上には、一般的なリアルタイム機能コンピューティング プラットフォームのアーキテクチャが 1 つリストされています。簡単に言うと、主にオフラインの計算エンジンとオンラインの計算エンジンが含まれており、オフラインとオンラインの計算ロジックの一貫性を確保することが重要なポイントとなります。現在、市場には、Flink などの汎用システムや、OpenMLDB、Tecton、Feast などの特殊システムなど、上記の要件を満たし、完全なリアルタイム特徴コンピューティング プラットフォームを形成できる機能プラットフォームが数多く存在します。しかし、業界には現在、そのようなシステムのパフォーマンスを厳密かつ科学的に評価するためのリアルタイム特性を重視した専用のベンチマークがありません。この要求に応えて、この文書の著者は、リアルタイム機能コンピューティング ベンチマーク テストである FEBench を構築しました。これは、機能コンピューティング プラットフォームのパフォーマンスを評価し、全体的な遅延、ロングテール 遅延、および同時実行パフォーマンスを分析するために使用されます。システム。

技術原則

FEBench のベンチマーク構築には、主に 3 つの作業側面が含まれます。データ セットの収集、クエリで生成されたコンテンツの書き換えが必要な場合、およびコンテンツの書き換えが必要な場合です。書き換えられる場合は、適切なテンプレートを選択してください

データセット コレクション

研究チームは、リアルタイム特徴計算シナリオで使用できる合計 118 のデータ セットを収集しました。これらのデータ セットは、Kaggle、Tianchi、UCI から提供されています。 ML、KiltHub およびその他の公開ソース: データ Web サイトと 4Paradigm 内部公開データは、金融、小売、医療、製造、運輸、その他の業界シナリオなど、業界の一般的な使用シナリオをカバーしています。研究チームは、以下の図 3 に示すように、収集したデータ セットをテーブルの数とデータ セットのサイズに応じてさらに分類しました。

書き換えた内容: FEBench のテーブル数とデータセットのサイズのグラフは次のとおりです:

クエリ生成されたコンテンツは書き換える必要があります

データ セットの数が多いため、データ セットごとに特徴抽出を手動で生成する計算ロジックのワークロードは非常に膨大であるため、研究者はAutoCross (参考資料: AutoCross: 実世界アプリケーションにおける表形式データの自動特徴交差) や、収集されたデータ セットのクエリを自動的に生成するその他の自動機械学習テクノロジなどのツール。 FEBench の機能選択とクエリ生成コンテンツを書き直す必要があります。これには、次の 4 つのステップが含まれます (下の図 4 を参照):

• データ セット内のメイン テーブルを識別する (ストリーミング データ ) と初期化用の補助テーブル (静的/追加可能/スナップショット テーブルなど) を格納します。続いて、主テーブルと副テーブルの類似した名前またはキー関係を持つ列が分析され、異なる機能操作モードに対応する列間の 1 対 1/1 対多の関係が列挙されます。

• 列の関係を特徴演算子にマップします。

• すべての候補特徴を抽出した後、ビーム検索アルゴリズムを使用して効果的な特徴セットを繰り返し生成します。

• 選択された機能は、意味的に同等の SQL クエリに変換されます。

#図 4. FEBench でのクエリ生成プロセス

内容を書き換える場合は、適切なテンプレートを選択する必要があります

各データ セットのクエリを生成した後、研究者らはさらにクラスタリング アルゴリズムを使用して、代表的なクエリをクエリ テンプレートとして選択し、同様のタスクの繰り返しテストを削減しました。 118 個の収集されたデータ セットと特徴クエリについて、DBSCAN アルゴリズムを使用してこれらのクエリをクラスタ化します。具体的な手順は次のとおりです。

• 各クエリの特徴を 5 つの部分に分割します。列の数、クエリ演算子の合計数、複雑な演算子の頻度、ネストされたサブクエリのレベル数、および時間ウィンドウ内の最大のタプルの数。特徴エンジニアリング クエリには通常、時間枠が含まれ、クエリの複雑さはバッチ データ サイズの影響を受けないため、データセット サイズはクラスタリング機能の 1 つとして含まれません。

• ロジスティック回帰モデルを使用して、モデルの入力として特徴を使用し、モデルの出力として特徴クエリの実行時間を使用して、クエリ特徴とクエリ実行特性の間の関係を評価します。モデル。クラスタリング結果に対するさまざまな特徴の重要性は、各特徴の回帰重みをクラスタリング重みとして使用することによって考慮されます。

• 重み付けされたクエリ特徴に基づいて、DBSCAN アルゴリズムを使用して、複数のクラスターへの機能クエリ。

#次のグラフは、さまざまな考慮指標の下での 118 個のデータ セットの分布を示しています。図 (a) は、出力列の数、クエリ演算子の総数、ネストされたサブクエリ レベルの数などの統計的性質の指標を示し、図 (b) は、クエリ実行時間との相関が最も高い指標を示しています。集計操作の数、ネストされたサブクエリ レベルの数、および時間ウィンドウの数

図 5. クラスター分析を通じて 6 つのクラスターを取得した 118 個の特徴クエリと生成されたクエリ テンプレート ( Q0 -5)

最後に、クラスタリングの結果に基づいて、118 個の特徴クエリが 6 つのクラスターに分割されました。各クラスターについて、重心に近いクエリが候補テンプレートとして選択されます。さらに、さまざまなアプリケーション シナリオの人工知能アプリケーションにはさまざまな特徴エンジニアリング要件がある可能性があることを考慮して、さまざまな特徴エンジニアリング シナリオをより適切にカバーできるように、各クラスターの重心付近のさまざまなシナリオからクエリを選択するようにしてください。最後に、交通、ヘルスケア、エネルギー、販売、金融取引など、さまざまなシナリオに適した 6 つのクエリ テンプレートが 118 の機能クエリから選択されました。これら 6 つのクエリ テンプレートは、最終的に FEBench のコア データ セットとクエリを構成し、リアルタイム特徴計算プラットフォームのパフォーマンス テストに使用されます。

書き直す必要がある内容は次のとおりです: ベンチマーク評価 (OpenMLDB および Flink)

この研究では、研究者らは FEBench を使用して、Flink と OpenMLDB という 2 つの典型的な産業システムをテストしました。 Flink は一般的なバッチおよびストリーム処理の一貫したコンピューティング プラットフォームであるのに対し、OpenMLDB は専用のリアルタイム機能コンピューティング プラットフォームです。研究者たちは、テストと分析を通じて、各システムの長所と短所、およびその背後にある理由を発見しました。実験結果は、アーキテクチャ設計の違いにより、Flink と OpenMLDB の間にパフォーマンスの違いがあることを示しています。同時に、これはターゲット システムの機能を分析する際の FEBench の重要性も示しています。要約すると、研究の主な結論は次のとおりです。

• Flink は、待ち時間が OpenMLDB より 2 桁遅いです (図 6)。研究者らは、このギャップの主な理由は、2 つのシステム アーキテクチャの実装方法の違いにあると分析しており、OpenMLDB は、リアルタイム特徴計算専用システムとして、メモリベースの 2 層ジャンプ テーブルや時間的に最適化されたその他のデータ構造を備えています。最終的に、Flink と比較すると、特徴量計算シナリオにおいて明らかにパフォーマンス上の利点があります。もちろん、汎用システムである Flink は、OpenMLDB よりも適用可能なシナリオの範囲が広いです。

#図 6. OpenMLDB と Flink 間の TP-50 レイテンシーの比較

• #OpenMLDB には明らかなロングテール レイテンシの問題が見られますが、Flink のテール レイテンシはより安定しています (図 7)。次の数値は、OpenMLDB および Flink のそれぞれの TP-50 に対して正規化されたレイテンシー パフォーマンスを示しており、絶対的なパフォーマンスの比較を表すものではないことに注意してください。 次のように書き直されました: OpenMLDB にはテール レイテンシーに関する明らかな問題がありますが、Flink のテール レイテンシーはより安定しています (図 7 を参照)。次の数値は、絶対的なパフォーマンスの比較ではなく、レイテンシ パフォーマンスを TP-50 での OpenMLDB と Flink のパフォーマンスにそれぞれ正規化したものであることに注意してください。
  #図 7. OpenMLDB と Flink のテール レイテンシの比較 (それぞれの TP-50 レイテンシに正規化)

研究者らは、上記のパフォーマンス結果をさらに詳しく調べました。

実行時間に基づいて逆アセンブルおよび分析します。マイクロアーキテクチャの指標には、命令の完了、誤った分岐の予測、バックエンドの依存関係、フロントエンドの依存関係などが含まれます。クエリ テンプレートが異なれば、微細構造レベルでパフォーマンスのボトルネックも異なります。図 8 に示すように、Q0 ～ Q2 のパフォーマンスのボトルネックは主にフロントエンドに依存しており、全体の実行時間の 45% 以上を占めています。この場合、実行される操作は比較的単純で、ほとんどの時間はユーザー要求の処理と特徴抽出命令の切り替えに費やされます。第 3 四半期から第 5 四半期にかけて、バックエンドの依存関係 (キャッシュの無効化など) と命令の実行 (より複雑な命令を含む) がより重要な要素になります。 OpenMLDB は、ターゲットを絞った最適化によってパフォーマンスをさらに向上させます

• 図 8 は、OpenMLDB と Flink のマイクロアーキテクチャ インジケーター分析を示しています

実行プランの分析: Q0 を例として、以下の図 9 は Flink と OpenMLDB の実行プランの違いを比較しています。 Flink の計算演算子は最も時間がかかりますが、OpenMLDB はウィンドウ処理を最適化し、カスタム集計関数などの最適化手法を使用することで実行レイテンシを短縮します。

• 9 番目の図は、実行計画に関する OpenMLDB と Flink の比較を示しています (Q0)

#ユーザーが上記の実験結果を再現したい場合、またはローカル システムでベンチマーク テストを実施したい場合 (論文の著者はコミュニティでテスト結果を提出して共有することも推奨しています)、詳細については FEBench プロジェクトのホームページにアクセスしてください。

FEBench プロジェクト: https://github.com/decis-bench/febench

Flink プロジェクト: https://github.com /apache/flink

• OpenMLDB プロジェクト: https://github.com/4paradigm/OpenMLDB

以上がVLDB 2023 賞が発表、清華大学、4Paradigm、NUS の共同論文が最優秀産業論文賞を受賞の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。