最近こちらのサイトを参考にfeature storeに関して勉強してみたので、今回はそのメモです。
Why：なぜ必要か？
機械学習の実運用時の困りごと
機械学習のモデルを実際のアプリケーション上で運用しようとすると様々な問題が発生します。
実験環境と本番環境を揃えたい
例えば、学習時と推論時に使用できるデータに一貫性を取ることが難しい問題があります。 学習時には、過去の時点の特徴量を使用してモデルの学習を行うことになります。 一般的に、この段階では時間制約はあまり厳しくなく、時間をかけて特徴量作成を行うことができます。 そして、この実験段階でのバリデーションにも、過去のデータを使用して検証を行いますが、こちらも時間制約はそれほど厳しくないと思います。
一方、本番環境では学習・推論に使用する特徴量に制約が入ることがあります。 特に、オンライン推論時にはリクエスト時に必要なログや特徴量の作成が追いつかないことが考えられ、学習環境で作成していたのと同じ条件で特徴量を作成することが難しいことがあります。 そうなると、実験環境の理想的な状態ではうまく行ったモデルであっても、本番環境では実は使用できない特徴量があることで、期待した性能を出せなかったり信頼性のある結果を提供できないことがあります。
過去のある時点の状況を再現したい
実際に運用していたモデルについて、ある時点でのモデルの学習・推論の振る舞いを確認することで、何らかの知見を得てモデル開発に反映していきたいことがあります。 これをやろうとすると、モデルの学習・推論に使用した特徴量をすべて過去の時点で再現する必要が出てきます。 自分で作った特徴量ならまだしも、他人が作成した特徴量では作成したロジックについて理解していないこともあり、さらに特徴量作成のロジックがあとから変更になっている場合もあります。
そういった状況で、特徴量を再現して、過去の時点での学習・推論を再現するのは、なかなか骨の折れる作業となりえます。
特徴量に関する車輪の再発明をなくしたい
組織やチームの規模が大きくなると、情報のシェアが難しくなります。 特徴量を作成するのにもコストがかかり、各人が自分で使用する特徴量を0から作成して車輪の再発明をしていくのは非常に非効率だと言えます。
可能な限り組織の中で作成した特徴量を共有・再利用し、特徴量作成のコストを抑えて効率的に開発を進めて行くことが望ましいと考えられます。
歴史的経緯
上記に挙げたような悩みは業界内さまざまなところで考えられており、この問題を解決するためにFeature Storeというものが登場しました。
上記の年表のように、Feature Storeという概念自体は2017年にUberのMichelangeloの発表で初めて登場しました。 その後、AirbnbやLogical clocksなどからFeature Storeのプラクティスが発表されるようになりました。 そして現在では、それに続くように、Amazon、Google、Databricksなどの機械学習プラットフォームを持つ企業が参入してきています。
What：Feature Storeとはなにものか？
The Feature Store is where the features are stored and organized for the explicit purpose of being used to either train models (by Data Scientists) or make predictions (by applications that have a trained model). It is a central location where you can either create or update groups of features created from multiple different data sources, or create and update new datasets from those feature groups for training models or for use in applications that do not want to compute the features but just retrieve them when it needs them to make predictions.
Feature Store for ML - What is a Feature Store?
DeepLによると下記のような説明になります。
フィーチャーストアは、モデルのトレーニング（データサイエンティストによる）または予測（トレーニング済みモデルを持つアプリケーションによる）に使用することを明確な目的として、フィーチャーを保存・整理する場所です。複数の異なるデータソースから作成された特徴量のグループを作成・更新したり、モデルのトレーニングや、特徴量を計算せずに予測に必要な時だけ取り出すアプリケーションで使用するために、それらの特徴量グループから新しいデータセットを作成・更新することができる中央の場所です。
一言で言うと、
機械学習の学習・推論に使用することを目的として、特徴量を作成・更新・保存・探索・アクセスするための管理システム
と、個人的には理解しています。
Feature Storeの利点は大まかに下記のようなものが挙げられます。
- 学習データとサービスのための一貫したフィーチャーエンジニアリング
- 特徴量の再利用
- 特徴量の供給のためのシステムサポート
- 特徴量のための探索的データ分析
- スポット利用時のリークのない正確なトレーニングデータの提供
- 特徴量のセキュリティとガバナンス
- トレーニングデータセットの再現性
求められる要件
共有性
A fundamental premise of the feature store is that it must be shareable across an organization; features must be accessible by any team that needs them.
5 Minimum Requirements of an Operational Feature Store | by Ben Epstein | Feature Stores for ML | Medium
Feature Storeの一つの大きな要件は、組織全体で特徴量を共有できることとしています。 データサイエンスを大規模に取り入れている組織では数百から数千のFeatureが利用されることもあり、その規模は非常に膨大になります。 SQLやAPIの形式などで、これらの特徴量をかんたんに検索・アクセスできることは、データサイエンティストの生産性向上に有効になってきたりします。
学習系と推論系の一貫性
多くの機械学習のタスクでは、学習と推論が時間的に続いて実行されず、学習と推論が時間的に切り離されて実行されることがあります。 このとき、学習と推論で特徴量エンジニアリングが一貫していないと予測の信頼性は低くなってしまいます。（当然ですが）
この問題に対して、特徴量をデータベースに書き込み、学習と推論に使用する際にそのデータベースから読み出す方法が考えられます。 オンラインではリアルタイムでのアクセスが求められるケースもあり、そうした場合にはこの方法は有効になります。 リアルタイム性に関する制約が厳しくない場合には、共通の特徴量エンジニアリングライブラリを使用するという解決策も考えられます。 いずれにせよ学習系と推論系でのデータの一貫性が求められます。
Feature Engineeringと透明性
MLでは、生のデータソースから必要に応じた特徴量を作成します。 Feature Storeでは、特徴量の格納だけでなく、その生成過程についても管理する必要があります。 UberのMichelangeloではこれをサポートするためにDSLを整備していますし、Spark/PySpark, Pandas, Apache Flink, Apache Beamといったフレームワークを使用することで実現する事例も多く見られます。
また、Feature Storeは、暗黙のうちに信頼性を信用して使用されるため、各特徴量の出自と実装を調査可能でなければなりません。 Feature Engineeringの内容が文書化され、誰でもその経緯を確認できる状態にしておくことが求められます。
バージョン管理と再現性
Feature Storeの一つの目的として、特徴量を使用した共同作業があります。 特徴量の透明性や共有性に加え、バージョン管理が信頼性を保証するのに役立ちます。 とくに、自分で作成したわけではない特徴量を使用する際には、使用しようとしている特徴量について下記のような情報を確認することが重要になります。
- 特徴量の計算方法とその計算が変更された場合のバージョン
- その特徴量が最後に更新されたのがいつなのかのバージョン
特徴量をバージョン管理することで、特定の特徴量が過去に変更された場合に、誰がそれを構築し、どのような変更を施したのかを追跡できるようになります。 これにより、誤った特徴量を使用した結果によって意思決定をすることを防ぐことができます。
過去のある時点でのデータベースのカラムの値を問い合わせるため、テーブルにdatetime/event-timeのカラムを含めることで対応する事ができますが、最近では一部のデータベースではタイムトラベルクエリをサポートしており、過去の時点での特徴に関するクエリを可能にしていたりします。
ガバナンスとアクセスコントロール
場合によっては、適切なガバナンスとアクセスコントロールが必要になる場合があります。 特徴量へのアクセスを制御し、組織内で誰がいつ特定の特徴にアクセスしたのかは確認できる必要が出る場合があり、同様に挿入・更新についても管理する必要が出たりします。
バッチとオンライン処理
特徴量をオンラインでも使用したい場合、Feature Storeはオフラインとオンラインの2種類のワークロードに分けられます。 オフラインではバッチ処理によって一定間隔で特徴量を作成し、オンラインでは新しいデータから瞬時に特徴量を作成する処理が行われます。 これら2種類のワークロードは、概念的に別物であり、2つのFeature Storeとして考えられそうですが、実際にはこれは問題です。 理想的にはオフラインで作成した特徴量とオンラインで作成した特徴量の双方を1つのFeature Storeで管理され、Feature Storeのユーザーはそれがオンライン・オフラインで作成されたものかを意識しなくてよい状況が望ましいです。
How：どうやって実現する？
Feature Storeは様々な形式で実現されます。 オンラインデータベースを使用したものもあれば、データベースを使用しない仮想的なFeature Store(Feature Form)のような形式もあります。 単一のDWHと連携させて使用することもあれば、Sparkのような計算機を使って多くのことなるデータストアと連携するものもあります。
標準的なFeature Storeの構成
一つの具体例として、典型的なFeature Storeの構成について確認します。
Feature Storeが提供する機能は大きく5種類に分けられます。
- Serving
- Storage
- Transformation
- Monitoring
- Registory
Serving
機械学習のモデルが使用する特徴量を提供する機能です。 これは学習・推論の両方で一貫した形で提供されます。
上の図では、Servingの機能によって、学習時と推論時で同様の特徴を要求し、それが応答されています。 学習時と推論時で戻り値の形式が異なるように変換も行われています。
モデルの学習で使用する特徴量の定義は、推論時に使用される特徴量の定義と同じであることが求められます。 Servingでは、オンライン・オフラインで使用する特徴量の生成過程を抽象化し、データにアクセスする方法を標準化します。
Storage
Feature StoreではServing レイヤからの呼び出しに応じるために特徴量を保持しています。
これは通常、上図のように、オンラインとオフラインのストレージに分けられ、状況に応じて使い分けられています。
オフラインストレージはモデルの学習用に数ヶ月〜数年分の特徴量データを保存するために使用されます。 オフラインの特徴量のデータは、S3、BigQuery、Snowflake、Redshiftなどを利用して保管されます。 データのサイロ化を防ぐために、既存のデータレイクやデータウェアハウスをオフラインのFeature Store用に拡張することが一般的に推奨されいているようです。
一方、オンラインストレージは、推論時に低レイテンシでアクセスできるようにする必要があります。 オンラインストレージは通常、最新の特徴量のみを保持しています。 そのため、オンラインストレージは通常、DynamoDB、Redis、CassandraなどのKey-Valueストアで実装されます。
各特徴量はエンティティとタイムスタンプに関連付けられるように、最小限の構造を提供するようデザインされます。
Transformation
機械学習では、新しいデータを特徴量として定期的に処理して新しい特徴量を作成し続けることが求められます。 Feature Store では、これらの値を生成するために、データの変換を管理・調整し、必要に応じて外部のシステムから生成された値を取り込む機能を提供します。
この変換にも、オフラインとオンライン、他に予測時にしか計算できない特徴量作成(on-demand)などに分けられます。 これらはSparkやPandasなどを使用して計算されることになります。
また、特徴量はしばしば過去値をもとに計算したくなります。 FeatureStoreでは、ある特徴量を新しく定義しそれを過去にさかのぼって計算するバックフィルをかんたんに実行できるようになっています。
Monitoring
機械学習のシステムで何かしらの問題が発生した際、データに問題あるケースがあります。 特徴量を管理しているFeature Storeでは、提供している特徴量に関して妥当性や品質について計算し、モニタリングすることが求められます。
妥当性はデータの構造的な基準に基づいて検証することができますし、品質についてはドリフト戸トレーニングのスキューを確認することでトラッキングされます。 モデルが学習したデータと推論に使用したデータ間で比較することで、モデルの性能を低下させる可能性のある不整合を検出できます。
また、運用指標についても監視する必要があります。 特に、ストレージに関する可用性、容量、使用率、またはサービングに関するスループット、レイテンシー、エラー率に関するメトリクス、特徴量生成に関するジョブ成功率、スループット、処理遅延、速度などは、運用上問題になるケースがあるのでこれらについてもモニタリングが必要で、Feature Storeではこれらについて監視ができるようになっています。
Registory
Feature Storeに欠かせないのが、特徴量の定義とメタデータの一元管理です。 特に、組織内で信頼できる唯一の情報源である必要があります。
レジストリはユーザーと特徴量のやり取りを行う中心的なインターフェースです。 レジストリ内の定義によって、特徴量計算の動作が設定され、レジストリの情報を使用してデータの取り込み・変換・保存をスケジュールしていきます。 また、レジストリにはメタデータが含まれ、どの特徴量が使用できて、誰がアクセス可能で、どのように提供されるのかが定義されていきます。
その他、主なプロダクト群
最後に、業界の動向について確認してみたいと思います。 OSSのものや企業独自で開発されているものと様々ですが、それぞれがどんな形で実現しているか確認してみます。
一応この辺りに主要なFeature Storeの概要が整理されています。
また、別のソースで紹介されていたプロダクト構成は下記のようになっています。
(出所: Feature Store For ML)
OSS
OSSとしてFeature Storeが提供されている事例について確認してみます。
Feast
Feastは様々なクラウドサービスを中心に構成できるFeature Storeです。
オフラインストレージにRedShiftやBigQuery、Snowflake、オブジェクトストレージなどが使用でき、オンラインストレージにDynamoDB、Redis、DataStoreなどが使用でき、特徴量作成にはApache BeamやPySparkを使用でき、機械学習モデルの開発とデータ管理を明確に分離している点が特徴的です。
さらにFeastでは、特徴量の管理、発見、バリデーション、集約といった機能を一元化して提供しています。
FeastはSalesforce、Twitterなどで導入されているようです。
Hopsworks
HopsworksはFeature StoreのOSSで、マネージドサービスも提供しています。 オンライン・オフラインストレージを両方使用でき、それらに格納された特徴量をAPIを経由して特徴量を呼び出すことができます。 各種クラウドサービスでも使用できるようで、メジャーなFeature Storeの製品の一つでしょう。
Wildlife Studiosなどで使用されているそうです。
Rasgo
RasgoはOSSで提供されているFeature Storeで、フルマネージド版も提供されています。
Storageには現状BigQueryとSnowflakeが使用可能らしく、ドキュメントを見る限り、オンラインストレージ等の機能は提供していない模様。（2022/03/20時点） 特徴量のメタデータの管理をすることで、特徴量の共有を容易にし、データドリフトやデータ品質に関するモニタリングの機能等が提供されています。
マネージドサービス
マネージドサービスだとざっと探しただけで下記のようなサービスが見つかりました。 マネージドサービスを使用してFeature Storeを作るならこの辺りでしょうか。
企業等の事例
実際に企業や組織内でFeature Storeが開発・運用されている事例について、気になった企業の事例を簡単に確認します。
Uber, Michaelengelo
Michelangeloでは、オフラインではバッチ学習・バッチ推論、オンラインでは高速なオンライン推論を可能にします。 Uberでは様々なチームで同じ特徴量を使用することが散見されており、Michelangeloでは他のチームで入念に作成されあ特徴量をチーム間で共有・発見できるように、特徴量を管理する機構を設けています。
オフラインでのFeature Storeでは、取引やログデータがHDFSデータレイクに蓄積されており、SparkやHive SQLを使って簡単に取り出せるようになっています。 一方、オンラインでは特徴量作成に対する時間的制約が厳しいことから、
- バッチで事前学習済みの特徴量を使用して学習・推論する
- kafkaで収集されたほぼリアルタイムの情報を使用して学習・推論する
の2種類から選択することで、特徴量を即時に応答することを可能にしています。
Airbnb, Zipline
AirbnbではZiplineというData management frameworkが運用されていて、そこでFeature Storeと同様の管理が行われています。 バッチ処理はデイリーでSparkで特徴量を作成し、オンラインではFlinkによって特徴量が作成されます。 そして、これらはそれぞれKey Value Storeに保存され、それらがZipline clientによって呼び出されるような形で、servingされるようになっています。
Spotify, Jukebox
SpotifyではJukeboxというFeature Storeを内製しています。 特徴量はJukeboxのエコシステムを通じて利用され、データリークが発生しないように学習データが用意されます。 オンライン推論のためにBigTableが使用され、その他はBigQueryやGCSをオフラインストレージとして利用して構成しているようです。
Zomato
インドのフードデリバリースタートアップであるZomatoはFeature Storeを自社で運用しています。
Zomatoでは、リアルタイムで作成される特徴量はApache Kafkaを使って計算され、ストリーム処理エンジンのApache Flinkでリアルタイムに処理されます。 これらは、Redis Clusterを利用したオンラインFeature Storeに保存されます。
一方、バッチ処理された特徴量は、Sparkを使って計算され、オフラインのFeature StoreのDynamoDBに保存され、新しい特徴量についてははRedis Clusterにキャッシュされるような構成になっているようです。
MLSysでの報告
MLSysで報告された論文でFeature Storeが紹介されています。 この事例では、特徴量の計算にApache Spark、データの格納にはHive、メタデータの格納にMySQL Clusterを使用しています。 このFeature Storeでは、選択した特徴量についてTensorFlow、Keras、Pytorch用のネイティブファイル形式のデータ生成もサポートしています。 これらの利用のためのPython APIも提供しています。
参考文献
今回の記事を書くにあたって下記の文献を参考にさせていただきました。
Feature Store: The missing data layer for Machine Learning pipelines?
What is a Feature Store? - Tecton
Vertex Feature Store で特徴量管理の MLOps はこう変わる | Google Cloud Blog
Vertex AI Feature Store の概要 | Google Cloud
Amazon SageMaker Feature Store (機械学習機能のフルマネージドリポジトリ) | AWS
Tecton: Enterprise Feature Store for Machine Learning
Enterprise Feature Store for Machine Learning Pipelines
GitHub - mlrun/mlrun: Machine Learning automation and tracking
Kaskada - The first feature engine with time travel | Kaskada
Meet Michelangelo: Uber's Machine Learning Platform
How Zomato Uses Machine Learning
Horizontally Scalable ML Pipelines with a Feature Store
日本語でも書いてある記事がありましたので、参考にさせていただきました。
Vertex Feature Storeの機械学習システムへの導入 - ZOZO TECH BLOG
感想
以上、社内の雑談のネタ用に書き始めた記事でした。 （まさかこれを書くためだけに英語の資料を何十本も読み漁る羽目になるとは…）
これで自分としては30~60分くらいの雑談のネタにはなりそうです。 読者のみなさまの、ちょっとした雑談の種になれば幸いです。
