【Hadoop】Hadoop基础概念

1. HDFS读写流程

1.1 写流程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UoRKi53o-1656234446808)(D:\Note\Hadoop\picture\hadoop写流程.png)]

  1. 客户端通过Distributed FileSystem模块向NameNode请求上传文件
  2. NameNode响应是否可以上传
  3. 客户端请求上传第一个Block到哪些DataNode服务器
  4. NameNode返回3个DataNode节点
  5. 客户端通过FSOutputStream模块请求dn1上传数据,dn1收到请求后继续调用dn2,dn2调用dn3,将通信管道建立完成。
  6. dn1,dn2,dn3逐级应答客户端
  7. 客户端开始向dn1上传第一个Block,先从磁盘读取数据放入一个本地内存缓存。以Packet为单位,dn1收到一个Packet传入到dn2,dn2传给dn3,packet在传输时会放入ack应答队列等到应答
  8. 当一个Block传输完成后,开始请求下一个Block重复3-7的步骤。

1.2 读数据

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TlzPa7hN-1656234446809)(D:\Note\Hadoop\picture\hadoop读数据.png)]

  1. 客户端通过Distributed FileSystem向NameNode请求下载文件,NameNode通过查询元数据,找到文件块所在的DataNode地址
  2. 挑选一套DataNode服务器,请求读取数据。满足就近原则,随机读取
  3. DataNode传输数据给客户端,从磁盘中读取数据输入流,以Packet为单位做校验
  4. 客户端以Packet为单位接收,现在本地缓存,写入目标文件

2.NameNode和Secondary NameNode工作机制

2.1 NameNode结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LFBeksQ1-1656234446810)(D:\Note\Hadoop\picture\NameNode结构.png)]

Fsimage

该文件是HDFS文件系统元数据的一个永久性检查点,包含HDFS文件系统的所有目录和文件iNode的序列化信息。

Edit

存放HDFS文件系统的所有更新操作的逻辑,文件系统客户端执行的所有写操作首先会记录到Edits文件中。

Seen_txid

文件保存的是一个数字,就是最后一个edits_的数字。

2.2 NameNode的元数据存储

假设元数据存储在NameNode节点的磁盘中,由于会随机访问,同时相应客户请求,会效率过低。因此,元数据需要存放在内存中,但是由于断电会造成元数据丢失,导致集群无法工作,因此需要在磁盘中备份元数据的FsImage。

而每一次元数据更新时,如果同时更新FsImage,会导致效率过低,不更新就会发生一致性问题,一旦NameNode节点断电就会产生数据丢失。引入Edits文件,只进行追加操作。当元数据有更新或者添加时,修改内存中的元数据并追加到Edits中。这样,及时NameNode节点断电,可以通过FsImage和Edits的合并,合成元数据。

如果长时间添加数据到Edits中,会导致该文件数据过大,效率过低,断电会恢复元数据的时间过长。因此,需要定期对FsImage和Edits合并,如果由NameNode节点完成此操作,又会效率过低。引入一个新的节点Secondary NameNode专门用于FsImage和Edits的合并。

2.3 NameNode工作机制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2BgFngfA-1656234446810)(D:\Note\Hadoop\picture\NameNode.jpg)]

第一阶段:NameNode启动

  1. 第一次启动NameNode格式化后,创建FsImage和Edits文件,如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
  2. 客户端对元数据进行增删改的请求
  3. NameNode记录操作日志,更新滚动日志
  4. NameNode在内存中对元数据进行增删改

第二阶段:Secondary NameNode工作

  1. Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
  2. Secondary NameNode请求执行CheckPoint
  3. NameNode滚动正在写的Edits日志
  4. 滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
  5. Secondary NameNode加载编辑日志和镜像文件到内存并合并
  6. 生成新的镜像文件fsImage.chkpoint
  7. 拷贝到fsImage.chkpoint到NameNode
  8. NameNode将fsImage.chkpoint重新命名为fsimage

3. HA NameNode如何工作?

