Lakehouse 服务：Onehouse LakeBase vs Databricks Lakebase Postgres

Source: Dev.to

多年来，湖仓（lakehouse）统一了存储和分析，但它并未统一服务层。

典型的架构如下：

• Lakehouse → 分析 & ETL
• 运营数据库 → 低延迟应用
• Reverse ETL → 在两者之间复制已策划的子集

当查询由人类驱动时，这种划分还能工作。AI 代理改变了负载特征。它们会在紧密的推理循环中发出迭代的点查找、选择性过滤、重复连接以及并行查询。该工作负载以不同方式对扫描优化引擎和传统 OLTP 系统施加压力。

Onehouse LakeBase：开放表上的数据库原语

LakeBase 被定位为直接构建在开放湖仓表上的低延迟服务层，具体包括：

• Apache Hudi
• Apache Iceberg

存储仍然基于对象存储。LakeBase 引入了：

• 记录级和二级索引
• 将成本转向 O(K) 的索引连接，用于选择性工作负载
• 与表提交绑定的事务感知分布式缓存
• 自动扩缩的服务引擎（基于 Quanton 的执行）
• 与 PostgreSQL 兼容的端点，提供标准连接方式

核心思路：不通过 Reverse ETL 维护单独的服务层，而是用数据库式机制直接扩展湖仓本身。

传统的分布式引擎（如 Spark/Trino 级别）通常因扫描和 shuffle 模式而以 O(N + M) 的工作量执行连接。LakeBase 的索引连接旨在将成本降低到过滤后的工作集。

针对狭窄、高选择性的查询，Onehouse 报告称：

• 在 1 TB TPC‑DS 选择性工作负载上延迟降低约 95 %
• 相比 Databricks SQL Serverless（窄查询）性能提升约 6 倍
• 在客户追踪回放中比 AWS Athena 提升 5–10 倍

这些是厂商报告的基准，且针对特定工作负载，但它们展示了设计意图：让湖仓能够在高并发服务场景下使用，而无需复制数据。

Databricks Lakebase Postgres：与湖仓集成的专用 OLTP

Databricks 采用了另一种方式。Lakebase 是一个完全托管的、兼容 PostgreSQL 的 OLTP 引擎，集成在 Databricks 平台中。

架构上：

• 事务工作负载运行在专用的 Postgres 引擎上
• 提供强 OLTP 语义和隔离保证
• 与 Unity Catalog 紧密集成
• 在 OLTP 与湖仓分析之间实现联邦访问

Databricks 原生围绕 Delta Lake 优化，并逐步提升对 Iceberg 的互操作性。Lakebase Postgres 并不修改湖仓的存储层，而是对其进行补充。

这种理念强调专精：

• OLTP 引擎 → 为事务延迟进行优化
• Lakehouse（Delta / Iceberg） → 为分布式分析进行优化
• 统一控制平面 → 分离执行语义

架构对比

两种方案都旨在削减脆弱的 Reverse ETL 流水线。区别在于数据库行为所在的位置：

• Onehouse → 在开放湖仓表（Hudi/Iceberg）上扩展索引、缓存和服务语义。
• Databricks → 在 Delta‑原生湖仓旁引入专用的 PostgreSQL 引擎。

前者向内部收敛，后者在同一平台下组合专用系统。

最终结论

• 如果你的工作负载以读取为主、选择性强且围绕湖仓，则索引优先的模型具有吸引力。
• 如果你需要成熟的事务保证以及明确的工作负载隔离，则与湖仓集成的托管 PostgreSQL 引擎在结构上可能更清晰。

真正的转变不在于数据格式，而在于服务是成为湖仓的原生属性——还是仍然是其专用伴随组件。