メタデータとアクセス制御を備え、MLフィーチャーを保存、バージョン管理、提供する一元化されたリポジトリ。環境間での再利用と一貫性を実現します。
によって Databricks Staff による投稿

このブログは元々Tecton.aiによって公開されました。Tecton.aiは2025年8月にDatabricksによって買収されました。買収以来、Databricks Feature Storeは宣言型Feature APIをリリースしました。これは、バッチデータとストリーミングデータの両方に対応するマネージド特徴量パイプラインの作成を自動化する、特徴量実験のための強力な抽象化です。
更新日: 2025年5月15日
著者について:
Mike Del Balso, Tecton CEO & 共同創設者
Willem Pienaar, Feastの作成者
データチームは、運用機械学習がデータパイプラインの作成をはるかに超えるデータ問題の解決を必要とすることに気づき始めています。
以前の投稿「MLデータにDevOpsが必要な理由」では、MLシステムを本番環境に導入する際にチームが直面する主要なデータ課題のいくつかを取り上げました。
大規模な分析であれリアルタイムストリーミングであれ、本番データシステムは新しいものではありません。しかし、顧客向けアプリケーションに組み込まれたML駆動型インテリジェンスである運用機械学習は、ほとんどのチームにとって新しいものです。運用目的(例:レコメンダーシステム、不正検出、パーソナライゼーションなど)で機械学習を本番環境にデプロイする課題は、データツールに新たな要件をもたらします。
そ れを可能にするために、新しい種類のML特化型データインフラストラクチャが登場しています。
データサイエンスチームとデータエンジニアリングチームは、MLアプリケーションを本番環境に導入するために必要なデータセットとデータパイプラインを管理するために、ますます特徴量ストアに注目しています。この投稿では、最新の特徴量ストアの主要コンポーネントと、それらの組み合わせがデータエンジニアリングの重複を減らし、機械学習のライフサイクルを加速し、データサイエンスチーム間の新しい種類のコラボレーションを可能にすることで、組織にどのように相乗効果をもたらすかを説明します。
| おさらい:MLにおいて、特徴量とは予測モデルへの入力信号として使用されるデータです。 |
| 例えば、クレジットカード会社が取引が不正かどうかを予測しようとしている場合、有用な特徴量として、その取引が外国で行われているかどうか、あるいはその取引の規模が顧客の通常の取引と比較してどうか、などが挙げられます。特徴量という場合、通常はその信号の概念(例:「transaction_in_foreign_country」)を指し、特定の特徴量の値(例:「取引番号1364は外国で行われた」)を指すわけではありません。 |
![]() |
「モデルとデータの間のインターフェース」
私たちは、UberのMichelangeloプラットフォームを説明するブログ記事で初めて特徴量ストアを紹介しました。それ以来、特徴量ストアは運用機械学習スタックの不可欠なコンポーネントとして登場しました。
特徴量ストアの利点には以下が含まれます:
特徴量ストアは、運用MLアプリケーションの構築と運用時に発生するデータ管理問題のすべてを解決することを目指しています。
特徴量ストアは、以下の機能を持つML特化型デー タシステムです。

シンプルな特徴量管理をサポートするため、特徴量ストアは、様々な環境で特徴量パイプラインを簡単に構築、デプロイ、および理解できるデータ抽象化を提供します。例えば、特徴量変換を一度定義すれば、開発環境(過去の値でのトレーニング用)と本番環境(新しい特徴量値での推論用)の両方で、その値を一貫して計算および提供することが容易になります。
特徴量ストアは、MLプロジェクトのライフサイクル全体にわたる特徴量データとメタデータの中央ハブとして機能します。特徴量ストア内のデータは以下の目的で使用されます。
特徴量ストアは、コラボレーションを可能にすることで、ML組織に規模の経済をもたらします。特徴量が特徴量ストアに登録されると、組織内の他のモデルによってすぐに再利用できるようになります。これにより、データエンジニアリングの重複が減り、新しいMLプロジェクトが厳選された本番環境対応の特徴量のライブラリで迅速に立ち上げられるようになります。

効果的な特徴量ストアは、デプロイされる環境に適応できるモジュール型システムとして設計されています。特徴量ストアは通常、5つの主要なコンポーネントで構成されています。この投稿の残りの部分では、これらのコンポーネントを順に説明し、運用MLアプリケーションを強化する上でのそれぞれの役割を解説します。
最新の特徴量ストアには、変換、ストレージ、サービング、監視、特徴量レジストリの5つの主要コンポーネントがあります。

以下のセクションでは、これらの各セクションの目的と典型的な機能の概要を説明します。
特徴量ストアは、モデルに特徴量データを提供します。これらのモデルには、トレーニングとサービング全体で特徴量の一貫したビューが必要です。モデルのトレーニングに使用される特徴量の定義は、オンラインサービングで提供される特徴量と完全に一致する必要があります。それらが一致しない場合、トレーニング/サービングスキューが発生し、壊滅的でデバッグが困難なモデルのパフォーマンス問題を引き起こす可能性があります。

