参考：
- Hadoop.The.Definitive.Guide.4th
我们遇到的问题很简单：在硬盘存储容量多年来不断提升的同时，访问速度（硬盘数据读取速度）却没有与时俱进。1990 年，一个普通硬盘可以存储1370 MB数据，传输速度为4.4 MB/s；因此只需要5分钟就可以读完整个硬盘中的数据。20年过去了，ITB的硬盘成为主流，但其数据传输速度约为100 MB/s，读完整个硬盘中的数据至少得花2.5个小时。
读完整个硬盘中的数据需要更长时间，写入数据就别提了。
一个很简单的减少读取时间的办法是同时从多个硬盘上读数据。试想，如果我们有100 个硬盘，每个硬盘存储1%的数据，并行读取，那么不到两分钟就可以读完所有数据。仅使用硬盘容量的1%似乎很浪费。但是我们可以存储100个数据集，每个数据集1 TB，并实现共享硬盘的读取。可以想象，用户肯定很乐于通过硬盘共享来缩短数据分析时间；并且，从统计角度来看，用户的分析工作都是在不同时间点进行的，所以彼此之间的干扰并不太大。
虽然如此，但要对多个硬盘中的数据进行 并行读/写 数据，还有更多问题要解决。
数据存储问题
第一个需要解决的是硬件故障问题。一旦开始使用多个硬件，其中个别硬件就很有可能发生故障。为了避免数据丢失，最常见的做法是复制(replcation)：系统保存数据的复本(replica)，一旦有系统发生故障，就可以使用另外保存的复本。例如，冗余硬盘阵列(RAID)就是按这个原理实现的，另外，Hadoop 的文件系统(Hadoop Distributed FileSystem, HDFS)也是一类，不过它采取的方法稍有不同。
数据分析问题
第二个问题是大多数分析任务需要以某种方式结合大部分数据来共同完成分析，即从一个硬盘读取的数据可能需要与从另外99个硬盘中读取的数据结合使用。各种分布式系统允许结合不同来源的数据进行分析，但保证其正确性是一个非常大的挑战。
MapReduce提出一个编程模型，该模型抽象出这些硬盘读/写问题并将其转换为对一个数据集(由键-值对组成)的计算。后文将详细讨论这个模型，这样的计算由map和reduce两部分组成，而且只有这两部分提供对外的接口。与HDFS类似，MapReduce自身也有很高的可靠性。
解决方案
Hadoop
简而言之，Hadoop 为我们提供了一个可靠的且可扩展的存储和分析平台。此外，由于Hadoop运行在商用硬件上且是开源的，因而可以说Hadoop的使用成本是在可承受范围内的。
Hadoop 包含了一组守护进程服务（HDFS、YARN、MapReduce等）与客户端应用。在Hadoop集群中，守护进程服务维护了Hadoop的运行环境，而客户端用于与Hadoop提供的服务进行交互。
HDFS
HDFS（Hadoop Distributed File System），它是一个文件系统，用于存储文件，通过目录树来定位文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。
HDFS的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合用来做网盘应用。
MapReduce
MapReduce看似采用了一种蛮力方法。每个查询（读）需要处理整个数据集或至少一个数据集的绝大部分。但反过来想，这也正是它的能力。MapReduce 是一个批量查询处理器，能够在合理的时间范围内处理针对整个数据集的动态查询。它改变了我们对数据的传统看法，解放了以前只是保存在磁带和硬盘上的数据。它让我们有机会对数据进行创新。以前需要很长时间处理才能获得结果的问题，到现在变得顷刻之间就迎刃而解，同时还可以引发新的问题和新的见解。
例如，Rackspace 公司的邮件部门Mailtrust就用Hadoop来处理邮件日志。他们写了一条特别的查询用于帮助找出用户的地理分布。他们是这么描述的：“这些数据非常有用，我们每月运行一次 MapReduce 任务来帮助我们决定扩容时将新的邮件服务器放在哪些Rackspace数据中心。”。
通过整合好几百GB的数据，用工具来分析这些数据，Rackspace 的工程师能够对以往没有注意到的数据有所理解，甚至还运用这些信息来改善现有的服务。
从MapReduce 的所有长处来看，它基本上是一个批处理系统，并不适合交互式分析。你不可能执行一条查询并在几秒内或更短的时间内得到结果。典型情况下，执行查询需要几分钟或更多时间。因此，MapReduce更适合那种没有用户在现场等待查询结果的离线使用场景。
Hadoop相关生态组件
然而，从最初的原型出现以来，Hadoop 的发展已经超越了批处理本身。实际上，名词“Hadoop”有时被用于指代一个更大的、多个项目组成的生态系统，而不仅仅是HDFS和MapReduce。
这些项目都属于分布式计算和大规模数据处理范畴。这些项目中有许多都是由Apache软件基金会管理，该基金会为开源软件项目社区提供支持，其中包括最初的HTTP server项目(基金会的名称也来源于这个项目)。
HBase
第一个提供在线访问的组件是HBase，一种使用HDFS做底层存储的键值存储模型。HBase不仅提供对单行的在线读/写访问，还提供对数据块读/写的批操作，这对于在HBase上构建应用来说是一种很好的解决方案。
Hadoop 2中YARN(Yet Another Resource Negotiator)的出现意味着Hadoop有了新处理模型。YARN 是一个集群资源管理系统，允许任何一个分布式程序(不仅仅是MapReduce)基于Hadoop集群的数据而运行。
在过去的几年中，出现了许多不同的、能与Hadoop协同工作的处理模式。以下是一些例子。
Hive和impala
Interactive SQL(交互式SQL)
利用MapReduce 进行分发并使用一个分布式查询引擎，使得在Hadoop 上获得SQL查询低延迟响应的同时还能保持对大数据集规模的可扩展性。这个引擎使用指定的“总是开启(always on)”守护进程(如同impala)或容器重用(如同Tez上的Hive)。
Spark
lterative processing(迭代处理)
许多算法，例如机器学习算法，自身具有迭代性，因此和那种每次迭代都从硬盘加载的方式相比，这种在内存中保存每次中间结果集的方式更加高效。MapReduce的架构不允许这样，但如果使用Spark就会比较直接，它在使用数据集方面展现了一种高度探究的风格。
Storm和Spark Streaming
Stream processing(流处理)
流系统，例如Storm, Spark Streaming 或Samza使得在无边界数据流上运行实时、分布式的计算，并向Hadoop存储系统或外部系统发布结果成为可能。
Solr
Search(搜索)
Solr搜索平台能够在Hadoop 集群上运行，当文档加入HDFS 后就可对其进行索引，且根据HDFS中存储的索引为搜索查询提供服务。
无论Hadoop上出现了多少不同的处理框架，就批处理而言，MapReduce仍然有着一席之地。MapReduce 提出的一些概念更具有通用性(例如，输入格式、数据集分片等)，因此最好是能够了解MapReduce的工作机制。
若有收获，就点个赞吧
0 人点赞
