大数据工程师面试题(三)

2.22. hadoop框架中怎么来优化
 从应用程序角度进行优化。由于mapreduce是迭代逐行解析数据文件的，怎样在迭代的情况下，编写高效率的应用程序，是一种优化思路。
 对Hadoop参数进行调优。当前hadoop系统有190多个配置参数，怎样调整这些参数，使hadoop作业运行尽可能的快，也是一种优化思路。
 从系统实现角度进行优化。这种优化难度是最大的，它是从hadoop实现机制角度，发现当前Hadoop设计和实现上的缺点，然后进行源码级
地修改。该方法虽难度大，但往往效果明显。
 linux内核参数调整
2.22.1. 从应用程序角度进行优化
（1） 避免不必要的reduce任务
如果mapreduce程序中reduce是不必要的，那么我们可以在map中处理数据, Reducer设置为0。这样避免了多余的reduce任务。
（2） 为job添加一个Combiner
为job添加一个combiner可以大大减少shuffle阶段从map task拷贝给远程reduce task的数据量。一般而言，combiner与reducer相同。
（3） 根据处理数据特征使用最适合和简洁的Writable类型
Text对象使用起来很方便，但它在由数值转换到文本或是由UTF8字符串转换到文本时都是低效的，且会消耗大量的CPU时间。当处理那些非
文本的数据时，可以使用二进制的Writable类型，如IntWritable， FloatWritable等。二进制writable好处：避免文件转换的消耗；
使map task中间结果占用更少的空间。
（4） 重用Writable类型
很多MapReduce用户常犯的一个错误是，在一个map/reduce方法中为每个输出都创建Writable对象。例如，你的Wordcout mapper方法可能
这样写：
public void map(...) {
  …
    for (String word : words) {
        (new Text(word), new IntWritable(1));
    }
}
这样会导致程序分配出成千上万个短周期的对象。Java垃圾收集器就要为此做很多的工作。更有效的写法是：
class MyMapper … {
    Text wordText = new Text();
    IntWritable one = new IntWritable(1);
 
    public void map(...) {
        for (String word: words) {
            (word);
            (wordText, one);
        }
    }
}
（5） 使用StringBuffer而不是String
当需要对字符串进行操作时，使用StringBuffer而不是String，String是read-only的，如果对它进行修改，会产生临时对象，
而StringBuffer是可修改的，不会产生临时对象。
2.22.2.  对参数进行调优
查看linux的服务，可以关闭不必要的服务
ntsysv
停止打印服务
#/etc//cups stop
#chkconfig cups off
关闭ipv6
#vim /etc/
添加内容
alias net-pf-10 off
alias ipv6 off
调整文件最大打开数
查看： ulimit -a    结果：open files (-n) 1024
临时修改： ulimit -n 4096
持久修改：
vi /etc/security/在文件最后加上：
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
修改linux内核参数
vi /etc/
添加
= 32768
#web应用中listen函数的backlog默认会给我们内核参数的限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，
所以有必要调整这个值。
调整swap分区什么时候使用：
查看：cat /proc/sys/vm/swappiness
设置：vi /etc/ 
            在这个文档的最后加上这样一行: =10
            表示物理内存使用到90%（100-10=90）的时候才使用swap交换区
关闭noatime
vi /etc/fstab
/dev/sda2    /data     ext3  noatime,nodiratime  0 0
设置readahead buffer
blockdev --setra READAHEAD 512 /dev/sda
以下是修改文件
修改最大槽位数
槽位数是在各个tasktracker上的上设置的，默认都是2
<property>
    <name></name>  
    <!--maptask的最大数-->
    <value>2</value>  
</property>                  
<property>  
    <name></name>     
    <!--reducetask的最大数-->
    <value>2</value>  
</property>
调整心跳间隔
集群规模小于300时，心跳间隔为300毫秒
 心跳时间
 集群每增加多少节点，时间增加下面的值
集群每增加上面的个数，心跳增多少
启动带外心跳
 默认是false
配置多块磁盘

配置RPC hander数目
默认是10，可以改成50，根据机器的能力
配置HTTP线程数目
 默认是40，可以改成100 根据机器的能力
选择合适的压缩方式
以snappy为例：
<property>  
    <name></name>
    <value>true</value>  
</property>                  
<property>  
    <name></name>
    <value></value>  
</property>
启用推测执行机制
推测执行(Speculative Execution)是指在分布式集群环境下，因为程序BUG，负载不均衡或者资源分布不均等原因，造成同一个job的多个
task运行速度不一致，有的task运行速度明显慢于其他task（比如：一个job的某个task进度只有10%，而其他所有task已经运行完毕），
则这些task拖慢了作业的整体执行进度，为了避免这种情况发生，Hadoop会为该task启动备份任务，让该speculative task与原始task同时
处理一份数据，哪个先运行完，则将谁的结果作为最终结果。
推测执行优化机制采用了典型的以空间换时间的优化策略，它同时启动多个相同task（备份任务）处理相同的数据块，哪个完成的早，则采用哪个task的结果，这样可防止拖后腿Task任务出现，进而提高作业计算速度，但是，这样却会占用更多的资源，在集群资源紧缺的情况下，设计合理的推测执行机制可在多用少量资源情况下，减少大作业的计算时间。
 默认是true
 默认是true
设置是失败容忍度
  作业允许失败的map最大比例  默认值0，即0%
 作业允许失败的reduce最大比例  默认值0，即0%
 失败后最多重新尝试的次数 默认是4
 失败后最多重新尝试的次数 默认是4
启动jvm重用功能
 默认值1，表示只能启动一个task，若为-1，表示可以最多运行数不限制
设置任务超时时间
 默认值600000毫秒，也就是10分钟。
合理的控制reduce的启动时间
 默认值0.05  表示map任务完成5%时，开始启动reduce任务
跳过坏记录
当任务失败次数达到该值时，才会进入skip mode，即启用跳过坏记录数功能,也就是先试几次，不行就跳过
默认值 2
map最多允许跳过的记录数
默认值0，为不启用
reduce最多允许跳过的记录数
默认值0，为不启用
换记录存放的目录
 默认值${}/_logs/