オンライン特徴量の作成とサービング¶
レイテンシの影響を受けやすい機械学習推論ワークフロー向けに、オンライン特徴量を作成してサービングします。作成する特徴量ビューのオンライン特徴量を有効化するか、既存の特徴量ビューを更新してオンラインサービングできるようにします。
重要
オンライン特徴量サービングを使用するには、Snowflakeバージョン9.26以降と、 snowflake-ml-python バージョン1.18.0が必要です。
オンライン特徴量サービングには、次のようなメリットがあります。
リアルタイム推論のための低レイテンシでのポイントルックアップ
オフラインソースからの自動データ同期
完全に管理されたインフラストラクチャとメンテナンス
要求の厳しいワークロード向けの柔軟なスケーリング
オンライン特徴量サービングは、 オンライン特徴量テーブル に支えられます。
データの鮮度¶
オンライン特徴量サービングのある特徴量ビューは、オフラインストアからデータを自動的に同期します。
target_lag パラメーターを使用して、データがオンライン特徴量テーブルに同期される頻度を設定します。この値は、最小10秒から最大8日まで設定できます。
リフレッシュモード¶
Snowflakeは、次のリフレッシュモードを使用してデータを更新します。
増分リフレッシュ:推奨される最も効率的なモードです。Snowflakeはソースの変更を追跡し、新しい行または更新された行のみをオンラインストアにマージします。これにより、コンピューティングコストとI/Oコストが最小限に抑えられます。
フルリフレッシュ:このモードでは、テーブル内のすべての既存データをドロップし、ソースからすべてをリロードします。リソースを大量に消費するものであり、増分リフレッシュが不可能な場合に使用されます。
リフレッシュモードを明示的に INCREMENTAL または FULL に設定できます。または AUTO に設定して、Snowflakeが利用可能で最も効率的なリフレッシュモードを決定するようにもできます。
時系列データの取り扱い¶
データの一貫性を確保するために、 timestamp_col を指定できます。ソースに同じ主キーを持つ複数の行が見つかった場合、Snowflakeは最新のタイムスタンプを持つバージョンのみをインジェストします。タイムスタンプ列を指定しない場合は、最近処理された行が優先されます。
オンライン特徴量の作成とサービングへのアクセスを提供する¶
オンライン特徴量ストアの使用を開始する前に、関連するロールに必要な権限を提供する必要があります。
権限を提供するには、 SQL でのアクセス制御設定 で説明されているアクセス制御スクリプトを使用します。スクリプトを実行したら、以下の権限を付与します。
GRANT CREATE ONLINE FEATURE TABLE ON SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_PRODUCER);
GRANT SELECT, MONITOR ON FUTURE ONLINE FEATURE TABLES IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);
GRANT SELECT, MONITOR ON ALL ONLINE FEATURE TABLES IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);
Python API を使用してオンライン特徴量を管理してサービングする¶
次の例では、新しい特徴量ビューを作成する際にオンライン特徴量を設定する方法を示しています。OnlineConfig オブジェクトを使用して、ターゲットデータの鮮度ラグなどのオンラインサービング設定を指定できます。
from snowflake.ml.feature_store import FeatureView
from snowflake.ml.feature_store.feature_view import OnlineConfig
online_config = OnlineConfig(enable=True, target_lag="30 seconds")
fv = FeatureView(
name="MY_FV",
entities=[entity],
feature_df=my_df, # Snowpark DataFrame containing feature transformations
timestamp_col="ts", # optional timestamp column name in the dataframe
refresh_freq="5 minutes",
refresh_mode="AUTO", # refresh mode of the feature data
desc="my feature view", # optional description
online_config=online_config
)
fv = fs.register_feature_view(feature_view=fv, version="v1")
以下は OnlineConfig パラメーターです。
パラメーター |
型 |
説明 |
デフォルト |
|---|---|---|---|
enable |
ブール値、オプション |
特徴量ビューでオンライン特徴量サービングを有効にするかどうかを指定します。 |
デフォルト:False |
target_lag |
文字列、オプション |
「<num> (seconds|minutes|hours|days|s|m|h|d)」という形式でターゲットデータの鮮度ラグを指定する文字列。 |
デフォルト:10秒 |
注釈
refresh_freq および OnlineConfig.target_lag は独立して動作します。上記の例では、 my_df で表されるソースデータからオンラインデータストアへの有効なターゲットデータ伝播のラグは refresh_freq + online_config.target_lag になります。
特徴量ビューを更新してオンライン特徴量サービングを有効/無効にする¶
既存の特徴量ビューの場合は、 update_feature_view メソッドを使用してオンライン特徴量サービング設定を更新できます。このメソッドを使用すると、既存の特徴量ビューに対してオンライン特徴量サービングを有効にすることができます。
以下のコードを使用して、オンライン特徴量サービングを有効にします。
# Enable online feature serving
fs.update_feature_view(
name="<name>",
version="<version>",
online_config=OnlineConfig(enable=True, target_lag="5 minutes")
)
以下のコードを使用して、オンライン特徴量サービングを無効にします。
# Disable online feature serving
fs.update_feature_view(
name="<name>",
version="<version>",
online_config=OnlineConfig(enable=False)
)
オンラインストレージから特徴量を取得する¶
特定のサンプルのオンラインストレージから特徴量の値を取得するには、read_feature_view メソッドを使用して、特徴量名のリストとサンプルの結合キーを渡します。
fs.read_feature_view(
feature_view=fv,
keys=[["<k_1>", "<k_2>"]],
feature_names=["<feature1>", "<feature2>", "<feature3>"],
store_type=StoreType.ONLINE
)
オンラインデータリフレッシュを一時停止/再開する¶
以下のコードを使用して、データのリフレッシュを一時的に停止します。
fs.suspend_feature_view(feature_view=fv)
データのリフレッシュを再開するには、以下のコードを使用します。
fs.resume_feature_view(feature_view=fv)
これらの操作では、オフライン特徴量ビュー(動的テーブルと関連タスク)とオンライン特徴量テーブル(存在する場合)の両方を一時停止/再開し、すべてのストレージタイプで一貫した状態を確保します。
特徴量ビューを手動でリフレッシュする¶
fs.refresh_feature_view(
feature_view=fv,
store_type=<store_type>
)
store_type 引数は、オフライン(StoreType.OFFLINE)かオンライン(StoreType.ONLINE)のどちらの特徴量データをリフレッシュするかを指定します。
リフレッシュ履歴を表示する¶
fs.get_refresh_history(
feature_view=fv,
store_type=store_type
)
store_type 引数は、オフライン(StoreType.OFFLINE)とオンライン(StoreType.ONLINE)のどちらのストアのリフレッシュ履歴を返すかを指定します。
コストについて¶
オンライン特徴量テーブルには、以下の消費モード全体でコストが発生します。
仮想ウェアハウスコンピューティング:キールックアップとデータインジェスチョン操作の両方が、標準レートで仮想ウェアハウスのクレジットを消費します。詳細については、 仮想ウェアハウスのクレジット使用状況 をご参照ください。
クラウドサービスコンピューティング:基になるベースオブジェクトの変更を識別し、リフレッシュ操作が必要なタイミングを判断するために必要です。詳細については、 クラウドサービスのクレジット使用状況 をご参照ください。
ハイブリッドテーブルストレージ:GB あたりの月額定額料金に基づくストレージコスト。従来のSnowflakeストレージのコストよりも高価ですが、ハイブリッドテーブルを格納するコストと同一です。詳細については、Credit Consumption Table のTable 3(b)をご参照ください。
ハイブリッドテーブルのリクエスト:これらのリクエストは、行ストレージクラスターへの読み取り/書き込み操作に サーバーレスのクレジット使用状況 を使用します。これらのクラスターとの間で書き込みまたは読み取りされるデータ量は、クレジット消費の計算に使用されます。操作ごとの最小使用量は4 KB です。クレジットは、コンパクションなどのバックグラウンド処理に使用されるコンピューティングリソースでも消費されます。詳細については、 Credit Consumption Table のTable 5をご参照ください。
Tip
増分リフレッシュは、コスト削減に役立ちます。増分アップデートは一般的にフルリフレッシュよりもコスト効率が高く、コンピューティングコストとデータインジェスチョンコストが低減されます。
コストのモニタリング¶
コストを監視するには、以下のビューを使用します。
-- Hybrid table request credits
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.HYBRID_TABLE_USAGE_HISTORY;
-- Storage consumption
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.STORAGE_USAGE;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.DATABASE_STORAGE_USAGE_HISTORY;
-- Overall costs
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY;