从 SQL 到自然语言，下一代 Lakehouse 为何必须「AI 优先」

过去三十年OLAP 引擎的发展核心始终围绕结构化数据的处理与分析当然也取得了显著的进步比如分布式架构、存算分离及 cloud native、查询性能大幅提升等。然而随着大模型LLM技术的爆发数据分析的范式正在发生根本性重构。行业预测显示未来五年内非结构化数据文本、图像、音视频等在企业数据资产中的占比将达到 80%。未来的数据形态将趋于多模态分析需求将更加复杂查询方式也将从单一的 SQL 转向自然语言与多模态混合检索。因此我们需要在现代大数据分析平台基础上全面拥抱 AI构建下一代AI-First Lakehouse。一、基础设施演进异构融合的存储与计算层存储层统一管理多模态数据目前大数据体系与 AI 体系存在严重的物理与逻辑割裂。大数据团队习惯维护基于 Hive、OLAP、Lakehouse 等大数据平台来处理分析结构化数据也诞生出业界主流的存储格式如 Parquet、ORC 等能很好的支持结构化数据分析需求。而AI 团队习惯在单机服务器或配备独立显卡的个人电脑Laptop上开发调试数据以本地文件形式散落。这种割裂导致数据无法统一存储治理困难且跨系统调用的性能极低需先查数据库再调 AI 模型。但大数据时代的存储格式如 Parquet 的 Row Group 设计专为结构化数据优化不再适配 AI 场景AI 场景非结构化数据异构特性明显同一批数据里部分字段内容小部分 embedding 后的字段会很大。为此可以考虑引入如 Lance 等专为 AI 设计的存储引擎支持对文本、图像、视频等多模态数据的高效索引与存取。以实现统一管理分散在各处的非结构化数据使得 Lakehouse 不仅是数据存储库更是 AI 资产的统一底座。CPU/GPU 异构计算统一调度传统 OLAP 依赖 CPU 进行聚合、排序与过滤而 AI 负载如 Embedding 生成、非结构化数据解析、模型推理高度依赖 GPU 资源。计算引擎需从单一的 CPU 架构向 CPU/GPU 异构架构演进。系统应具备智能调度能力根据任务类型自动分配计算资源实现结构化查询与非结构化推理的混合执行。典型场景直播电商实时分析单场直播会上架数十至上百个商品每个商品展示时长仅 1-2 分钟。系统需同时处理两类数据结构化计算CPU五维四率数据曝光进房率、商品曝光率、商品点击率、成交转化率等实时指标非结构化计算GPU主播语音讲解分析、主播商品展示视频分析、助播互动表现、用户弹幕评论分析业务方需要将“点击率”与“主播当时说了什么/做了什么”进行关联分析以判断推荐是否精准以及多种因素对成单的影响。这要求计算引擎具备异构资源管理能力能够灵活调度 CPU 处理统计指标调度 GPU 处理特征提取与推理实现多模态数据的实时融合计算。二、内核能力构建AI 原生的查询与 In-Database 推理原生向量检索从外挂到内核的能力下沉简单的语义检索已无法满足高精度的业务需求且外挂式的向量库方案会导致数据冗余与延迟向量能力已经是多模态处理的必备项Must-have。同时引擎内核需要原生支持混合检索并具备混合召回能力结合关键词匹配通过倒排索引实现与语义检索通过向量检索实现通过粗排与精排的组合策略满足如“搜合同关键条款”、“电商以图搜图”、“在线教育以图搜题”等高精度业务需求。更进一步随着越来越多不同类型、不同领域、不同维度的数据摄入 Lakehouse内嵌知识图谱搜索能力也变得越来越重要以便高效快捷的挖掘数据之间的关系。In-Database AI 写入即处理查询即分析1写入时处理传统架构中非结构化数据的 ETL 依赖外部脚本或独立工具链维护成本高且容易形成数据孤岛。下一代系统应将 AI 能力内置于写入路径系统自动调用内核级的解析Parse、分块Chunking、向量化Embedding实现从原始非结构化文件到可查询数据资产的自动化转换无需人工深度介入即可完成打标与关联。2查询时推理将 LLM 能力内嵌至数据库内核实现“查询即分析”。用户无需将数据导出至外部模型处理而是直接在 SQL 中调用 AI 函数。还是以直播评论分析为例系统应能直接通过 SQL 调用内置 AI 能力对海量弹幕进行情感分析如自动过滤“扣 1”、“扣 2”等无意义评论识别具有购买意向的负面/正面反馈甚至触发内置 Chatbot 进行自动回复相比调用外部 API内置推理可利用本地数据过滤机制仅对筛选后的高价值数据进行推理大幅降低延迟与成本并提升吞吐量。将 AI 能力贯穿写入和查询全流程让数据处理成为数据库的内置本能。这种架构下数据从接入到分析的每个环节都被 AI 增强消解了传统“先存储、后处理”模式的滞后性使数据在落盘时即具备智能检索和分析能力。高面向 Agent 架构适配从确定性查询到探索式执行随着 AI Agent 应用的普及数据交互模式将从“确定性查询”转向“探索式执行”。Agent 具有多轮推理、自我修正及高并发的特点这对底层系统提出了新要求极致弹性与高并发Agent 通过多轮推理、自我修正来完成任务且存在 Multi-Agent 场景这将导致会产生海量、突发性的查询请求。系统需要具备毫秒级的弹性伸缩能力支持多路 Agent 并发协作来实现计算资源的即用即取与成本隔离。高效智能元数据管理Agent 会频繁探索数据的 Schema 信息以理解数据结构系统需提供高性能元数据管理服务快速响应 Schema 查询。同时在查询元数据时除了常规的库表结构信息外还应包含丰富的语义数据。另外不同于精确的 SQLAgent 生成的查询往往很模糊。执行引擎需要支持描述性约束信息例如Agent 指令包含“精度要求80%”或“查询超时2 秒”可以根据约束动态调整策略允许在精度与资源消耗之间做权衡而非僵硬地执行全量扫描。四、平台自治AI 反哺系统的自我进化在基础层、内核层、以及架构层升级后还可以思考进一步利用 AI 技术反哺 Lakehouse 自身的鲁棒性与性能。学习最佳实践系统应自动学习内部海量日志中的 Best Practice将其内化为引擎的管理能力。智能故障排查利用 AI 自动定位数据库运行中的隐性问题替代人工排查。智能物化视图Auto-MV加速洞察目前的物化视图依赖业务方手动创建门槛较高。未来系统将结合慢查询分析与数据量特征自动识别性能瓶颈同时学习用户的查询行为自动创建并维护物化视图从底层透明地加速查询响应无需用户感知。流畅开发避免复杂的 UDF 依赖对于复杂的业务逻辑与非结构化数据处理不应强行依赖传统的 UDF而应通过上述的内核级 AI 能力与开放接口来解决提供更流畅的开发体验。结语下一代 AI-first Lakehouse 的构建是一个系统性工程需要从数据处理、存储引擎、计算架构、Agent 支持以及平台生态进行全方位升级。核心目标是打破结构化与非结构化数据的壁垒将 AI 能力从应用层下沉至内核层构建真正面向 AI 时代的新一代数据平台。