1. 项目概述当AI成为数据基础设施的“头号玩家”最近和几个做数据平台的朋友聊天话题总绕不开一个词AI负载。过去几年我们谈论数据仓库、数据湖、实时数仓核心场景是BI报表、用户画像、实时大屏。但风向变了现在大家讨论的焦点是如何支撑大模型训练、如何做向量检索、如何让数据管道直接对接AI应用。这不仅仅是增加几个GPU服务器那么简单它意味着从底层存储格式、查询引擎到资源调度、运维体系的全面重构。Apache Doris社区最近发布的2026路线图就像一份“剧透”清晰地指向了这个未来。它不再只是一个高效的OLAP引擎而是立志成为AI时代统一的数据服务层。今天我就结合这份路线图以及我们团队在真实场景中踩过的坑来深度拆解一下当AI成为主流负载后我们赖以生存的数据基础设施到底会经历一场怎样的“基因改造”。简单来说传统数据基础设施是为“人”服务的追求的是让分析师和业务人员能快速、准确地拿到聚合后的统计结果。而AI负载无论是训练还是推理本质上是在为“机器”服务。它需要的是海量的原始数据、高吞吐的数据流转、低延迟的特征供给以及对非结构化数据如图片、文本、向量的原生支持。这种根本性的需求转变倒逼着像Apache Doris这样的核心组件必须进化。这份2026路线图可以看作是Doris社区对未来三年技术演进的公开承诺和系统思考它涉及查询引擎、存储、资源管理、生态融合等多个维度目标直指“AI-Native”。如果你是一位数据架构师、平台研发工程师或者正在为公司的AI应用寻找可靠的数据底座那么理解这份演进方向至关重要。它不仅能帮你提前规划技术栈避免未来两年的重复建设更能让你看清在AI浪潮下一个现代化的数据平台应该具备哪些核心能力。接下来我将从设计思路、核心能力解析、关键技术实现以及我们面临的挑战这几个方面为你层层剥开这份路线图背后的技术逻辑与实战考量。2. 核心设计思路从“分析优先”到“AI原生”的范式转移要理解Doris 2026路线图的雄心首先要跳出“Doris只是一个查询很快的OLAP数据库”这个固有印象。它的目标演进路径本质上是一次从“分析优先”Analytics-First到“AI原生”AI-Native的底层设计哲学转移。这并非简单的功能叠加而是围绕AI工作流的特点对系统架构进行的一次重塑。2.1 统一数据服务层的愿景传统的数据栈是分层的数据从业务系统通过ETL进入数据仓库或数据湖再经由数据开发加工成数据集市最后提供给BI或AI应用。这个链条长且每层之间数据格式、接口不一形成烟囱。Doris 2026路线图的核心愿景之一是构建“统一数据服务层”。这意味着Doris希望自己能够同时扮演好三个角色高性能数据湖分析引擎直接对接HDFS、S3、Iceberg、Hudi等开放格式实现对这些数据的高效查询避免不必要的跨系统数据搬迁这对应了AI训练中需要读取海量原始数据的需求。实时特征存储与供给平台为在线推理和实时推荐场景提供毫秒级延迟的特征查询服务。这要求存储引擎不仅能处理批量更新更要擅长处理高并发的点查、小范围扫描。向量数据库与多模数据融合引擎原生支持向量数据类型和相似性搜索并能与结构化数据联合查询。这是让AI应用如RAG、语义搜索直接与业务数据对话的关键。这个“三位一体”的定位旨在让AI应用开发者能够通过一套统一的SQL接口和协议完成从数据准备、特征工程到模型服务的数据闭环极大简化了架构复杂度。2.2 核心挑战与设计权衡转向AI原生Doris需要解决几个传统OLAP引擎不擅长的问题工作负载的混合与隔离一个集群可能同时运行着传统的凌晨批量报表作业、业务人员的即席查询、流式写入的实时数据摄入以及AI训练任务发起的大规模全表扫描。这些负载对资源CPU、内存、IO的需求和优先级截然不同。如何保证高优先级的在线特征查询不被一个跑偏的批量训练任务“拖死”是资源管理模块如Resource Group需要进化的重点。数据类型的极大丰富AI处理的数据远不止INT、VARCHAR。除了前面提到的向量Vector还有嵌入文本Embedding、图像特征、图数据等。存储引擎需要高效地序列化、反序列化这些复杂类型并为其设计专用的索引和检索算法。计算模式的扩展单纯的MPP大规模并行处理计算模型对于某些AI预处理任务如图像转换、文本分词可能效率不高。路线图中提到的对UDF用户自定义函数能力的增强特别是支持更复杂的语言如Python和GPU加速就是为了将部分计算下沉到数据存储节点减少数据移动这正是AI计算的核心思想。在设计权衡上社区显然选择了“增强核心开放生态”的路径。不是自己重新造一个AI数据库而是在强大的数据管理和查询能力基础上通过深度集成如与Ray、Flink的协同和标准接口如支持PostgreSQL协议、Arrow Flight来融入AI生态。这样做的好处是既能快速响应市场需求又能保持内核的专注与稳定。3. 关键技术能力演进解析路线图描绘了多个技术方向我将其中最关键、与我们实际工作关联最紧密的几点拿出来结合我们的理解进行深度解读。3.1 存算分离架构的深化与成本优化存算分离已是现代数据平台的标配但Doris的目标是将其做到极致。2026路线图强调了对对象存储如S3更深度的支持不仅仅是冷数据归档而是要实现“热数据也可直接计算”。技术要点透明缓存加速计算节点本地SSD作为对象存储数据的缓存层。智能预取和缓存淘汰策略是关键。Doris需要能学习查询模式对频繁扫描的数据块进行缓存这对AI训练中反复读取同一数据集的行为非常友好。数据分层智能化自动根据数据的访问频次、温度在本地NVMe SSD、本地SATA SSD、对象存储之间流动数据。对于AI场景训练用的历史数据集可能被标记为“温”或“冷”而实时生成的特征表则必须是“热”的。存储格式优化针对对象存储延迟高的特点优化文件格式如Parquet的读取包括更细粒度的数据裁剪、谓词下推以及利用S3的Select功能减少网络传输量。实操心得在我们早期的存算分离测试中最大的坑在于元数据管理。当数据文件全部放在S3上时LIST操作的成本很高。Doris需要维护一个高效、一致的元数据缓存层来快速定位文件否则查询规划阶段就会成为瓶颈。社区在路线图中提到的“元数据服务独立化”正是为了解决这个问题。3.2 向量检索能力的原生集成这是AI原生最标志性的能力。Doris不仅要能存向量更要能快速查。技术要点向量数据类型与索引引入新的VECTOR数据类型并集成主流的向量索引库如FAISS、HNSWlib。索引的创建、更新、查询需要完全融入Doris的SQL体系和执行引擎。混合查询Hybrid Search这是杀手级应用。例如一条SQL可以同时表达“从商品表中找出品类是‘电子产品’且向量描述与用户当前浏览内容最相似的Top 10商品”。这需要查询优化器能够将传统的谓词过滤品类‘电子产品’与向量近似最近邻搜索ANN高效地结合起来执行。性能考量向量索引通常全部加载到内存才能获得最佳性能。这给Doris的内存管理带来了新挑战。可能需要为向量索引设立独立的内存池并支持磁盘索引作为备选。一个简化的混合查询示例构想-- 假设 products 表有 category (VARCHAR), description_embedding (VECTOR), product_name 等字段 SELECT product_id, product_name, cosine_distance(description_embedding, [用户输入文本的嵌入向量]) as distance FROM products WHERE category electronics ORDER BY distance ASC LIMIT 10;这条查询需要先通过category过滤出部分数据再在这部分数据的description_embedding向量列上进行相似度计算和排序。执行引擎需要智能地决定是先过滤再算向量距离还是利用向量索引先找相似再过滤。3.3 资源管理与工作负载隔离的精细化AI任务的不稳定性和资源饥渴性让集群稳定性面临巨大考验。路线图中对Resource Group的增强是必然之举。技术要点多维度资源管控从目前的CPU、内存管控扩展到对GPU、网络带宽、磁盘IOPS的管控。一个模型训练任务组可以被限制只能使用特定的GPU节点和有限的网络带宽。弹性资源伸缩根据队列负载自动弹性扩缩容计算节点尤其是在云上。当检测到AI训练任务队列积压时能自动从资源池拉起计算Pod任务完成后释放。优先级与抢占支持更高优先级的在线查询任务抢占低优先级批量任务的资源。这需要非常精细的状态保存和恢复机制对于被抢占的长时间运行的AI扫描任务能记录断点后续续跑。3.4 生态融合与标准接口“独木不成林”Doris必须更好地融入整个AI和数据生态。技术要点Arrow Flight作为高性能数据通道Arrow内存格式是AI框架如PyTorch, TensorFlow和数据系统之间事实标准的数据交换格式。通过支持Arrow Flight RPC协议Doris可以将查询结果以Arrow格式零拷贝地传输给Python AI程序效率远超传统的JDBC/ODBC。与计算框架深度协同例如与Ray集成将Doris作为Ray的数据源Ray的任务可以直接分布式读取Doris中的数据与Flink集成实现维表Join时更高效的点查。增强的UDF框架支持用户用Python编写复杂的特征转换函数并能在Doris集群中分布式执行。更进一步可以探索通过GPU UDF在数据读取的同时完成一些简单的模型推理或特征提取。4. 面向AI的查询引擎与执行优化架构愿景需要强大的执行引擎来落地。面向AI负载查询引擎的优化方向也发生了显著变化。4.1 复杂数据类型与自定义函数的支持AI场景下的数据转换逻辑异常复杂。传统的SQL内置函数远远不够。扩展类型系统如前所述原生支持VECTOR、MAP复杂嵌套结构、BINARY存储序列化后的模型权重或特征等类型。优化器需要理解这些类型的特性比如知道在VECTOR列上建索引是有意义的。Python UDF的成熟化不仅仅是“能用”而是要“高性能、易管理、稳如狗”。这包括进程隔离与安全UDF运行在独立的沙箱进程中避免劣质Python代码拖垮整个BEBackend进程。依赖管理如何将Python环境及其依赖如numpy, pandas, torch打包并分发到各个BE节点。数据交换效率在Doris的C核心与Python UDF之间高效传递数据避免不必要的序列化开销。利用Apache Arrow作为中间格式是理想选择。GPU加速的查询算子对于一些典型的AI预处理操作如向量归一化、矩阵乘法在特征组合场景可以将其实现为能运行在GPU上的查询算子由查询优化器在生成执行计划时自动选择。4.2 自适应执行与代价模型优化AI查询的模式多变且数据分布可能随实时写入而快速变化。静态的优化策略往往失效。运行时统计信息收集更频繁、更细粒度地收集数据统计信息如NDV、数据分布直方图特别是在数据实时更新的场景下。自适应执行计划允许执行计划在运行时根据中间结果的大小进行调整。例如一个Join操作如果发现某一边的中间结果实际很小可以从基于Shuffle的Hash Join动态切换为Broadcast Join。针对AI负载的代价模型传统的代价模型主要考虑IO和CPU。对于涉及向量搜索或GPU UDF的查询代价模型需要加入新的因子如GPU内存带宽、向量索引搜索的近似复杂度等。5. 运维与可观测性体系的升级一个为AI准备的数据基础设施其运维复杂度是指数级上升的。路线图中对可观测性的重视说到了所有运维人员的心坎里。5.1 全链路追踪与性能剖析当一条混合查询Hybrid Search变慢时问题可能出在SQL解析、查询规划、向量索引加载、GPU UDF执行、网络传输等任何一个环节。集成OpenTelemetry将查询执行过程中的关键阶段如扫描、过滤、Join、UDF执行、网络传输生成Span并集成到统一的追踪系统如Jaeger中。这样我们可以清晰地看到一个慢查询的时间到底耗在了哪里。细粒度资源监控监控指标需要从节点级别下沉到查询级别甚至算子级别。我们能知道是哪个查询耗光了GPU内存哪个UDF函数占用了异常的CPU时间。向量索引性能监控监控索引的命中率、重建频率、内存占用等这对于排查向量搜索性能问题至关重要。5.2 智能诊断与自愈面对海量的监控指标和日志人工排查低效且容易遗漏。AI时代的基础设施应该具备用AI运维AI的能力。异常检测基于历史指标自动检测查询延迟异常、资源使用率异常、节点健康状态异常。根因分析建议当系统识别出一个慢查询模式后能自动关联当时的资源状态、配置变更、数据分布情况给出可能的原因建议例如“该查询性能下降与某向量索引最近一次重建时间吻合建议检查索引参数”。弹性自愈的尝试对于非致命性的问题如某个BE节点因UDF内存泄漏导致响应变慢系统可以尝试自动将其隔离并重启该节点上的服务同时将负载迁移到其他节点。6. 实战推演构建一个AI-Ready的数据平台基于Doris 2026路线图描绘的蓝图我们可以设想一下在未来1-2年内如何一步步地将现有的以Doris为核心的数据平台升级为能从容应对AI负载的平台。6.1 阶段一夯实基础拥抱开放格式目标实现数据湖查询的稳定高效为AI训练准备好数据源。行动项升级与验证将Doris升级到支持高性能Iceberg/Hudi查询的版本如2.0以后的版本。在测试环境构建完整的湖仓一体链路业务数据 - Kafka - Flink - Iceberg (S3) - Doris。性能调优针对AI训练常见的全表扫描、大范围过滤查询测试并优化Doris对ORC/Parquet文件的读取性能。重点关注谓词下推、并行扫描、以及与小文件合并相关的配置。成本评估对比直接从S3训练和通过Doris查询后训练的成本与性能差异。明确Doris在数据湖查询上的价值边界通常是加速交互式探查和复杂过滤。注意事项直接查询数据湖格式时元数据管理的开销可能成为瓶颈。需要密切关注Doris FEFrontend的负载以及与Hive Metastore或AWS Glue的交互延迟。对象存储的延迟和费用特别是请求费用需要仔细核算。合理设置Doris的缓存策略至关重要。6.2 阶段二引入向量探索混合搜索目标为AI应用如智能客服、推荐搜索提供向量检索能力。行动项技术选型与POC待Doris发布稳定支持向量索引的版本后立即搭建POC环境。准备一批带有文本嵌入向量的商品或文档数据。构建混合查询原型设计业务场景例如“搜索与某款手机相似且价格在3000-5000元的其他手机”。编写SQL进行测试评估查询性能QPS、延迟和准确度召回率。应用侧改造与AI应用团队协作改造其数据获取逻辑从原来可能的多系统拼接从Redis取特征从PG取商品信息改为向Doris发送一条混合查询SQL。避坑指南索引构建资源构建大规模向量索引如十亿级别是CPU和内存密集型操作需要在业务低峰期进行并规划好单独的构建集群资源。索引更新策略对于实时更新的向量数据如实时生成的用户嵌入需要设计高效的增量索引更新机制避免全量重建。了解Doris支持的索引更新模式是近实时还是批处理。准确性与性能权衡向量索引的参数如HNSW中的efConstruction和efSearch直接影响构建速度、搜索速度和召回率。需要根据业务要求进行精细调优。6.3 阶段三实现资源隔离与弹性调度目标保障核心在线业务稳定同时高效利用资源运行AI任务。行动项划分资源组根据业务优先级创建至少三个资源组high_priority_online用于在线特征查询和实时看板、batch_report用于定时报表、ai_training用于模型训练和数据预处理。配置资源限制为每个组设置明确的CPU、内存配额。为ai_training组可能配置较低的优先级允许其使用空闲资源但在高优先级任务需要时可以被抢占。云上弹性方案设计如果部署在云上设计与Kubernetes或云厂商自动伸缩组集成的方案。当ai_training队列任务积压时能自动扩容一组“廉价”的计算节点如Spot实例加入集群任务完成后自动销毁。实操心得资源隔离的粒度要把握好。过细的隔离会导致资源碎片化利用率降低过粗则起不到隔离效果。建议先从大的业务线维度进行隔离。“抢占”功能是一把双刃剑。对于被抢占的AI长任务必须有良好的断点续跑机制否则会造成大量计算资源浪费。在启用前务必充分测试各种抢占场景下的任务行为。6.4 阶段四完善可观测性与智能运维目标建立面向AI负载的、白盒化的运维能力。行动项部署全链路追踪集成OpenTelemetry Collector将Doris、Flink、业务应用产生的追踪数据统一收集到Jaeger或类似后端中。确保一次AI特征查询的完整路径可以被还原。定制化监控看板在Grafana中不仅看集群整体健康度更要创建面向AI负载的专属看板。关键指标包括向量查询的P99延迟、GPU UDF的执行耗时与成功率、各资源组的利用率与排队情况、向量索引的内存占用与缓存命中率。建立性能基线与告警在业务平稳期记录各类典型查询如点查、混合搜索、批量扫描的性能基线平均延迟、耗用资源。设置智能告警当查询延迟偏离基线一定范围时自动触发并关联当时的资源监控进行告警。7. 未来展望与潜在挑战Doris 2026路线图为我们勾勒了一个激动人心的未来但通往AI原生数据基础设施的道路绝非坦途。结合我们的实践可以看到一些必须面对的挑战1. 技术复杂度与稳定性的平衡每增加一个像向量索引、GPU UDF这样的核心功能系统的复杂度就呈指数级增长。如何保证在如此多功能叠加下的系统整体稳定性是对开发团队架构和工程能力的终极考验。早期采用者需要做好面对更多未知Bug和性能波动的心理准备。2. 社区生态与人才储备一个成功的开源项目离不开繁荣的生态。Doris需要吸引更多AI领域的开发者贡献代码、工具和最佳实践。同时市场上既懂分布式数据库又懂AI算法和框架的“双料”人才非常稀缺这可能会成为企业落地相关技术的瓶颈。3. 成本控制的永恒命题AI负载是“资源饕餮”。GPU昂贵向量索引吃内存海量数据扫描产生巨额对象存储请求费用。路线图中的所有优化最终都要落到性价比上。未来的竞争不仅是性能竞争更是单位成本下处理能力的竞争。存算分离、弹性伸缩、数据分层等技术其核心目标之一就是成本优化。4. 标准与协议的竞争在向量搜索、机器学习数据交换等领域业界尚未形成完全统一的标准。Doris选择了集成主流开源库FAISS和支持Arrow这是一个务实的策略。但它需要密切关注市场动向确保自己的技术选型与未来事实标准的方向一致。从我个人的经验来看数据基础设施的演进从来不是颠覆式的革命而是围绕业务需求进行的持续迭代和重构。Apache Doris的2026路线图是一次面向未来的、系统性的自我进化宣言。它提醒我们作为数据领域的从业者不能只埋头于当下的SQL优化和集群维稳更要抬头看路理解AI这股洪流将如何重塑我们脚下的土地。提前布局深入理解这些演进方向背后的技术逻辑才能在未来几年帮助我们的公司和团队构建出真正有竞争力、能赋能业务创新的数据平台。这个过程注定充满挑战但也正是技术人价值的体现。