executor

1,首先要区分分布式概念,分布式指的是将一个任务切分成多块分到多台机器运行. 2,进程可以理解成该服务器分到的那一块任务(MapReduce每分到一个任务会重启一个进程,而spark的所有任务都只在一个进程中,每来一个任务启动一个线程.) 3,线程可以理解成在进程的基础之上又细分的更小的任务 4,在任务级别（特指Spark任务和MapReduce任务）上却采用了不同的并行机制：Hadoop MapReduce采用了多进程模型，而Spark采用了多线程模型 5,多进程模型便于细粒度控制每个任务占用的资源，但会消耗较多的启动时间，不适合运行低延迟类型的作业，这是MapReduce广为诟病的原因之一。而多线程模型则相反，该模型使得Spark很适合运行低延迟类型的作业。总之，Spark同节点上的任务以多线程的方式运行在一个JVM进程中，可带来以下好处： 1）任务启动速度快，与之相反的是MapReduce Task进程的慢启动速度，通常需要1s左右； 2）同节点上所有任务运行在一个进程中，有利于共享内存。这非常适合内存密集型任务，尤其对于那些需要加载大量词典的应用程序，可大大节省内存。 3）同节点上所有任务可运行在一个JVM进程(Executor)中，且Executor所占资源可连续被多批任务使用，不会在运行部分任务后释放掉，这避免了每个任务重复申请资源带来的时间开销

/usr/local/spark/bin/spark-submit \ - - class com . wen . sparkstudy . WordCount \ - -num-executors 80 \ - -driver-memory 6 g \ - -executor-memory 6 g \ - -executor-cores 3 \ - -master yarn-cluster \ - -queue root.default \ - -conf spark.yarn.executor.memoryOverhead= 2048 \ - -conf spark.core.connection.ack.wait.timeout= 300 \ /usr/local/spark/spark.jar \ ${1} 1. executor堆外内存 有时候，如果你的spark作业处理的数据量特别特别大，几亿数据量；然后spark作业一运行，时不时的报错，shuffle file cannot find，executor、task lost，out of memory（内存溢出）； 可能是说executor的堆外内存不太够用，导致executor在运行的过程中，可能会内存溢出；然后可能导致后续的stage的task在运行的时候，可能要从一些executor中去拉取shuffle map

广播变量允许程序员保持只读变量，在每个机器上缓存，而不是用任务来发送它的副本。它们可以有效的方式给每个节点提供一个大的输入数据集的副本。spark尝试使用高效广播算法来分发广播变量以减少通信成本。注意，对象在广播后不应修改以确保所有节点获得广播变量的相同值 Broadcast 就是将数据从一个节点发送到其他的节点上; 例如 Driver 上有一张表，而 Executor 中的每个并行执行的Task (100万个Task) 都要查询这张表的话，那我们通过 Broadcast 的方式就只需要往每个Executor 把这张表发送一次就行了，Executor 中的每个运行的 Task 查询这张唯一的表，而不是每次执行的时候都从 Driver 中获得这张表！ Broadcast 是分布式的共享数据，默认情况下只要程序在运行 Broadcast 变量就会存在，因为 Broadcast 在底层是通过 BlockManager 管理的，Broadcast 是在创建 SparkContext 时被创建的！你也可以手动指定或者配置具体周期来销毁 Broadcast 变量！Broadcast 一般用于处理共享配置文件，通用的数据子，常用的数据结构等等；但是不适合存放太大的数据在Broadcast。Broadcast 不会内存溢出，因为其数据的保存的 Storage Level 是 MEMORY_AND

1.MRV1 有哪些不足？ 1) 可扩展性（对于变化的应付能力） a)JobTracker 内存中保存用户作业的信息 b)JobTracker 使用的是粗粒度的锁 2) 可靠性和可用性 a)JobTracker 失效会多事集群中所有的运行作业，用户需手动重新提交和恢复工作流 3) 对不同编程模型的支持 HadoopV1 以 MapReduce 为中心的设计虽然能支持广泛的用例，但是并不适合所有大型计算 , 如 storm ， spark 2. 描述 Yarn 执行一个任务的过程？ 1 ）客户端 client 向 ResouceManager 提交 Application ， ResouceManager 接受 Application 并根据集群资源状况选取一个 node 来启动 Application 的任务调度器 driver （ ApplicationMaster ） 2 ） ResouceManager 找到那个 node ，命令其该 node 上的 nodeManager 来启动一个新的 JVM 进程运行程序的 driver （ ApplicationMaster ）部分， driver （ ApplicationMaster ）启动时会首先向 ResourceManager 注册，说明由自己来负责当前程序的运行 3 ） driver （ ApplicationMaster

