设计模式——管道模式（一）

已于 2023-06-02 18:45:03 修改
阅读量4.6k 收藏 27
点赞数 6
分类专栏： 设计模式 文章标签： 设计模式 java 开发语言
于 2021-08-24 17:44:52 首次发布
原文链接：https://www.jianshu.com/p/a4b719145b46
版权

管道模式(Pipeline Pattern) 是 责任链模式(Chain of Responsibility Pattern)的常用变体之一。在管道模式中，管道扮演着流水线的角色，将数据传递到一个加工处理序列中，数据在每个步骤中被加工处理后，传递到下一个步骤进行加工处理，直到全部步骤处理完毕。

PS：纯的责任链模式在链上只会有一个处理器用于处理数据，而管道模式上多个处理器都会处理数据。

何时使用管道模式

任务代码较为复杂，需要拆分为多个子步骤时，尤其是后续可能在任意位置添加新的子步骤、删除旧的子步骤、交换子步骤顺序，可以考虑使用管道模式。

▐ 背景回放

最开始做模型平台的时候，创建模型实例的功能，包括： “输入数据校验 -> 根据输入创建模型实例 -> 保存模型实 例到相关 DB 表” 总共三个步骤，也不算复杂，所以当时的代码大概是这样的：

public class ModelServiceImpl implements ModelService {

    /**
     * 提交模型（构建模型实例）
     */
    public CommonReponse<Long> buildModelInstance(InstanceBuildRequest request) {
        // 输入数据校验
        validateInput(request);
        // 根据输入创建模型实例
        ModelInstance instance = createModelInstance(request);
        // 保存实例到相关 DB 表
        saveInstance(instance);
    }
}

然而没有过多久，我们发现表单输入数据的格式并不完全符合模型的输入要求，于是我们要加入 “表单数据的预处理”。这功能还没动手呢，又有业务方提出自己也存在需要对数据进行处理的情况（比如根据商家的表单输入，生成一些其他业务数据作为模型输入）。

所以在 “输入数据校验” 之后，还需要加入 “表单输入输出预处理” 和 “业务方自定义数据处理（可选）”。这个时候我就面临一个选择：是否继续通过在 buildModelInstance 中加入新的方法来实现这些新的处理步骤？好处就是可以当下偷懒，但是坏处呢：

  1. ModelService 应该只用来接收 HSF 请求，而不应该承载业务逻辑，如果将 提交模型 的逻辑都写在这个类当中，违反了 单一职责，而且后面会导致 类代码爆炸
  2. 将来每加入一个新的处理步骤或者删除某个步骤，我就要修改 buildModelInstance 这个本应该非常内聚的方法，违反了 开闭原则

所以，为了不给以后的自己挖坑，我觉得要思考一个万全的方案。这个时候，我小脑袋花开始飞转，突然闪过了 Netty 中的 ChannelPipeline —— 对哦， 管道模式 ，不就正是我需要的嘛！

管道模式的实现方式也是多种多样，接下来基于前面的背景，我分享一下我目前基于 Spring 实现管道模式的 “最佳套路”（如果你有更好的套路，欢迎赐教，一起讨论哦）。

▐ 定义管道处理的上下文

/**
 * 传递到管道的上下文
 */
@Getter
@Setter
public class PipelineContext {

    /**
     * 处理开始时间
     */
    private LocalDateTime startTime;

    /**
     * 处理结束时间
     */
    private LocalDateTime endTime;

    /**
     * 获取数据名称
     */
    public String getName() {
        return this.getClass().getSimpleName();
    }
}

▐ 定义上下文处理器

/**
 * 管道中的上下文处理器
 */
public interface ContextHandler<T extends PipelineContext> {

    /**
     * 处理输入的上下文数据
     *
     * @param context 处理时的上下文数据
     * @return 返回 true 则表示由下一个 ContextHandler 继续处理，返回 false 则表示处理结束
     */
    boolean handle(T context);
}

为了方便说明，我们现在先定义出最早版 【 提交模型逻辑】 的上下文和相关处理器：

/**
 * 模型实例构建的上下文
 */
@Getter
@Setter
public class InstanceBuildContext extends PipelineContext {

    /**
     * 模型 id
     */
    private Long modelId;

