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.提高下游拉取数据的数量
