大数据分析技术研究报告(三-2)

作者：朱赛凡

2) 并行计算引擎层

(1) 并行计算形式

并行化可以分为水平并行(无依赖并行)与垂直并行(流水线并行)两类。如下图：

如果两个操作OP1、OP2 无相互依赖关系，则称这两个操作相互独立。水平并行化指的是互相独立的多个操作或者一个操作内互相独立的多个子操作分别由不同的处理机并行执行的形式。例如，排序操作、扫描操作由不同处理机并行执行就是水平并行化的实例。

水平并行中一个非常常见的就是基于数据划分的并行，例如MAPREDUCE，就是通过将数据划分到多台服务器上，并行执行MAP和Reduce来进行并行运算。也有人把这种基于数据划分并行与操作独立并行区分开。

垂直并行化则是指存在流水线方式依赖关系的操作分别由不同处理机并行执行的形式。流水线方式依赖：如果OP2无需等待OP1执行完毕即可在另一处理机上开始执行。由于一般情况下，流水的级数远小于处理的数据条目，因此流水并行主要意义是在可以避免中间结果磁盘IO操作，对并行度的贡献相对较小。

 

(2) 并行计算面临的问题与并行计算框架

并行计算需要解决的问题主要包括几下几个方面：自动并行化、通讯、任务调度、并发控制、容错、资源管理。由于并行计算面向上述一系列问题，因为业界为了简化并行程序开发，提供了一系列的并行计算底层库或者框架。

在高性能计算领域，最常用于并行计算编程的库是MPI库，但是该库主要只是解决通讯问题。这导致容错、资源管理、任务调度、并行化等方面问题需要程序员来解决，因此利用MPI开发并行程序相对比较困难。

最近一些年，各大型互联网公司开发开发了一系列的通用并行计算框架。包括谷歌公司的MAPREDUCE框架、微软公司的Dryad框架（目前微软已经停止该项目开发，转而支持hadoop）、谷歌公司基于BSP模型的Pregel框架、Twitter公司的Storm框架、Yahoo公司S4框架、HortonWorks公司的Tez框架、Berkeley大学的spark框架等通用并行计算框架。

有了这些框架了，程序开发时只需要编写串行执行程序即可，而且也不用考虑任务与任务之间的并发控制以及通讯等问题，其它所有问题都有框架来解决 ，这样就大大简化并行程序开发难度。例如采用MAPREDUCE框架，我们只需要提供MAP函数和Reduce函数，这些函数对程序员而言，都只是对本地数据操作。

目前虽然并行计算框架很多，但是可以把它们分成几个大类(基于BSP并行图计算引擎请参考第四章)：

 流数据并行计算框架

Storm、S4是属于流数据并行计算框架，适合对流数据实时处理，也就是在数据写入磁盘前对数据进行实时并发运算。这类特点是计算不变，数据一直在变化。在上一个文档中，对此框架做过详细介绍，这里不再详细介绍。

基于DAG通用批处理并行计算框架

MapReduce、Tez、Dryad、Spark等属于基于DAG(有向无环图)的通用批处理并行计算框架。这类框架是针对存储在存储设备上的一批数据进行分析处理，而且把分析处理流程利用DAG模型来表达。

在这些框架中MAPREDUCE是最早出现的框架，而后面出现的一系列框架都为了改进MR框架不足而出现的升级版本。

MR框架主要不足是两个方面：

一是编程接口太简单，表现在单个MAPREDUCE无法表达复杂运算，所以在实际应用环境中都是通过多个MR作业组合来完成一个任务。为了简化MR作业组合，在早期出现了一系列项目来执行组和式MR作业，例如Cascading项目。另外一个方面所有问题都必须转换为MAP和REDUCE模式，导致程序编写比较麻烦。

二是MR只支持基于数据分区并行方式，不支持流水线并行，采用是步步物化策略来提高可靠性，当是这种导致大量中间结果物化，IO开销非常大。

因此Tez、Dryad、Spark等后续框架改进主要针对以下两点进行改进：

一是直接支持基于DAG结构表达方法，DAG使得用户能够非常清晰地写出非常复杂的业务逻辑；

二是通过支持流水线并性方式或者是尽量将中间结果放内存等方式，解决中间结果物化导致的IO开销问题。Dryad和Spark框架在执行运算时，都会自动识别可以采取流水线方式执行的计算步骤，并尽量采用流水线执行方式来执行。

容错：由于支持流水线并行或者采取把中间结果放内存的方式，因此要必须考虑容错的问题。由于这些框架都采用的是DAG结构，DAG中一个节点所代表计算的执行是不会对输入进行修改(所谓函数式编程)，因此可以多次重复执行不会影响计算。因此如果某个节点计算失败，它可以根据输入重复计算，而如果输入数据也消失了，则让前一个节点重新计算。所有这一切都是由框架自动执行。

