hadoop笔记

hadooop后台进程:

    NameNode:名称节点,是hdfs的守护程序。分布式文献系统的总控作用。会记录所有元数据。比如会记录这个文件是怎样存放在节点里边的,每个文件分别存放在那个节点,在节点的哪个数据块里面;同时也会内存和IO进行集中管理,用户要访问hadoop集群一般会先访问namenode,或得文件的分部信息,查出要访问的数据节点的情况。namenode是一个单点,如果namenode崩溃,集群则会崩溃。
    管理文件系统的命名空间;        
    记录每个文件数据块的在各个datanode上的位置和副本信息;        
    协调客户端对文件的访问;       
     记录命名空间内的改动或空间本身属性的变化(权限);        
    namenode使用事务日志记录HDFS元数据的变化,使用镜像文件存储文件系统的命名空间,包括文件映射,文件属性等。

   SecondaryNode:辅助名称节点。主要作为namenode的后备。备份namenode的元数据。也是一个单点。

    DataNode:数据节点。运行在各个子节点里边。负责具体文件系统数据块的读写。
        负责他所在物理节点的存储管理;        
        一次写入,多次读取(不修改);       
        文件是由数据块组成,典型块大小为64MB;        
        数据块尽量散布在各个节点,达到冗余的效果。

    JobTracker:对map-reduce的总控作用,位于master节点。
        用于处于用户提交的作业;
        也可以决定有哪些文件参与处理然后切割task(小任务)就近运行;
        监控这些task,重启失败的task(在不同的节点)。
        每个集群只有一个jobtracker,是一个单点。

    TaskTracker:管理自己节点(slave)上的task,每个节点只有一个tasktracker,但是一个taskTracker可以启动多个JVM,并行处理map或reduce任务。也负责和JobTracker交互。
    Master:namenode,secondaryname,jobtracker ;    Master不是唯一的
    Slave:datanode,taskTracker

读取数据流程:
        客户端(集群的某一节点)------从namenode获得组成这个文件的数据块列表,根据列表查出存储数据块的datanode,访问datanode获得数据块。在这个过程namenode只是查询作用(查地图),并不参与数据块的实际运输。
    
HDFS可靠性
        冗余副本策略
                可以在hdfs-site.xml中设置复制因子指定副本数量,副本的数目可以在hdfs-site.xml中设置相应的复制因子。
                所有数据块都有副本
                Datanode启动时,遍历本地文件系统,产生一份hdfs数据块和本地文件的对应关系列表(blockreport)汇报给          namenode,namenode会与元数据对照,决定采取什么措施。
          机架策略
                集群一般放在不同机架上,机架间带宽要比机架内带宽要小(1U或2U)
                HDFS的“机架感知”
                一般在本机架存放一个副本,在其它机架再存放别的副本,这样可以防止机架失效时丢失数据,也可以提高带宽            利用率
           心跳机制
                Namenode周期性从datanode接收心跳信号和块报告
                Namenode根据块报告验证元数据
                没有按时发送心跳的datanode会被标记为宕机,不会再给它任何I/O请求
                如果datanode失效造成副本数量下降,并且低于预先设置的阈值,namenode会检测出这些数据块,并在合适的时机进行重新复制(阈值在hdfs-site.xml中设置
    1. <property>  
    2.         <name>heartbeat.recheck.interval</name>  
    3.         <value>10</value>  
    4. </property> 
                引发重新复制的原因还包括数据副本本身损坏、磁盘错误,复制因子被增大等。

                NameNode周期性向管理的各个DataNode发送心跳包,而收到心跳包的DataNode则需要回复。因为心跳包总是定时发送的,所以NameNode就把要执行的命令也通过心跳包发送给DataNode,而DataNode收到心跳包,一方面回复NameNode,另一方面就开始了与用户或者应用的数据传输。

                如果侦测到了DataNode失效,那么之前保存在这个DataNode上的数据就变成不可用的。那么,如果有的副本存储在失效的DataNode上,则需要重新创建这个副本,放到另外可用的地方。其他需要创建副本的情况包括数据块校验失败等。        

   datanode向namenode发送heartbeat过程是这样的:  
    a) 在datanode初始化获得namenode的proxy  
    b) 在datanode上,调用namenode proxy的heartbeat方法:  
        namenode.sendHeartbeat(dnRegistration,  
                                             <span style="white-space:pre">	</span>       data.getCapacity(),  
                                                       data.getDfsUsed(),  
                                                       data.getRemaining(),  
                                                       xmitsInProgress.get(),  
                                                       getXceiverCount());  
    c) 在datanode上的namenode动态代理类将这个调用包装成(或者叫“序列化成”)一个Invocation对象,并调用client.call方法  
    d) client call方法将Invocation转化为Call对象  
    e) client 将call发送到真正的namenode服务器  
    f) namenode接收后,转化成namenode端的Call,并process后,通过Responder发回来!  
    g) datanode接收结果,并将结果转化为DatanodeCommand[] 


        安全模式(一定比例在哪里设置??)
                Namenode启动时会先经过一个“安全模式”阶段
                安全模式阶段不会产生数据写
                在此阶段Namenode收集各个datanode的报告,当数据块达到最小副本数以上时,会被认为是“安全”的
                在一定比例(可设置)的数据块被确定为“安全”后,再过若干时间,安全模式结束
                当检测到副本数不足的数据块时,该块会被复制直到达到最小副本数
                    
