Apache Cassandra をリアルタイム機能ストアとして使用するためのガイド

これは、リアルタイム機能ストアとして Apache Cassandra を使用するための実用的なガイドです。リアルタイム AI と、Cassandra をフィーチャ ストアの優れたデータベースにする独自のパフォーマンスとコストの属性について説明し、フィーチャ ストアの基本とリアルタイム アプリケーションにおけるその役割について詳しく説明します。 Cassandra は、次のような大企業によってフィーチャー ストアとして使用されています。 およびNetflix;実際の条件下では、tp99 < 23ms でリアルタイム推論の機能を提供できます。 ユーバー このガイドは、いくつかの重要なセクションに分かれています。 Cassandra とその機能を紹介することから始めます。これにより、Cassandra はフィーチャー ストアの理想的な選択肢となります。次に、フィーチャ ストアとは何か、リアルタイム アプリケーションでどのように使用できるかなど、フィーチャ ストアの基本について説明します。その後、Cassandra を使用して機能ストアを作成するための実装の詳細を調べます。これには、データ モデリング、フィーチャの取り込みと取得、およびデータ更新の処理が含まれます。最後に、Cassandra をフィーチャ ストアとして使用して最適なパフォーマンスとスケーラビリティを確保するためのベスト プラクティスとヒントを提供します。これには、レイテンシ要件から推定パフォーマンス メトリック要件、リファレンス アーキテクチャとエコシステムの互換性までが含まれます。 このガイドでは、 または で .ここで取り上げるベスト プラクティスは、Google、Facebook、 、 、 と クラウドネイティブ インフラストラクチャで顧客にリアルタイムの AI エクスペリエンスを提供する方法について。 Cassandra を使用してリアルタイム機能ストレージを実装する方法に特に焦点を当てますが、アーキテクチャ ガイドラインは、Redis、MongoDB、Postgres など、あらゆるデータベース テクノロジに実際に適用されます。 リアルタイム機械学習のデータ サイエンスの側面 機能のライフサイクル管理の側面 フィーチャー ストア ユーバー AirBnB ネットフリックス リアルタイム AI とは リアルタイム AI は、 。従来、モデルのトレーニングとモデルに基づく推論 (予測) はバッチで行われてきました。通常は一晩中、または 1 日を通して定期的に行われていました。今日、最新の機械学習システムは、可能な限り正確な予測を提供するために、最新のデータの推論を実行します。 TikTok や Google などの少数の企業は、新しいデータが入ってくるたびにモデルのオンザフライ トレーニングを組み込むことで、リアルタイム パラダイムをさらに推し進めています。 最近のイベントに基づいて推論またはトレーニング モデルを作成します これらの推論の変化と、モデル トレーニングに発生する可能性が高い変化のために、特徴データ (ML モデルのトレーニングと推論の実行に使用されるデータ) の永続性も適応する必要があります。このガイドを読み終えると、Cassandra と、Cassandra 上に構築されたマネージド サービスである DataStax Astra DB がリアルタイム AI のニーズをどのように満たしているか、およびそれらを他のデータベース テクノロジーと組み合わせて使用する方法がより明確になります。モデルの推論とトレーニング用。 フィーチャー ストアとは フィーチャ ストアは、次のような機械学習 (ML) に固有のデータ システムです。 生データを特徴値に変換するデータ パイプラインを実行する 特徴データ自体を保存および管理し、 トレーニングと推論の目的で特徴データを一貫して提供します リアルタイム AI は、特にモデル サービスとモデル トレーニングのための機能の と に関して、Cassandra が独自に満たすことができる機能ストアに特定の要求を課します。 保存 提供 ベストプラクティス **機能提供のための低レイテンシ クエリを実装する リアルタイムの推論では、大規模な低レイテンシーで機能をアプリケーションに返す必要があります。典型的なモデルには、最大 10 個のエンティティにまたがる最大 200 個の機能が含まれます。リアルタイムの推論では、特徴の収集、軽量のデータ変換、および推論の実行 必要があります。 (実践者との会話でも確認されています) によると、フィーチャー ストアは 50 ミリ秒以内に推論を実行するアプリケーションにフィーチャーを返す必要があります。 に時間を割く 次の調査 通常、モデルには複数の論理エンティティにわたる「内部結合」が必要です。つまり、共通の値を共有する複数のテーブルの行の値を結合します。これは、低レイテンシー機能の提供に重大な課題をもたらします。食事を配達する時間を予測する Uber Eats の例を考えてみましょう。注文情報からデータを結合する必要があり、これにレストラン情報が結合され、さらにレストランの地域の交通情報が結合されます。この場合、2 つの内部結合が必要です (下の図を参照)。 Cassandra で内部結合を実現するには、挿入時にデータを非正規化するか、Cassandra に対して 2 つの連続したクエリを作成し、クライアント側で結合を実行します。非正規化によってデータベースにデータを挿入する際にすべての内部結合を実行することは可能ですが、モデルとテーブルの比率を 1:1 にすることは、非正規化されたテーブルの数が異常に多くなることを意味するため、現実的ではありません。ベスト プラクティスでは、フィーチャ ストアでは、非正規化と組み合わせて、内部結合に対して 1 ～ 2 の順次クエリを許可する必要があることが示唆されています。 リアルタイム ML パイプラインの要件を見積もるために使用できるパフォーマンス メトリックの概要を次に示します。 試験条件: 機能 = 200 テーブル (エンティティ) の数 = 3 内部結合の数 = 2 クエリ TPS : 5000 クエリ/秒 書き込み TPS : 500 レコード/秒 クラスタ サイズ : AstraDB* 上の 3 ノード レイテンシ パフォーマンスの概要 (ここでの不確実性は標準偏差です): tp95 = 13.2(+/-0.6) ミリ秒 tp99 = 23.0(+/-3.5) ミリ秒 tp99.9 = 63(+/- 5) ミリ秒 圧縮の効果: tp95 = 無視できる tp99、tp999 = ごくわずか、上で引用したシグマによって捕捉される 変更データ キャプチャ (CDC) の影響: tp50、tp95 ～ 3 ～ 5 ミリ秒 tp99 ～ 3 ミリ秒 tp999 ~ ごくわずか *以下のテストは、Cassandra のサーバーレス環境である DataStax の で行われました。 を使用して 3 つのメモに展開した場合、ユーザーは同様のレイテンシ パフォーマンスを期待する必要があります。 Astra DB の無料利用枠 次の推奨設定 レイテンシーに最も大きな影響を与えるのは、内部結合の数です。 3 つではなく 1 つのテーブルのみをクエリすると、tp99 は 58% 低下します。 2 つのテーブルの場合、29% 少なくなります。 tp95 はそれぞれ 56% と 21% 低下します。 Cassandra は水平方向にスケーラブルであるため、より多くの機能をクエリしても、平均レイテンシが大幅に増加することはありません。 最後に、すぐにレイテンシ要件を満たすことができない場合、Cassandra には 2 つの追加機能があります。高い書き込みスループット機能により非正規化データをサポートする (したがって内部結合を減らす) 機能と、データを選択的に複製する機能です。変更データ キャプチャによるメモリ キャッシュ (Redis など)。レイテンシを短縮するためのその他のヒントについては、こちらを参照してください。 機能変換のためのフォールト トレラントで低レイテンシの書き込みを実装する リアルタイム AI の重要なコンポーネントは、モデルの推論を行うために最新のデータを使用できることです。そのため、新しいデータをできるだけ早く推論に使用できるようにすることが重要です。同時に、エンタープライズ ユース ケースでは、データ損失が本番環境に重大な問題を引き起こす可能性があるため、書き込みが永続的であることが重要です。 * オブジェクト ストア (S3 や HIVE など) は、データ ウェアハウスなどの他の種類のバッチ指向システムに置き換えることができます。 低レイテンシの永続的な書き込みと低レイテンシの機能提供の間にはトレードオフがあります。たとえば、データを耐久性のない場所 (Redis など) にのみ保存することは可能ですが、生のイベントから大規模な再計算が必要になるため、本番環境で障害が発生すると、最新の機能を回復することが難しくなる可能性があります。 . 一般的なアーキテクチャでは、機能をオフライン ストア (Hive / S3 など) に書き込み、その機能をオンライン ストア (メモリ内キャッシュなど) に複製することを提案しています。これにより、機能の提供に耐久性と低レイテンシーが提供されますが、機能の書き込みにレイテンシーが発生するという犠牲が伴い、常に予測パフォーマンスが低下します。 Cassandra は、低レイテンシーの機能提供と低レイテンシーの「耐久性のある」機能の書き込みとの間の適切なトレードオフを提供します。 Cassandra に書き込まれたデータは通常、最低 3 回レプリケートされており、マルチリージョン レプリケーションをサポートしています。書き込みから可用性、読み取りまでの待機時間は、通常、ミリ秒未満です。その結果、機能をオンライン ストア (Cassandra) に直接保持し、オフライン ストアをバイパスすることで、アプリケーションは最近のデータにすばやくアクセスして、より正確な予測を行うことができます。同時に、CDC は、オンライン ストアからオフライン ストアまで、既存のツールを使用したバッチ トレーニングやデータ探索を可能にします。 予測キャッシュとパフォーマンス監視のために低レイテンシと書き込みを実装する 特徴変換の保存に加えて、パフォーマンス監視のために予測やその他の追跡データを保存する必要もあります。 予測の保存には、いくつかの使用例があります。 – このシナリオでは、 によって行われた予測をキャッシュするために使用されるデータベース。ストリーミング アーキテクチャは、推論にかかる時間が要求応答システムで許容できる時間を超えている場合に特に役立ちます。 予測ストア バッチ システムまたはストリーミング システム リアルタイム推論の予測出力を監視し、最終結果と比較することが必要になることがよくあります。これは、予測の結果と最終結果を記録するデータベースを持つことを意味します。 予測パフォーマンスの監視 Cassandra は、書き込みスループットが高いため、両方のユース ケースに適したストアです。 エラスティックな読み取りと書き込みのワークロードを計画する 1 秒あたりのクエリおよび書き込みトランザクションのレベルは、通常、システムを同時に使用しているユーザーの数によって異なります。その結果、時間帯や時期によってワークロードが変化する場合があります。クラスターを迅速にスケールアップおよびスケールダウンして、増加するワークロードをサポートできることが重要です。 Cassandra と Astra DB には、動的なクラスター スケーリングを可能にする機能があります。 書き込みワークロードに影響を与える可能性のある 2 つ目の側面は、機能変換ロジックに変更がある場合です。書き込みワークロードが急増すると、Cassandra は、リアルタイムの推論を実行するために通常許容されるデータの一貫性よりも、低レイテンシーのクエリを維持し、TPS を書き込むことを自動的に優先します。 低レイテンシのマルチリージョン サポートを実装する リアルタイム AI がすべてのアプリで普及するにつれて、推論が行われる場所のできるだけ近くで特徴データを利用できるようにすることが重要です。これは、推論を行うアプリケーションと同じリージョンにフィーチャ ストアを配置することを意味します。リージョン間でフィーチャ ストアのデータをレプリケートすると、その機能を確保するのに役立ちます。さらに、機能の生成に使用される生データではなく、機能のみを複製することで、クラウドの下り料金が大幅に削減されます。 Astra DB は、すぐに使用できるマルチリージョン レプリケーションをサポートしており、レプリケーション レイテンシはミリ秒単位です。すべての未加工のイベント データを 1 つのリージョンにストリーミングし、特徴生成を実行し、特徴を保存して他のすべてのリージョンに複製することをお勧めします。 理論的には、各リージョンでフィーチャを生成することでレイテンシの利点をいくらか達成できますが、多くの場合、イベント データは他のリージョンからの生のイベント データと結合する必要があります。正確さと効率の観点から、すべてのイベントを 1 つのリージョンに送信して、ほとんどのユースケースで処理する方が簡単です。一方、モデルの使用が地域のコンテキストで最も理にかなっており、ほとんどのイベントが地域固有のエンティティに関連付けられている場合は、機能を地域固有のものとして扱うことが理にかなっています。リージョン間でレプリケートする必要があるイベントはすべて、グローバル レプリケーション戦略を使用してキースペースに配置できますが、理想的には、これはイベントの小さなサブセットである必要があります。特定の時点で、イベント テーブルをグローバルにレプリケートすることは、特徴計算のためにすべてのイベントを 1 つのリージョンに単純に送信するよりも効率が低下します。 費用対効果が高く、低遅延のマルチクラウド サポートを計画する マルチクラウドのサポートにより、アプリケーションの回復力が向上し、顧客は低価格で交渉できるようになります。 DynamoDB などの単一クラウドのオンライン ストアでは、機能を取得するためのレイテンシーが増加し、データの送信コストが大幅に増加しますが、単一のクラウド ベンダーへのロックインも発生します。 クラウド間でのレプリケーションをサポートするオープンソース データベースは、パフォーマンス コストの最適なバランスを提供します。エグレスのコストを最小限に抑えるには、イベントと機能の生成を 1 つのクラウドに統合し、機能データを他のクラウド全体のオープンソース データベースに複製する必要があります。これにより、エグレス コストが最小限に抑えられます。 本番モデルのバッチ トレーニングとリアルタイム トレーニングの両方を計画する モデルを構築するためのバッチ処理インフラストラクチャは、新しいモデルの構築とテスト、および本番用のモデルの構築という 2 つのユース ケースに使用されます。したがって、通常、トレーニングの目的で特徴データを低速のオブジェクト ストアに格納するだけで十分でした。ただし、新しいモデル トレーニング パラダイムには、リアルタイムまたはほぼリアルタイムでのモデルの更新 (リアルタイム トレーニング) が含まれます。これは「オンライン学習」として知られています (例: )。リアルタイム トレーニングのアクセス パターンは、推論と従来のバッチ トレーニングの中間にあります。スループットのデータ要件は推論よりも高くなりますが (通常は単一行のルックアップにアクセスしないため)、テーブル全体のスキャンを伴うバッチ処理ほど高くはありません。 TikTok の Monolith Cassandra は、(適切なデータ モデルを使用して) 1 秒あたり数十万の TPS 評価をサポートでき、ほとんどのリアルタイム トレーニングのユース ケースに十分なスループットを提供できます。ただし、ユーザーがオブジェクト ストアからのリアルタイム トレーニングを維持したい場合、Cassandra はオブジェクト ストレージへの CDC を介してこれを実現します。バッチ トレーニングの場合、CDC はデータをオブジェクト ストレージにレプリケートする必要があります。 や PyTorch などの機械学習フレームワークは、オブジェクト ストレージからの ML モデルの並列トレーニング用に特に最適化されていることに注意してください。 Tensorflow 「オンライン学習」のより詳細な説明については、Chip Huyuen の に関する説明、または 。 継続学習 Gomes らのこのテクニカル ペーパーを参照してください。アル Kappa アーキテクチャのサポート 、オンライン/オフライン スキューによるコストとデータ品質の問題により、徐々に Lambda アーキテクチャに取って代わりつつあります。多くの記事で、個別のバッチ計算レイヤーとリアルタイム計算レイヤーから単一のリアルタイム レイヤーに移行する利点について説明していますが、サービング レイヤーの設計方法についてはあまり説明されていません。 Kappa アーキテクチャは 機能の生成に Kappa アーキテクチャを使用すると、いくつかの新しい考慮事項が生じます。 更新機能は大量に更新されており、データベースへの大量の書き込みが発生する可能性があります。これらの大規模な更新中にクエリの遅延が発生しないようにすることが重要です。 サービス レイヤーは、推論用の低レイテンシ クエリや、モデルのバッチ トレーニング用の高 TPS クエリなど、さまざまな種類のクエリをサポートする必要があります。 Cassandra は、次の方法で Kappa アーキテクチャをサポートします。 Cassandra は書き込み用に設計されています。書き込みの流入が増加しても、クエリのレイテンシが大幅に短縮されるわけではありません。 Cassandra は、強い整合性ではなく結果整合性を使用して書き込みを処理することを選択します。これは通常、予測を行うために受け入れられます。 CDC を使用すると、トレーニング用のオブジェクト ストレージと推論用のメモリ内ストレージにデータをレプリケートできます。 CDC は、Cassandra へのクエリのレイテンシーにほとんど影響を与えません。 Lambda アーキテクチャのサポート ほとんどの企業は、リアルタイム パイプラインとは別のバッチ レイヤー パイプラインを備えた Lambda アーキテクチャを採用しています。このシナリオには、いくつかのカテゴリの機能があります。 リアルタイムでのみ計算され、トレーニングのためにバッチ特徴ストアに複製される特徴 バッチでのみ計算され、リアルタイム フィーチャ ストアに複製されるフィーチャ 特徴は最初にリアルタイムで計算され、次にバッチで再計算されます。その後、不一致はリアルタイム ストアとオブジェクト ストアの両方で更新されます。 ただし、このシナリオでは、DataStaxは次の図で説明されているアーキテクチャを推奨しています: 理由は次のとおりです。 Cassandra は、読み取りレイテンシーにほとんど影響を与えずにデータのバッチ アップロードを行うように設計されています 単一の記録システムを持つことで、データがフィーチャ ストアとオブジェクト ストアに分割されている場合に比べて、データ管理が大幅に容易になります。これは、最初にリアルタイムで計算され、次にバッチで再計算される特徴にとって特に重要です。 Cassandra から CDC 経由でオブジェクト フィーチャ ストアにデータをエクスポートする場合、データ エクスポートをバッチ トレーニング用に最適化できます ( )。これにより、トレーニング インフラストラクチャのコストが大幅に削減されます。 Facebook などの企業で使用される一般的なパターン 既存のパイプラインを更新できない場合、または機能を最初にオブジェクト ストアに配置する必要がある特定の理由がある場合は、Cassandra 機能ストアとオブジェクト ストア間の双方向の CDC パスを使用することをお勧めします。以下に示します。 既存の ML ソフトウェア エコシステムとの互換性を確保する Cassandra を機能ストアとして使用するには、推論とトレーニングを実行する機械学習ライブラリと、機能変換を実行するデータ処理ライブラリという、エコシステムの 2 つの部分と統合する必要があります。 機械学習の最も一般的な 2 つのフレームワークは、TensorFlow と PyTorch です。 Cassandra には Python ドライバーがあり、Cassandra データベースから機能を簡単に取得できます。つまり、複数の機能を並行して取得できます ( )。機能変換を実行するための 2 つの最も一般的なフレームワークは、Flink と です。 Cassandra では、 と の両方のコネクタを使用できます。実践者は、 と 、および Cassandra のチュートリアルを使用できます。 このサンプル コードを参照してください Spark Structured Streaming Flink Spark Flink Spark 構造化ストリーミング FEAST などのオープン ソース機能ストアにも、Cassandra 用の と あります。 コネクタ チュートリアルが コストを決定するためのクエリ パターンとスループットを理解する フィーチャ ストアとしての Cassandra の読み取りクエリの数は、受信する推論リクエストの数によって異なります。特徴データが複数のテーブルに分割されていると仮定するか、データを並行してロードできる場合、これにより、実行可能なリアルタイム推論間のファンアウトの見積もりが得られます。たとえば、10 個の個別のテーブル内の 10 個のエンティティにまたがる 200 個の特徴により、リアルタイムの推論と Cassandra へのクエリの比率は約 1:10 になります。 実行される推論の数の計算は、推論トラフィック パターンによって異なります。たとえば、 関連する特徴が変化するたびに推論が実行されるため、推論の総数は特徴データが変化する頻度に依存します。 「request-reply」設定で推論が実行される場合、推論はユーザーが要求したときにのみ実行されます。 「ストリーミング推論」の場合、 バッチおよびリアルタイムの書き込みパターンを理解してコストを決定する 書き込みスループットは、主にフィーチャの変更頻度によって決まります。非正規化が発生すると、これも書き込まれる機能の数に影響を与える可能性があります。その他の書き込みスループットに関する考慮事項には、バッチまたはストリーミング推論シナリオのキャッシュ推論が含まれます。 結論 リアルタイム ML パイプラインを設計するときは、フィーチャ ストアのパフォーマンスとスケーラビリティに特別な注意を払う必要があります。この要件は、Cassandra などの NoSQL データベースによって特に十分に満たされます。 Cassandra または を使用して独自のフィーチャー ストアを立ち上げ、 を使用して を試してみてください。 AstraDB Cassandra コネクタ Feast.dev