标签：
王家林每日大数据语录Spark篇0043（2015.12.15于上海）:Worker在退出的时候会通过ExecutorRunner杀死Executor并且会将运行在当前Worker下的Driver Client删除掉，最终AppClient端的SparkDeploySchedulerBackend会收到Master发过来的StatusUpdate信息来处理Executor丢失的信息，Task会被重新分配。
王家林每日大数据语录Spark篇0042（2015.12.15于上海）:生产环境下Spark Master一般选择使用ZooKeeper做HA,如果当前管理集群的Master失败，ZooKeeper会在Standby模式下的Master中选出新的集群管理者，新选举出的Master会从ZooKeeper中读取集群的Worker、Driver Client、Application等元数据信息进行恢复并和Worker、Driver Client、Application沟通，最后Master会变成ACTIVE的状态，开始对外提供服务。
王家林每日大数据语录Spark篇0041（2015.12.14于上海）:Spark对错误的处理提供了高度的弹性，对于集群而言，机器故障、网络故障时常态，Spark基于RDD的调度和容错系统和Hadoop相比能够以更小的代价和更快的速度从错误中恢复从而持续提供数据处理服务。
王家林每日大数据语录Spark篇0040（2015.12.14于上海）:Worker在向Master注册的时候如果在指定的时间收不到Master的响应会重新发送注册信息进行重试，目前重试次数是16次，其中前6次的重试时间间隔是5-15秒，后面10次重试的时间间隔是30-90秒。
王家林每日大数据语录Spark篇0039（2015.12.14于上海）:Worker会记录当前机器节点使用的CPU Cores、Memory等信息，但在Worker给Master发送心跳的时并不会携带这些信息，Worker向Master发送心跳只是为了说明Worker还在活着，而Master在让Worker分配资源的时候会记录资源Worker的资源的使用，并且在Worker的资源被回收的时候也会想Master发送消息。
王家林每日大数据语录Spark篇0038（2015.12.13于上海）:Spark Master实现基于ZooKeeper的HA的时候，整个集群的元数据会持久化到ZooKeeper中，在Master故障后ZooKeeper会在Standby的Master中选举出新的Master，新选举出来的Master在启动后会从ZooKeeper中获取元数据信息并基于这些元数据信息恢复集群的状态，从而让新的Master提供资源管理和分配服务。
王家林每日大数据语录Spark篇0037（2015.12.12于广州）:Spark Master保存了整个集群中所有Worker、Application、Driver的元数据信息，具体的元数据的持久化方式可能是ZooKeeper、FileSystem或者其它用户自定义的方式。默认情况下不保存元数据，Master在启动之后会立即接管集群的管理工作。
王家林每日大数据语录Spark篇0036（2015.12.11于广州）:Spark部署模式采用的是典型的Master-Slave架构，Master负责整个集群的资源调度和Application的管理，Worker接受Master的资源分配命令来启动具体的Executor，通过Executor中线程池来并行的完成Task的计算。
王家林每日大数据语录Spark篇0035（2015.12.11于广州）:Spark on Mesos细粒度的资源调度模式是指根据任务的实际需要动态申请资源，任务完成后就会将申请的资源归还给系统，这种方式可以有效的避免资源的浪费，但是也带来的调度时间的开销，尤其是在任务运行时间非常短但是计算任务数量有非常多的情况下对性能的影响会非常大。
王家林每日大数据语录Spark篇0034（2015.12.11于广州）:Spark on Mesos粗粒度的资源调度模式是指每个Executor获得资源后就长期持有，直到应用程序退出才会释放资源。这种方式的优点是减少了资源调度的时间开销，缺点是可能造成资源浪费，尤其在有些计算出现长尾的情况下。
王家林每日大数据语录Spark篇0033（2015.12.2于北京）:Spark的Cluster Manager支持Standalone、YARN、Mesos、EC2、Local等五种模式，Standalone模式极大的丰富和扩展了Spark的应用场景、同时也极大的降低了部署和使用Spark的难度
王家林每日大数据语录Spark篇0032（2015.12.1于北京）:Spark中的Task会被发送到为当前程序启动的Executors中，由Executor在线程池中使用线程完成Task的计算，执行的过程调用TaskRunner的run方法。
王家林每日大数据语录Spark篇0031（2015.11.25于上海）:一个Job包含多个Stage（至少一个Stage），Stage内部是一组完全相同的Task构成，这些Task只是处理的数据不同；一个Stage的开始就是从外部存储或者Shuffle结果中读取数据，一个Stage的结束是由于要发送Shuffle或者生成最终的计算结果。
王家林每日大数据语录Spark篇0030（2015.11.25于上海）:Task是Spark集群运行的基本单位，一个Task负责处理RDD的一个Partition，Spark中的ShuffleMapTask会根据Task的partitioner将计算结果放到不同的bucket中，而ResultTask会将计算结果发送回Driver。
王家林每日大数据语录Spark篇0029（2015.11.25于上海）:对于Spark的Standalone模式而言，在创建SparkContext的时候会通过Master为用户提交的计算分配计算资源Executors，在DAGScheduler将计算任务通过TaskSet的方式提交给TaskScheduler的时候就会在已经分配好的计算资源启动计算的Tasks。
王家林每日大数据语录Spark篇0028（2015.11.25于上海）:TaskSetManager在Task执行失败时根据不同的失败原因采取不同的处理方式，如果是Task结果序列化失败，就会说明Task的执行有问题，会直接导致TaskSetManager的失败，如果是其它的情况，TaskSetManager会重试任务的执行，默认重试的最大次数是4次，当然，用户也可以通过修改spark.task.maxFailures来设置这个最大重试次数。
王家林每日大数据语录Spark篇0027（2015.11.24于上海）:Task在Executor执行完成后会想Driver发送StatusUpdate消息来通知Driver任务的状态，此时Driver端会首先调用TaskScheduler的具体是闲着statusUpdate来处理结果信息。
王家林每日大数据语录Spark篇0026（2015.11.24于上海）:Spark的任务调度具体实现有FIFO和FAIR两种实现，FIFO方式的Pool中是TaskSetManager，而FAIR的Pool里面包含了一组由Pool构建的调度树，这棵树的叶子节点是TaskSetManager.
王家林每日大数据语录Spark篇0026（2015.11.24于上海）:Spark的任务调度具体实现有FIFO和FAIR两种实现，FIFO方式的Pool中是TaskSetManager，而FAIR的Pool里面包含了一组由Pool构建的调度树，这棵树的叶子节点是TaskSetManager.
王家林每日大数据语录Spark篇0025（2015.11.24于上海）:Spark的MapOutputTrackerMaster是运行在Driver端管理Job中ShuffleMapTask输出的，这样整个Job中的下一个Stage就可以通过MapOutputTrackerMaster来获取上一个依赖的Stage内部Task处理完数据后所保存的数据的位置信息，进而获取所依赖Stage的数据。
王家林每日大数据语录Spark篇0024（2015.11.24于上海）:Spark的任务调度模块的三个核心累分别是DAGScheduler、TaskScheduler和SchedulerBackend，其中SchedulerBackend的作用是向当前等待分配的计算资源Task分配计算资源Executor，并且在分配的Executor上启动该Task，最终完成计算的调度过程。
王家林每日大数据语录Spark篇0023（2015.11.18于珠海）:Spark的调度器分为高层调度器DAGScheduler和底层调度器TaskScheduler，其中TaskScheduler是一个抽象类，其最为重要的实现是TaskSchedulerImpl，其中Local、Standalone、Mesos底层调度器的实现都是TaskSchedulerImpl，而Yarn Cluster和Yarn Client的TaskScheduler的实现分别是YarnClusterScheduler和YarnClientClusterScheduler都是继承自TaskSchedulerImpl。
王家林每日大数据语录Spark篇0022（2015.11.18于珠海）:Spark Checkpoint通过将RDD写入Disk做检查点，是Spark lineage容错的辅助，lineage过长会造成容错成本过高，这时候在中间阶段做检查点容错，如果之后有节点出现问题而丢失分区，从做检查点的RDD开始重做Lineage，就会减少开销。Checkpoint主要适用于以下两种情况：1. DAG中的Lineage过长，如果重算时会开销太大，例如在PageRank、ALS等；2. 尤其适合于在宽依赖上做Checkpoint，这个时候就可以避免应为Lineage重新计算而带来的冗余计算。
王家林每日大数据语录Spark篇0021（2015.11.18于珠海）:Spark RDD实现基于Lineage的容错机制，基于RDD的各项transformation构成了compute chain，在部分计算结果丢失的时候可以根据Lineage重新计算恢复。在窄依赖中，在子RDD的分区丢失要重算父RDD分区时，父RDD相应分区的所有数据都是子RDD分区的数据，并不存在冗余计算；在宽依赖情况下，丢失一个子RDD分区重算的每个父RDD的每个分区的所有数据并不是都给丢失的子RDD分区用的，会有一部分数据相当于对应的是未丢失的子RDD分区中需要的数据，这样就会产生冗余计算开销和巨大的性能浪费。
王家林每日大数据语录Spark篇0020（2015.11.11于重庆）:Spark中生成的不同的RDD中有的和用户逻辑显示的对应，例如map操作会生成MapPartitionsRDD，而又的RDD则是Spark框架帮助我们隐式生成的，例如reduceByKey操作时候的ShuffledRDD.
王家林每日大数据语录Spark篇0019（2015.11.10于重庆）:Spark中的Task分为ShuffleMapTask和ResultTask两种类型，在Spark中DAG的最后一个Stage内部的任务都是ResultTask，其余所有的Stage(s)的内部都是ShuffleMapTask，生成的Task会被Driver发送到已经启动的Executor中执行具体的计算任务，执行的实现是在TaskRunner.run方法中完成的。
王家林每日大数据语录Spark篇0018（2015.11.7于南宁）:在Spark的reduceByKey操作时会触发Shuffle的过程，在Shuffle之前，会有本地的聚合过程产生MapPartitionsRDD，接着具体Shuffle会产生ShuffledRDD,之后做全局的聚合生成结果MapPartitionsRDD.
王家林每日大数据语录Spark篇0017（2015.11.6于南宁）:在Spark的Stage内部的每个Partition都会被分配一个计算任务Task，这些Task是并行执行的; Stage之间的依赖关系变成了一个大粒度的DAG，Stage只有在它没有parent Stage或者parent Stage都已经执行完成后才可以执行，也就是说DAG中的Stage是从前往后顺序执行的。
王家林每日大数据语录Spark篇0016（2015.11.6于南宁）:RDD在创建子RDD的时候，会通过Dependency来定义他们之间的关系，通过Dependency，子RDD可以获得parent RDD(s)和parent RDD(s)的Partition(s).
王家林每日大数据语录Spark篇0015（2015.11.5于南宁）:Spark中宽依赖指的是生成的RDD的每一个partition都依赖于父 RDD(s) 所有partition，宽依赖典型的操作有groupByKey, sortByKey等，宽依赖意味着shuffle操作，这是Spark划分stage的边界的依据，Spark中宽依赖支持两种Shuffle Manager，即HashShuffleManager和SortShuffleManager，前者是基于Hash的Shuffle机制，后者是基于排序的Shuffle机制。
王家林每日大数据语录Spark篇0014（2015.11.4于南宁）:对于Spark中的join操作，如果每个partition仅仅和特定的partition进行join那么就是窄依赖；对于需要parent RDD所有partition进行join的操作，即需要shuffle,此时就是宽依赖。
王家林每日大数据语录Spark篇0013（2015.11.3于广州）:RDD有narrow dependency和wide dependency两种不同的类型的依赖，其中的narrow dependency指的是每一个parent RDD 的Partition最多被child RDD的一个Partition所使用，而wide dependency指的是多个child RDDs的Partition会依赖于同一个parent RDD的Partition。
王家林每日大数据语录Spark篇0012（2015.11.2于深圳）:可以从两个方面来理解RDD之间的依赖关系，一方面是RDD的parent RDD(s)是什么，另一方面是依赖于parent RDD(s)哪些Partions(s); 根据依赖于parent RDD(s)哪些Partions(s)的不同情况，Spark讲Dependency分为宽依赖和窄依赖两种。
王家林每日大数据语录Spark篇0011（2015.11.2于深圳）:RDD的saveAsTextFile方法会首先生成一个MapPartitionsRDD，该RDD通过雕工PairRDDFunctions的saveAsHadoopDataset方法向HDFS等输出RDD数据的内容，并在在最后调用SparkContext的runJob来真正的向Spark集群提交计算任务。
王家林每日大数据语录Spark篇0010（2015.11.2于深圳）:SparkContext是用户程序和Spark交互的接口，它会负责连接到Spark集群，并且根据系统默认配置和用户设置来申请计算资源，完成RDD的创建等工作。
王家林每日大数据语录Spark篇0009（2015.11.1于北京）:Spark的CheckPoint是在计算完成之后重新建立一个Job来进行计算的，用户可以通过调用RDD.checkpoint()来指定RDD需要checkpoint的机制；为了避免重复计算，建议先对RDD进行persist操作，这样可以保证checkpoint更加快速的完成。
王家林每日大数据语录Spark篇0008（2015.10.31于北京）:持久化（包含Memory、Disk、Tachyon等类型）是Spark构建迭代算法和快速交互式查询的关键，当通过persist对一个RDD持久化后，每一个节点都将把计算的分片结果保存在内存或者磁盘或者Tachyon上，并且对此数据集或者衍生出来的数据集进行的其它Action级别的炒作都可以重用当前RDD的计算结果，这是的后续的的操作通常会快10到100倍。
王家林每日Spark语录0007（2015.10.30于北京）:RDD的所有Transformation操作都是Lazy级别的，实际上这些Transformation级别操作的RDD在发生Action操作之前只是仅仅被记录会作用在基础数据集上而已，只有当Driver需要返回结果的时候，这些Transformation类型的RDD才会真正作用数据集，基于这样设计的调度模式和运行模式让Spark更加有效率的运行。
王家林每日Spark语录0006（2015.10.29于深圳）:基于RDD的整个计算过程都是发生在Worker中的Executor中的。RDD支持三种类型的操作：Transformation、Action以及Persist和CheckPoint为代表的控制类型的操作，RDD一般会从外部数据源读取数据，经过多次RDD的Transformation（中间为了容错和提高效率，有可能使用Persist和CheckPoint），最终通过Action类型的操作一般会把结果写回外部存储系统。
王家林每日Spark语录0005（2015.10.28于深圳）: Spark RDD是被分区的，对于RDD来说，每个分区都会被一个计算任务处理，并决定并行计算的粒度；RDD的每次转换操作都会生成新的RDD，在生成RDD时候，一般可以指定分区的数量，如果不指定分区数量，当RDD从集合创建时候，则默认为该程序所分配到的资源的CPU核数，如果是从HDFS文件创建，默认为文件的Block数。
王家林每日Spark语录0004:Spark中RDD采用高度受限的分布式共享内存，且新的RDD的产生只能够通过其它RDD上的批量操作来创建，依赖于以RDD的Lineage为核心的容错处理，在迭代计算方面比Hadoop快20多倍，同时还可以在5~7秒内交互式的查询TB级别的数据集。
王家林每日Spark语录0003:Spark一体化多元化的解决方案极大的减少了开发和维护的人力成本和部署平台的物力成本，并在性能方面有极大的优势，特别适合于迭代计算，例如机器学习和和图计算；同时Spark对Scala和Python交互式shell的支持也极大的方便了通过shell直接来使用Spark集群来验证解决问题的方法，这对于原型开发至关重要，对数据分析人员有着无法拒绝的吸引力！
王家林每日Spark语录0002:Spark基于RDD近乎完美的实现了分布式内存的抽象，且能够基于位置感知性调度、自动容错、负载均衡和高度的可扩展性，Spark中允许用户在执行多个查询时显式的将工作集缓存起来以供后续查询重用，这极大的提高了查询的速度。
王家林每日Spark语录0001:腾讯的Spark集群已经达到8000台的规模，是目前已知最大的Spark集群，每天运行超过1万各种作业。单个Spark Job最大分别是阿里巴巴和Databricks——1PB。
标签：
原文地址：http://www.cnblogs.com/sparkbigdata/p/5403994.html
