executor

1 ，库存流水，转换格式 ： spark-submit --master yarn --deploy-mode cluster --num-executors 5 --executor-cores 3 --executor-memory 6144m --class lifecycle01_tool.ParseCsvToParquet s3://lifecyclebigdata/dataWareHouse/BALABALA/00jar/02_work/veryOK-1.0-SNAPSHOT.jar lifecyclebigdata/dataWareHouse/BALABALA/01history/2019Q3_3/库存流水.gz lifecyclebigdata/dataWareHouse/BALABALA/02pdw/01_正确数据/21_库存流水/res01 2 ，库存结余，转换格式 ： spark-submit --master yarn --deploy-mode cluster --num-executors 5 --executor-cores 3 --executor-memory 6144m --class lifecycle01_tool.ParseCsvToParquet s3://lifecyclebigdata/dataWareHouse/BALABALA

前言 　　上篇笔记我们成功的装载了Configuration，并写入了我们全部需要的信息。根据这个Configuration创建了DefaultSqlSessionFactory。本篇我们实现构建SqlSession即mybatis的一次sql会话，并获取到我们常用的代理mapper接口类。在正文之前先放上之前的一段代码 　　 @Autowired private SqlSessionFactory sqlSessionFactory; @GetMapping("/get") public List<AssetInfo> get(){ SqlSession sqlSession = sqlSessionFactory.openSession(); AssetInfoMapper mapper = sqlSession.getMapper(AssetInfoMapper.class); List<AssetInfo> test = mapper.get("测试删除" , "123123123"); System.out.println(test); return test; } public interface AssetInfoMapper { List<AssetInfo> get(@Param("name") String name, @Param("id")String id

上一篇说到CacheManager和checkpoint来管理缓存和数据相关的东西。但实际上，他们底层都是通过BlockManger来管理数据的。 找到RDD#getOrCompute中的 SparkEnv.get.blockManager.getOrElseUpdate(blockId, storageLevel, elementClassTag,我们就可以看到最终是通过BlockManager来管理数据。在分析源码前老规矩，先画一张整体的图 首先Driver上有一个BlockManagerMaster，它的功能就是负责各个节点上的BlockManager元数据管理，进行维护。比如block的增删改查等操作，都会在这里维护变更。 每个节点上都会有blockManager，BlockManager有几个关键组件： DiskStore：负责磁盘上的数据进行读写 MemoryStore：负责对内存上的数据进行读写 BlockTransferService：负责和远程节点建立数据传输的组件 每个BlockManager创建之后，向Driver中的BlockManagerMaster进行注册，此时BlockManager会为创建对应的BlockManagerInfo。 使用BlockManager进行读写操作时，比如RDD运行过程中间数据，或者手动指定了persisit，优先将数据写入内存

mybatis的插件开发：主要就是实现拦截器，mybatis在创建四大神器的时候会将我们的拦截器逻辑通过代理的方式植入进去。 mybatis在创建Executor,StatmentHandler,ParameterHandler,ResultHandler这四个对象的时候都会有这个处理逻辑： interceptorChain.pluginAll(resultSetHandler) 下面看其中两个： public ParameterHandler newParameterHandler ( MappedStatement mappedStatement , Object parameterObject , BoundSql boundSql ) { ParameterHandler parameterHandler = mappedStatement . getLang ( ) . createParameterHandler ( mappedStatement , parameterObject , boundSql ) ; parameterHandler = ( ParameterHandler ) interceptorChain . pluginAll ( parameterHandler ) ; return parameterHandler ; } public

Question about RDD、分区、stage、并行计算、集群、流水线计算、shuffle（join？？）、task、executor RDD是spark数据中最基本的数据抽象，task是spark的最小代码执行单元？数据不是代码的资源？？？那为什么RDD又是分区存储？节点中又是对分区（父分区进行流水线计算）？RDD只能转换操作，但是RDD可以分成多个分区，而且这些分区可以被保存到集群中不同的节点，可在不同的节点进行并行计算，那RDD还是高度受限的吗？在一个节点的中以流水线形式计算窄关系的父节点，那RDD还是高度受限的吗？将RDD分成stage，又是为了什么？分配资源吗？优化效率吗？哈希分区和范围分区？shuffle又是什么？？？task也又是什么？？？ 流水线计算？是transformation？？那就是进行数据的筛选？？不对，机器学习算法和交互式数据挖掘使用的目的是什么？理解这个能够理解父分区中的流水计算！ shuffle操作中的reduce task需要 跨节点去拉取（为什么要跨节点拉取，因为RDD的不同分区都是在不同的节点储存，但宽关联是子RDD的一个分区就需要父RDD的所有分区，肯定要跨节点。而窄关联的子RDD中的一个分区只是有父RDD的一个分区就可，所以不需要跨节点，但是 join？？？？？ 前提组成子RDD的分区的父分区都在同一个节点？？

1.1.1 常规性能调优一：最优资源配置 Spark性能调优的第一步，就是为任务分配更多的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。 资源的分配在使用脚本提交Spark任务时进行指定，标准的Spark任务提交脚本如代码清单2-1所示：、 /usr/opt/modules/spark/bin/spark-submit \ --class com.atguigu.spark.Analysis \ --num-executors 80 \ --driver-memory 6g \ --executor-memory 6g \ --executor-cores 3 \ /usr/opt/modules/spark/jar/spark.jar \ 可以进行分配的资源如表2-1所示： 表2-1 可分配资源表 名称 说明 --num-executors 配置Executor的数量 --driver-memory 配置Driver内存（影响不大） --executor-memory 配置每个Executor的内存大小 --executor-cores 配置每个Executor的CPU core数量 调节原则：尽量将任务分配的资源调节到可以使用的资源的最大限度。 对于具体资源的分配

Release Notes - Mesos - Version 1.1.1 (WIP) This is a bug fix release. Release Notes - Mesos - Version 1.1.0 This release contains the following new features: [MESOS-2449] - Experimental support for launching a group of tasks via a new LAUNCH_GROUP Offer operation. Mesos will guarantee that either all tasks or none of the tasks in the group are delivered to the executor. Executors receive the task group via a new LAUNCH_GROUP event. [MESOS-2533] - Experimental support for HTTP and HTTPS health checks. Executors may now use the updated HealthCheck protobuf to implement HTTP(S) health checks.