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