リアルタイムAI/MLの機能ストア：ベンチマーク、アーキテクチャ、ケーススタディ

不正防止や推奨などのリアルタイムの人工知能/機械学習（AI / ML）のユースケースが増加しており、機能ストアはそれらを本番環境に正常に展開する上で重要な役割を果たします。人気のあるオープンソースの機能ストアFeastによると、ユーザーがコミュニティSlackで尋ねる最も一般的な質問の1つは、次のとおりです。 スケーラブル/パフォーマンス 饗宴ですか？ これは、リアルタイムAI / MLの機能ストアの最も重要な特性が、オンラインストアからオンライン予測またはスコアリングのMLモデルへの機能提供速度であるためです。成功する機能ストアは、厳しいレイテンシ要件（ミリ秒単位で測定）を一貫して（p99と考えて）大規模に（ギガバイトからテラバイトサイズのデータ​​セットで1秒あたり最大数百万のクエリ）満たすと同時に、所有権と高精度。

この投稿でわかるように、オンライン機能ストアの選択と機能ストアのアーキテクチャは、パフォーマンスと費用対効果を決定する上で重要な役割を果たします。多くの場合、企業はオンライン機能ストアを選択する前に、徹底的なベンチマークを実行して、アーキテクチャまたはオンライン機能ストアのどちらを選択するかが最もパフォーマンスが高く、費用効果が高いかどうかを確認します。この投稿では、リアルタイムAI / MLユースケースの展開に成功した企業によって構築されたDIY機能ストアと、オープンソースおよび商用機能ストアの両方のアーキテクチャとベンチマークを確認します。始めましょう。

1。オープンソースの饗宴

最初にベンチマークデータを見てから、Feastオープンソース機能ストアのデータアーキテクチャを見てみましょう。 Feastは最近、さまざまなオンラインストア（RedisとGoogle CloudDataStoreとAWSDynamoDB）を使用した場合の機能提供レイテンシーを比較するためのベンチマークを実行しました。また、機能を抽出するためにさまざまなメカニズム（Java gRPCサーバー、Python HTTPサーバー、ラムダ関数など）を使用する速度を比較しました。完全なベンチマーク設定とその結果は、このブログ投稿にあります。結論：Feastは、Java gRPCサーバーを使用し、Redisをオンラインストアとして使用した場合に、これが群を抜いて最もパフォーマンスが高いことを発見しました。

上の図では、オンライン住宅ローン会社Better.comが、オープンソースのFeast機能ストアを使用してリードスコアリングランキングシステムを実装した例を示しています。 Better.comのシニアソフトウェアエンジニアであるVitalySergeyによって提示されたように、機能はオフラインストア（S3、Snowflake、およびRedshift）からオンラインストア（Redis）に具体化されています。それに加えて、機能はストリーミングソース（Kafkaトピック）からオンラインストアにも取り込まれます。 Feastは最近、（バッチデータソースに加えて）ストリーミングデータソースのサポートを追加しました。これは現在、Redisでのみサポートされています。ストリーミングデータソースのサポートは、リアルタイムのAI / MLユースケースにとって非常に重要です。これらのユースケースは、新鮮なライブデータに依存しているためです。

例として、Better.comのリードスコアリングのユースケースでは、新しいリードが1日を通して継続的に取り込まれています。機能はさまざまなソースから提供され、エンティティ（リード）とそれらのスコアリングに使用される機能の両方が常に更新されるため、リードはランク付けされ、再ランク付けされます。新しいリードがあるとすぐに、モデルによって取り込まれ、スコアが付けられます。オンラインストアに取り込まれると同時に、すぐに再ランク付けすることをお勧めします。 Better.comのリードは48時間後に期限切れになります。これは、存続時間（TTL）を48時間に設定するだけで、Redisオンラインストアに実装され、エンティティ（リード）と関連する特徴ベクトルを48時間後に期限切れにします。そのため、機能ストアは自動的にクリーンアップされ、貴重なオンラインストレージを使用する古いエンティティや機能はありません。

