EMR Serverless StarRocks Object Table：用 SQL 连接 OSS 文件与多模态 AI

商品图片、产品说明书、巡检视频和客服录音，通常存放在对象存储中；商品、订单、设备和客户信息，则保存在业务表中。当企业希望比较商品图片、提取文档信息，或把图文内容转成可检索的向量时，首先需要把这些分散的数据组织起来。

阿里云 EMR Serverless StarRocks 的 Object Table 将 OSS 文件清单映射为可查询的表，并通过文件描述符与 AI Function 衔接。 开发者可以用 SQL 筛选文件、理解多张图片、解析文档、生成多模态向量，再把结果保存到 StarRocks，与业务数据关联分析。原始文件继续保存在 OSS 中，内容在解析或推理时按需读取。

这让已有的 OSS 文件能够直接进入 SQL 数据处理流程。本文围绕“文件清单—内容加工—结果复用”展开，介绍 Object Table 的能力，并给出多图比较、图文融合向量和异步保存结果的实践示例。

01 从文件管理走向业务分析

以商品素材为例，一件商品可能同时具有主图、细节图和说明文档。运营人员想知道的往往是：“新旧主图有什么差异？”“说明书中的文字与图片展示的内容是否一致？”“哪些素材适合进入后续检索应用？”

这些问题涉及多个步骤：找到文件，确定文件与商品的关系，调用模型，保存加工结果，再关联商品属性和运营数据。自行开发时，常常需要维护对象存储访问、模型请求和数据库写入等多段代码。

Object Table 提供了一个 SQL 入口：先把文件 URI、大小、修改时间及类型等信息纳入查询，再选择需要加工的内容。AI Function 负责将选中的输入交给相应模型，结果可以继续参与查询或写入普通表。

业务问题	Object Table 与 AI Function 的组合方式	可保存的结果
商品素材对比	按商品关联图片 URI，在一次请求中比较多张原图	差异描述、素材说明
文档知识加工	选择文档，提取文字，分块并进行摘要或文本向量化	文本片段、摘要、文本向量
图文共同表达	将文档文字与原图作为同一次请求的输入	图文理解结果、融合向量
音视频内容分析	按类型选择音频或视频，调用适配的转写或理解函数	转写文本、视频摘要及分段信息

表中的场景是应用设计示例。具体输出质量取决于文件内容、模型能力和提示词，需要结合业务样本评估。

02 Object Table 如何连接 OSS 与 AI Function

Object Table 包含三个关键元素：

• 对象元数据：object_uri、size、etag、last_modified 等列，用于定位文件、筛选输入和组织后续加工。

• 文件描述符 **file**：以 JSON 形式携带文件引用和表上下文，供解析与 AI 函数使用；它不是文件原始字节。

• 显式刷新：通过 REFRESH OBJECT TABLE 更新对象清单。文件新增、覆盖或删除后，需要再次刷新，才会反映到表内清单。

处理过程可以分成五步：OSS 保存原始文件；Object Table 提供文件清单；SQL 选择输入并调用 AI 函数；结果表保存文本或向量；业务查询复用这些结果。

查询文件清单不需要先下载全部内容。执行文档解析或多模态推理时，仍会发生必要的内容读取或模型访问。清单刷新也不会自动调用模型，已有的摘要、向量等结果需要由后续加工任务更新。

这种分工使文件管理与内容加工可以独立安排：先检查待处理文件的范围，再决定使用哪个模型、处理哪些记录、如何保存结果。

分层架构：从文件入口到应用服务

在完整应用中，可以将这条流程进一步拆成“数据源、文件入口、SQL 加工、结果资产、应用服务”五层。模型服务位于处理链路的一侧，业务数据通过独立入口参与筛选与关联；原始文件并不因为创建 Object Table 而整体搬入数据库。

图中下游的业务分析、素材搜索与知识问答 是基于加工结果构建的应用，需要配置相应索引、查询接口、访问控制和调用编排。Object Table 提供的是文件入口，不能仅凭建表就获得完整应用。

层次	核心职责	设计时需要明确的内容
原始数据	OSS 保存文档、图片与音视频；业务表保存商品、设备等属性	文件作用域、业务 ID 与 URI 的关联关系
文件入口	Object Table 保存清单与 file 描述符	刷新时机、目录范围、文件访问权限
SQL 与 AI 加工	用 SQL 选择输入，通过解析函数或模型调用提取内容	模型、Prompt、输入类型、单批处理范围
结果资产	保存片段、字段、描述、向量及来源信息	结果表结构、处理版本、质量状态和更新策略
应用服务	复用结果做分析、搜索、问答或为 Agent 提供查询工具	索引与召回、业务权限、引用溯源和效果验收

