目录
2、将文件放入? hdfs的 ? ?/input? 目录下?
1、关于? /etc/profile? 与? .bash_profile? ?与? .bashrc
一、修改hadoop pid 文件的位置
1、查看目前pid文件存储位置
root下查看 /tmp文件
现将其修改至 用户下的的 tmp文件夹
2、修改配置文件，修改pid文件存储位置
[peizk@hadoop hadoop]$ vim hadoop-env.sh
添加如下内容
3、重新启动集群
查看pid文件是否移动至家目录下的tmp文件
二、配置YARN
1、修改配置文件mapred-site.xml
修改如下 在 中添加
<name>mapreduce.framework.name</name>
<value>yarn</value>
2、修改配置文件 yarn-site.xml
修改如下 在 中添加
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
3、启动 YARN
三、运行YARN例子
1、创建一个input.txt文件
2、将文件放入 hdfs的 /input 目录下
3、运行官网实例
[peizk@hadoop hadoop-3.1.3]$ hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /input/input.txt /output
4、web端查看 hdfs
5、查看一下产生文件内容
实例运行成功
四、一些思考题
1、关于 /etc/profile 与 .bash_profile 与 .bashrc
首先 .bash_profile 文件内 内容为
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH
即 .bash_profile 就是调用 .bashrc 文件
所以就是区分 .bashrc 与 /etc/profile
/etc/profile 是全局变量
.bashrc 是用户变量
当用户变量配置时 优先取用用户变量 否则采用全局变量
2、启动YARN出现如下错误解决方法
3、如何避免小文件过多
（1）小文件定义
小文件是指文件大小明显小于 HDFS 上块（block）大小（默认64MB，在Hadoop2.x中默认为128MB）的文件。
（2）HDFS的小文件问题
**1）**HDFS 中任何一个文件，目录或者数据块在 NameNode 节点内存中均以一个对象形式表示（元数据），而这受到 NameNode 物理内存容量的限制。每个元数据对象约占 150 byte，所以如果有1千万个小文件，每个文件占用一个block，则 NameNode 大约需要2G空间。如果存储1亿个文件，则 NameNode 需要20G空间，这毫无疑问1亿个小文件是不可取的。
**２）**处理小文件并非 Hadoop 的设计目标，HDFS 的设计目标是流式访问大数据集（TB级别）。因而，在 HDFS 中存储大量小文件是很低效的。访问大量小文件经常会导致大量的 seek，以及不断的在 DatanNde 间跳跃去检索小文件。这不是一个很有效的访问模式，严重影响性能。
**３）**处理大量小文件速度远远小于处理同等大小的大文件的速度。每一个小文件要占用一个slot，而任务启动将耗费大量时间甚至大部分时间都耗费在启动任务和释放任务上。
（3）MapReduce上的小文件问题
Map任务一般一次只处理一个块的输入（input。如果文件非常小，并且有很多，那么每一个 Map 任务都仅仅处理非常小的输入数据，并会产生大量的 Map 任务，每一个 Map 任务都会额外增加bookkeeping 开销。
（3） 为什么会产生大量的小文件
至少在两种场景下会产生大量的小文件:
**１）**这些小文件都是一个大逻辑文件的一部分。由于 HDFS 在2.x版本才开始支持对文件进行追加，所以在此之前保存无边界文件（例如日志文件）一种常用的方式就是将这些数据以块的形式写入HDFS中。
**２）**文件本身就是很小。比如对于一个很大的图片语料库，每一个图片都是一个单独的文件，并且没有一种很好的方法来将这些文件合并为一个大的文件。
（4）解决方案
这两种情况需要有不同的解决方式：
**１）**对于第一种情况，文件是许多记录组成的，那么可以通过调用 HDFS 的 sync() 方法(和 append 方法结合使用)，每隔一定时间生成一个大文件。或者，可以通过写一个 MapReduce 程序来来合并这些小文件。
**２）**对于第二种情况，就需要容器通过某种方式来对这些文件进行分组。Hadoop提供了一些选择：
①使用HAR File。Hadoop Archives （HAR files）是在 0.18.0 版本中引入到 HDFS 中的，它的出现就是为了缓解大量小文件消耗 NameNode 内存的问题。HAR 文件是通过在 HDFS 上构建一个分层文件系统来工作。HAR 文件通过 hadoop archive 命令来创建，而这个命令实际上是运行 MapReduce 作业来将小文件打包成少量的 HDFS 文件。对于客户端来说，使用 HAR 文件系统没有任何的变化：所有原始文件都可见以及可以访问（只是使用 har://URL，而不是 hdfs://URL），但是在 HDFS 中中文件个数却减少了。
②使用SequenceFile存储。文件名作为 key，文件内容作为 value。在实践中这种方式非常有效。比如对于10,000个100KB大小的小文件问题，可以编写一个程序将合并为一个 SequenceFile，然后你可以以流式方式处理（直接处理或使用 MapReduce） SequenceFile。
③使用HBase。如果你产生很多小文件，根据访问模式的不同，应该进行不同类型的存储。HBase 将数据存储在 Map Files（带索引的 SequenceFile）中，如果你需要随机访问来执行 MapReduce 流式分析，这是一个不错的选择。
扫一扫
750
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
