Hadoop详细的理论基础

1）HDFS基于流式数据，为处理超大型文件（PB级别）的需求而设计。

2）流式数据：

将数据序列化为字节流来存储，这样不会破坏文件的结构和内容。字节数据可以分片或者分块切分出来，更方便传输和存储。另外当超大规模的文件本身就已经超越了单台服务器的存储窖，需要多台服务器同时存储，就要将文件序列化为字节的序列，然后按照字节的顺序进行切分后分布式地均匀存储在各个服务器上。

3）若要将一个大的文件进行切分，该文件必须支持序列化，若要存储在文件系统中，该文件系统必须是流式数据访问模式。

4）HDFS将大规模的数据以分布式的方式均匀存储在集群中的各个服务器上，然后分布式并行计算框架MapReduce就可以利用各个服务器的本地计算资源在本地服务器上对大规模数据集的一个子集数据进行计算。

1）处理超大文件

      PB级别（1PB=1024T）

2）处理非结构化数据

      ①构化类型：关系型

      ②结构化类型：word、ppt、xmind等

      ③结构化类型：视频、图片、音频等

3）流式数据访问模式

     ①一次写入，多次读

     ②写入后，不允许修改
        因为这些数据是用来建模。在集群中是允许多用户访问的，集群是用来处理超大规模的数据，而且数据做了副本，这个时候修改数据，需要一次性修改多个副本的数据，对超大规模的数据修改会加锁，加锁后别人就不能用了，这样HDFS的性能就会急剧下降。HDFS已经去掉了数据修改的功能。

4）运行于廉价的商用机器集群

5）发生故障时能继续运行且不被用户察觉

      在分布式集群中，各个节点都承担了数据的存储任务，HDFS分布集群通过数据冗余的方式，将同一份数据的多个副本存储在多个节点上，这样避免了当某一节点的机器突然宕机时数据不完整而造成客户端访问中断的情况发生。

1）不适合处理低延迟数据访问
    ① 当数据体量超过传统数据库RDBMS所能够存储的极限时，就不再对数据进行简单的CRUD操作，而是通过对这些海量数据的分析，挖掘其商业价值
    ② HDFS对低延迟访问的需求量很小，而对数据处理吞吐量要求很高。若要在海量数据的分析上实现低延迟，HBase更合适，低延迟数据访问推荐使用关系型数据库Oracle，MySQL等

2）无法高效存储大量小型文件

     ①大量的小型文件会给HDFS扩展性和访问处理性能带来严重问题，可以通过SequenceFile，MapFile等方式归并文件来解决这个问题。

     ②小文件和大文件在文件元数据信息上的差别很小，大量的小文件会占用NanemNode内存，导致NameNode处理性能降低，且会制约HDFS的扩展性。

3）不支持多用户写入及任意修改同一个文件

     ①HDFS中同一根文件只对应一个写入者，且只能追加操作，不支持多用户对同一文件的写操作，及在文件任意位置进行修改

     ②多用户对同一文件的操作，涉及到多线程安全问题。要解决此问题，会造成文件系统处理性能上的损失

     ③另外，因为HDFS的数据冗余涉及，当对文件任意一个位置进行修改，那么备份的数据也要一起修改，如此HDFS的开销会很大，不利于对文件数据的访问和处理。

     ④从业务的角度来说，一个PB级别的文件，如果只修改了几行数据，对最后分析的结果影响很小。

1）可扩展性及可配置性
    集群在不重启的情况下，能够自动识别配置进来的新服务器

2）跨平台性
    HDFS是java开发的

3）shell命令行接口

4）WEB界面
    内置两个web系统（HDFS，Mapreduce）

二、HDFS核心设计 1.数据块

1）文件系统都有自己的数据设计

2） 64M（Hadoop 1.x）—>128M（Hadoop 2.x）
    ①不能远小于64M
        a.减少硬盘寻道时间。HDFS设计是为了大数据操作，数据块大小太小，使用文件时拼接文件需要根据管道寻找数据块的时间更长，从而降低了效率
        b.减少namenode内存消耗。nn中记录着dn中的数据块信息，如果数据块大小太小需要维护的数据块信息会增多，会加大nn内存消耗
    ②不能远大于64M（主要是从MapReduce并行运算框架来找原因）
        a.Map崩溃问题。系统重启时，需要重新加载数据，数据块越大，数据加载时间越长
        b.监管时间问题。主节点监管其他节点的情况，每个节点会周期性的与主节点进行汇报通信。倘若某一个节点保持沉默的时间超过一个预设的时间间隔，主节点会记录这个节点状态为死亡，并将该节点的数据转发给别的节点。而这个“预设时间间隔”是从数据块的角度大致估算的，数据块大小过大，会导致“预设时间间隔”难以估计
        c.问题分解。数据量的大小与问题解决的复杂度呈线性关系。对于同一个算法，处理的数据量越大，时间复杂度越高
        d.约束Map输出。 在Map Reduce框架里，Map之后的数据是要经过排序才执行Reduce操作的。这通常涉及到归并排序，而归并排序的算法思想便是“对小文件进行排序，然后将小文件归并成大文件”，因此“小文件”不宜过大

