Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — 2026 年 5 月、「本当にフィーチャーストアは要るのか?」という真面目な問い

2020〜2022 年のフィーチャーストア黄金期は終わった。2026 年 5 月現在、市場は二つに割れている。一方では **Tecton・Hopsworks・Chalk・Fennel のような専用プラットフォーム**がエンタープライズを取り、もう一方では **Databricks Unity Catalog + Feature Engineering、Snowflake Feature Store、Vertex AI Feature Store といったレイクハウス/ウェアハウスネイティブ統合**が「データ基盤の中に入っていればいいよね」と静かに市場を吸収した。

その結果、よく聞かれる質問が変わった。「どの製品を入れる?」ではなく **「うちに専用フィーチャーストアは要るのか? dbt でフィーチャーテーブルを作って Redis にキャッシュするだけで足りるのでは?」** だ。この記事はマーケティング比較表ではない。フィーチャーストアが本当に解いている問題、その問題が本当に別システムを要求するのか、2026 年の選択肢はどこまで来たのかをコードと一緒に整理する。

フィーチャーストアとは何で、何ではないか — レジストリ/マテリアライズ/サービングの分離

まず用語を厳密にする。「フィーチャーストア」とひと括りに呼ぶが、実際には三つの責務が一つの箱に詰まっている。

1. **フィーチャーレジストリ**: 「この特徴量は誰が作ったか、どのソースから、どの変換で、どの型で出るのか」のメタデータ。

2. **オフラインのマテリアライゼーション**: 過去の正しい時点で特徴量値を結合して学習データセットを作ること。

3. **オンラインサービング**: 推論時に最新の特徴量をミリ秒で返す Key-Value ルックアップ。

この三つは分離可能だ。dbt + Snowflake で 1・2 を、Redis で 3 を別々にやれば、それだけで軽量フィーチャーストアになる。Feast・Tecton・Hopsworks がやるのは **三つの責務を一つの API でまとめ、その間の整合性(特に学習-推論スキュー)をシステムが保証すること**だ。

本質的な問題 — 学習-推論スキュー(training-serving skew)はなぜ起こるか

フィーチャーストアが解いている唯一の本質的問題は **学習-推論スキュー**だ。学習時に見た特徴量値と推論時に見た特徴量値が微妙に違ってモデル性能が崩れる現象である。原因は地味だ。

- 学習時は **過去のある時点まで**のデータで特徴量を計算した。

- 推論時は **現在時点**のデータで特徴量を計算する。

- 二つのコードパスが別々の SQL/Python で書かれていて、時間処理が微妙に違う。

これを防ぐには (a) 特徴量定義が一箇所にあり、(b) ポイントインタイム結合が正確である必要がある。フィーチャーストアという製品カテゴリの存在理由はここに尽きる。

オンラインとオフラインのストア — なぜ二つのバックエンドを持つのか

フィーチャーストアはほぼ常に二つのバックエンドを持つ。

- **オフラインストア**: 学習データ生成用。Snowflake、BigQuery、Redshift、Iceberg/Delta on S3。ペタバイト級の履歴と時間範囲スキャンに最適化。

- **オンラインストア**: 推論サービング用。Redis、DynamoDB、Cassandra、ScyllaDB、Aerospike。Key ルックアップで p99 ≤ 10ms。

同じ特徴量が **異なる鮮度**で両方に存在する。オフラインには昨日までの全値、オンラインには「現在もっとも新しい一行」だけ。両者の同期(マテリアライゼーション)がフィーチャーストア運用の日常になる。

ポイントインタイム整合性 — 漏れのない学習データを作る

学習データ生成の難所は **「このユーザーがこのラベルを受け取った時刻 t において、その時点までに知れた特徴量値だけを取る」** ルールにある。これを守らないと未来情報が学習に漏れ込み、オフライン性能だけが過大評価される。

フィーチャーストアのポイントインタイム結合は、おおよそ次のような SQL を安全に書いてくれる。

-- ラベルイベントと特徴量テーブルの時間整合結合