在一个典型的HA集群中,每个NameNode是一台独立的服务器中。在任一时刻,只有一个NameNode处于active状态,另一个处于standby状态。其中active状态的NameNode负责所有客户端操作,standby状态的NameNode属于从属地位,维护数据状态,随时准备切换。

两个NameNode为了数据同步,会通过一组成为JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时,会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中变更信息,并且一直监控edit log的变化,把变化应用于自己的命名空间,standby可以确保在集群出错时,命名空间状态已经完全同步。

为了确保快速切换,standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点,所有的datanodes必须配置两个NameNode的地址,发送数据块位置信息和心跳给他们两个。

对于HA集群来说,确保同一时刻只有一个NameNode处于active状态至关重要。否则,两个NameNode的数据状态会存在分歧,可能丢失数据,或者产生错误的结果。为了保证这点,JNs必须确保同一时刻只有一个NameNode可以向自己写数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Z5R4Ru2B-1656234446811)(D:\Note\Hadoop\picture\HANameNode.png)]

ZKFC:

ZKFC即ZKFailoverController,作为独立进程存在,负责控制NameNode的主备切换,ZKFC会监控NameNode的健康状况,当发现Active NameNode出现异常时会通过Zookeeper集群进行一次主备选举,完成Active和Standby状态的切换。

HealthMonitor:

定时调用NameNode的HAServiceProtocol RPC接口,监控NameNode的健康状态并向ZKFC反馈。

ActiveStandbyElector:

接收ZKFC的选举请求,通过Zookeeper自动完成主备选举,选举完成后回调ZKFC的主备切换方法对NameNode进行Active和Standby状态的切换。

JournalNode集群:

共享存储系统,负责存储HDFS的元数据,Active NameNode和Standby NameNode通过共享存储系统实现元数据同步,在主备切换过程中,新的Active NameNode必须确保元数据同步完成才能对完提供服务。

4. DataNode工作机制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CKBiZ4vK-1656234446811)(D:\Note\Hadoop\picture\DataNode工作机制.png)]

  1. 一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
  2. DataNode启动后向NameNode注册,通过后,周期性(一小时)的向NameNode上报所有块信息。
  3. 心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令,如复制该块数据到另一台机器,或删除某个数据块,如果超过十分钟没有收到某个DataNode的心跳,则认为该节点不可用。
  4. 集群运行中可以安全加入和退出一些机器。

5. DataNode数据损坏怎么办

  1. 当DataNode读取Block的时候,她会计算CheckSum
  2. 如果计算后的CheckSum,与Block创建时值不一样,说明Block已损坏
  3. Client读取其他DataNode上的Block
  4. DataNode在其文件创建后周期验证CheckSum

6. 压缩方式怎么选择

6.1 gzip压缩

应用场景:

当每个文件压缩之后在130M以内(一个块大小内),都可以考虑用gzip压缩格式。例如,一天或者一个小时的日志压缩成一个gzip文件,运行MapReduce程序的时候通过多个gzip文件达到并发。hive程序,streaming程序和Java写的mapreduce程序万泉河文本处理一样,压缩后原来的程序不需要做任何修改。

优点:

压缩率比较高,而且压缩/解压速度比较快;hadoop本身支持,在应用中处理gzip格式的文件和直接处理文本一样;有hadoop native库;大部分linux系统都自带gzip命令,使用方便。

缺点:

不支持split

6.2 snappy压缩

应用场景:

当mapreduce作业的map输出的数据比较大的时候,作为map到reduce的中间数据压缩格式,或者作为mapreduce作业的输出和另一个mapreduce作业的输入。

优点:

高速压缩速度和合理的压缩率,支持hadoop native库

缺点:

不支持split,压缩率比gzip要低,hadoop本身不支持,需要安装;Linux系统下没有对应的命令。

6.3 lzo压缩

应用场景:

一个很大的文本文件,压缩之后还大于200M以上的可以考虑,而且单个文件越大,lzo有点越明显。

优点:

压缩/解压速度比较快,合理的压缩率,支持split,是到hadoop最流行的压缩格式,支持hadoop native库;可以在Linux系统下安装lzop命令,使用方便

