下面是小编为大家整理的javaEE,大数据培训教程-Hadoop平台优化总结（全文）,供大家参考。
Java 一直都是主流的语言之一，因为大数据的人才急需导致 Java 相关的工作岗位再次火爆起来。而在大数据中优化是一个非常关键的课题。今天和大家一起讨论一下关于大数据优化的相关问题。
随着企业要处理的数据量越来越大，MapReduce 思想越来越受到重视。Hadoop 是MapReduce 的一个开源实现，由于其良好的扩展性和容错性，已得到越来越广泛的应用。Hadoop 作为一个基础数据处理平台，虽然其应用价值已得到大家认可，但仍存在很多问题，以下是主要几个：
（1 ）Namenode/jobtracker 单点故障。
Hadoop 采用的是 master/slaves 架构，该架构管理起来比较简单，但存在致命的单点故障和空间容量不足等缺点，这已经严重影响了 Hadoop 的可扩展性。
（2 ）HDFS 小文件问题。在 HDFS 中，任何 block，文件或者目录在内存中均以对象的形式存储，每个对象约占 150byte，如果有 1000 0000 个小文件，每个文件占用一个block，则 namenode 需要 2G 空间。如果存储 1 亿个文件，则 namenode 需要 20G 空间。这样 namenode 内存容量严重制约了集群的扩展。
（3 ）jobtracker 同时进行监控和调度，负载过大。为了解决该问题，yahoo 已经开始着手设计下一代 Hadoop MapReduce（见参考资料 1）。他们的主要思路是将监控和调度分离，独立出一个专门的组件进行监控，而 jobtracker 只负责总体调度，至于局部调度，交给作业所在的 client。
（4 ）数据处理性能。
很多实验表明，其处理性能有很大的提升空间。Hadoop 类似于数据库，可能需要专门的优化工程师根据实际的应用需要对 Hadoop 进行调优，有人称之为“Hadoop Performance Optimization” (HPO)。
为了提高其数据性能，很多人开始优化 Hadoop。总结看来，对于 Hadoop，当前主要有几个优化思路：
（1）
从应用程序角度进行优化。由于 mapreduce 是迭代逐行解析数据文件的，怎样在迭代的情况下，编写高效率的应用程序，是一种优化思路。
（2）
对 Hadoop 参数进行调优。当前 hadoop 系统有 190 多个配置参数，怎样调整这些参数，使 hadoop 作业运行尽可能的快，也是一种优化思路。
（3）
从系统实现角度进行优化。这种优化难度是最大的，它是从 hadoop 实现机制角度，发现当前 Hadoop 设计和实现上的缺点，然后进行源码级地修改。该方法虽难度大，但往往效果明显。
以上三种思路出发点均是提高 hadoop 应用程序的效率。实际上，随着社会的发展，绿色环保观念也越来越多地融入了企业，因而很多人开始研究 Green Hadoop，即怎样让Hadoop 完成相应数据处理任务的同时，使用最少的能源.
当前学术界的一些优化思路，有人试图从 Hadoop 自动配置角度对 Hadoop 进行优化，但更多的是从系统实现角度进行优化，概括其优化点和实验效果如下：
（1）从参数自动调优角度对 Hadoop 进行优化，给出了一种 Hadoop 优化的新思路，即怎样对其 190 多个配置参数进行自动调整，使应用程序执行效率最高。
（2）
提出 prefetching 和 preshuffling 机制，在不同负载不同规模集群下测试，效率提升了约 73%。
（3）
影响 Hadoop 效率的五个因素，并通过提出相应的解决方案，使 Hadoop 效率提高了 2.5~3.5 倍。
（4）
为 Hadoop 提供了一种索引机制– Trojan Index，同时提出了一种高效的 join算法– Trojan Join，实验表明，效率比 Hadoop 和 HadoopDB 高很多。
除了学术界的优化，工业界也在不断进行优化以适应自己公司的产品需要，主要有：
（1 ）Baidu 公司。baidu 对 Hadoop 中关键组件使用 C++进行了重写（包括 map, shuffler 和 reducer 等），经他们内部测试（5 nodes，40GB data），效率提升了约 20%.
（2 ）淘宝。淘宝针对自己集群特点（作业小，slot 多，作业之间有依赖，集群共享，有些作业有时效性），对 jobtracker 和 namenode 进行了优化，据其官方博客称，其jobtracker 有较大性能提升，且 namenode 吞吐量提升了 8+倍。但其具体优化方法，未公开。
从应用程序角度进行优化
（1 ）
避免不必要的 reduce 任务
如果要处理的数据是排序且已经分区的，或者对于一份数据, 需要多次处理, 可以先排序分区；然后自定义 InputSplit, 将单个分区作为单个 mapred 的输入；在 map 中处理数据, Reducer 设置为空。
这样, 既重用了已有的 “排序”, 也避免了多余的 reduce 任务。
（2 ）外部文件引入 有些应用程序要使用外部文件，如字典，配置文件等，这些文件需要在所有 task 之间共享，可以放到分布式缓存 DistributedCache 中（或直接采用-files 选项，机制相同）。
更多的这方面的优化方法，还需要在实践中不断积累。
（3 ）
为 为 job 添加一个 Combiner 为 job 添加一个 combiner 可以大大减少 shuffle 阶段从 map task 拷贝给远程 reduce task 的数据量。一般而言，combiner 与 reducer 相同。
（4 ）
根据处理数据特征使用最适合和简洁的 Writable 类型 Text 对象使用起来很方便，但它在由数值转换到文本或是由 UTF8 字符串转换到文本时都是低效的，且会消耗大量的 CPU 时间。当处理那些非文本的数据时，可以使用二进制的 Writable 类型，如 IntWritable， FloatWritable 等。二进制 writable 好处：避免文件转换的消耗；使 map task 中间结果占用更少的空间。
（5 ）
重用 Writable 类型 很多 MapReduce 用户常犯的一个错误是，在一个 map/reduce 方法中为每个输出都创建 Writable 对象。例如，你的 Wordcout mapper 方法可能这样写：
public void map(...) {
…
for (String word : words) {
output.collect(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) {
wordText.set(word);
output.collect(wordText, one);
}
} }
（6 ）
使用 StringBuffer 而不是 String 当需要对字符串进行操作时，使用 StringBuffer 而不是 String，String 是 read-only 的，如果对它进行修改，会产生临时对象，而 StringBuffer 是可修改的，不会产生临时对象。
（7 ）调试 最重要，也是最基本的，是要掌握 MapReduce 程序调试方法，跟踪程序的瓶颈.
推荐访问:javaEE 大数据培训教程-Hadoop平台优化总结 培训教程 优化 数据