    /**
     * 用户 id
     */
    private long userId;

    /**
     * 表单输入
     */
    private Map<String, Object> formInput;

    /**
     * 保存模型实例完成后，记录下 id
     */
    private Long instanceId;

    /**
     * 模型创建出错时的错误信息
     */
    private String errorMsg;

    // 其他参数

    @Override
    public String getName() {
        return "模型实例构建上下文";
    }
}

处理器 - 输入数据校验：

@Component
public class InputDataPreChecker implements ContextHandler<InstanceBuildContext> {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public boolean handle(InstanceBuildContext context) {
        logger.info("--输入数据校验--");

        Map<String, Object> formInput = context.getFormInput();

        if (MapUtils.isEmpty(formInput)) {
            context.setErrorMsg("表单输入数据不能为空");
            return false;
        }

        String instanceName = (String) formInput.get("instanceName");

        if (StringUtils.isBlank(instanceName)) {
            context.setErrorMsg("表单输入数据必须包含实例名称");
            return false;
        }

        return true;
    }
}

处理器 - 根据输入创建模型实例：

@Component
public class ModelInstanceCreator implements ContextHandler<InstanceBuildContext> {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public boolean handle(InstanceBuildContext context) {
        logger.info("--根据输入数据创建模型实例--");

        // 假装创建模型实例

        return true;
    }
}

处理器 - 保存模型实例到相关DB表：

@Component
public class ModelInstanceSaver implements ContextHandler<InstanceBuildContext> {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public boolean handle(InstanceBuildContext context) {
        logger.info("--保存模型实例到相关DB表--");

        // 假装保存模型实例

        return true;
    }
}

到这里，有个问题就出现了：应该使用什么样的方式，将同一种 Context 的 ContextHandler 串联为管道呢？思考一下：

  1. 给 ContextHandler 加一个 setNext 方法，每个实现类必须指定其下一个处理器。缺点也很明显，如果在当前管道中间加入一个新的 ContextHandler，那么要势必要修改前一个 ContextHandler 的 setNext 方法；另外，代码是写给人阅读的，这样做没法一眼就直观的知道整个管道的处理链路，还要进入到每个相关的 ContextHandler 中去查看才知道。
  2. 给 ContextHandler 加上 @Order 注解，根据 @Order 中给定的数字来确定每个 ContextHandler 的序列，一开始时每个数字间隔的可以大些（比如 10、20、30），后续加入新的 ContextHandler 时，可以指定数字为 （11、21、31）这种，那么可以避免上面方案中要修改代码的问题，但是仍然无法避免要进入每个相关的 ContextHandler 中去查看才能知道管道处理链路的问题。
  3. 提前写好一份路由表，指定好 ”Context -> 管道“ 的映射（管道用 List<ContextHandler> 来表示），以及管道中处理器的顺序 。Spring 来根据这份路由表，在启动时就构建好一个 Map，Map 的键为 Context 的类型，值为 管道（即 List<ContextHandler>）。这样的话，如果想知道每个管道的处理链路，直接看这份路由表就行，一目了然。缺点嘛，就是每次加入新的 ContextHandler 时，这份路由表也需要在对应管道上进行小改动 —— 但是如果能让阅读代码更清晰，我觉得这样的修改是值得的、可接受的~

▐ 构建管道路由表

/**
 * 管道路由的配置
 */
@Configuration
public class PipelineRouteConfig implements ApplicationContextAware {

    /**
     * 数据类型->管道中处理器类型列表 的路由
     */
    private static final
    Map<Class<? extends PipelineContext>,
        List<Class<? extends ContextHandler<? extends PipelineContext>>>> PIPELINE_ROUTE_MAP = new HashMap<>(4);

    /*
     * 在这里配置各种上下文类型对应的处理管道：键为上下文类型，值为处理器类型的列表
     */
    static {
        PIPELINE_ROUTE_MAP.put(InstanceBuildContext.class,
                               Arrays.asList(
                                       InputDataPreChecker.class,
                                       ModelInstanceCreator.class,
                                       ModelInstanceSaver.class
                               ));

        // 将来其他 Context 的管道配置
    }