Feastのもう1つの興味深い実装は、Microsoft AzureFeatureStoreです。ここでそのアーキテクチャを見ることができます。低レイテンシのリアルタイムAI/MLユースケース向けに最適化されたAzureクラウド上で実行され、バッチソースとストリーミングソースの両方をサポートし、Azure Data＆AIエコシステムへの統合をサポートします。機能は、バッチソース（Azure SynapseサーバーレスSQL、Azureストレージ/ ADLS）とストリーミングソース（Azure Event Hub）の両方からオンラインストアに取り込まれます。既にAzureにデプロイされているか、Azureエコシステムに精通している場合は、 この機能ストアはあなたにぴったりかもしれません。オンラインストアでは、AzureRedis用のAzureCacheを使用し、Azure Redisのエンタープライズ層では、最大99.999％の可用性でグローバルに分散されたキャッシュを作成するためのアクティブ-アクティブジオ複製が含まれています。さらに、エンタープライズフラッシュ階層を使用して、メモリ内（DRAM）とフラッシュメモリ（NVMeまたはSSD）の両方を使用してデータを格納する階層型メモリアーキテクチャでRedisを実行することにより、さらにコストを削減できます。

2。 Wix DIY機能ストア–MLOpsプラットフォームの要

以下は、リアルタイムAI/MLのユースケースを実装するための異なるアーキテクチャです。これは、人気のあるWebサイト構築プラットフォームWixの機能ストアアーキテクチャです。これは、推奨事項、チャーンとプレミアムの予測、ランキング、スパム分類などのリアルタイムのユースケースに使用されます。 Wixは2億人を超える登録ユーザーにサービスを提供しており、そのうちのごく一部が常に「アクティブユーザー」です。これは、機能ストアの実装方法に大きな影響を与えました。それを見てみましょう。

以下の情報は、RanRomanoがWixでMLエンジニアリングを率いたときに提供されたTechTalkプレゼンテーションに基づいています。 Wix機能ストアに保存されているデータの90％以上はクリックストリームであり、MLモデルはウェブサイトごとまたはユーザーごとにトリガーされます。 Ranは、リアルタイムのユースケースでは、レイテンシーが大きな問題であると説明しています。また、本番環境のユースケースの中には、ミリ秒以内に特徴ベクトルを抽出する必要があるものもあります。

生データは、AWSのParquetファイルのS3バケットに保存され、ビジネスユニット（「編集者」、「レストラン」、「予約」など）ごとに、次に日付ごとに分割されます。これは、WixMLプラットフォームよりも何年も前から存在していたデータアナリストが使用するWixデータプラットフォームの一部です。 デイリービルド Spark、SQLを使用したバッチプロセス（数分から数時間かかります）すべてのユーザーの履歴機能がS3から抽出され、ユーザーによってピボットおよび集約され、オフラインストア（Apache Hbase）に取り込まれます。これにより、「ユーザー」によるユーザーの履歴の検索がはるかに高速になります。ユーザーが現在アクティブであることをシステムが検出すると、「ウォームアップ」 プロセスがトリガーされ、そのユーザーの機能がオンラインストア（Redis）に読み込まれます。オンラインストア（Redis）は、アクティブユーザーのユーザー履歴のみを保持するため、オフラインストアよりもはるかに小さくなります。この「ウォームアップ」プロセスには数秒かかる場合があります。そして最後に、オンライン機能ストアの機能は、ユーザーからの各イベントごとにストリーミングソースから直接新鮮なライブリアルタイムデータを使用して継続的に更新されます（Apache Stormを使用）。

このタイプのアーキテクチャは、Feastアーキテクチャと比較して書き込みと読み取りの比率が低く、すべてのユーザーの機能ではなく、アクティブユーザーの機能のみをオンラインストアに保存するため、マテリアライゼーションとオンラインストレージの点で非常に効率的です。アクティブユーザーはWix内のすべての登録ユーザーのごく一部を占めるため、これは大幅な節約になります。ただし、これには代償が伴います。オンラインストアから機能を取得するのは非常に高速ですが、ミリ秒以内に、機能がオンラインストア内にすでに存在する場合に限ります。競合状態のため、ウォームアッププロセスには数秒かかるため、ユーザーがアクティブになると、関連する機能を読み込むのに十分な速度ではありません。したがって、そのユーザーのスコアリングまたは予測は単に失敗します。これは、ユースケースがクリティカルフローの一部でない限り、またはトランザクションの承認や不正の防止などのミッションクリティカルなユースケースの場合は問題ありません。このタイプのアーキテクチャはWixにも非常に固有であり、特定の時点でアクティブなユーザーはごく一部のユーザーのみです。

3。コマーシャルフィーチャーストアテクトン