特徴量ストアは、特徴量の生成に使用されるロジックと処理を抽象化し、ユーザーが必要なすべての環境で、企業内のすべての特徴量に一貫してアクセスできる簡単で標準的な方法を提供します。
オフラインでデータ(例:トレーニング用)を取得する場合、特徴量値は、ノートブックフレンドリーな特徴量ストアSDKを介して一般的にアクセスされます。これらは、モデルのトレーニングに使用される各例について、その時点での世界の正しい状態のビュー(別名「タイムトラベル」)を提供します。
オンラインサービングの場合、特徴量ストアは、最新の特徴量値で構成される単一の特徴量ベクトルを一度に配信します。応答は、低レイテンシーデータベースに支えられた高性能APIを介して提供されます。

特徴量ストアは、特徴量サービングレイヤーを介した取得をサポートするために特徴量データを永続化します。これらは通常、異なる特徴量サービングシステムの要件をサポートするために、オンラインとオフラインの両方のストレージレイヤーを含んでいます。

オフラインストレージレイヤーは、通常、トレーニング目的で数ヶ月から数年分の特徴量データを保存するために使用されます。オフラインの特徴量ストアデータは、S3、BigQuery、Snowflake、Redshiftなどのデータウェアハウスやデータレイクに保存されることがよくあります。データサイロを防ぐために、既存のデータレイクまたはデータウェアハウスをオフラインの特徴量ストレージ用に拡張することが一般的に推奨されます。
オンラインストレージレイヤーは、推論中の低レイテンシーなルックアップのために特徴量値を永続化するために使用されます。これらは通常、各エンティティの最新の特徴量値のみを保存し、本質的に世界の現在の状態をモデル化します。オンラインストアは通常、結果整合性があり、ほとんどのMLユースケースでは厳密な整合性要件はありません。これらは通常、DynamoDB、Redis、Cassandraなどのキーバリューストアで実装されます。

特徴量ストアは、各特徴量値がエンティティ(例:ユーザー)とタイムスタンプに関連付けられるエンティティベースのデータモデルを使用します。エンティティベースのデータモデルは、標準化された特徴量管理をサポートするための最小限の構造を提供し、一般的な特徴量エンジニアリングワークフローに自然に適合し、本番環境での簡単な取得クエリを可能にします。

運用MLアプリケーションは、モデルが最新の視点を使用して予測を行えるように、新しいデータを特徴量値に定期的に処理する必要があります。特徴量ストアは、これらの値を生成するデータ変換を管理およびオーケストレーションし、外部システムによって生成された値も取り込みます。特徴量ストアによって管理される変換は、共通の特徴量レジストリ(下記参照)の定義によって構成されます。
特徴量ストアを使い始めるほとんどのチームは、すでに特徴量値を生成する既存のデータパイプラインを持っています。このため、特徴量ストアが段階的に導入可能であり、既存のデータプラットフォームとのファーストクラスの統合を持つことが非常に重要であり、チームは既存のETLパイプラインをMLユースケースのためにすぐに運用できるようになります。
特徴量ストアは、主に3種類のデータ変換と連携します。
| 特徴量タイプ | 定義 | 一般的な入力データソース | 例 |
|---|---|---|---|
| バッチ変換 | 静止データにのみ適用される変換 | データウェアハウス、データレイク、データベース | ユーザーの国、製品カテゴリ |
| ストリーミング変換 | ストリーミングソースに適用される変換 | Kafka, Kinesis, PubSub | 過去30分間のユーザーごとの垂直方向のクリック数、過去1時間のリスティングごとのビュー数 |
| オンデマンド変換 | 予測時にのみ利用可能なデータに基づいて特徴量を生成するために使用される変換。これらの特徴量は事前に計算できません。 | ユーザー向けアプ リケーション | ユーザーは現在、サポートされている場所にいますか? |
主要な利点は、異なる種類の特徴量を同じモデルで簡単に一緒に使用できることです。