<span style="white-space:pre">	</span>安全模式的相关属性都在文件conf/hdfs-site.xml中指定,有如下几个:
                dfs.replication.min  指定数据块要达到的最小副本数,默认为1;
                dfs.safemode.extension   指定系统退出安全模式时需要的延迟时间,默认为30(秒);
                dfs.safemode.threshold.pct 指定退出条件,需要达到最小副本数的数据块比例,1.0.3中默认是0.95

        校验和
                在文件创立时,每个数据块都产生校验和
                校验和会作为单独一个隐藏文件保存在命名空间下
                客户端获取数据时可以检查校验和是否相同,从而发现数据块是否损坏
                如果正在读取的数据块损坏,则可以继续读取其它副本
        回收站
                删除文件时,其实是放入回收站/trash
                回收站里的文件可以快速恢复
                可以设置一个时间阈值,当回收站里文件的存放时间超过这个阈值,就被彻底删除,并且释放占用的数据块
         
<span style="white-space:pre">	</span>[root@Slave01 hadoop]# vim core-site.xml
            <property> 
                <name>fs.trash.interval</name>    
                <value>1440</value>    
                <description>Number of minutes between trash checkpoints.    
                    If zero, the trash feature is disabled.
                </description>    
            </property>
        注:fs.trash.interval 的含义是文件删除后保留时长,默认为0,单位为分钟,这里设的是1天(60*24)


        元数据保护
                映像文件刚和事务日志是Namenode的核心数据。可以配置为拥有多个副本
                副本会降低Namenode的处理速度,但增加安全性
                Namenode依然是单点,如果发生故障要手工切换
        快照(0.20.2没有实现)
                支持存储某个时间点的映像,需要时可以使数据重返这个时间点的状态
                Hadoop目前还不支持快照,已经列入开发计划


Mapper
                Map-reduce的思想就是“分而治之”
                Mapper负责“分”,即把复杂的任务分解为若干个“简单的任务”执行
            “简单的任务”有几个含义:1 数据或计算规模相对于原任务要大大缩小;2 就近计算,即会被分配到存放了所需            数据的节点进行计算;3 这些小任务可以并行计算,彼此间几乎没有依赖关系
Reducer
                对map阶段的结果进行汇总
                Reducer的数目由mapred-site.xml配置文件里的项目mapred.reduce.tasks决定。缺省值为1,用户可以覆盖之
Shuffler
                在mapper和reducer中间的一个步骤(可以没有)
                可以把mapper的输出按照某种key值重新切分和组合成n份,把key值符合某种范围的输出送到特定的reducer那里去处理
               可以简化reducer过程
性能调优
                究竟需要多少个reducer?
                输入:大文件优于小文件
                减少网络传输:压缩map的输出
                优化每个节点能运行的任务数:mapred.tasktracker.map.tasks.maximum和mapred.tasktracker.reduce.tasks.maximum (缺省值均为2)
任务执行优化
        推测式执行:即如果jobtracker发现有拖后腿的任务,会再启动一个相同的备份任务,然后哪个先执行完就会kill去另外一个。因此在监控网页上经常能看到正常执行完的作业有被kill掉的任务。
        推测式执行缺省打开,但如果是代码问题,并不能解决问题,而且会使集群更慢,通过在mapred-site.xml配置文件中设置mapred.map.tasks.speculative.execution和mapred.reduce.tasks.speculative.execution可为map任务或reduce任务开启或关闭推测式执行
        重用JVM,可以省去启动新的JVM消耗的时间,在mapred-site.xml配置文件中设置mapred.job.reuse.jvm.num.tasks设置单个JVM上运行的最大任务数(1,>1或-1表示没有限制)    
        忽略模式,任务在读取数据失败2次后,会把数据位置告诉jobtracker,后者重新启动该任务并且在遇到所记录的坏数据时直接跳过(缺省关闭,用SkipBadRecord方法打开)
错误处理机制:硬件故障
        硬件故障是指jobtracker故障或tasktracker故障
        jobtracker是单点,若发生故障目前hadoop还无法处理,唯有选择最牢靠的硬件作为jobtracker
        Jobtracker通过心跳(周期1分钟)信号了解tasktracker是否发生故障或负载过于严重
        Jobtracker将从任务节点列表中移除发生故障的tasktracker
        如果故障节点在执行map任务并且尚未完成,jobtracker会要求其它节点重新执行此map任务
        如果故障节点在执行reduce任务并且尚未完成,jobtracker会要求其它节点继续执行尚未完成的reduce任务
错误处理机制:任务失败
       由于代码缺陷或进程崩溃引起任务失败
        Jvm自动退出,向tasktracker父进程发送方错误信息,错误信息也会写入到日志
        Tasktracker监听程序会发现进程退出,或进程很久没有更新信息送回,将任务标记为失败
        标记失败任务后,任务计数器减去1以便接受新任务,并通过心跳信号告诉jobtracker任务失败的信息
        Jobtrack获悉任务失败后,将把该任务重新放入调度队列,重新分配出去再执行
        如果一个任务失败超过4次(可以设置),将不会再被执行,同时作业也宣布失败








   
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值