缺点:

压缩率比gzip要低一些;hadoop本身不支持,需要安装;在应用中对lzo格式的文件需要做一些特殊处理,为支持split需要建立索引,还需要指定inputformat为lzo格式。

6.4 bzip2压缩

应用场景:

适合对速度要求不高,但需要较高的压缩率的使用,可以作为mapreduce作业的输出格式;或者输出之后的数据比较大,处理之后的数据需要压缩存档减少磁盘空间并且以后数据用的比较少的情况;或者对单个很大的文本文件想压缩减少存储空间,同时又需要支持split,而且兼容之前的应用程序的情况。

优点:

支持split,具有很高的压缩率,比gzip压缩率高;hadoop本身支持,但不支持native,在Linux系统下自带bzip2命令,使用方便。

7. MapReduce工作流程

7.1 MapTask

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0wi3xIVs-1656234446812)(D:\Note\Hadoop\picture\maptask.png)]

  1. read阶段:MapTask通过对用户编写的RecordReader,从输入InputSplit中解析出一个个key/value
  2. Map阶段:该节点将解析出来的key/value交给用户编写map()函数处理,并产生一系列新的key/value。
  3. Collect收集阶段:在用户编写map()函数中,当数据处理完成后,一般会调用OutputCollector.collect()输出果。在该函数内部,他会将生成的key/value分区(调用Partitioner),并写入一个环形内存缓冲区中。
  4. 溢写阶段:当环形缓冲区满后,MapReduce会将数据写到本地磁盘中,生成一个临时文件。在将数据写入到本地磁盘前,会对数据进行一次本地排序,在必要时对数据进行合并,压缩操作。
  5. Combine阶段:当所有数据处理完成后,MapReduce对所有临时文件进行一次合并,确保最终只会生成一个数据文件。

溢写详情:

步骤1:利用快速排序算法对缓存区内的数据进行排序,排序方式是,先按照分区编号Partition进行排序,然后按照key进行排序。这样,经过排序后,数据以分区为单位聚集在一起,且同一分区内所有数据按照key有序。
步骤2:按照分区编号由小到大依次将每个分区中的数据写入任务工作目录下的临时文件output/spillN.out(N表示当前溢写次数)中。如果用户设置了Combiner,则写入文件之前,对每个分区中的数据进行一次聚集操作。
步骤3:将分区数据的元信息写到内存索引数据结构SpillRecord中,其中每个分区的元信息包括在临时文件中的偏移量、压缩前数据大小和压缩后数据大小。如果当前内存索引大小超过1MB,则将内存索引写到文件output/spillN.out.index中。

7.2 ReduceTask

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZsUiFDLt-1656234446813)(D:\Note\Hadoop\picture\reduceTask.png)]

  1. copy阶段:ReduceTask从各个MapTask上远程拷贝一片数据,并针对某一片数据,如果其大小超过一定阈值,则写道磁盘上,否则直接放到内存中。
  2. Merge阶段:在远程拷贝数据的同时,ReduceTask启动两个后台线程对内存和磁盘上的文件进行合并,以防止内存使用过多或者磁盘上的文件过多。
  3. Sort阶段:按照MapReduce语义,用户编写reduce()函数输入数据是按照key进行聚集的一组数据。为了将key相同的数据聚在一起,hadoop采用了基于排序的策略。由于MapTask已经实现了对自己处理结果进行了局部排序,因此reduceTask只需要对所有数据进行一次归并排序
  4. Reduce阶段:reduce()函数将计算结果写到HDFS上。

8. Yarn工作机制(作业提交全过程)是什么

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZQNL6vLS-1656234446813)(D:\Note\Hadoop\picture\Yarn工作机制.png)]

8.1 作业提交

  1. Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业
  2. Client向RM申请一个作业ID
  3. RM给Client返回该job资源的提交路径和作业ID
  4. Client提交jar包、切片信息和配置文件到指定的资源提交路径
  5. Client提交完资源后,向RM申请运行MrAppMaster

