Hadoop与MapReduce实用入门

分布式文件系统

传统技术可能不足以从大数据集提取有意义的信息。

谷歌很早就意识到这一问题，并提出了一个潜在的稳健解决方案。

因此，他们创建了一个分布式文件系统，称为Google 文件系统（GFS），并发表了一篇相关论文。

简而言之，GFS 是一种为分布式数据密集型应用设计的可扩展分布式文件系统。其最终目标是高效处理大规模数据集，索引数十亿个网页，并从中提取知识。

另一个重要要求是，GFS 应能在一组普通服务器上运行，这些服务器使用的是日常硬件，类似于大多数普通计算机所用的硬件。

这是因为专用硬件成本高昂，且按需生产。考虑到谷歌所需的集群规模，这并不现实。所有专用硬件的开销将使任何初始利润变得毫无意义。

值得注意的是，与其它文件系统不同，GFS 采用 64MB 的块大小以提高吞吐量。大多数日常文件系统使用的块大小仅为几 KB。

当然，仅有一个文件系统还不够。如果无法从中创造价值，数据就毫无用处。

MapReduce

通俗地说，可以把 MapReduce 理解为一种分而治之的策略。一个庞大的数据集被分配到多个工作节点上进行处理。当各节点完成计算后，再将结果汇总，得出最终答案。

MapReduce 基于以下两个核心原则：

原则一：简单性

只需两个函数即可完成任务，即 map 和 reduce。

由于大多数人认为分布式系统的编程非常复杂，MapReduce 通过这种简单的两函数机制隐藏了底层复杂性。

map 函数处理输入流（如文件），并对它们进行细粒度分析。换句话说，用户定义一个 map 函数，用于处理键值对，生成一组中间键值对。例如，若输入为文本，map 阶段可以统计每句话包含多少个字母。另一方面，reduce 函数接收一个或多个 map 函数的输出，并对其进行聚合。

请记住，由于是分布式运行，我们可能有多个映射器和归约器。

原则二：本地化执行

为了提升效率和性能，最佳做法是将待执行的代码发送到数据所在的位置，而不是反过来。数据始终存储在 GFS 集群中的某个节点上。

特性

MapReduce 编程模型具有以下特点：

• 分布式：MapReduce 是一个分布式框架，由运行 map 或 reduce 任务的普通硬件集群组成。
• 并行：map 和 reduce 任务始终并行执行。
• 容错：若某个任务失败，系统会将其重新调度到其他节点上。
• 可扩展：可任意扩展。随着问题规模扩大，可通过增加机器来在合理时间内解决问题。该框架支持横向扩展而非纵向扩展。

示例

现在我们通过一个现实生活中的例子来演示这一概念，而非技术性的说明。

想象你和10位朋友在网球场上，数以千计的网球散落在场地各处。

如果你要统计场地上不同颜色球的总数，就需要在团队内部进行分工：

• 一部分人充当 映射器，另一部分人充当 归约器。
• 你们将球场划分为若干区域，每人负责一个区域。这就是对数据的分区。
• 映射器记录类似“我看到一个绿色球”、“我看到一个粉色球”等信息。根据映射器的报告，归约器统计出各类颜色球的数量。
• 最后，将所有归约器的结果合并，得到你想要的总数。

Hadoop

此后，Hadoop 被 Apache 接管，并持续维护多年。