yarn调度器:
1.FIFO调度器:先进先出,并行度为1
2.容量调度器:先进先出:并行度为队列的个数
3.公平调度器:多队列;每个队列内部按照缺额大小分配资源启动任务,同一时间队列中有多个任务执行。
队列的并行度大于等于队列的个数。
Lzo压缩:
hadoop默认不支持Lao压缩,需要添加Jar包并在cores-site.xml中添加相关压缩配置
Hadoop参数调优
1 在hdfs中配置夺目录
2.namenode有一个工作线程池用来处理并发的心跳和元数据操作
dfs.namenode.handler.count=20 * log2(Cluster Size)
3.日志文件存储路径和文件讯处路径要分开
4.服务器节点上YARN可使用的物理内存总量,默认是8192(MB)【8G】
5.单个任务最多可以申请的节点物理内存量为8G yarn.scheduler.maximum-allocation-mb
另外:搭建完集群后需要对HDFS的读写性能和MR的计算能力进行测试
假如Hadoop宕机:
1.如果是MR造成的宕机:此时需要YARN控制mr的任务数,(调大参数,单个任务可以申请的最大的内存量为8G)
2.如果是写入文件过量造成的namenode宕机;可以调大Kafka的存储大小(kafka可以作为缓冲区减小Hadoop的压力达到削锋的目的)
Zookeeper:
选举机制:半数机制(所以个数为奇数)
常用命令:ls,get,create、
Flume:
Flume组成:Put事务,Take事务、
source-----channel----sink
Taildir Source:支持断点续存需要配置多目录
FileChannel:数据存储在磁盘,宕机可以保存数据;效率慢(适用于对数据可靠性的金融行业)
Mermory Channel:数据存储在内存中,宕机数据丢失,传输熟读快;(普通的日志数据);
Kafka Channel :减少了Flume的Sink阶段,提高了传输效率。(下游必须是Kafka);
Source到Channel是Put事务
Channel到Sink是Take事务
Flume:拦截器
ETL拦截器和区分类型的拦截器
a.实现Interceptor
b 重写四个方法:
初始化:initialize()
单个event()
处理多个event
close()
c.静态内部类
Flume选择器:
Replicating Channel Selector(default):
会将source过来的events发往所有的channel
multiplexing Channel Selector:
可以选择发往那些Channel
Flume:监控器 Ganglia
Flume 采集数据会丢失吗? 不会,Channel存储可以存储在File中,数据传输自身有事务
Flume 内存:
开发中在Flume-env.sh 中设置JVM heap为4G 或者更高,最好部署在单独的服务器上
-Xmx和Xms设置最好一致,减少内存抖动带来的性能影响
Flume Cnannel优化:
1.通过配置DataDirs指向多个路径,每个路径对用不同的磁盘,增大Flume的吞吐量
2.checkpointDir和backupCheckPointDir尽量设置在不同硬盘对应目录中
保证checkpoint坏掉后,可以通过chackupCkeckpointDir恢复数据
hdfs–sink小文件:
小文件过多,会占用服务器大量的内存,影响Namenode性能和使用寿命
计算层面:每一个小文件都需要一个MR进行计算,非常影响计算性能
小文件优化:
hdfs.rollinterval
hdfs.rollSize
hdfs.rollCount
效果是:文件在达到128m时候会滚动生成正式文件
Kafka总价::
kafka压测:一般是网络IO存在瓶颈
Kafka机器数:2*(峰值速度副本数/100)+1
日志保存天数:7
保存的数据量7=硬盘的大小
监控:Kafka Manager或者Kafka monitor
分区数:
一般来说分布不要超过集群的个数(分区数越多占用的内存越大)
一般设置3-10个
副本数:一般遵循三副本原则
Kafka会不会丢数据:
ack=0:异步发送
ack=1:leader收到接收请求才会增加offset,然后继续生产
ack=-1:leader收到所有的请求才会增加offeset,然后继续生产
ISR:副本同步队列
Kafka的分区策略:
Range(default):对同一个topic是按照序号进行排序
RoundRobin:
数据量计算:1000条/秒
Kafka挂掉:
Flume里有记录
日至有记录
短期没事
Kafka消息数据有积压,消费能力不足?
1.增加Topic的分区数
2.提高下游拉取数据的数量