SELECT

l.user_id,

l.event_ts,

l.label,

f.feature_value

FROM labels l

LEFT JOIN LATERAL (

SELECT feature_value

FROM user_features f

WHERE f.user_id = l.user_id

AND f.event_ts <= l.event_ts

ORDER BY f.event_ts DESC

LIMIT 1

) f ON TRUE;

手書きすると `<` と `<=` を取り違えたり、結合順がずれたりして微小な漏洩が混ざる。`get_historical_features` の役割は、その安全性をシステム側が引き受けることにある。

Feast — CNCF サンドボックス、OSS の事実上の標準

[Feast](https://feast.dev) は元 Gojek/Google のエンジニアが 2020 年に作った OSS フィーチャーストアで、2024 年に CNCF サンドボックス入りした。2026 年 5 月現在、もっとも広く使われている OSS だ。「BYO バックエンド」哲学を取り、Feast 自体はメタデータレジストリと SDK だけを提供し、オフラインは BigQuery/Snowflake/Redshift/Spark、オンラインは Redis/DynamoDB/Postgres/Bigtable を差し込んで使う。

典型的な Feature View はこう書く。

from datetime import timedelta

from feast import Entity, FeatureView, Field, FileSource

from feast.types import Float32, Int64

driver = Entity(name="driver", join_keys=["driver_id"])

driver_stats_source = FileSource(

name="driver_stats_source",

path="data/driver_stats.parquet",

timestamp_field="event_timestamp",

)

driver_stats_fv = FeatureView(

name="driver_hourly_stats",

entities=[driver],

ttl=timedelta(days=1),

schema=[

Field(name="conv_rate", dtype=Float32),

Field(name="acc_rate", dtype=Float32),

Field(name="avg_daily_trips", dtype=Int64),

source=driver_stats_source,

)

`feast apply` でレジストリ登録、`feast materialize` でオフラインからオンラインへ同期する。バックエンド選択は `feature_store.yaml` で決める。

project: prod_recsys

registry:

registry_type: sql

path: postgresql://feast:***@registry-db:5432/feast

provider: aws

online_store:

type: redis

connection_string: "redis-prod.cluster.local:6379"

offline_store:

type: snowflake.offline

account: xy12345

warehouse: COMPUTE_WH

database: ML

schema: FEATURES

entity_key_serialization_version: 2

学習時は `store.get_historical_features(entity_df, ...)`、推論時は `store.get_online_features(...)` で取る。シンプルさが武器で、ストリーミング特徴量は弱い(Push API か外部ストリームエンジンが必要)。

Tecton — 商用 SaaS、バッチとストリーミングを同一デコレータで

[Tecton](https://www.tecton.ai) は元 Uber Michelangelo のメンバーが 2019 年に起業した商用プラットフォーム。2024 年に実験分析ツール Eppo の一部資産を取り込み、「特徴量 + 実験 + モデル監視」へ領域を広げた。最大の強みは **バッチ・ストリーミング・on-demand 特徴量を同じデコレータモデルで定義する**点。

from tecton import stream_feature_view, FilteredSource, Aggregation

from datetime import timedelta

@stream_feature_view(

source=FilteredSource(transactions_stream),

entities=[user],

mode="pyspark",

aggregations=[

Aggregation(column="amount", function="sum", time_window=timedelta(minutes=10)),

Aggregation(column="amount", function="count", time_window=timedelta(hours=1)),

online=True,

offline=True,

feature_start_time=datetime(2024, 1, 1),

)

def user_txn_aggregates(transactions):

return transactions.select("user_id", "amount", "timestamp")

Spark Streaming/Flink の上で窓集約を自動で回し、同じ定義から過去の学習データセットも作れる。トレードオフ: 高価、そして Tecton のプレーンが顧客 VPC/アカウントに食い込む構成なので運用面の負担はそれなりにある。

Hopsworks — エンタープライズ + OSS、欧州発の本命

[Hopsworks](https://www.hopsworks.ai) はスウェーデンの Logical Clocks(2023 年に Hopsworks AB へリブランド)が作ったフルスタック ML プラットフォーム。フィーチャーストアが中心だが、モデルレジストリ・サービング・ベクトルインデックスまで同じ箱に入っている。Apache 2.0 の OSS 版と SaaS 版(Serverless 含む)が並走する。

オフラインストアは自社の Hudi ベースまたは外部 Snowflake/BigQuery、オンラインストアは RonDB(MySQL Cluster ベースのインメモリ KV)または外部システム。RonDB の強みはトランザクション保証とミリ秒 p99 を両方押さえている点で、これは珍しい。

project = hopsworks.login()

fs = project.get_feature_store()

fg = fs.get_or_create_feature_group(

name="user_txn_aggregates",

version=1,

primary_key=["user_id"],

event_time="event_ts",

online_enabled=True,

)

fg.insert(txn_df, write_options={"wait_for_job": True})

fv = fs.create_feature_view(

name="user_fraud_features",

version=1,

query=fg.select_all(),

labels=["is_fraud"],

)

train_df, test_df = fv.train_test_split(test_size=0.2)

GDPR/EU AI Act 対応に強く、欧州金融での採用率が高い。

Databricks Feature Engineering in Unity Catalog — レイクハウスネイティブの答え

Databricks は 2023 年まで別系統の Workspace Feature Store を持っていたが、2024 年に **Unity Catalog 上の通常の Delta テーブルがそのまま特徴量テーブルになる**という単純化に踏み切った。独立したメタデータ系は消え、特徴量は UC テーブルになり、権限・系統・検索は UC が一手に引き受ける。

from databricks.feature_engineering import FeatureEngineeringClient

from databricks.feature_engineering import FeatureLookup

fe = FeatureEngineeringClient()

fe.create_table(

name="ml.user_features.transaction_summary",

primary_keys=["user_id"],

timestamp_keys=["event_ts"],

df=summary_df,

)

training_set = fe.create_training_set(

df=labels_df,

feature_lookups=[

FeatureLookup(

table_name="ml.user_features.transaction_summary",

feature_names=["amount_7d_sum", "amount_30d_avg"],

lookup_key="user_id",

timestamp_lookup_key="event_ts",

)

label="fraud",

)

オンラインサービングは Databricks Online Tables(Lakebase ベース)で、同じ UC テーブルを自動ミラーする。すでに Databricks に深く乗っているチームなら、別ベンダーの検証は事実上オプションになった。

Vertex AI Feature Store — GCP 陣営の統合型

[Vertex AI Feature Store](https://cloud.google.com/vertex-ai/docs/featurestore) は 2023 年に大幅再設計(Feature Store 2.0)され、BigQuery をオフラインバックエンドに、BigQuery + Bigtable または Optimized Online Store をオンラインバックエンドに使う構成になった。ユーザーが BigQuery のビューを Feature View として登録すると、Vertex が自動的にオンラインミラーを作ってミリ秒サービングする。

別途 ETL がほとんど要らないのが強みで、弱みは GCP ロックインと、Tecton/Hopsworks ほどのストリーミング自由度がない点。Dataflow/Pub-Sub と組ませて鮮度を上げるケースが多い。

SageMaker Feature Store — AWS 純正

[SageMaker Feature Store](https://aws.amazon.com/sagemaker/feature-store) は AWS が 2020 年に投入したマネージド製品。オフラインは S3 + Athena/Glue、オンラインは DynamoDB ベースのインメモリ KV。グルーピングの単位は **Feature Group**で、同じデータが同期/非同期で両ストアに流れる。

2024 年に追加された **In-Memory Online Store** は p99 < 5ms を出せて、広告入札のような超低遅延経路にも使える水準になった。SageMaker Studio/Pipelines/Model Registry との統合が強み。バッチ変換は EMR/Glue、ストリーミング変換は Kinesis Data Analytics/Flink を載せる構成が定番だ。

Featureform と軽量代替 — 「仮想フィーチャーストア」というアプローチ

[Featureform](https://www.featureform.com) は「物理データを動かさず、既存基盤(Snowflake、BigQuery、Spark、Redis、DynamoDB)の上に仮想層だけ被せる」というコンセプトで出てきた。Featureform は定義・系統・アクセス制御を持ち、実データはユーザーの既存システムに置いたまま。導入コストが低いのが利点で、欠点は「定義だけあって実行は外」のため運用負担をユーザーに戻す点。

同じ系統では **TensorFlow TFX FeatureColumn**(レガシー)、**PyTorch TorchRec**(推薦モデル向け埋め込みテーブル)、**Airflow + Redis** の手組みもいまだに多い。Splice Machine(2022 年閉鎖)・Logical Clocks(Hopsworks 統合)のような撤退事例もあるので、OSS の活性度確認は新規導入時の必須項目だ。

Bytewax — Python ネイティブのストリーミング特徴量エンジン

[Bytewax](https://www.bytewax.io) は Rust コアの上に Python データフロー API を提供するストリーム処理エンジン。Kafka/Kinesis/Pulsar を受けて、窓集約・結合・セッション化のような変換を Python で書く。Flink/Spark Streaming ほどの生パワーは譲るが、**データサイエンティスト自身が運用できる Python コード**であることが武器だ。

from bytewax.connectors.kafka import KafkaSource, KafkaSink

from bytewax.dataflow import Dataflow

flow = Dataflow("user-amount-1min")

stream = op.input("kafka-in", flow, KafkaSource(brokers=["kafka:9092"], topics=["txns"]))

keyed = op.key_on("key-by-user", stream, lambda r: r["user_id"])

windowed = op.windowed_reduce(

"amount-1min-sum",

keyed,

clock=...,

windower=...,

builder=lambda: 0.0,

folder=lambda acc, r: acc + r["amount"],

)

op.output("kafka-out", windowed, KafkaSink(brokers=["kafka:9092"], topic="features"))

Bytewax 自体はフィーチャーストアではない。出力を Feast/Tecton のオンラインストア(Redis)に直接書くか、Kafka 経由で Feast の Push API に流すかで使う。

Materialize・RisingWave・Feldera・ksqlDB — ストリーミング SQL で特徴量を作る

ストリーミング特徴量へのもう一つの道は **ストリーミング SQL エンジン**だ。`CREATE MATERIALIZED VIEW` を一度書けば、入って来るイベントに合わせて結果が増分更新され、そのままオンラインストアに書き出せる。

- **Materialize**: 差分データフロー(differential dataflow)基盤。ANSI SQL 互換が強く、整合性に厳しい。2024 年に BYOC モード追加。

- **RisingWave**: ストリーム処理と永続状態を一体化。PostgreSQL ワイヤ互換。

- **Feldera**: DBSP(Database Stream Processor)論文ベースの増分計算エンジン。2024 年に OSS 公開。

- **ksqlDB**: Confluent の Kafka ネイティブストリーミング SQL。

最大の利点は同じ SQL がバッチ(過去の学習データ)とストリーミング(現在の特徴量)の両方に通用すること。学習-推論スキューを生むコードパスの分岐を根から減らせる。

-- Materialize/RisingWave: ユーザー別の直近 10 分の取引合計 (ストリーミング)

CREATE MATERIALIZED VIEW user_amount_10m AS

SELECT

user_id,

SUM(amount) AS amount_10m_sum,

COUNT(*) AS txn_10m_count

FROM transactions

WHERE event_ts >= mz_now() - INTERVAL '10 minutes'

GROUP BY user_id;

このビューが Redis に流れれば、それがそのままオンライン特徴量になる。

Fennel と Chalk — トランザクショナル/外部 API 統合型のフィーチャーストア

フィンテック・決済・保険でもっとも素早く地歩を固めた二つの新興勢力だ。

[Fennel.ai](https://fennel.ai) は「SQL ではなく **Python データフレーム API** でバッチ・ストリーミング特徴量を一つの定義で書く」というコンセプトで 2022 年に登場。差別化ポイントは **トランザクショナル整合性** で、同一ユーザーに対する特徴量更新が決済・イベント順序と同じ順序で適用される。2025 年に Stripe が Fennel を買収。外部 SaaS としての活動は減ったが、トランザクショナルフィーチャーストアという発想自体が決済業界の標準になる兆しと受け止められている。Stripe 内部の不正検知特徴量基盤として残る可能性が高い。

[Chalk.ai](https://chalk.ai) は 2022 年登場の商用プラットフォーム。Python クラスで特徴量を定義し、バッチとストリーミング両方の経路を自動生成する。強みは (a) 外部 API 呼び出しを 1 級の特徴量として扱う(例: 信用情報 API のレスポンスをキャッシュ可能な特徴量として)、(b) 推論時に必要な特徴量グラフを自動でトポロジカルソートして呼び出す、の二点。2026 年 5 月現在フィンテック・保険領域でシェアを伸ばしている。欠点はクローズドソース SaaS と価格。

埋め込みが特徴量になるとき — ベクトル DB との収束

2024 年までは埋め込み(ベクトル)は別系統のトラックだった。2026 年には **埋め込みも特徴量の一種**として扱われる。Tecton/Hopsworks/Feast すべてがベクトル型を 1 級でサポートし、オンラインストアとして Pinecone/Weaviate/Milvus/PostgreSQL pgvector を登録できる。

帰結は二つ。一つはベクトル DB が「埋め込み専用フィーチャーストア」としてポジショニングされる流れ(Pinecone Serverless、Weaviate Cloud)。もう一つはフィーチャーストアがベクトルインデックスを吸収して統合 SDK へ向かう流れ(Hopsworks Vector Index)。2027 年には両者の境界はほぼ消える可能性が高い。

特徴量の監視 — ドリフト検知が 1 級市民になる

2026 年のフィーチャーストアの第二の責務は **特徴量自身の品質監視**だ。分布のドリフト、欠損率の急増、カーディナリティ爆発、時間単位の鮮度 SLO を自動でみる。Evidently AI、Arize、WhyLabs、Fiddler のような監視ツールがフィーチャーストアと直結し、Tecton・Hopsworks は自社監視を内蔵する。

要点は **モデル性能が落ちたときにモデル問題かデータ/特徴量問題かを素早く切り分けられること**にある。特徴量ドリフトを見ていないと、モデルだけ再学習し続けて根本原因を見落とす。

比較表 — 2026 年フィーチャーストア地図を一目で

| --- | --- | --- | --- | --- | --- | --- | --- |

| Chalk.ai | クローズド | 強 | 強 | 自社 | 自社/外部 | 強 | SaaS |

| Fennel(Stripe) | クローズド | 非常に強 | 強 | 自社 | 自社 | 強 | 内部化 |

データコントラクトとモデル-特徴量グラフ — ガバナンスの背骨

フィーチャーストアを運用するとやがて **データコントラクト**の問題に収束する。誰かが上流テーブルのスキーマを変えると特徴量計算が壊れ、モデル推論も壊れる。2026 年のよいフィーチャーストアは (a) 上流ソースのスキーマ変更を自動検知し、(b) 影響を受ける Feature View とモデルを系統グラフで見せ、(c) 互換性のない変更を事前に止める。Databricks UC のカラムマスキング/系統、Tecton の source tracking、Hopsworks の schema evolution policy が代表例だ。

その上に **モデル-特徴量の双方向グラフ**が必要になる。Feature X が消えれば影響を受けるモデル一覧が、Model Y の入力としてどの Feature が使われているかが即座にわかる必要がある。MLflow Model Registry、Databricks UC のモデル系統、Tecton の Feature Service-Model リンク、外部カタログ(DataHub、OpenMetadata)との連携がこの層を担う。これが欠けたフィーチャーストアは自重で崩れる。

レイクハウス統合仮説 — 「フィーチャーストアは製品ではなく層だ」

2025 年以降もっとも強い流れは **フィーチャーストアが独立した製品ではなく、レイクハウスの一層として吸収される**ことだ。Databricks が Workspace Feature Store を UC FE に統合したのは決定的なシグナルで、Snowflake も Snowpark + Snowflake Feature Store(2024 年 GA)で同じ道を行った。Iceberg + Polaris/Tabular 陣営も同方向だ。

この仮説が正しければ、2027〜2028 年には「専用フィーチャーストア」というカテゴリーはフィンテック・広告など超低遅延・トランザクショナル領域だけに残り、一般 ML はレイクハウス内で完結する。前提は **オンラインストア統合が十分に速いこと**で、2026 年 5 月時点では Online Tables/Bigtable 統合はまだフィンテック水準には届いていない。

「dbt + Redis で十分では?」への正直な答え

この記事でいちばん正直に書くべき部分だ。次の条件をすべて満たすなら **専用フィーチャーストアなしで足りる**。

- 本番モデル数が 5 以下。

- 特徴量がほぼバッチ(時間単位/日次)。1 分以下の鮮度は要らない。

- 同じ特徴量を複数モデルが共有する場面が少ない。

- 学習-推論整合性を保てる責任者が明確で、ポイントインタイム結合を自前で書ける。

- ガバナンス/監査要件が軽い。

逆に次のどれか一つでも当てはまるなら、専用フィーチャーストアが答えになる可能性が高い。

- モデル数が数十〜数百に増えつつある。

- ストリーミング特徴量に 1 秒〜 1 分単位の鮮度が要る。

- 同一特徴量を 5 つ以上のモデルが共有する。

- 規制(GDPR、EU AI Act、各国個人情報保護法)で系統が必要。

- 不正検知・推薦・広告のようにミリ秒のオンラインルックアップが基幹経路にある。

韓国の導入事例 — Coupang・Toss・Naver

- **Coupang** は推薦・ランキング・物流 ETA モデル向けの内製フィーチャー基盤を 2021 年頃から運用している。Coupang Engineering Blog 等の社外発表で Spark + Redis + 自社メタデータ層という構造が公開され、2025〜2026 年には Iceberg ベースのオフライン + Aerospike/Redis オンラインへ進化したとされる。

- **Toss** は不正検知・推薦・信用評価で Kafka + Flink + Redis のストリーミング特徴量パイプラインを SLASH カンファレンスで共有している。フルスタック単一のストアより「ドメインごとに短いパイプラインを持つ」分散戦略が特徴。

- **Naver** は Hyperion のような内部 ML プラットフォームに特徴量管理コンポーネントを置き、HBase/Redis/MySQL をバックエンドにする構造を公開してきた。検索・ショッピング・CLOVA がそれぞれ変形して使う。

三社とも **純粋な OSS(Feast)や SaaS(Tecton)単独導入より、自社ビルドまたは部分流用**を選んだ。トラフィック規模とドメイン固有性が、既製品のままでは扱いにくい領域にある。

日本の導入事例 — Mercari・ZOZO・CyberAgent

- **Mercari** は 2022〜2023 年に Feast ベースの自社フィーチャー基盤構築事例を Mercari Engineering Blog で公開した。BigQuery オフライン + Redis オンライン + Vertex AI 学習パイプラインの組み合わせだ。

- **ZOZO** は推薦・検索特徴量を BigQuery + Memorystore Redis で運用するパターンを ZOZO TECH BLOG で何度も公開している。一部モデルで Vertex AI Feature Store 検討事例も報告された。

- **CyberAgent AI Lab** は広告・ゲーム推薦でストリーミング特徴量パイプライン(Kafka + Flink/Beam + Bigtable)構築事例を ai-tech-publish 等で共有した。広告入札のようなミリ秒領域は別インメモリ KV に切り出す典型パターンを示している。

三社とも日本特有の「BigQuery 中心 + GCP マネージド活用」戦略を踏襲する傾向がある。

2026〜2027 年の見通し — 統合・縮小・専門化

三つの流れが同時に進む。

1. **レイクハウス吸収**: 汎用 ML は Databricks UC FE、Snowflake Feature Store に吸収される。

2. **OSS 中位の縮小**: Feast が標準位置を固める一方、二番手以下の OSS は活性度が落ちる。

3. **専門化 SaaS の生存**: フィンテック・広告・不正検知のようにミリ秒トランザクショナル特徴量が必要な領域は Tecton/Hopsworks/Chalk が残る。

ストリーミング SQL 陣営(Materialize、RisingWave、Feldera)が「フィーチャーストア」として直接ポジショニングしてくるのも興味深い変数だ。2027 年には「フィーチャーストア vs ストリーミング DB」の境界自体が曖昧になる可能性が高い。

おわりに — 製品ではなく責務を選ぶ

フィーチャーストアの選定は結局 **三つの責務(レジストリ・整合性・サービング)を誰に任せるか**の意思決定だ。すでに Databricks/Snowflake/GCP/AWS のどれかに深く乗っているなら、まずそのプラットフォームのネイティブ機能で足りるかを検証する。マルチクラウドあるいはストリーミング鮮度が核なら Tecton/Hopsworks/Chalk を見る。軽量な OSS 標準が要るなら Feast だ。

最後に運用が静かに崩れるアンチパターンを短く挙げる。(1) 再利用されない一過性 SQL まで特徴量登録してカタログを汚す。(2) オンライン鮮度 SLO(p99 ≤ X 分)を明文化しない。(3) ドリフト監視がなく、モデルだけを疑い続ける。(4) 特徴量ごとの owner 欄が空で、半年後に誰も触れない。(5) 特徴量定義への単体・回帰テストがなく、小さな変更が学習-推論スキューを生む。

「本当にフィーチャーストアが要るのか?」に正直に答えよう。モデル数が 10 未満でバッチ中心なら、よく作り込んだ dbt + Redis キャッシュもまた立派なフィーチャーストアだ。製品はその後の話である。

References

- Feast 公式ドキュメント: https://docs.feast.dev/

- Tecton 公式ドキュメント: https://docs.tecton.ai/

- Hopsworks 公式ドキュメント: https://docs.hopsworks.ai/

- Databricks Feature Engineering: https://docs.databricks.com/aws/en/machine-learning/feature-store/

- Vertex AI Feature Store: https://cloud.google.com/vertex-ai/docs/featurestore

- SageMaker Feature Store: https://aws.amazon.com/sagemaker/feature-store/

- Bytewax 公式ドキュメント: https://docs.bytewax.io/

- Materialize 公式ドキュメント: https://materialize.com/docs/

- RisingWave 公式ドキュメント: https://docs.risingwave.com/

- Feldera GitHub: https://github.com/feldera/feldera

- Featureform 公式ドキュメント: https://docs.featureform.com/

- Chalk.ai 公式ドキュメント: https://docs.chalk.ai/

- Fennel.ai ブログ(Stripe 買収前): https://fennel.ai/blog

- ksqlDB 公式ドキュメント: https://docs.ksqldb.io/

- Feast GitHub: https://github.com/feast-dev/feast

- Apache Flink 公式ドキュメント: https://flink.apache.org/docs/

- Snowflake Feature Store: https://docs.snowflake.com/en/developer-guide/snowflake-ml/feature-store/overview

- Evidently AI 公式ドキュメント: https://docs.evidentlyai.com/

- Arize AI 公式ドキュメント: https://docs.arize.com/arize

- Coupang Engineering Blog: https://medium.com/coupang-engineering

- Toss Engineering(SLASH): https://toss.tech/

- Mercari Engineering Blog: https://engineering.mercari.com/en/blog/

- ZOZO TECH BLOG: https://techblog.zozo.com/

- CyberAgent AI Tech Publish: https://ai-tech.cyberagent.co.jp/

- classmethod.jp Feature Store: https://dev.classmethod.jp/articles/?s=feature+store