上篇《高可用Hadoop平台－启航》博客已经让我们初步了解了Hadoop平台；接下来，我们对Hadoop做进一步的探索，一步一步的揭开Hadoop的神秘面纱。下面，我们开始赘述今天的探索之路。
2.探索在探索之前，我们来看一下Hadoop解决了什么问题，Hadoop就是解决了大数据（大到单台服务器无法进行存储，单台服务器无法在限定的时间内进行处理）的可靠存储和处理。
HDFS：在由普通或廉价的服务器（或PC）组成的集群上提供高可用的文件存储，通过将块保存多个副本的办法解决服务器或硬盘坏掉的问题。
MapReduce：通过简单的Mapper和Reducer的抽象提供一个编程模型，可以在一个由几十台或上百台的服务器组成的集群上进行并发，分布式的处理大量的数据集；而并发，分布式（如：机器间通信）和故障恢复等计算细节隐藏起来。而Mapper和Reducer的抽象，又是各种各样的复杂数据处理都可以分解为基本元素。这样，复杂的数据处理可以分解为由多个Job（包含一个Mapper和一个Reducer）组成的有向无环图（DAG），然后每个Mapper和Reducer放到Hadoop集群上执行，就可以得出如下图所示的结果：
在Hadoop的源码中，提供了一个很经典的例子：WordCount，具体源码可以参见上篇文章，如果对MapReduce不熟悉，通过该示例对MapReduce进行一些了解对理解下文会由帮助。在MapReduce中，Shuffle是一个非常重要的过程，正是有了看不见的Shuffle过程，才可以使在MapReduce之上写数据处理的开发者完全感觉不到分布式和并发的存在。
注：广义的Shuffle是指图中在Map和Reduce之间的一系列过程。
2.1Hadoop的局限和不足MapReduce存在以下局限，使用起来比较困难。
抽象层次低，需要手工编写代码来完成，使用上难以上手，入门门槛较高。
只提供两个操作，Map和Reduce，表达的力度不够。
一个Job只有Map和Reduce两个阶段，复杂的计算需要大量的Job来完成。Job之间的依赖关系是由开发者自己来管理的。
处理逻辑隐藏在代码细节中，没有整体逻辑。
中间结果也放在HDFS文件系统中。
ReduceTask需要等待所有的MapTask都完成后才可以开始。
时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够。
对于迭代式数据处理性能比较差。
举个例子，用MapReduce实现表与表之间的join，都是一个很需要技巧来处理的过程，如下图：
因此，在Hadoop之后，出现来很多相关技术对其中的局限进行改进，如：Hive，Oozie，Tez，Spark，Storm等等。
3.HiveHive是Facebook的产品，目前已托管到Apache基金。关于Hive的安装搭建和使用请参考《那些年使用Hive踩过的坑》和《Hive的安装部署》，这里就不多赘述了。Hive是一种底层封装了Hadoop的数据仓库处理工具，使用类SQL的HiveSQL语言实现数据查询，所有Hive的数据都存储在HDFS中。Hive在加载数据过程中不会对数据进行任何的修改，只是将数据移动到HDFS中Hive的指定目录下，因此，Hive不支持对数据的改写和添加，所有的数据都是在加载的时候确定的。
Hive解决类MapReduce存在的大量手写代码，语义隐藏，提供操作种类少的问题。类似的项目还有Pig，JAQL等。
4.TezTez是HortonWorks的Stinger Initiative的的一部分。作为执行引擎，Tez也提供了有向无环图（DAG），DAG由顶点（Vertex）和边（Edge）组成，Edge是对数据的移动的抽象，提供了One-To-One，BroadCast，和Scatter-Gather三种类型，只有Scatter-Gather才需要进行Shuffle。
示例：
SELECT a.state, COUNT(*), AVERAGE(c.price) FROM a JOIN b ON (a.id = b.id) JOIN c ON (a.itemId = c.itemId) GROUP BY a.state