3）当小于一个数据块的大小的文件存储进来时不会占据整个数据块的空间

4）查询某一个文件所占用块数及相关的数据信息可以通过操作命令的方式
    hadoop  fsck  /xxxx  -files  -locatons  -blocks

5）数据块抽象设计带来的好处
    ①在企业生产实际环境中，一个文件的大小可以大于网络集群中任意一个节点磁盘的容量。因为文件数据以数据块形式分布式存储
    ②使用块抽象而不是文件，简化了存储子系统。在集群网络环境中，只需要考虑文件被切分后的数据块存储就可以了，对集群中任意一个节点上文件数据的存储就就变得更易操作。
    ③数据块非常适合用于数据的备份，从而提高数据的容错能力。当数据丢失时，可以以块为单位找回，而不涉及文件整体。当要使用一个文件时，只需要将这个文件对应的块进行临时的拼接即可。

2.数据块复制

1）默认复制系数为3，可以通过hdfs-site.xml来修改

dfs.replication 3

2）数据块大小：64M（Hadoop 1.x）/128M（Hadoop 2.x）

3.数据块副本的存放策略

1）以副本数为3为例，第1个副本放置在客户端所在的datanode节点（如果客户端不在集群内，则第一个副本随机选放在datanode上，但原则仍是选取距离客户端近的datanode），第2个副本放置在与第1个节点不同机架的任意datanode上，第3个副本放置在与第1个副本所在节点同一机架的另一个datanode上，还有更多的副本，就随机放

2）这可优先保证本机架下对该数据块所属文件的访问，如果此机架发生故障，也可在另外的机架上找到该数据块的副本

  4.机架感知

1）整个数据块副本存放的实现过程称为机架感知。默认是关闭的

2）如果集群中的机器都跑在一个机架上，那么我们上面都不用做，集群下的节点默认都是在“/default-rack”下的，可以启动hadoop集群的时候查看logs/namenode.log

3）查看机架感知   

hdfs dfsadmin -printTopology

 4）机架感知配置

环境：Centos7，Hadoop2.5.2（/usr/local/hadoop252）
    ①编写脚本rackaware.sh
        进入 /usr/local/hadoop252/etc/hadoop（路径根据自己的实际情况和自己意愿修改）创建文件夹rackaware

mkdir rackaware # 创建目录rackaware #创建并编写脚本rackaware.sh #!bin/sh while [ $# -gt 0 ] ; do nodeArg=$1 exec< /usr/local/hadoop271/etc/hadoop/rackaware/topology.data result="" while read line ; do ar=( $line ) if [ "${ar[0]}" = "$nodeArg" ] ; then result="${ar[1]}" fi done #销毁当前第一个变量，变量个数减一 shift #判断字符串长度是否为0 if [ -z "$result" ] ; then echo -n "/default/rack " else echo -n "$result " fi done #注意修改脚本权限 chmod a+x rackaware.sh #注意 a表示所有用户 g表示组用户 o表示其他用户 x表示执行权限

    ②编写配置文件topology.data

        进入/usr/local/hadoop252/etc/hadoop创建配置文件topolog.data

192.168.76.200 /dc1/rack1 192.168.76.201 /dc1/rack2 192.168.76.202 /dc1/rack2 192.168.76.203 /dc1/rack3

    ③测试

sh rackaware.sh 192.168.1.201

    ④启用机架感知：core-site.xml中加入

topology.script.file.name /usr/local/hadoop252/etc/hadoop/rackaware/rackaware.sh

这个topology.script.file.name是一个可执行脚本，它接收一个参数，输出一个值

参数：是某台datanode的ip地址
输出：该ip对应的datanode所在的机架

这个shell脚本的编写，需要将真实的网络拓扑和机架信息了解清楚后，通过这个脚本将机器的ip地址正确地映射到相应的机架
      ⑤测试

hdfs dfsadmin -printTopology   5.数据块的备份数

1）修改 hdfs-site.xml

2）命令修改

hadoop fs -setrep -R 3 / 6.安全模式

1）操作

#1.退出安全模式 hadoop dfsadmin -safemode leave #2.进入安全模式 hadoop dfsadmin -safemode enter #3.查看安全模式状态 hadoop dfsadmin -safemode get #4.等待，直到安全模式结束 hadoop dfsadmin -safemode wait

2）安全模式指在不加载第三方设备驱动情况下启动机器，便于检测与修复

3）应用场景
    ①启动或者重启hdfs时；②HDFS维护升级时

4）对hdfs文件系统进行检查       hadoop fsck

7.负载均衡

