IvorySQL HTAP 实时湖仓接入引擎

本文章整理于 HOW 2026 中陶郑IvorySQL 核心贡献者演讲内容。一、数据架构的演进历程1.1 传统数据架构的局限业务数据从产生到被分析使用中间需要经过多个系统的流转。当前行业主要存在两种架构模式线性架构业务数据产生后进入事务数据库经过 ETL 数据迁徙进入数据湖再经处理进入数据仓库最终由 AI 调用数据仓库接口进行分析。这一链路冗长数据处理环节众多。变形架构数据同时写入事务数据库和分析型数据库即数据库与数据仓库并存但本质上仍是多个数据库系统AI 查询仍需跨系统访问。这两类架构共同面临的困境是数据处理流程复杂导致分钟级甚至小时级的延迟且多次查询间原始数据可能已经发生变化造成数据割裂。与此同时多套系统的运维成本也居高不下。1.2 架构演进的三代路径第一代2000年代——数据仓库随着数据量增长企业开始按业务需求设计数据结构并存入数据仓库。但后期业务扩展时新增数据分析需求往往面临数据仓库改造的高昂成本。第二代2010年代——数据湖为降低成本企业开始将全量增量数据保存至廉价的数据湖中仅在需要时提取至数据仓库。这虽降低了存储成本却使分析链路更加复杂维护难度加大。第三代2020年前后——湖仓一体融合数据仓库与数据湖的优势但本质上仍是两个系统的组合。1.3 HTAP 原生化下一代架构当前最新趋势是从“湖仓一体”向“HTAP 原生化”演进——让事务数据与分析数据存储在同一数据库中彻底消除数据迁徙与 ETL 环节。两代架构的核心差异维度湖仓一体HTAP 原生化存储底座对象存储统一高性能存储引擎数据新鲜度分钟级/小时级秒级/毫秒级核心能力数据湖增加数仓功能数据库具备数仓体量这意味着多个数据库整合为一个AI 可通过单一 API 调用无需跨库查询运维成本显著降低数据实时性大幅提升。这一演进逻辑在知识管理领域同样成立传统的“笔记事务 大脑思考分析”分离模式正向着“AI 统一管理所有笔记、查询与自动更新”的方向演进——这正是人类大脑“记忆与思考同一器官”的工作方式。二、AI 时代传统架构的三大痛点AI Agent 的普及对数据基础设施提出了全新要求传统架构在三个维度上面临根本性挑战痛点一查询模式不可预测传统架构按预定查询脚本和数据模型设计但 Agent 生成的查询是随机的——用户用自然语言描述需求Agent 可能生成点查也可能生成聚合分析。传统架构无法同时高效应对这两种查询模式。痛点二数据新鲜度敏感ETL 延迟意味着 Agent 查询事务数据和分析数据时数据可能已经发生变化。在风控、推荐、金融等对实时性要求极高的场景中这一延迟不可接受。痛点三跨系统延迟叠加AI 任务的执行本质上是线性的。当单次任务需要同时涉及点查和聚合分析时跨两套系统的延迟相互叠加数据准确性与响应速度双双受损。三、HTAP 原生架构行业动向与 IvorySQL 的定位3.1 行业风向标Databricks 的两笔关键并购过去一年中数据库领域龙头企业 Databricks 完成了两笔具有标志性意义的收购2025年5月——收购 NeonNeon 是无服务器 PostgreSQL 服务提供商。这一收购意味着 OLAP 巨头主动进入 OLTP 领域事务与分析的边界开始被打破。2025年10月——收购 Mooncake LabsMooncake Labs 的核心项目是 pg_mooncake——在 PostgreSQL 内嵌入 DuckDB 列存引擎使同一份数据同时支持事务查询与分析查询彻底无需 ETL。这两笔收购释放了明确信号HTAP 原生化方向已有顶级资本认可且有商业化产品在实质推进。IvorySQL 的方案正是基于 pg_mooncake 构建。3.2 pg_mooncake 留下的两个空白空白一开源生态的维护缺口pg_mooncake 被收购后更新频率明显放缓自2025年10月起至今未再更新。后续迭代必然优先服务于 Databricks 自身的商业产品路线图。开源社区需要一个独立维护的实现迭代方向由社区共同决定不被单一公司绑定。空白二Oracle 迁移场景的能力缺口pg_mooncake 基于 PostgreSQL 生态构建从未考虑过 Oracle 兼容场景。然而中国大量企业的核心数据仍运行在 Oracle 上迁移过程中同样面临 HTAP 需求——目前这一领域尚无现成答案。3.3 IvorySQL 的定位与填补IvorySQL 是一个开源的 PostgreSQL 分支由社区独立维护完整兼容 PostgreSQL 生态同时支持 Oracle 语法、数据类型和函数行为。基于这一基础IvorySQL 的 HTAP 引擎做到填补空白一社区独立维护的 pg_mooncake 持续演进版本迭代方向不受商业公司绑定填补空白二全面支持 Oracle 迁移场景的 HTAP 能力覆盖 Oracle 数据类型、语法及函数兼容实时湖仓接入引擎在上述基础上同一份数据同时支持事务与分析两条路径实时可查四、技术路径与架构原理4.1 行存与列存理解 HTAP 的技术基础PostgreSQL 是行存数据库数据按整行连续存储如同一张 Excel 表中一行完整记录。行存适合事务型操作写入速度快事务支持完善但在大数据量分析查询时性能会遇到瓶颈。列存则按列独立排列如所有金额值集中存储查询时可直接提取目标列无需整行扫描。列存在大数据量聚合分析场景下性能优势显著。HTAP 的核心思路是在同一数据库中同时拥有行存与列存两种存储形态根据查询特征自动选择最优执行路径。4.2 整体架构IvorySQL HTAP 引擎基于 pg_mooncake 构建核心机制如下智能路由通过 Hooks 方式嵌入 PostgreSQL 内核不侵入内核代码Planner计划器自动识别查询特征判断走行存点查/事务还是列存聚合/分析效率更高自动路由至最优执行路径。双存储引擎行存PG Heap 文件服务于 OLTP 事务场景列存DuckDB 引擎 Parquet 列存格式服务于 OLAP 分析场景内存共享与自动同步在内存中同一份数据既可通过 PG 行存访问也可转化为列存供 DuckDB 查询。持久化层面数据通过 Parquet 等列存格式保存行存与列存之间自动实时同步应用层完全无感知。4.3 为什么不需要 ETL传统方案中数据库 → ETL → 数仓延迟达分钟级甚至小时级AI Agent 拿到的是过时数据。HTAP 原生方案中数据始终只有一份存储在 PostgreSQL 中。行存和列存是同一份数据的两种访问路径——ETL 消失了延迟也消失了AI Agent 拿到的是最新数据。4.4 写入路径与查询路由应用层 SQL标准 SQL 语句发出无需任何改造应用完全不感知底层路由决策PostgreSQL 查询层Parser解析器→ Planner规划器→ Executor执行器pg_mooncake 以 Hook 方式嵌入不侵入 PG 内核自动路由Planner 识别查询特征自动决定行存点查/事务或列存聚合/分析双存储引擎执行行存走 PG HeapOLTP列存走 DuckDB ParquetOLAP自动同步两种存储之间自动同步数据始终只有一份五、应用场景场景一Oracle 数仓迁移迁移前痛点企业将 Oracle 数仓迁移到开源数据库后原有的分析链路需全部重建——OLAP 系统重新搭建、ETL 脚本重新编写、业务停摆等待成本倍增。迁移到 IvorySQL 后Oracle 类型、语法、数据类型、函数行为全面兼容迁移脚本无需修改。HTAP 能力随迁移一并到位分析链路不需要重建迁移完成即可用无需额外部署任何组件。场景二AI Agent 混合查询当前困境Agent 完成一个任务需要同时查询事务数据和分析数据——先查 MySQL 拿最新订单再查分析数据库做趋势分析。两个系统、两次延迟且数据新鲜度不一致。统一到 IvorySQL 后点查走行存聚合走列存一个连接搞定所有查询。数据实时一致Agent 响应速度与决策质量同步提升。场景三实时风控当前困境交易发生后数据经过 ETL 进入风控分析系统最快也是分钟级延迟。对于高风险交易风控判断往往在交易完成后才到达形同虚设。接入 IvorySQL 后交易写入 IvorySQL 的同时列存即可查询。风控规则实时触发从分钟级降到秒级以内。对风控、推荐、金融等延迟敏感场景效果尤为显著。六、开源发布计划发布时间计划伴随 IvorySQL 6.0 版本正式发布开源内容代码完全开源包含三个核心模块——ivy_mooncake、ivy_duckdb、ivy_moonlink获取方式可通过 IvorySQL 官网获取相关资源与文档注现在已经发布了预览版 1.0 beta1七、总结IvorySQL HTAP 实时湖仓接入引擎是 IvorySQL 社区在数据库架构演进方向上的重要布局。项目紧跟 Databricks 等行业巨头验证的技术方向基于 pg_mooncake 构建同时填补了开源独立维护与 Oracle 迁移场景两大空白。通过行存与列存的融合、智能路由与自动同步机制实现了事务与分析在同一数据库中的实时统一为 AI Agent 时代的数据查询、实时风控、Oracle 迁移等场景提供了切实可行的解决方案。随着 6.0 版本的开源发布IvorySQL 社区将为企业用户提供一套真正开放、可独立演进、兼容 Oracle 生态的 HTAP 基础设施。