Hadoop的特点有哪些
Hadoop的特点有哪些发布时间：2021-12-0809:22:10来源：亿速云阅读：2132作者：iii栏目：大数据本篇内容介绍了“Hadoop的特点有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
1Hadoop简介
1.1Hadoop由来
数据容量
大数据时代数据量超级大，数据具有如下特性：
Volume(大量)
Velocity(高速)
Variety(多样)
Value(低价值密度)
以前的存储手段跟分析方法现在行不通了!Hadoop就是用来解决海量数据的存储跟海量数据的分析计算问题的，创始人DougCutting在创建 Hadoop时主要思想源头是Google三辆马车
第一辆GFS产生了HDFS。
第二辆MapReduce产生了MR。
第三辆BigTable产生了HBase。
现在说的Hadoop通常指的是Hadoop生态圈这样一个广义概念，如下：
大数据知识体系
1.2Hadoop特点
1.2.1Hadoop特点
高可用
Hadoop底层对同一个数据维护这多个复本，即使Hadoop某个计算元素或者存储出现问题，也不会导致数据的丢失。
高扩展
在集群之间分配任务数据，可以方便的扩展跟删除多个节点，比如美团节点就在3K~5k个节点
高效性
在MapReduce的思想下Hadoop是并行工作的，以加快任务的处理速度
高容错性
如果一个子任务速度过慢或者任务失败Hadoop会有响应策略会自动重试跟任务分配。
1.2.2Hadoop架构设计
Hadoop的1.x跟2.x区别挺大，2.x主要是将1.xMapReduce中资源调度的任务解耦合出来交Yarn 来管理了(接下来本文以2.7开展探索)。
1.x跟2.x变化
HDFS
HadoopDistributedFileSystem简称HDFS，是一个分布式文件系统。HDFS 有着高容错性，被设计用来部署在低廉的硬件上来提供高吞吐量的访问应用程序的数据，适合超大数据集的应用程序。
MapReduce
MapReduce是一种编程模型，包含Map(映射)跟Reduce(归约)。你可以认为是归并排序的深入化思想。
Yarn
ApacheHadoopYARN(YetAnotherResourceNegotiator，另一种资源协调者)是一种新的Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
Common组件
log组件。
独有RPC体系ipc、I/O系统、序列化、压缩。
配置文件conf。
公共方法类，比如checkSum校验。
2HDFS
产生背景：
随着数据量变大，数据在一个OS的磁盘无法存储了，需要将数据分配到多个OS管理的磁盘中，为了方面管理多个OS下的磁盘文件，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统，HDFS 是通过目录树定位文件。需注意HDFS只是分布式文件系统中的其中一种。
2.1HDFS优缺点
2.1.1优点
高容错性
数据会自动保存多个副本，默认为3个，通过增加副本来提高容错性。
某个副本丢失后系统会自动恢复。
高扩展性
HDFS集群规模是可以动态伸缩的。
适合大数据处理
数据规模达到GB/TB/PB级别。
文件规模达到百万规模以上。
流式访问，它能保证数据的一致性。
低成本，部署廉价机器提高了商业化能了。
统一对外接口，Hadoop本身用Java编写，但基于此的应用程序可以用其他语言编写调用。
2.1.1缺点
做不到低延时
Hadoop对高吞吐做了优化，牺牲了获取数据的延迟，比如毫秒级获取数据在Hadoop上做不到。
不适合存储大量小文件
存储大量小文件的话，它会占用NameNode大量的内存来存储文件、目录和块信息。因此该文件系统所能存储的文件总数受限于NameNode 的内存容量，根据经验，每个文件、目录和数据块的存储信息大约占150字节。
小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。
无法修改文件
对于上传到HDFS上的文件，不支持修改文件，仅支持追加。HDFS适合一次写入，多次读取的场景。
无法并发写入
HDFS不支持多用户同时执行写操作，即同一时间，只能有一个用户执行写操作。
2.2HDFS组成架构
2.2.1Client
客户端主要有如下功能：
文件切分，文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行存储。
与NameNode交互，获取文件的位置信息。
与DataNode交互，读取或者写入数据。
Client提供一些命令来管理HDFS，比如启动或者关闭HDFS。
Client可以通过一些命令来访问HDFS。
2.2.2NameNode
NameNode简称NN，就是HDFS中的Master，是个管理者，主要有如下功能：
管理HDFS的名称空间。
配置副本策略
处理客户端读写请求。
管理数据块(Block)映射信息。
映射信息：NameNode(文件路径，副本数，{Block1，Block2}，[Block1:[三个副本路径],Block2:[三个副本路径]])
2.2.3DataNode
DataNode简称DN就是HDFS集群中的Slave，NameNode负责下达命令，DataNode执行实际的操作。
存储实际的数据块。
执行数据块的读/写操作。
上面说过数据目录信息存储在NN中，而具体信息存储在DN中，很形象的比喻如下
NN跟DN对比
DataNode的工作机制
数据块存储在磁盘信息包括数据+数据长度+校验和+时间戳。
DataNode启动后向NameNode注册，周期性(1小时)的向NameNode上报所有的块信息。
NN跟DN之间心跳3秒一次，心跳返回结果带有NameNode给该DataNode 的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用。
集群运行中可以安全加入和退出一些机器。
DataNode确保数据完整性
当DataNode读取Block的时候，它会计算CheckSum。
如果计算后的CheckSum，与Block创建时值不一样，说明Block已经损坏。
Client读取其他DataNode上的Block。
DataNode在其文件创建后周期验证CheckSum
DN进程死亡或无法跟NN通信后NN不会立即将DN判死，一般经过十分钟+30秒再判刑。
2.2.4SecondaryNameNode
当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务。需要通过HA等手段实现自动切换。SNN主要提供如下功能：
辅助NameNode，分担其工作量。
定期合并Fsimage和Edits，并推送给NameNode。
在紧急情况下，可辅助恢复NameNode。
2.2.5Block
HDFS中的文件在物理上是分块Block存储的，在1.x版本中块=64M，2.x中块= 128M。块不是越大越好，也不是越小越好。因为用户获取数据信息时间=寻址块时间+磁盘传输时间。
块太小会增加寻址时间，程序大部分耗时在寻址上了。
快太大则会导致磁盘传输时间明显大于寻址时间，程序处理块数据时较慢。
2.3HDFS写流程
2.3.1具体写流程
写流程
客户端通过DistributedFileSystem模块向NameNode 请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
NameNode返回是否可以上传。
客户端请求第一个Block上传到哪几个DataNode服务器上。
NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
客户端通过FSDataOutputStream 模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
dn1、dn2、dn3逐级应答客户端。
客户端开始往dn1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存)，以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3;dn1每传一个packet会放入一个应答队列等待应答。
当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。(重复执行3-7步)。
2.3.2节点距离计算
在HDFS写数据的过程中，NameNode会选择距离待上传数据最近距离的DataNode接收数据。
最近距离=两个节点到达最近的共同祖先的距离总和。
节点距离计算
Distance(/d1/r1/n0,/d1/r1/n0)=0同一节点上的进程
Distance(/d1/r1/n1,/d1/r1/n2)=2同一机架上不同节点
Distance(/d1/r2/n0,/d1/r3/n2)=4同一数据中心不同机架节点
Distance(/d1/r2/n1,/d2/r4/n1)=6不同数据中心
2.3.3副本节点选择
第一个副本在Client所在节点上，如果在集群外则随机选个。
第二个副本跟第一个副本位于同机架不同节点
第三个部分位于不同机架，随机节点。
机架感知
2.4HDFS读流程
读流程
客户端通过DistributedFileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的 DataNode地址。
挑选一台DataNode(就近原则，然后随机)服务器，请求读取数据。
DataNode开始传输数据给客户端(从磁盘里面读取数据输入流，以Packet为单位来做校验)。
客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。
2.5NameNode和SecondaryNameNode
2.5.1NN和2NN工作机制
NameNode中元数据单独存到磁盘不方便读写。单独存到内存时，断电会丢失。Hadoop采用的是如下方式。
FsImage:
元数据序列化后在磁盘存储的地方。包含HDFS文件系统的所有目录跟文件inode序列化信息。
Memory：
元数据在内存中存储的地方。
Edit文件：
Edit记录客户端更新元数据信息的每一步操作(可通过Edits运算出元数据)。
一旦元数据有更新跟添加，元数据修改追加到Edits中然后修改内存中的元数据，这样一旦NameNode节点断电，通过FsImage跟Edits 的合并生成元数据。
Edits文件不要过大，系统会定期的由SecondaryNamenode完成FsImage和Edits的合并。
NN跟2NN工作机制
第一阶段：NameNode启动
第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
客户端对元数据进行增删改的请求。
NameNode记录操作日志，更新滚动日志。
NameNode在内存中对数据进行增删改。
第二阶段：SecondaryNameNode工作
SecondaryNameNode询问NameNode是否需要CheckPoint。直接带回NameNode 是否检查结果。一般下面条件任意满足即可：
CheckPoint默认1小时执行一次。
一分钟检查一次Edits文件操作次数，达阈值CheckPoint。
SecondaryNameNode请求执行CheckPoint。
NameNode滚动正在写的Edits日志。
将滚动前的编辑日志Edit_001和镜像文件FsImage拷贝到SecondaryNameNode。
SecondaryNameNode加载编辑日志和镜像文件到内存并合并。
生成新的镜像文件FsImage.chkpoint。
拷贝FsImage.chkpoint到NameNode。
NameNode将FsImage.chkpoint重新命名成FsImage。
2.6安全模式
NameNode刚启动时候系统进入安全模式(只读)，如果整个文件系统中99.9%块满足最小副本，NameNode会30秒后退出安全模式。
2.6.1NameNode启动
将FsImage文件载入内存再执行Edits文件各种操作，最终内存生成完整的元数据镜像。
创建个新的FsImage跟空Edits文件。
NameNode开始监听DataNode。
整个过程NameNode一直运行在安全模式，NameNode对于Client是只读的。
2.6.2DataNode启动
系统数据块位置不是由NameNode维护的，而是以块列表形式存储在DataNode中。
安全模式下DataNode向NameNode发送最新块列表信息，促使NameNode高效运行。
正常运行期NameNode内存中保留所有块位置映射信息。
2.7HDFS-HA
HDFS集群中NameNode存在单点故障(SPOF)，为了实现HighAvailable，其实包括HDFS-HA和YARN-HA。HDFS 可以通过配置Active/Standby两个NameNodes实现在集群中对NameNode 的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，可将NameNode很快的切换到另外一台机器。实现HA功能主要依赖ZooKeeper跟 ZKFC进程。
HA故障转移
2.7.1HDFS-HA工作要点
元数据管理方式需要改变
内存中各自保存一份元数据。
Edits日志只有Active状态的NameNode节点可以做写操作。
两个NameNode都可以读取Edits。
共享的Edits放在一个共享存储中管理(qjournal或NFS)。
需要一个状态管理功能模块
实现了一个ZKFC，常驻在每一个namenode所在的节点，每一个ZKFC负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由ZKFC来负责切换，切换时需要防止brain split现象的发生。
必须保证两个NameNode之间能够ssh无密码登录
防脑裂，同一时刻仅仅有一个NameNode对外提供服务。
2.7.2ZooKeeper
ZooKeeper提供如下功能：
故障检测：集群中每个NameNode在ZooKeeper 中维护一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。
现役NameNode选择：ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。
2.7.3ZKFC进程
在NameNode主机上有个ZKFC(ZKFailoverController)这样的ZK客户端，负责监视管理NameNode 状态。ZKFC负责：
健康监测：ZKFC周期性检测同主机下NameNode监控撞库。
ZooKeeper会话管理：NameNode健康时候ZKFC保持跟ZK集群会话打开状态，ZKFC还持有个znode锁，如果会话终止，锁节点将自动删除。
基于ZooKeeper的选择：ZKFC发现本地NameNode健康前提下会尝试获取znode锁，获得成功则Active状态。
3MapReduce
MapReduce是个分布式运算程序的编程框架，是基于Hadoop的数据分析计算核心框架。处理过程分为两个阶段：Map阶段跟Reduce 阶段。
Map负责把一个任务分解成多个任务。该阶段的MapTask并发实例，完全并行运行，互不相干。
Reduce负责把多个任务处理结果汇总。该阶段的ReduceTask并发实例互不相干，但是他们的数据依赖于上一个阶段的所有MapTask 并发实例的输出。
MapReduce编程模型只能包含一个Map阶段和一个Reduce 阶段，如果用户的业务逻辑非常复杂，那就只能多个MapReduce程序串行运行。
用户编写MR任务时候程序实现部分分成三个部分：Mapper、Reducer、Driver(提交运行mr程序的客户端)。
3.1优缺点
3.1.1优点
易于编程
简单实现了一些接口就可以完成个分布式程序，你写个分布式程序跟写个串行化程序一样，类似八股文编程。
良好的扩展
计算资源不足时可以简单的增加机器来扩展计算能力。
高容错性
MapReduce任务部署在多台机器上后如果其中一台挂了，系统会进行自动化的任务转移来保证任务正确执行。
适合PB级数据离线处理
比如美团3K个节点的集群并发，提供超大数据处理能力。
3.1.2缺点
不擅长实时计算
MapReduce不会想MySQL一样毫秒级返回结果。
不擅长流式计算
流式计算的输入数据是动态的，而MapReduce的输入数据集是静态的。
不擅长DAG计算
多个应用程序存在依赖关系，MapReduce的作业结果会落盘导致大量磁盘IO，性能贼低，此时上Spark吧!
3.2序列化
序列化
把内存中的对象，转换成字节序列(或其他数据传输协议)以便于存储(持久化)和网络传输。
反序列化
将收到字节序列(或其他数据传输协议)或者是硬盘的持久化数据，转换成内存中的对象。
因为Hadoop在集群之间进行通讯或者RPC 调用时是需要序列化的，而且要求序列化要快、且体积要小、占用带宽要小。而Java自带的序列化是重量级框架，对象序列化后会附带额外信息，比如各种校验信息，header，继承体系等。所以 Hadoop自研了序列化框架。
Java类型HadoopWritable类型booleanBooleanWritablebyteByteWritableintIntWritablefloatFloatWritablelongLongWritabledoubleDoubleWritableStringTextmapMapWritablearrayArrayWritable3.3MapTask并行度
数据块：Block是HDFS物理上把数据分成一块一块。
数据切片：数据切片只是在逻辑上对输入进行分片，并不会在磁盘上将其切分成片进行存储。
切片核心注意点：
一个Job的Map阶段并行度又客户端提交Job时的切片数决定
每个Split切片分配个MapTask并行实例处理
模型情况下切片大小=BlockSize
切片时不会考虑数据集整体大小，而是逐个针对每个文件单独切片的。
3.3.1FileInputFormat切片源码追踪
FileInputFormat切片源码追踪
程序先找到目标数据存储目录
开始遍历目录下每个文件。每个文件都会做如下操作
获取切片大小，默认情况下切片大小=blocksize
开始切片，每次切片都要判断剩余部分是否大于块的1.1倍，不大于则就划分到一个切片。
切片信息写到切片规划文件中。
切片核心过程在getSplit方法完成。
InputSplit只是记录了切片元数据信息，如起始位置、长度跟所在节点列表等。
3.3.2切片大小计算
SplitSize=Math.max(minSize,Math.min(maxSize,blockSize))
mapreduce.input.fileinputformat.split.minsize默认1
mapreduce.input.fileinputformat.split.maxsize默认Long.MAXValue
blockSize默认128M
maxsize：该参数如果比blockSize小灰导致切片变小，且就等于配置的整个参数。
minsize：该参数如果调的比blockSize大，则切片大小会比blockSize还大。
3.3.3切片举例
切片举例
3.4FileInputFormat
3.4.1实现类简介
MR任务输入文件个数各有不同，针对不同类型MR定义了一个接口跟若干实现类来读取不同的数据。
input继承关系
TextInputFormat
默认使用类，按行读取每条数据，Key是该行数据的offset，Value=行内容。
KeyValueTExtInputFormat
每行都是一条记录，被指定分隔符分割为Key跟Value，默认是 。
NLineInputFormat
该模型下每个map处理InputSplit时不再按照Block块去划分，而是按照指定的行数N来划分文件。
自定义InputFormat
基础接口，改写RecordReader，实现一次读取一个完整文件封装为KV，使用SequenceFileOutPutFormat 输出合并文件。
CombineTextInputFormat
用于小文件过多场景，逻辑上合并多个小文件个一个切片任务。较重要中
3.4.2CombineTextInputFormat
默认框架TextInputFormat 切片机制是对任务按文件规划切片，不管文件多小，都会是一个单独的切片，都会交给一个MapTask，这样如果有大量小文件，就会产生大量的MapTask，处理效率极其低下。CombineTextInputFormat 可以将多个小文件从逻辑上规划到一个切片中，这样多个小文件就可以交给一个MapTask处理。主要包含虚拟存储过程跟切片过程。
CombineTextInputFormat.setMaxInputSplitSize(job,4194304);//4m
虚拟存储过程：
文件=2*SplitSize时，以SplitSize切割一块，剩余部分若getPartition数，会多产生几个空的输出part-r-000xx。
如果1