清单刷新和内容读取走不同的路径。 刷新阶段由 FE 组织 OSS 对象列举，将匹配对象的元数据加载到临时分区，完成后再替换正式清单；失败时保留上次成功的清单。查询元数据时扫描的是 StarRocks 中的表记录。进入文档解析或 AI 推理后，执行节点才处理文件引用，并按需要读取内容或准备模型可访问的临时地址。

这个分界有两点价值：一是可以在模型调用前检查数量、类型与业务范围；二是便于按清单刷新、文件访问和模型调用分段排查。清单替换成功并不表示 AI 加工已经完成，也不锁定后续读取时的 OSS 文件内容版本。

创建并查询一个文件清单

下面的示例面向已支持 Object Table 的 EMR Serverless StarRocks 存算分离实例。请先准备独立数据库与专用 OSS 目录，确认实例的模型能力、网络和权限可用，再在当前数据库创建表。示例名称应尚未使用。文中的 qwen3.8-max 与 qwen3-vl-embedding 是示例使用的模型名，实例需要已开通相应服务，调用账号需具有 AI FUNCTION 使用权限。它们不是本例新建的 Resource 名称。音视频加工则还需单独配置适配的模型 Resource，本文不展开其配置。

建表中的占位值需替换为自己的配置；OSS 地域与 endpoint 必须匹配，凭证须能列举目录和读取对象。实际凭证应受控提供，不要写入共享文档。

CREATE OBJECT TABLE oss_files
PROPERTIES (
    'path' = 'oss://<bucket>/object-table-demo',
    'aliyun.oss.endpoint' = 'oss-<region>-internal.aliyuncs.com',
    'aliyun.oss.region' = '<region>',
    'aliyun.oss.access_key' = '<AccessKey ID>',
    'aliyun.oss.secret_key' = '<AccessKey Secret>',
    'recursive' = 'true',
    'file_pattern' = '(?i).*[.](txt|md|pdf|docx|jpg|jpeg|png|wav|mp4)'
);

REFRESH OBJECT TABLE oss_files;

SELECT object_uri, size, etag,
       object_file_type(file) AS file_type
FROM oss_files
ORDER BY object_uri;

recursive 用于包含子目录；file_pattern 是文件路径的正则过滤条件。Object Table 的列由系统定义，不需要额外声明列或分布方式。

object_file_type(file) 可返回 image、video、audio、text、document 或 unknown。该分类依据描述符信息及文件扩展名，不代表已经解码文件或验证了模型兼容性。

03 直接用 Object Table 元数据比较多张图片

多图理解需要让模型在同一次请求中看到多个原始输入。例如，新旧商品图的差异比较，需要同时提供两张图片，而不是先各自生成一句描述，再比较描述文本。

在专用 OSS 目录中准备 img1.jpg 与 img2.png，刷新清单后，可以直接从 Object Table 取出完整 object_uri：

SELECT ai_complete(
    'qwen3.8-max',
    '对比这两张图片的差异',
    [
        MAP{'image': a.object_uri},
        MAP{'image': b.object_uri}
    ]
) AS comparison
FROM oss_files a
CROSS JOIN oss_files b
WHERE a.object_uri LIKE '%/img1.jpg'
  AND b.object_uri LIKE '%/img2.png';

这里的数组是一次多内容请求，image 对应图片地址。该 SQL 已在验证环境返回非空的图片差异描述。模型回答会随输入及生成过程变化，应按业务要求检查质量。

客户可以仅通过 Object Table 元数据完成上述流程，不需要编写 OSS SDK 代码生成图片链接。 在已配置的 OSS 访问与签名环境中，StarRocks 会为完整 oss:// 图片 URI 生成模型可访问的临时地址，再发起请求。该过程依赖实例的访问权限和模型服务的网络可达性，并不意味着任意 OSS 地址都可直接读取。

示例要求两个筛选条件各匹配一行。实际业务中应使用明确的完整 URI 或业务配对条件，控制输入数量，避免 CROSS JOIN 产生大量图片组合。

需要区分“完整 URI”和“相对文件名”：扫描 Object Table 行得到的 object_uri，以及这些行上的 object_file_uri(file)，可提供完整路径；不要将单独的 img1.jpg 当成完整 URL 放入多内容数组。

一次多模态请求如何组织输入

