Feast 0.27+ 强制区分 online_store（低延迟 KV，如 Redis）与 offline_store（批量处理，如 BigQuery），二者不可混用；FeatureView 的 ttl 仅作用于 online_store，表名/实体键不匹配将导致 get_online_features 返回 None，且无 fallback 机制。
Feast 0.27+ 特征仓库必须区分 online_store 和 offline_store
Feast 不是“一键同步”工具，它强制要求你为在线（低延迟查询）和离线（批量训练）场景分别配置存储后端。混淆两者会导致 FeatureView 注册失败或 get_online_features 返回空/超时。
常见错误现象：OnlineStoreConfig 缺失、用 FileOfflineStore 当作 online_store、Redis 配置未启用 redis-py 连接池导致 QPS 下降。
-
offline_store推荐用BigQueryOfflineStore（GCP）、SparkOfflineStore（数据湖）、或本地FileOfflineStore（仅开发） -
online_store必须是低延迟 KV 存储：生产环境用RedisOnlineStore或DynamoDBOnlineStore；本地调试可用SqliteOnlineStore（但不支持并发写入） - 同一
FeatureView的ttl（如timedelta(hours=1)）只影响 online_store 的过期逻辑，不影响 offline_store 中原始数据保留时间
注册 FeatureView 时 offline_table 和 online_table 名称不一致怎么办
Feast 不自动推导表名映射。如果你在 BigQuery 中的离线表叫 my_dataset.user_features_v1，但 online_store 里 Redis 的 key 前缀设成 fv:user_activity，Feast 不会报错，但 get_online_features 查不到数据——因为特征值根本没写进去。
关键原因：Feast 在 materialize() 阶段只把离线数据读出、按 FeatureView.ttl 和 entity_columns 聚合后，原样写入 online_store，**不校验 key 结构是否匹配线上服务预期**。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 检查
FeatureView.online_entity_names是否与你调用get_online_features(entity_rows=[...])传入的字段名完全一致（大小写敏感） - 用
feast materialize-incremental时，确保起始时间戳早于离线数据中最早事件时间，否则 Redis 里没写入任何记录 - 调试技巧：直接连 Redis 执行
KEYS "fv:user_features_v1:*"看是否有 key 写入；若无，说明materialize流程中断（常因 Spark job 失败或 BigQuery 权限不足）
get_online_features 返回 None 或 KeyError
这不是 Feast bug，而是实体键（entity key）未命中 online_store 中已 materialize 的记录。典型表现：训练时用 A 用户 ID 拿到特征，推理时用 B 用户 ID 却返回 None，且无报错。
根本原因：Feast 的 online_store 是纯 key-value 缓存，不提供 fallback 到离线 store 的能力（即 no “online serving with offline fallback”）。
- 确认
entity_rows中每个 dict 的 key 名与Entity.name完全一致，例如定义了Entity(name="user_id", ...)，就必须传{"user_id": 123}，不能传{"uid": 123} - Redis 中 key 格式默认为
f{feature_view_name}:{entity_key_value}，如果自定义了online_store.key_ttl_seconds过短（如 60），而你的业务请求间隔长于该值，key 已被自动清理 - 用
get_online_features时传入多个 entity_rows，但部分用户从未被materialize过——Feast 不会过滤掉无效项，而是静默返回对应位置为None，需业务层主动判空
Python SDK 调用 online_store 的性能瓶颈在哪
单次 get_online_features 调用平均耗时超过 50ms，大概率卡在 Redis 连接建立或序列化环节，而非网络延迟。
Feast Python SDK 默认为每次调用新建 Redis 连接，高并发下会迅速打满连接数限制，触发 ConnectionError: Error 24 connecting to localhost:6379. Too many open files.
- 必须显式复用
Redis连接池：在 Feast 初始化时传入redis.Redis(connection_pool=pool)，其中pool = redis.ConnectionPool(..., max_connections=50) - 避免在循环里反复创建
FeatureStore实例；应全局复用一个实例，它内部已缓存 registry 和 online_store client - 如果使用
SqliteOnlineStore，注意其get_online_features是文件锁操作，QPS 上限约 5–10，仅限本地验证，不可用于压测
最易被忽略的一点：Feast 的 get_online_features 不支持异步 I/O，如果你的服务本身是 async（如 FastAPI + uvicorn），需用 loop.run_in_executor 包一层，否则会阻塞整个 event loop。
