Review(5)

2024-01-01 19:20:40

5 小文件过多了什么危害如何规避？

哪里会产生小文件 ?

源数据本身有很多小文件
动态分区会产生大量小文件
reduce个数越多, 小文件越多
按分区插入数据的时候会产生大量的小文件, 文件个数 = maptask个数 * 分区数

小文件太多造成的影响 ?

从Hive的角度看，小文件会开很多map，一个map开一个JVM去执行，所以这些任务的初始化，启动，执行会浪费大量的资源，严重影响性能。
HDFS存储太多小文件, 会导致namenode元数据特别大, 占用太多内存, 制约了集群的扩展

小文件解决方法

方法一: 通过调整参数进行合并

#每个Map最大输入大小(这个值决定了合并后文件的数量)
set mapred.max.split.size=256000000;

#一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=100000000;

#一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)
set mapred.min.split.size.per.rack=100000000;

#执行Map前进行小文件合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

#===设置map输出和reduce输出进行合并的相关参数：

#设置map端输出进行合并，默认为true
set hive.merge.mapfiles = true

#设置reduce端输出进行合并，默认为false
set hive.merge.mapredfiles = true

#设置合并文件的大小
set hive.merge.size.per.task = 256*1000*1000

#当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge。
set hive.merge.smallfiles.avgsize=16000000

方法二: 针对按分区插入数据的时候产生大量的小文件的问题, 可以使用DISTRIBUTE BY rand() 将数据随机分配给Reduce，这样可以使得每个Reduce处理的数据大体一致.

# 设置每个reducer处理的大小为5个G
set hive.exec.reducers.bytes.per.reducer=5120000000;

# 使用distribute by rand()将数据随机分配给reduce, 避免出现有的文件特别大, 有的文件特别小
insert overwrite table test partition(dt)

select * from iteblog_tmp
DISTRIBUTE BY rand();

方法三: 使用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件

方法四: 使用hadoop的archive归档

#用来控制归档是否可用
set hive.archive.enabled=true;
#通知Hive在创建归档时是否可以设置父目录
set hive.archive.har.parentdir.settable=true;
#控制需要归档文件的大小
set har.partfile.size=1099511627776;

#使用以下命令进行归档
ALTER TABLE srcpart ARCHIVE PARTITION(ds='2008-04-08', hr='12');

#对已归档的分区恢复为原文件
ALTER TABLE srcpart UNARCHIVE PARTITION(ds='2008-04-08', hr='12');

#::注意，归档的分区不能够INSERT OVERWRITE，必须先unarchive

hadoop自带的三种小文件处理方案 – Hadoop Archive，Sequence file和CombineFileInputFormat.

Hadoop Archive

Hadoop Archive或者HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问。

Sequence file

sequence file由一系列的二进制key/value组成，如果为key小文件名，value为文件内容，则可以将大批小文件合并成一个大文件。

CombineFileInputFormat

它是一种新的inputformat，用于将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置。

Spark coalsce（合并分区小文件）

6 Yarn的工作流程

1.用户向Yarn的RM提交应用程序，其中包括
   ApplicationMaster程序，启动ApplicationMaster命令等
   2.RM首先为该app程序分配第一个container容器，并与对应的NM通信，要求NM在这个Container中启动应用程序的application master
   3.App master首先向Apps manager注册，这样的话，我们就可以通过web 8088，查看应用程序的运行状态，且监控它的运行状态
   4.ApplicationMaster向Resource Scheduler申请和领取资源
   5.一旦ApplicationMaster申请到资源后，便与对应的NM通信，要求它启动任务
   6.NM节点启动container容器，运行task任务
   7.各个容器的任务，通过rpc向app master汇报自己的状态和进度，以让APP master随时掌握各个任务的运行状态，从而在任务失败时重启任务。
   那么用户可以通过web界面实时查看应用的当前运行状态
   8.app运行完成后，app master向 apps manager注销并关闭

7.Yarn调度器哪几种区别 CDH动态资源池

1).FIFO:先进先出

2).Capacity：计算

3).Fair:公平（生产上使用）

（1）FIFO Scheduler

将所有的Applications放到队列中，先按照作业的优先级高低、再按照到达时间的先后，为每个app分配资源。如果第一个app需要的资源被满足了，如果还剩下了资源并且满足第二个app需要的资源，那么就为第二个app分配资源，and so on。

优点：简单，不需要配置。

缺点：不适合共享集群。如果有大的app需要很多资源，那么其他app可能会一直等待。

一个例子

上图的示例：有一个很大的job1，它先提交，并且占据了全部的资源。那么job2提交时发现没有资源了，则job2必须等待job1执行结束，才能获得资源执行。

配置

FIFO Scheduler不需要配置

（2）Capacity Scheduler