下面的图把多图比较与图文融合放在同一视图中。两条路径都从 Object Table 出发，但组合输入的方式不同：多图比较把两张原图放入一个数组；图文融合先提取文档文字，再与原图一起交给同一个模型请求。

需要区分三个对象：file 是带有表上下文的文件描述符，object_uri 是文件位置，图片或文档内容才是模型实际处理的信息。多内容数组中的 image 值使用完整 URI 字符串，不能直接塞入整个 file JSON，也不能把相对文件名当作可访问地址。

单文件调用由描述符关联 Object Table 的访问上下文；多 URI 请求则对完整 oss:// 地址走相应的访问与临时签名路径。因此，单文件解析成功后，仍应单独验证多内容请求的文件可达性。客户侧无需编写 OSS SDK，但实例的文件访问和模型访问配置都必须就绪。

图文融合向量表示一次组合输入的整体语义，不是把单独生成的图片向量和文本向量简单拼接。模型调用成功之后，还需检查输入配对是否正确、输出是否非空，以及结果是否满足业务用途。

04 从文档文字到图文融合向量

文件进入 SQL 流程后，可以选择不同的加工路径。

转成文本，便于阅读与结构化分析。 文档可通过 ai_parse_document 提取文字，再进行分块、摘要、信息提取或文本向量化。图片可通过 ai_complete 生成描述；音频转写与视频理解分别由 ai_transcribe、ai_video_understand 等能力承接，并配置支持相应媒体的模型 Resource。

保留原始模态，生成融合表示。 当任务需要同时保留图像和文字语义时，可以将两者直接交给多模态模型。以商品说明与商品图片为例，在同一 Object Table 目录准备非空 UTF-8 文件 note.txt，确认 img1.jpg 已存在并刷新清单后，可以让文档文字与原图一起参与理解：

SELECT ai_complete(
    'qwen3.8-max',
    '结合文字说明，用一句话分析图片',
    [
        MAP{'text': ai_parse_document(
            to_file('oss_files', 'note.txt'))},
        MAP{'image': object_file_uri(file)}
    ]
) AS description
FROM oss_files
WHERE object_uri LIKE '%/img1.jpg';

to_file 将指定路径绑定到已有 Object Table，文档解析函数负责提取文字；图片则来自当前扫描行。该组合已验证返回非空描述。

使用同样的输入，还可以生成图文融合向量：

SELECT array_length(ai_embed_multimodal(
    'qwen3-vl-embedding',
    [
        MAP{'text': ai_parse_document(
            to_file('oss_files', 'note.txt'))},
        MAP{'image': object_file_uri(file)}
    ]
)) AS dimensions
FROM oss_files
WHERE object_uri LIKE '%/img1.jpg';

这个例子将文字与图片组合为一个融合向量，本次验证配置返回 2560 维。array_length 仅用于展示维度；需要保存完整向量时，使用内部 ai_embed_multimodal(...) 的返回值。

融合向量与“先生成图片描述、再对描述做文本向量化”是两条不同路径。前者直接使用原图与文字共同生成表示，后者便于阅读和检查生成的描述。应根据业务目标选择，并用自己的样本评估检索效果；向量成功返回并不等于检索质量已经达标。向量存储、索引及检索应用还需另行设计。

文档解析也有格式边界：含可提取文字的 PDF、普通 DOCX 和文本文件适合先做验证，扫描件不能直接视为已有通用 OCR 能力。音视频的输入格式、长度和分段输出同样受模型能力影响。

连接 AI 下游：从可复用结果到检索、RAG 与 Agent

AI 下游通常分为预加工与在线查询两个阶段。预加工把原始文件变成可复用的文本、字段或向量；在线阶段根据当前用户的问题选择相关结果，再组织回答或业务分析。这样，提问时可以查询已加工的数据，无需重新解析整个文件目录。

文档知识库路径。 文档经过解析与分块后，每个片段保存源 URI、内容版本、片段标识、文本及向量。用户提问时，采用与该集合相匹配的编码方式生成查询向量，再检索相关片段。应用将命中的片段与问题组成提示词，调用生成模型，返回答案及引用来源。这就是检索增强生成（RAG）的一种组织方式。

商品与素材路径。 将同一商品的说明文字与图片组合为融合向量，保留商品 ID、源 URI、业务属性与处理版本。查询可以围绕素材的语义相似性展开，再结合类目、有效状态或用户权限筛选；最终返回素材及相关业务信息。图片描述和结构化属性也可以直接参与聚合分析，不一定经过问答生成。

