大数据处理框架概览

第一章 大数据处理框架概览

1.1 大数据及其带来的挑战

大数据概念：

具有数据量大、数据类型多样、产生与处理速度快、价值高的“4V”特性。

带来的挑战

传统数据处理系统难以在可接受的时间范围内对大数据进行高效处理。

OLTP（在线事务处理）

21世纪70年代的关系型数据库解决了关系型数据的存储与OLTP问题

OLAP（在线分析处理）

数据仓库解决了数据建模及OLAP问题

1.2 大数据处理框架

为了高效处理大数据，工业界和学术界提出了很多分布式大数据处理框架。

2004年Google在计算机系统领域顶级会议OSDI上提出了基于==分治、归并和函数式编程思想==的MapReduce分布式计算框架。

随后，Apache社区对==Google File System和MapReduce进行了开源实现，并命名为Hadoop==。

2007年微软公司提出了Dryad分布式计算框架。Dryad不同于MapReduce固定的数据处理流程，Dryad允许用户将任务处理组织成有向无环图（Directed Acyclic Graph，DAG），来获取更强大的数据处理表达能力。

2012年UC Berkeley的AMPLab提出了基于内存，适合迭代计算的Spark分布式处理框架。该框架允许用户将可重用的数据缓存（cache）到内存中，同时利用内存进行中间数据的聚合，极大缩短了数据处理时间。

这些大数据处理框架拥有共同的编程模型，即MapReduce模型，采用“分治-聚合”策略来对数据进行分布并行处理。

1.3 大数据应用及编程模型

大数据应用在工业界和学术界广泛存在，在网页索引的构建、日志挖掘、大数据SQL查询、机器学习、社交网络图分析等。

**MapReduce编程的局限性，该模型不能直接对多张表格数据进行join()。**表示疑问？

为了提高MapReduce编程模型的通用型，Dryad和Spark设计了一些更一般的、对用户友好的操作符，如：faltMap()、groupByKey()…

出了编程模型开发的大数据应用，用户也可以借助构建于框架之上的高层语言或高层库开发大数据应用。

在Hadoop MapReduce之上，Yahoo！开发了SQL-like的Pig Latin语言，可以将SQL-like脚本转化成Hadoop MapReduce作业；

Facebook开发的分布式数据仓库Hive构建在Hadoop MapReduce之上，也可以将类SQL查询分析语言转化成Hadoop MapReduce作业；

Apache Mahout提供了基于Hadoop MapReduce的机器学习库；

在Spark之上，GraphX提供了面向大规模图处理的库，Mlib提供了面向大规模机器学习的库，Spark SQL提供了基于Spark的SQL查询框架及语言。

1.4 大数据处理框架的四层结构

一个大数据应用可以表示为<输入数据，用户代码，配置参数>。用户在向大数据处理框架提交应用之前需要指定数据存储位置，撰写数据处理代码，并设定配置参数。之后，用户将应用提交给大数据处理框架运行。

大数据处理框架大体可以分为四层结构：用户层、分布式数据并行处理层、资源管理与任务调度层、物理执行层。

1.4.1用户层

用户层方便用户开发大数据应用。我们将一个大数据应用表示为<输入数据，用户代码，配置参数>。

1. 输入数据（要处理的数据）

   	对于批式大数据处理框架，如Hadoop、Spark，用户在提交作业（job）之前，需要提前准备好输入数据。输入数据按照hdfs默认配置文件大小（一般是128MB）存放在HDFS上。
   	对于流式大数据处理框架，如 SparkStreaming（微批次准实时）和 APache Flink，输入数据可以来自网络流（socket）、消息队列（Kafka）等。数据以微批或者连续的形式进入大数据处理框架。
   

2. 用户代码

   	用户代码可以是用户手写的MapReduce代码，或者是基于其他大数据处理框架的的具体应用处理流程的代码。
   	Hadoop MapReduce提供的map()和reduce()函数的处理逻辑比较固定单一，难以支持复杂数据操作，如常见的排序操作sort()、数据库表的关联操作join()等。为此Dryad和Spark提供了更加通用的数据操作符，如flatMap()等。
   

   ​ 在实际系统中，用户撰写用户代码后，大数据处理框架会生成一个Driver程序，将用户代码提交给集群运行。

   ​ 在Hadoop MapReduce中，Driver程序负责设定输入/输出数据类型，并向Hadoop MapReduce框架提交作业。

   ​ 在Spark中，Driver程序不仅可以产生数据、广播数据给各个task，而且可以收集task运行结果，最后在Driver程序的内存中计算出最终结果。

