stage

1.查看index/stage的文件 git ls-files 2.删除某个index/stage的文件 git rm --cached xxx（file名字） 切换分支，index/stage共享文件， 可以多次checkout，checkout默认是从index/stage checkout。 3.git stash 即使是git add了的文件，git stash之后，也会恢复到上次提交的文件 来源： CSDN 作者： natual177 链接： https://blog.csdn.net/natual177/article/details/103800686

小白一枚，欢迎吐槽~ SSD:Single Shot MultiBox Detector. one-stage和two-stage网络说明 one-stage网络会讲图片分成许多image patch,之后在每个patch上设置不同宽高的anchor框，网络对该框的数据进行分类和回归即可得到结果。two-stage网络则是会先生成建议目标候选区域，然后送入分类器分类。 特点： one-stage网络速度要快很多，但是准确性稍低。one-stage网络反之。 two-stage网络会首先生成若干候选区域，讲这些候选区域放入分类器进行分类，候选区域其实并不多，所以不会造成严重的正负样本不均衡，而one-stage网络例如yolo3就不同了，它存在三种尺度，13x13，26x26，52x52，每种尺度的每个像素点生成三种anchor而一张图片的目标是较少的，会存在正负样本失衡，目标置信度损失会受到影响。one-stage网络进入分类器的anchor框较多，但是只有少数anchor对最终网络的学习是有利的，而大部分ancor对最终网络的学习都是不利的，负样本很大程度上影响了整个网络的学习，拉低了整体的准确率；而two-stage网络进入分类器的anchor框相对不多，但是负样本也就是对网络学习不利的anchor减少了，与one-stage网络相比，负样本对two-stage网络的影响要小

Spack进阶 1.RDD的依赖关系 窄依赖(不产生shuffle) 父RDD和子RDD的patiition之间的关系是一对一,或者是多对一的关系 宽依赖(会有shuffle产生(类似中间结果,会影响计算效率)) 父RDD和子RDD的patition之间的关系是多对一. 宽依赖与窄依赖示意图 2.stage 过程 spark会根据RDD之间的依赖关系,形成一个有向无环图(DAG),DAG会提交给DAGscheduler,DAGScheduler会将DAG划分为多个相互依赖的stage,划分规则就是从后往前遇到宽依赖就切割stage,每一个stage里包含task,将这些task以taskset的形式传给taskScheduler运行, 切割规则 从后往前遇到宽依赖就切割成stage stage的计算模式 pipeline管道计算模式,(一条路走到黑) stage的注意点 管道里面的数据说明时候可以落地呢 当RDD进行持久化时 当shuffle write时 stage的task的并行度由stage的最后一个RDD来决定的 如何改变RDD的分区数呢 reduceByKey(XXX,3),GroupByKey(4) 3.spark的资源调度与任务调度 以standalone的client为例 启动集群后,worker节点向Master节点发送本机的资源情况.

Stage Spark任务会根据RDD之间的依赖关系，形成一个DAG有向无环图，DAG会提交给DAGScheduler，DAGScheduler会把DAG划分相互依赖的多个stage，划分stage的依据就是RDD之间的宽窄依赖。 遇到宽依赖就划分stage ,每个stage包含一个或多个task任务。然后将这些task以taskSet的形式提交给TaskScheduler运行。 stage是由一组并行的task组成。 stage切割规则 切割规则：从后往前，遇到宽依赖就切割stage。 stage计算模式 pipeline管道计算模式,pipeline只是一种计算思想，模式。 管道计算模式是便于理解虚构的 实际上并没有pipeline的类 问题解析 数据一直在管道里面什么时候数据会落地？ 1.对RDD进行持久化。 2.shuffle write的时候。 Stage的并行度由什么确定 Stage的task并行度是由stage的最后一个RDD的分区数来决定的 。 如何改变RDD的分区数？ 例如：reduceByKey(XXX,3),GroupByKey(4) 测试验证pipeline计算模式 测试代码示例: val conf = new SparkConf ( ) conf . setMaster ( "local" ) . setAppName ( "pipeline" ) ;

　　每个action对应一个job，每个job里面会有很多个阶段（stage），其实每个stage都是一个算子（Operation），可能是transformation，可能是action；但是action一定是一个job的最后一个stage， 其实action之前的stage都是做DAG而已，真正触发执行其实是在action执行的时候，因为action的操作是基于前面的transformation执行结果基础之上的，这也算是一种懒加载吧。 　　关于DAG，通过看YARN的UI，发现其实只是包括Transformation（在job页面，点击DAG Visualization），但是Job其实是包含两类stage，一部分是DAG（map算子组合）stage，一部分执行（action）stage，一定是最后一个stage；所以在job页面，DAG+stage decription里面描述的action，组合在一起才是一个Job；与之对应的一个job最多只有两个stage，一个stage是map构建的DAG过程，第二个stage 　　举一个栗子： rdd.map( r => mapFunction(r)).repartitionAndSortWithinPartitions(regionSplitPartitioner).hbaseForeachPartition( this ,