hadoop笔记

最新推荐文章于 2023-08-03 17:07:33 发布

java老菜鸟

最新推荐文章于 2023-08-03 17:07:33 发布

阅读量1.1k

点赞数 3

分类专栏： hadoop 文章标签： hadoop java

hadoop 专栏收录该内容

1 篇文章

订阅专栏

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父进程发送方错误信息，错误信息也会写入到日志