1. 从“数据仓库”到“智能引擎”为什么我们需要AI Function最近在社区里看到不少朋友在讨论Apache Doris的AI Function官网的文档也更新了相关章节。作为一个和数据仓库、OLAP引擎打了多年交道的从业者我最初的反应是一个主打极速分析的MPP数据库怎么也开始搞AI了这会不会又是一个追逐热点的“噱头”功能带着这个疑问我花了一些时间深入研究和实测了Doris的AI Function。我得出的结论是这绝非噱头而是一个能实实在在解决我们日常工作中“最后一公里”痛点的能力。它解决的核心问题是数据价值挖掘的“断点”。传统的数据分析链路通常是这样的业务数据通过ETL进入数据仓库如Doris分析师或数据科学家通过SQL查询出聚合结果或明细数据然后将这些数据导出到CSV或通过API传递给Python/Jupyter Notebook环境在那里调用各种机器学习库如scikit-learn或深度学习框架如PyTorch进行模型训练、预测或向量化处理。最后再将处理结果写回数据库或用于生成报告。这个流程存在几个明显的效率瓶颈数据移动成本高大规模数据在系统间导入导出耗时耗力且有泄露风险。技术栈割裂数据分析师需要熟悉SQL和Python两套工具链上下文切换成本高。实时性差对于需要实时利用AI模型进行判别的场景如实时风控、内容推荐上述批处理链路延迟太高。部署运维复杂维护一套独立的AI服务并确保其与数据库服务的高可用和弹性是另一个维度的挑战。Apache Doris的AI Function本质上是在数据库内核中内置了一个AI模型调用与向量计算引擎。它允许用户直接通过标准的SQL函数像调用SUM()、AVG()一样去调用内嵌的或远程的AI模型完成文本嵌入、情感分析、相似度匹配等任务。这意味着数据无需离开数据库在查询的瞬间就能完成AI处理真正实现了“SQL化”和“实时化”的AI能力。举个例子你有一个用户评论表现在想实时分析每条评论的情感倾向正面/负面。过去你需要把评论文本导出用Python调用情感分析模型再关联回原表。现在在Doris里可能只需要这样一句SQLSELECT comment_id, user_id, content, ai_analyze_sentiment(content) as sentiment FROM user_comments;这种变革对于需要频繁将AI能力应用于数据分析的场景无疑是效率的飞跃。接下来我将从几个核心层面拆解Doris AI Function的实现与使用。2. AI Function的两种模式内置函数与远程服务理解AI Function首先要搞清楚它的两种工作模式。这是架构设计的核心也直接决定了它的能力边界和适用场景。2.1 内置AI函数开箱即用的轻量级智能内置函数是Doris将一些经典的、轻量级的AI算法直接集成到数据库执行引擎中。这些函数通常不依赖外部模型服务计算直接在Doris的BE节点上完成因此具有极高的性能和稳定性。目前Doris内置的AI函数主要集中在文本向量化和向量相似度计算这两个最基础、最通用的领域。1. 文本向量化函数ai_embedding_vector这是AI Function的基石。它的作用是将一段文本句子、段落转换成一个固定长度的数值向量即Embedding。这个向量在高维空间中代表了文本的语义信息语义相近的文本其向量在空间中的距离也更近。-- 将文本‘Apache Doris是一款高性能的实时分析数据库’转换为向量 SELECT ai_embedding_vector(‘Apache Doris是一款高性能的实时分析数据库’) AS feature_vector;执行后你会得到一个类似[0.123, -0.456, 0.789, ...]的浮点数数组通常是384维或768维。这个向量可以存入表的ARRAYFLOAT类型字段中为后续的相似性搜索做好准备。注意内置的ai_embedding_vector函数通常基于一个内置的轻量级模型如MiniLM。它的优点是零配置、速度快但可能在某些专业领域或对语义理解精度要求极高的场景下不如大型专用模型如OpenAI的text-embedding-ada-002效果好。如果你的场景对精度要求苛刻可能需要使用下文介绍的远程服务模式接入更强大的模型。2. 向量相似度函数cosine_similarity与dot_product生成向量后如何衡量两个文本的相似度这就需要相似度函数。最常用的是余弦相似度cosine_similarity和点积dot_product。余弦相似度计算两个向量在方向上的差异值域为[-1, 1]1表示完全相同0表示无关-1表示完全相反。它对向量的绝对长度不敏感更适合比较文本语义。-- 计算两段文本的语义相似度 SELECT cosine_similarity( ai_embedding_vector(‘如何学习Doris’), ai_embedding_vector(‘Doris入门教程’) ) AS similarity_score;点积计算两个向量的点积值域没有固定范围。当向量经过归一化处理后点积等价于余弦相似度。在某些向量数据库的索引中点积计算效率更高。这两种模式构成了向量检索的核心。你可以预先将海量文本如商品描述、文章、问答对向量化后存入Doris当有新的查询文本时将其向量化并通过相似度函数在库中快速找出最相关的条目。这就是一个简易的、基于SQL的语义搜索系统。2.2 远程AI服务函数对接强大的外部模型内置函数能力有限Doris更大的想象力在于ai_系列函数它能通过HTTP协议直接调用外部AI服务。这意味着你可以将任何提供HTTP API的AI模型接入Doris无论是公司内部部署的大模型还是云服务商提供的各类AI能力。其核心函数是ai_query或ai_call具体函数名可能随版本更新需查阅对应版本文档。其工作原理是Doris BE节点作为客户端将SQL函数中的参数如文本通过HTTP请求发送到你配置好的AI服务端点并解析返回的JSON结果。-- 假设你部署了一个情感分析服务 endpoint为 http://your-ai-service/sentiment -- 在Doris中可能需要通过配置或函数参数指定该端点 SELECT comment, ai_query(‘http://your-ai-service/sentiment‘, content) AS sentiment_result FROM comments;远程服务模式提供了无限的扩展性。你可以接入大型语言模型用于文本摘要、翻译、内容生成、复杂问答。专用领域模型用于图像识别传入图片URL或base64、语音转文本、欺诈检测。向量生成模型使用更强大的embedding模型如BGE、text2vec来生成质量更高的向量。实操心得远程模式的关键在于服务治理。你需要确保你的AI服务具备高可用、低延迟和弹性伸缩能力。因为Doris的查询是并发的可能瞬间发起大量请求。建议为AI服务配置负载均衡。在Doris端或服务端实现请求限流和重试机制。仔细设计API接口的输入输出格式确保与ai_query函数兼容。通常需要返回结构化的JSON以便Doris解析出其中的字段。3. 核心实战在Doris中构建一个智能问答知识库理论讲完了我们来点实际的。我将手把手带你用Doris AI Function构建一个最简单的智能问答FAQ知识库。这个场景非常普遍比如企业内部的知识库、电商产品的客服机器人等。目标用户输入一个自然语言问题系统从已有的问题-答案库中找出语义最相似的问题并返回对应的答案。步骤拆解知识库数据准备与向量化。构建语义搜索SQL。性能优化与索引使用。部署为实时服务。3.1 数据准备与向量化建表首先我们需要一张表来存储标准问答对。CREATE DATABASE IF NOT EXISTS faq_db; USE faq_db; CREATE TABLE faq_knowledge_base ( id BIGINT NOT NULL AUTO_INCREMENT, standard_question VARCHAR(500) NOT NULL COMMENT ‘标准问题‘, answer TEXT NOT NULL COMMENT ‘对应答案‘, question_vector ARRAYFLOAT COMMENT ‘标准问题的语义向量‘, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEOLAP DUPLICATE KEY(id, standard_question) DISTRIBUTED BY HASH(id) BUCKETS 8 PROPERTIES ( replication_num 3 );接下来向表中插入一些示例数据并使用内置函数生成向量。这里假设我们使用内置的embedding模型。-- 插入数据并同时生成向量 (假设 Doris版本支持在插入时调用函数) INSERT INTO faq_knowledge_base (standard_question, answer, question_vector) VALUES (‘Apache Doris是什么‘, ‘Apache Doris是一个基于MPP架构的高性能、实时的分析型数据库。‘, ai_embedding_vector(‘Apache Doris是什么‘)), (‘如何安装Doris‘, ‘可以通过下载源码编译安装或使用官方发布的二进制包进行安装详细步骤请参考官网文档。‘, ai_embedding_vector(‘如何安装Doris‘)), (‘Doris支持哪些数据导入方式‘, ‘Doris支持Broker Load, Routine Load, Stream Load, Insert Into等多种数据导入方式。‘, ai_embedding_vector(‘Doris支持哪些数据导入方式‘)), (‘什么是Rollup表‘, ‘Rollup是Doris中一种物化索引可以通过预聚合提升特定维度查询的性能。‘, ai_embedding_vector(‘什么是Rollup表‘));如果已有存量数据可以通过UPDATE语句来批量生成向量UPDATE faq_knowledge_base SET question_vector ai_embedding_vector(standard_question) WHERE question_vector IS NULL;踩坑提醒大规模批量生成向量时如果使用远程的AI服务务必注意控制并发请求频率避免打垮服务。可以考虑在业务低峰期执行或使用Doris的异步任务功能如果支持。3.2 构建语义搜索SQL当用户提问怎么安装Apache Doris时我们需要将用户问题向量化。计算该向量与知识库中所有question_vector的余弦相似度。按相似度排序取出最匹配的结果。对应的SQL如下WITH user_query AS ( SELECT ai_embedding_vector(‘怎么安装Apache Doris‘) AS query_vec ) SELECT k.standard_question, k.answer, cosine_similarity(q.query_vec, k.question_vector) AS score FROM faq_knowledge_base k, user_query q ORDER BY score DESC LIMIT 3;这条查询会返回与怎么安装Apache Doris最相似的三个标准问题及其答案。你会发现尽管用户提问没有使用“如何”而是“怎么”但语义搜索依然能准确匹配到如何安装Doris这条记录这就是向量语义检索的优势。3.3 性能优化向量索引的必要性上面的查询有一个严重问题它进行了全表扫描。对于知识库这种SELECT ... WHERE ... ORDER BY ... LIMIT的典型搜索场景当数据量达到百万、千万级时每次查询都计算所有向量的相似度是不可接受的耗时将变得极长。解决方案是使用向量索引。Doris从某个版本开始支持了对ARRAYFLOAT类型的向量列构建倒排文件IVF或分层可导航小世界HNSW索引。这两种索引都能在牺牲少量精度的情况下将相似度搜索的复杂度从O(N)降至O(logN)。假设我们使用HNSW索引适合高召回率场景-- 创建向量索引 (语法可能随版本变化请以官方文档为准) ALTER TABLE faq_knowledge_base ADD INDEX vec_idx (question_vector) USING HNSW; -- 创建索引后优化查询语句使用特定的索引搜索函数 SELECT standard_question, answer, cosine_similarity(ai_embedding_vector(‘怎么安装‘), question_vector) AS score FROM faq_knowledge_base ORDER BY score DESC LIMIT 3; -- 注意Doris可能会自动在底层利用HNSW索引加速ORDER BY ... LIMIT的相似度计算也可能需要特定的函数包装如vec_search需查阅对应版本手册。重要提示向量索引的创建和维护有额外开销。HNSW索引构建速度较慢但查询性能好IVF构建快但需要定期根据数据分布重新训练。需要根据数据更新频率和查询性能要求做权衡。在数据首次向量化后创建索引并在数据批量更新后考虑重建索引。3.4 部署为实时服务将上述能力封装成即时的问答服务有两种常见模式模式一应用层封装在应用程序中如Java/Go/Python服务执行上述语义搜索SQL将结果返回给前端。这是最直接的方式Doris负责高效的向量检索和SQL计算。模式二使用Doris的HTTP接口或JDBC/ODBCDoris提供HTTP Rest API和标准的数据库驱动。你可以编写一个简单的后端服务接收用户问题拼接SQL查询Doris并返回结果。甚至可以将这个逻辑写成一个Doris的自定义函数UDF进一步简化调用比如SELECT get_faq_answer(‘用户问题‘)。模式三与现有AI服务栈集成如果你的问答逻辑更复杂例如需要先经过大模型理解意图、再检索知识库、最后让大模型组织答案RAG架构那么Doris可以完美扮演“向量数据库”的角色。你的AI应用服务先从Doris中检索出最相关的几条知识然后将这些知识作为上下文与大模型对话生成最终答案。4. 深入原理AI Function在Doris内部是如何工作的知其然更要知其所以然。了解AI Function的内部机制能帮助我们在出现问题时更好地排查也能更合理地使用它。4.1 内置函数的执行向量化计算引擎的延伸Doris以其高效的向量化执行引擎而闻名。内置的AI函数如cosine_similarity本质上就是利用了这个引擎。当执行cosine_similarity(vec_a, vec_b)时解析与优化FE前端接收到SQL后将其解析成逻辑计划。识别出cosine_similarity是一个内置函数。生成物理计划FE将逻辑计划转化为可在BE后端执行的物理计划。对于这个函数会生成一个对应的向量化计算算子。向量化执行BE在执行时不会像传统UDF那样一行一行处理。而是将vec_a和vec_b两列数据以列式批处理的方式加载到内存中。然后在一个CPU循环内对这两个数组的每一对元素执行乘积累加操作计算点积同时分别计算两个向量的L2范数最后完成余弦值计算。这个过程充分利用了现代CPU的SIMD指令集进行并行加速。结果输出计算出的相似度标量值作为新的一列输出。整个过程与计算SUM()、AVG()等聚合函数在引擎层面是类似的都是列式、向量化的。因此内置AI函数的性能非常高是原生C代码的速度。4.2 远程服务函数的执行可控的并行RPC调用远程函数ai_query的执行则是一个分布式RPC过程。查询规划FE分析出SQL中包含ai_query(‘endpoint‘, param)。FE知道这个函数需要在BE上执行且涉及网络调用。任务下发与并行化FE将查询分片Tablet调度到多个BE节点。每个BE节点负责自己分片上数据的处理。这是关键如果ai_query的参数来自于表中的某一列如ai_query(‘endpoint‘, content)那么每个BE会对自己持有的数据分片并发地向远程服务发起HTTP请求。RPC调用与容错BE节点会管理到远程服务的HTTP连接池。对于每一批数据它并发地或按配置的并发度发送请求。这里通常会包含超时设置、重试机制如3次和简单的故障处理如某个BE调用失败可能影响局部结果但查询可能不会完全失败取决于实现。结果解析与组装远程服务返回的通常是JSON。BE节点需要根据函数定义或全局配置解析JSON中的特定字段将其转换为Doris内部的列数据格式如INT, STRING, ARRAY等。数据汇总各BE处理完自己的分片后将结果返回给FEFE汇总后返回给客户端。性能与稳定性核心并发控制如果一张表有1000万行分布在100个BE上每个BE处理10万行。如果毫无节制地并发调用瞬间会向AI服务发起10万*1001000万次请求这绝对是灾难。因此必须在BE端或AI服务端实施严格的QPS限制和批处理。Doris可能提供相关配置参数如ai_query_concurrency_limit如果没有你可能需要在AI服务前部署网关进行限流。超时与重试网络和服务不稳定是常态。必须设置合理的超时时间如5-10秒和有限次数的重试如2-3次。结果缓存对于重复的输入参数可以考虑在Doris端或接入层增加缓存避免重复调用AI服务。例如相同的问题文本其向量化结果在短时间内是相同的。4.3 资源隔离与稳定性保障AI查询尤其是远程调用属于资源消耗型操作可能占用大量CPU内置函数或网络I/O远程函数。需要关注其对集群稳定性的影响。内存与CPU向量计算和大型模型推理可能消耗大量内存。需要监控BE节点的内存使用避免因AI查询导致常规OLAP查询因内存不足而失败。网络带宽远程调用会占用网络带宽。如果集群网络带宽有限大量的AI查询可能会挤占数据导入、副本同步等关键流量。建议在生产环境中可以考虑通过Doris的资源标签或查询队列功能将AI查询路由到特定的BE节点组实现物理隔离。或者为AI查询设置更低的优先级确保核心OLAP查询的响应时间。5. 生产环境部署避坑指南与最佳实践将AI Function用于生产远不止写对SQL那么简单。下面是我总结的一些关键实践和踩过的坑。5.1 模型服务选型与部署选择内置还是远程内置模型胜在简单、稳定、零延迟。适用于语义搜索、简单文本分类等通用场景。如果效果满足要求首选内置。远程模型能力强大、灵活。适用于需要高精度、多模态图、音、或复杂推理的场景。远程模型服务部署建议使用专用推理框架不要直接部署原始的PyTorch/TensorFlow模型服务。使用Triton Inference Server、TensorFlow Serving或Ray Serve等生产级推理框架。它们提供了并发管理、动态批处理、模型版本管理、监控指标等关键特性。启用动态批处理这是提升吞吐量的关键。推理框架可以将短时间内多个请求如来自Doris多个BE的请求在服务端自动合并成一个批次进行推理大幅提升GPU利用率。确保你的模型支持可变批次输入。设计高效的API接口应简洁输入输出最好是JSON并且字段名明确。对于向量生成服务可以考虑支持批量请求即一次传入多个文本返回多个向量减少HTTP开销。监控与告警对AI服务的GPU使用率、内存占用、请求延迟、QPS、错误率建立完善的监控和告警。5.2 Doris侧配置优化连接池与超时在Doris的BE配置中调整与AI服务通信的HTTP客户端参数。包括连接池大小、连接超时、读取超时、最大重试次数等。这些参数通常需要在be.conf中设置。# 示例参数 (具体参数名需查文档) ai_http_max_connections_per_host50 ai_http_connection_timeout_ms5000 ai_http_socket_timeout_ms30000 ai_http_retry_times2并发度控制如果Doris支持设置每个查询或每个BE节点调用AI服务的最大并发数防止突发流量击垮后端服务。启用结果缓存如果Doris支持对ai_query结果进行缓存基于参数哈希强烈建议开启。对于热点、重复的查询参数如热门搜索词能极大减轻AI服务压力。5.3 数据治理与成本控制向量字段的生命周期管理向量数据通常比原始文本大一个数量级一段文本几十字节其向量可能几千字节。需要规划存储成本。考虑对历史冷数据将向量字段转移到成本更低的存储如Doris的冷热分层功能。定期清理不再需要的向量数据。索引维护向量索引会占用额外空间且影响数据导入速度。制定索引重建计划特别是在知识库大规模更新后。调用成本审计如果使用按调用次数收费的云上AI API如OpenAI务必在Doris层或API网关层记录调用日志进行成本分析和用量控制。可以设置每日/每月预算和告警。5.4 典型问题排查链路当AI查询变慢或失败时可以按照以下链路排查问题现象ai_query函数执行超时。第一步检查Doris BE日志。查看是否有大量的HTTP超时错误。确认是网络问题还是服务端问题。第二步检查AI服务监控。查看服务端的CPU/GPU使用率、请求队列长度、错误日志。判断是否达到性能瓶颈。第三步测试直接调用AI服务API。用curl或Postman模拟Doris发送的请求看响应时间和结果是否正常。缩小问题范围。第四步检查Doris配置。确认ai_http_socket_timeout_ms等参数设置是否合理是否小于AI服务的实际处理时间。问题现象语义搜索结果不准确。第一步检查向量生成环节。用ai_embedding_vector对几个有明显语义差异的文本生成向量手动计算一下它们的余弦相似度看是否符合预期。如果不符可能是内置模型不适合你的领域。第二步检查向量索引。如果使用了HNSW/IVF索引尝试关闭索引进行暴力全量搜索对比结果。可能是索引参数如HNSW的ef_search、M设置不当导致召回率下降。第三步检查数据质量。标准问题的表述是否清晰、无歧义是否有大量重复或高度相似的问题问题现象查询内存不足OOM。第一步分析查询模式。是否在对一个超大表上亿行直接进行全表向量相似度计算未用索引这种操作本身就会产生巨大的中间结果。第二步检查向量维度。使用的向量模型维度是否过高如1024维可以考虑降维或使用维度更低的模型如384维在精度和性能间权衡。第三步调整资源配置。增加BE节点内存或通过SQL Hint为这类查询分配更多内存资源。6. 超越基础AI Function的进阶应用场景掌握了基础用法后我们可以探索一些更复杂的场景这些场景能充分发挥“在数据库内进行AI计算”的优势。6.1 实时个性化推荐传统推荐系统的特征计算和召回逻辑通常在数仓外完成延迟高。利用Doris AI Function可以实现准实时的特征计算与向量召回。场景在新闻APP中根据用户实时点击行为推荐相似文章。数据流用户点击日志通过Stream Load实时进入Doris。实时向量化在Doris中通过ai_embedding_vector函数将新闻文章的内容标题摘要实时转化为向量存入文章表。用户兴趣向量根据用户最近30分钟的点击记录将这些文章的向量进行加权平均或使用更复杂的模型生成一个代表用户当前兴趣的“动态兴趣向量”。实时召回当需要为该用户生成推荐时执行一条SQL计算其“动态兴趣向量”与文章库中所有文章向量的相似度排序取TopN。整个过程在百毫秒内完成。优势特征计算和召回逻辑全部用SQL表达与业务数据在同一系统中无需复杂的数据搬运和系统间同步实现了真正的实时推荐。6.2 多模态数据分析通过远程服务函数Doris可以处理的不只是文本。场景电商平台审核商品主图识别是否包含违禁品。数据存储商品表包含图片的URL或存储在对象存储的可访问路径。AI调用编写一个UDF或直接使用ai_query调用部署好的图像识别模型服务如YOLO。将图片URL或特征传给服务返回识别结果如{“contains_tobacco”: false, “contains_weapon”: true}。SQL化审核审核人员或自动巡检任务可以执行如下的SQLSELECT product_id, image_url, ai_query(‘http://image-audit-service/detect‘, image_url) AS audit_result FROM products WHERE JSON_EXTRACT(audit_result, ‘$.contains_weapon‘) true;所有审核逻辑、结果关联都在SQL中清晰呈现易于理解和维护。6.3 与流处理结合实时智能ETL在数据接入层就融入AI能力实现智能化的实时ETL。场景实时处理客服对话日志自动打上情感标签和问题分类。管道设计客服对话流如Kafka通过Doris的Routine Load持续导入一张临时表。智能处理对临时表的数据通过一个常驻的物化视图或周期性的INSERT INTO SELECT任务调用AI函数进行处理。-- 创建物化视图自动处理新数据 CREATE MATERIALIZED VIEW processed_chat_mv AS SELECT chat_id, customer_id, dialog_text, ai_query(‘http://sentiment-service/analyze‘, dialog_text) AS sentiment, ai_query(‘http://classify-service/category‘, dialog_text) AS category FROM incoming_chat_stream;结果落地处理后的结构化数据包含原始对话、情感得分、问题类别自动写入另一张结果表供下游的BI报表或告警系统使用。这种方式将AI能力变成了数据管道中的一个标准“处理算子”极大地简化了架构。从我实际的体验来看Apache Doris的AI Function代表了数据分析栈的一个重要演进方向智能内聚。它不是在数据库外另起炉灶搞一套复杂的AI系统而是将AI能力以最自然的方式SQL函数嵌入到数据处理的核心流程中。这降低了使用门槛缩短了数据到智能的路径让数据分析师和工程师能更专注于业务逻辑本身。当然它目前还不是万能的。复杂的模型训练、超参数调优、多轮对话等场景仍然需要专业的AI平台。但对于那些需要将AI模型“应用”到海量数据上进行批量或实时推理、检索的场景Doris AI Function提供了一个极其优雅和高效的解决方案。随着其生态的完善如支持更多的内置模型、更强大的向量索引、与主流模型框架更深的集成它的应用前景会越来越广阔。