《企业级大数据平台构建：架构与实现》——2.5　Spark

2.5　Spark

2.5.1　概述

十年前我们只有Hadoop，大家首先通过HDFS实现海量数据的共享存储，然后使用MapReduce以批处理的方式处理这些海量数据，这一切看起来似乎十分完美。但众口难调啊，有人觉得MapReduce的编程模型太难使用了，为什么不能使用SQL来分析数据呢？我们数据库领域已经有非常成熟的数据仓库模型了，为何不实现一个大数据技术的数据仓库呢？于是Hive类的框架便诞生了，人们开始使用Hive类的框架来构建大数据技术的数据仓库，使用SQL查询数据。接着人们又开始诟病MapReduce的执行效率太慢，因为它本质上是面向批处理场景的，难以支撑一些实时性要求很高的场景，我们需要一种能够支撑流计算的架构，于是Storm类的框架诞生了。人们开始使用Storm这类框架处理流计算场景。接着伴随垃圾邮件分析、商品推荐、金融风控这类应用场景需求的出现，又迫使我们需要在大数据场景下具备机器学习的能力，于是乎Mahout类的框架出现了，人们使用它们来进行大数据下的机器学习。

随着越来越多来自应用领域的细分需求，人们从最初Hadoop的HDFS和Map-Reduce开始，一步步地构造出了各种细分领域的技术框架。有专攻处理批处理场景的，有专攻数据仓库场景的，有处理流计算场景的，也有专职机器学习的。在我看来这有点像在给Hadoop打补丁，因为Hadoop在设计之初根本没有考虑过这么多的场景，它只是为了支撑离线批处理。但是需求摆在这里，为了实现目标只得另起炉灶通过设计一个全新的系统满足需求。这种现状造成了很多问题。

重复工作：不同的系统之间都需要解决一些相同的共性问题，比如分布式执行和容错性。例如MapReduce、SQL查询引擎和机器学习系统都会涉及聚合操作。

组合：不同系统之间的组合使用非常“昂贵”，因为不同系统之间无法有效的功效数。为了组合使用我们需要将数据在不同的系统之间频繁的导出导入，数据用来移动的时间可能都会超过计算的时间。

维护成本：虽然这些系统从每个个体的角度来看都十分优秀，但是它们都是在不同时期由不同的团队设计实现的，其设计思路和实现方式也各不相同。这导致平台在部署运维这些系统的时候十分痛苦，因为它们差异太大了。

学习成本：系统之间巨大的差异性对于开发人员来讲更是如此，这些技术框架拥有不同的逻辑对象、专业术语、API和编程模型，每种框架都需要重新学习一遍才能使用。

Spark意识到了这个问题，作为一个后起之秀它拥有天然的优势。Spark诞生于2012年，那个时候Hadoop生态已经经过了6个年头的发展，其生态格局已经成型。Spark已经能够看清大数据有哪些细分领域，同时MapReduce、Hive、Storm等开源组件也已经发展多年，Spark也能够了解到它们的长处和不足。

于是Spark横空出世，成为目前开源社区最为火爆的一款分布式内存计算引擎。Spark使用DAG（有向无环图）模型作为其执行模型，并且主要使用内存计算的方式进行任务计算。Spark基于一套统一的数据模型（RDD）和编程模型（Trans-foration /Action）之上，构建出了Spark SQL、Spark Streaming、Spark MLibs等多个分支，其功能涵盖了大数据的多个领域，如图2-14所示。

图2-14　Spark涵盖的领域

Spark通过统一的数据模型和编程模型，构造出了SQL查询、流计算、机器学习和图计算等多个分支库