Hadoop Linux环境介绍以及hadoop环境搭建基础使用API 编程之开发

课程环境介绍：

课程录制的系统的事Mac,所以采用linux客户端是mac自带的shell

如果你们是win：xshell crt 客户端都可以

服务器/linux地址：192.168.1.233

连接到Linux环境

登陆：ssh hadoop@192.168.1.233

登陆成功后：[hadoop@hadoop000 ~]$

linux机器：用户名hadoop 密码：123456 hadoopname是hadoop000

创建课程中所需要的目录（适合的文件存放在合适的目录）

mkdir software 存放课程所用的软件安装包目录

mkdir app 存放课程所有软件的安装目录

mkdir data 存放课程中使用的数据

mkdir lib 存放课程中开发过的作业jar存放的目录

mkdir shell 存放课程中相关的脚本

mkdir maven_resp 存放课程中使用到的maven依赖包存放的目录

 

切换hadoop用户到root用户：sudo -i

切换root用户到hadoop用户：su hadoop

本环境中创建的hadoop用户是有sudo权限的所以你只要在执行需要root用户权限的操作是加上sudo就行，例如sudo vi /etc/host

本课程使用centos7 uname -a 查看系统版本信息

最好增加下主机 ip地址和主机名的映射关系，192.168.1.233 hadoop000 文件 /etc/hosts 文件

 

Hadoop环境搭建

使用的Hadoop相关版本：CDH

CDH相关软件下载地址：http://archive.cloudera.com/cdh5/cdh/5/

Hadoop使用版本:hadoop-2.6.0-cdh5.15.1

Hadoop下载：wget hhttp://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.15.1/

Hive使用的版本：hive-1.1.0-cdh5.15.1

 

 

Hadoop/Hive/Spark相关框架的学习：

前期使用单机版足够

如果使用集群学习会导致：从入门到放弃

使用Linux/Mac学习

一定不要使用Windows来搭建Hadoop环境

所以linux基础是要会的

 

Hadoop 安装前置要求

Java 1.8+ ssh

 

安装Java

拷贝本地软件包到服务器：scp 源文件名称路径 用户名@远程主机地址：要拷贝到的地址路径

解压jdk到～/app/: tar -zxvf 解压包的文件 -C 解压后路径

把jdk配置系统环境变量中： ～/.bash_profile

export JAVA_HOME=/home/hadoop/app/jdk1.8.0_91

export PATH=$JAVA_HOME/bin:$PATH

使得配置修改生效：source .bash_profile

查看路径：echo $JAVA_HOME

验证：java -version

 

 

ssh无密码登陆部署

ls 查看目录结构 查看有没有一个.ssh的文件夹

ls -a 显示当前目录下所有文件和文件夹包括隐藏文件

ls -al 显示当前目录下所有文件和文件夹包括隐藏文件的详细信息

ssh-keygen -t rsa 一路回车

cd ~/.ssh

[hadoop@hadoop000 .ssh]$ ll

总用量 12

-rw------- 1 hadoop hadoop 1679 1月 5 09:11 id_rsa 私钥

-rw-r--r-- 1 hadoop hadoop 398 1月 5 09:11 id_rsa.pub 公钥

-rw-r--r-- 1 hadoop hadoop 185 1月 5 09:12 known_hosts

 

我们需要把公钥写到这个文件里

cat id_rsa.pub >> authorized_keys

 

改下权限

chmod 600 authorized_keys

 

Hadoop（HDFS）安装目录详情及hadoop-env配置

 

下载:wget hhttp://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.15.1/

解压：～/app ar -zxvf 解压包的文件 -C 解压后路径

hadoop软件包常见目录说明：

bin: hadoop客户端名单

etc/hadoop: hadoop 相关配置存放目录

sbin: 启动hadoop相关进程的脚本

share: 常用例子

添加HADOOP_HOME/bin到系统变量

export HADOOP_HOME=/home/hadoop/app/hadoop-2.6.0-cdh5.15.1

export PATH=$HADOOP_HOME/bin:$PATH

保存后生效：source .bash_profile

查看路径：echo $HADOOP_HOME

 

HDFS格式化以及启动

修改Hadoop配置文件

hadoop-env.sh

修改这项：export JAVA_HOME=/home/hadoop/app/jdk1.8.0_91

 

修改配置项

etc/hadoop/core-site.xml