CapacityScheduler用于一个集群（集群被多个组织共享）中运行多个Application的情况，目标是最大化吞吐量和集群利用率。

CapacityScheduler允许将整个集群的资源分成多个部分，每个组织使用其中的一部分，即每个组织有一个专门的队列，每个组织的队列还可以进一步划分成层次结构（Hierarchical Queues），从而允许组织内部的不同用户组的使用。
每个队列内部，按照FIFO的方式调度Applications。当某个队列的资源空闲时，可以将它的剩余资源共享给其他队列。

配置

CapacityScheduler的配置文件etc/hadoop/capacity-scheduler.xml

说明：root队列下面有两个队列，分别为prod（40%的容量，即使用40%的集群资源）和dev（60%的容量，最大的75% -> 说明即使prod队列空闲了，那么dev最多只能使用75%的集群资源。这样就可以保证prod中添加新的apps时马上可以使用25%的资源）。

除了队列的容量和层次，还可以指定单个用户或者应用被分配的资源大小、同时可以运行的app数量、队列的ACLs。

可以指定app要放在哪个队列中。如果不指定，app将会被放在名字是 default的队列中。

CapacityScheduler的队列名字必须是层次结构最后的名字，比如eng。不能是root.dev.eng或者dev.eng。

（3）Fair Scheduler　

FairScheduler允许应用在一个集群中公平地共享资源。默认情况下FairScheduler的公平调度只基于内存，也可以配置成基于memory and CPU。当集群中只有一个app时，它独占集群资源。当有新的app提交时，空闲的资源被新的app使用，这样最终每个app就会得到大约相同的资源。可以为不同的app设置优先级，决定每个app占用的资源百分比。FairScheduler可以让短的作业在合理的时间内完成，而不必一直等待长作业的完成。

Fair Sharing： Scheduler将apps组织成queues，将资源在这些queues之间公平分配。默认情况下，所有的apps都加入到名字为“default“的队列中。app也可以指定要加入哪个队列中。队列内部的默认调度策略是基于内存的共享策略，也可以配置成FIFO和multi-resource with Dominant Resource Fairness

Minimum Sharing：FairScheduller提供公平共享，还允许指定minimum shares to queues，从而保证所有的用户以及Apps都能得到足够的资源。如果有的app用不了指定的minimum的资源，那么可以将超出的资源分给别的app使用。

FairScheduler默认让所有的apps都运行，但是也可以通过配置文件小智每个用户以及每个queue运行的apps的数量。这是针对一个用户一次提交hundreds of apps产生大量中间结果数据或者大量的context-switching的情况。

使用FairScheduler需要修改yarn-size.xml文件，创建allocation file，列出存在的队列和各自的 weights and capacities

prod和dev的权重也可以设置成2和3。

dev下的两个sub-queue没有指定权重，则为1:1。

在设置权重时，需要考虑default queue和用户命名的queue的权重，这些没有在xml文件中指定，但是它们的权重都是1.

队列还可以被配置minimum maximum Resources以及可以运行的最大的apps的数量

FairScheduler支持preemption（抢占），当queue占用的资源大于它应得的，那么调度器可以杀掉queue对应的containers，将yarn.scheduler.fair.preemption设置成true即可。

FairScheduler和CapacityScheduler的异同

相同：

（1）以队列划分资源

（2）设定最低保证和最大使用上限

（3）在某个队列空闲时可以将资源共享给其他队列。

不同：

（1）Fair Scheduler队列内部支持多种调度策略，包括FIFO、Fair（队列中的N个作业，每个获得该队列1 / N的资源）、DRF（Dominant Resource Fairness）（多种资源类型e.g. CPU，内存的公平资源分配策略）

（2）Fair Scheduler支持资源抢占。当队列中有新的应用提交时，系统调度器理应为它回收资源，但是考虑到共享的资源正在进行计算，所以调度器采用先等待再强制回收的策略，即等待一段时间后入股仍没有获得资源，那么从使用共享资源的队列中杀死一部分任务

（3）Fair Scheduler中有一个基于任务数量的负载均衡机制，该机制尽可能将系统中的任务分配到各个节点

（4）Fair Scheduler可以为每个队列单独设置调度策略（FIFO Fair DRF）

（5）Fair Scheduler由于可以采用Fair算法，因此可以使得小应用快速获得资源，避免了饿死的情况。

Hierarchical queues with pluggable policies

FairScheduler支持层次队列（hierarchical queues），所有队列都从root队列开始，root队列的孩子队列公平地共享可用的资源。孩子队列再把可用资源公平地分配给他们的孩子队列。apps可能只会在叶子队列被调度。此外，用户可以为每个队列设置不同的共享资源的策略，内置的队列策略包括 FifoPolicy, FairSharePolicy (default), and DominantResourceFairnessPolicy。

用户可以通过继承org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy实现自己定义的策略。