コンセプト
このセクションでは、 Databricksで特徴量テーブルを使用する際に役立つ概念について説明します。
Feature Store
Feature Storeは、データサイエンティストが特徴量を見つけて共有できるようにする一元化されたリポジトリであり、特徴値を計算するために使用されるのと同じコードがモデル トレーニングと推論に使用されるようにします。 Databricks でのFeature Storeの実装は、ワークスペースが Unity Catalog に対して有効になっているかどうかによって異なります。 Unity Catalogが有効になっているワークスペースでは、任意のDeltaテーブルが特徴量テーブルとして機能し、Unity CatalogがFeature Storeとして機能するため、テーブルを特徴量テーブルとして登録するために別の手順は必要ありません。ワークスペースが有効になっていない 2024 年 8 月 19 日 4:00:00 PM (UTC) より前に作成された Unity Catalog は、従来の ワークスペース Feature Store にアクセスできます。
機械学習では既存のデータを使用してモデルを構築し、将来の結果を予測します。生データを使用してモデルを構築するには、ほぼすべてのケースで、生データの前処理と変換が必要になります。このプロセスは特徴量エンジニアリングと呼ばれ、このプロセスの結果は、モデルのビルディングブロックとして特徴量と呼ばれます。
特徴量の開発は複雑で時間がかかります。 さらに複雑なのは、機械学習の場合、モデルのトレーニングのために特徴計算を行う必要があり、その後、モデルを使用して予測を行うときに再度計算を行う必要があることです。 これらの実装は、同じチームによって、または同じコード環境を使用して行われない場合があり、遅延やエラーにつながる可能性があります。 また、組織内の異なるチームは、多くの場合、同様の特徴量のニーズを持っていますが、他のチームが行った作業を認識していない可能性があります。 特徴量ストアはこれらの問題に対処するために設計されています。
特徴量テーブル
特徴量は特徴量テーブルとして整理されています。 各テーブルには主キーが必要であり、 Delta テーブル と追加のメタデータによってサポートされます。 特徴量テーブルのメタデータは、テーブルの生成元となったデータソースと、テーブルを作成またはテーブルに書き込んだノートブックとジョブを追跡します。
Databricks Runtime13.3LTS 以降では、ワークスペースでUnity Catalogが有効になっている場合、主キーをもつUnity Catalog上の任意のDeltaテーブルを特徴量テーブルとして使用できます。Unity Catalogの 特徴量テーブルの操作を参照してください。ローカルのワークスペース Feature Store に保存されている特徴量テーブルは「ワークスペース 特徴量テーブル」と呼ばれます。 ワークスペース Feature Storeにおける特徴量テーブルの取り扱い (レガシー) を参照してください。
特徴量テーブルの特徴量は通常、一般的な計算関数を使用して計算、更新されます。
FeatureLookup
多くの異なるモデルが特定の特徴量テーブルの特徴量テーブルを使用する可能性があり、すべてのモデルがすべての特徴量テーブルを必要とするわけではありません。 特徴量テーブルごとに FeatureLookup をトレーニングするには、特徴量テーブルごとにモデルをトレーニングします。 この FeatureLookup は、テーブルから使用するフィーチャを指定し、 create_training_setに渡されるラベル データに特徴量テーブルを結合するために使用するキーも定義します。
この図は、 FeatureLookup の仕組みを示しています。 この例では、 customer_features と product_featuresの 2 つの特徴量テーブルの特徴を使用してモデルをトレーニングします。 特徴量テーブルごとに FeatureLookup を作成し、テーブルの名前、テーブルから選択する特徴量(列)、特徴量を結合してトレーニング データセットを作成するときに使用するルックアップ キーを指定します。
次に、図に示されている create_training_setを呼び出します。 この API 呼び出しでは、生のトレーニング データ (label_df) を含む DataFrame 、使用する FeatureLookups 、 label、グラウンド トゥルースを含む列を指定します。 トレーニングデータには、特徴量テーブルの各主キーに対応する列が含まれている必要があります。 特徴量テーブルのデータは、これらのキーに従って入力 DataFrame に結合されます。 結果は、図に "トレーニング データセット" として示されています。
トレーニングセット
トレーニング セットは、特徴量のリストと、特徴量を検索するための生のトレーニング データ、ラベル、および主キーを含む DataFrame で構成されます。 トレーニング セットを作成するには、Feature Store から抽出する特徴量を指定し、モデルのトレーニング中にトレーニング セットを入力として提供します。
トレーニング セットを作成して使用する方法の例については、「 トレーニング データセットを作成する 」を参照してください。
Unity Catalogでの特徴量エンジニアリングを使用してモデルをトレーニングおよびログに記録すると、Catalog Explorer でモデルのリネージを表示できます。モデルの作成に使用されたテーブルと関数は、自動的に追跡され、表示されます。 特徴量のガバナンスとリネージを参照してください。
時系列 特徴量テーブル (ポイントインタイムのルックアップ)
モデルのトレーニングに使用されるデータには、多くの場合、時間依存関係が組み込まれています。 モデルを構築するときは、観測されたターゲット値の時点までの特徴値のみを考慮する必要があります。 目標値のタイムスタンプ以降に測定されたデータに基づいた特徴量でトレーニングすると、モデルのパフォーマンスが低下する可能性があります。
時系列 特徴量テーブル には、トレーニング データセットの各行が行のタイムスタンプの時点で最新の既知の特徴値を表すことを保証するタイムスタンプ列が含まれています。 時系列 特徴量テーブルは、時系列データ、イベントベースのデータ、時間集計データなど、特徴値が時間の経過とともに変化する場合に使用する必要があります。
時系列特徴量テーブルを作成するときは、主キーの時間関連列を時系列列として指定するには、引数 timeseries_columns ( Unity Catalogでの特徴量エンジニアリングの場合) または timestamp_keys 引数 (ワークスペース Feature Storeの場合) を使用します。 これにより、 create_training_set または score_batchを使用するときにポイントインタイムルックアップが可能になります。 システムは、指定された timestamp_lookup_key を使用して、タイムスタンプ時結合を実行します。
timeseries_columns 引数または timestamp_keys 引数を使用せず、時系列列をプライマリ・キー列としてのみ指定する場合、Feature Store は結合時に時系列列にポイント・イン・タイム・ロジックを適用しません。代わりに、タイムスタンプより前のすべての行を照合するのではなく、時刻が完全に一致する行のみを照合します。
オフラインストア
オフライン特徴ストアは、特徴の検出、モデル トレーニング、バッチ推論に使用されます。 Deltaテーブルとして具体化された特徴量テーブルが含まれています。
ストリーミング
バッチ書き込みに加えて、Databricks Feature Store はストリーミングをサポートしています。 ストリーミング ソースから特徴量テーブルに特徴量テーブルに特徴値を書き込むことができ、特徴量計算コードでは 構造化ストリーミング を利用して生データ ストリームを特徴に変換できます。
モデルパッケージ
Unity Catalog Feature Storeを使用して機械学習モデルをトレーニングし、クライアントの log_model() メソッドを使用してログに記録すると、モデルはこれらの特徴量への参照を保持します。 推論時に、モデルはオプションで特徴量の値を自動的に取得できます。 呼び出し元は、モデルで使用される特徴量の主キー ( user_idなど) を指定するだけでよく、モデルは必要なすべての特徴量の値を取得します。
バッチ推論では、特徴値はオフラインストアから取得され、スコアリングの前に新しいデータと結合されます。 リアルタイム推論では、特徴値はオンラインストアから取得されます。
フィーチャー メタデータを使用してモデルをパッケージ化するには、FeatureEngineeringClient.log_model ( Unity Catalogでの特徴量エンジニアリングの場合) または FeatureStoreClient.log_model (ワークスペース Feature Storeの場合) を使用します。