大禹平台：流批一体离线Dump平台的设计与应用

一、前言

在搜索、推荐、广告（业内常简称为“搜推广”）这类核心业务场景中，有一个关键环节至关重要：如何将来自四面八方的异构数据，高效、可靠地加工处理，最终交付给索引平台构建索引。这个环节，就是我们今天要讨论的“Dump”流程。而大禹平台，正是为此而生的一个离线Dump平台。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

那么，一个典型的Dump流程通常面临哪些挑战呢？简单梳理一下，主要有这么几点：

首先，数据来源五花八门，MySQL、ODPS、HBase、Kafka……堪称多源异构。其次，输出目标也多样化，既要支持构建倒排索引，也要能生成供Summary服务使用的kv/kkv索引。再者，业务对时效性要求苛刻，往往需要全量与增量结合，并且增量更新最好能达到秒级，同时还得保证流处理和批处理的逻辑完全一致。最后，为了满足复杂的业务需求，平台本身还得具备强大的数据处理能力，比如多表关联、自定义函数（UDF）、数据过滤等等。

离线 Dump 流程

二、项目背景

现状

当前 dump 开发模式

上图展示的是过去常见的Dump开发模式，采用了典型的流批分离架构。简单来说，流处理这边，通过DTS订阅数据库的binlog，由Flink消费主表变更事件，再实时反查关联表来拼装宽表；批处理那边，则是把MySQL数据先抽到ODPS，再用Spark处理多源数据，按业务逻辑加工后输出。这种架构听起来清晰，但实际跑起来，问题可不少。

当前 dump 开发的问题

具体有哪些痛点呢？开发效率低是个老问题，流批两套代码，逻辑一致性的维护成本高昂。数据质量也令人头疼，流批数据源和计算逻辑不一致，很容易导致最终结果对不上。更棘手的是稳定性，频繁对源数据库进行反查，给上游带来了不小的压力，一旦源库抖动，整个链路都可能受影响。

目标

因此，我们以社区搜索这个核心场景为切入点，决心构建一套全新的流批一体化Dump架构。这套新架构瞄准三大核心目标：

第一，提升工程效率。目标是打造一个可视化的DAG编排工具，通过低代码甚至拖拽式的开发界面，让复杂任务流程的搭建和迭代变得像搭积木一样简单，显著降低开发门槛。

第二，保障数据质量。依托流批一体的设计，从源头实现计算逻辑的统一，让流处理和批处理“同源同构”，从根本上杜绝数据不一致的隐患。

第三，强化稳定性保障。通过引入镜像表和状态大宽表等机制，减少甚至消除对源数据库的实时反查压力，让整个系统运行得更稳健、更高效。

三、大禹平台介绍

平台设计

系统架构

平台架构

上面这张图清晰地勾勒出了大禹平台的技术架构全貌。它的底层，充分复用公司已有的基础设施，比如DJob Cron定时任务调度、Flink/Spark流批计算引擎，以及各类存储系统。在此之上，平台面向搜推广等多种业务场景提供支撑。

整个平台可以分成两大部分：面向用户的管理平台，和负责实际执行的后台系统。管理平台就像“指挥中心”，开发者在这里通过DAG图进行流程编排、配置业务逻辑，还能进行Debug、回归测试和查看监控大盘。而后台系统则是“执行引擎”，它把前端的配置转化为具体的计算任务，依托Flink/Spark生成执行实例，并通过调度引擎驱动整个流程跑起来。

那么，新版Dump流程具体做了哪些优化呢？关键就在于将流程拆解为三个清晰的阶段：镜像、宽表、导出，并统一了流批两种处理模式。如下图所示：

新版 Dump 流程

优化点主要体现在三个方面：一是将MySQL数据统一同步到HBase构建镜像层，实现与上游数据库的解耦，避免了多任务并发反查的压力；二是将Binlog订阅流程平台化、自动化，开发者无需再关心底层链路；三是基于HBase构建了持久化的“状态大宽表”，任务处理时直接读取状态数据，彻底告别了冗余的反查逻辑。

调度引擎