モデルは推論のために最新の特徴量値にアクセスする必要があります。特徴量ストアは、特徴量を継続的に定期的に再計算することでこれを実現します。変換ジョブは、新しいデータが処理され、新鮮な新しい特徴量値に変換されるようにオーケストレーションされます。これらのジョブは、特徴量ストアが接続されているデータ処理エンジン(例:SparkやPandas)で実行されます。
モデル開発では、異なる変換要件が生じます。モデルを反復処理する際、新しい特徴量は、過去のイベント(例:過去6ヶ月間のすべての購入)に対応するトレーニングデータセットで使用されるように設計されることがよくあります。これらのユースケースをサポートするために、特徴量ストアは、トレーニング用の特徴量の履歴値を生成および永続化する「バックフィルジョブ」を簡単に実行できるようにします。一部の特徴量ストアは、登録されたトレーニングデータセットに対して、事前に設定された期間で新しく登録された特徴量を自動的にバックフィルします。
変換コードは環境間で再利用され、トレーニング/サービングスキューを防ぎ、チームが環境ごとにコードを書き直す手間を省きます。
特徴量ストアは、特徴量のライフサイクル全体にわたって、すべての特徴量関連リソース(計算、ストレージ、サービング)を包括的に管理します。特徴量を本番環境に導入するために必要な反復的なエンジニアリングタスクを自動化することで、シンプルで迅速な本番環境へのパスを可能にします。管理の最適化(例:どのモデルにも使用されていない特徴量の廃止、またはモデル間の特徴量変換の重複排除)は、特にチームが手動で特徴量を管理する複雑さが増すにつれて、大きな効率化をもたらすことができます。
MLシステムで問題が発生した場合、それは通常データの問題です。特徴量ストアは、そのような問題を検出して表面化するのに独自の立場にあります。これらは、保存および提供する特徴量に関するメトリクスを計算し、正確性と品質を記述できます。特徴量ストアはこれらのメトリクスを監視し、MLアプリケーション全体の健全性を示すシグナルを提供します。

特徴量データは、ユーザー定義のスキーマまたはその他の構造的基準に基づいて検証できます。データ品質は、ドリフトとトレーニング/サービングスキューを監視することで追跡されます。例えば、モデルに提供される特徴量データは、モデルがトレーニン グされたデータと比較され、モデルのパフォーマンスを低下させる可能性のある不整合を検出します。
本番システムを運用する際には、運用メトリクスを監視することも重要です。特徴量ストアは、コア機能に関連する運用メトリクスを追跡します。例えば、特徴量ストレージ(可用性、容量、利用率、鮮度)や特徴量サービング(スループット、レイテンシー、エラー率)に関連するメトリクスなどです。その他のメトリクスは、外部データ処理エンジン(例:ジョブ成功率、スループット、処理遅延、処理速度)の運用メトリクスなど、重要な隣接システムコンポーネントの操作を記述します。
特徴量ストアは、これらのメトリクスを既存の監視インフラストラクチャで利用できるようにします。これにより、MLアプリケーションの健全性を、本番スタック内の既存の可観測性ツールで監視および管理できます。
どの特徴量がどのモデルで使用されているかを可視化することで、特徴量ストアは、アラートと健全性メトリクスを特定のユーザー、モデル、またはコンシューマーに関連するビューに自動的に集約できます。
すべてのフィーチャーストアがこのようなモニタリングを内部的に実装することは必須ではありませんが、少なくともデータ品質監視システムが接続できるインターフェースを提供すべきです。さまざまなMLユースケースには異なる専門的な監視ニーズがあるため、ここでのプラグイン可能性は重要です。
すべてのフィーチャーストアにおいて重要なコンポーネントは、標準化された特徴量定義とメタデータの一元化されたレジストリです。レジストリは、組織内の特徴量に関する情報の唯一の信頼できる情報源として機能します。

レジストリは、フィーチャーストアとのユーザーインタラクションのための中央インターフェースです。チームはレジストリを共通のカタログとして使用し、チーム内およびチーム間で新しい定義を探索、開発、共同作業、公開します。
レジストリ内の定義は、フィーチャーストアのシステム動作を設定します。自動化されたジョブはレジストリを使用して、データ取り込み、変換、およびストレージをスケジュールおよび設定します。これは、フィーチャーストアにどのようなデータが保存され、どのように整理されるかの基礎を形成します。サービングAPIはレジストリを使用して、どの特徴量値が利用可能であるべきか、誰がそれらにアクセスできるべきか、そしてどのように提供されるべきかについて一貫した理解を得ます。
レジストリにより、重要なメタデータを特徴量定義に添付できます。これにより、所有権、プロジェクトまたはドメイン固有の情報を追跡し、隣接システムと簡単に統合するための経路が提供されます。これには、リネージトラッキングに使用される依存関係とバージョンに関する情報が含まれます。
一般的なデバッグ、コンプライアンス、および監査ワークフローを支援するために、レジストリは分析的に利用可能なものと実際に本番環境で実行されているものの不変の記録として機能します。
これまで、フィーチャーストアのコアとなる最小限のコンポーネントを見てきました。実際には、企業はコンプライアンス、ガバナンス、セキュリティなどのニーズを抱えており、追加のエンタープライズ向け機能が必要となることがよくあります。それについては、今後のブログ記事で取り上げます。
私たちは、フィーチャーストアを最新のMLアプリケーションにおけるデータフローの中心と捉えています。これらは、MLを本番環境に導入するデータサイエンスチームにとって、重要なインフラストラクチャであることが急速に証明されています。2028年までにフィーチャーストアを利用する組織の数は4倍になると予想しています。
フィーチャーストアの利用を開始するためのいくつかの選択肢があります。
私たちは、運用MLスタックの主要コンポーネントとしてフィーチャーストアが登場するにあたり、その共通の定義を提供するためにこのブログ記事を執筆しました。この分野で業界が爆発的な活動を目の当たりにすると信じています。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。