Monthly Archive: 九月 2014

ping的ttl含义

ping的ttl含义

TTL值全称是“生存时间(Time To Live)”

不同的 OS 在 TTL 的设置上是不同的,他们的基数不同
比如,Solaris 和早起的 RedHat TTL = 255
FreeBSD 和现在的 Linux TTL = 64
Windows TTL = 128

ping 一个网站,看 TTL 是多少,大概可以分辨出他的 OS (这里说“大概”,因为有很多例外)
通过 TTL 可以知道他原先的 TTL 基数是多少
比如 119,大概知道基数是 128,大概是 WINDOWS 操作系统
比如 232,大概知道基数是 255,大概知道是 Solaris 或其他 UNIX 系统
比如 46,大概知道基数是 64,大概知道是 Linux 或其他 UNIX 系统比如 FreeBSD
TTL 在系统里是可调的.
每过一次路由,TTL 要 -1,因此也可以知道大概中间过了多少跳
比如一个 TTL = 43 和 TTL= 123 的网站,大概知道后者访问起来比前者要快,因为经过的跳数相对少些 

原文:http://www.jszl.org/post-10.html

oracle数据库数据字典及动态性能视图

oracle数据库数据字典及动态性能视图

oracle官方:http://docs.oracle.com/cd/E11882_01/server.112/e40540/datadict.htm#CNCPT002

数据字典是只读的表和视图,动态性能视图在数据库运行时不断进行更新。

Overview of the Data Dictionary

数据字典提供数据库的管理元数据。包含以下信息:

  • 所有schema object(模式对象 注1)的定义,包含列的默认值及完整性约束。

  • schema object所分配及已使用的空间

  • 为oracle用户分配的用户、特权、角色,用户的审计信息

数据字典是oracle数据库进行数据管理的主要部分。例如,oracle执行以下内容:

  • 通过查询数据字典来获得用户、模式对象、存储结构

  • 每当下达一次DDL(数据定义语言)声明,更新一次数据字典

数据字典存在数据库表中,可以使用sql访问。

数据字典定义

数据字典由以下类型的对象组成:

  • 基本表

这些底层表存储数据库信息,只有数据库可以访问及修改这些表。一般用户不会访问这些表,因为数据格式化存储,并进行了加密

  • 视图

这些视图将基本表中的数据解析为有用信息,例如用户,表名。这些视图包含基本表中所有对象的命名和描述。一些视图可以被所有用户访问,一些视图则只提供给管理员使用。

数据字典视图按照用户分组管理。通常来说,三组视图通过其前缀区分。每一组视图只提供给其对应的用户查看。如下表:

Prefix User Access Contents Notes

DBA_

Database administrators

All objects

Some DBA_ views have additional columns containing information useful to the administrator.

ALL_

All users

Objects to which user has privileges

Includes objects owned by user. These views obey the current set of enabled roles.

USER_

All users

Objects owned by user

Views with the prefix USER_ usually exclude the column OWNER. This column is implied in the USER_ views to be the user issuing the query.

不是所有的视图都包含前述三个用户组的数据。例如,数据字典只包含DBA_LOCK而不包含ALL_LOCK视图。

系统自带的DICTIONARY视图包括所有数据字典视图的名字和简短说明。例:

原文链接

sparkinternal作业调度【mark待学,先看看DAG的解释】

sparkinternal作业调度【mark待学,先看看DAG的解释】

出处:http://blog.csdn.net/colorant/article/details/24010035


Spark中作业调度的相关类最重要的就是DAGSchedulerDAGScheduler顾名思义就是基于DAG图的Scheduler


DAG全称 Directed Acyclic Graph,有向无环图。简单的来说,就是一个由顶点和有方向性的边构成的图中,从任意一个顶点出发,没有任何一条路径会将其带回到出发的顶点。

 

在作业调度系统中,调度的基础就在于判断多个作业任务的依赖关系,这些任务之间可能存在多重的依赖关系,也就是说有些任务必须先获得执行,然后另外的相关依赖任务才能执行,但是任务之间显然不应该出现任何直接或间接的循环依赖关系,所以本质上这种关系适合用DAG有向无环图来表示。

 

概括地描述DAGSchedulerTaskScheduler(关于TaskScheduler的相关细节,在我之前的关于Spark运行模式的文章中有)的功能划分就是:TaskScheduler负责实际每个具体任务的物理调度,DAGScheduler负责将作业拆分成不同阶段的具有依赖关系的多批任务,可以理解为DAGScheduler负责任务的逻辑调度。

 

 