8.2 作业初始化

  1. 当RM收到Client请求后,将该job添加到容量调度器中
  2. 某一个空闲NM领取到该job
  3. 该NM创建Container,并产生MRAPPMaster
  4. 下载Client提交的资源到本地

8.3 任务分配

  1. MrAppMaster向RM申请运行多个MapTask任务资源
  2. RM将运行MapTask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器

8.4 任务运行

  1. MR向两个接收到任务的NM发送程序启动脚本,这两个NM分别启动MapTask,MapTask对数据分区排序
  2. MrAPPMaster等到所有MapTask运行完毕后,向RM申请容器,运行ReduceTask
  3. ReduceTask向MapTask获取相应分区的数据
  4. 程序运行完毕后,MR会向RM申请注销自己

8.5 进度和状态更新

YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户

8.6 作业完成

除了向应用管理器请求作业进度外, 客户端每5秒都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和Container会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

8.7 总结

  1. 用户想yarn提交应用程序,包括ApplicationMaster程序,启动ApplicationMaster命令、用户程序等
  2. RM分配一个Container,并与对应的NodeManager通信,要求他在该Container中启动应用程序的ApplicationMaster
  3. ApplicationMaster 首先向ResourceManager 注册, 这样用户可以直接通过ResourceManage 查看应用程序的运行状态,然后它将为各个任务申请资源,并监控它的运行状态,直到运行结束,即重复步骤4~7。
  4. ApplicationMaster 采用轮询的方式通过RPC 协议向ResourceManager 申请和领取资源。
  5. 一旦ApplicationMaster 申请到资源后,便与对应的NodeManager 通信,要求它启动任务。
  6. NodeManager 为任务设置好运行环境(包括环境变量、JAR 包、二进制程序等)后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。
  7. 各个任务通过某个RPC 协议向ApplicationMaster 汇报自己的状态和进度,以让ApplicationMaster 随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务。在应用程序运行过程中,用户可随时通过RPC 向ApplicationMaster 查询应用程序的当前运行状态。
  8. 应用程序运行完成后,ApplicationMaster 向ResourceManager 注销并关闭自己。

9. Yarn调度器了解多少

9.1 FIFO

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-77g7MRft-1656234446814)(D:\Note\Hadoop\picture\FIFO.png)]

先进先出调度器。把应用按提交的顺序排成一个队列,这是一个先进先出队列,在进行资源分配的时候,先给队列中最头上的应用分配资源,等到最头上的应用需求满足之后再给下一个分配。

9.2 容量调度器

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PD0ls6Am-1656234446814)(D:\Note\Hadoop\picture\容量调度器.png)]

以队列为单位划分资源,每个队列可设定一定比例的资源最低保证和使用上限,同时,每个用户可以设定一定的资源使用上限以防止资源滥用。当一个队列的资源有剩余时,可暂时将剩余资源共享给其他队列。

特点:

  1. 可为每个队列设置资源最低保证和资源使用上限,而所有提交到该队列的应用程序共享这些资源。
  2. 如果一个队列中的资源有剩余,可以暂时共享给那些需要资源的队列,而一旦该队列有新的应用程序提交,则其他队列释放的资源会归还给该队列。
  3. 支持多用户共享集群和多应用程序同时运行。为防止单个应用程序,用户或者队列独占集群中的资源,可为其增加多重约束
  4. 每个队列有严格的ACL列表规定他的访问用户,每个用户可以指定哪些用户允许查看自己应用程序的运行状态或者控制应用程序。

9.3 公平调度器

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xRcvhqPG-1656234446815)(D:\Note\Hadoop\picture\容量调度器.png)]

为所有的应用应用“平均公平”分配资源,“公平”可以配置,称为权重,可以在分配文件中为每一个队列设置分配资源的权重,如果没有设置,默认是1

特点:

  1. 允许资源共享,当一个APP运行时,如果其他队列没有任务执行,则可以使用其他队列,当其他队列有APP需要资源时再将占用的队列释放出来,所有的APP都从资源队列中分配资源。
  2. 当队列中有任务,该队列至少获得最小资源,当队列资源使用不完时,可以给其他队列使用。
  3. 当队列不能满足最小资源时,可以从其他队列抢占。