在调度层面，大禹平台基于得物内部的DJob Cron自建了一套调度系统。其核心思路是通过部署多个Cron Job进行轮询，来有序地驱动任务各个阶段的执行。

Cron Job 构建调度系统

一个执行实例的全流程

执行框架

在镜像、宽表、导出这三个核心阶段，平台都提供了对应的Spark和Flink处理框架。其中，宽表阶段是业务逻辑实现的核心。

宽表Spark框架的逻辑很直观：任务严格按照DAG图的拓扑顺序，像流水线一样依次执行各个算子节点，从数据源读取，经过业务逻辑处理，最终通过BulkLoad方式高效写入HBase。

宽表阶段 Spark 框架逻辑

而宽表Flink框架，则专注于处理增量数据。它消费非维表节点的增量消息，同样按照依赖关系拓扑排序后依次执行计算，并将产出的字段更新到状态大宽表中，同时实时同步给下游的导出链路。

宽表阶段 Flink 框架逻辑

流批一体保障数据质量

如何确保流处理和批处理的结果一致？大禹平台的答案是：从架构上统一。平台采用统一的DAG编排引擎，让流和批任务共享相同的计算拓扑，这就从源头上杜绝了因开发环境不同导致的数据偏差。

更值得一提的是UDF（用户自定义函数）的处理方式。平台内置了标准化的UDF开发模板和运行时框架。这意味着，开发者只需要编写一次业务逻辑代码，完成注册后，这份代码就能同时应用于流式和批量处理流程中。真正做到了“一次开发，两端复用”，极大提升了开发效率，也从根本上保障了数据处理逻辑的一致性。

平台通过定义 AlgoDumpUDF 这个基类，封装了消息类型，用户可以在自己的UDF中方便地实现数据过滤和驱动删除等逻辑。

public abstract class AlgoDumpUDF implements UDFFunction, Serializable {
    //消息类型 add/delete/drop 三种
    public AlgoDumpMessageType algoDumpMessageType = AlgoDumpMessageType.MESSAGE_TYPE_ADD;
    @Override
    public AlgoDumpMessageType getStatus() {
        return algoDumpMessageType;
    }
    //调用该方法实现增量驱动删除
    @Override
    public void delete(Object key, String reason) {
        this.algoDumpMessageType = AlgoDumpMessageType.MESSAGE_TYPE_DELETE;
    }
    //调用该方法实现增量过滤
    @Override
    public void drop(Object key, String reason) {
        this.algoDumpMessageType = AlgoDumpMessageType.MESSAGE_TYPE_DROP;
    }
    /**
     * 用户重写该方法完成业务逻辑开发
     */
    public void process() throws Exception {
    }
}

来看一个具体例子：用户通过重写 process() 方法实现业务逻辑，期间可以调用 drop() 方法过滤无效数据，或调用 delete() 方法通知下游索引删除某条记录。

public class MyUdf extends AlgoDumpUDF implements Serializable {
    public Tuple2 process(String id, String taskname) throws Exception {
        //过滤消息
        if(StringUtils.isBlank(id)) {
            this.drop(id, "drop by id null");
        }
        //驱动增量删除消息
        if(id.equals("0")) {
            this.delete(id, "delete by id = 0");
        }
        //用户写具体业务逻辑
        String a1 = "";
        if (taskname.equals("dddddd")) {
            a1 = "ddd";
        }
        String b1 = "test";
        return new Tuple2<>(a1, b1);
    }
}

小全量模式加速数据Dump

为了应对不同的数据更新需求，大禹平台支持“大全量”和“小全量”两种任务运行模式。

“大全量”模式好理解，就是推倒重来：对数据源执行全量同步，重建整个状态大宽表，并刷新所有相关链路。这适用于需要彻底更新数据基准的场景。

而“小全量”模式则是针对性的优化。当只有部分字段频繁更新时，它基于已有的状态大宽表，仅加载批处理来源字段的最新数据快照，处理后通过BulkLoad高效写入HBase。借助HBase的多版本特性，可以实现新旧数据的平滑切换，在数据更新过程中做到查询服务零中断，完美兼顾了数据时效性和业务连续性。

小全量模式

