- Published on
Feature Store 与 Vector·Graph·时序 DB 融合指南: Feast·Tecton·Pinecone·Weaviate·Milvus·Neo4j·TimescaleDB (2025)
- Authors
- Name
- Youngju Kim
- @fjvbn20031
Season 5 Ep 6 — 如果说 Ep 5 讲的是“指标的语言”，那么 Ep 6 讲的就是 “AI·ML 所要求的特殊存储”。它们各自作为不同品类起步，但在 2025 年正以惊人的速度收敛。
- Prologue — “DB 地形因为 AI 被重新绘制了”
- 第 1 章 · Feature Store — ML 的语言
- 第 2 章 · Vector DB — AI 的语言
- 第 3 章 · Graph DB — 关系的语言
- 第 4 章 · 时序 DB — 运维的语言
- 第 5 章 · “Unified DB”的登场
- 第 6 章 · AI 给 DB 地形带来的冲击
- 第 7 章 · 选择指南
- 第 8 章 · 韩国企业的实务
- 第 9 章 · 三个案例研究
- 第 10 章 · 反模式 10 选
- 第 11 章 · 检查清单 — 引入特殊 DB 的 12 项
- 第 12 章 · 下一篇预告 — Season 5 Ep 7: “数据治理·Lineage·PII”
Prologue — “DB 地形因为 AI 被重新绘制了”
2015–2020 年，DB 的品类界线很清晰:
- OLTP: Postgres/MySQL
- OLAP: Warehouse
- NoSQL: Mongo/Cassandra/Redis
- 时序: InfluxDB
2022 年 LLM 热潮之后向量 DB 爆发，而 2024–2025 年反过来:
- Postgres + pgvector → 通用 DB 把向量吞了下去
- Lakehouse → 把特征·向量·时序一并容纳
- 时序 DB 增加了向量支持
- Graph DB 借 AI 推荐·GraphRAG 重新崛起
边界正在变得模糊。 这篇文章就来梳理这场混沌。
第 1 章 · Feature Store — ML 的语言
1.1 为什么需要它
- ML 模型训练与推理用了 不同的特征 就会产生 Online-Offline skew
- 每个团队各自重算自己的特征 → 重复·不一致
- 缺少可复现性·审计·治理
1.2 Feature Store 的两层结构
- Offline Store: 批量训练·回填 (Lakehouse/Iceberg/BigQuery)
- Online Store: 低延迟推理 (Redis/DynamoDB/Cassandra)
- 两层都由 同一份定义 生成
1.3 主要工具
- Feast (开源): 最受欢迎，由 Tecton 主导
- Tecton (商用): 实时 Feature Pipeline
- Hopsworks: End-to-End 的 ML 平台
- Databricks Feature Store: Delta 集成
- Vertex AI Feature Store: GCP
- SageMaker Feature Store: AWS
1.4 Feast 示例
from feast import Entity, FeatureView, Field
from feast.types import Float32
user = Entity(name='user', join_keys=['user_id'])
driver_stats = FeatureView(
name='user_stats',
entities=[user],
schema=[Field(name='avg_order_value', dtype=Float32)],
source=...
)
1.5 防止 Online-Offline Skew
- 用 同一套 SQL / 代码 生成两边的特征
- Point-in-time correctness: 训练用特征必须是当时那一刻的值
- Materialization: Offline → Online 的周期性同步
- Data validation: 检测分布异常
1.6 2024–2025 动向
- 在 Iceberg·Delta 之上构建 Feature Store 的做法增多
- 与实时 Feature Pipeline (Flink/RisingWave) 结合
- 也开始尝试用 Feature Store 管理 LLM RAG 的上下文数据
第 2 章 · Vector DB — AI 的语言
2.1 2022–2024 的爆发
- LLM RAG 热潮把向量 DB 这个品类推到台前
- Pinecone 的 B 轮 $100M (2023)
- Weaviate·Qdrant·Milvus·Chroma·LanceDB 等大量涌现
2.2 主要的向量 DB
| 名称 | 类型 | 特点 |
|---|---|---|
| Pinecone | SaaS | 业界领先，管理省心 |
| Weaviate | 开源+SaaS | 混合检索·模块化 |
| Milvus | 开源+SaaS | 大规模，Zilliz 做商用 |
| Qdrant | 开源+SaaS | Rust，性能快 |
| Chroma | 开源 | 嵌入式/对开发者友好 |
| LanceDB | 开源 | 基于文件，嵌入式 |
| pgvector | Postgres 扩展 | 集成进通用 DB |
| Vespa | 开源 | 源自 Yahoo，排序是强项 |
| Elasticsearch | 检索 + 向量 | 已有检索+向量 |
| Redis Vector | 内存 | 超低延迟 |
2.3 主要算法
- HNSW: 业界标准的近似最近邻检索
- IVF: 大规模下更高效
- ScaNN (Google): 大规模 + 精度
- DiskANN (Microsoft): 基于 SSD 的超大容量
2.4 混合检索
- Dense (向量) + Sparse (BM25) 结合
- 2024–2025 已成为默认标准
- Weaviate·Vespa·Elastic·OpenSearch 全都支持
2.5 Postgres + pgvector 的反击
- 2023–2024 年 pgvector 得到爆发式改进
- HNSW 索引、元数据过滤、混合检索
- “别再多建一个 DB，就在 Postgres 里做”成了 2025 年常见的选择
2.6 用在哪里
- RAG 的上下文检索
- 推荐系统
- 图像·视频·音频的相似度
- 聚类·异常检测
第 3 章 · Graph DB — 关系的语言
3.1 为什么又火起来了
- 基于知识图谱的 RAG (GraphRAG) 在 2024 年浮现
- 推荐·反欺诈·供应链分析
- LLM 利用结构化知识的模式
3.2 主要的 Graph DB
- Neo4j: 业界领先，Cypher 语言
- NebulaGraph: 源自中国，面向大规模
- Dgraph: 分布式 GraphQL
- TigerGraph: 高性能分析
- Amazon Neptune: AWS 托管
- ArangoDB: 多模型 (document+graph)
- Apache AGE: Postgres 扩展 (graph)
- Kuzu: 嵌入式 Graph (最近受关注)
3.3 查询语言
- Cypher: Neo4j 的标准，用得最广
- Gremlin: Apache TinkerPop
- GQL: ISO 标准化进行中
- GraphQL: 作为 API 语言被 Dgraph 等采用
3.4 GraphRAG
- 把相关实体·关系以图的形式提供给 LLM
- 对“这个人参与过的项目，核心负责人是谁?”这类提问很有优势
- Microsoft GraphRAG (2024)、LlamaIndex KnowledgeGraph 等
3.5 用在哪里
- 反欺诈 (交易网络)
- 推荐 (用户-商品-属性的关系)
- 知识图谱 (企业信息·学术·医疗)
- Supply chain、网络安全
3.6 局限与现实
- Graph DB 多数时候只负责“一部分”
- 主力仍是 Postgres/Warehouse，Graph 负责特定负载
- Apache AGE·Kuzu 这类轻量选项把门槛拉低了
第 4 章 · 时序 DB — 运维的语言
4.1 品类
- 专用: InfluxDB、TimescaleDB、VictoriaMetrics、QuestDB
- 对可观测性友好: Prometheus、M3、Cortex、Mimir、Thanos
- 内置于通用引擎: ClickHouse·BigQuery·Snowflake 也能处理时序
4.2 主要工具
- InfluxDB 3: 2024 年基于 Parquet/Arrow 重新设计
- TimescaleDB: Postgres 扩展，最通用
- VictoriaMetrics: 兼容 Prometheus，超高性能
- QuestDB: 超高速 ingest，SQL
- Prometheus: 监控标准，长期保存交给 Thanos/Cortex
- ClickHouse: 日志·指标·链路的统一
4.3 与 AI·ML 的相遇
- 生成时序特征 (Feature Store 的 source)
- 用 LLM 做时序异常检测·摘要
- 与预测模型 (Prophet、Nixtla) 结合
4.4 2024–2025 趋势
- OpenTelemetry 统一了三大信号 (Metric·Log·Trace)
- ClickHouse·SigNoz·Grafana Cloud Loki/Mimir/Tempo 成为统一后端
- TimescaleDB 吸收 Postgres 生态 + 也支持向量 (pgvector)
4.5 用在哪里
- APM·基础设施监控
- IoT·传感器数据
- 金融交易时间线
- 用户行为时间线
第 5 章 · “Unified DB”的登场
5.1 2024–2025 的现象
- Postgres + 扩展: OLTP + 向量 + 时序 + Graph (AGE)
- ClickHouse: OLAP + 日志/指标 + 向量 (2024 年扩展) + 相似度
- MongoDB: Document + Atlas Vector Search
- Elastic: 检索 + 向量 + 可观测性
- Snowflake/Databricks: Warehouse + 向量 + ML + 流式
5.2 为什么会走向统合
- 运维多个 DB 的成本
- 数据复制·一致性的负担
- 创业公司更愿意 先用一个起步
5.3 统合的局限
- 追不上专用引擎 (Pinecone·Neo4j·InfluxDB) 的性能与功能深度
- 到了大规模又得重新拆开
- “单一 DB vs 多个专用 DB”是按规模·负载来权衡的
5.4 2025 年的建议
- 早期 < 10M 条记录: 单一 DB (Postgres + 扩展) 就够
- 中期 10M–1B: 统合 DB + 少量专用
- 大规模 1B+: 按负载拆出专用 DB
第 6 章 · AI 给 DB 地形带来的冲击
6.1 向量 DB 的爆发 → 收敛
- 2022: 品类诞生
- 2023: 几十家厂商
- 2024: Postgres/ES/Mongo 吸收 → 专用向量 DB 聚焦大规模·超低延迟
6.2 Graph 的再发现
- GraphRAG·LLM 的知识底座
- 企业数据整合 (知识图谱)
- Neo4j·Microsoft GraphRAG 扩散
6.3 时序 + LLM
- 用自然语言向日志·指标提问
- 用 LLM 辅助预测·异常检测
- OpenTelemetry + LLM 可观测性平台
6.4 Feature Store 的扩张
- 从传统 ML 特征 → 连 LLM RAG 的上下文也一起管
- Vector + Feature 统合存储的实验
- 复用 Online-Offline 同步模式
6.5 警惕 DB Sprawl
- 每个产品 2–5 个 DB → 管理负担
- 2025 年的智慧: “专业的深度 vs 运维的简洁” 之间的平衡
第 7 章 · 选择指南
7.1 “需要专用向量 DB 的情况”
- 1 亿+ 向量，需要超低延迟
- 复杂的元数据过滤 + 混合检索
- 有专职 ML 团队
→ Pinecone、Weaviate、Milvus、Qdrant
7.2 “Postgres + pgvector 就够”
- < 1000 万向量
- 想复用已有的 Postgres 技术栈
- 优先考虑运维·审计的便利
7.3 “需要 Graph DB 的情况”
- 关系就是核心业务逻辑 (反欺诈·推荐)
- 递归/路径查询频繁
- 知识图谱规模很大
→ Neo4j、NebulaGraph、Neptune
7.4 “需要时序 DB 的情况”
- 每秒上万条 metric/log
- 长期保存 + 聚合查询
→ TimescaleDB (通用)、VictoriaMetrics/ClickHouse (大规模)
7.5 “该上 Feature Store 的时点”
- 有 2 个以上 ML 模型在生产环境
- 共享 10 个以上特征
- 出现训练-推理 skew 问题
→ Feast (轻量)、Tecton/Databricks (企业级)
第 8 章 · 韩国企业的实务
8.1 落地现状
- Vector DB: 2023–2024 大多从 Pinecone/Weaviate 起步，2025 年迁往 pgvector·Elastic 的增多
- Graph DB: 金融 (反欺诈)·通信 (网络) 一直在用，LLM 时代再次起飞
- 时序 DB: APM·IoT 以 InfluxDB/Prometheus 为主
- Feature Store: Coupang·Karrot·Toss·NAVER 都有自建案例
8.2 网络隔离·本地部署的要求
- 金融·公共部门: 自行运维开源方案 (Milvus·Qdrant·Neo4j Community)
- Vector DB 的本地部署 SI 业务在增长
- 韩语嵌入模型 (Solar·KoSimCSE·E5-Korean) + 本地向量 DB 的组合
8.3 成本·性能小贴士
- 试验能否降低嵌入维度 (dimension reduction)
- 用 Dense+Sparse 混合来提升精度
- Cold 数据放 Parquet + Iceberg，Hot 数据放向量 DB
8.4 2025 年韩国方面的动向
- Upstage Embedding / Solar → 国产嵌入模型扩散
- 三星 SDS·LG CNS·NAVER Cloud 推出 Vector·Graph·LLM 整合套件
- 创业公司对 GraphRAG·本地 Vector DB 建设的需求
第 9 章 · 三个案例研究
9.1 电商推荐
- User·Item·Order 图: Neo4j
- Item 嵌入: pgvector 或 Pinecone
- 实时特征: Feast + Redis
- 结果: “下一个可能购买的商品”准确率 +20%
9.2 金融反欺诈
- 交易图: NebulaGraph
- 用户行为时序: TimescaleDB
- 实时规则 + ML 评分: Feast + Flink
- 结果: 误报率下降，响应时间缩短
9.3 企业 AI Assistant (RAG)
- 文档嵌入: Weaviate
- 内部知识图谱: Neo4j + GraphRAG
- 用户权限·元数据: Postgres
- LLM 与 Semantic Layer 结合
第 10 章 · 反模式 10 选
10.1 “每个产品都上 Vector DB”
pgvector 就够了却过度投入。
10.2 拿 Graph DB 当 OLTP 的替代品
它不适合做事务处理。
10.3 把时序数据原样堆进 OLTP
表膨胀，查询暴涨。
10.4 没有 Feature Store 却跑 5 个 ML
特征计算重复·skew。
10.5 缺少 Online-Offline 同步
训练得很好的模型到了生产就一塌糊涂。
10.6 不做向量索引调优
HNSW/IVF 用默认值导致性能下降。
10.7 忽视混合检索
只用 Dense 对关键词查询很弱。
10.8 不用 GraphRAG，只把 raw 文档丢给 LLM
关系型提问的准确率下降。
10.9 一开始就把多个专用 DB 全上
运维负担过重。
10.10 数据治理分散
5 种 DB 各有各的 PII/审计，一致性崩塌。
第 11 章 · 检查清单 — 引入特殊 DB 的 12 项
- 负载分类 (ML 特征·向量·图·时序)
- 按规模决定单一 vs 专用 DB
- 评估是否需要 Feature Store
- 向量索引算法·参数的基准测试
- 是否引入混合检索
- 整理 Graph 查询模式 (Cypher/GQL)
- 时序采集管道
- Online-Offline skew 的检测·告警
- 安全·权限·审计的统合
- PII·加密策略
- 成本预测·监控
- 运维·备份·DR 计划
第 12 章 · 下一篇预告 — Season 5 Ep 7: “数据治理·Lineage·PII”
特殊 DB 越多，治理就越难。Ep 7 讲的是 数据流动全过程的管理。
- OpenLineage 标准
- Collibra / Atlan / DataHub / Alation
- Unity Catalog / Polaris / Glue 的治理层
- PII 的检测·脱敏·令牌化
- GDPR·韩国个人信息保护法中的数据主体权利
- 敏感数据分类
- 数据契约 (Ep 4 的延伸) 与审计
- 多云·多 DB 的治理
- 韩国企业治理的现实
- AI 时代的治理扩张
“不管理数据，数据就会统治公司。” 这是 Ep 7 的主题。
下一篇再见。
摘要: 2025 年的 DB 地形正处在 被 AI·ML 摇动之后走向收敛的阶段。Vector DB 是专用厂商与 Postgres/ES/Mongo 集成并存，Graph DB 借 GraphRAG 与反欺诈重新崛起，时序 DB 与 OpenTelemetry 结合，Feature Store 与 Iceberg·实时流式融合。“先用单一 DB 起步 → 按规模专业化”是主导模式，而韩国企业的特殊性在于网络隔离·韩语嵌入·自行运维 Feast/Neo4j/Milvus。下一篇要谈的，是凌驾于这一切之上的 数据治理 · Lineage · PII。