hadoop怎么保存配置文件

从安装Hadoop 单机版的配置说起

在这里配置了Hadoop的文件目录

1. 启动Hadoop 并上传文件

上传文件命令：hadoop fs -put hadoop-2.9.2.tar.gz hdfs://hdgroup01:9000/

可以看到已经上传了文件了

2. 删除本地文件

如果删除后你在浏览器刷新页面 然后还能下载 说明 肯定存在其他地方

使用命令下载也可以：hadoop fs -get hdfs://hdgroup01:9000/hadoop-2.9.2.tar.gz

3. hdfs 文件存放的位置

通过查看 安装时配置的hadoop文件目录 上传文件后的结果

这个dfs 应该见过的 就是在格式化namenode的时候 在我们配置的文件中创建了dfs 文件夹

4. 上传一个349.5M 的文件

5. 进到hadoop 本地存储文件中查看 存储格式

上传的文件为349.47M 被切分成了 三块 因为是单机版 所以都存放到了 这台主机的文件系统中

可以看到 hadoop 块大小为128M（默认） 超过128M的文件会被切成不同的块存放

总结

1. hdfs是是通过分布式集群来存储文件，为客户端提供了一个便捷的访问方式 虚拟的目录结构

2. 文件存储到hdfs集群中的时候是被切分成block的 默认为128M

3. 文件的block 存放在若干台datanode节点中

4. hdfs文件系统中的文件与真实的block之间有映射关系，由namenode管理

5. 每个block 在集群中会存储多个副本，好处是可以提高数据的可靠性，还可以提高访问的吞吐量。

文件管理软件。hadoop把本地的文件上传到虚拟机需要用的软件并不是固定的，其就是文件管理软件，虚拟机是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。

  Yarn 是 Hadoop 的资源管理系统，用于取代 MapReduce1 的资源调度，改善 MapReduce 的实现，并且有足够的通用性，可以支持其他的分布式计算模式

  一般情况下，应用不直接使用 Yarn 的API，而是通过一些分布式计算框架（MapReduce、Spark等）来间接实现资源调度管理，使用这些框架的 Yarn 应用运行在集群计算层（Yarn）和集群存储层（HDFS、HBase）上。

  Yarn 主要由两部分组成：resource manager、node manager。

  资源管理器（resource manager）管理集群上资源的使用，节点管理器（node manager）运行在集群中所有节点上且能够启动和监控容器（container）。容器用于执行特定应用程序的进程，每个容器都有资源限制（内存、CPU）。

  在 Yarn 上运行一个应用的步骤如图所示：

  在 MapReduce1中，有两类守护进程控制作业执行过程： jobtracker、tasktracker 。

  jobtracker 通过调度 tasktracker 上运行的任务来协调所有运行在系统上的作业，记录每项作业任务的整体进度情况，若有任务失败，则在另一个 tasktracker 节点上重新调度该任务。

  tasktracker 在运行任务的同时将运行进度报告发送给 job tracker。

  MapReduce1 的 jobtracker 既要负责资源管理（作业的调度分配），将任务分配给不同的 tasktracker；又要负责任务进度的监控。如果集群非常繁忙，每时每刻都有大量的作业，每个作业下又有很多任务，jobtracker 需要面面俱到了解每个任务的执行情况，负担很重。

  在 MapReduce2 对 Yarn 的应用中，一般是会先让 RM 启动容器运行一个 Application Master 的进程，然后该进程负责创建和监控所有的 map task 和 reduce task，了解每个 task 的执行进度，每个 task 都会运行在一个单独的 container 中，这些 container 都是 Application Master 统一调度负责向 RM 申请的，这样就把资源分配和作业运行调度监控解耦，让 Yarn 专注于资源调度。

  FIFO 调度器将应用放置在一个队列中，然后按照提交的顺序（先入先出）运行应用。

【优点】简单易懂，不需要任何配置。

【缺点】不适合共享集群。大的应用会占用集群的所有资源，每个应用必须等待直到轮到自己运行，作业平均等待时间较长。

  为了避免小作业被大作业阻塞，容量调度器会创建几个队列，其中会有专门队列给小作业执行，保证一提交就可以启动。

  每个队列都被分配了一定比例容量的资源，保证大作业不会占用整个集群的所有资源。一般每个队列对应一个组织，这样就允许了多个组织共享一个 Hadoop 集群，每个组织可以分配到集群资源的一部分。队列可以进一步按层次划分，这样每个组织内的不同用户能够共享该组织队列所分配的资源。

  在一个队列内，使用 FIFO 调度策略对应用进行调度，但是一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job。

  官方文档： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html 。

  容量调度器是 Hadoop2.7 默认的调度器，在 yarn-site.xml 中通过以下参数配置：

   "d性队列" ：如果队列 queue 资源不够用了，而其他队列可能是有空闲可用的资源，那么容量调度器可能会将空余的资源分配给队列 queue 中的队列，这种特性称为 "d性队列"。可以通过 yarn.scheduler.capacity.<queue-path>.maximum-capacity 参数来控制队列最大占用集群资源容量的比例。

  示例：

  在 root 队列下定义两个队列：prod、dev。分别占用集群 40%、60% 的容量。

  prod 没有设置最大容量限制，所以当 dev 队列空闲，prod 资源不足时，可能会占用整个集群 100% 的资源。

  dev 队列设置了最大容量显示为 75%，也就是及时另外 25% 的资源空闲，dev 最大也只能占用整个集群 75% 的资源。dev 队列下还有子队列 eng、science，容量都是 dev 容量的 50%，没有为子队列设置最大容量，所以每个子队列最大都可能占用 dev 队列 100% 的资源，所以占用的整个集群的绝对资源大小为 30%~75%。

  将上述示例的配置添加到 hadoop 配置文件目录下的 capacity-scheduler.xml 中，启动 Yarn，上控制台（ http://192.168.190.111:8088/cluster/scheduler ）可以看到配置的队列容量限制。

  查看配置的每个队列的容量限制是否生效。

  可以看到 prod 队列容量限制是 40%，最大容量限制不设置则默认为 100%。

  dev 的两个子队列，占用 dev 队列的相对容量大小为 50%~100%，占用整个集群的绝对容量大小为 30%~100%。

  默认的容量调度器配置

  公平调度器就是在队列内，所有的作业平等地分配资源，如果队列中只有一个作业，可以占用 100% 的资源；此时进来一个新的作业，则会调度到每个作业占用 50% 的资源，以此类推。

  公平调度器不仅实现了队列内部的公平，还实现了队列之间的公平。

  现在有两个队列 A、B。当 A 执行第一个作业，而 B 没有作业时，A可以占用整个集群的资源；当 A 作业还没完成，B 执行一个作业，则经过一段时间之后，两个作业各占用集群一半的资源；当 B 启动第二个作业时，队列内部的两个队列共享队列 B 的资源，经过一段时间，各占用集群 1/4 的资源，A 继续占用一半的集群资源。最终结果就是资源在用户之间实现了公平共享。

  官方文档： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/FairScheduler.html 。

  启用公平调度器，在 yarn-site.xml 中添加以下配置：

  创建公平调度配置文件 fair-scheduler.xml，内容如下：

  公平调度器使用一个规则列表来确定应用应该放到哪个队列，可配置的值和含义如下：

  将上述的配置配置好，启用 Yarn，web console 上看到的调度器如下：

---