10. HDFS小文件怎么处理

10.1 小文件弊端

每个文件都要在NameNode上建立一个索引,这个索引大小约为150byte,当小文件过多时,会产生很多索引文件,会大量占用NameNode的内存空间,另一方面索引文件过大使得索引速度变慢。

10.2 小文件解决方案

  1. Hadoop Archive或者HAR,一个高效将小文件放入HDFS块中的文件存档工具,他能够将多个小文件打包成一个HAR文件,这样在减少namenode内存的同时,仍然允许对文件进行透明的访问。
  2. Sequence file 由一系列的二进制key/value组成,如果为key小文件名,value为文件内容,则可以将大批小文件合并成一个大文件
  3. CombineFileInputFormat 用于将多个文件合并出单独的Split,另外他会考虑数据的存储位置。
  4. 开启JVM重用,一个Map运行在一个JVM上,开启重用的话,该Map在JVM上运行完毕,JVM继续运行其他Map。(mapreduce.job.jvm.numtasks) ,对于大量小文件Job,可以减少45%运行时间。

11. Shuffle及优化

11.1 Shuffl过程

Map之后,Reduce方法之前的数据处理过程。

11.2 Map阶段优化

  1. 增大环形缓冲区大小,由100M扩大到200M
  2. 增大环形缓冲区溢写的比例。由80%扩大到90%
  3. 减少对溢写文件的merge次数
  4. 不影响实际业务的前提下,采用Combiner提前合并,减少IO

11.3 Reduce阶段优化

  1. 合理设置Map和Reduce数,太少会导致Task等待,延长处理时间;太多,会导致Map、Reduce任务间竞争资源,造成处理超时等错误
  2. 设置Map和Reduce共存,调整slowstart.completedmaps参数,使Map运行到一定程度之后,Reduce也开始运行,减少Reduce的等待时间
  3. 规避使用Reduce,因为Reduce在用于连接数据集的时候会产生大量的网络消耗
  4. 增加每个Reduce去Map中拿数据的并行数
  5. 集群性能可以的前提下,增大Reduce端存储数据内存的大小

11.4 IO传输

采用数据压缩的方式,减少网络IO的时间。安装Snappy和LZOP压缩编码器。

压缩:

  1. map输入端主要考虑数据量大小和切片,支持切片的有bzip2、Lzo
  2. map输出端主要考虑速度,速度快的有snappy、Lzo
  3. reduce输出端主要看具体需求,例如作为下一个mr输入需要考虑切片,永久保存考虑压缩率比较大的gzip

11.5 参数优化

同下文

12. Hadoop解决数据倾斜方法

类似hive,spark,flink数据倾斜

1.提前在map进行combine,减少传输的数据量

在Mapper加上combiner相当于提前进行reduce,即把一个Mapper中的相同key进行了聚合,减少shuffle过程中传输的数据量,以及Reducer端的计算量。如果导致数据倾斜的key大量分布在不同的mapper的时候,这种方法就不是很有效了。

2.导致数据倾斜的key 大量分布在不同的mapper

  1. 局部聚合加全局聚合。

第一次在map阶段对那些导致了数据倾斜的key 加上1到n的随机前缀,这样本来相同的key 也会被分到多个Reducer中进行局部聚合,数量就会大大降低。

第二次mapreduce,去掉key的随机前缀,进行全局聚合。思想:二次mr,第一次将key随机散列到不同reducer进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀,按原key进行reduce处理。这个方法进行两次mapreduce,性能稍差。

  1. 增加Reducer,提升并行度。JobConf.setNumReduceTasks(int)
  2. 实现自定义分区:根据数据分布情况,自定义散列函数,将key均匀分配到不同Reducer

13. Hadoop的参数优化

