当一个计算工作过于简单不能被一台服务器独立实现的时候，咱们就须要分布式计算。分布式计算技术将一个大型工作切分为多个更小的工作，用多台计算机通过网络组装起来后，将每个小工作交给一些服务器来独立实现，最终实现这个简单的计算工作。本篇咱们介绍两个经典的计算框架 MapReduce 和 Spark。
— MapReduce 批处理引擎 —
MapReduce 是第一个比拟胜利的计算引擎，次要用于数据批处理。因为企业的大数据业务多是围绕结构化数据等价值密度更高的数据开展，所有的大数据公司开始在大数据平台上打造 SQL 引擎或散布数据库。2012 年开始到随后两年中呈现 20 多个基于 Hadoop 的 SQL 引擎，以解决结构化数据问题。
MapReduce 框架是 Hadoop 技术的外围，它的呈现是计算模式历史上的一个重大事件，在此之前行业内大多是通过 MPP(Massive Parallel Programming)的形式来加强零碎的计算能力，个别都是通过简单而低廉的硬件来减速计算，如高性能计算机和数据库一体机等。而 MapReduce 则是通过分布式计算，只须要便宜的硬件就能够实现可扩大的、高并行的计算能力。一个 MapReduce 程序会蕴含一个 Map 过程和一个 Reduce 过程。在 Map 过程中，输出为 (Key, Value) 数据对，次要做过滤、转换、排序等数据操作，并将所有 Key 值雷同的 Value 值组合起来；而在 Reduce 过程中，解析 Map 阶段生成的 (Key, list(value)) 数据，并对数据做聚合、关联等操作，生成最初的数据后果。每个 worker 只解决一个 file split，而 Map 和 Reduce 过程之间通过硬盘进行数据交换，如果呈现任何谬误，worker 会从上个阶段的磁盘数据开始从新执行相干的工作，保证系统的容错性和鲁棒性。
图片来源于《MapReduce: simplified data processing on large clusters》
MapReduce 在设计上并不是为了高性能，而是为了更好的弹性和可扩展性。在等同规模的硬件以及同等量级的数据上，与一些基于关系数据库的 MPP 数据库相比，MapReduce 的剖析性能个别会慢一个数量级，不过 MapReduce 能够反对的集群规模和数据量级要高几个数量级。在 2014 年 Jeff Dean 提出 MapReduce 的论文里提及的相干集群曾经是 1800 台服务器的规模，而当初放眼国内，单个集群超过几千个服务器、解决数据量达到 PB 级别的集群有超过数百个。
除了能够反对 PB 级别的弹性化数据计算外，MapReduce 还有几个很好的架构个性，这些个性也都被起初的一些计算框架（如 Spark 等）无效地继承。第一个个性是简化的编程接口设计，与之前的 MPP 畛域风行的 MPI 等编程接口不同，MapReduce 不须要开发者本人解决并行度、数据分布策略等简单问题，而是须要关注于实现 Map 和 Reduce 对应的业务逻辑，从而大大简化开发过程。另外 MapReduce 的计算基于 key-value 的数据对，value 域能够蕴含各种类型的数据，如结构化数据或图片、文件类非结构化数据，因而 MapReduce 计算框架可能很好地反对非结构化数据的解决。
此外，在容错性方面，因为 MapReduce 的分布式架构设计，在设计之初即设定了硬件故障的常态性，因而其计算模型设计了大量的容错逻辑，如工作心跳、重试、故障检测、重散布、工作黑 / 灰名单、磁盘故障解决等机制，笼罩了从 JobTracker、TaskTracker 到 Job、Task 和 Record 级别的从大到小各个层级的故障解决，从而保障了计算框架的良好容错能力。
而随着企业数据分析类需要的逐步深刻，MapReduce 计算框架的架构问题从 2010 年后也逐步裸露进去。首先就是其性能问题，无论是框架启动开销（个别要数分钟），还是工作自身的计算性能都有余，尤其是在解决中小数据量级的数据工作上与数据库相差太大，不能用于交互式数据分析场景。有意思的是，从 2010 年开始，学术界有大量的论文钻研如何优化 MapReduce 性能，也有多个开源框架诞生进去，但都未能实现性能在量级上的晋升，因而也逐步淡出了历史。第二个重要问题是不能解决实时类数据，因而不能满足一些疾速倒退的互联网场景需要，如实时举荐、实时调度、准实时剖析等。后续 Spark 框架的呈现就优先解决了这几个问题，框架启动开销降到 2 秒以内，基于内存和 DAG 的计算模式无效的缩小了数据 shuffle 落磁盘的 IO 和子过程数量，实现了性能的数量级上的晋升。随着更好的计算框架呈现，MapReduce 逐步退出了支流利用场景，不过其作为分布式计算的第一代技术架构，其在计算技术演进的过程中施展了重要的历史价值。
— Spark 计算框架 —
随着大量的企业开始通过 Hadoop 来构建企业应用，MapReduce 的性能慢的问题逐步成为瓶颈，只能用于离线的数据处理，而不能用于对性能要求高的计算场景，如在线交互式剖析、实时剖析等。在此背景下，Spark 计算模型诞生了。尽管实质上 Spark 依然是一个 MapReduce 的计算模式，然而有几个外围的翻新使得 Spark 的性能比 MapReduce 快一个数量级以上。第一是数据尽量通过内存进行交互，相比拟基于磁盘的替换，可能防止 IO 带来的性能问题；第二采纳 Lazy evaluation 的计算模型和基于 DAG（Directed Acyclic Graph, 有向无环图）的执行模式，能够生成更好的执行打算。此外，通过无效的 check pointing 机制能够实现良好的容错，防止内存生效带来的计算问题。
Spark 实现了一种分布式的内存形象，称为弹性分布式数据集(RDD，Resilient Distributed Datasets)。它反对基于工作集的利用，同时具备数据流模型的特点 主动容错、地位感知调度和可伸缩性。RDD 容许用户在执行多个查问时显式地将工作集缓存在内存中，后续的查问可能重用工作集，这极大地晋升了查问速度。RDD 提供了一种高度受限的共享内存模型，即 RDD 是只读的记录分区的汇合，只能通过在其余 RDD 执行确定的转换操作(如 map、join 和 groupBy) 而创立，然而这些限度使得实现容错的开销很低。与分布式共享内存零碎须要付出昂扬代价的检查点和回滚机制不同，RDD 通过 Lineage 来重建失落的分区一个 RDD 中蕴含了如何从其余 RDD 衍生所必须的相干信息，从而不须要检查点操作就能够重构失落的数据分区。
除了 Spark Core API 以外，Spark 还蕴含几个次要的组件来提供大数据分析和数据挖掘的能力，次要包含 Spark SQL、Spark Streaming、Spark MLLib。
Spark SQL
Spark SQL 是基于 Spark 引擎提供应用 SQL 来做统计分析的模块，因为有较好的 SQL 兼容性，对一般数据开发者应用比较简单，因而在用户中应用比拟宽泛。SparkSQL 充沛排汇了 Hive 等我的项目的架构优缺点，通过无效的模块化以及与 Hive 元数据模块的兼容，使得开发者能够间接用 Spark SQL 来剖析 Hive 中的数据表，而比间接应用 Hive 做剖析可能大幅度提高性能。尔后，Spark SQL 陆续减少了对 JSON 等各种内部数据源的反对，并提供了一个标准化的数据源 API。数据源 API 给 Spark SQL 提供了拜访结构化数据的可插拔机制。各种数据源有了简便的路径去进行数据转换并接入到 Spark 平台进行计算，此外由 API 提供的优化器，在大多数状况下，能够将过滤和列修剪都下推到数据源，从而极大地缩小了待处理的数据量，可能显著进步 Spark 的工作效率。通过这些架构上的翻新，Spark SQL 能够无效地剖析多样化的数据，包含 Hadoop、Alluxio、各种云存储，以及一些内部数据库。
Spark Streaming
Spark Streaming 基于 Spark Core 实现了可扩大、高吞吐和容错的实时数据流解决。Spark Streaming 是将流式计算分解成一系列短小的批处理作业。这里的批处理引擎是 Spark，也就是把 Spark Streaming 的输出数据依照 micro batch size(如 500 毫秒)分成一段一段的数据(Discretized Stream)，每一段数据都转换成 Spark 中 RDD(Resilient Distributed Dataset)，而后将 Spark Streaming 中对 DStream 的转换操作变为针对 Spark 中对 RDD 的转换操作，将 RDD 通过操作变成两头后果保留在内存中。
因为 Spark Streaming 采纳了微批的解决形式，零碎自身的吞吐量比拟高，然而从利用的视角来看，数据从产生到计算构造的延时在 500 毫秒甚至以上，如果一个简单逻辑波及到多个流上的简单运算，这个延时将会进一步放大，因而对一些延时敏感度比拟高的利用，Spark Streaming 的延时过高问题是十分重大的架构问题。Spark 社区也在踊跃的解决相干的问题，从 Spark 2.x 版本开始推出了 Structured Streaming，最实质的区别是不再将数据依照 batch 来解决，而是每个接管到的数据都会触发计算操作并追加到 Data Stream 中，紧接着新追加的记录就会被相应的流利用解决并更新到后果表中，如下图所示。
因为 Structured Streaming 无效地升高了实时计算的延时，此外又是间接基于 Dataframe 和 Dataset API 进行了封装，从而不便与 Spark SQL 以及 MLlib 对接，因而很快便取代了 Spark Streaming 成为 Spark 次要的实时计算计划。尔后，社区很快减少了对数据乱序问题的解决、通过 checkpoint 机制保障 At least once 语义等要害的流计算性能要求，逐渐贴近了生产需要。
Spark MLLib
MLlib 是 Spark 对罕用的机器学习算法的分布式实现，同时包含数据类型、数学统计计算库和算法评测性能，机器学习算法包含分类、回归、聚类、协同过滤、降维等。除了大量的分布式机器学习算法以外，MLlib 中还提供了包含特征提取、特色转换、特征选择等性能。因为基于 Spark 框架，MLlib 有很好的可扩展性和性能，并且提供下层 API 用于定制化的算法开发，因而从推出后就失去宽泛的反对和落地。
— 小结—
分布式计算技术依照其业务场景的不同能够分为离线计算和实时计算，本文介绍了两个具备代表性的离线计算技术 MapReduce 批处理引擎和 Spark 计算框架，那么对于实时数据的解决又该怎么做呢？下一篇将介绍面向交互式剖析的计算引擎 Impala、实时计算引擎 Apache Flink 和星环实时计算引擎 Slipstream。
【参考文献】Dean J, Ghemawat S. MapReduce: simplified data processing on large clusters[J]. Communications of the ACM, 2008, 51(1): 107-113.