当然需要指出的是对一些流水线执行的多个计算步骤，如果某个计算节点失败，则只能整个流水线整体失败。

 

基于Tree结构的MPP并行查询引擎

MPP并行数据库与Dremel、impala、Presto、Shard query、Citusdb都采用的是基于Tree结构并行查询引擎。此类并行计算引擎共同特点是：

一是针对SQL专用并行计算引擎，只支持SQL或者类SQL语义。

二是执行计划都是树状结构；

三是以流水线或者将中间结果放入内存方式来实现快速计算。

四是粗粒度容错机制。

它们之间不同点：

一 MPP并行数据库中并行查询引擎与底层存储是紧耦合的，导致如果采用MPP并行数据库，则只能通过SQL来访问数据，无法采用其他计算引擎直接处理存储在数据库中的数据。

二 Impala、Presto都只是一个并行查询引擎，它们可以直接查询以文件方式存储在HDFS上的数据,这样同一份数据既可以利用这些引擎来实现交互式查询，也可以支持利用其他计算框架进行更深入分析。

三 Dremel 只支持Google自己的基于嵌套结构列式存储(Column IO)。该引擎也主要适合于聚合型计算，不支持join操作。

四 上述引擎中只有MPP并行数据库可以利用索引以及各种统计信息来优化物理执行过程，因此该系统执行效率应该是最高。

五 Dremel、impala都只适合中间结果越来越小的查询，因为这些系统都是把中间结果放在内存，一旦某个中间节点输出结果超过内存，则整个任务会失败，例如大表之间Join。

六 shard query和citusdb 都是在单机版本关系数据库基础上，采用增加一层中间件方式来支持并行查询。

n基于Tree并行计算引擎与基于DAG并行计算引擎本质区别

基于Tree结构并行计算引擎与基于DAG并行计算引擎从表面上看，它们之间的主要区别是在于语义层面：前者主要专用与SQL类，而后者更通用。

但是MPP并行关系数据库引擎、Imapla等都会支持通过UDF来扩展和解决标准SQL语言表达能力，另外SQL语言本身可以通过嵌套查询、子查询、union等各种方法表达很复杂的计算过程，因此从语义表达层面来讲他们之间不存在本质区别。

这两者之间主要区别还是在于表达执行计划结构方面：树结构是一个逐步汇聚的一个计算过程，无法表达split结构，因此基于DAG表达结构更灵活和通用。个人认为：树型结构可能更加适合采用迭代器模型来实现流水线式的操作(只有树结构才有上下层的关系，因此方便实现上层操作符嵌套调用下层操作符)。

所以不是所有计算都可以通过一个复杂SQL语句来表达！

 

 (5) 自动并行化、数据重分布、本地调度

并行计算引擎最重要的一个职责是自动并行。根据前面的并行计算基础知识，并行计算的形式主要包括：基于数据划分水平并行、基于流水线垂直并行、基于无依赖水平并行三种方式。

大数据属于数据密集型计算，数据数量远远超过计算步骤数量。因此基于数据划分并行方式是最有效的一种并行计算方法。在整个并行计算过程中，基于数据划分中涉及数据可以分为两大类：原始数据与中间结果数据。

n 原始数据划分以及SN、SD架构讨论

原始数据则可能存在两种情况：一是在Shared-nothing架构中，原始数据本身就已经划分好了，例如HDFS或者SN架构 MPP数据库；另外一种情况如shared-disk结构中，原始数据没有划分。

第一种情况下针对原始数据划分并行计算，就要受该划分的限制。例如在MAPREDUCE中，map输入是存储在HDFS上的数据文件，因此MAP实例个数一是不能少于该数据文件分片数，二是MAP实例最好运行在该数据文件所在机器，也就是要求任务调度时，能把该任务调度到特定机器上，即所谓“本地调度”，将计算尽量移动到数据。

第二种情况下，由于所有计算节点都可以看到所有数据，因此此时可以根据计算特点灵活选择：数据划分粒度、并行度、参与计算的节点。例如在ORALCE并性机制中，ORALCE可以针对某张表，按block或者partition 为单位进行划分。

根据上述分析我们可以发现SD架构相对SN架构，在针对原始数据第一级并性计算时，SD架构更灵活，SN架构面临的一个缺陷就是如果原始数据分布不均衡，则存在计算倾斜问题。

但是现在大部分大的数据库厂商的MPP数据库还是采用了SN架构。根据网上所查资料来看,主要原因有两点：

