Apache Hadoop Day1

Apache Hadoop Day1

随着互联网的高速发展，其架构模式也随之发生演变：

单一架构→高并发分布式架构：单机储存→分布式储存

JavaWeb：为了应对高并发和分布式提出的是LNMP(Linux、Nginx、MySQL、PHP)思想。

分布式：

提供服务时出现跨机器，跨进程通信都统一称为分布式。

• 储存

  • 单机存储：容量限制，扩展性差，数据灾备问题
    

  • 分布式存储：使用存储的集群去实现对海量数据的并行化操作，提升系统的效率。

  • 目前针对传统业务领域的分布式文件存储方案有：文件存储，块存储
    

Hadoop

基于对海量数据进行操作时的一系列问题，Hadoop应运而生，其两大版块：

• HDFS ：Hadoop Distribute File System 分布式文件存储。
• MapReduce ：分发-->汇总，MapReduce是hadoop中通用的分布式并行计算框架。

安装Hadoop:

• 安装虚拟器并且安装CentOS-7 64位

• 安装JDK，并且配置环境变量

• tar -zxf hadoop-2.9.2.tar.gz -C /usr/

  • rpm -ivh jdk-8u191-linux-x64.rpm

  • vi .bashrc

    JAVA_HOME=/usr/java/latest
    PATH=$PATH:$JAVA_HOME/bin
    CLASSPATH=.
    export JAVA_HOME
    export PATH
    export CLASSPATH
    

  • source ~/.bashrc

  • vi /etc/hostname

  CentOS
  

  • reboot

  • ip addr

    获取IP例如：192.168.80.137
    

  • vi /etc/hosts

    192.168.80.137 CentOS
    

  • 配置SSH免密码认证:

    • ssh-keygen -t rsa -P ‘’
    • ssh-copy-id CentOS
    • ssh root@CentOS

  • firewall

    • systemctl stop firewalld.service
    • systemctl disable firewalld.service
    • firewall-cmd --state

  • cd /usr/hadoop-2.9.2/

    • vi etc/hadoop/core-site.xml

      <!--nn访问入口-->
      <property>
          <name>fs.defaultFS</name>
          <value>hdfs://CentOS:9000</value>
      </property>
      <!--hdfs工作基础目录-->
      <property>
          <name>hadoop.tmp.dir</name>
          <value>/usr/hadoop-2.9.2/hadoop-${user.name}</value>
      </property>
      

  • cd /usr/hadoop-2.9.2/

    • vi etc/hadoop/hdfs-site.xml

      <!--block副本因子-->
      <property>
          <name>dfs.replication</name>
          <value>1</value>
      </property>
      <!--配置Sencondary namenode所在物理主机-->
      <property>
          <name>dfs.namenode.secondary.http-address</name>
          <value>CentOS:50090</value>
      </property>
      

  • vi /usr/hadoop-2.9.2/etc/hadoop/slaves

    CentOS
    

  • 在第一次启动HDFS系统的时候，需要对系统做一次格式化，主要为后续的启动做准备，这里需要注意只有再第一次启动的时候才需要这么做，以后再次启动HDFS的时候可以忽略这一步骤！

    • hdfs namenode -format
    • start-dfs.sh
    • stop-dfs.sh
    • jps
    • Web:192.168.80.137:50070

HDFS架构

简介

Hadoop分布式文件系统(HDFS: Hadoop Distributed File System)指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（Distributed File System）。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。

HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。

架构

NameNode & DataNodes

HDFS是一个master/slave架构，一个HDFS的集群包含一个NameNode,该服务是主要务负责管理文件系统的Namespace和响应客户端的常规访问。另外，有很多个DataNode节点，每个DataNode负责管理存储在DataNode运行所在主机上的文件。HDFS暴露了一个文件系统Namespace以及允许将用户数据存储到文件里。HDFS底层会将文件切分成1~N个块，这些块被存储在一系列的DataNode上，NameNode负责修改Namespace的DDL操作例如：打开、关闭、修改文件或者文件夹。NameNode决定了数据块到DataNode的映射。DataNode负责响应客户端的读写请求，同时在接收到来自于NameNode的指令DataNode还要进行块的创建、删除、复制等操作。

NameNode:使用内存存储集群中的元数据（文件命名空间-文件目录结构、数据块到DataNode映射）

DataNode:负责响应客户端对数据块的读写请求，向NameNode汇报自身状态信息。

Block:是HDFS切分文件的尺度，默认是128MB，一个文件最多只有 一个不足128MB块

副本因子：HDFS为了防止DataNode宕机导致块的丢失，允许一个块又多个备份，默认备份是3

为什么HDFS不擅长存储小文件？

