1. Hadoop 最出名的是 MapReduce和 HDFS，不过也有很多其他有用的子项目。
技术栈如下：
Core
一系列分布式文件系统和通用I/O的组件和接口（序列化、Java RPC和持久化数据结构）
Avro
一种提供高效、跨语言RPC的数据序列系统，持久化数据存储。
MapReduce
分布式数据处理模式和执行环境，运行于大型商用机集群。
HDFS
分布式文件系统，运行于大型商用机集群。
Pig
一种数据流语言和运行环境，用以检索非常大的数据集。Pig运行在MapReduce和HDFS的集群上。
Hbase
一个分布式、列存储数据库。使用HDFS作为底层存储，同时支持MapReduce的批量式计算和点查询（随机读取）。
ZooKeeper
一个分布式的、高可用性的协调服务。ZooKeeper提供分布式锁之类的基本服务用于构建分布式应用。
Hive
分布式数据仓库。Hive管理HDFS中存储的数据，并提供基于SQL的查询语言（运行时由引擎翻译成MapReduce作业）用以查询数据。
Chukwa
分布式数据收集和分析系统。Chukwa运行HDFS中存储数据的收集器，它使用MapReduce来生成报告。
2. Shuffle and combiner
Shuffle
是从map输出，到reduce输入之间的过程。
很多map任务和reduce任务，并不是一对一的关系，所以可以认为在中间进行了“洗牌” 重组操作，形象的叫作shuffle。
Shuffle是Hadoop很核心的部分，涉及到最珍贵的网络资源。此外，shuffle过程中会有很多参数，也有很多策略可以研究。
Combiner
是运行在map上的一种优化，并不改变reducer的结果，可以帮助减少map和reduce 之间的数据传输量。
它的一个很重要的作用：会对相同key的值进行合并，即减少了数据量，进而提高了效率。
3. HDFS
Hadoop Distributed Filesystem. HDFS is a filesystem designed for storing very large files with streaming data access
patterns, running on clusters of commodity hardware.
1) 大文件
2）流式数据访问。 一次写入，多次读取
3）商用普通硬件。并不要求昂贵、高可靠性机器。因此要应对节点故障和中断（使用户尽量感知不到）
所以，一些不适合使用的领域是：
1）低延迟数据访问。
HDFS是高数据吞吐量，HBase是低延迟访问的更好选择
2）大量的小文件
namenode（名称节点）存储文件系统的元数据，因此文件数量也由namenode的内存大小决定。
3）多用户写入，任意位置修改文件
HDFS中的文件只有一个写入者，否则会造成冲突。而且写操作总是在文件的末尾。
4. HA 高可用性
参考自 http://blog.csdn.net/caizhongda/article/details/7947480
在以前的版本中，HDFS 集群中的NameNode机器，存在单点故障（SPOF ）。如果只有一个NameNode的集群出现故障，那么整个集群将无法使用，直到NameNode 重新启动。主要是在以下两种情况会影响HDFS集群：
1). NameNode 机器发生意外，比如宕机，集群将无法使用，直到管理员重启NameNode
2). NameNode 机器需要升级，包括软件、硬件升级，此时集群也将无法使用
而HDFS 的HA 功能通过配置Active/Standby 两个NameNodes，实现故障时快速切换另外一台。
在一个典型的HDFS(HA) 集群中，使用两台单独的机器配置为NameNodes ,在任何时间点，确保NameNodes 中只有一个处于Active 状态，其他的处在Standby 状态。
5. YARN
参考自 http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/#_3.3_hadoop_ 官方简介
YARN 是Hadoop 0.23.0 版本后新的 map-reduce 框架。
0.20.0 及之前版本的map-reduce框架如下：
提交任务 分发任务
Jobclient ------------> JobTracker <-------------------> TaskTracker ------------------> map & reducer slots
heartbeat通信
缺点：
- JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
- JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
- 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到每个task的 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
- 在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
- 源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
- 从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。
YARN 是对旧的map-reduce框架的完全重构。根本的思想是将 JobTracker 两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度 / 监控。
ResourceManager, ApplicationMaster 与 NodeManager 三个部分取代了 JobTracker和TaskTracker。
ResourceManager 调度、启动每一个 Job 所属的 ApplicationMaster、另外监控 ApplicationMaster 的存在情况；具体来说就是接收 JobSubmitter 提交的作业，按照作业的上下文 (Context) 信息，以及从 NodeManager 收集来的状态信息，启动调度过程，分配一个 Container 作为 App Mstr
NodeManager 功能比较专一，就是负责 Container 状态的维护，并向 RM 保持心跳。
ApplicationMaster 负责一个 Job 生命周期内的所有工作