    /**
     * 在 Spring 启动时，根据路由表生成对应的管道映射关系，          
     * PipelineExecutor 从这里获取处理器列表
     */
    @Bean("pipelineRouteMap")
    public Map<Class<? extends PipelineContext>, List<? extends ContextHandler<? extends PipelineContext>>> getHandlerPipelineMap() {
        return PIPELINE_ROUTE_MAP.entrySet()
                                 .stream()
                                 .collect(Collectors.toMap(Map.Entry::getKey, this::toPipeline));
    }

    /**
     * 根据给定的管道中 ContextHandler 的类型的列表，构建管道
     */
    private List<? extends ContextHandler<? extends PipelineContext>> toPipeline(
            Map.Entry<Class<? extends PipelineContext>, List<Class<? extends ContextHandler<? extends PipelineContext>>>> entry) {
        return entry.getValue()
                    .stream()
                    .map(appContext::getBean)
                    .collect(Collectors.toList());
    }

    private ApplicationContext appContext;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        appContext = applicationContext;
    }
}

▐ 定义管道执行器

最后一步，定义管道执行器。管道执行器 根据传入的上下文数据的类型，找到其对应的管道，然后将上下文数据放入管道中去进行处理。

/**
 * 管道执行器
 */
@Component
public class PipelineExecutor {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    /**
     * 引用 PipelineRouteConfig 中的 pipelineRouteMap
     */
    @Resource
    private Map<Class<? extends PipelineContext>,
                List<? extends ContextHandler<? super PipelineContext>>> pipelineRouteMap;

    /**
     * 同步处理输入的上下文数据<br/>
     * 如果处理时上下文数据流通到最后一个处理器且最后一个处理器返回 true，则返回 true，否则返回 false
     *
     * @param context 输入的上下文数据
     * @return 处理过程中管道是否畅通，畅通返回 true，不畅通返回 false
     */
    public boolean acceptSync(PipelineContext context) {
        Objects.requireNonNull(context, "上下文数据不能为 null");
        // 拿到数据类型
        Class<? extends PipelineContext> dataType = context.getClass();
        // 获取数据处理管道
        List<? extends ContextHandler<? super PipelineContext>> pipeline = pipelineRouteMap.get(dataType);

        if (CollectionUtils.isEmpty(pipeline)) {
            logger.error("{} 的管道为空", dataType.getSimpleName());
            return false;
        }

        // 管道是否畅通
        boolean lastSuccess = true;

        for (ContextHandler<? super PipelineContext> handler : pipeline) {
            try {
                // 当前处理器处理数据，并返回是否继续向下处理
                lastSuccess = handler.handle(context);
            } catch (Throwable ex) {
                lastSuccess = false;
                logger.error("[{}] 处理异常，handler={}", context.getName(), handler.getClass().getSimpleName(), ex);
            }

            // 不再向下处理
            if (!lastSuccess) { break; }
        }

        return lastSuccess;
    }
}

▐ 使用管道模式

此时，我们可以将最开始的 buildModelInstance 修改为：

public CommonResponse<Long> buildModelInstance(InstanceBuildRequest request) {
    InstanceBuildContext data = createPipelineData(request);
    boolean success = pipelineExecutor.acceptSync(data);

    // 创建模型实例成功
    if (success) {
        return CommonResponse.success(data.getInstanceId());
    }

    logger.error("创建模式实例失败：{}", data.getErrorMsg());
    return CommonResponse.failed(data.getErrorMsg());
}

我们模拟一下模型实例的创建过程：

参数正常时：

参数出错时：

这个时候我们再为 InstanceBuildContext 加入新的两个 ContextHandler：FormInputPreprocessor（表单输入数据预处理） 和 BizSideCustomProcessor（业务方自定义数据处理）。

@Component
public class FormInputPreprocessor implements ContextHandler<InstanceBuildContext> {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public boolean handle(InstanceBuildContext context) {
        logger.info("--表单输入数据预处理--");

        // 假装进行表单输入数据预处理

        return true;
    }
}

@Component
public class BizSideCustomProcessor implements ContextHandler<InstanceBuildContext> {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public boolean handle(InstanceBuildContext context) {
        logger.info("--业务方自定义数据处理--");

        // 先判断是否存在自定义数据处理，如果没有，直接返回 true

        // 调用业务方的自定义的表单数据处理

