电视剧《卡夫卡2026》剧情介绍
2026-07-22 3416669
2026-07-22 0
过去十多年，大数据系统的主线相对清晰：以结构化表为主要数据模型，以SQL为核心交互方式，以稳定的集群和业务负载支撑数据分析。Hadoop、Spark、Flink以及各类OLAP系统，基本都建立在这一假设之上。
进入AI时代后，这些基础假设正在发生系统性变化。企业不再只处理结构化数据，也需要处理图像、视频、文本、Embedding、JSON、Blob等多种数据形态；数据系统的使用者也不再只有人，Agent和模型会以更高频、更低延迟的方式访问数据；同时，AI工作负载对弹性、隔离、成本和可观测性提出了更高要求。
本文围绕一个核心问题展开：当数据模态、查询范式和基础设施负载同时变化时，湖仓系统应如何从传统的结构化分析平台，演进为面向AI的统一多模态分析检索平台。
数据模态、查询范式与云原生基建的三重重塑
传统湖仓主要围绕结构化表组织数据，而AI场景需要同时建模结构化数据、半结构化数据、文本、对象以及向量。视频、图像等非结构化对象经过模型处理后会产生Embedding；日志、埋点和异构Schema则常以JSON或Variant的形式存在；文档和文本数据还需要全文索引和关键词匹配能力。这意味着数据系统不能只优化单一的列式表扫描，而需要同时支撑标量、向量和全文的混合检索。
过去的数据分析以人编写SQL、查看报表为主，系统的核心目标是稳定、准确和高吞吐。现在，越来越多的访问来自自然语言接口、DataAgent或AIAgent。用户可能通过自然语言描述问题，由系统生成SQL；也可能直接表达一个语义检索意图，例如"找到雨夜机动车加塞的训练样本"。这种查询既包含结构化过滤条件，也包含向量相似度检索和全文匹配，要求系统在一条查询链路中完成联合优化。
AI工作负载具有明显的弹性和突发性，既要支持低延迟交互，也要隔离业务查询、索引构建、Compaction、ETL和模型调用等不同任务。因此，AI-Ready的数据基建需要在Lakehouse统一数据面之上，进一步强化弹性隔离、可观测性、智能运维以及模型能力集成。
这三类变化共同指向同一个方向：未来的湖仓系统需要从结构化分析引擎，演进为能够统一管理多模态数据、统一表达混合检索、统一调度多类工作负载的全模态分析引擎。
Paimon2.0多模态存储与GlobalRowID关联模型
Lakehouse的价值已经被广泛验证。它的第一项核心价值是"一份数据"：数据不需要在不同系统之间反复复制，从而降低一致性风险。对于数据工程而言，一致性是底线；相比于延迟或局部性能波动，结果不一致往往更难接受。第二项价值是低成本，湖仓架构将大规模数据放在对象存储等低成本介质中，通过计算引擎按需访问和优化查询路径，避免为每一种场景都维护一套昂贵的数据副本。第三项价值是开放性，数据以Parquet、ORC等开放格式保存，避免被单一厂商或单一系统绑定，使不同计算引擎能够在统一数据面上协同工作。
在Paimon1.0阶段，实时更新、LSMCompaction、湖表一致性以及与计算引擎的协同已经形成了较为完整的能力。随着AI与BI一体化从概念走向生产实践，Paimon2.0需要进一步承载多模态数据：结构化数据仍然可以保存在Parquet或ORC中；图像、视频等对象数据可以保存在Blob文件中；向量数据和向量索引则可以使用更适合检索的存储形式。关键问题在于——这些不同物理形态的数据，必须在逻辑上保持统一。
Paimon2.0的解法是全局RowID： 每一行数据拥有稳定的RowID，向量索引、对象文件、标量列和全文索引都可以围绕RowID建立映射。检索时，向量索引首先返回TopKRowID；随后系统再通过Paimon的元数据和Manifest找到对应的物理文件并回捞相关列。这样，索引与物理文件被解耦，Compaction改变的是文件布局，而不是数据行的逻辑身份。这是多模态湖仓能够保持稳定性和可维护性的基础。
传统"多系统拼接"检索的成本、延迟与一致性瓶颈
多模态混合检索解决的是企业AI数据准备中的一个典型痛点。当前很多系统会将标量数据放在OLAP引擎中，将文本放在Elasticsearch等全文检索系统中，将向量放在专用向量数据库或单机检索库中。一次业务查询往往需要先在OLAP中过滤标签，再在向量库中做相似度检索，再在全文系统中做关键词匹配，最后由应用层将三路结果拼接、Join或重排。
这种架构带来三个问题：
成本高： 同一份数据要为不同检索系统维护多个副本；
延迟高： 多个系统之间缺少统一优化，只能由应用层串联执行；
一致性弱： 数据在不同系统间同步存在延迟和失败风险，同一查询条件下可能得到不一致的结果。
在AIData场景中，这类查询非常常见。例如，训练数据准备可能需要从海量视频片段中筛选"雨夜"“急刹”"加塞"等标签，同时要求画面语义与某段典型场景相似。它不是单纯的SQL分析，也不是单纯的向量检索，而是标量过滤、向量ANN、全文匹配和融合重排共同参与的混合检索。统一引擎的目标，就是让这些能力在同一份数据、同一套优化器和同一条SQL链路中完成。
StarRocks面向AI时代的能力全景
StarRocks过去在极速OLAP、实时分析和Lakehouse查询方面积累了较多能力。面向AI时代，StarRocks的演进方向不是放弃OLAP，而是在OLAP之上补齐Search能力，形成Search&OLAP混合引擎。
从应用层看，传统即席查询、BI报表和实时湖仓仍然是重要场景；新增的AIData准备、AIAgent、AIMemory等场景，则需要系统提供向量检索、全文检索、混合检索和AIFunction。数据可以来自业务数据库、日志埋点、IoT、非结构化对象和外部知识源，通过Kafka、FlinkCDC、DataX、文档解析和Embedding等链路进入统一存储。
从存储层看，StarRocks既支持自身内表，也支持Lakehouse湖表，包括Paimon、Lance、Iceberg等开放格式。其中，Paimon与StarRocks在多模态湖表上的协同最为直接。整体目标可以概括为三条主线：
Search场景能力补强（全文、向量、混合检索）；
LakehouseOLAP持续演进（湖表查询性能与开放性）；
AIAgentic场景拓展（AIFunction、Memory、Agent数据面）。
全文、向量、混合三类检索能力矩阵
StarRocks的多模态分析检索能力包括全文检索、向量检索和混合检索三类：
全文检索： 主要面向日志存储、智能分析、文本匹配和半结构化数据过滤等场景，支持BM25排序、倒排索引和智能分词。
向量检索： 主要面向RAG、语义相似度搜索、图像与文本多模态检索等场景，支持HNSW、IVFPQ、DiskANN等主流ANN算法，并在系统层面对带标签过滤的FilteredANN做优化。
混合检索： 将标量过滤、向量召回和全文召回统一在同一条查询链路中，不仅支持多路召回，还需要支持权重配置、RRF等融合算法以及自定义Reranker。
对于智能驾驶训练数据准备、电商商品精准搜索、RAG知识问答增强等场景，混合检索比单一检索方式更接近真实业务需求。这一能力组合的关键不在于简单叠加多个检索模块，而在于让OLAP查询、全文检索、向量检索和融合重排共享统一的SQL表达、执行框架、缓存体系和数据一致性语义。
FE、计算层、存储层三层协同的多模检索架构
从整体架构看，StarRocks的多模检索需要在FE、计算层和存储层同时进行增强。
FE需要完成SQL解析、CBO优化、Search短路径设计以及Pre-Filter/Post-Filter策略选择。对于纯向量检索，如果仍然经过过重的通用优化流程，FE本身可能成为延迟瓶颈；因此需要为Search查询提供更短的执行路径。对于带标量过滤的向量查询，则需要根据过滤选择率、TopK大小和索引成本，在Pre-Filter与Post-Filter之间选择合适策略：
Pre-Filter： 先用标量条件缩小候选集，再在候选集上做向量检索，适合过滤选择率高的场景；
Post-Filter： 先扩大向量召回，再从召回结果中筛选满足标签条件的数据，适合向量召回成本更低或过滤条件较宽的场景。
系统级优化的价值在于，它可以根据统计信息和执行代价自动选择策略，而不是把选择固定在应用层。
在计算层，StarRocks需要扩展ANN、全文、HybridSearch和Rerank等算子，并与传统OLAP执行引擎协同。在存储层，系统同时支持内表专用索引和湖表开放格式索引。引入多模态检索后，本地Cache的管理也更复杂：PageCache、元数据Cache、湖表文件Cache、向量索引Cache需要被统一调度，才能在有限内存中获得稳定性能。
DataFile×IndexShard×RowIDRange的湖表索引模型
湖表和内表在索引模型上存在本质差异。内表通常围绕Segment建索引，索引与物理数据文件关系紧密；当Segment过小、持续写入或发生Compaction时，索引构建和重建会影响实时性与成本。湖表则更适合通过GlobalIndex将索引与物理文件解耦。
以Paimon为例，多个DataFile可以共同对应一个IndexShard。每个Shard记录一个RowID范围，例如[0,199999]或[200000,399999]。向量索引、全文索引、BTree索引或Bitmap索引都可以围绕RowID范围构建。查询时，索引返回的是RowID，而不是某个瞬时物理文件位置。
这种设计有两个重要收益：
第一， RowID是每一行数据的稳定逻辑标识，因此不同模态的数据可以通过同一个RowID关联；
第二， Compaction只改变文件的物理组织，不改变RowID范围本身，因此多数情况下不需要因为物理文件合并而重建索引。
在场景选择上，湖表更适合数据量极大、时效性要求中等、希望以低成本对象存储承载大规模多模态数据的场景；内表更适合数据量中等、时效性要求更高、需要在新写入数据和索引数据之间做混合访问的场景。二者并不是互相替代，而是在不同数据规模和新鲜度要求下形成互补。
检索阶段与回捞阶段的职责分工
StarRocks对湖表的VectorSearch与FullTextSearch采用严格的两阶段设计。
系统接收到向量检索、全文检索或混合检索查询后，FE会生成包含Search算子的执行计划，并将任务分发到计算节点。计算节点扫描已经构建好的索引Shard，每个Shard先局部返回TopK候选结果。随后，系统在全局范围内对各个Shard的候选集进行Merge，得到最终候选RowID。
第一阶段输出的是RowID，而用户最终查询的通常是图像路径、文本、标签、分数、业务主键等列。因此，系统需要根据RowID到Paimon文件和元数据中回捞对应行，并返回完整结果。
两阶段设计的优势在于职责清晰：第一阶段可以针对索引扫描、TopKMerge和多路召回做优化；第二阶段可以针对RowID到列数据的回捞、行存索引、列裁剪和延迟物化做优化。后续优化方向包括将部分Merge工作从FE下沉到计算层，降低FE的CPU与内存压力；以及根据文件格式和列布局决定是否在打开索引或数据文件时顺带回捞部分标量列。
内表Segment组织下的检索+回捞流程
内表的Search框架与湖表在整体流程上相似，也可以分为检索和回捞两个阶段，但它的物理组织不同。内表中，向量、标量和其他列通常位于同一套Segment体系内，因此索引构建、数据新鲜度和回捞策略需要围绕Segment管理。
在写入较实时的场景下，系统不适合为非常小的Segment立即构建完整向量索引。更合理的做法是让数据先积累到一定规模，或经过Compaction形成更稳定的Segment后，再异步或同步构建EnhancedVectorIndex。对于尚未建索引的新数据，系统可以采用索引搜索与暴力搜索混合的方式保证可见性。
内表也会借鉴湖表的延迟物化思想：先在索引中得到候选RowID或行号，完成全局Merge后，再回到Segment中读取真正需要的标量列。反过来，湖表也可以借鉴内表在同一文件布局中减少二次回捞的能力。两种表模型的优化方向，本质上是在索引效率、数据新鲜度、回捞成本和存储开放性之间寻找平衡。
全文、向量、标量三路召回在引擎内部的融合执行
多路召回是混合检索的核心。它解决的不是"是否支持向量检索"这样单点能力问题，而是如何把全文、向量、标量过滤和业务排序统一到一个系统中执行。
如果没有统一引擎，应用层通常需要分别访问全文系统、向量系统和OLAP系统，再自行合并结果。这不仅增加数据搬迁和一致性风险，也使优化空间被割裂。StarRocks的做法是将多路召回放入引擎内部：全文召回、向量召回和标量过滤可以并行执行，候选集在计算层进行融合和重排，最终以SQL结果形式返回。
这一框架适用于多类场景。例如，智能驾驶需要从视频和图像中挖掘特定驾驶场景；人群画像不再只依赖结构化标签，也会结合文本与语义向量；广告素材投放需要同时考虑关键词、视觉语义、商品标签和业务指标。统一执行框架使这些场景能够在同一份数据上完成端到端检索。
标签召回与向量召回在clip_id上的FullJoin融合
以"雨夜机动车加塞"为例，可以同时构造两路召回：
标签/关键词召回： 在结构化标签、全文字段中检索"雨夜""加塞"等条件；
向量召回： 输入一段典型雨夜加塞场景的向量表示，寻找视觉语义上相近的视频片段。
这个例子要说明的重点是：同一个业务意图在不同模态中会形成不同证据，融合检索需要把这些证据统一到同一个候选集合中进行排序。
单独依赖标签并不充分。标签可能来自模型打标，虽然整体准确，但仍会受到识别误差、标签粒度和上下文理解不足的影响。例如，某些片段确实是加塞场景，但打标模型没有准确识别"加塞"；也可能有些片段被标成"加塞"，但实际画面中的行为并不典型。单独依赖向量也不充分，因为向量相似度更擅长表达画面语义接近，却不一定严格满足业务标签。多路召回的价值在于，它让不同证据来源互相补充。
具体到实现，可以把两路结果理解为两个有序候选表：一张表来自标签或全文召回，另一张表来自向量召回。系统以clip_id作为关联键，对所有出现过的候选做FullJoin；如果某个片段只被一路召回，另一侧的分数就是空值。这样做的意义是，不提前丢弃任何一路发现的潜在样本，而是在融合阶段统一打分。
融合打分可以采用RRF、加权融合或自定义Reranker。如果认为向量语义更可靠，可以提高向量分数的权重；如果认为标签与向量同等重要，也可以将两路权重都设为0.5。经过融合后，Demo中排名最靠前的是C27、C03和C08——这三个片段的共同特点是：既被标签或全文侧召回，也被向量侧召回，说明它们同时满足"标签判断正确"和"视觉语义相似"两个条件，因此可以作为Top3高置信结果。
排名后面的C11和C42则体现了融合检索对召回率的保留能力。它们可能只在一路召回中表现较好，或者两路证据没有C27、C03、C08那么一致，因此置信度低于Top3；但从业务角度看，它们仍然可能是足够接近"雨夜机动车加塞"的有效候选。对于训练数据准备而言，这类样本不一定应该被直接丢弃，而是可以进入Top5或更大的候选集，由后续人工校验、自动评估或Reranker进一步处理。
因此，多路召回不是简单求交集，也不是简单求并集，而是在召回率和精确率之间进行可解释、可调节的排序优化。对于训练数据准备，这一点尤其重要，因为数据集质量会直接影响后续模型训练或评估效果。
阿里云EMRServerlessStarRocks在开源StarRocks的基础上，围绕多模态检索场景进行了全面的商业版增强。这些增强覆盖AIFunction集成、Stella自研引擎性能优化、Paimon湖表原生适配、DataCache统一管理以及全托管免运维等方面，使其成为面向AIData场景开箱即用的企业级选择。
AIFunction将模型调用纳入SQL数据处理链路
除检索能力外，阿里云EMRServerlessStarRocks还与大模型能力集成，形成完整的多模态数据处理链路。AIFunction让用户在SQL中调用外部模型能力，对原始对象进行解析、打标、Embedding、结构化抽取或文本生成。
在很多企业里，多模态数据处理往往由Python脚本、离线任务与多个服务拼接完成，工程复杂度高。AIFunction提供另一种路径：将模型调用纳入数据引擎，让用户用SQL表达"从Blob中解析文本"“对图片生成标签”"对文本生成Embedding"等操作。它与混合检索是互补关系——AIFunction把原始多模态对象转化为可索引、可分析的数据形态，混合检索则在这些数据形态之上完成高质量召回。
阿里云EMRServerlessStarRocks使用自研Stella引擎，在多模态检索与湖表查询场景下有多项开源版本不具备的优化：
NativeReader性能优化： 对Paimon湖表数据实现原生C++读取，绕过JNI调用开销；向量化批处理+列式裁剪，大幅减少反序列化成本。在向量索引扫描和全文检索回捞阶段，相比开源JNI方式查询性能提升显著。
查询优化器增强： 当Paimon湖表与StarRocks内表Join时，自动选择最优Join策略；支持跨Catalog的全局查询优化——例如一条SQL中同时涉及Paimon多模态湖表的向量检索和内表的标量聚合，优化器可以统一编排执行计划。
Search短路径进一步压缩： 商业版在FE层针对纯向量检索和混合检索场景做了更激进的短路径设计，跳过不必要的CBO阶段，将向量查询的FE延迟压缩到亚毫秒级。
阿里云EMRServerlessStarRocks对DLFPaimon进行了全面的原生适配，提供从Catalog注册、数据读取、分区裁剪到多模态索引访问的完整能力支持：
PaimonCatalog一键注册： 通过CREATEEXTERNALCATALOG注册DLFPaimon数据源，SQL直查，商业版提供预置Catalog模板一键配置。
Native读取Paimon数据： 对Paimon格式数据实现原生C++读取，绕过JNI开销。在两阶段检索框架中，回捞阶段直接以Native方式读取Paimon文件，性能领先开源版本。
分区裁剪： 按分区条件过滤Paimon表，避免全表扫描。对于按时间分区的多模态数据（如训练样本按日/按批次分区），可以显著减少无效I/O。
GlobalRowID索引直通： 商业版与Paimon2.0GlobalRowID深度打通，向量索引返回RowID后，系统直接通过PaimonManifest回捞对应列，无需中间数据搬迁。
引入多模态检索后，系统需要同时管理PageCache、元数据Cache、湖表文件Cache和向量索引Cache。阿里云EMRServerlessStarRocks商业版在这一层做了统一调度：
内外表统一缓存： Paimon湖表查询与StarRocks内表共享统一DataCache层，热数据自动缓存到本地SSD，重复查询直接命中缓存，避免内表与外表缓存空间冲突（开源版需手动配置）。
向量索引Cache智能管理： 高频访问的HNSW/DiskANN索引分片被自动缓存，减少湖上索引的远程读取开销，使向量检索延迟逼近内表水平。
缓存自适应淘汰： 根据不同Cache类型的访问频率和数据体积自动调整淘汰策略，在有限内存下获得全局最优的缓存命中率。
阿里云EMRServerlessStarRocks商业版在多模态检索场景下的核心差异化价值可以概括为四点：
全托管免运维： Serverless架构，一键开通即用，无需管理集群基础设施，空闲时零成本。
Stella引擎独有优化： NativeReader+DataCache统一管理+跨Catalog查询优化，湖表多模态检索性能对标内表。
端到端一站式方案： 从数据接入（实时计算Flink版）到湖仓存储（DLFPaimon）到分析检索（EMRServerlessStarRocks）到可视化（QuickBI），全链路阿里云一站式交付，RAM统一权限满足企业合规要求。
TCO总拥有成本更优： 数据统一沉淀在Paimon湖上（避免多系统数据副本）+Serverless弹性按需付费+DataCache缓存加速，TCO显著低于"向量库+全文引擎+OLAP"三系统拼接的自建方案。
AIData平台端到端链路——从多模态入湖到Agent消费
阿里集团内部的AIData场景可以体现阿里云EMRServerlessStarRocks与DLFPaimon结合后的业务价值。该平台主要面向大模型训练数据准备和AI应用高质量数据供给，要求在低成本、一份数据、开放性和准实时之间取得平衡。
从数据链路看，原始文件、Blob、文本、Variant、结构化标签和向量数据进入Paimon多模态湖格式；AIFunction负责解析文本、Chunking、Embedding和结构化抽取；标量与全文通道使用谓词过滤、倒排索引和BM25；向量通道使用ANN索引进行语义召回；最终通过RRF、加权融合或Rerank完成多路结果融合。上层可以服务BI分析、混合检索SQL、AI应用和DataAgent。
交互式数据筛选： 用户输入一个或多个标签、全文条件以及语义描述，系统返回TopK样本供预览和校验；
数据集生成： 系统根据索引召回或半径条件抽取符合要求的数据集合，用于训练、评测或后续标注。
这一案例的业务价值在于：一套引擎和一套存储格式替代了多套割裂系统，降低了数据复制和同步成本；标量与向量双路召回结合融合重排，提高了数据集召回质量；阿里云EMRServerlessStarRocksAIFunction将向量化和结构化抽取纳入SQL体系，降低了多模态数据处理门槛。
总体来看，AI时代正在推动Lakehouse从结构化数据底座升级为多模态数据底座。
Paimon2.0的关键演进： 通过多模态存储格式和稳定RowID，将结构化数据、半结构化数据、对象数据、文本数据和向量数据统一到同一张湖表语义之下；
StarRocks的关键演进： 从纯OLAP引擎扩展为Search&OLAP混合引擎，使全文检索、向量检索、标量过滤、混合召回和AIFunction能够在统一执行框架中协同工作。
阿里云EMRServerlessStarRocks这一方向的核心目标不是简单增加一个向量索引，也不是将多个系统拼接在一起，而是在统一数据、一致语义和系统级优化之上，构建面向AIData、AIAgent和多模态应用的下一代湖仓架构。后续，StarRocks社区也会持续将这些经过生产验证的能力逐步贡献到开源版本，并通过云上产品形态服务更多企业的AI数据场景。
本文整理自FlinkForwardAsia2026·深圳主题演讲。
作者：范振（StarRocks 社区 TSC、阿里云开源 OLAP 负责人)