资源相关参数
配置参数参数说明
mapreduce.map.memory.mb一个MapTask可使用的资源上限(单位:MB),默认为1024。如果MapTask实际使用的资源量超过该值,则会被强制杀死。
mapreduce.reduce.memory.mb一个ReduceTask可使用的资源上限(单位:MB),默认为1024。如果ReduceTask实际使用的资源量超过该值,则会被强制杀死。
mapreduce.map.cpu.vcores每个MapTask可使用的最多cpu core数目,默认值: 1
mapreduce.reduce.shuffle.parallelcopies每个ReduceTask可使用的最多cpu core数目,默认值: 1
mapreduce.reduce.shuffle.merge.percent每个Reduce去Map中取数据的并行数。默认值是5
mapreduce.reduce.shuffle.input.buffer.percentBuffer中的数据达到多少比例开始写入磁盘。默认值0.66
mapreduce.reduce.input.buffer.percentBuffer大小占Reduce可用内存的比例。默认值0.7 指定多少比例的内存用来存放Buffer中的数据,默认值是0.0
YARN
配置参数参数说明
yarn.scheduler.minimum-allocation-mb给应用程序Container分配的最小内存,默认值:1024
yarn.scheduler.maximum-allocation-mb给应用程序Container分配的最大内存,默认值:8192
yarn.scheduler.minimum-allocation-vcores每个Container申请的最小CPU核数,默认值:1
yarn.scheduler.maximum-allocation-vcores每个Container申请的最大CPU核数,默认值:32
yarn.nodemanager.resource.memory-mb给Containers分配的最大物理内存,默认值:8192
Shuffle
配置参数参数说明
mapreduce.task.io.sort.mbShuffle的环形缓冲区大小,默认100m
mapreduce.map.sort.spill.percent环形缓冲区溢出的阈值,默认80%
容错相关参数
配置参数参数说明
mapreduce.map.maxattempts每个Map Task最大重试次数,一旦重试参数超过该值,则认为Map Task运行失败,默认值:4。
mapreduce.reduce.maxattempts每个Reduce Task最大重试次数,一旦重试参数超过该值,则认为Map Task运行失败,默认值:4。
mapreduce.task.timeoutTask超时时间,经常需要设置的一个参数,该参数表达的意思为:如果一个Task在一定时间内没有任何进入,即不会读取新的数据,也没有输出数据,则认为该Task处于Block状态,可能是卡住了,也许永远会卡住,为了防止因为用户程序永远Block住不退出,则强制设置了一个该超时时间(单位毫秒),默认是600000。如果你的程序对每条输入数据的处理时间过长(比如会访问数据库,通过网络拉取数据等),建议将该参数调大。

14. 异构存储(冷热数据分离)

所谓的异构存储就是将不同需求或者冷热的数据存储到不同的介质中去,实现既能兼顾性能又能兼顾成本。

14.1 存储类型

HDFS异构存储支持如下4种类型,分别是:

  • RAM_DISK(内存镜像文件系统)
  • SSD(固态硬盘)
  • DISK(普通磁盘,HDFS默认)
  • ARCHIVE(计算能力弱而存储密度高的存储介质,一般用于归档)

以上四种自上到下,速度由快到慢,单位存储成本由高到低。

14.2 存储策略

HDFS总共支持Lazy_Persist、All_SSD、One_SSD、Hot、Warm和Cold等6种存储策略。

策略说明
Lazy_Persist1份数据存储在[RAM_DISK]即内存中,其他副本存储在DISK中
All_SSD全部数据都存储在SSD中
One_SSD一份数据存储在SSD中,其他副本存储在DISK中
Hot全部数据存储在DISK中,默认策略为Hot
Warm一份数据存储在DISK中,其他数据存储方式为ARCHIVE
Cold全部数据以ARCHIVE的方式保存

15.Hadoop不能连接网页

报错信息:

put: Call From hadoop102/192.168.202.102 to hadoop102:8020 failed on connection exception: java.net.

解决方案:

  1. 关闭hadoop集群
  2. 在hadoop目录下删除data和logs目录
  3. 格式化namenode,hdfs namenode -format
  4. 重启集群
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值