        return true;
    }
}

此时 buildModelInstance 不需要做任何修改，我们只需要在 “路由表” 里面，将这两个 ContextHandler 加入到 InstanceBuildContext 关联的管道中， Spring 启动的时候，会自动帮我们构建好每种 Context 对应的管道：

再模拟一下模型实例的创建过程：

▐ 异步处理

管道执行器 PipelineExecutor 中，acceptSync 是个同步的方法。

 对于步骤繁多的任务，很多时候我们更需要的是异步处理，比如某些耗时长的定时任务。管道处理异步化非常的简单，我们先定义一个线程池，比如：

<!-- 专门用于执行管道任务的线程池 -->
<bean id="pipelineThreadPool"
      class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
    <property name="corePoolSize" value="4" /> <!-- 核心线程数 -->
    <property name="maxPoolSize" value="8" />  <!-- 最大线程数 -->
    <property name="keepAliveSeconds" value="960" />  <!-- 线程最大空闲时间/秒（根据管道使用情况指定）-->
    <property name="queueCapacity" value="256" />     <!-- 任务队列大小（根据管道使用情况指定）-->
    <property name="threadNamePrefix" value="pipelineThreadPool" />
    <property name="rejectedExecutionHandler">
        <bean class="java.util.concurrent.ThreadPoolExecutor.CallerRunsPolicy" />
    </property>
</bean>

然后在 PipelineExecutor 中加入异步处理的方法：

/**
 * 管道线程池
 */
@Resource
private ThreadPoolTaskExecutor pipelineThreadPool;

/**
 * 异步处理输入的上下文数据
 *
 * @param context  上下文数据
 * @param callback 处理完成的回调
 */
public void acceptAsync(PipelineContext context, BiConsumer<PipelineContext, Boolean> callback) {
    pipelineThreadPool.execute(() -> {
        boolean success = acceptSync(context);

        if (callback != null) {
            callback.accept(context, success);
        }
    });
}

▐ 通用处理

比如我们想记录下每次管道处理的时间，以及在处理前和处理后都打印相关的日志。那么我们可以提供两个通用的 ContextHandler，分别放在每个管道的头和尾：

@Component
public class CommonHeadHandler implements ContextHandler<PipelineContext> {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public boolean handle(PipelineContext context) {
        logger.info("管道开始执行：context={}", JSON.toJSONString(context));

        // 设置开始时间
        context.setStartTime(LocalDateTime.now());

        return true;
    }
}

@Component
public class CommonTailHandler implements ContextHandler<PipelineContext> {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public boolean handle(PipelineContext context) {
        // 设置处理结束时间
        context.setEndTime(LocalDateTime.now());

        logger.info("管道执行完毕：context={}", JSON.toJSONString(context));

        return true;
    }
}

通用头、尾处理器可以在路由表里面放置，但是每次新加一种 PipelineContext 都要加一次，好像没有必要 —— 我们直接修改下 管道执行器 PipelineExecutor 中的 acceptSync 方法：

@Component
public class PipelineExecutor {

    ......

    @Autowired
    private CommonHeadHandler commonHeadHandler;

    @Autowired
    private CommonTailHandler commonTailHandler;

    public boolean acceptSync(PipelineContext context) {
        ......

        // 【通用头处理器】处理
        commonHeadHandler.handle(context);

        // 管道是否畅通
        boolean lastSuccess = true;

        for (ContextHandler<? super PipelineContext> handler : pipeline) {
            try {
                // 当前处理器处理数据，并返回是否继续向下处理
                lastSuccess = handler.handle(context);
            } catch (Throwable ex) {
                lastSuccess = false;
                logger.error("[{}] 处理异常，handler={}", context.getName(), handler.getClass().getSimpleName(), ex);
            }

            // 不再向下处理
            if (!lastSuccess) { break; }
        }

        // 【通用尾处理器】处理
        commonTailHandler.handle(context);

        return lastSuccess;
    }
}

总结

通过管道模式，我们大幅降低了系统的耦合度和提升了内聚程度与扩展性：

  • ModelService 只负责处理 HSF 请求，不用关心具体的业务逻辑
  • PipelineExecutor 只做执行工作，不用关心具体的管道细节
  • 每个 ContextHandler 只负责自己那部分的业务逻辑，不需要知道管道的结构，与其他ContextHandler 的业务逻辑解耦
  • 新增、删除 或者 交换子步骤时，都只需要操作路由表的配置，而不要修改原来的调用代码



