数据闭环数据挖掘平台架构设计：控制面、数据面分离的工程实践

工程实践谁来从海量数据里发现高价值场景?这就是数据挖掘平台的位置：它居于闭环的枢纽，输出有两条路——命中存量数据直接回补训练集(零采集成本),未命中则下发定向采集需求，开启新一轮循环。数据挖掘与AI:从平台架构到抽帧、标签、规则挖掘、VLM推理、向量化流水线与多模态检索。开篇这篇讲最难也最重要的问题：一个要消费湖仓数据的平台，自身应该怎么设计，才不会破坏单一事实源?一、平台定位：挖掘域的枢纽与双出口数据挖掘与多模态检索平台是智驾数据闭环挖掘域的核心工具平台，承担「从海量数据中发现高价值场景」的职责。它用四项核心能力完成这件事：·规则挖掘引擎基于结构化元数据与已有标签，批量产出高价值场景标签一—「雨天+夜间+无灯路口」这类组合条件，用SQL就能圈出来；·VLM推理挖掘引擎多模态大模型做语义级标签与关键说明(caption)生成——规则覆盖不了的长尾场景，让大模型看图说话来补；·统一标签体系采集标签、规则标签、大模型标签三来源统一字典、统一管理、可追溯；·多模态语义检索T+1向量化流水线构建图片与文本向量，支撑「以文搜图、以图搜图」。这四项能力服务的正是上篇全景综述里讲过的「挖掘双出口」:库内命中场景直接回补训练集，零采集成本；未命中才下发定向采集需求。回灌」与此同构——挖掘平台的效率，直接决定每一圈闭环的成本与转二、第一设计原则：平台不持有主数据很多团队做挖掘平台时踩的最大的坑是：平台顺手建了一套自己的「数据副本」——抽帧结果存一份、标签存一份、向量再存一份，时间一长，平台里的数据与湖仓对不上，口径分裂、血缘断裂。我们的第一设计原则恰好相反：平台不持有主数据。clip、图片文件、标签、向量全部沉淀于湖仓(Paimon),平台只是湖仓数据的「加工者+消费者」——向下读取采集元数据与回传数据，向上产出标签、向量与检索结果，全部统一回写湖仓。围绕这条原则，有五条对齐约定：对齐原则湖仓单一事实源抽帧元信息、标签、向量统一落Paimon,与运行态贯穿采集最小单元为clip,统一用全局dataid;imageid内嵌data_id,天然可回溯数仓命名规范新增表遵循{层级}{挖掘域}{实体}detail,共11张表(1OD双路查询检索明细与向量走ExternalCatalog查Paimon;看板经ADS物质量门禁与血缘标签入湖复用既有质量门禁(唯一性/有效性),抽帧产物登记血缘，全链路可追溯一个容易被忽略的细节是clip元数据不新建表：平台直接复用采集域既有的dwd_collect_clip_detail,而不是复制一份自己的。避免了与湖仓既有建模冲突，也让data_id全局贯穿不断链。平台自身按五层组织，每一层职责单一、伸缩独立：设计要点统一入口，认证/限流/审计，OpenAPI为唯一对外通道应用服务统一检索/任务管理/统一标签/圈选导出/审核流，五个无状态微服务核心引擎Flink流)/VLM推理(Ray+GPU)/Embedding流水线度独立扩容，互不阻塞平台支撑MySQL/Redis/Kafka/OSS/模型注册表数据一律不进外部DLF+Paimon湖仓/StarRocksinScheduler/GPU资源池无状态可随时重建这套分层的关键是「引擎与服务解耦、引擎之间也解耦」:抽帧结果写入dwd_mining_image_frame_detail之后，规则挖掘与VLM推理各自基于该表独立运行——批处理引擎白天跑批，推理引擎按优先级抢GPU,谁也不等谁。任何一个引擎故障或扩容，都不影响其他链路。四、控制面/数据面分离：平台运行态怎么管「平台不持有主数据」落到工程上，就是控制面与数据面的彻底分·控制面(平台本地)MySQL存规则配置、任务配置与执行状态、审核流状态；Redis存检索热点与字典热缓存——全部是「平台自身运行态」,体量小、可随时重建；做查询与向量索引加速，同样不持有主数据； dwd_mining_task_detail——平台的每一步操作都进血缘，与湖仓闭环。这样做的收益很直接：平台可以整体重建与迁移，主数据不受影响——MySQL丢了，重建配置即可；服务挂了，无状态重启即可。同时湖仓是唯一对账基准，不存在双写导致的口径分裂。判断一个平台设计是否健康的简单标准：把平台的数据库清空重建，业务数据是否完好?如果是，控制面/数据面才算真正分离。部署区组件务区控制台、网关、检索/任务/标签/审核服务每服务4C8G×2起，无状态+HPA随检索QPS扩缩计算引擎区Spark/Flink执行器池、抽帧作业放GPU资源池分时复用+优先级队列+弹性扩缩GPU是最贵的资源，利用率设计是重头戏：VLM推理与Embedding共享同一个GPU池——推理任务白天按优先级队列执行，Embedding点前完成),用时间错峰避免资源争抢；峰值期低优任务可被抢占。此外向量化本身也分成本等级：高价值数据(规则命中/事件抽帧/VLM标签)优先向量化，普通数据抽样处理——GPU成本花在刀刃上。技术选型上几个关键取舍：批处理选SparkonK8s(放弃Hive,迭代开发与UDF扩展性不足);流处理选Flink(SparkStreaming事件准实时语义弱);GPU推理调度选Ray+vLLM(Triton适合单模型服务化，但缺任务编排与断点续跑);向量检索选StarRocks外部表HNSW——业界主流是Milvus等独立向量库，我们放弃独立向量库换取湖仓单一事实源与免数据冗余，属差异化权衡，并保留内表降级路径。六、OpenAPI出口：能力如何被上下游调用平台能力经OpenAPI网关统一对外，接口分四组，每组都对应一个明确的业务动作：组检索类POST/api/v1/scene/semantic-s文搜图/图搜图/混合检索+标量过滤任务类等键防重复提交标签治理类标签字典CRUD;候选审核approve/reject;标签merge一律经统一标签服务收口数据集类POST/api/v1/scene/curate;GET/d圈选结果回写数据资产域，clip级防泄漏系统集成上，平台对上对接采集系统(clip入湖走既有链路，平台backfill_dataset_id回补)、仿真平台(场景资产导出)与文档门户(统一登录，权限复用湖仓四级管控)——平台从不自建数据通道，永远走在湖仓既有的链路上。要点回顾：①平台不持有主数据，湖仓是唯一事实源；②五层架构各司其职，引擎间解耦独立伸缩；③控制面存运行态、数据面在湖仓，审计留痕回流闭环；④K8s三