因为Namenode使用单机的内存存储，因此由于小文件会占用更多的内存空间，导致了Namenode内存浪费。

什么是机架感知？

分布式的集群通常包含非常多的机器，由于受到机架槽位和交换机网口的限制，通常大型的分布式集群都会跨好几个机架，由多个机架上的机器共同组成一个分布式集群。机架内的机器之间的网络速度通常都会高于跨机架机器之间的网络速度，并且机架之间机器的网络通信通常受到上层交换机间网络带宽的限制。

Hadoop在设计时考虑到数据的安全与高效，数据文件默认在HDFS上存放三份，存储策略为:

第一个block副本放在客户端所在的数据节点里（如果客户端不在集群范围内，则从整个集群中随机选择一个合适的数据节点来存放）。

第二个副本放置在与第一个副本所在节点相同机架内的其它数据节点上

第三个副本放置在不同机架的节点上

参考：https://www.cnblogs.com/zwgblog/p/7096875.html

SecondaryNameNode & NameNode

fsimage :存储在Namenode服务所在物理主机磁盘上的一个二

进制文本文件。记录了元数据信息

edits :存储在Namenode服务所在物理主机磁盘上的一个二进

制文本文件，记录了对元数据修改操作。

当第一次启动Namenode服务的时候，系统会加载fsimage和

edits文件进行合并得到最新元数据信息，并且更新fsimage和

edits，一旦服务启动成功后，在服务运行期间不再更新

fsimage，只是将操作记录在edits中。导致namenode在长期运

行之后重启导致namenode启动时间过长，还可能导致edits文

件过大。因此Hadoop HDFS引入Secondary Namenode 辅助

Namenode在运行期间完成对元数据的整理。

The NameNode stores modifications to the file system as a log appended to a native file system file, edits. When a NameNode starts up, it reads HDFS state from an image file, fsimage, and then applies edits from the edits log file. It then writes new HDFS state to the fsimage and starts normal operation with an empty edits file. Since NameNode merges fsimage and edits files only during start up, the edits log file could get very large over time on a busy cluster. Another side effect of a larger edits file is that next restart of NameNode takes longer. The secondary NameNode merges the fsimage and the edits log files periodically and keeps edits log size within a limit. It is usually run on a diwerent machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode.
The start of the checkpoint process on the secondary NameNode is controlled by two configuration parameters. dfs.namenode.checkpoint.period , set to 1 hour by default, specifies the maximum delay between two consecutive checkpoints, and dfs.namenode.checkpoint.txns , set to 1 million by default, defines the number of uncheckpointed transactions on the NameNode which will force an urgent checkpoint, even if the checkpoint period has not been reached. The secondary NameNode stores the latest checkpoint in a directory which is structured the same way as the primary NameNode’s directory. So that the check pointed image is always ready to be read by the primary NameNode if necessary.

NameNode将变动存储到文件系统时，会同步附加一个log（edits）到源文件系统中.当一个NameNode启动时，它会从一个映像文件（fsimage）读取HDFS的状态，然后从edits日志文件应用edits，而后NameNode写入新的HDFS的状态到fsimage并且会随着一个空的edits启动常规运行.只有在服务器启动这段期间内NameNode才会合并fsimage和edits,因为在一个繁忙的集群中edits日志文件的size会随着时间推移变得很大。另一个方面一个过大的edits日志文件会使得NameNode的下次重启消耗更多的时间。Secondary NameNode会定期的合并edits日志文件和fsimage同时确保edits的size在一个限制的范围内。Secondary NameNode 相比与主NameNode通常运行在不同的机器上，因为Secondary NameNode的内存要求与主NameNode的序列相同。

Secondary NameNode 的检测切入的进程的启动可以通过配置两个变量来控制：

dfs.namenode.checkpoint.period:默认1个小时一启动，具体指两个连续的检测点最大延迟是1小时

dfs.namenode.checkpoint.txns：默认处理一百万条事务时启动，当NameNode中的uncheckpointed事务的数量达到规定的量，将会强制执行一个紧急的检测点尽管还没有到检测点的检测周期。Secondary NameNode会在一个文件夹内存储一个最新版的检测点切这个文件夹的结构与NameNode的文件的结构一致。以至于当NameNode 需要时总是可以随时提供给NameNode.

dfs.namenode.checkpoint.txns：默认处理一百万条事务时启动，当NameNode中的uncheckpointed事务的数量达到规定的量，将会强制执行一个紧急的检测点尽管还没有到检测点的检测周期。Secondary NameNode会在一个文件夹内存储一个最新版的检测点且这个文件夹的结构与NameNode的文件的结构一致。以至于当NameNode 需要时总是可以随时提供给NameNode.