有权威机构预测,2026年约60%的AI项目可能因数据处理问题被放弃。这是火山引擎在发布云数据库Lakebase时引用的一组判断,也是这款产品试图回答的问题:数据从哪里来、要到哪里存、怎么快速查。
今天,火山引擎正式发布面向Agent的新型数据引擎Lakebase。官方给它的定位是轻量化库湖服务,具备业务数据自动转换、多源数据入湖、弹性算力分析、海量数据资产管理四大核心能力,既能为Agent决策提供多源数据上下文,也能应对海量Agent实例带来的突发性弹性负载。
为什么现在需要这样一款产品
AI应用普及正在改变数据的使用方式。Agent负载具有明显突发性:执行任务过程中,Agent会自动化快速创建或唤醒大量数据库进行过程验证,任务结束后实例则可能长时间闲置。生命周期灵活、访问全自动,成为AI对数据基础设施提出的新要求。
另一重压力来自数据来源。面对复杂任务,Agent不仅要访问企业订单、库存等实时OLTP数据,还需要结合湖表中的历史数据和分析结果。而企业数据中约80%–90%为非结构化,散落在业务系统、本地和外部平台,来源杂、类型多、整理耗时,导致项目常常卡在数据准备阶段。
火山引擎用三个词概括Lakebase的定位:开放、轻量、完整。数据以开放格式存储在对象存储上,多种计算引擎都能访问,不被单一引擎锁定;Serverless架构存算分离,算力按需拉起、用完释放;入湖、转换、查询、管理一条链路全部覆盖。
五层架构与四项能力
Lakebase的五层架构把业务应用、数据处理和底层存储串了起来。数据存储层兼容主流开放湖表格式,业务数据、分析数据和本地文件可以放在同一个数据底座中;数据计算层提供Serverless弹性算力,支持行存、列存和向量检索等链路协同,任务完成后自动释放资源。
查询服务层支持业务通过标准SQL接入,也提供MCP、Skill、CLI方便Agent访问数据。数据管理层由Catalog统一管理元数据、血缘、权限和安全,数据从哪里来、谁能访问、经过哪些处理都有记录可查。业务应用层则承接AI应用、BI分析和多模检索。
四大核心能力对应四个具体痛点:
- Zero ETL:业务数据自动同步到数据湖并转换成开放湖表格式,全过程对业务团队透明,入湖即可用标准SQL查询,ETL的开发和维护负担大幅下降。
- 多源数据处理:门店、工厂、分支机构散在本地、受网络和合规限制的数据,可以高效安全完整地同步入湖,现有本地系统继续运行,企业不用为“上湖”重构IT架构。
- 极致弹性算力:存算分离的Serverless架构,计算资源随任务量自动伸缩,查询时秒级启动,任务完成后自动释放,对比长期运行的数据库实例,成本降低90%以上
- 数据资产管理:把表、字段定义、数据来源、更新时间、处理过程和访问权限统一记录,分析人员能快速找到数据,管理员能识别冗余与冷数据,合规团队可沿血缘追溯处理过程。
四类场景与一份自测清单
火山引擎列出了Lakebase直接发挥价值的四类场景:中小型SaaS数据分析,商业数仓license费用太高、换开源方案又缺人维护;Vibe Coding智能应用扩展,界面搭好了但订单、库存、会员数据进不来;BI报表与即席查询加速,复杂报表要跑几分钟;多源异构数据的统一治理,结构化与非结构化数据统一沉淀后按需使用向量检索、关键词检索、语义检索和多源混合检索。
官方还给出四个自测问题:数据是否分散在多个系统,跨系统关联分析很费力?报表和探索式查询是否经常要等数分钟?负载峰谷明显,固定集群是否经常不够用或大量闲置?团队是否把大半精力花在集群部署、扩缩容和故障排查上?只要有一个问题的答案是“是”,就值得一试。
Lakebase的理念被概括为一句话:把复杂留给系统,把简单交给用户。把数据放进来,然后查询它。
热门跟贴