两条路径应分别定义结果集合。文本向量与图文融合向量不能仅因为维度相同就混在一起检索；模型、向量空间、归一化方式及距离度量都需要匹配。图中表达的是应用分层，不假定不同模型的输出天然兼容。

建议保存的信息	用途
object_uri、业务 ID、源内容标识	将加工结果关联回原文件与业务记录
片段 ID、片段文本、图片描述或提取字段	提供可阅读、可检查的检索内容和生成依据
向量、模型标识、处理版本	明确属于哪个结果集合，支持模型或 Prompt 变更后的重建
加工时间、质量状态	判断结果是否可用，组织补加工与失败处理
业务可见范围或权限关联键	在向模型提供上下文及向用户返回结果之前落实权限过滤

这些是建议的业务结果模型，不是 Object Table 自动新增的系统列。建立索引、选择召回与重排策略、过滤无权限内容、拼接上下文以及检查答案引用，都属于应用需要配置和验收的部分。

对于 Agent，可以将经过授权的搜索或分析查询封装为工具，由应用返回候选素材、结构化结果与来源信息。Object Table 负责文件入口和加工衔接，Agent 的工具选择、会话状态及业务操作权限仍由应用管理。

05 将 AI 加工结果保存下来，接入后续业务查询

交互查询适合探索少量样本。需要持续使用图片描述、文本摘要或向量时，可以将结果写入 StarRocks 表，再与商品、订单或设备等业务数据关联，避免业务查询每次都重新生成内容。

结果表建议保留源 URI、源内容标识、模型或处理版本、结果和加工时间。下面沿用前面同一数据库中的 oss_files，展示图片描述的异步写入。初次执行应将 OSS 目录控制在少量图片范围内。

CREATE TABLE image_results (
    object_uri VARCHAR(1024),
    source_etag VARCHAR(256),
    pipeline_version VARCHAR(32),
    description STRING,
    processed_at DATETIME
) PRIMARY KEY(object_uri, source_etag, pipeline_version)
DISTRIBUTED BY HASH(object_uri) BUCKETS 1;

通过 SUBMIT TASK 在后台执行加工和写入，查询逻辑同时筛选当前尚无非空描述的图片：

SUBMIT TASK ai_image_batch
PROPERTIES (
    "session.insert_timeout" = "120",
    "session.enable_profile" = "true"
)
AS INSERT INTO image_results
SELECT o.object_uri, COALESCE(o.etag, ''), 'caption-v1',
       ai_complete('qwen3.8-max', '用一句话描述图片', o.file, 'image'),
       now()
FROM oss_files o
LEFT JOIN image_results r
  ON o.object_uri = r.object_uri
 AND COALESCE(o.etag, '') = r.source_etag
 AND r.pipeline_version = 'caption-v1'
WHERE object_file_type(o.file) = 'image'
  AND (r.object_uri IS NULL
       OR r.description IS NULL
       OR LENGTH(TRIM(r.description)) = 0);

这里直接传入 Object Table 的 file 进行单图理解。caption-v1 是业务定义的处理版本，更换提示词或模型后应更新；任务属性中的超时与 Profile 配置属于执行会话，不是模型参数。SUBMIT TASK 官方说明

提交成功仅表示任务被接收。结合提交时间与 QUERY_ID 定位本次运行，确认 STATE='SUCCESS' 后，再核对本轮预期记录的数量与非空描述。历史成功记录不能代表本次任务结果：

SELECT TASK_NAME, CREATE_TIME, STATE, ERROR_CODE, ERROR_MESSAGE, QUERY_ID
FROM information_schema.task_runs
WHERE TASK_NAME = 'ai_image_batch'
ORDER BY CREATE_TIME DESC;

SELECT object_uri, source_etag, pipeline_version,
       description, processed_at
FROM image_results;

上述图片链路已验证一条记录成功加工并持久化。扩大范围时，仍需检查任务状态、结果数量、空回答和业务质量；不要把小样本成功当作吞吐或并发去重结论。

对于持续批处理，可以先将本轮待处理记录物化为中间表，检查范围后再提交 AI 加工。上一批结束后重新筛选，处理新增或失败记录。不要并发提交同一批次，也不要将结果表的主键等同于模型请求只执行一次。

ETag 可以辅助识别内容变化，但不会锁定后续读取时的文件版本。示例将缺失 ETag 转为空字符串；此时应补充业务版本，或采用不覆盖的文件路径。结果表应保存原始 URI，不应保存会过期的临时签名 URL。

运行设计：显式刷新、批次加工与结果验收

