特征存储的核心价值在于把特征计算逻辑、特征元数据和特征值统一管理起来，避免训练阶段和推理阶段使用不同的特征口径。传统做法里，数据工程师在离线环境用Spark计算特征，算法工程师在训练时直接读取离线表，而在线推理常常由后端工程师重新实现一遍特征逻辑，导致同一批特征出现多个版本。引入特征存储后，特征定义只维护一次，离线任务可以批量回填历史特征，在线服务按相同逻辑读取实时特征，模型上线后的表现会稳定很多。
把特征存储部署到Kubernetes，不是为了追新的基础设施，而是因为特征服务天然适合容器化编排。特征服务本身是无状态的API，可以水平扩展；离线特征计算是批处理任务，可以用Job或CronJob调度；注册中心和在线存储虽然是有状态组件，但也可以通过StatefulSet或外部托管服务接入。Kubernetes的声明式配置和自动恢复能力，正好覆盖了特征存储日常运维中最容易出问题的几个环节。
一、特征存储组件与Kubernetes部署形态
特征存储一般由四个核心部分组成：注册中心、离线存储、在线存储和特征服务。注册中心保存特征视图、实体、数据源等元数据，通常使用PostgreSQL或MySQL这类关系型数据库。离线存储负责存放历史特征值，可以是对象存储加Spark计算引擎，也可以是ClickHouse等分析型数据库。在线存储面向低延迟读取，常见选择有Redis、Cassandra、DynamoDB等。特征服务则是应用访问特征数据的统一入口，提供HTTP或gRPC接口。
在Kubernetes上部署时，需要把这些组件映射成不同的工作负载。特征服务适合使用Deployment管理，配合Service暴露端口，Ingress或Gateway处理外部流量。离线特征计算任务可以用CronJob定时执行，也可以提交Spark Application到集群上运行。注册中心如果放在集群内部，可以部署为单副本或主从模式的StatefulSet，并挂载持久卷。在线存储不建议直接跑在Kubernetes里，优先使用云厂商托管的Redis或Cassandra服务，这样能避免有状态服务扩容、备份和故障转移带来的复杂度。
以Feast为例，它的组件主要包括registry、offline store、online store和feature server。Feast的feature server是一个独立的无状态进程，启动后可以从注册中心加载特征元数据，并通过gRPC或HTTP接口对外提供在线特征查询。Kubernetes的HPA可以直接作用在feature server的Deployment上，根据CPU使用率或请求延迟自动调整副本数。离线物化任务则通过feast materialize命令触发，把特征从离线存储写入在线存储，这个命令可以封装成CronJob定期执行。
二、使用Helm部署Feast到Kubernetes
Helm是当前Kubernetes生态中最常用的包管理工具，Feast社区提供了基础Helm Chart，可以快速安装feature server和相关依赖。开始之前需要准备好Kubernetes集群、Helm命令行工具，以及一个可用的对象存储和数据库。对象存储可以使用MinIO搭建在集群内部，也可以直接使用云上的S3兼容存储。注册中心推荐使用PostgreSQL，在线存储使用Redis，这些组件可以先以外部服务的形式接入，降低初次部署的复杂度。
首先添加Helm仓库并创建独立的命名空间，避免与其他业务应用相互影响。执行以下命令完成基础安装：
helm repo add feast-charts https://feast-helm-charts.storage.googleapis.com helm repo update kubectl create namespace feast helm install feast feast-charts/feast -n feast -f values.yaml
values.yaml是配置入口，需要指定feature server的镜像、服务类型以及在线存储连接信息。一个最小可用的配置示例如下：
featureServer:
enabled: true
image:
repository: feastdev/feature-server
tag: 0.36.0
service:
type: ClusterIP
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
onlineStore:
type: redis
redis:
host: redis.feast.svc.cluster.local
port: 6379
registry:
type: postgres
host: postgres.feast.svc.cluster.local
database: feast
user: feast
password: feast安装完成后，可以用kubectl get pods -n feast查看feature server是否正常运行。此时还需要配置feature_store.yaml文件，让Feast组件知道注册中心和存储的具体位置。这个文件通常放在代码仓库中，由特征工程团队维护，而Helm values只管理运行时的服务配置，两者职责不同，尽量不要混在一起。
三、离线与在线特征存储接入实践
离线存储的选择直接影响特征回填和物化的效率。如果团队规模较小，可以先用文件存储配合本地Spark任务跑通流程。对于生产环境，建议使用S3加上Spark集群，或者使用云上的数据仓库。Feast的离线存储支持file、s3、bigquery、redshift等类型，配置文件里指定type和路径即可。对象存储需要保证feature server和离线任务都能访问，例如通过Kubernetes ServiceAccount绑定IAM角色，而不是把访问密钥硬编码到配置里。
下面是一个使用S3作为离线存储、Redis作为在线存储的feature_store.yaml示例：
project: fraud_detection registry: registry_store_type: SQLRegistry path: postgresql://feast:feast@postgres.feast.svc.cluster.local:5432/feast offline_store: type: s3 s3_endpoint: http://minio.feast.svc.cluster.local:9000 bucket: feast-offline online_store: type: redis connection_string: redis.feast.svc.cluster.local:6379
定义特征时，需要先创建实体和数据源，再围绕实体创建特征视图。特征源可以是文件、数据表或流式主题。FeatureView中声明的schema就是特征元数据，它会被写入注册中心，供离线任务和在线服务共同使用。一个典型的Python定义如下：
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64
driver = Entity(name="driver_id", join_keys=["driver_id"])
driver_stats_source = FileSource(
path="s3://features/driver_stats.parquet",
timestamp_field="event_timestamp",
)
driver_hourly_stats = FeatureView(
name="driver_hourly_stats",
entities=[driver],
schema=[
Field(name="conv_rate", dtype=Float32),
Field(name="acc_rate", dtype=Float32),
Field(name="avg_daily_trips", dtype=Int64),
],
source=driver_stats_source,
ttl=None,
)执行feast apply命令会把特征元数据同步到注册中心。之后需要运行物化任务，把离线存储中的特征值加载到在线存储。物化命令可以手动执行，也可以封装成CronJob。对于大型特征集，建议使用增量物化，只处理最近时间段的数据，减少每次任务的运行时间。在线特征查询时，feature server会根据请求中的实体键从Redis读取特征值，并按照特征视图定义返回结果。
四、生产环境监控与扩缩容策略
特征存储上线后，需要关注四类指标：特征服务请求量、请求延迟、在线存储容量和离线任务运行时长。可以在feature server上暴露Prometheus指标端点，配合Grafana仪表盘查看服务状态。请求延迟是模型在线推理链路中的重要一环，如果特征获取延迟从10毫秒上升到100毫秒，整个推理服务的响应时间也会显著增加，因此需要设置合理的告警阈值。在线存储的容量也要持续监控，尤其是在物化任务频繁写入的情况下，Redis内存使用率不能超过物理内存的70%。
Kubernetes的HPA可以根据CPU或内存使用率自动调整feature server的副本数。对于延迟敏感的场景，建议使用自定义指标进行扩缩容，例如每个实例的请求QPS或平均响应时间。扩缩容时要注意在线缓存的一致性，feature server本身不保存特征值，只是从Redis读取，所以扩容和缩容都不会导致数据丢失。但如果Redis本身成为瓶颈，仅靠增加feature server副本并不能解决问题，需要评估是否升级Redis规格或引入本地缓存。
离线任务的监控同样重要。CronJob执行失败时，需要通知特征工程负责人。可以在任务末尾增加检查逻辑，验证物化后的特征行数是否符合预期，或者对比注册中心中的特征版本是否更新成功。日志可以输出到标准输出，由Kubernetes的日志采集系统统一收集。对于有状态的注册中心数据库，要配置定期备份，避免PostgreSQL实例故障导致特征元数据丢失。一个完整的生产部署至少需要做到：配置健康检查、设置资源上限、接入监控告警、定期备份数据库，只有这样才能让特征存储成为稳定的MLOps基础设施。
Kubernetes机器学习特征存储修改时间：2026-08-25 21:53:36