<property> <name>fs.defaultFS</name> fs就文件系统 defaultFS就是系统默认的文件系统 <value>hdfs://192.168.1.233:8020</value> 指向的机器地址及端口号 </property>

<property> <name>hadoop.tmp.dir</name> 文件系统存放目录默认在系统临时目录下重启后会清空，所以更改下目录 <value>/home/hadoop/app/tmp</value> </property>

 

etc/hadoop/hdfs-site.xml

<property> <name>dfs.replication</name> 文件系统 副本 <value>1</value> 副本数量 单机时就一个就行 以后集群了可以修改 </property>

etc/hadoop/slaves

添加或修改主机名我们这里是 hadoop000

 

启动HDFS

第一次执行的时候一定要格式化文件系统，一定要第一次时候执行之后不用重复执行。（会删掉文件）

切换到 /home/hadoop/app/hadoop-2.6.0-cdh5.15.1/bin 目录

执行：hdfs namenode -format 来执行第一次配置的格式化，

各式完成后会在/home/hadoop/app/tmp目录下生成文件

 

启动HDFS 切换到/home/hadoop/app/hadoop-2.6.0-cdh5.15.1/sbin

执行：./start-dfs.sh

启动后查看进程：jps

验证：

[hadoop@hadoop000 sbin]$ jps

7921 Jps

7478 NameNode

7787 SecondaryNameNode

7614 DataNode

 

HDFS 常见文件之防火墙干扰

 

验证2:

在浏览器输入http:192.168.1.233:50070

 

若果页面打不开 但是jps是有的那么多数是防火墙问题 查看防火墙：sudo firewall-cmd --state 关闭防火墙：sudo systemctl stop firewalld.service

 

Live Nodes 活的节点数 Dead Nodes 死的节点数

 

Utilities ---> Browse the system 浏览系统文件

 

Hadoop停止集群以及如何单个进程启动

 

停止集群：

/home/hadoop/app/hadoop-2.6.0-cdh5.15.1/sbin 目录下 执行 ./stop-dfs.sh

 

另外注意：

start/stop-dfs.sh 与 hadoop-daemons.sh的关系

start-dfs.sh =

./hadoop-daemons.sh start namenode

./hadoop-daemons.sh start datanode

./hadoop-daemons.sh start secondarynamenode

同理：

stop-dfs.sh =

./hadoop-daemons.sh stop namenode

./hadoop-daemons.sh stop datanode

./hadoop-daemons.sh stop secondarynamenode

 

Hadoop命令行操作：

 

hadoop fs -ls / 查看dfs文件

hadoop fs -put 复制文件到dfs

hadoop fs -copyFromLocal 复制文件到dfs

hadoop fs -moveFromLocal 剪切文件到dfs

hadoop fs -cat 查看dfs文件内容

hadoop fs -text 查看dfs文件内容

hadoop fs -get 从dfs拿文件

hadoop fs -mkdir 新建文件夹

hadoop fs -mv 移动/改名

hadoop fs -getmerge 合并文件

hadoop fs -rm 删除文件

hadoop fs -rmdir 删除空的文件夹

hadoop fs -rm -r 删除有数据的文件夹

 

深渡解析Hadoop文件的存储机制扩展

put: 1file ==> 1...n block ==>存放在不同的节点上

get: 去nn上查找这个file对应的元数据信息

了解底层的存储机制这才是文门真正要学习的东西，掌握API只是毛毛雨

 

HDFS API 编程之开发环境搭建

1、在本地安装maven 对包进行统一管理

2、下载maven 安装包 https://maven.apache.org/download.cgi

3、包名 apache-maven-3.6.3-bin.tar.gz

4、解压到安装目录 tar -zxvf apache-maven-3.6.3-bin.tar.gz -C /Users/zhaoxinbo/Documents/maven/

5、设置环境变量 vim .bash_profile

增加：

#maven

export MAVEN_HOME=/Users/zhaoxinbo/Documents/maven/apache-maven-3.6.3

export PATH=$PATH:MAVEN_HOME/bin

然后保存退出 执行 source .bash_profile 保存生效

 

1、安装代码编译软件 intellij idea

2、下载 https://www.jetbrains.com/idea/download/

3、一直下一步安装完成

4、打开软件--》点击create new project

 

-->maven-->钩上create from archetype-->选择maven-archetype-quickstart

 

