HDFS和MapReduce擅长与局限

HDFS的优势

HDFS的英文全称是 Hadoop Distributed File System，即Hadoop分布式文件系统，它是Hadoop的核心子项目。实际上，Hadoop中有一个综合性的文件系统抽象，它提供了文件系统实现的各类接口，而HDFS只是这个抽象文件系统的一种实现，但HDFS是各种抽象接口中应用最为广泛和最广为人知的一个。

HDFS被设计成适合运行在通用和廉价硬件上的分布式文件系统。它和现有的分布式文件系统有很多共同点，但他和其它分布式文件系统的区别也是明显的。HDFS是基于流式数据模式访问和处理超大文件的需求而开发的，

其主要特点如下：

1、处理超大文件

这里的超大文件通常指的是GB、TB甚至PB大小的文件。通过将超大文件拆分为小的HDFS和MapReduce优缺点Split，并分配给数以百计、千计甚至万计的的节点，Hadoop可以很容易地扩展并处理这些超大文件。

2、运行于廉价的商用机器集群上

HDFS设计对硬件需求比较低，只需运行在低廉的的商用机器集群上，而无须使用昂贵的高可用机器。在设计HDFS时要充分考虑数据的可靠性、安全性和高可用性。

3、高容错性和高可靠性

HDFS设计中就考虑到低廉硬件的不可靠性，一份数据会自动保存多个副本（具体可用设置，通常三个副本），通过增加副本的数量来保证它的容错性。如果某一个副本丢失，HDFS会自动复制其它机器上的副本。

当然，有可能多个副本都会出现问题，但是HDFS保存的时候会自动跨节点和跨机架，因此这种概率非常低，HDFS同时也提供了各种副本放置策略来满足不同级别的容错需求。

4、流式的访问数据

HDFS的设计建立在更多低相应“一次写入，多次读写”任务的基础上，这意味着一个数据集一旦有数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各种的数据分析任务需求。在多数情况下，分析任务都

会涉及数据集的大部分数据，也就是说，对HDFS来说，请求读取整个数据集比请求读取单条记录会更加高效。

HDFS的局限

HDFS的上述种种特点非常适合于大数据量的批处理，但是对于一些特点问题不但没有优势，而且有一定的局限性，主要表现以下几个方面：

1、不适合低延迟数据访问

如果要处理一些用户要求时间比较短的低延迟应用请求（比如毫秒级、秒级的响应时间），则HDFS不适合。HDFS是为了处理大型数据集而设计的，主要是为了达到高的数据吞吐量而设计的，

延迟时间通常是在分钟乃至小时级别。

对于那些有低延迟要求的应用程序，HBase是一个更好的选择，尤其是对于海量数据集进行访问要求毫秒级响应的情况，单HBase的设计是对单行或少量数据集的访问，对HBase的访问必须提供主键或主键范围。

2、无法高效存储大量小文件

3、不支持多用户写入和随机文件修改

在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。

MapReduce 的优势

MapReduce是Google公司的核心计算模型，它将运行于大规模集群上复杂并行计算过程高度抽象为两个函数：Map和Reduce。MapReduce目前非常流行，因为它有如下特点：

1、MapReduce易于理解：简单地实现一些接口，就可以完成一个分布式程序，而且这个分布式程序还可以分布到大量廉价的PC机器运行。也就是说，写一个分布式程序，跟写一个简单的串行程序是一模一样的。MapReduce

易于编程的背后是MapReduce通过抽象模型和计算框架把需要做什么（What need to do）与具体怎么做（How to do）分开了，为程序员提供了一个抽象和高层的编程接口和框架，程序员仅需关心其应用层的具体计算问题，

仅需要编写少量的应用本身计算问题的程序代码；如何具体完成这个并行计算任务所相关的诸多系统层细节被隐藏起来，交给计算框架去处理-----从分布代码的执行到大到数千、小到输几个节点集群的自动调度使用。

2、良好的扩展性

当计算机资源不能得到满足的时候，可以通过简单的增加机器来扩展它的计算能力。多项研究发现，基于MapReduce的计算性可以随节点数目增长保持近似于线性的增长，这个特点是MapReduce处理海量数据的关键，通过

将计算节点增至几百或者几千可以很容易地处理数百TB甚至PB级别的离线数据。

3、高容错性

MapReduce设计的初衷就是使程序能部署在廉价的PC机器上，这就要求它具有很高的容错性。比如，其中一台机器宕机了，它可以把上面的计算任务转移到另一个节点上运行，不至于这个任务运行失败，

而且这个过程不需要人工参与，完全是由Hadoop内部完成的。

MapReduce的局限

MapReduce虽然有很多的优势，但是也有它不擅长的。这里的“不擅长”，不代表不能做，而是在有些场景下实现的效果差，并不适合用MapReduce来处理，主要表现在以下结果方面：

1、实时计算：MapReduce无法像Oracle或MySQL那样在毫秒或秒级内返回结果，如果需要大数据量的毫秒级响应，可以考虑使用HBase.

2、流计算：流计算的输入数据是动态的，而MapReduce的输入数据是静态的，不能动态变化，这是因为MapReduce自身的设计特点决定了数据源必须是静态的。如果需要处理流式数据可以用Storm,Spark Steaming、Flink

等流计算框架。

3、DGA（有向图）计算：多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出。在这种情况下，MapReduce并不是不能做，而是使用后，每个MapReduce作业的输出结果都会写入磁盘，会造成大量的词频IO

导致性能非常低下，此时可以考虑用Spark等迭代计算框架。