Hadoop基础知识点汇总简易版

学好hadoop不是一朝一夕的事情此文档简略仅适用于初入门做了解使用，若想深入学习请使用《hadoop权威指南》

hadoop模块：

Hadoop Common：支持其他Hadoop模块的常用实用程序。

Hadoop分布式文件系统（HDFS™）：一种分布式文件系统，可提供对应用程序数据的高吞吐量访问。

Hadoop YARN：作业调度和集群资源管理的框架。

Hadoop MapReduce：基于YARN的系统，用于并行处理大型数据集。（一种计算框架）

Hadoop Ozone： Hadoop的对象存储。（后来新增）

 

三种运行模式：

本地（独立）模式：

Hadoop配置为以非分布式模式运行，作为单个Java进程。这对调试很有用

伪分布式模式： 

Hadoop还可以在伪分布式模式下在单节点上运行，其中每个Hadoop守护程序在单独的Java进程中运行

在一台机器上运行hdfs文件系统，运行mr程序，从hdfs上获取数据，结果存放到hdfs上

完全分布式模式：

运行在多台机器上，同时只有一个hdfs系统

10.12

hdfs体系结构（主、/从结构）

图参照官方文档

 

 

namenode：维护命名空间、保存元数据和用户对hdfs的操作、副本数等

管理文件系统命名空间的主服务器,和管理客户端对文件的访问组成,块到DataNode的映射

datanode:   存放实际数据（块）

连接到它们运行的节点的存储

提供来自文件系统客户端的读写请求

执行块的创建，删除

secondarynamenode：辅助namenode进行工作（检查点保存）

hdfs的设计理念

硬件故障是常态而非例外。HDFS实例可能包含数百或数千台服务器计算机，每台计算机都存储文件系统数据的一部分。事实上，存在大量组件并且每个组件具有非平凡的故障概率意味着HDFS的某些组件始终不起作用。

因此，检测故障并从中快速自动恢复是HDFS的核心架构目标。

 

在HDFS上运行的应用程序需要对其数据集进行流式访问。

它们不是通常在通用文件系统上运行的通用应用程序。HDFS设计用于批处理而不是用户的交互式使用。

重点是数据访问的高吞吐量而不是数据访问的低延迟。

POSIX强加了许多针对HDFS的应用程序不需要的硬性要求。

交易几个关键领域的POSIX语义以提高数据吞吐率。

 

在HDFS上运行的应用程序具有大型数据集。HDFS中的典型文件大小为千兆字节到太字节。

因此，HDFS被调整为支持大文件。它应该提供高聚合数据带宽并扩展到单个集群中的数百个节点。

它应该在单个实例中支持数千万个文件。

 

HDFS应用程序需要一个一次写入多次读取的文件访问模型。

除了追加和截断之外，无需更改创建，写入和关闭的文件。支持将内容附加到文件末尾，但无法在任意点更新。该假设简化了数据一致性问题并实现了高吞吐量数据访问。

MapReduce应用程序或Web爬虫应用程序完全适合此模型。

 

应用程序请求的计算如果在其操作的数据附近执行则更有效。

当数据集的大小很大时尤其如此。这可以最大限度地减少网络拥塞并提高系统的整体吞吐量。

假设通常更好的是将计算迁移到更靠近数据所在的位置，而不是将数据移动到运行应用程序的位置。

HDFS为应用程序提供了接口，使其自身更靠近数据所在的位置。

数据块

存储在hdfs中的最小单位

默认大小128M

这么大的原因：

为了最小化寻址开销，一般寻址时间为10ms，传输速率为100MB/s

为了寻址时间占传输时间的1%，所以。。。。

10.13

元数据：

查看fsimage

整个文件系统命名空间（包括块到文件和文件系统属性的映射）

hdfs oiv -i 要查看的文件名 -o输出的文件名 -p XML

查看edites

文件系统元数据发生的每个更改

hdfs oev -i 要查看的文件名 -o输出的文件名

 

namenode启动过程

加载fsimage

加载edites

进行检查点保存

等待datanode汇报块信息

 

datanode启动后

扫描本地块的信息

汇报给namenode

 

心跳机制

datanode每隔三秒汇报给namenode

 

检查点（运行时主要由secondarynamenode完成）

它从磁盘读取FsImage和EditLog，将EditLog中的所有事务应用到FsImage的内存中表示，并将此新版本刷新为磁盘上的新FsImage。然后它可以截断旧的EditLog，因为它的事务已应用于持久性FsImage

 

 

10.15

机架感知：

检查两台机器是否在同一机架上

NameNode通过Hadoop Rack Awareness中概述的过程确定每个DataNode所属的机架ID 。

一个简单但非最优的策略是将复制品放在独特的机架上。这可以防止在整个机架发生故障时丢失数据，并允许在读取数据时使用来自多个机架的带宽。此策略在群集中均匀分布副本，这样可以轻松平衡组件故障的负载。但是，此策略会增加写入成本，因为写入需要将块传输到多个机架。

 

副本存放策略：

基于机架感知

当复制因子为3时，HDFS的放置策略是在编写器位于datanode上时将一个副本放在本地计算机上，否则放在随机datanode上，另一个副本放在另一个（远程）机架上的节点上，

最后一个在同一个远程机架的不同节点上。此策略可以减少机架间写入流量，从而提高写入性能。

机架故障的可能性远小于节点故障的可能性; 此策略不会影响数据可靠性和可用性保证。

但是，它确实减少了读取数据时使用的聚合网络带宽，因为块只放在两个唯一的机架而不是三个。

使用此策略时，文件的副本不会均匀分布在机架上。三分之一的副本位于一个节点上，

三分之一的副本位于一个机架上的其他节点，另外三分之一均匀分布在剩余的机架上。此策略可提高写入性能，而不会影响数据可靠性或读取性能。

网络带宽 22

大型HDFS实例在通常分布在许多机架上的计算机群集上运行。不同机架中两个节点之间的通信必须通过交换机。

在大多数情况下，同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。

 

数据磁盘故障：

心跳和重新复制

每个DataNode定期向NameNode发送Heartbeat消息。网络分区可能导致DataNode的子集失去与NameNode的连接。

NameNode通过缺少Heartbeat消息来检测此情况。NameNode将DataNodes标记为没有最近的Heartbeats，并且不会将任何新的IO请求转发给它们。注册到死DataNode的任何数据都不再可用于HDFS。

DataNode死亡可能导致某些块的复制因子低于其指定值。NameNode不断跟踪需要复制的块，并在必要时启动复制。由于许多原因可能会出现重新复制的必要性：DataNode可