一、Executor（接口） /** * 执行器 * */ public interface Executor { //不需要ResultHandler ResultHandler NO_RESULT_HANDLER = null; //更新 int update(MappedStatement ms, Object parameter) throws SQLException; //查询，带分页，带缓存，BoundSql <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey cacheKey, BoundSql boundSql) throws SQLException; //查询，带分页 <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException; //刷新批处理语句 List<BatchResult> flushStatements() throws SQLException; //提交和回滚，参数是否要强制

Retrofit源码分析基于2.4.0。 本章节中将对Retrofit2中的CallAdapter机制做详细讲解。 在上一章节中曾提到了Call对象的创建是通过是通过ServiceMethod.adapt()完成的，这里在看看该方法的源码： ServiceMethod.adapt()方法： T adapt( Call <R> call ) { return callAdapter.adapt( call ); } 通过上述源码可知，最终Call对象是调用CallAdapter.adapt(Call)方法创建的，那么CallAdapter及具体的Call对象又是如何生成的呢？ 带着这个疑问开始本章节。 在上一章节Retrofit创建过程中知道，Retrofit创建时需要获取一个Platform对象，用于指定Retrofit运行的平台，这里我们看下Platform类，如下： class Platform { // 1、创建Platform实例 private static final Platform PLATFORM = findPlatform(); // 2、获取Platform实例 static Platform get() { return PLATFORM; } // 3、创建Platform实例 private static Platform findPlatform (

Azkaban 一 1.1 为什么需要工作流调度系统 1）一个完整的数据分析系统通常都是由大量任务单元组成： shell脚本程序，java程序，mapreduce程序、hive脚本等 2）各任务单元之间存在时间先后及前后依赖关系 3）为了很好地组织起这样的复杂执行计划，需要一个工作流调度系统来调度执行； 20G原始数据，我们每天都要对其进行处理，处理步骤如下所示： Hadoop先将原始数据上传到HDFS上（HDFS的操作）； MapReduce对原始数据进行清洗（MapReduce的操作）； hive表中（hive的导入操作）； Hive中多个表的数据进行JOIN处理，得到一张hive的明细表（创建中间表）； hive的查询操作）； 1.2 2）任务依赖（1）任务的结果，（3）任务依赖（2）任务的结果，（4）任务依赖（3）任务的结果，（5）任务依赖（4）任务的结果。一般的做法是，先执行完（1）再执行（2），再一次执行（3）（4）（5）。 crontab执行。其实，整个过程类似于一个有向无环图（DAG）。每个子任务相当于大任务中的一个节点，也就是，我们需要的就是一个工作流的调度器，而Azkaban就是能解决上述问题的一个调度器。 1.3 什么是azkaban Azkaban是由Linkedin公司推出的一个批量工作流任务调度器，主要用于在一个工作流内以一个特定的顺序运行一组工作和流程

版权声明：欢迎转载，注明出处即可 https://blog.csdn.net/yolohohohoho/article/details/90339655 关于Event Timeline 下面举个简单的例子，例如下图： 现在这很有趣。 我们看到基本都是红色和蓝色，也就是大部分时间花在了 Scheduler Delay 和 Task Deserialization Time 上 而我们真正想要看到的是很多绿色 ―― Executor Computing Time 的比例，就是executor真正执行工作所花的时间。 Scheduler Delay (蓝色部分)是等待的时间，即Executor正在等待某些东西 ―― 通常这是等待驱动程序来控制和协调作业。 而红色是任务反序列化时间 Task Deserialization Time ，一般来说它不应该这占用如此大的比例。 所以我们知道我们的任务需要很长时间来反序列化，但为什么呢？ 在这一点上，原因仍然不明确，但可以看出来程序中的数据被序列化并发送到每个Executor进行处理消耗了很长时间，因此很大可能是因为每个executor所分配的数据量太大了，可以考虑减小任务的大小，即将输入的数据进行更多的分区。 另外，由于 任务与数据分区是一对一的 ，这确实有助于我们回答这个问题：我们应该拥有多少个分区？ 更确切地说：如果分区（和任务）太少

SqlSession是mybatis的核心接口之一，是myabtis接口层的主要组成部分，对外提供了mybatis常用的api。myabtis提供了两个SqlSesion接口的实现，常用的实现类是DefaultSqlSession。它相当于一个 数据库 连接对象，在一个SqlSession中可以执行多条SQL语句。 创建SqlSession 前面的两篇文章我们已经得到了 SqlSessionFactory ，那么 SqlSession 将由 SqlSessionFactory 进行创建。 SqlSession sqlSession=sqlSessionFactory.openSession(); 我们就来 看看 这个SqlSessionFactory的 openSession方法是如何创建SqlSession对象的。根据上面的分析，这里的SqlSessionFactory类型对象其实是一个DefaultSqlSessionFactory对象，因此，需要到DefaultSqlSessionFactory类中去看openSession方法。 @Override public SqlSession openSession() { return openSessionFromDataSource(configuration.getDefaultExecutorType(), null,

在上一篇中我们剖析了Master的工作原理，这节我们接着来剖析Worker的工作员原理，Worker主要包括两部分的工作，启动Executor和启动Driver，然后向Master发送注册启动消息。 下面是Worker的工作流程图： 在Application向Master注册之后，Master会发出命令启动Wroker，在Worker节点启动之后，它会调动内部的两个方法LaunchDriver和LaunchExecutor分别启动Driver和Executor，它们的启动过程大致相同，都是先创建一个DriverRunnner或者ExecutorRunner来封装Driver或者Executor的信息来启动Driver或者Executor，先创建它们各自的工作目录，然后会调用内部的start的方法启动，在start方法中会创建ProcessBuilder来启动进程，最后它会等待Driver或者Executor工作完成退出，最后向它们各自所在的Worker节点发送DriverStateChanged消息，接着Worker向Master发送DriverStateChanged消息。 首先来看看Driver启动的LaunchDriver方法的源码： /** * 启动Driver */ case LaunchDriver(driverId, driverDesc) => { logInfo