Forma 工程博客系列：从 EAV 到零脏读的 Lakehouse
三篇文章，讲透一个为 AI 时代设计的灵活数据存储引擎
凌晨三点的警报
凌晨三点，管道崩了。原因是上周部署的模型开始输出一个 confidence_score 字段，而这个字段昨天还不存在。数据库拒绝了写入，监控没有报警，最后是用户先发现的。
这就是 AI 驱动应用的现实：数据结构的演变速度，远超数据库 Schema 的变更速度。
超市小票的类比
传统 SQL 数据库就像一张列出所有可能商品的小票，香蕉、牛排、洗发水、寿司都印在上面，你没买的东西旁边打印个"0"。想卖新商品？得重新印刷所有小票格式。
基于 EAV 的系统只列出你实际买的东西。薯片、可乐，完事。新商品就是多一行。
这就是 Forma 的核心思想：只存储存在的数据，让 Schema 随着 AI 的输出一起演进。
写给怀疑者
如果你在数据工程领域待过一段时间，你可能在想："EAV？那个会毁掉性能、让查询变成噩梦的反模式？"
这个坏名声是它自己挣来的，怀疑也很合理。这个系列讲的就是我们怎么驯服它：性能问题在第二篇，一致性顾虑在第三篇，最后得到的是一个已经在处理数十亿条记录的生产级架构。
Forma 是什么
Forma 是一个为 AI 时代设计的灵活数据存储引擎，基于三个核心技术选型：
| 技术 | 作用 | 解决的问题 |
|---|---|---|
| EAV 模式 | 属性存储为行，新增字段无需 DDL | Schema 灵活性 |
| JSON Schema | AI 原生的数据契约，写入即校验 | 类型安全与 AI 集成 |
| PostgreSQL + DuckDB | OLTP 与 OLAP 协同，冷热分离 | 性能与成本的平衡 |
我们要解决的三个问题
问题一：AI 数据结构的快速迭代
AI Agent 今天输出 12 个字段，明天 30 个，下周又加 5 个。传统数据库的 DDL 流程（提工单、审批、停服、ALTER TABLE）根本跟不上这个节奏。
第一篇文章解释为什么 JSON Schema + EAV + 热表的组合适合 AI 应用：不需要 DDL，改动即时生效，写入仍然类型安全。
问题二：N+1 查询的性能噩梦
EAV 很灵活，新增字段只是多插几行，不用改表结构。问题出在查询上：查 100 条记录可能需要 101 次数据库往返，延迟轻松破秒。
第二篇文章展示如何用 PostgreSQL 的 CTE + JSON_AGG 把查询次数从 101 降到 1，延迟从 1000ms 降到 25ms。
问题三：海量历史数据的一致性
数据量到了亿级，冷热分离就不再是可选项。"Lakehouse"听起来很美好，但每个工程师心里都有同一个疑问：我怎么知道查出来的数据不是脏的？
第三篇文章详细解释 Forma 如何用 Anti-Join 加 Dirty Set 机制，让联邦查询读不到未提交或不一致的数据。
阅读指南
有共性疑问？查看 FAQ。
| 你的场景 | 推荐从这里开始 |
|---|---|
| 正在构建 AI 应用，需要灵活的数据存储 | 第一篇：AI 架构篇 |
| 被 N+1 查询困扰，想快速提升性能 | 第二篇：杀死 N+1 |
| 数据量增长，考虑冷热分离架构 | 第三篇：Serverless 湖仓 |
| 想完整了解 Forma 架构 | 按顺序读完三篇 |
系列文章
[第一篇] 为什么 EAV 是 AI 时代最被低估的数据模型
TL;DR：类型契约由 JSON Schema 一路带进存储层。配合热表设计，就能做到 AI 输出、即时校验、零 DDL 入库。
→ 阅读中文版 | Read in English
[第二篇] 杀死 N+1：一次 SQL 优化如何让延迟从 1 秒降到 25 毫秒
TL;DR：用 PostgreSQL CTE + JSON_AGG，把数据库往返从 101 次减少到 1 次，延迟下降 97%。
→ 阅读中文版 | Read in English
[第三篇] 零脏读的 Serverless 湖仓：我们如何用 DuckDB 解决一致性难题
TL;DR：PostgreSQL 负责当下，DuckDB + Parquet 负责历史，Anti-Join 加 Dirty Set 确保联邦查询零脏读。
→ 阅读中文版 | Read in English
关于 Forma
Forma 是一个开源的数据存储引擎，面向 AI 时代的工作负载，目标是在保持灵活的同时不牺牲查询性能、也不把存储成本做上去。
有问题或建议，欢迎去仓库提 Issue、参与讨论，觉得有用也可以顺手点个 Star。