-->填写项目名称（name-填写hadooptrainv2 这个根据自己随意）和项目地址（Location）和 groupid（com.imooc.bigdata 一般是工件组的名称，通常是公司域）、artifactld（hadoop-train-v2 组中工件的名称，通常是项目名称）、version（1.0版本）

 

-->maven home directory(Bundled Maven 3)、User setting file(可选择自己本地安装的maven）（Override 打勾）-->Finish(完成)

 

-->创建完后会下载maven依赖包（会很长时间）下载完后会出现这个界面

 

右侧窗口打开pox.xml文件进行编辑

-->修改这段添加红色部分代码

<properties>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<maven.compiler.source>1.7</maven.compiler.source>

<maven.compiler.target>1.7</maven.compiler.target>

<!--定义Hadoop版本-->

<hadoop.version>2.6.0-cdh5.15.1</hadoop.version>

</properties>

-->增加以下两段代码

<!--引入cdh的仓库-->

<repositories>

<repository>

<id>cloudera</id>

<url>https://repository.cloudera.com/artifactory/clouders-repos</url>

</repository>

</repositories>

<!--添加Hadoop的依赖包-->

<dependencies>

<dependency>

<groupId>org.apache.hadoop</groupId>

<artifactId>hadoop-client</artifactId>

<version>${hadoop.version}</version>

</dependency>

 

》〉》---全部代码版本 除了以上那些其他的会自动生成start---《〈《

<?xml version="1.0" encoding="UTF-8"?>

 

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

 

<groupId>com.imooc.bigdata</groupId>

<artifactId>hadoop-train-v2</artifactId>

<version>1.0</version>

 

<name>hadoop-train-v2</name>

<!-- FIXME change it to the project's website -->

<url>http://www.example.com</url>

 

 

<properties>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<maven.compiler.source>1.7</maven.compiler.source>

<maven.compiler.target>1.7</maven.compiler.target>

<!--定义Hadoop版本-->

<hadoop.version>2.6.0-cdh5.15.1</hadoop.version>

</properties>

 

<!--引入cdh的仓库-->

<repositories>

<repository>

<id>cloudera</id>

<url>https://repository.cloudera.com/artifactory/cloudera-repos/</url>

</repository>

</repositories>

 

<dependencies>

<!--添加Hadoop的依赖包-->

<dependency>

<groupId>org.apache.hadoop</groupId>

<artifactId>hadoop-client</artifactId>

<version>${hadoop.version}</version>

</dependency>

 

<!--添加junit的依赖包-->

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.11</version>

<scope>test</scope>

</dependency>

</dependencies>

 

<build>

<pluginManagement><!-- lock down plugins versions to avoid using Maven defaults (may be moved to parent pom) -->

<plugins>

<!-- clean lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#clean_Lifecycle -->

<plugin>

<artifactId>maven-clean-plugin</artifactId>

<version>3.1.0</version>

</plugin>

<!-- default lifecycle, jar packaging: see https://maven.apache.org/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging -->

<plugin>

<artifactId>maven-resources-plugin</artifactId>

<version>3.0.2</version>

</plugin>

<plugin>

<artifactId>maven-compiler-plugin</artifactId>

<version>3.8.0</version>

</plugin>

<plugin>

<artifactId>maven-surefire-plugin</artifactId>

<version>2.22.1</version>

</plugin>

<plugin>

<artifactId>maven-jar-plugin</artifactId>

<version>3.0.2</version>

</plugin>

<plugin>

<artifactId>maven-install-plugin</artifactId>

<version>2.5.2</version>

</plugin>

<plugin>

<artifactId>maven-deploy-plugin</artifactId>

<version>2.8.2</version>

</plugin>

<!-- site lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#site_Lifecycle -->

<plugin>

<artifactId>maven-site-plugin</artifactId>

<version>3.7.1</version>

</plugin>

<plugin>

<artifactId>maven-project-info-reports-plugin</artifactId>

<version>3.0.0</version>

</plugin>

</plugins>

</pluginManagement>

</build>

</project>

》〉》---全部代码版本 除了以上那些其他的会自动生成end---《〈《

 

-->View-->Tool Windows-->Mave-->刷新-->包下载好后会出现--Lifecycle\Plugins\Dependencies文件包

 

支持的 dfs yarn mapreduce 这些包都就出现了

 

-->在项目src->test->java->新建个包用来测试开发用hadoop.hdfs

 

HDFS API 编程之第一个应用程序的开发

 

结果如下创建成功

 

HDFS API编程之jUnit封装

 

HDFS API之查看HDFS文件内容

 

HDFS API 编程之查看HDFS创建文件并写入内容

 

HDFS API编程之副本系数深度解析

 

HDFS API编程之重命名

 

HDFS API 编程之cpoyFromLocalFile

 

HDFS API 编程之带进度的上传大文件

 

HDFS API 编程之下载文件

 

HDFS API编程之列出文件下的所有内容

 

HDFS API编程之递归列出文件下的所有内容

 

HDFS API编程之查看文件块信息

 

HDFS API编程之删除文件

 

HDFS 项目实战之需求分析

 

综合性的HDFS实战：使用HDFS JAVA API才完成HDFS文件系统上的文件的词频统计

词频统计：wordcount

/path/1.txt

hello world hell

 

/path/2.txt

hello world hell

 

-->(hello,4) (world,2)

将词频统计的结果输出到HDFS上去。

 

 

HDFS 项目实战之代码框架编写、HDFS项目实战之自定义上下文、HDFS项目实战之自定义处理类实现、HDFS项目实战之功能实现

 

HdfsWordCount类

 

HdfsWordCount类

 

 

HDFS项目实现战之使用自定义配置文件重构代码 （接下来是上面的代码优化）

HDFS项目实战之使用反射创建自定义Mapper对象（接下来是上面的代码优化）

HDFS项目实战之可插拔的业务逻辑（接下来是上面的代码优化）

 

更改过（HdfsWordCount、ImoocMapper、ImoocConte、WordCountMapper）新增(paramsUtils、Constants、CaselgWordCountMapper、resources-->wc.properties)

-------------------------------------------------------------------------------------------------------------

HdfsWordCount 文件优化后

 

接下来是HDFS Replica Placement Policy 副本放置策略

 

The placement of replicas is critical to HDFS reliability and performance. Optimizing replica placement distinguishes HDFS from most other distributed file systems. This is a feature that needs lots of tuning and experience. The purpose of a rack-aware replica placement policy is to improve data reliability, availability, and network bandwidth utilization. The current implementation for the replica placement policy is a first effort in this direction. The short-term goals of implementing this policy are to validate it on production systems, learn more about its behavior, and build a foundation to test and research more sophisticated policies.

 

Large HDFS instances run on a cluster of computers that commonly spread across many racks. Communication between two nodes in different racks has to go through switches. In most cases, network bandwidth between machines in the same rack is greater than network bandwidth between machines in different racks.

 

The NameNode determines the rack id each DataNode belongs to via the process outlined in Hadoop Rack Awareness. A simple but non-optimal policy is to place replicas on unique racks. This prevents losing data when an entire rack fails and allows use of bandwidth from multiple racks when reading data. This policy evenly distributes replicas in the cluster which makes it easy to balance load on component failure. However, this policy increases the cost of writes because a write needs to transfer blocks to multiple racks.

For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on the local machine if the writer is on a datanode, otherwise on a random datanode in the same rack as that of the writer, another replica on a node in a different (remote) rack, and the last on a different node in the same remote rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure; this policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without compromising data reliability or read performance.

 

If the replication factor is greater than 3, the placement of the 4th and following replicas are determined randomly while keeping the number of replicas per rack below the upper limit (which is basically (replicas - 1) / racks + 2).

 

Because the NameNode does not allow DataNodes to have multiple replicas of the same block, maximum number of replicas created is the total number of DataNodes at that time.

 

After the support for Storage Types and Storage Policies was added to HDFS, the NameNode takes the policy into account for replica placement in addition to the rack awareness described above. The NameNode chooses nodes based on rack awareness at first, then checks that the candidate node have storage required by the policy associated with the file. If the candidate node does not have the storage type, the NameNode looks for another node. If enough nodes to place replicas can not be found in the first path, the NameNode looks for nodes having fallback storage types in the second path.

 

The current, default replica placement policy described here is a work in progress.

 

概述：

副本的放置对HDFS的可靠性和性能至关重要。优化副本放置使HDFS区别于大多数其他分布式文件系统。这是一个需要大量调整和经验的特性。机架感知副本放置策略的目的是提高数据可靠性、可用性和网络带宽利用率。副本放置策略的当前实现是这方面的第一项工作。实施这一政策的短期目标是在生产系统上验证它，了解它的行为，并为测试和研究更复杂的政策打下基础。

 

大型HDFS实例运行在通常分布在许多机架上的计算机集群上。不同机架中的两个节点之间的通信必须通过交换机。在大多数情况下，同一机架中机器之间的网络带宽大于不同机架中机器之间的网络带宽。

 

NameNode通过Hadoop rack Awareness中概述的过程确定每个数据节点所属的机架id。一个简单但非最优的策略是将副本放在唯一的机架上。这可防止整个机架出现故障时丢失数据，并允许在读取数据时使用多个机架的带宽。此策略在群集中均匀分布副本，这使得在组件出现故障时轻松平衡负载。但是，此策略会增加写入成本，因为写入需要将块传输到多个机架。

 

简单的来说，就是将副本均匀的放在不同机架上，这样的好处是不管那个机架出现了问题都可轻松解决问题，但是此策略会增加写入的层本。

 

对于常见情况，当复制因子为3时，HDFS的放置策略是，如果写入程序位于数据节点上，则将一个副本放在本地计算机上，否则放在与写入程序位于同一机架中的随机数据节点上，另一个副本放在不同（远程）机架中的节点上，最后一个放在同一远程机架中的不同节点上。此策略减少机架间写入通信量，这通常会提高写入性能。机架故障的几率远小于节点故障的几率；此策略不会影响数据可靠性和可用性保证。但是，它确实减少了读取数据时使用的聚合网络带宽，因为块仅放置在两个唯一的机架中，而不是三个机架中。使用此策略，文件的副本不会均匀分布在机架上。三分之一的副本位于一个节点上，三分之二的副本位于一个机架上，另三分之一的副本均匀分布在其余机架上。此策略在不影响数据可靠性或读取性能的情况下提高写入性能。

 

如果复制因子大于3，则在将每个机架的副本数保持在上限（基本上是（副本-1）/机架+2）以下的同时，随机确定第4个和后续副本的位置。

 

因为NAMENODE不允许数据元具有同一块的多个副本，所以创建的副本的最大数量是当时的数据总数。

 

在HDFS中添加了对存储类型和存储策略的支持之后，除了上面描述的机架感知之外，NameNode还考虑了副本放置的策略。NameNode首先基于机架感知选择节点，然后检查候选节点是否具有与文件关联的策略所需的存储。如果候选节点没有存储类型，则NameNode将查找另一个节点。如果在第一个路径中找不到足够的节点来放置副本，则NameNode将在第二个路径中查找具有回退存储类型的节点。

 

此处描述的当前默认副本放置策略正在进行中。

 

HDFS写数据流程图解：

 

HDFS 读取数据流程图解

 

HDFS Checkpoint \ HDFS的元数据管理

元数据：HDFS的目录结构以及每个文件的block信息（id 副本系数 block存放在那个DN上）

存在什么地方：对应的配置的路径：${hadoop.tmp.dir}配置路径用的

元数据存放在文件中

 

一系列操作

/test1 X

/test1/a.txt X

/test2

/test2/1.txt X

/test2/2.txt

/test2/xxx

/test2/3.txt

 

hadoop fs -put xxx /test2

hadoop fs -rmr /test1

hadoop fs -mv /test2/1.txt /test2/3.txt

 

HDFS Safemode

 

On startup, the NameNode enters a special state called Safemode. Replication of data blocks does not occur when the NameNode is in the Safemode state. The NameNode receives Heartbeat and Blockreport messages from the DataNodes. A Blockreport contains the list of data blocks that a DataNode is hosting. Each block has a specified minimum number of replicas. A block is considered safely replicated when the minimum number of replicas of that data block has checked in with the NameNode. After a configurable percentage of safely replicated data blocks checks in with the NameNode (plus an additional 30 seconds), the NameNode exits the Safemode state. It then determines the list of data blocks (if any) that still have fewer than the specified number of replicas. The NameNode then replicates these blocks to other DataNodes.

 

 

在启动时，NameNode进入一个称为Safemode的特殊状态。当NameNode处于Safemode状态时，不会复制数据块。NameNode从DataNodes接收Heartbeat（心跳）和Blockreport消息。Blockreport包含数据节点托管的数据块列表。每个块都有指定的最小副本数。当数据块的最小副本数已签入NameNode时，块被认为是安全复制的。在安全复制数据块的可配置百分比与NAMENODE一起检查（加上另外30秒）之后，NAMENODEL退出SAFMODED状态。然后，它确定仍具有少于指定副本数目的数据块（如果有）的列表。然后，NameNode将这些块复制到其他数据节点。