1、Hive本地MR   如果在hive中运行的sql本身数据量很小，那么使用本地mr的效率要比分布式的快很多。但是hive本地MR对内存使用很敏感，查询的数据不能太大，否则本地内存是吃不消的。 So the query processor will launch this task in a child jvm, which has the same heap size as the

map task的数量即mapred.map.tasks的参数值，用户不能直接设置这个参数。Input Split的大小，决定了一个Job拥有多少个map。默认input split的大小是64M（与dfs.block.size的默认值相同）。然而，如果输入的数据量巨大，那么默认的64M的block会有几万甚至几十万的Map Task，集群的网络传输会很大，最严重的是给Job Tracker的调度

4.     从系统实现角度进行优化 4.1    在可移植性和性能之间进行权衡 论文[16]主要针对HDFS进行了优化，它分析了HDFS性能低下的两个原因：调度延迟和可移植性假设。 （1） 调度延迟 Hadoop采用的是动态调度算法，即：当某个tasktracker上出现空slot时，它会通过HEARBEAT（默认时间间隔为3s，当集群变大时，会适当调大）告诉jo

Hive 针对不同的查询进行了优化，优化可以通过配置进行控制，本文将介绍部分优化的策略以及优化控制选项。 列裁剪（Column Pruning） 在读数据的时候，只读取查询中需要用到的列，而忽略其他列。例如，对于查询： SELECT a,b FROM T WHERE e 其中，T 包含 5 个列 (a,b,c,d,e)，列 c，d 将会被忽略，只会读取a, b, e 列

1.     概述 随着企业要处理的数据量越来越大，MapReduce思想越来越受到重视。Hadoop是MapReduce的一个开源实现，由于其良好的扩展性和容错性，已得到越来越广泛的应用。Hadoop作为一个基础数据处理平台，虽然其应用价值已得到大家认可，但仍存在很多问题，以下是主要几个： （1）     Namenode/jobtracker单点故障。 Hadoop采用的是

1. 概述 在传统数据库（如：MYSQL）中，JOIN操作是非常常见且非常耗时的。而在HADOOP中进行JOIN操作，同样常见且耗时，由于Hadoop的独特设计思想，当进行JOIN操作时，有一些特殊的技巧。 本文首先介绍了Hadoop上通常的JOIN实现方法，然后给出了几种针对不同输入数据集的优化方法。 2. 常见的join方法介绍 假设要进行join的数据分别来自

利用CombineFileInputFormat把netflix data set导入到Hbase里

原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://peterhs.blog.51cto.com/6318839/1099236 （译自7 Tips for improving MapReduce Performance http://blog.cloudera.com/blog/2009/12/7-tips-f

官方解释：The maximum number of map tasks that will be run  simultaneously by a task tracker. 我的理解：一个tasktracker最多可以同时运行的map任务数量 默认值：2 优化值：mapred.tasktracker.map.tasks.maximum = cpu数量 cpu数量 = 服

一、背景 Hadoop的集群使用也有些时候了，不过都是小集群的使用（数量小于30台）。在这个过程中不断的进行着配置调优的操作。最早的时候，在网上也没有找到一些合适的配置调优方法，于是，我在这里列举一些基本的调优配置，以供参考。最后，还有一个我自己的测试环境的配置说明，也可以参看一下。 二、环境和配置 1.       版本和环境 Ø  Hadoop版本：apache发布的0

map和reduce是hadoop的核心功能，hadoop正是通过多个map和reduce的并行运行来实现任务的分布式并行计算，从这个观点来看，如果将map和reduce的数量设置为1，那么用户的任务就没有并行执行，但是map和reduce的数量也不能过多，数量过多虽然可以提高任务并行度，但是太多的map和reduce也会导致整个hadoop框架因为过度的系统资源开销而使任务失败。所以用户在提交m

在使用Hadoop处理海量小文件的应用场景中，如果你选择使用CombineFileInputFormat，而且你是第一次使用，可能你会感到有点迷惑。虽然，从这个处理方案的思想上很容易理解，但是可能会遇到这样那样的问题。 使用CombineFileInputFormat作为Map任务的输入规格描述，首先需要实现一个自定义的RecordReader。 CombineFileInputFormat的

经常看到一些Hive优化的建议中说当小表与大表做关联时，把小表写在前面，这样可以使Hive的关联速度更快，提到的原因都是说因为小表可以先放到内存中，然后大表的每条记录再去内存中检测，最终完成关联查询。这样的原因看似合理，但是仔细推敲，又站不住脚跟。 多小的表算小表？如果所谓的小表在内存中放不下怎么办？我用2个只有几条记录的表做关联查询，这应该算是小表了，在查看reduce的执行日志时依然是有

最近几次被问到关于数据倾斜的问题，这里找了些资料也结合一些自己的理解.      在并行计算中我们总希望分配的每一个task 都能以差不多的粒度来切分并且完成时间相差不大，但是集群中可能硬件不同，应用的类型不同和切分的数据大小不一致总会导致有部分任务极大的拖慢了整个任务的完成时间，硬件不同就不说了，应用的类型不同其中就比如page rank 或者data mining 里面一些计算，它的每条

在文章开头，我想先做几点说明： 1、本文的内容来自我对Yarn的相应功能的理解和实践。而我对该部分功能的理解主要来自对Hadoop的开发者之前相应言论的分析，并且我也将我的分析发给了Hadoop community， 并得到了Yarn的创始人兼架构师Arun Murthy的肯定回复。 2、本文中uber的配置部分，主要参考之前Hadoop开发者的言论。但是我当初看该言论的时候对一些细节有所疑惑