基本概念

 

Task任务 :单个分区数据集上的最小处理流程单元

TaskSet任务集:一组关联的,但是互相之间没有Shuffle依赖关系的任务所组成的任务集

Stage调度阶段:一个任务集所对应的调度阶段

Job作业:一次RDD Action生成的一个或多个Stage所组成的一次计算作业

 

 

运行方式

 

DAGSchedulerSparkContext初始化过程中实例化,一个SparkContext对应一个DAGSchedulerDAGScheduler的事件循环逻辑基于Akka Actor的消息传递机制来构建,在DAGSchedulerStart函数中创建了一个eventProcessActor用来处理各种DAGSchedulerEvent,这些事件包括作业的提交,任务状态的变化,监控等等

[plain] view plaincopy

  • private[scheduler]case class JobSubmitted(  

  •     jobId: Int,  

  •     finalRDD: RDD[_],  

  •     func: (TaskContext, Iterator[_]) => _,  

  •     partitions: Array[Int],  

  •     allowLocal: Boolean,  

  •     callSite: String,  

  •     listener: JobListener,  

  •     properties: Properties = null)  

  •   extends DAGSchedulerEvent  

  •    

  • private[scheduler]case class JobCancelled(jobId: Int) extends DAGSchedulerEvent  

  • private[scheduler]case class JobGroupCancelled(groupId: String) extends DAGSchedulerEvent  

  • private[scheduler]case object AllJobsCancelled extends DAGSchedulerEvent  

  • private[scheduler]  

  • case classBeginEvent(task: Task[_], taskInfo: TaskInfo) extends DAGSchedulerEvent  

  •    

  • private[scheduler]  

  • case classGettingResultEvent(task: Task[_], taskInfo: TaskInfo) extends DAGSchedulerEvent  

  •    

  • private[scheduler]case class CompletionEvent(  

  •     task: Task[_],  

  •     reason: TaskEndReason,  

  •     result: Any,  

  •     accumUpdates: Map[Long, Any],  

  •     taskInfo: TaskInfo,  

  •     taskMetrics: TaskMetrics)  

  •   extends DAGSchedulerEvent  

  •    

  • private[scheduler]case class ExecutorAdded(execId: String, host: String) extendsDAGSchedulerEvent  

  • private[scheduler]case class ExecutorLost(execId: String) extends DAGSchedulerEvent  

  • private[scheduler]  caseclass TaskSetFailed(taskSet: TaskSet, reason: String) extends DAGSchedulerEvent  

  • private[scheduler]case object ResubmitFailedStages extends DAGSchedulerEvent  

  • private[scheduler]case object StopDAGScheduler extends DAGSchedulerEvent  


  •  

    不论是Client还是TaskSchedulerDAGScheduler的交互方式基本上都是通过DAGScheduler暴露的函数接口间接的给eventProcessActor发送相关消息

     

    如前面所说,DAGScheduler最重要的任务之一就是计算作业和任务的依赖关系,制定调度逻辑

     

    DAGScheduler作业调度的两个主要入口是submitJob  runJob,两者的区别在于前者返回一个Jobwaiter对象,可以用在异步调用中,用来判断作业完成或者取消作业,runJob在内部调用submitJob,阻塞等待直到作业完成(或失败)

     

    具体往DAGScheduler提交作业的操作,基本都是封装在RDD的相关Action操作里面,不需要用户显式的提交作业

     

    用户代码都是基于RDD的一系列计算操作,实际运行时,这些计算操作是Lazy执行的,并不是所有的RDD操作都会触发SparkCluster上提交实际作业,基本上只有一些需要返回数据或者向外部输出的操作才会触发实际计算工作,其它的变换操作基本上只是生成对应的RDD记录依赖关系。

     

    DAGScheduler内部维护了各种 task / stage / job之间的映射关系表

     

    工作流程

     

    提交并运行一个Job的基本流程,包括以下步骤

     

    划分Stage

     

    当某个操作触发计算,向DAGScheduler提交作业时,DAGScheduler需要从RDD依赖链最末端的RDD出发,遍历整个RDD依赖链,划分Stage任务阶段,并决定各个Stage之间的依赖关系。Stage的划分是以ShuffleDependency为依据的,也就是说当某个RDD的运算需要将数据进行Shuffle时,这个包含了Shuffle依赖关系的RDD将被用来作为输入信息,构建一个新的Stage,由此为依据划分Stage,可以确保有依赖关系的数据能够按照正确的顺序得到处理和运算。

     

    GroupByKey操作为例,该操作返回的结果实际上是一个ShuffleRDD,当DAGScheduler遍历到这个ShuffleRDD的时候,因为其Dependency是一个ShuffleDependency,于是这个ShuffleRDD的父RDD以及shuffleDependency等对象就被用来构建一个新的Stage,这个Stage的输出结果的分区方式,则由ShuffleDependency中的Partitioner对象来决定。

     

    可以看到,尽管划分和构建Stage的依据是ShuffleDependency,对应的RDD也就是这里的ShuffleRDD,但是这个Stage所处理的数据是从这个shuffleRDD的父RDD开始计算的,只是最终的输出结果的位置信息参考了ShuffleRDD返回的ShuffleDependency里所包含的内容。而shuffleRDD本身的运算操作(其实就是一个获取shuffle结果的过程),是在下一个Stage里进行的。

     

    生成Job,提交Stage

     

    上一个步骤得到一个或多个有依赖关系的Stage,其中直接触发JobRDD所关联的Stage作为FinalStage生成一个Job实例,这两者的关系进一步存储在resultStageToJob映射表中,用于在该Stage全部完成时做一些后续处理,如报告状态,清理Job相关数据等。

     

    具体提交一个Stage时,首先判断该Stage所依赖的父Stage的结果是否可用,如果所有父Stage的结果都可用,则提交该Stage,如果有任何一个父Stage的结果不可用,则迭代尝试提交父Stage 所有迭代过程中由于所依赖Stage的结果不可用而没有提交成功的Stage都被放到waitingStages列表中等待将来被提交

     

    什么时候waitingStages中的Stage会被重新提交呢,当一个属于中间过程Stage的任务(这种类型的任务所对应的类为ShuffleMapTask)完成以后,DAGScheduler会检查对应的Stage的所有任务是否都完成了,如果是都完成了,则DAGScheduler将重新扫描一次waitingStages中的所有Stage,检查他们是否还有任何依赖的Stage没有完成,如果没有就可以提交该Stage

     

    此外每当完成一次DAGScheduler的事件循环以后,也会触发一次从等待和失败列表中扫描并提交就绪Stage的调用过程

     

    任务集的提交

     

    每个Stage的提交,最终是转换成一个TaskSet任务集的提交,DAGScheduler通过TaskScheduler接口提交TaskSet,这个TaskSet最终会触发TaskScheduler构建一个TaskSetManager的实例来管理这个TaskSet的生命周期,对于DAGScheduler来说提交Stage的工作到此就完成了。而TaskScheduler的具体实现则会在得到计算资源的时候,进一步通过TaskSetManager调度具体的Task到对应的Executor节点上进行运算

     

    任务作业完成状态的监控

     

    要保证相互依赖的job/stage能够得到顺利的调度执行,DAGScheduler就必然需要监控当前Job / Stage乃至Task的完成情况。这是通过对外(主要是对TaskScheduler)暴露一系列的回调函数来实现的,对于TaskScheduler来说,这些回调函数主要包括任务的开始结束失败,任务集的失败,DAGScheduler根据这些Task的生命周期信息进一步维护JobStage的状态信息。

     

    此外TaskScheduler还可以通过回调函数通知DAGScheduler具体的Executor的生命状态,如果某一个Executor崩溃了,或者由于任何原因与Driver失去联系了,则对应的StageshuffleMapTask的输出结果也将被标志为不可用,这也将导致对应Stage状态的变更,进而影响相关Job的状态,再进一步可能触发对应Stage的重新提交来重新计算获取相关的数据。

     

    任务结果的获取

     

    一个具体的任务在Executor中执行完毕以后,其结果需要以某种形式返回给DAGScheduler,根据任务类型的不同,任务的结果的返回方式也不同

     

    对于FinalStage所对应的任务(对应的类为ResultTask)返回给DAGScheduler的是运算结果本身,而对于ShuffleMapTask,返回给DAGScheduler的是一个MapStatus对象,MapStatus对象管理了ShuffleMapTask的运算输出结果在BlockManager里的相关存储信息,而非结果本身,这些存储位置信息将作为下一个Stage的任务的获取输入数据的依据

     

    而根据任务结果的大小的不同,ResultTask返回的结果又分为两类,如果结果足够小,则直接放在DirectTaskResult对象内,如果超过特定尺寸(默认约10MB)则在Executor端会将DirectTaskResult先序列化,再把序列化的结果作为一个Block存放在BlockManager里,而后将BlockManager返回的BlockID放在IndirectTaskResult对象中返回给TaskSchedulerTaskScheduler进而调用TaskResultGetterIndirectTaskResult中的BlockID取出并通过BlockManager最终取得对应的DirectTaskResult。当然从DAGScheduler的角度来说,这些过程对它来说是透明的,它所获得的都是任务的实际运算结果。

     

     

    TaskSetManager

     

    前面提到DAGScheduler负责将一组任务提交给TaskScheduler以后,这组任务的调度工作对它来说就算完成了,接下来这组任务内部的调度逻辑,则是由TaskSetManager来完成的。

     

    TaskSetManager的主要接口包括:

     

    ResourceOffer根据TaskScheduler所提供的单个Resource资源包括hostexecutorlocality的要求返回一个合适的TaskTaskSetManager内部会根据上一个任务成功提交的时间,自动调整自身的Locality匹配策略,如果上一次成功提交任务的时间间隔很长,则降低对Locality的要求(例如从最差要求Process Local降低为最差要求Node Local),反之则提高对Locality的要求。这一动态调整Locality策略基本可以理解为是为了提高任务在最佳Locality的情况下得到运行的机会,因为Resource资源可能是在短期内分批提供给TaskSetManager的,动态调整Locality门槛有助于改善整体的Locality分布情况。

     

    举个例子,如果TaskSetManager内部有a/b两个任务等待调度,a/b两个任务Prefer的节点分别是Host A  Host B 这时候先有一个Host C的资源以最差匹配为Rack Local的形式提供给TaskSetManager,如果没有内部动态Locality调整机制,那么比如a任务将被调度。接下来在很短的时间间隔内,一个Host A的资源来到,同样的b任务被调度。 而原本最佳的情况应该是任务b调度给Host C 而任务a调度给Host A

     

    当然动态Locality也会带来一定的调度延迟,因此如何设置合适的调整策略也是需要针对实际情况来确定的。目前可以设置参数包括

    spark.locality.wait.process

    spark.locality.wait.node

    spark.locality.wait.rack

     

    即各个Locality级别中TaskSetManager等待分配下一个任务的时间,如果距离上一次成功分配资源的时间间隔超过对应的参数值,则降低匹配要求(即process -> node -> rack -> any) 而每当成功分配一个任务时,则重置时间间隔,并更新Locality级别为当前成功分配的任务的Locality级别

     

     

    handleSuccessfulTask / handleFailedTask /handleTaskGettingResult :用于更新任务的运行状态,Taskset Manager在这些函数中除了更新自身维护的任务状态列表等信息,用于剩余的任务的调度以外,也会进一步调用DAGScheduler的函数接口将结果通知给它。

     

    此外,TaskSetManager在调度任务时还可能进一步考虑Speculation的情况,亦即当某个任务的运行时间超过其它任务的运行完成时间的一个特定比例值时,该任务可能被重复调度。目的当然是为了防止某个运行中的Task由于某些特殊原因(例如所在节点CPU负载过高,IO带宽被占等等)运行特别缓慢拖延了整个Stage的完成时间,Speculation同样需要根据集群和作业的实际情况合理配置,否则可能反而降低集群性能。

     

     

    Pool 调度池

     

    前面我们说了,DAGScheduler负责构建具有依赖关系的任务集,TaskSetManager负责在具体的任务集的内部调度任务,而TaskScheduler负责将资源提供给TaskSetManager供其作为调度任务的依据。但是每个SparkContext可能同时存在多个可运行的任务集(没有依赖关系),这些任务集之间如何调度,则是由调度池(POOL)对象来决定的,Pool所管理的对象是下一级的Pool或者TaskSetManager对象

     

    TaskSchedulerImpl在初始化过程中会根据用户设定的SchedulingMode(默认为FIFO)创建一个rootPool根调度池,之后根据具体的调度模式再进一步创建SchedulableBuilder对象,具体的SchedulableBuilder对象的BuildPools方法将在rootPool的基础上完成整个Pool的构建工作。

     

    目前的实现有两种调度模式,对应了两种类型的Pool

     

    FIFO:先进先出型,FIFO Pool直接管理的是TaskSetManager,每个TaskSetManager创建时都存储了其对应的StageIDFIFO pool最终根据StageID的顺序来调度TaskSetManager

     

    FAIR:公平调度,FAIR Pool管理的对象是下一级的POOL,或者TaskSetManager,公平调度的基本原则是根据所管理的Pool/TaskSetManager中正在运行的任务的数量来判断优先级,用户可以设置minShare最小任务数,weight任务权重来调整对应Pool里的任务集的优先程度。当采用公平调度模式时,目前所构建的调度池是两级的结构,即根调度池管理一组子调度池,子调度池进一步管理属于该调度池的TaskSetManager

     

    公平调度模式的配置通过配置文件来管理,默认使用fairscheduler.xml文件,范例参见conf目录下的模板:

     

    [html] view plaincopy

  • <?xmlversionxmlversion=“1.0”?>  

  • <allocations>  

  •   <pool name=“production”>  

  •    <schedulingMode>FAIR</schedulingMode>  

  •     <weight>1</weight>  

  •     <minShare>2</minShare>  

  •   </pool>  

  •   <pool name=“test”>  

  •    <schedulingMode>FIFO</schedulingMode>  

  •     <weight>2</weight>  

  •     <minShare>3</minShare>  

  •   </pool>  

  • </allocations>  


  •  

    由于这里的调度池是在SparkContext内部的调度,因此其调度范畴是一个基于该SparkContextSpark应用程序,正常情况下,多个Spark应用程序之间在调度池层面是没有调度优先级关系的。那么这种调度模式的应用场合是怎样的呢? 举一个例子就是SparkServer或者SharkServer,作为一个长期运行的SparkContext,他们代理运行了其它连上ServerSpark应用的任务,这样你可以为每个链接按照用户名指定一个Pool运行,从而实现用户优先级和资源分配的合理调度等。

     

    Spark应用之间的调度

     

    前面提到调度池只是在SparkContxt内部调度资源,SparkContext之间的调度关系,按照Spark不同的运行模式,就不一定归Spark所管理的了。

     

    MesosYARN模式下,底层资源调度系统的调度策略由MesosYARN所决定,只有在Standalone模式下,Spark Master按照当前cluster资源是否满足等待列表中的Spark应用 对内存和CPU资源的需求,而决定是否创建一个SparkContext对应的Driver,进而完成Spark应用的启动过程,这可以粗略近似的认为是一种粗颗粒度的有条件的FIFO策略吧

    学习spark中的关

    学习spark中的关

    原文(扫盲扫的很舒畅):http://www.searchdatabase.com.cn/showcontent_79727.htm

    一、Driver&worker

    二、RDD(即弹性分布式数据集 Resilient Distributed Dataset 

    三、DAG(http://bananalighter.blog.51cto.com/6386339/1557614

    四、扩展阅读(spark使用场景等):http://tech.ddvip.com/2013-10/1381214820203655.html

    尽管Hadoop适合大多数批处理工作负载,而且在大数据时代成为企业的首选技术,但由于以下几个限制,它对一些工作负载并不是最优选择:

    • 缺少对迭代的支持

    • 需要将中间数据存在硬盘上以保持一致性,因此会有比较高的延迟

    当然,整个Hadoop生态系统是在不断演进的,包括Map/Reduce已经证明是处理大规模海量数据的理想方式。而HDFS、HBase等在过去几年中也有了长足的进步。

    在本文中,我们将深入了解一下过去一年中“红透半边天”的技术Spark,它与Hadoop架构类似,但是在许多方面都弥补了Hadoop的不足,比如在进行批处理时更加高效,并有更低的延迟。在大数据时代,Spark给我们带了新的选择,它的前途不可限量。

    在Spark集群中,有两个重要的元素,即driver和worker。  driver 程序是应用逻辑执行的起点,而多个worker用来对数据进行并行处理。driver 程序是应用逻辑执行的起点,而多个worker用来对数据进行并行处理。尽管不是强制的,但数据通常是与worker搭配,并在集群内的同一套机器中进行分区。在执行阶段,driver程序会将code/closure传递给worker机器,同时相应分区的数据将进行处理。数据会经历转换的各个阶段,同时尽可能地保持在同一分区之内。执行结束之后,worker会将结果返回到driver程序。

     

    在集群背后,有一个非常重要的分布式数据架构,即弹性分布式数据集(Resilient Distributed Dataset ,RDD),它是逻辑集中的实体,但在集群中的多台机器上进行了分区。通过对多台机器上不同RDD联合分区的控制,就能够减少机器之间数据混合(data shuffling)。Spark提供了一个“partition-by”运算符,能够通过集群中多台机器之间对原始RDD进行数据再分配来创建一个新的RDD。

    RDD可以随意在RAM中进行缓存,因此它提供了更快速的数据访问。目前缓存的粒度在处在RDD级别,因此只能是全部RDD被缓存。在集群中有足够的内存时,Spark会根据LRU驱逐算法将RDD进行缓存。

    RDD提供了一个抽象的数据架构,我们不必担心底层数据的分布式特性,而应用逻辑可以表达为一系列转换处理。

    通常应用逻辑是以一系列TRANSFORMATION和ACTION来表达的。前者在RDD之间指定处理的相互依赖关系DAG,后者指定输出的形式。调度程序通过拓扑排序来决定DAG执行的顺序,追踪最源头的节点或者代表缓存RDD的节点。

    Spark中的依赖性主要体现为两种形式,宽与窄(Narrow dependency,Wide dependency)。Narrow dependency是指父RDD的每一个分区最多被一个子RDD的分区所用,表现为一个父RDD的分区对应于一个子RDD的分区或多个父RDD的分区对应于一个子RDD的分区,也就是说一个父RDD的一个分区不可能对应一个子RDD的多个分区。Wide dependency是指子RDD的分区依赖于父RDD的多个分区或所有分区,也就是说存在一个父RDD的一个分区对应一个子RDD的多个分区。注意Narrow dependency 的RDD可以通过相同的键进行联合分区,整个操作都可以在一台机器上进行,不会造成网络之间的数据混合。另一方面,Wide dependency的RDD就会涉及到数据混合。调度程序会检查依赖性的类型,将Narrow dependency 的RDD划到一组处理当中,即stage。Wide dependency在一个执行中会跨越连续的stage,同时需要显式指定多个子RDD的分区。

    典型的执行顺序如下:

    1. RDD直接从外部数据源创建(HDFS、本地文件等)

    2. RDD经历一系列的TRANSFORMATION( map、flatMap、filter、 groupBy、join),每一次都会产生不同的RDD,供给下一个TRANSFORMATION使用

    3. 最后一步就是ACTION(count、collect、save、take),将最后一个RDD进行转换,输出到外部数据源。

    上述一系列处理称为一个lineage,即DAG拓扑排序的结果。在lineage中生成的每个RDD都是不可变的。事实上,除非被缓存,每个RDD在进入下一个TRANSFORMATION前都只使用一次。

    在一个典型的分布式系统当中,故障恢复是由主动监控系统以及不同机器之间的数据复制来实现的。当一台机器出现故障,其他的机器上总是会有一套数据副本来进行故障恢复。

    而在Spark当中则采取了不同的方法。首先作为一个大型的集群,Spark并不应该是一个大规模数据集群。Spark针对工作负载会做出两种假设:

    • 处理时间是有限的

    • 保持数据持久性是外部数据源的职责,主要是让处理过程中的数据保持稳定

    Spark在执行期间发生数据丢失时会选择折中方案,它会重新执行之前的步骤来恢复丢失的数据。但这并不是说丢弃所有之前已经完成的工作,而重新开始再来一遍。我们只需要再执行一遍父RDD的相对应分区。

    需要知道,丢失分区的再执行其实与DAG的延迟计算一样的,它开始于DAG的叶节点,追溯父RDD需要的依赖性,然后逐渐追踪到源节点。丢失节点的重新计算其实与它非常类似,但它把分区作为额外的信息,以便决定需要哪些父RDD。

    然而,跨Wide dependency的再执行能够涉及到多个父RDD从而引发全部的再执行。为了规避这一点,Spark会保持Map阶段中间数据输出的持久,以免它们混合到不同机器上执行reduce阶段。在机器发生故障的情况下,再执行只需要回溯mapper持续输出的相应分区,来获取中间数据。Spark还提供了检查点的API,明确持久中间RDD,这样再执行就不必追溯到最开始的阶段。未来,通过在恢复的延迟以及根据统计结果的check-pointing总开销之间进行权衡,Spark会自动化地执行check-pointing。

    Spark为构建低延迟,大规模并行处理的大数据分析应用提供了强大的处理框架。它支持围绕RDD抽象的API,同时包括一套TRANSFORMATION和ACTION操作,以及针对大量流行编程语言的支持,比如Scala、Java和Python。

    来来来,个人blog第一弹——WordPress的Linux运行环境

    来来来,个人blog第一弹——WordPress的Linux运行环境

    基本上就是安装Lamp

    一、准备Linux

    这里用的centos 6.5

    二、安装Apache

    yum install httpd

    三、安装mysql+建库

    yum install mysql-server
    mysql_secure_installation
    mysqladmin -uroot password root
    mysql -uroot -proot
    mysql>create database wordpress;

    四、安装php

    yum install php5
    yum install phpmyadmin

    五、解压WordPress包

    unzip WordPress.zip /var/www/html/

    参考:http://www.cnblogs.com/xiaofengkang/archive/2011/11/16/2251608.html

    Hadoop20Federation

    Hadoop20Federation

    原文:http://www.linuxidc.com/Linux/2014-05/101179.htm

    1 概述

    Hadoop1.0的架构中,HDFS的所有的元数据都放在一个namenode中,只有一个namespace(名字空间)。这样随着HDFS的数据越来越多,单个namenode的资源使用必然会达到上限,而且namenode的负载也会越来越高,限制了HDFS的性能。

    在hadoop2.0架构中,namenode federation(联合)通过多个namenode/namespace把元数据的存储和管理分散到多个节点中,使到namenode/namespace可以通过增加机器来进行水平扩展,并且能把单个namenode的负载分散到多个节点中,在HDFS数据规模较大的时候不会也降低HDFS的性能。还有可以通过多个namespace来隔离不同类型的应用,把不同类型应用的HDFS元数据的存储和管理分派到不同的namenode中。

    2 架构

    如果上图所示,一个block pool由属于同一个namespace的数据块组成,每个namenode管理一个namespace,即每个namenode负责存储和管理一个block pool的元数据。而每个datanode是会连接所有的namenode的,为所有的block pools所共享,即每个datanode都会存储所有的block pools的数据块。每个block pool通过namespace隔离开来,对一个block pool的操作不会影响另外一个block pool。

    从配置和使用的角度来看,整个HDFS有一个唯一的clusterid,如“hellokitty”,它可以配置多个block pool/namespace(也叫name service),如“mycluster”和“yourcluster”。为了方便访问不同名字空间的目录和文件,federation还提供了一个类似linux的Client Side Mount Table的挂载机制,提供了一个统一的全局的文件系统视图(viewfs)。用户可以根据自己的需要把各个namespace挂载到一个叫做viewFS的文件系统视图的不同目录下。例如namespace/name service “mycluster”和“yourcluster”分别挂载到viewfs的“/my”和“/your”目录下,如下图所示:

    3 federation和HA

    上面提到的每个namespace/name service配置一个namenode,这样这个namespace/name service的单点问题还是存在,因此可以给每个namespace/name service配置成HA。

    假设我们有4台namenode,分别是namenode1,namenode2,namenode3,namenode4。其中namenode1和namenode2是namespace/name service“mycluster”的两个主备namenode节点,NN_ID分别是“mycluster”的“nn1”和“nn2”;而namenode3和namenode4是namespace/name service“yourcluster”的两个主备namenode节点,NN_ID分别是“yourcluster”的“nn1”和“nn2”。

    “mycluster”和“yourcluster”分别挂载在viewfs的“/my”和“/your”目录下。

    结构如下图所示:

    4 实战tips

    一般1000台机器一下的中小规模的hadoop集群,一个namespace/name service就足够了,不需要考虑federation,以免增加不必要的复杂性。

    Apache Hadoop HDFS federation官方wiki:http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/Federation.html

    扩展阅读:http://www.sizeofvoid.net/hadoop-2-0-namenode-ha-federation-practice-zh/

    Linux ftp下载目录

    Linuxftp下载目录

    一、下载文件夹

    wget ftp://hehe[:port]/upload/wordpress-3.9.2/* --ftp-user=test --ftp-password=test -r
    # tip:url一定要打开到需下载的目录,并在该目录上层用*表示全部

    二、下载多个文件

    ftp客户端登陆
    ftp 127.0.0.1
    #关掉提示(不再每个文件提示是否y)
    prompt off
    #拿到test下的各个文件
    mget ../test/*

    参考:http://yahoon.blog.51cto.com/13184/200991/