从 SQL 到自然语言，下一代湖仓为何必须 AI 优先

作者｜陈鹏，镜舟科技 技术副总裁

过去三十年，OLAP 引擎的发展核心始终围绕结构化数据的处理与分析，当然也取得了显著的进步，比如分布式架构、存算分离及 cloud native、查询性能大幅提升等。然而，随着大模型（LLM）技术的爆发，数据分析的范式正在发生根本性重构。行业预测显示，未来五年内，非结构化数据（文本、图像、音视频等）在企业数据资产中的占比将达到 80%。未来的数据形态将趋于多模态，分析需求将更加复杂，查询方式也将从单一的 SQL 转向自然语言与多模态混合检索。因此，我们需要在现代大数据分析平台基础上，全面拥抱 AI，构建下一代AI-First Lakehouse。

一、基础设施演进：异构融合的存储与计算层

1. 存储层统一：管理多模态数据

目前大数据体系与 AI 体系存在严重的物理与逻辑割裂。

大数据团队习惯维护基于 Hive、OLAP、Lakehouse 等大数据平台来处理分析结构化数据，也诞生出业界主流的存储格式如 Parquet、ORC 等，能很好的支持结构化数据分析需求。而AI 团队习惯在单机服务器或配备独立显卡的个人电脑（Laptop）上开发调试，数据以本地文件形式散落。

这种割裂导致数据无法统一存储，治理困难，且跨系统调用的性能极低，需先查数据库再调 AI 模型。但大数据时代的存储格式如 Parquet 的 Row Group 设计专为结构化数据优化，不再适配 AI 场景，AI 场景非结构化数据异构特性明显，同一批数据里，部分字段内容小，部分 embedding 后的字段会很大。

为此，可以考虑引入如 Lance 等专为 AI 设计的存储引擎，支持对文本、图像、视频等多模态数据的高效索引与存取。以实现统一管理分散在各处的非结构化数据，使得 Lakehouse 不仅是数据存储库，更是 AI 资产的统一底座。

2. CPU/GPU异构计算统一调度

传统 OLAP 依赖 CPU 进行聚合、排序与过滤，而 AI 负载（如 Embedding 生成、非结构化数据解析、模型推理）高度依赖 GPU 资源。

计算引擎需从单一的 CPU 架构向 CPU/GPU 异构架构演进。系统应具备智能调度能力，根据任务类型自动分配计算资源，实现结构化查询与非结构化推理的混合执行。

典型场景：直播电商实时分析

单场直播会上架数十至上百个商品，每个商品展示时长仅 1-2 分钟。系统需同时处理两类数据：

• 结构化计算（CPU）：五维四率数据（曝光进房率、商品曝光率、商品点击率、成交转化率）等实时指标；
• 非结构化计算（GPU）：主播语音讲解分析、主播商品展示视频分析、助播互动表现、用户弹幕评论分析

业务方需要将“点击率”与“主播当时说了什么/做了什么”进行关联分析，以判断推荐是否精准，以及多种因素对成单的影响。这要求计算引擎具备异构资源管理能力，能够灵活调度 CPU 处理统计指标，调度 GPU 处理特征提取与推理，实现多模态数据的实时融合计算。

二、内核能力构建：AI 原生的查询与 In-Database 推理

1. 原生向量检索，从外挂到内核的能力下沉

简单的语义检索已无法满足高精度的业务需求，且外挂式的向量库方案会导致数据冗余与延迟，向量能力已经是多模态处理的必备项（Must-have）。同时引擎内核需要原生支持混合检索，并具备混合召回能力，结合关键词匹配（通过倒排索引实现）与语义检索（通过向量检索实现），通过粗排与精排的组合策略，满足如“搜合同关键条款”、“电商以图搜图”、“在线教育以图搜题”等高精度业务需求。

更进一步，随着越来越多不同类型、不同领域、不同维度的数据摄入 Lakehouse，内嵌知识图谱搜索能力也变得越来越重要，以便高效快捷的挖掘数据之间的关系。

2. 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 具有多轮推理、自我修正及高并发的特点，这对底层系统提出了新要求：

1. 极致弹性与高并发

Agent 通过多轮推理、自我修正来完成任务，且存在 Multi-Agent 场景，这将导致会产生海量、突发性的查询请求。系统需要具备毫秒级的弹性伸缩能力，支持多路 Agent 并发协作，来实现计算资源的即用即取与成本隔离。

2. 高效智能元数据管理

Agent 会频繁探索数据的 Schema 信息以理解数据结构，系统需提供高性能元数据管理服务，快速响应 Schema 查询。同时在查询元数据时除了常规的库表结构信息外，还应包含丰富的语义数据。

另外，不同于精确的 SQL，Agent 生成的查询往往很模糊。执行引擎需要支持描述性约束信息（例如，Agent 指令包含“精度要求>80%”或“查询超时<2 秒”），可以根据约束动态调整策略，允许在精度与资源消耗之间做权衡，而非僵硬地执行全量扫描。

四、平台自治：AI 反哺系统的自我进化

在基础层、内核层、以及架构层升级后，还可以思考进一步利用 AI 技术反哺 Lakehouse 自身的鲁棒性与性能。

学习最佳实践：系统应自动学习内部海量日志中的 Best Practice，将其内化为引擎的管理能力。

智能故障排查：利用 AI 自动定位数据库运行中的隐性问题，替代人工排查。

智能物化视图（Auto-MV）加速洞察

目前的物化视图依赖业务方手动创建，门槛较高。未来系统将结合慢查询分析与数据量特征，自动识别性能瓶颈，同时，学习用户的查询行为，自动创建并维护物化视图，从底层透明地加速查询响应，无需用户感知。

流畅开发：避免复杂的UDF依赖

对于复杂的业务逻辑与非结构化数据处理，不应强行依赖传统的 UDF，而应通过上述的内核级 AI 能力与开放接口来解决，提供更流畅的开发体验。

结语

下一代 AI-first Lakehouse 的构建是一个系统性工程，需要从数据处理、存储引擎、计算架构、Agent 支持以及平台生态进行全方位升级。核心目标是打破结构化与非结构化数据的壁垒，将 AI 能力从应用层下沉至内核层，构建真正面向 AI 时代的新一代数据平台。