作者：马小诺QAQ
链接：https://www.jianshu.com/p/a4b719145b46
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

相关文章：

管道模式​​​​​​​

码上得天下
关注
专栏目录
浅谈管道模型(Pipeline)
tansitongba
05-12 4607
本篇和大家谈谈一种通用的设计与处理模型——Pipeline（管道）。 Pipeline简介 Pipeline模型最早被使用在Unix操作系统中。据称，如果说Unix是计算机文明中最伟大的发明，那么，Unix下的Pipe管道就是跟随Unix所带来的另一个伟大的发明【1】。我认为管道的出现，所要解决的问题，还是软件设计中老生常谈的设计目标——高内聚，低耦合。它以一种“链式模型”来串接不同的程序或者不同...
设计模式——管道模式
jishulaozhuanjia的博客
03-19 2792
个人博客导航页（点击右侧链接即可打开个人博客）：大牛带你入门技术栈 概念 我们把特定的业务，比如订单业务中的临时订单、订单提交以及订单支付等，抽象成一组Pipeline（管道）； 拿生成临时订单业务来说，执行流程包括：1参数校验->2业务数据校验->3业务处理，这里的三段子流程是严格按照顺序执行的，我们用Valve（阀门）定义它们，每一个子流程即一个Valve； 在管道模...
设计模式之管道和过滤器的应用
bingozq的专栏
04-01 9104
 软件设计的一个核心问题是能否使用重复的体系架构，即能否达到体系架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一体系架构。基于这个目的，许多学者们开始研究和实践软件体系架构的模式问题。在中首次提出了8种体系结构模式： 层（L a y e r s）、管道和过滤器(Pipes and Filters) 、黑板( B l a c k b o a r d )、代理者（ B r o
【Java设计模式】集合管道模式：简化数据操作
道长的博客
08-29 1098
在Java中，集合管道设计模式通过将操作序列链接起来处理数据集合。利用Java Stream API，它以声明式的方式转换数据，关注应该做什么而不是如何做。
设计模式——管道模式（并发模式）
meser88的博客
08-25 1970
1、pipeline简介 pipeline又称为管道，是一种在计算机普遍使用的技术。举个最普遍的例子，如下图所示cpu流水线，一个流水线分为4部分，每个部分可以独立工作，于是可以处理多个数据流。linux 管道也是一个常用的管道技术，其字符处理功能十分强大，在面试过程中常会被问到。在分布式处理领域，由于管道模式是数据驱动，而目前流行的Spark分布式处理平台也是数据驱动的，两者非常合拍，于是在spark的新的api里面pipeline模式得到了广泛的应用。还有java web中的struct的filter
设计模式之管道模式
05-09 1577
管道模式（Pipeline Pattern） 是责任链模式的常用变体之一
管道设计模式、责任链模式、单例模式
10-15
压缩包里是我自己写的管道模式、单例模式的代码；你需要copy到你自己eclipse建的工程文件中。另外，我把我的代码说明，写在了readme.txt文件里，偷懒以及求快的人看看...如果有问题，可留言。另外我分数高，但绝对有保证！
pipeline模式
hjy82919的专栏
08-05 3616
         Pipeline模式在分布式框架中经常可以看到，应用该模式可以使框架具有良好的灵活性。当我们需要构建一个系统用于处理并转换一串输入数据时，如果通过一个大的组件按部就班的来实现此功能，那么一旦需求发生变化，比如其中的两个处理步骤需要调换次序，或者需要加入或减去某些处理，系统将很难适应，甚至需要重写。而Pipeline模式则将一个个的处理模块相互分离，各自独立，然后按照需要将它们串联
