NativeTask：利用本地执行引擎加速Hadoop <转>

NativeTask是Hadoop MapReduce的高效执行引擎实现。与MapReduce相比，NativeTask获得了不错的性能提升，主要包括更好的排序实现、关键路径避免序列化、避免复杂抽象、更好的利用压缩等。

简介

NativeTask是一个高性能MapReduce执行单元，支持C++接口。顾名思义，NativeTask是一个本地数据处理引擎，专注于数 据处理本身，在MapReduce的环境下，它仅替换Task模块功能。换句话说，NativeTask并不关心资源管理、作业调度和容错，这些功能仍旧 由原有的模块完成，而实际的数据处理由这个高性能处理引擎完成。任务级别的数据处理占用Hadoop集群绝大部分资源，而利用NativeTask的高效 性能可以显著提高数据分析速度、降低成本。

NativeTask目前还是一个正在开发中的开源项目，虽然部分功能还没有完成，但已能体现明显的性能优势。该项目的另一个目的是提供一个本地MapReduce开发接口，以便能在此基础上构建更加高效的大数据处理工具，例如下面两种情形。

数据仓库工具。开源实现，如Hive，相比商业分析型数据库的性能还有很大劣势。目前最先进的查询执行技术，例如轻量级压缩、向量化执行、LLVM动态编译等，使用本地语言更容易实现。

数据挖掘和机器学习算法库。这类应用通常都是计算密集型，需要多次迭代计算。另外有大量的数值分析和机器学习库是本地库，C++环境可以更容易利用到这些算法库。

对已经熟悉Hadoop的用户来说，NativeTask的接口和使用方法与Hadoop Pipes类似，用户通过NativeTask提供的头文件和动态库，编译生成自己的应用库，提交作业到Hadoop集群执行。NativeTask有以下特点。

• 高性能，加速作业执行并节约硬件资源。
• C++接口，应用可以更方便地使用各种优化技术，例如SSE/AVX指令优化、LLVM动态编译、GPU计算等。
• 纯二进制接口，避免序列化和反序列化开销。
• 支持不排序的数据流，经典的MapReduce数据流是需要对记录排序的，但很多应用并不需要排序，通过移除排序，可以进一步提升性能。
• 新加一种与MapReduce不同的编程模型接口Map-Foldl，能够更高效地执行聚合类的应用。

背景

大多数人感兴趣的问题是，为什么NativeTask能够这么快？在我看来，这从另一个问题展开更加合适：MapReduce模型是不是已经足够高效，以致于没有太大的优化空间了?

显然不是。比如，一个高质量的C++程序可以很轻易地在几秒钟内完成1GB数据的简单处理，但一个MapReduce任务（不是整个作业）通常需要 几分钟来处理同样的数据。另外，最近学术界也有很多研究表明，MapReduce相比并行数据库性能差距很大，并提出一些改进方案，在特定的应用场景下获 得了数十倍的性能提升，比如HadoopDB（目前已经成立创业公司Hadapt），以及最近提出的Clydesdale。这些研究都证明Hadoop还 有很大的优化空间。

虽然Hadoop在可扩展性和容错性上有明显的优势，并且在处理非结构化和半结构化数据上易用性更好，但这些优势和性能并不是一种折中关系。 MapReduce完全可以在保持原有计算模型不变的前提下更加高效，而且目前没有任何技术方面的局限去实现更高的性能。下面，我们来分析一下 MapReduce能做到多快，假设现在有一个Hadoop节点，如表1所示。

表1 节点配置

假设每个核运行一个任务，这个节点可以并行运行12个任务，平均每个任务使用4GB内存、1个SATA硬盘。一个典型的Map任务各个流程的极限性能应该能够达到如表2所示的理想速度。