特徴量ストア - yuuk1's Digital Garden

# 特徴量ストア ## 定義特徴量ストアとは、抽出された特徴量(とラベル)の値を保存し、モデルの訓練時・推論時に迅速かつ一貫した読み出しができるように設計されたストレージシステムである。特に、特徴量の定義と値が複数のモデル間で共有されるような大規模・集中管理サービスにおいて最も有用だが、全ての問題を解決するわけではない点に注意が必要である。『信頼性の高い機械学習』第4章は、特徴量ストアが備えるべき基本機能を、(1) 特徴量定義の保存(通常、生データから目的の形式で特徴量を出力するコードとして格納する)、(2) 特徴量の値そのものの保存、(3) 特徴量データの提供(高価な計算資源がI/O待ちで停止しないよう、タスクに適した性能で素早くアクセスできること)、(4) メタデータの書き込みをメタデータシステムと連携させること、の4点に整理する。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.1.3.2) 前提として、特徴量には「特徴量の定義」(基礎データから情報を抽出するコードやアルゴリズムの記述そのもの)と「特徴量の値」(そのコードを実データに適用して得られる具体的な出力)という2つの異なる意味があり、この区別が特徴量ストアの設計とライフサイクル管理の基礎になる。(Source: 同 §4.1) ### ストアの分類とアクセスパターン特徴量ストアは、データのアクセスパターン(特定の順序で読み込むか、読み込み/書き込み比率、追加のみか更新可能か、プライバシー・セキュリティ要件の有無)に応じて次の2バケットに大別される。 - **列指向ストア**: データは構造化され列に分解可能で、多くの場合時間などで順序付けられる。柔軟で効率的。 - **BLOBストア**: 順序を持たず構造化されていないデータ(バイトの束)を効率的に保存する。binary large objectsの略。多くの実例は両方の特徴を併せ持つ(例: 画像本体はBLOBだが、撮影日時・位置情報などの画像メタデータは列指向で扱える)。(Source: 同 §4.1.3.2) 「ライフサイクルアクセスのパターン」というコラムでは、常に再学習される少量データ(取り込みが遅くても前処理と読み出し効率を優先すべき)と、数回使って削除する大量データ(前処理を切り詰め安価な取り込みを優先すべき)という2類型を対比し、いずれの場合も削除のスコープ(期間別・エンドユーザー別など)をあらかじめ設計し、スコープ別の暗号化とキー削除によって効果的かつ低コストな削除を実現する設計原則が示される。(Source: 同 §4.1.3.2 コラム) ### 変換特徴量(transformed feature) 変換特徴量とは、1つ以上の特徴量列を組み合わせて計算した結果として得られる特徴量であり、バケッティング(連続値を離散カテゴリに分類すること、例: 年齢を年代別区分に変換)がその代表例である。歴史的には訓練パイプラインの別の場所(主に訓練フェーズ)で実装されることが多かったが、訓練用と推論(サービス提供)用の実装が食い違う「コードのドリフト」を招く。変換特徴量を特徴量ストアに移すことでこのドリフトを解消できる。計算負荷が高く頻繁に読み込まれる変換特徴量は、特徴量ストア側で結果を実体化(新しい列として事前計算・保存)することで計算・I/Oコストを大幅に削減できるが、(1) 特徴量定義変更時に全件の再計算が必要になる、(2) 新データ処理システムにバグがあると実体化列がデータと非同期になる、という2つのリスクを伴う。(Source: 同コラム「特徴量の変換」) ### 機械学習プラットフォームの一構成要素としての特徴ストア(3つの主要機能) [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] §10.4.3は、特徴ストア(feature store)を機械学習プラットフォーム(モデルストアと並ぶ構成要素)の一部として位置づけ、それが力を発揮しうる主要テーマを特徴管理(feature management)・特徴計算(feature computation)・特徴の一貫性(feature consistency)の3つに整理する。特徴ストアのソリューションの多くは、これらのテーマのうち1つまたは複数に対応する。 - **特徴管理**: 企業には複数のモデルがあり、それぞれ多数の特徴量を使用する(Uberは2017年当時チーム全体で約1万の特徴量を扱っていた)。ある特徴量が複数モデルで流用できることは珍しくなく、特徴ストアはチームが特徴量を発見・共有し、機密情報へのロールベースのアクセス制御を行える「特徴カタログ」として機能する。ツール例: Lyftが開発したAmundsen、LinkedInが開発したDataHub。 - **特徴計算**: 特徴量を定義した後、実データを参照して特徴エンジニアリングのロジックを計算する必要がある。計算コストが低ければモデルが必要とするたびに計算してもよいが、コストが高い場合は初回に一度だけ計算し保存しておくことが望まれる。この観点で特徴ストアはデータウェアハウスに似た働きをする。 - **特徴の一貫性**: 訓練パイプラインでバッチ特徴を抽出し推論パイプラインでストリーミング特徴を抽出するというように、同じモデルに対して2つの別々のパイプラインを持つと、開発時のPythonの特徴定義を本番用言語(Java・C言語等)に再度実装する必要が生じ、これが本番環境と訓練時の特徴の差異による不可解な不具合を招く。最新の特徴ストアの重要なセールスポイントは、バッチ特徴とストリーミング特徴の処理を統合し、この一貫性を確保することにある。本書執筆時点(2023年)で最も有名なオープンソースの特徴ストアは[[Feast]]だが、得意とするのはバッチ特徴でありストリーミング特徴ではない。Tectonはバッチ特徴とオンライン特徴の両方を扱えるフルマネージドサービスだが、インテグレーションの敷居の高さから普及が遅れている。2022年1月に著者が調査した95社のうち、特徴ストアを使用していると回答したのは約40%にとどまり、そのうち半数は自前で特徴ストアを構築している。(Source: 同 §10.4.3) 同著者による『機械学習システムデザイン』5章は、特徴エンジニアリングの文脈で特徴ストアに1段落だけ触れ、「特徴ストアがその解決策になると考える人がいるかもしれないが、すべての特徴ストアが特徴を管理できるわけではない」と釘を刺したうえで詳細を10章に委ねている。この一文は、10章が実例(Feastはバッチに強くストリーミングは弱い、Tectonは両対応だが導入障壁が高い)で示す「特徴管理・特徴計算・特徴の一貫性という3機能を全て満たすソリューションは希少である」という結論を、5章の時点で先取りして予告している。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 5 特徴エンジニアリング]] §5.4) ## 横断的知見 - **『機械学習システムデザイン』10章の「特徴管理/特徴計算/特徴の一貫性」という3機能軸は、『信頼性の高い機械学習』4章のAPI要件(定義・値・提供・メタデータ)と対応関係を持ちつつ視点が異なる**: 4章§4.1.3.2が挙げる(1)特徴量定義の保存は10章の「特徴管理」(特徴カタログとしての発見・共有)に、(2)特徴量の値そのものの保存と(3)特徴量データの提供は10章の「特徴計算」(計算結果の保存と高速な読み出し)に、それぞれ概ね対応する。しかし10章が独自に立てる「特徴の一貫性」(訓練・推論間のコードドリフト防止)という軸は、4章のAPI要件には直接対応する項目がなく、4章はむしろ「変換特徴量」節でこの同じ問題(訓練用と推論用の実装の食い違い)を、API要件とは別立てのコラムとして扱っている。つまり両ソースとも同じ課題(訓練/推論間の特徴定義の不一致)を認識しているが、4章はAPI設計の内部構造として、10章はビジネス上の機能テーマとして、異なる切り口で章立てしている。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.1.3.2, [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] §10.4.3) - **『信頼性の高い機械学習』が特徴量ストアのAPI要件(定義・値・提供・メタデータ)を内部設計として詳述するのに対し、『機械学習システムデザイン』はETLパイプラインの中でのその位置づけと、格納される特徴量の2分類(バッチ/ストリーミング)を外側から補う**: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]] の図3-7(ETLプロセスの概要)は、抽出・変換したデータの格納先としてデータウェアハウス・データベースと並べて「特徴ストア」を明示的に描き、特徴量ストアがETLパイプラインのload段階の一終着点であることを示す。さらに同章§3.6は、格納される特徴量を「バッチ処理で抽出されたバッチ特徴(静的特徴、例: ドライバーの評価のような変化の遅い特徴)」と「ストリーム処理で抽出されたストリーミング特徴(動的特徴、例: 対応可能なドライバー数のような急激に変化する特徴)」の2種に分ける。本conceptが『信頼性の高い機械学習』第4章から得た「列指向ストア対BLOBストア」というアクセスパターンによる分類は、データの*形状*(構造化か非構造化か)に基づく分類であるのに対し、『機械学習システムデザイン』のバッチ/ストリーミング分類は、データの*更新頻度と生成元パイプライン*に基づく直交する分類軸である。両者を組み合わせると、特徴量ストアの設計は「データ形状(列指向/BLOB)×更新頻度(バッチ/ストリーミング)」という2軸のグリッドで捉え直せる可能性がある。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.1.3.2, [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]] §3.4.2 図3-7、§3.6) ## 未解決の問い - 「データ形状(列指向/BLOB)×更新頻度(バッチ/ストリーミング)」という2軸のグリッドは、具体的な特徴量ストア実装(Feast、Tecton等)のオンラインストア/オフラインストアという二重構成とどう対応するか。本wikiにはまだ実装レベルのソースがない。 - 特徴量ストアのAPI要件(§4.1.3.2)は一般論として列挙されているが、具体的な商用・OSSの特徴量ストア(Feast、Tecton等)がこれらの機能をどう実装しているかは本章では扱われない。 - 変換特徴量の実体化(materialization)による性能向上と、定義変更時の全件再計算コストのトレードオフをどう定量的に判断するかの基準は本章に示されていない。 - ライフサイクルアクセスパターンのコラムが提案する「削除スコープ別の暗号化とキー削除」による効果的削除は、[[データのプライバシーと同意]] や [[差分プライバシー]] が扱う削除要件(忘れられる権利等)とどう接続するか。 - 10章は特徴ストア使用企業が約40%(2022年1月調査)にとどまり、そのうち半数が自前構築だったと報告するが、自前構築した企業が4章のAPI要件(定義・値・提供・メタデータ)と10章の3機能(管理・計算・一貫性)のどこまでを実装しているかは示されていない。実装レベルの充足度を扱う別ソースが必要。 ## 関連 - ソース: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] / [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]] / [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] - 概念: [[MLメタデータ管理]] / [[教師データのためのログ設計]] / [[特徴量削減]](本概念は特徴量の保存・提供基盤を扱うのに対し、[[特徴量削減]]は障害箇所特定における統計的なメトリクス削減を扱い、対象領域が異なる) / [[データフローエンジン]](バッチ特徴・ストリーミング特徴を生成する処理基盤) / [[機械学習基盤]](特徴ストアを含む機械学習プラットフォーム層全体) - 実体: [[YarnIt]] / [[Feast]] - 書籍: [[信頼性の高い機械学習]] / [[wiki/entities/機械学習システムデザイン|機械学習システムデザイン]] ## 出典 - Cathy Chen ほか, 『信頼性の高い機械学習 ―SRE 原則を活用した MLOps』, オライリー・ジャパン, 2024, 4 章 §4.1.3.2. - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]](§3.4.2 図3-7、§3.6 バッチ特徴/ストリーミング特徴) - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]](§10.4.3 特徴管理/特徴計算/特徴の一貫性の3機能) - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 5 特徴エンジニアリング]](§5.4 「すべての特徴ストアが特徴を管理できるわけではない」という予告)