java 管道设计_设计模式——管道模式
weixin_30802125的博客
02-13 2372
管道(执行流)模型由Pipeline(管道)/ Valve(阀门)/ Context(上下文) 组成概念我们把特定的业务，比如订单业务中的临时订单、订单提交以及订单支付等，抽象成一组Pipeline(管道)；拿生成临时订单业务来说，执行流程包括：1参数校验->2业务数据校验->3业务处理，这里的三段子流程是严格按照顺序执行的，我们用Valve(阀门)定义它们，每一个子流程即一个Valv...
基于图形化模型的跨平台机器学习管道设计源码——MediaPipe详解
最新发布
09-26
MediaPipe是一个基于图形化模型的跨平台机器学习管道设计框架，源码包含4474个文件，涵盖多种编程语言，如C++、Python、Java等，支持视频、音频和传感器等多模式应用开发。该框架采用模块化设计，便于构建和部署复杂...
多线程设计模式——Producer-Consumer生产者消费者模式
buyoufa的博客
07-08 3202
Producer-Consumer生产者消费者模式
多线程设计模式——Pipeline(流水线)模式
01-27
Pipeline(流水线)模式有时一些线程的步奏比较冗长，而且由于每个阶段的结果与下阶段的执行有关系，又不能分开。可以将任务的处理分解为若干个处理阶段，上一个阶段任务的结果交给下一个阶段来处理，这样每个线程的处理是并行的，可以充分利用资源提高计算效率。 模式所使用的类：Pipe对处理阶段的抽象，负责对输入进行处理，并将输出作为下一个阶段的输入:process（）用于接收前一个处理阶段的处理结果，作为该处理阶段的输入,init（）初始化当前处理阶段对外提供的服务,shutdown（）关闭当前处理阶段对外提供的服务,setNext
设计模式-责任链模式变体之管道模式
weixin_43598257的博客
02-23 2248
一.管道模式的定义   管道模式（Pipeline Pattern） 是责任链模式（Chain of Responsibility Pattern）的常用变体之一。在管道模式中，管道扮演着流水线的角色，将数据传递到一个加工处理序列中，数据在每个步骤中被加工处理后，传递到下一个步骤进行加工处理，直到全部步骤处理完毕（比如电子厂里原材料通过流水线工人一个一个加工最后组装成一个完整的电子产品）。   注：责任链模式只有一个处理器会处理数据，而管道模式是多个处理器会处理 二.什么情况下使用管道模式   任务代码较为
手撸设计模式之-管道模式
以梦为马，不负韶华
06-15 1111
手撸设计模式之管道模式
设计模式最优实践—管道模式
wusd1256的专栏
12-13 682
设计模式
设计模式7.1-管道模式
2lovecode blog
02-09 3605
管道模式：对于管道模式来说，有3个对象：管道，载荷，过滤器(阶段，阀门均可)。 我们的目的是在管道中对载荷进行一系列的处理。因为可以对过滤器进行动态的添加， 所以对载荷的处理可以变得更加灵活。但同时带来的问题是，在过滤器过多时， 我们很难把握整体的处理逻辑。而且在某一个过滤器对载荷处理后，因为载荷改变， 会造成下一个过滤器中的逻辑出错。 在我们的示例中：管道类是Pipeline，载荷是在实...
[设计模式] Pipeline 设计模式
ykun089的博客
10-29 1142
深析Pipeline设计模式 - 知乎目标通过提供初始输入并传递处理后的输出以供下一阶段使用，从而允许在一系列阶段中进行数据处理。 解释Pipeline模式为管道模式，也称为流水线模式。通过预先设定好的一系列的阶段来处理输入的数据，每个阶段的输…https://zhuanlan.zhihu.com/p/355034910 ...
Pipeline模型在QT中的实现
追赶时代的博客
03-17 279
Pipeline 实践
【AI设计模式】03-数据处理-流水线(Pipeline)模式
Kenji_Shinji的博客
08-23 2220
但在运行的过程中会占用比较多的系统资源，包括CPU、内存，以ImageNet的训练为例，内存占用可以达到30-50GB，因此，对于训练数据量较小、训练资源不足或者推理场景（零散样本）的场景，并不适合流水线模式，此时可以考虑使用Eager模式用串行的方式直接调用数据处理的算子完成数据处理。基于流水线模式执行的最大特点是需要定义map算子，如下面的数据流水线中，map算子负责调度Resize、Crop、HWC2CHW的启动和执行，对数据管道的数据进行映射变换。引至《计算机体系结构基础》 第三版第九章。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值