不止湖仓一体！Databricks Lakebase 湖库一体，解锁 AI 原生统一数据底座

不止湖仓一体Databricks Lakebase 湖库一体解锁 AI 原生统一数据底座2025年Databricks在DataAI峰会上推出了一款数据库“Lakebase”,这是一款首创的、专为 AI 打造的完全托管 PostgreSQL 数据库。通过 LakebaseDatabricks 为其数据智能平台增加了一个运营数据库层。2020年左右湖仓一体这一关键技术出现后为OLAP业务提供了巨大支撑现在湖库一体的关键技术即将在AI时代为AI融合发挥巨大作用。1、lakebase是什么自从1990年代以来分析系统经理了四次重大技术革命从列存到向量处理再到流处理和湖仓一体。而OLTP数据库仍旧沿用着几十年前的架构。如今由于环境和负载的变化OLTP系统也迎来了技术拐点一种新型、开放、可扩展的OLTP架构作为湖仓一体的一种进化形态技术在AI时代出现了他就是Lakebase--湖库一体。Databricks对lakebase的定义Lakebase is anew database architecturethatseparates compute from storage, keepingdata in a low-cost, open format cloud object storagewhile aserverless Postgres engineruns elastically on top. This design enablesinstant scaling, branching and unified transactional and analytical workloads, making it a cloud-native, AI-era reinvention of the traditional database.A Lakebase is a new, open architecture that combines thebest elements of transactional databaseswith theflexibility and economics of the data lake. Lakebases are enabled by a fundamentally new design: separating compute from storageand placing the database’sdata directly in low-cost cloud storage (“lake”) in open formats, while allowing thetransactional compute layerto run independently on top。总而言之LakeBase 作为统一数据基座融合数据湖的可扩展性与数据库高性能、ACID 事务优势依靠实时处理能力放大 AI 驱动的数据洞察价值。2、为什么需要lakebaseAI正在从“查询方式、数据形态、开发节奏”三个维度重写数据库负载。OLTP方面AI编码写代码比人快4倍以上催生处了高频开发循环80%的新库都由AI创建由此需要毫秒创建分支、秒级启动和一键回滚的能力匿名数据集、沙箱环境需求量暴涨推动“Serverless 免费分支”成为默认。OLAP方面访问模式从“一条大 SQL”变成“投机式多小查询”Agent 先并行发 50–100 条轻量查询探路再拼出最终答案。传统 BI 的“巨型关联 SQL”被拆成“多轮小 SQL 向量语义搜索”对引擎提出“高并发轻查询 向量索引”双重要求。共性需求向量搜索与语义算子支持。如下图所示OLTP接入湖仓时需要ETL等从湖读数据做AI等分析时无法在库内完成所有操作3、lakebase的核心特性3.1存算分离这里先看下以往存算分离的架构以便区分lakebase的存算分离有何不同。3.11 Polardb for PgSQL存算分离以PolarDB for PgSQL的存算分离架构为例它的架构以日志即数据为核心简单来说WAL META就是WAL日志中除去数据部分的头包括页号、起始lsn等信息WAL META传递到RO节点后RO节点进行解析将其转换到LogIndex Hash table中其中key是PageTag表空间OID表OID页号唯一确定一个数据页value是修改该数据页的WAL日志的头部位置也就是起始LSN。同一个桶以递增的形式形成一个链表。构建好后更新该lsn结束位置作为Apply LSN超过这个位置的WAL不能回放因为还没有解析到logindex hash table中找不到 WAL、事务可见性信息不全数据不一致。普通读查询的 target_lsn 直接等于这个 Apply LSN因此页面回放截止点最大不会超过它。共享存储中不进行回放它的数据页仅由RW节点异步刷脏。当RW节点checkpoint后会将checkpoint lsn发给RO节点将该lsn位置之前的lsn从logindex hash table中删除。所以RO节点的回放的基准数据页总是在共享存储中一旦RO节点数据页没有命中时需要从共享存储加载上来然后看下该数据页是否需要回放如果需要则从startlsn位置开始从共享存储取WAL然后回放直到回放到apply lsn位置然后返回给上层由MVCC机制判断里面数据是否可见。如果命中需要回放则基于该数据页进行回放。总的来说RW节点的数据需要异步写到共享存储需要给RO发送WAL META供其解析成log indexRO节点需要加载基准数据页在此基础上从start lsn位置加载WAL进行回放由MVCC机制决定回放出来的数据页里面数据是否可见。3.12 Neon PgSQL存算分离接下来看下lakebase中的存算分离Neon serverless postgres结构。Lakebase首先需要支持存储与计算分离然后才可以很好地提供即时分支、scale-to-zero等能力。下面是databaricks的存算分离架构由Postgres的内核大佬Heikki领衔开发的NEON无服务PG架构开源具备存储与计算分离、单写节点和多读节点、多租户存储、单租户计算以及copy-on-write branching能力。上图中各个部件说明1computes负责计算以及事务和锁的管理这部分基本是原来PgSQL的代码在原来基础上hook了对SMGR存储部分的代码。读数据页时从Pageserver获取另外新创建了一个WAL proposer进程将WAL同步到Safekeeper。2SafekeeperWAL服务负责持久化WAL日志这里一个Safekeeper接收到WAL后会将其写到本地的SSD盘并且通过Paxos实现3副本以保证WAL的高可靠和高可用。3Pageserver存储服务负责重放从Safekeeper过来的WAL日志并解析成自己的格式。相应compute的GetPage的请求到来时按需重放WAL并定期把快照写入上述的Object Storage。4Object storage保存Safekeeper和Pageserver的数据。和以往存算分离架构不同的是neon的计算层的脏页不会持久化共享存储。原理说明safekeeper负责接收RW节点的WAL日志并会存储到safekeeper的本地磁盘。Pageserver会消费safekeeper的WAL。Pageserver分为数据镜像层和deta wal层。其中数据镜像层作为数据恢复的基准数据页最开始的镜像由initdb或者pg_basebackup等导入时生成的基础数据后续的数据镜像快照都是基于这个开始构建的pageserver解析WAL时仅生成deta waldeta wal层是解析后提取变更保存增量修改内容以keylsnvalue三元组的形式写入内存增量层。WAL转换到增量层后safekeeper层对应的WAL就可以清理掉了。内存增量层和数据镜像层会定期持久到到对象存储内存增量层可以合并成一个大的增量当增量大小超过比如10GB的时候就基于上一个镜像回放增量WAL形成一个新的镜像当然还可以设定一个周期时间到了就基于上一个镜像增量WAL回放形成一个新镜像下面以一个例子来说明如何生成镜像初始基线镜像层image_1000对应lsn1000表示1000之前wal都生成到镜像中形成全量页面快照了已落盘的5个delta层及大小如上图所示按照lsn先后排序范围互不重叠调度配置阈值镜像生成的增量阈值假设10GB表示上一个镜像后累计增量超过10GB就强制生成新镜像最大回溯深度3层表示单词页面读取最多穿过3个delta层GC保留地平线LSN3000表示早于3000的历史数据允许被回收场景一累计增量触发这个是最常见的触发方式由空间比例阈值驱动。触发条件image_1000之后的delta总大小22.522.51.810.8GB超过了10GB的镜像生成阈值。目标LSN选择直接取最新delta层的结束编辑也就是delta_5的end_lsn7000。执行选取7000之前最近的镜像也就是image_1000为基准将delta_1到delta_5的更新合并到image_1000中生成新镜像image_7000即lsn7000时刻的全量页快照。后续影响image_1000delta_1-delta_5都是历史层超过PITR保留窗口的可以被GC回收新读取从image_7000开始回溯深度是零。场景二回溯深度触发当写入速度快、增量还没有攒够阈值但读放到已经超标时触发生成新镜像。触发条件假设当前只生成到delta_4总大小是9GB还未到10GB此时读取最新的LSN6100的页面需要从image_1000触发依次穿过delta_1、delta_2、delta_3、delta_4共4层超过了最大回溯深度3层。目标LSN选择选择回溯路径中间delta层边界即delta_2的end_lsn3500。执行结果生成中间镜像image_3500。效果读取lsn3500的页面从image_3500出发仅需要穿过delta_3和delta——4符合深度要求。不用等增量攒满10GB提前控制读延迟避免性能劣化。场景三GC需求出发垃圾回收必须有基线镜像才能安全清理旧数据。触发条件GC的地平线是LSN3000意味着系统可以回收早于3000的历史数据。但此时3000之前仅有image_1000没有更近的镜像如果删除掉image_10003000之前就没有镜像快照历史数据无法读取。硬约束目标LSN必须是delta的边界不能选3000所以选择delta_1的end_lsn2200作为目标LSN。执行结果生成镜像image_2200。后续有了image_2200更早的image_1000就可以回收了。场景四delta层合并不生成新镜像这类compaction只合并小增量层输出delta层不涉及镜像生成。触发条件写入流量波动大短时间生成了大量小体积的L0 delta层比如delta_a(1000-1200)、delta_b(1200-1500)、delta_c(1500-1800)...累计超过L0层的阈值。目标LSN被合并的最后一个delta层end_lsn2100起始LSN取第一个层的start_lsn1000。合并成1个大的L1 delta层LSN范围1000-2100可以范围不变。3.2写时复制的瞬时branch能力分支本质是元数据级操作而非物理数据复制。1创建分支时系统仅生成一个指向父库共享存储的新指针并标记分支的起始分歧点不复制任何实际数据页。因此无论父库是 MB 级还是 TB 级分支创建都是时间复杂度 O (1) 的操作可在 1 秒内完成创建初始不产生额外存储开销。2分支创建后与父库共享所有未修改的数据页只有当分支内发生写入数据修改、Schema 变更等时被修改的数据页才会单独存储形成分支独有的数据。整个过程中父库的数据完全不受影响分支与父库、分支与分支之间实现物理级隔离。和postgres的备机promote提升时间线变成主是一个原理但是promote是主备复制之间发生故障被动提升的而这里的分叉是主动行为。假设研发需要一份和当前线上完全一致的数据搭建一个独立的测试环境不能更改线上数据。在平台上选择线上集群在当前运行点位LSN2000的位置创建新分支test_branch给测试分支单独部署一个RW读写计算节点Pageservver自动给测试分支分配全新时间线TL2比如下图的子branch线上原有集群不受影响继续在TL1上正常业务写入研发连接的test_branch的RW节点做测试修改所有变更全部写入TL2的日志文件中分叉结果以LSN 2000为分界分裂TL1和TL2两个时间线分支行为瞬时完成不会回放WAL仅新建独立的时间线写入元数据父分支ID、branchpointlsn。查询访问时按需回放pageserver检索页面需要找到branchpointlsn前面最近的镜像点从最近的镜像开始回放delta到分叉点然后再将该页返回。分支进行写时将日志通过写到safekeeper中由时间线等标记日志是该分支的这个WAL和父分支没有关系。分叉点lsn强制落在事务提交的边界所以分支回放到branchpointlsn点的数据页一定是一致的。3.3无限、低成本、高持久化存储数据存放在数据湖中存储容量近乎无限成本远低于需要固定容量基础设施的传统数据库。同时其存储依托云对象存储如 S3的持久化能力默认提供 11 个 999.999999999%的数据持久性远优于传统数据库通过副本实现存储冗余的方案 —— 传统方案大多采用异步更新意味着多数配置下若发生双重故障存在数据丢失的风险.3.4弹性serverlessPostgres 计算Lakebase 提供全托管的无服务器 Postgres 服务可随业务需求即时扩容空闲时自动缩容。成本与实际用量完全匹配非常适合波峰波谷明显的突发型负载、开发环境以及 AI 智能体临时启动实例的场景.3.5事务与分析负载一体化Lakebase 可与湖仓一体Lakehouse架构无缝集成在 OLTP联机事务处理与 OLAP联机分析处理场景下共享同一存储层。这意味着用户可以直接基于事务数据运行实时分析、机器学习与 AI 优化任务无需搬运或复制数据.3.6原生开放与多云兼容以开放格式存储的数据避免了专有格式锁定可在 AWS、Azure 等多云环境间实现真正的可移植性。用户对数据拥有完全自主权不再受引擎厂商的深度绑定锁定程度大幅降低。内置的多云灵活能力支撑容灾部署、长期技术自主且能长期优化成本效益。4、参考材料https://www.databricks.com/blog/what-is-a-lakebasehttps://www.databricks.com/product/lakebasehttps://www.bilibili.com/video/BV1Y84y1B7kX/?vd_source10ce859f3f7b1da2094a1283c19fe9b9https://www.databricks.com/blog/enabling-evolutionary-database-development-database-branching-lakebase-part-3https://www.databricks.com/blog/enabling-evolutionary-database-development-database-branching-lakebase-part-2https://www.databricks.com/blog/enabling-evolutionary-database-development-database-branching-lakebasehttps://zhuanlan.zhihu.com/p/624075600https://github.com/neondatabase/neon