1）DataNode分组

   在第2步中，HDFS会把当前的DataNode节点，根据阈值的设定情况划分到Over、Above、Below、Under四个组中。在移动数据块的时候，Over组、Above组中的块向Below组、Under组移动。四个组定义如下：   

   ①Over  组：此组中的DataNode均满足
        DataNode_usedSpace_percent > Cluster_usedSpace_percent + threshold
    ②Above组：此组中的DataNode均满足
         Cluster_usedSpace_percent + threshold > DataNode_ usedSpace _percent > Cluster_usedSpace_percent
    ③Below组：此组中的DataNode均满足
        Cluster_usedSpace_percent > DataNode_ usedSpace_percent > Cluster_ usedSpace_percent – threshold
    ④Under组：此组中的DataNode均满足
        Cluster_usedSpace_percent – threshold > DataNode_usedSpace_percent

2）HDFS数据自动平衡脚本使用方法

start-balancer.sh -threshold #启动负载均衡 -threshold 默认设置：10，参数取值范围：0-100 参数含义：判断集群是否平衡的阈值。理论上，该参数设置的越小，整个集群就越平衡 stop-balancer.sh #关闭

3）在hdfs-site.xml文件中可以设置数据均衡占用的网络宽带限制

dfs.balance.bandwidthPerSec 1048576 dfs.balance.bandwidthPerSec 默认设置：1048576（1M/S） 参数含义：Balancer运行时允许占用的宽带

4）Hadoop集群不怕数据量大，怕数据倾斜

8.心跳机制

1）主节点和从节点之间的通信是通过心跳机制（心跳实际上是一个RPC函数，RPC远程过程调用）实现的

2）心跳机制
    ①master启动的时候，会开启一个RPC server
    ②slave启动时进行连接master，并每隔3秒钟主动向master发送一个“心跳”将自己的状态信息告诉master，然后master通过这个心跳的返回值，向slave节点传达指令

3）HDFS
   ① DataNode—>NameNode        

         3s      本地磁盘上block块的使用情况    

        1h     block的report
    ②当长时间没有发送心跳时，NameNode就判断DataNode的连接已经中断，不能继续工作了，就把它定性为“deadnode”。NameNode会检查dead node中的副本数据，复制到其他的data node中。

4）YARN
    ①NodeManager—>ResourceManager    

       3s      本节点上cpu内存
    ②ApplicationMaster—>ResourceManager    

       申请资源，返还资源

5）MapReduce
    ①TaskTracker—>JobTracker

     汇报节点和任务运行状态信息：
        1、判断Tasktracker是否活着
        2、及时让JobTracker获取各个节点上的资源使用情况和任务运行状态
        3、为TaskTracker分配任务

注意：
        JobTracker与TaskTracker之间采用了Pull（拉）而不是Push（推）模型
        JobTracker不会主动向TaskTracker发送任何信息，而是由TaskTracker主动通过心跳领取属于自己的信息
        JobTracker只能通过心跳应答的形式为各个TaskTracker分配任务
        TaskTracker周期性的调用RPC函数heartbeat向JobTracker汇报信息和领取任务

三、HDFS体系结构 1.主从架构

不管什么时候都只有一台namenode，其他作为从节点

2.核心组件功能

1）namenode
    ①维护文件系统树
    ②保存元数据
    ③负责管理数据块副本，按一定周期（3s），接受来自每个DataNode的心跳信号和块状态报告。心跳用户判断datanode是否正常，块状态报告则关于某个datanode上存储的所有数据块的列表
    ④查看namenode中的数据
        到 /opt/hadoopdata 上
            官网上的配置是配在/tmp/hadoopdata上，但因为tmp目录每次重启都会清空，所以不建议配在这上面。个人习惯配在/opt/hadoopdata上

yum -y install tree tree -L 6

    ⑤fsimage：对元数据定期进行镜像操作，形成镜像文件
    ⑥edits：一定时间内对HDFS的操作
    ⑦随着时间的推移，edits会越来越多，当达到阈值时，一般为64M或者3600s就会触发检查点，这里secondarynamenode起作用，secondarynamenode完成同步元数据功能，辅助namenode对fsimage和edits进行合并，即冷备份

2）datanode
    ①以数据的形式存储HDFS文件
    ②响应HDFS客户端读写请求
    ③周期性的向namenode汇报心跳信息、数据块信息、缓存数据块信息

3）secondarynamenode

帮助namenode合并edits log和fsimage

    
    流程
        1、当触发检查点时，即edits达到64M或者3600s时，nn先复制一份edits，更名为edits.new

        2、然后再将fsimage和edits复制一份到snn，再将edits.new更名为edits

        3、然后secondarynamenode将复制过来的fsimage和edits合并成一个新的fsimage.ckpt

        4、然后再从secondarynamenode将fsimage.ckpt复制一份到namenode

        5、覆盖掉之前的fsimage

3.数据块损坏处理

DataNode还有一个自检的功能，数据块创建3周后，自动触发校验和运算（checksum算法），以保证集群中数据块的安全

作者：shenming98

理论基础 hadoop