2026/9/17 7:13:12
FEATURED · 精选文章 
Feast SQLite Online Store从 feature_store.yaml 配置到源码实现的本地在线特征服务【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feastFeast 的 SQLite Online Store 是最轻量的在线存储后端它把特征值物化到一个磁盘上的 SQLite 数据库文件中供 Python/Go SDK 在线读取。本文基于 SQLite Online Store 官方参考文档 展开结合 SqliteOnlineStore 源码实现、Go 端实现 与 单元测试完整讲解其配置项、底层数据模型、读写路径、plan/update/teardown 基础设施管理以及向量与全文检索扩展能力帮助你在本地开发、示例演示或轻量级部署中正确配置并理解它的行为边界。一、定位与核心特征按照 官方文档 的定义SQLite Online Store 提供将特征值物化materialize到 SQLite 数据库以进行在线特征服务的能力其核心特征是所有特征值存储在磁盘上的 SQLite 数据库中——整个后端就是单个.db文件无需额外安装数据库服务仅持久化每个 key 的最新特征值——写入采用 upsert 语义历史值不保留这与文档功能矩阵中不支持 TTL、不支持过期数据删除是同一枚硬币的两面。源码层面同样明确了它的定位边界。SqliteOnlineStore 类的 docstring 直接写明SQLite implementation of the online store interface. Not recommended for production usage.也就是说它是 Feast 核心在线存储实现之一与 Redis、DynamoDB、Snowflake、Datastore 并列见 在线存储总览但官方建议将其用于本地开发、快速上手、演示与测试场景而非生产环境。这一判断也体现在它的功能短板上见第七节功能矩阵不支持同 key 并发写、不支持 TTL、Java SDK 无法读取。二、配置在 feature_store.yaml 中启用 sqlite online store启用方式非常直接。在特征仓库根目录的feature_store.yaml中把online_store.type设为sqlite并指定数据库文件路径即可project: my_feature_repo registry: data/registry.db provider: local online_store: type: sqlite path: data/online_store.db仓库中的 MCP Feature Store 示例配置 就是一个真实用例type: sqlite、path: data/online_store.db并搭配type: file的离线存储和type: mcp的 Feature Server构成一个完全本地化的运行形态。快速入门文档 与 feature-store-yaml 参考文档 中给出的默认仓库模板也采用同样的 SQLite 在线存储。2.1 配置项全集文档指出完整配置项见SqliteOnlineStoreConfig。对照 源码中的 Pydantic 模型定义 及其混入的 VectorStoreConfig配置项全集如下配置项类型默认值说明typeLiteral[sqlite]sqlite在线存储类型选择器也接受完整类名feast.infra.online_stores.sqlite.SqliteOnlineStore见_get_db_path中的断言L232-L243pathStrictStrdata/online.dbSQLite 数据库文件路径若为相对路径会基于特征仓库路径repo_path解析为绝对路径vector_enabledOptional[bool]False是否启用向量相似检索依赖sqlite_vec扩展见第六节similarityOptional[str]cosineKNN 检索的向量相似度度量主要服务于不支持在检索时动态配置度量的向量库text_search_enabledboolFalse是否启用基于 SQLite FTS5/BM25 的全文检索enable_openai_compatible_storeboolFalse是否以OpenAI 兼容存储模式运行写入时为每行物化value_text数值化列value_num使检索支持基于特征数值的元数据过滤注意一个容易踩坑的细节path的解析逻辑在_get_db_path中——只有当配置了repo_path且path是相对路径时才会拼接成repo_path / path否则原样使用。这意味着feast materialize、feast apply等操作在不同工作目录下执行时实际读写的.db文件可能位于不同位置排障时应以特征仓库根目录为基准确认数据库文件位置。三、底层数据模型每个 Feature View 一张表SQLite Online Store 的数据模型是按 Feature View 共置collocated by feature view——这与功能矩阵中 collocated by feature view: yes 一致。每个启用在线服务的 Feature View 对应一张物理表表名由compute_table_id即源码中的_table_id基于 project 名与 Feature View 名计算因此测试中可以看到test_project_driver_dropoffs_stream这类表名test_sqlite_plan.py。3.1 表结构update()方法 与SqliteTable.update()中的 DDL 揭示了完整的表结构CREATE TABLE IF NOT EXISTS table_name ( entity_key BLOB, -- 序列化后的实体 keyEntityKeyProto - 二进制 feature_name TEXT, -- 特征名 value BLOB, -- ValueProto 的 protobuf 序列化结果读取时反序列化 value_text TEXT, -- 值的人读文本形式过滤辅助列 value_num REAL, -- 可选列仅 enable_openai_compatible_store 时创建数值化形式 vector_value BLOB, -- 可选列vector_enabled 时写入 f32 序列化向量 event_ts timestamp, -- 事件时间戳UTC naive created_ts timestamp, -- 物化/写入时间戳 PRIMARY KEY (entity_key, feature_name) )并会为每张表额外创建entity_key索引CREATE INDEX IF NOT EXISTS table_ek ON table (entity_key)。几个值得注意的实现细节复合主键(entity_key, feature_name)是仅保留最新值的根本保证。写入使用INSERT ... ON CONFLICT(entity_key, feature_name) DO UPDATE SET ...的 upsert 语句online_write_batch L324-L328同一实体同一特征的新值会整体覆盖旧值而不是追加。entity_key以 BLOB 存储写入前调用serialize_entity_key按entity_key_serialization_version版本序列化L332-L335读取时再反序列化。这也解释了为什么 SQLite 在线存储与 Go SDK 的 key 序列化版本必须保持一致。value存的是ValueProto的 protobuf 字节val.SerializeToString()L345读取时用ValueProto.ParseFromString还原online_read L408-L409。这一protobuf 透传方式使 Python 与 Go 两个 SDK 可以无损地共享同一份数据。时间类型适配模块顶部通过sqlite3.register_adapter注册了date/datetime的 ISO 8601 与 Unix epoch 两种适配以及对应的 converterL74-L111配合建连接时的detect_typesPARSE_DECLTYPES | PARSE_COLNAMES_initialize_conn L911-L929使event_ts、created_ts列能以原生 Pythondatetime对象读出。安全加固所有表名/列名拼接前都会经过_quote_id的双引号转义注释明确说明其目的是防止 SQL 注入。四、写路径与读路径4.1 写入online_write_batchonline_write_batch 的写入流程是通过_get_conn懒加载连接首次访问时才sqlite3.connect且check_same_threadFalse解析 Feature View 的特征类型字典、表名并根据enable_openai_compatible_store检查表中是否已存在value_num列结果会被缓存在_table_has_value_num中逐行执行参数化 upsertentity_key序列化、时间戳统一转为 UTC naiveto_naive_utc每个(entity_key, feature)对写入一行value为 protobuf 字节、value_text为文本形式可选写入value_num数值与vector_value若该特征是向量类型则按 Feature View 的vector_length元数据做serialize_f32序列化默认长度 512整个批次包在单个with conn:事务中提交并对每个实体调用progress(1)回调供上层展示物化进度。一个实用的行为差异如果配置了enable_openai_compatible_store: true但表里还没有value_num列源码不会报错而是打印警告Runfeast applyto add it. Writing without value_num.L304-L309即降级为不带数值列的写入。因此修改该开关后必须执行一次feast apply让 schema 变更落地。4.2 读取online_readonline_read 是一次典型的批量点查把所有EntityKeyProto序列化成二进制后用一条SELECT entity_key, feature_name, value, event_ts FROM table WHERE entity_key IN (?, ?, ...) ORDER BY entity_key一次性取回用itertools.groupby按entity_key分组逐实体重建feature_name - ValueProto字典并统一把时间戳规整为 UTC未命中的实体返回(None, None)由上层在线服务将其解析为空特征值而不是抛错。Go SDK 侧的SqliteOnlineStore.OnlineRead采用完全一致的读法mattn/go-sqlite3驱动打开同一文件按 feature view 逐个执行IN (...)查询用proto.Unmarshal把value字节还原为types.Value再按实体 key 的 hash 索引回填到结果矩阵。这也印证了功能矩阵中 readable by Go: yes 且 readable by Java: no仓库 Go 目录存在独立实现Java serving 模块则没有对应存储。五、基础设施生命周期plan / update / teardownSQLite Online Store 完整实现了OnlineStore接口的五个方法功能矩阵中对应的四行 update / teardown / plan: yes 都能从源码逐一对应update()L423-L458对保留的表执行CREATE TABLE IF NOT EXISTS与索引创建对需要删除的表执行DROP TABLE IF EXISTS。由于 SQLite 的ALTER TABLE ADD COLUMN不支持IF NOT EXISTS源码封装了_alter_table_add_column_if_missing——捕获 duplicate column name 的OperationalError并静默忽略其他错误照常抛出以此实现幂等的列升级value_text、value_num。teardown()L500-L522比单纯 drop 表更彻底——先关闭连接然后直接os.unlink删除整个.db文件并对PermissionError做最多 10 次、间隔 0.25 秒的重试。这意味着feast teardown后数据库文件本身就不存在了。plan()L460-L498从 registry proto 反解出全部 Feature View / Stream Feature View / 在线 Label View为每一个生成一个SqliteTable基础设施对象含path、name、include_value_num序列化为SqliteTableProto对应 protos/feast/core 下的SqliteTable.proto供feast diff类命令做基础设施变更规划。值得注意的是plan()必须区分FeatureView.from_proto与StreamFeatureView.from_proto——回归测试 专门验证了registry 中只有流特征视图与批、流视图混合两种场景都能正确产出SqliteTable列表这是一个曾经因类型检查导致崩溃的真实缺陷。SqliteTable作为InfraObject的实现L966 起把CREATE TABLE / CREATE INDEX / ALTER逻辑收敛到update()中并附带同样受 Python 版本约束的sqlite_vec加载逻辑是feast apply在 SQLite 后端上的实际执行单元。六、向量检索与全文检索扩展虽然文档主体描述的是常规在线服务但当前源码中 SQLite 后端还内置了两种检索扩展对应配置项vector_enabled与text_search_enabled6.1 向量相似检索sqlite_vec开启vector_enabled: true后写入时向量类型的特征会被serialize_f32序列化为定长 float32 BLOB 存入vector_value列L350-L365检索入口retrieve_online_documents会动态创建vec0虚拟表、把目标向量字段的数据灌入再用WHERE vector_value MATCH ? ORDER BY distance LIMIT ?做 KNN最后 join 回主表取回entity_key、原始值与时间戳从源码结构看sqlite_vec扩展的加载被限制在Python 3.10sys.version_info[0:2] (3, 10)L246-L252 与 L1014-L1021且扩展缺失时仅告警降级其他 Python 版本无法启用向量路径。Feature View 中必须声明且仅声明一个带向量索引的字段否则_get_vector_field会直接断言失败。6.2 全文检索FTS5 BM25与元数据过滤开启text_search_enabled: true后retrieve_online_documents_v2会基于fts5创建search_tabletokenizeporter unicode61将 Feature View 的全部 STRING 类型特征列灌入用bm25(search_table, ...)计分并ORDER BY distance LIMIT top_k完成关键词检索若检索时携带数值条件过滤filters则必须同时开启enable_openai_compatible_store: true并运行feast apply生成value_num列否则抛出明确异常L688-L715。过滤条件由SqliteFilterTranslator翻译成entity_key IN (SELECT entity_key FROM ... WHERE feature_name ? AND value_num op ?)形式的子查询支持eq/ne/gt/gte/lt/lte/in/nin及AND/OR复合条件。这些扩展能力使 SQLite 后端在本地场景下甚至可以承担轻量的向量/全文 元数据过滤型文档检索但请注意其仍受单文件数据库的并发与容量限制约束。七、功能矩阵与适用边界以下是 官方文档 给出的完整功能矩阵可直接对照 在线存储功能总览 与其他实现比较能力Sqlite写入特征值到在线存储yes从在线存储读取特征值yes更新基础设施如表yes拆除基础设施如表yes生成基础设施变更计划planyes支持 on-demand transformsyes可被 Python SDK 读取yes可被 Java 读取no可被 Go 读取yes支持无实体entitylessFeature Viewyes支持同 key 并发写入no支持检索时 TTLno支持删除过期数据no按 Feature View 共置yes按 Feature Service 共置no按实体 key 共置no结合源码可以把这几项 no 理解为工程取舍而非遗漏无并发写SQLite 的写锁与单文件模型决定了同一 key 的高并发更新不是它的设计目标源码中连接仅懒加载一次并长期持有_conn面向单进程物化/服务场景。无 TTL / 无过期删除因为 upsert 只保留最新值时间维度信息仅体现在event_ts中存储层不做过期清理。无 Java 读取仓库的java/serving模块没有 SQLite 存储实现只有 Python 与 Gogo/internal/feast/onlinestore/sqliteonlinestore.go两条读取路径。plan 能力独有优势在总览矩阵中支持 generate a plan of infrastructure changes 的核心实现只有 SQLite 与 Cassandra这意味着 SQLite 后端可以完整地配合feast diff/feast apply做声明式基础设施演进。适用建议本地开发与学习feast init默认形态、快速演示与 notebook 实验如 MCP Feature Store 示例、credit-risk 端到端示例 均使用 sqlite 在线存储、CI 测试与离线评估生产环境请换用总览矩阵中的其他在线存储。八、参考文件索引官方参考文档docs/reference/online-stores/sqlite.md在线存储对比总览docs/reference/online-stores/overview.mdPython 实现sdk/python/feast/infra/online_stores/sqlite.py向量配置基类sdk/python/feast/infra/online_stores/vector_store.pyplan 回归测试sdk/python/tests/unit/infra/online_store/test_sqlite_plan.pyGo 实现go/internal/feast/onlinestore/sqliteonlinestore.go实际配置示例examples/mcp_feature_store/feature_store.yaml配置参考docs/reference/feature-repository/feature-store-yaml.md【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Feast SQLite Online Store：从 feature_store.yaml 配置到源码实现的本地在线特征服务
Feast SQLite Online Store从 feature_store.yaml 配置到源码实现的本地在线特征服务【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feastFeast 的 SQLite Online Store 是最轻量的在线存储后端它把特征值物化到一个磁盘上的 SQLite 数据库文件中供 Python/Go SDK 在线读取。本文基于 SQLite Online Store 官方参考文档 展开结合 SqliteOnlineStore 源码实现、Go 端实现 与 单元测试完整讲解其配置项、底层数据模型、读写路径、plan/update/teardown 基础设施管理以及向量与全文检索扩展能力帮助你在本地开发、示例演示或轻量级部署中正确配置并理解它的行为边界。一、定位与核心特征按照 官方文档 的定义SQLite Online Store 提供将特征值物化materialize到 SQLite 数据库以进行在线特征服务的能力其核心特征是所有特征值存储在磁盘上的 SQLite 数据库中——整个后端就是单个.db文件无需额外安装数据库服务仅持久化每个 key 的最新特征值——写入采用 upsert 语义历史值不保留这与文档功能矩阵中不支持 TTL、不支持过期数据删除是同一枚硬币的两面。源码层面同样明确了它的定位边界。SqliteOnlineStore 类的 docstring 直接写明SQLite implementation of the online store interface. Not recommended for production usage.也就是说它是 Feast 核心在线存储实现之一与 Redis、DynamoDB、Snowflake、Datastore 并列见 在线存储总览但官方建议将其用于本地开发、快速上手、演示与测试场景而非生产环境。这一判断也体现在它的功能短板上见第七节功能矩阵不支持同 key 并发写、不支持 TTL、Java SDK 无法读取。二、配置在 feature_store.yaml 中启用 sqlite online store启用方式非常直接。在特征仓库根目录的feature_store.yaml中把online_store.type设为sqlite并指定数据库文件路径即可project: my_feature_repo registry: data/registry.db provider: local online_store: type: sqlite path: data/online_store.db仓库中的 MCP Feature Store 示例配置 就是一个真实用例type: sqlite、path: data/online_store.db并搭配type: file的离线存储和type: mcp的 Feature Server构成一个完全本地化的运行形态。快速入门文档 与 feature-store-yaml 参考文档 中给出的默认仓库模板也采用同样的 SQLite 在线存储。2.1 配置项全集文档指出完整配置项见SqliteOnlineStoreConfig。对照 源码中的 Pydantic 模型定义 及其混入的 VectorStoreConfig配置项全集如下配置项类型默认值说明typeLiteral[sqlite]sqlite在线存储类型选择器也接受完整类名feast.infra.online_stores.sqlite.SqliteOnlineStore见_get_db_path中的断言L232-L243pathStrictStrdata/online.dbSQLite 数据库文件路径若为相对路径会基于特征仓库路径repo_path解析为绝对路径vector_enabledOptional[bool]False是否启用向量相似检索依赖sqlite_vec扩展见第六节similarityOptional[str]cosineKNN 检索的向量相似度度量主要服务于不支持在检索时动态配置度量的向量库text_search_enabledboolFalse是否启用基于 SQLite FTS5/BM25 的全文检索enable_openai_compatible_storeboolFalse是否以OpenAI 兼容存储模式运行写入时为每行物化value_text数值化列value_num使检索支持基于特征数值的元数据过滤注意一个容易踩坑的细节path的解析逻辑在_get_db_path中——只有当配置了repo_path且path是相对路径时才会拼接成repo_path / path否则原样使用。这意味着feast materialize、feast apply等操作在不同工作目录下执行时实际读写的.db文件可能位于不同位置排障时应以特征仓库根目录为基准确认数据库文件位置。三、底层数据模型每个 Feature View 一张表SQLite Online Store 的数据模型是按 Feature View 共置collocated by feature view——这与功能矩阵中 collocated by feature view: yes 一致。每个启用在线服务的 Feature View 对应一张物理表表名由compute_table_id即源码中的_table_id基于 project 名与 Feature View 名计算因此测试中可以看到test_project_driver_dropoffs_stream这类表名test_sqlite_plan.py。3.1 表结构update()方法 与SqliteTable.update()中的 DDL 揭示了完整的表结构CREATE TABLE IF NOT EXISTS table_name ( entity_key BLOB, -- 序列化后的实体 keyEntityKeyProto - 二进制 feature_name TEXT, -- 特征名 value BLOB, -- ValueProto 的 protobuf 序列化结果读取时反序列化 value_text TEXT, -- 值的人读文本形式过滤辅助列 value_num REAL, -- 可选列仅 enable_openai_compatible_store 时创建数值化形式 vector_value BLOB, -- 可选列vector_enabled 时写入 f32 序列化向量 event_ts timestamp, -- 事件时间戳UTC naive created_ts timestamp, -- 物化/写入时间戳 PRIMARY KEY (entity_key, feature_name) )并会为每张表额外创建entity_key索引CREATE INDEX IF NOT EXISTS table_ek ON table (entity_key)。几个值得注意的实现细节复合主键(entity_key, feature_name)是仅保留最新值的根本保证。写入使用INSERT ... ON CONFLICT(entity_key, feature_name) DO UPDATE SET ...的 upsert 语句online_write_batch L324-L328同一实体同一特征的新值会整体覆盖旧值而不是追加。entity_key以 BLOB 存储写入前调用serialize_entity_key按entity_key_serialization_version版本序列化L332-L335读取时再反序列化。这也解释了为什么 SQLite 在线存储与 Go SDK 的 key 序列化版本必须保持一致。value存的是ValueProto的 protobuf 字节val.SerializeToString()L345读取时用ValueProto.ParseFromString还原online_read L408-L409。这一protobuf 透传方式使 Python 与 Go 两个 SDK 可以无损地共享同一份数据。时间类型适配模块顶部通过sqlite3.register_adapter注册了date/datetime的 ISO 8601 与 Unix epoch 两种适配以及对应的 converterL74-L111配合建连接时的detect_typesPARSE_DECLTYPES | PARSE_COLNAMES_initialize_conn L911-L929使event_ts、created_ts列能以原生 Pythondatetime对象读出。安全加固所有表名/列名拼接前都会经过_quote_id的双引号转义注释明确说明其目的是防止 SQL 注入。四、写路径与读路径4.1 写入online_write_batchonline_write_batch 的写入流程是通过_get_conn懒加载连接首次访问时才sqlite3.connect且check_same_threadFalse解析 Feature View 的特征类型字典、表名并根据enable_openai_compatible_store检查表中是否已存在value_num列结果会被缓存在_table_has_value_num中逐行执行参数化 upsertentity_key序列化、时间戳统一转为 UTC naiveto_naive_utc每个(entity_key, feature)对写入一行value为 protobuf 字节、value_text为文本形式可选写入value_num数值与vector_value若该特征是向量类型则按 Feature View 的vector_length元数据做serialize_f32序列化默认长度 512整个批次包在单个with conn:事务中提交并对每个实体调用progress(1)回调供上层展示物化进度。一个实用的行为差异如果配置了enable_openai_compatible_store: true但表里还没有value_num列源码不会报错而是打印警告Runfeast applyto add it. Writing without value_num.L304-L309即降级为不带数值列的写入。因此修改该开关后必须执行一次feast apply让 schema 变更落地。4.2 读取online_readonline_read 是一次典型的批量点查把所有EntityKeyProto序列化成二进制后用一条SELECT entity_key, feature_name, value, event_ts FROM table WHERE entity_key IN (?, ?, ...) ORDER BY entity_key一次性取回用itertools.groupby按entity_key分组逐实体重建feature_name - ValueProto字典并统一把时间戳规整为 UTC未命中的实体返回(None, None)由上层在线服务将其解析为空特征值而不是抛错。Go SDK 侧的SqliteOnlineStore.OnlineRead采用完全一致的读法mattn/go-sqlite3驱动打开同一文件按 feature view 逐个执行IN (...)查询用proto.Unmarshal把value字节还原为types.Value再按实体 key 的 hash 索引回填到结果矩阵。这也印证了功能矩阵中 readable by Go: yes 且 readable by Java: no仓库 Go 目录存在独立实现Java serving 模块则没有对应存储。五、基础设施生命周期plan / update / teardownSQLite Online Store 完整实现了OnlineStore接口的五个方法功能矩阵中对应的四行 update / teardown / plan: yes 都能从源码逐一对应update()L423-L458对保留的表执行CREATE TABLE IF NOT EXISTS与索引创建对需要删除的表执行DROP TABLE IF EXISTS。由于 SQLite 的ALTER TABLE ADD COLUMN不支持IF NOT EXISTS源码封装了_alter_table_add_column_if_missing——捕获 duplicate column name 的OperationalError并静默忽略其他错误照常抛出以此实现幂等的列升级value_text、value_num。teardown()L500-L522比单纯 drop 表更彻底——先关闭连接然后直接os.unlink删除整个.db文件并对PermissionError做最多 10 次、间隔 0.25 秒的重试。这意味着feast teardown后数据库文件本身就不存在了。plan()L460-L498从 registry proto 反解出全部 Feature View / Stream Feature View / 在线 Label View为每一个生成一个SqliteTable基础设施对象含path、name、include_value_num序列化为SqliteTableProto对应 protos/feast/core 下的SqliteTable.proto供feast diff类命令做基础设施变更规划。值得注意的是plan()必须区分FeatureView.from_proto与StreamFeatureView.from_proto——回归测试 专门验证了registry 中只有流特征视图与批、流视图混合两种场景都能正确产出SqliteTable列表这是一个曾经因类型检查导致崩溃的真实缺陷。SqliteTable作为InfraObject的实现L966 起把CREATE TABLE / CREATE INDEX / ALTER逻辑收敛到update()中并附带同样受 Python 版本约束的sqlite_vec加载逻辑是feast apply在 SQLite 后端上的实际执行单元。六、向量检索与全文检索扩展虽然文档主体描述的是常规在线服务但当前源码中 SQLite 后端还内置了两种检索扩展对应配置项vector_enabled与text_search_enabled6.1 向量相似检索sqlite_vec开启vector_enabled: true后写入时向量类型的特征会被serialize_f32序列化为定长 float32 BLOB 存入vector_value列L350-L365检索入口retrieve_online_documents会动态创建vec0虚拟表、把目标向量字段的数据灌入再用WHERE vector_value MATCH ? ORDER BY distance LIMIT ?做 KNN最后 join 回主表取回entity_key、原始值与时间戳从源码结构看sqlite_vec扩展的加载被限制在Python 3.10sys.version_info[0:2] (3, 10)L246-L252 与 L1014-L1021且扩展缺失时仅告警降级其他 Python 版本无法启用向量路径。Feature View 中必须声明且仅声明一个带向量索引的字段否则_get_vector_field会直接断言失败。6.2 全文检索FTS5 BM25与元数据过滤开启text_search_enabled: true后retrieve_online_documents_v2会基于fts5创建search_tabletokenizeporter unicode61将 Feature View 的全部 STRING 类型特征列灌入用bm25(search_table, ...)计分并ORDER BY distance LIMIT top_k完成关键词检索若检索时携带数值条件过滤filters则必须同时开启enable_openai_compatible_store: true并运行feast apply生成value_num列否则抛出明确异常L688-L715。过滤条件由SqliteFilterTranslator翻译成entity_key IN (SELECT entity_key FROM ... WHERE feature_name ? AND value_num op ?)形式的子查询支持eq/ne/gt/gte/lt/lte/in/nin及AND/OR复合条件。这些扩展能力使 SQLite 后端在本地场景下甚至可以承担轻量的向量/全文 元数据过滤型文档检索但请注意其仍受单文件数据库的并发与容量限制约束。七、功能矩阵与适用边界以下是 官方文档 给出的完整功能矩阵可直接对照 在线存储功能总览 与其他实现比较能力Sqlite写入特征值到在线存储yes从在线存储读取特征值yes更新基础设施如表yes拆除基础设施如表yes生成基础设施变更计划planyes支持 on-demand transformsyes可被 Python SDK 读取yes可被 Java 读取no可被 Go 读取yes支持无实体entitylessFeature Viewyes支持同 key 并发写入no支持检索时 TTLno支持删除过期数据no按 Feature View 共置yes按 Feature Service 共置no按实体 key 共置no结合源码可以把这几项 no 理解为工程取舍而非遗漏无并发写SQLite 的写锁与单文件模型决定了同一 key 的高并发更新不是它的设计目标源码中连接仅懒加载一次并长期持有_conn面向单进程物化/服务场景。无 TTL / 无过期删除因为 upsert 只保留最新值时间维度信息仅体现在event_ts中存储层不做过期清理。无 Java 读取仓库的java/serving模块没有 SQLite 存储实现只有 Python 与 Gogo/internal/feast/onlinestore/sqliteonlinestore.go两条读取路径。plan 能力独有优势在总览矩阵中支持 generate a plan of infrastructure changes 的核心实现只有 SQLite 与 Cassandra这意味着 SQLite 后端可以完整地配合feast diff/feast apply做声明式基础设施演进。适用建议本地开发与学习feast init默认形态、快速演示与 notebook 实验如 MCP Feature Store 示例、credit-risk 端到端示例 均使用 sqlite 在线存储、CI 测试与离线评估生产环境请换用总览矩阵中的其他在线存储。八、参考文件索引官方参考文档docs/reference/online-stores/sqlite.md在线存储对比总览docs/reference/online-stores/overview.mdPython 实现sdk/python/feast/infra/online_stores/sqlite.py向量配置基类sdk/python/feast/infra/online_stores/vector_store.pyplan 回归测试sdk/python/tests/unit/infra/online_store/test_sqlite_plan.pyGo 实现go/internal/feast/onlinestore/sqliteonlinestore.go实际配置示例examples/mcp_feature_store/feature_store.yaml配置参考docs/reference/feature-repository/feature-store-yaml.md【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
