「Spark从入门到精通系列」1. Apache Spark简介：一个统一的分析引擎

最新推荐文章于 2025-06-26 15:45:31 发布

原创

最新推荐文章于 2025-06-26 15:45:31 发布 · 597 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#分布式 #大数据 #编程语言 #hadoop #python

来源 | Learning Spark Lightning-Fast Data Analytics，Second Edition

作者 | Damji，et al.

翻译 | 吴邪大数据4年从业经验，目前就职于广州一家互联网公司，负责大数据基础平台自研、离线计算&实时计算研究

校对 | gongyouliu

编辑 | auroral-L

全文共9094字，预计阅读时间55分钟。

第一章 Apache Spark简介：

一个统一的分析引擎

1 Spark的起源

1.1 谷歌的大数据和分布式计算

1.2 Hadoop at Yahoo!

1.3 初期诞生于AMP实验室的Spark

2. Spark是什么

2.1 快速

2.2 易用

2.3 通用

2.4 可扩展

3. 统一的分析引擎

3.1 Apache Spark 组件栈

3.2 Apache Spark 分布式执行

4. 开发人员经验

4.1 使用Spark的群体和目的

4.2 社区采纳与拓展

本章阐述了Apache Spark的起源及其基本哲学。还讲述了该项目的主要组成部分及其分布式架构，如果你熟悉Spark的发展历史和高级概念，你可以直接跳过本章内容。

1.Spark的起源

在本节中，我们将介绍Apache Spark的短期演变过程：它的起源、诞生的灵感以及作为大数据统一处理引擎在社区中的应用。

1.1谷歌的大数据和分布式计算

当我们想到数据规模时，我们不禁想到谷歌的搜索引擎能够以闪电般的速度在互联网上索引和搜索全世界的数据，从这一点看谷歌这个名字是数据规模的同义词，事实上，谷歌是一个故意拼写错误的数学术语，谷歌：意思就是1后面加100个零！

传统的存储系统(如关系数据库管理系统(RDBMS))和必要的编程方式都无法处理谷歌想要构建和搜索互联网索引文档的数据规模。新的需求促进了新的技术诞生，这也是后来谷歌“三辆马车”的产生背景，分别是Google文件系统(GFS)、Map Reduce(MR)和Bigtable。

虽然GFS通过许多硬件服务器构成集群从而提供了容错和分布式文件系统的功能，但也只是解决了海量数据存放的问题，而BigTable则提供了GFS文件系统可伸缩扩展的结构化数据存储，将GFS的数据进行映射，另外MR基于函数式编程引入了一种新的并行编程范式，用户可以利用MR对GFS分布式文件系统以及BigTable映射的结构化数据进行大规模计算处理。

从本质上来说，MR应用程序通过与MapReduce System交互将数据发送给计算模块处理，该计算模块主要由map 和reduce函数组成，核心设计理念是“移动计算而不是移动数据”，支持对数据和集群机架的感知，实现就近计算，而不是每次都把数据移动到应用程序做计算，这样可以减少数据传输的成本，从而在一定程度上提供计算效率。

集群中的工作节点会对计算结果进行聚合，减少中间计算，并最终通过reduce函数将结果进行归一化输出，写入到分布式文件系统中去，程序也可以访问分布式文件系统，这样的工作模式可以显著减少网络流量，并且保证大部分的输入/输出（I/O）在本地进行落盘，而不是分配在网络上。

谷歌所做的大部分工作都是属于定制化的，不具备通用性，但是上述三篇论文中所表达的设计思想却激发了开源社区对分布式文件系统和大规模计算以及大数据数据结构化存储的创新想法——尤其是在雅虎，它在搜索引擎处理方面正遇到了类似的大数据挑战。

1.2Hadoop at Yahoo!

谷歌的GFS论文中所阐述的关于大规模数据计算挑战和解决方案给分布式文件系统(HDFS)的实现提供了蓝图，也包括为分布式计算框架MapReduce提供了实现。2006年4月，它捐赠给了Apache软件基金会(ASF)，成为Apache·Hadoop框架（包含Hadoop Common、MapReduce、HDFS和Apache Hadoop YARN等4大块）的一部分。

尽管Apache Hadoop在雅虎之外获得了广泛的应用！由于有一个大型的开源贡献者社区和两个开源的商业公司（Cloudera and Hortonworks，目前合并了）的参与，MapReduce框架在HDFS上还是存在一些缺点，有以下几点。

第一，Apache Hadoop由于繁琐且复杂的操作，使得其很难管理和维护。其次，它的通用批处理MapReduce API非常冗长，需要开发大量的格式化代码，容错性非常差。第三，对于大批量数据作业，通过需要很多组的MR任务进行计算，每组MR的中间计算结果都会写入本地磁盘，然后再通过从磁盘读取进行下一步操作（见图1-1）。如此频繁的磁盘I/O会导致性能非常差，代价不可谓不高，正如我们所了解的，通常大型MR工作可以连续运行数小时甚至几天，计算时间成本和风险是个非常严重的问题，一旦出现运行错误，就需要重头来过。

最后，尽管Hadoop MR有利于大型批量处理，但它不支持其他工作场景功能，比如机器学习、流计算或类似SQL的交互式查询。

为了解决Hadoop MR存在的问题，工程师们开发了一系列定制化系统（Apache Hive、Apache Storm、Apache Impala、Apache Giraph、Apache Drill、Apache Mahout等等），每个组件都有自己的API和集群配置，进一步丰富了Hadoop的生态，同时对开发人员的学习曲线有了更多的要求。

然后问题变成其他有针对性的问题，正如Alan Kay’s adage所说“Simple things should be simple, complex things should be possible”，简单的事情要简单做，复杂的事情应该是可能的，那么有没有办法让Hadoop和MR变得更简单更快呢？

1.3初期诞生于AMP实验室的Spark

加州大学伯克利分校的研究人员之前曾研究过Hadoop MapReduce，他们通过一个名为Spark的项目接受了Apache Hadoop存在的挑战。不得不承认，MR在交互或迭代计算工作方面效率是非常低下（或棘手）的，学习框架复杂，所以他们从一开始就产生了让Spa