共计 4415 个字符，预计需要花费 12 分钟才能阅读完成。
Hadoop 测试
集群搭建起来，是不是就高枕无忧了呢？如果只是用来学习或者做做试验，貌似够了，但生产环境中还不够，因为咱们还没有对集群进行测试，是不是能达到咱们预期。
1.1 写测试
测试写入 100 个 128M 的文件
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 100 -fileSize 128MB1.2. 读测试
测试读 100 个 128 的文件
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 100 -fileSize 128MB1.3 删除测试数据
测试数据必须删除，不能带到生产中
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean1.4 用 Sort 评估 MapReduce
1）应用 RandomWriter 来产生随机数，每个节点运行 10 个 Map 工作，每个 Map 产生大概 1G 大小的二进制随机数
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar randomwriter random-data2）执行 sort
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar sort random-data sorted-data3）验证后果
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar testmapredsort -sortInput random-data -sortOutput sorted-data哈哈，我的电脑不给力，没法间接演示，看来要降级了。
决定进入大数据坑的同学，电脑配置得高点，不然带不动。
2.Hadoop 性能调优
集群测试，不合乎预期，那就要进入性能调优了。
2.1 MpaReduce 的优化
MapReduce 执行效率的瓶颈在两个方面
1. 计算机性能影响，像 CPU、内存大小、磁盘、网络提早。
2.IO 方面的优化状况
1）数据歪斜问题
2）Map 和 Reduce 的个数设置状况
3）Map 耗时太长
4）小文件太多
5）Spill 和 Merge 次数太多等等
咱们对 MapReduce 的优化大抵是六个方面
1）数据输出
2）Map 阶段
3）Reduce 阶段
4）IO 传输
5）数据歪斜
6）参数调优
2.1.1 数据输出
例如合并小文件，咱们都晓得小文件会产生大量的 MapTask，所以咱们能够在执行 MR 工作前，先进行小文件的合并。
默认状况下 TextInputformat 对工作的切片机制是按文件布局切片, 不论文件多小, 都会有一个独自的切片, 都会交给一个 maptask, 如果有大量的小文件, 就会产生大量的 maptask, 解决效率及其低下
咱们能够改用 CombineTextInputFormat，解决输出端大量小文件的问题。
2.1.2 Map 阶段
1. 缩小 Spill 次数，也就是溢写次数：通过调整 io.sort.mb 及 sort.spill.percent 参数值，增大触发 Spill 的内存下限，缩小 Spill 次数，从而缩小磁盘 IO。
2. 缩小 Merge 次数：通过调整 io.sort.factor 参数，增大 Merge 的文件数目，缩小 Merge 的次数，从而缩短 MR 解决工夫。
3.Map 之后，在不影响业务逻辑前提之下，能够先进行 Combine，缩小 IO。
2.1.3 Reduce 阶段
1.Map 和 Reduce 个数的设置: 两个不能设置太少，也不能太多。
太少，会导致 Task 期待，缩短解决工夫；
太多，会导致 Map、Reduce 工作间竞争资源，造成解决超时等谬误。
2.Map、Reduce 共存: 调整 slowstart.completedmaps 参数，使 Map 运行到肯定水平后，Reduce 也开始运行，缩小 Reduce 的等待时间。
3. 躲避应用 Reduce：因为 Reduce 在用于连贯数据集的时候将会产生大量的网络耗费。
2.1.4 IO 传输
1）数据压缩
2）应用 SequenceFile 二进制文件
2.1.5 数据歪斜
什么是数据歪斜？
简略来说就是大量的雷同 key 被 partition 调配到一个分区里, 造成了 ’ 一个人累死, 其他人闲死 ’ 的状况。
解决办法：
1）自定义分区，也就是 Partition，指定分区策略
2）从新设计 key，例如在 map 阶段给 key 加一个随机值，有了随机值的 key 就不会有大概率的机会被大量分到同一个节点上了，到了 reduce 阶段，在把随机值去掉。
3）应用 Combine，Combinner 是在 map 阶段,reduce 之前的一个两头阶段, 在这个阶段能够选择性的把大量的雷同 key 数据先进行一个合并, 能够看做是 local reduce, 而后再交给 reduce 来解决, 这样做的益处很多, 即加重了 map 端向 reduce 端发送的数据量(加重了网络带宽), 也加重了 map 端和 reduce 端两头的 shuffle 阶段的数据拉取数量(本地化磁盘 IO 速率)
解决办法也不止下面所述，具体也要依据理论状况来说。
2.1.6 调优参数
1）以下参数是在用户本人的 MR 应用程序中配置就能够失效（mapred-default.xml）
| 配置参数 | 参数阐明 |
|---|---|
| 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.cpu.vcores | 每个 ReduceTask 可应用的最多 cpu core 数目，默认值: 1 |
| mapreduce.reduce.shuffle.parallelcopies | 每个 Reduce 去 Map 中取数据的并行数。默认值是 5 |
| mapreduce.reduce.shuffle.merge.percent | Buffer 中的数据达到多少比例开始写入磁盘。默认值 0.66 |
| mapreduce.reduce.shuffle.input.buffer.percent | Buffer 大小占 Reduce 可用内存的比例。默认值 0.7 |
| mapreduce.reduce.input.buffer.percent | 指定多少比例的内存用来寄存 Buffer 中的数据，默认值是 0.0 |
2）应该在 YARN 启动之前就配置在服务器的配置文件中能力失效（yarn-default.xml）
| 配置参数 | 参数阐明 |
|---|---|
| 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 |
3）Shuffle 性能优化的要害参数，应在 YARN 启动之前就配置好（mapred-default.xml）
| 配置参数 | 参数阐明 |
|---|---|
| mapreduce.task.io.sort.mb | Shuffle 的环形缓冲区大小，默认 100m |
| mapreduce.map.sort.spill.percent | 环形缓冲区溢出的阈值，默认 80% |
4）容错相干参数(MapReduce 性能优化)
| 配置参数 | 参数阐明 |
|---|---|
| mapreduce.map.maxattempts | 每个 Map Task 最大重试次数，一旦重试参数超过该值，则认为 Map Task 运行失败，默认值：4。 |
| mapreduce.reduce.maxattempts | 每个 Reduce Task 最大重试次数，一旦重试参数超过该值，则认为 Map Task 运行失败，默认值：4。 |
| mapreduce.task.timeout | Task 超时工夫，常常须要设置的一个参数，该参数表白的意思为：如果一个 Task 在肯定工夫内没有任何进入，即不会读取新的数据，也没有输入数据，则认为该 Task 处于 Block 状态，可能是卡住了，兴许永远会卡住，为了避免因为用户程序永远 Block 住不退出，则强制设置了一个该超时工夫（单位毫秒），默认是 600000。如果你的程序对每条输出数据的解决工夫过长（比方会拜访数据库，通过网络拉取数据等），倡议将该参数调大，该参数过小常呈现的谬误提醒是“AttemptID:attempt_14267829456721_123456_m_000224_0 Timed out after 300 secsContainer killed by the ApplicationMaster.”。 |
2.2 小文件的问题
为什么 HDFS 怕小文件呢？
因为 HDFS 上每个文件都要在 NameNode 建设一个索引，这个索引大小约 150byte，当大量小文件时，就会产生很多的索引文件，但内存是有限度的，另外索引文件过大也会使得索引查问效率升高。
所以小文件问题，在生产环境中肯定要引起留神的问题。
解决形式就是缩小小文件产生或者对小文件合并，具体有以下几种形式：
1）在数据采集的时候，就将小文件或小批数据合成大文件再上传 HDFS。
2）在业务解决之前，在 HDFS 上应用 MapReduce 程序对小文件进行合并。
3）在 MapReduce 解决时，可采纳 CombineTextInputFormat 提高效率。
