Lakebase LTAP Direct Writes正式可用：首批装载直写存储，已有同步表不能直接加开关
Databricks在2026年10月1日的Lakebase发布说明中宣布，LTAP Direct Writes已正式可用，支持运行Postgres 16、17或18的Lakebase项目。功能用于加速同步表的初始装载和全量刷新，默认关闭，需要在创建同步表时主动选择。官方同时提醒，发布按阶段推进，账号看到更新的时间可能晚于公告。
大批数据改走存储层入口
Lakebase同步表将Unity Catalog中的数据维护成Postgres侧可供应用查询的副本。常见用途包括把分析系统产生的特征、指标或模型结果交给在线应用读取。Direct Writes改变的是批量装载路径：数据直接写入支撑Lakebase分支的存储层，减少通过正在服务查询的计算端点写入大批记录。
这项调整与查询结果更及时并不是同一个保证。初次搬运完成得更快，可以缩短等待副本就绪的时间；但之后源数据多久更新、同步多频繁、应用读到哪一轮数据，仍由各自流程决定。本文建议把“初始装载耗时”和“后续数据新鲜度”分成两个验收指标。
AI模型生成的概念插图：批量装载通道与应用查询通道承担不同工作；不是Lakebase内部架构的精确图，也不是实际运行监控。
三种模式的收益范围不一样
按官方文档，所有同步模式的初次全量装载都可以使用Direct Writes。Snapshot每次同步执行全量刷新，因此后续同步也适用；Triggered和Continuous在初始化后通过Change Data Feed处理增量变化，后续更新不属于这条批量直写路径。
因此，若某个应用最关心持续到达的小批更新延迟，不能仅根据Direct Writes的GA消息就预测它会明显变快。相反，大表首次建立副本、需要周期性完整刷新，才更值得重点观察。选择同步模式仍应由数据变化方式和应用可接受的滞后决定，而不是单纯追逐某个加速选项。
老表迁移要先安排依赖关系
文档明确说明，Direct Writes在创建同步表时选定，不能直接添加到已有同步表；现有对象若要使用，需要删除后重新创建。这会涉及应用所引用的对象和数据准备过程。对线上链路，本文建议先核对依赖、名称、权限和回退方案，在可恢复的试点环境完成验证，再安排实际切换窗口。
同步本身还有独立的数据规则。例如，主键列为空的源记录会被排除；允许重复主键时，需要按配置使用时间序列键选择保留记录。即使装载更快，源数据与目标数据的条数也未必天然相等，必须结合排除和去重规则解释差异。
验收时可以保留装载前后快照，比较记录总数、关键字段、重复键处理和代表查询结果，同时观察批量作业运行期间的应用响应。官方这一页没有给出适用于所有项目的固定提速倍数。此次GA更明确地提供了可选的装载方式，项目收益仍要用自己的表规模和查询负载确认。
来源与核对时间
资料核对：2026年10月2日。本文依据公开资料整理，未安装或实测所述产品及服务。