持续处理文件时，需要把“清单已更新”“本批已提交”“结果可供业务使用”区分开。下面给出由业务或调度系统组织的运行流程；箭头表示调用与依赖关系，不代表 Object Table 自动维护整条加工链路。

建议将清单刷新与模型加工分别作为可检查的步骤：先等待刷新成功，确认对象范围；再根据源 URI、内容标识和处理版本选择本轮待处理记录。批次较复杂时，先将待处理范围物化到中间表，再由 SUBMIT TASK 执行 AI 处理与写入。

任务提交返回 SUBMITTED，只能说明任务已接收。使用本次提交时间和 QUERY_ID 关联 task_runs，确认 STATE='SUCCESS' 后，还要核对预期记录数、空回答、行级错误与业务质量。任务状态和结果质量是两层检查，不能相互替代。

发生的变化	调度或业务逻辑需要做的事
OSS 新增或覆盖文件	显式刷新清单，按内容标识与结果版本重新筛选
Prompt、模型或分块策略改变	更新处理版本，明确需要重建的结果范围
任务失败、空结果或质量不合格	检查原因，选择待重试记录，上一批结束后再提交
源文件被删除或业务权限改变	更新下游结果的有效性与可见范围，按业务策略失效或清理

跳过已有有效结果依赖业务 SQL 的筛选条件，而不是自动增量计算保证。任务互斥、重试次数、超时处理和结果发布时机也需要由调度或应用定义。模型请求可能重复发生，结果主键并不提供“只调用一次”的语义。

如果下游不允许读取未验收的数据，可以在应用结果模型中增加批次标识和可用状态，待本批质量检查通过后再切换可查询范围。这是一种可选的业务设计，相关字段和发布规则需要自行建立。

架构参考与实现选择

本文借鉴了 Hologres 文档将文件入口、数据加工、持久化结果与应用服务分层说明的方法。Hologres 的自动刷新与依赖管理由 Dynamic Table 提供；其 Object Table 文档仍要求显式刷新清单。本文的 StarRocks 运行流程采用已验证的 REFRESH OBJECT TABLE、业务筛选和 SUBMIT TASK，调度依赖由业务明确组织。Hologres Dynamic Table 介绍、Hologres Object Table 文档

06 从一个小场景开始构建可复用流程

Object Table 的落地点可以很具体：为一组商品补齐图片描述，为一个知识库提取文档文字，或为一批商品素材生成图文融合向量。先完成一条能够检查输入、输出和业务效果的路径，再逐步扩大处理范围。

可以按照以下顺序推进：

1. 连接文件清单：在专用目录创建 Object Table，刷新并检查 URI、数量与类型。

2. 验证一组样本：确认文件能读取、模型能访问，SQL 返回符合预期的文本或向量。

3. 定义结果与版本：保留源文件标识及处理版本，明确空结果、失败和业务质量的判定方式。

4. 批量加工与业务复用：分批保存结果，关联业务数据，并按实际变化安排后续刷新与加工。

企业可以沿用 SQL 来组织文件与业务数据，把多模态内容逐步接入已有分析流程。

常见问题

Object Table 会把 OSS 文件全部复制到 StarRocks 吗？

不会。Object Table 保存对象元数据与文件描述符，原始文件仍在 OSS。执行解析或模型推理时才发生相应的内容读取。

使用 OSS 图片调用 AI Function，需要客户自己编写签名代码吗？

本文已验证的路径不需要客户编写 OSS SDK：单文件处理可以直接使用表内 file；多内容请求可以使用表内完整 object_uri。实例需具备相应的 OSS 访问与签名环境，模型也需能读取生成的地址。

两张图片，或文字加图片，可以在一次请求中处理吗？

可以。本文的 ai_complete 使用多内容数组完成两图比较或图文共同理解；ai_embed_multimodal 可以将组合输入生成一个融合向量。具体输入类型和数量还需符合所选模型的限制。

新文件上传后，会自动产生摘要和向量吗？

不会。需要先刷新 Object Table 清单，再执行相应加工任务。清单更新与 AI 结果更新是两个步骤，应按业务需要安排调度。

删除 Object Table 会删除 OSS 文件吗？

不会。删除表不会删除 OSS 中的源对象；文件的生命周期继续由 OSS 和业务规则管理。

本文示例基于支持相应能力的实例验证。不同实例版本和模型服务的可用能力可能不同，请以目标实例支持情况为准。了解 StarRocks AI 的整体能力，可从阿里云 EMR Serverless StarRocks AI Function 文档进入。