それでは、営利企業の機能ストアであるTectonのアーキテクチャを見てみましょう。次の図に示すように、バッチデータソースとストリーミングデータソースに加えて、Tectonは「すぐに使える」リアルタイムデータソースもサポートしています。これらは「リアルタイム機能」とも呼ばれます 」または「リアルタイム」変換。リアルタイムの特徴は、推論要求でのみ計算できます。たとえば、疑わしいトランザクションのサイズと最後のトランザクションのサイズの違い。したがって、上記のオープンソースのFeastを使用するBetter.comの場合、Better.comは独自にリアルタイム機能のサポートを開発しました。 Tectonフィーチャーストアを使用すると、フィーチャーストアによって既にネイティブにサポートされているため、これを実装するのは簡単です。 FeastやWixの機能ストアと同様に、Tectonもレジストリで機能を定義するため、オフラインストアとオンラインストアの両方で論理定義が1回定義されます。これにより、トレーニングとサービスのスキューが大幅に削減され、本番環境でもMLモデルの高精度が保証されます。

オフラインストア、オンラインストア、ベンチマークの選択に関して、オフライン機能ストアの場合、TectonはS3をサポートし、オンラインストアの場合、Tectonは顧客にDynamoDBとRedisEnterpriseCloudのどちらかを選択できるようになりました。最近のプレゼンテーションで、TectonのCTOであるKevin Stumpfは、同社が最近実施したベンチマークに基づいて、オンライン機能ストアを選択する方法に関するヒントを提供しました。 Tectonは、レイテンシとスループットのベンチマークに加えて、オンラインストアのコストもベンチマークしました。何でこれが大切ですか？高スループットまたは低遅延のユースケースの場合、オンラインストアのコストは、MLOpsプラットフォーム全体の総所有コストの大部分を占める可能性があるため、コストを大幅に節約できます。

Tectonのベンチマークの要点は、Tectonのユーザーに典型的な高スループットのユースケースでは、Redis EnterpriseはDynamoDBと比較して3倍高速であり、同時に14倍安価であったということです。

それで、あなたが尋ねるかもしれないキャッチは何ですか？ユースケースが1つだけで、スループットが高くないか一貫性がなく、厳密なレイテンシ要件がない場合は、DynamoDBを使用できます。 Tectonのベンチマークの詳細と結果については、こちらをご覧ください。

4。コマーシャルフィーチャーストアQwakを使用したLightricks

以下は、機能ストアアーキテクチャの別の例です。これは、商用機能ストアQwakに基づいてLightricksによって使用されます。 Lightricksは、特に自撮り写真編集アプリFacetuneで知られるビデオおよび画像編集モバイルアプリを開発するユニコーン企業です。レコメンデーションシステムに機能ストアを使用しています。

上の図に示すように、Tectonと同様に、Qwak機能ストアはバッチ機能、ストリーミング機能、リアルタイム機能の3種類の機能ソースをサポートしています。

Qwak機能ストアでは、機能の機能ストアへの具体化は、オフラインストア（S3のParquetファイルを使用）とオンラインストア（Redisを使用）の両方の生データソースから直接行われることに注意してください。これは、オンラインストアの具体化がバッチソースのオフラインストアからオンラインストアに行われるWix、Feast、またはTectonの機能ストアの例とは異なります。これには、機能の変換ロジックがトレーニングフローとサービングフロー全体で統合されるだけでなく（上記のFeast、Wix、Tectonの機能ストアと同様）、実際の変換または機能の計算が均一に行われ、さらに減少するという利点があります。トレーニング-サービングスキュー。生データから直接オフラインとオンラインの統合データパイプラインを使用することで、本番環境でさらに高い精度を確保できる可能性があります。このプレゼンテーションでは、Qwakの機能ストアのアーキテクチャとコンポーネントの詳細を確認できます。

概要

この投稿では、リアルタイムAI/MLのいくつかの機能ストアのベンチマークとアーキテクチャの主要なハイライトを確認しました。 1つ目はOpenSourceFeast、2つ目はDIY Wixフィーチャーストア、3つ目はTecton、4つ目はQwakです。また、これらの企業が実行したベンチマークのいくつかのハイライトを確認して、どのオンラインストアが最もパフォーマンスが高く、最も費用効果が高いかを確認しました。また、オンラインストアから機能を抽出するために使用するメカニズムまたは機能サーバーについても検討しました。アーキテクチャ、サポートされている機能の種類、選択したコンポーネントによって、機能ストアのパフォーマンスとコストに大きな違いがあることがわかりました。

元々はで公開されました KDnuggets 。