任务复用支持数据分层管理

在大禹平台里，任务产出的数据不再是“一次性”的。它既可以交付给计算引擎使用，也可以作为公共数据资产，被其他下游任务直接复用。

这是怎么实现的呢？平台通过标准化的 MirrorOut（镜像导出）和 MirrorIn（镜像接入）算子，构建了一条清晰的数据复用链路。上游任务将加工好的公共数据配置为 MirrorOut，下游任务只需通过 MirrorIn 算子就能一键引用，无需重复开发或搬运数据。这种机制极大地提升了开发效率和数据的复用价值。

任务复用

管理平台

任务开发与运维

管理平台为开发者提供了一站式的任务开发与运维体验，覆盖了从创建、编排、调度到资源管理的全生命周期。

其中最直观的功能莫过于可视化流程编排。开发Dump任务时，用户只需像搭积木一样，拖拽不同的算子节点，配置相应参数，就能直观地构建出完整的数据处理逻辑图。这种方式不仅降低了开发门槛，也大大提升了配置的准确性。

图片

图画编排式开发任务

任务执行起来后，平台会以可视化的流程图实时展示每个节点的状态。每个节点都能看到详细的输入参数和输出结果，如果某个环节出了问题，还支持对该节点进行手动重试或终止操作，便于快速定位和干预。

执行实例状态

辅助工具

数据回归验证

数据质量是生命线。平台提供了强大的流批数据回归验证能力，支持模板化配置和一键复用，为数据准确性和业务稳定性保驾护航。

“批量回归”主要用于版本迭代后的验证，可以快速比对多个版本的批处理数据，一键校验全量结果的一致性。“流式回归”则针对实时链路，它基于索引表的增量变更进行抽样，对指定时间窗口内的流式数据进行跨索引一致性校验，能够精准定位流处理过程中的异常。

创建批数据回归任务

创建流数据回归任务

数据Debug

为了确保数据处理过程的可靠与灵活，大禹平台构建了覆盖全链路的数据运维干预能力。

这包括：对源端的组图配置进行主动干预和调整；对Dump构建全流程进行调控，以便快速定位问题；甚至提供对线上索引数据的实时干预能力，支持对增量数据进行修正，确保线上内容的准确性。

图片

四、业务场景实践

社区搜索倒排表链路

理论需要实践检验。在社区搜索场景中，大禹平台负责构建倒排表链路。如下图所示，该任务以动态内容为核心，融合了实时内容流、天级统计特征、商品特征等多源数据，通过流批一体处理，最终生成高时效的倒排索引宽表。

社区搜索倒排宽表链路

穿搭精选推荐链路

另一个典型场景是穿搭精选推荐。如下图所示，该任务以“动态-商品”关系表为主表，融合了动态维度下多种来源的流批特征数据（如内容基础特征、审核信息、离线统计特征等），通过DAG编排，最终构建出服务于推荐系统的动态-商品大宽表。

穿搭精选推荐链路

图片

五、未来规划

平台的进化永无止境。接下来的规划，主要围绕两个方向展开：一是持续增强平台自身能力，二是深化协同共建，释放更大价值。

在平台能力建设上，首先会持续完善算子体系，基于更多业务场景沉淀和优化关键算子，比如维表动态更新、服务化算子、UDTF部署优化等，同时优化调度流程。其次，进行性能深度优化，引入任务剪枝、智能倾斜治理等策略，提升资源利用率和执行效率。最后，升级可观测性，构建从全局大盘到单一任务的立体监控体系，完善资源消耗追踪、Debug和全链路追踪能力。

在协同共建方面，则分为“纵向提效”和“横向赋能”。纵向，将与索引平台深度协同，聚焦索引构建效率。以社区搜索大宽表为例，当前同步到索引需要近3小时，未来计划通过消除冗余中间状态、精简流程等手段，实现端到端的显著提速。横向，平台能力已在社区多个业务场景得到验证，后续将联动更多业务方共建。同时，平台中像数据回归验证、索引监控大盘这类高复用能力模块，将以“即插即用”的方式开放给各业务线，加速技术资产的沉淀和跨团队创新。

图片