オンライン特徴量の作成とサービング¶
レイテンシの影響を受けやすい機械学習推論ワークフロー向けに、オンライン特徴量を作成してサービングします。作成する特徴量ビューのオンライン特徴量を有効化するか、既存の特徴量ビューを更新してオンラインサービングできるようにします。
重要
オンライン特徴量サービングを使用するには、Snowflakeバージョン9.26以降と、 snowflake-ml-python バージョン1.18.0が必要です。
オンライン特徴量サービングには、次のようなメリットがあります。
リアルタイム推論のための低レイテンシでのポイントルックアップ
オフラインソースからの自動データ同期
完全に管理されたインフラストラクチャとメンテナンス
要求の厳しいワークロード向けの柔軟なスケーリング
オンライン特徴量サービングは、 オンライン特徴量テーブル に支えられます。
データの鮮度¶
オンライン特徴量サービングのある特徴量ビューは、オフラインストアからデータを自動的に同期します。
target_lag パラメーターを使用して、データがオンライン特徴量テーブルに同期される頻度を設定します。この値は、最小10秒から最大8日まで設定できます。
オンライン特徴量テーブルは、指定した値を使用してバックグラウンドでリフレッシュされます。連続で5回のリフレッシュ失敗が発生した場合、オンライン特徴量テーブルは一時停止されます。リフレッシュ失敗のトラブルシューティングについては、リフレッシュ履歴を確認してください。
リフレッシュモード¶
Snowflakeは、次のリフレッシュモードを使用してデータを更新します。
増分リフレッシュ:推奨される最も効率的なモードです。Snowflakeはソースの変更を追跡し、新しい行または更新された行のみをオンラインストアにマージします。これにより、コンピューティングコストとI/Oコストが最小限に抑えられます。
フルリフレッシュ:このモードでは、テーブル内のすべての既存データをドロップし、ソースからすべてをリロードします。リソースを大量に消費するものであり、増分リフレッシュが不可能な場合に使用されます。
リフレッシュモードを明示的に INCREMENTAL または FULL に設定できます。または AUTO に設定して、Snowflakeが利用可能で最も効率的なリフレッシュモードを決定するようにもできます。
時系列データの取り扱い¶
データの一貫性を確保するために、 timestamp_col を指定できます。ソースに同じ主キーを持つ複数の行が見つかった場合、Snowflakeは最新のタイムスタンプを持つバージョンのみをインジェストします。タイムスタンプ列を指定しない場合は、最近処理された行が優先されます。
オンライン特徴量の作成とサービングへのアクセスを提供する¶
オンライン特徴量ストアの使用を開始する前に、関連するロールに必要な権限を提供する必要があります。
権限を提供するには、 SQL でのアクセス制御設定 で説明されているアクセス制御スクリプトを使用します。スクリプトを実行したら、以下の権限を付与します。
Python API を使用してオンライン特徴量を管理してサービングする¶
次の例では、新しい特徴量ビューを作成する際にオンライン特徴量を設定する方法を示しています。OnlineConfig オブジェクトを使用して、ターゲットデータの鮮度ラグなどのオンラインサービング設定を指定できます。
以下は 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 メソッドを使用してオンライン特徴量サービング設定を更新できます。このメソッドを使用すると、既存の特徴量ビューに対してオンライン特徴量サービングを有効にすることができます。
以下のコードを使用して、オンライン特徴量サービングを有効にします。
以下のコードを使用して、オンライン特徴量サービングを無効にします。
オンラインストレージから特徴量を取得する¶
特定のサンプルのオンラインストレージから特徴量の値を取得するには、read_feature_view メソッドを使用して、特徴量名のリストとサンプルの結合キーを渡します。
オンラインデータリフレッシュを一時停止/再開する¶
以下のコードを使用して、データのリフレッシュを一時的に停止します。
データのリフレッシュを再開するには、以下のコードを使用します。
これらの操作では、オフライン特徴量ビュー(動的テーブルと関連タスク)とオンライン特徴量テーブル(存在する場合)の両方を一時停止/再開し、すべてのストレージタイプで一貫した状態を確保します。
特徴量ビューを手動でリフレッシュする¶
store_type 引数は、オフライン(StoreType.OFFLINE)かオンライン(StoreType.ONLINE)のどちらの特徴量データをリフレッシュするかを指定します。
リフレッシュ履歴を表示する¶
store_type 引数は、オフライン(StoreType.OFFLINE)とオンライン(StoreType.ONLINE)のどちらのストアのリフレッシュ履歴を返すかを指定します。
コストについて¶
オンライン特徴量テーブルには、以下の消費モード全体でコストが発生します。
仮想ウェアハウスコンピューティング:キールックアップとデータインジェスチョン操作の両方が、標準レートで仮想ウェアハウスのクレジットを消費します。詳細については、 仮想ウェアハウスのクレジット使用状況 をご参照ください。
クラウドサービスコンピューティング:基になるベースオブジェクトの変更を識別し、リフレッシュ操作が必要なタイミングを判断するために必要です。詳細については、 クラウドサービスのクレジット使用状況 をご参照ください。
ハイブリッドテーブルストレージ:GB あたりの月額定額料金に基づくストレージコスト。従来のSnowflakeストレージのコストよりも高価ですが、ハイブリッドテーブルを格納するコストと同一です。詳細については、Credit Consumption Table のTable 3(b)をご参照ください。
ハイブリッドテーブルのリクエスト:2026年3月1日の時点で、ハイブリッドテーブルリクエストは請求されなくなり、計測はこの価格変更が有効になった直後に無効になりました。
Tip
増分リフレッシュは、コスト削減に役立ちます。増分アップデートは一般的にフルリフレッシュよりもコスト効率が高く、コンピューティングコストとデータインジェスチョンコストが低減されます。
コストのモニタリング¶
コストを監視するには、以下のビューを使用します。