一是SD架构下，磁盘是一个共享资源，计算节点越多磁盘争抢概率越大(和RAID随机IO冲突道理一样)，导致该架构可扩展性不够好，也就是可能计算节点越多，效率相反不会提高。

 二是从缓存角度来看，SD架构下每个机器缓存都要面向全数据库，会导致命中概率底下；目前ORACLE-RAC开发一个fusion cache技术，实现了一个全局共享缓存来解决上述问题，但是可想而知这会影响系统可扩展性。

因此超过一定规模数据分析系统，都是采用SN架构。

中间结果数据划分与数据重分布

中间结果是由各个计算节点产生的，因此中间结果生成是就是分布在各个参与计算节点之上的，因此：

一 ：SD架构下数据共享好处，对中间结果无效。

二 ：如果由于计算任务之间需要，需要在任务之间传递中间结果，则即使是SD架构也存在数据重分布的问题，主要是中间结果重分布，也就是中间结果传输。

另外从该过程我们还可以得出另外一个结论：

一： 对于复杂的数据处理，索引只能影响第一级计算，对于中间结果，由于只使用一次，因此没有必要去针对中间结果建立索引。也就是即使我们将数据存储在关系型数据库中，也只有第一级计算能有效利用数据库索引。

二：即使采用并行数据库，如果我们的整个计算过程不能用一个SQL语句来表达，则我们必须自己解决中间结果的划分与并性计算的问题。

(6)并行计算引擎架构与资源管理

所有并行计算引擎实现基本上都是主从结构，即一个MASTER + 多个slave节点的结构。由client向MASTER提交一个job,然后由Master负责将逻辑执行计划变成实际执行计划，并由Master负责将各个任务分发到各个slave中，并负责各个任务的调度。

MPP数据库查询引擎架构

 

 

 

 

MAPREDUCE架构和该架构缺点

Mapreduce框架中，JobTracker承当MASTER的职责，一般和HDFS中的NadeNode节点安装在一个服务器上。TaskTracker安装在各个DataNode上，承担Slave的角色。

  

流程如下：

(1)首先用户程序(Client Program)提交了一个job，job的信息会发送到Job Tracker中，Job Tracker是Map-reduce框架的中心，他需要与集群中的机器定时通信(heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有job失败、重启等操作。

(2)TaskTracker是Map-reduce集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况（资源的表示是“本机还能起多少个map-task，多少个reduce-task”，每台机器起map/reduce task的上限是在建立集群的时候配置的），另外TaskTracker也会监视当前机器的tasks运行状况。

(3)TaskTracker需要把这些信息通过heartbeat发送给JobTracker，JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上。

MAPREDUCE结构存在以下缺点：

(1) jobtracker只能安装在一台服务器上，集中式作业控制导致可扩展性不好，另外JobTracker负责事情太多，容易成为性能瓶颈。

(2) 资源调度与编程模型紧耦合，只支持MAPREDUCE一种编程模型。

(3) 资源划分太简单，每个TaskTracker只是简单把整个机器资源按map task slot和reduce task slot来划分，而没有考虑不通任务所需的内存和CPU等的资源不同。

针对上述特点，hadoop平台开发通用的资源管理器yarn，只负责资源管理和分配，即通过把jobtrack中的资源管理分配自和并行应用程序调度与控制分离，从而实现双层调度框架：由yarn把资源分配给各计算引擎MASTER，再由MASTER分配给各个TASK。

 资源管理器YARN

 

流程如下：

1)  client 通过一个CLC (container launch  context )向ResourceManager提交一个应用

2)RM 启动该应用的 AplicationMaster。 AplicationMaster启动后先向ResourceManager注册，并利用心跳信息，定期向ResourceManager报告自己存活性和资源分配请求

3)ResourceManager分配一个container(container包括CPU个数和所需内存数量)时， AplicationMaster构造一个CLC,并在该container对应机器上Nodemanager上启动该container。AplicationMaster 监控该container的运行状态，并且该资源需要被回收时，由AplicationMaster停止该container。 监控container内部的作业的执行进度是AplicationMaster的职责。

4)一旦整个运行完毕，AM从RM中解除注册，并且干净退出。

 这种架构优点是：

优点一：减小了JobTracker（也就是现在的ResourceManager）的资源消耗，并且让监测每一个Job子任务(tasks)状态的程序分布式化了，更安全、更优美。也就是ApplicationMaster是每个应用一个，并且不通应用对应的ApplicationMaster的实例可以运行在不同服务器上。

优点二：能够支持不同的编程模型ApplicationMaster是一个可变更的部分，用户可以对不同的编程模型写自己的ApplicationMaster，让更多类型的编程模型能够跑在Hadoop集群中。

优点三：对于资源的表示比之前以剩余slot数目更合理。