3. 配置参数

   ​ 一个大数据应用可以有很多配置参数，如Hadoop支持200多个配置参数。这些配置参数可以分为两大类：一类是与资源相关的配置参数，另一类是与数据流相关的配置参数

   • 与资源相关的配置参数

     	buffer size 定义框架缓冲区大小，影响map/reduce任务的内存用量。
     	heap size 在Hadoop中，map/reduce任务实际启动一个JVM来运行，因此用户还要设置JVM的大小，就是heap size
     	在Spark中，map/reduce任务在资源容器(ExecutorJVM)中以线程的方式执行，用户需要估算应用的资源需求量，并设置应用需要的资源容器个数，CPU个数和内存大小。
     

   • 与数据流相关的配置参数

     	Hadoop 和 Spark 中都可以设置partition()函数、partition个数和数据分块大小。
     	partition()函数定义如何划分map()的输出数据。
     	partition个数定义产生多少个数据分块，也就是有多少个reduce任务会被reduce任务会被执行。
     	数据分块大小定义map任务的输入数据大小。
     

1.4.2 分布式数据并行处理层

分布式数据并行处理层首先将用户提交的应用转化为较小的计算任务，然后通过调用底层的资源管理与任务调度层实现并行执行。

	在Hadoop MapReduce中，这个转化过程是直接的。因为MapReduce具有固定的执行流程（map-Shuffle-reduce）,可以直接将包含map/reduce的函数的作业划分为Map和Reduce两个阶段，map阶段包含多个可以并行执行的map任务，reduce阶段包含多个可以并行执行的reduce任务。

	与Hadoop MapReduce不同，Spark上应用的转化包含两层：逻辑处理流程、执行阶段啊与执行任务划分。
	Spark首先根据用户代码中的数据操作语义和操作顺序，将代码转化为逻辑处理流程。逻辑处理流程包含多个数据单元和数据依赖，每个数据单元包含多个数据分块。然后，框架对逻辑处理流程进行划分，生成物理执行计划。
	物理执行计划包含多个执行阶段（stage），每个执行阶段包含若干执行任务（task）。
	为了将用户代码转化为逻辑处理流程，Spark/Dryad对输入/输出、中间数据进行了更具体的抽象处理，将这些数据用一个统一的数据结构表示。在Spark中，输入/输出、中间数据被表示为RDD（Resilient Distributed Datasets， 弹性分布式数据集）
	为了将逻辑处理流程转化为物理执行计划，Spark首先根据RDD之间的数据依赖关系，将整个流程分为多个小的执行计划（stage），计算任务的个数一般与RDD的分区数相同。

1.4.3 资源管理与任务调度层

从系统架构上讲，大数据处理框架一般是主-从（Master-Worker）结构。主节点（Master节点）负责接收用户提交的应用，处理请求，管理应用运行整个生命周期。从节点（Worker节点）负责执行具体的数据处理任务（task），并在运行过程中向主节点汇报任务的执行状态。

在运行大数据应用之前，大数据处理框架还需要对用户提交的应用（job）及其计算任务（task）进行调度。任务调度器有FIFO、容量、公平。

1.4.4 物理执行层

大数据处理框架的物理执行层负责启动task，执行每个task的数据处理步骤。在Hadoop MapReduce中，一个应用需要经历map、shuffle、reduce3个数据处理阶段。而在Spark中，一个应用可以有更多的执行阶段（Stage），每个阶段也包含多个task。

在Hadoop MapReduce中，每个task对应一个进程，也就是说每个task以JVM的方式执行，所以在Hadoop MapReduce中task内存用量指的是JVM的堆内存用量。在Spark中，每个task对应JVM中的一个线程，而一个JVM可能运行了多个task，因此JVM的内存空间由task共享。

从应用特点来分析，我们可以将task执行过程中主要消耗内存的数据分为以下三类：

1. 框架执行时的中间数据。例如，map()输出到缓冲区的数据和reduce task在Shuffle阶段暂存到内存中的数据。

2. 框架缓存数据。例如，在Spark中，用户调用cache()接口缓存到内存中的数据。

3. 用户代码产生的中间计算结果。例如，用户调用map(),reduce(),combine(),在处理输入数据时会在内存中产生中间计算结果

1.5 错误容忍机制

由于不能避免系统和用户代码的Bug、节点宕机、网络异常、磁盘损坏等软硬件可靠性问题，分布式文件系统在设计时一般都会考虑错误容忍机制，在实现时也会针对各种失效情况采用相对措施。

1.6 关于Spark Sql

基于RDD应用的逻辑处理流程和物理执行计划与Spark Sql应用的Logical plan 和Physical plan有所不同。

基于RDD应用的逻辑处理流程指的是一系列RDD操作形成的输入/输出、中间数据及数据之间的依赖关系；物理执行计划指的是具体的执行计划（stage）和执行任务（task）。

Spark Sql应用中的Logical Plan指的是将SQL脚本转化后的逻辑算子树，包含各种SQL操作，如Project（）、fillter（）、join（）等；而Physical plan指的是对逻辑算子树进行转化后形成的物理算子树，树中的节点可以转化为RDD等操作，也可以直接生成实现Project（）、filter（）、join（）等操作的Java代码。