首页 > 其他分享> > 关于SPARK的与周边比较

关于SPARK的与周边比较

2021-11-12 09:05:12 作者：互联网

Spark学习笔记(一)之基础篇

2019-11-11

Spark学习笔记

333

Spark简介

Spark是美国加州大学伯克利分校的AMP实验室(主要创始人lester和Matei)开发的通用的大数据处理框架.

Spark有4中运行模式:

local模式,适用于测试
standalone,并非是单节点,而是使用spark自带的资源调度框架
yarn,最流行的方式,使用yarn集群调度资源
mesos,国外使用的多

Spark比MapReduce快的原因

Spark基于内存迭代,而MapReduce基于磁盘迭代
- MapReduce的设计:中间结果保存到文件,可以提高可靠性,减少内存占用,但是牺牲了性能.
- Spark的设计:数据在内存中进行交换,要快一些,但是内存这个东西,可靠性比不过MapReduce.
DAG计算模型在迭代计算上还是比MR的更有效率. > 在图论中,如果一个有向图无法从某个顶点出发经过若干条边回到该点,则这个图是一个有向无环图(DAG)
Spark是粗粒度的资源调度,而MR是细粒度的资源调度.

DAG计算模型在Spark任务调度中详解

Spark 计算比 MapReduce 快的根本原因在于DAG计算模型.

一般而言,DAG 相比 MapReduce 在大多数情况下可以减少 shuffle 次数.
Spark 的 DAGScheduler 相当于一个改进版的 MapReduce ,如果计算不涉及与其他节点进行数据交换,Spark 可以在内存中一次性完成这些操作,也就是中间结果无须落盘,减少了磁盘IO的操作.但是,如果计算过程中涉及数据交换,Spark也是会把shuffle的数据写磁盘的!
有一个误区,Spark 是基于内存的计算,所以快,这不是主要原因,要对数据做计算,必然得加载到内存,Hadoop 也是如此,只不过Spark支持将需要反复用到的数据给Cache到内存中,减少数据加载耗时,所以Spark跑机器学习算法比较在行(需要对数据进行反复迭代).Spark基于磁盘的计算也是比 Hadoop 快.
刚刚提到了Spark 的DAGScheduler是个改进版的 MapReduce ,所以 Spark 天生适合做批处理的任务. Hadoop 的M apReduce 虽然不如 Spark 性能好,但是 HDFS 仍然是业界的大数据存储标准.

Spark 生态系统

Spark生态圈以Spark Core为核心,从HDFS、Amazon S3和HBase等持久层读取数据,以MESS、YARN和自身携带的Standalone为资源管理器调度Job完成Spark应用程序的计算. 这些应用程序可以来自于不同的组件,如Spark的批处理、Spark Streaming的实时处理应用、Spark SQL的即席查询、MLlib的机器学习、GraphX的图处理等等.

Spark Core

Spark Core 是整个 BDAS 生态系统的核心组件,是一个分布式大数据处理框架,Spark Core 提供了多种资源调度管理,通过内存计算、有向无环图(DAG)等机制保证分布式计算的快速,并引入了 RDD 的抽象保证了数据的高容错性.

提供了多种运行模式;
提供 DAG 的分布式并行计算框架,并提供内存机制来支持多次迭代计算或者数据共享;
引入 RDD 的抽象,是分布在一组节点中的只读对象集合,这些集合是弹性的,如果部分丢失可通过 血统 进行重建,保证数据高容错性.

Spark Streaming

Spark Streaming 是一个对实时数据流进行高吞吐、高容错的流式处理系统,可以对多种数据源进行类似 Map、Reduce 和 Join 等复杂操作,并将结果保存到外部文件系统、数据库或应用到实时仪表盘.

动态负载均衡
快速故障恢复机制
批处理、流处理与交互式分析的一体化

Spark SQL

Hive 是 Shark 的前身,Shark 是 Spark SQL 的前身, Spark SQL 产生的根本原因是其完全脱离了 Hive 的限制.

引入新的 RDD 类型 SchemaRDD, 可以向传统数据库定义表一样定义 Schema RDD;
内嵌 Catalyst 查询优化框架,将 SQL 解析成逻辑执行计划后,变成 RDD 的计算
可以混合使用不同来源的数据

Spark SQL 性能提升的原因

内存列存储.在内存中存储不是采用原生态的 JVM 对象存储方式,采用内存列存储.
字节码生成技术.在 Catalyst 模块的 Expressions 增加了 Codegen 模块,使用动态字节码生成技术,对匹配的表达式采用特定的代码动态编译.
Scala 代码优化.

BlinkDB

BlinkDB 是一个用于海量数据上运行交互式 SQL 查询的大规模并行查询引擎,允许用户通过权衡数据精度来提升响应时间,其数据精度被控制在允许的误差范围内.

自适应优化框架.从原始数据随时间的推移建立并维护一组多维样本.
动态样本选择策略.选择一个适应大小的示例,该示例基于查询的准确性和响应时间的紧迫性.

MLBase/MLlib

MLBase 是 Spark 中专注于机器学习的组件,目标是让机器学习的门槛更低.

MLRuntime:由 Spark Core 提供的分布式内存计算框架,运行由 Optimizer 优化过的算法进行数据的计算并输出分析结果.
MLlib:是 Spark 实现一些常见的机器学习算法和实用程序,包括分类、回归、聚类、协同过滤、降维以及底层优化.该算法可以进行可扩充.
MLI:是一个进行特征抽取和高级ML 编程抽象算法实现的 API 或平台.
MLOptimizer:会选择它认为最适合的已经在内部实现好了的机器学习算法和相关参数,来处理用户输入的数据,并返回模型或其他帮助分析的结果.

MLBase 与其他机器学习Weka 和Mahout 不同,三者各有特色,具体内容如下.

MLBase 基于Spark,它是使用的是分布式内存计算的;Weka 是一个单机的系统,而 Mahout 是使用 MapReduce 进行处理数据(Mahout 正向使用 Spark 处理数据转变).
MLBase 是自动化处理的;Weka 和 Mahout 都需要使用者具备机器学习技能,来选择自己想要的算法和参数来做处理.
MLBase 提供了不同抽象程度的接口,可以由用户通过该接口实现算法的扩展.

GraphX

GraphX 最初是伯克利 AMP 实验室的一个分布式图计算框架项目,后整合为 Spark 中成为一个核心组件.在Spark中用于图和图并行计算的API,可认为是 GraphLab 和 Pregel 在 Spark 上的重写及优化.

GraphX 的核心抽象是 Resilient Distributed Property Graph ,一种点和边都带属性的有向多重图. GraphX 扩展了Spark RDD 的抽象,它有 Table 和 Graph 两种视图,但只需要一份物理存储,两种视图都有自己独有的操作符,从而获得了灵活操作和执行效率.GraphX 的整体架构中大部分的实现都是围绕 Partition 的优化进行的,这在某种程度上说明了,点分割的存储和相应的计算优化的确是图计算框架的重点和难点.

对 Graph 视图的所有操作,最终都会转换成其关联的 Table 视图的 RDD 操作来完成.这样对一个图的计算,最终在逻辑上,等价于一系列RDD 的转换过程.因此,Graph 最终具备了RDD 的3 个关键特性:Immutable、Distributed 和 Fault-Tolerant.其中最关键的是Immutable(不变性).逻辑上,所有图的转换和操作都产生了一个新图;物理上,GraphX 会有一定程度的不变顶点和边的复用优化,对用户透明.
两种视图底层共用的物理数据,由 RDD[Vertex-Partition] 和 RDD[EdgePartition] 这两个RDD 组成.点和边实际都不是以表 Collection[tuple] 的形式存储的, 而是由VertexPartition/EdgePartition 在内部存储一个带索引结构的分片数据块,以加速不同视图下的遍历速度.不变的索引结构在 RDD 转换过程中是共用的,降低了计算和存储开销.
图的分布式存储采用点分割模式,而且使用 partitionBy 方法,由用户指定不同的划分策略(PartitionStrategy).划分策略会将边分配到各个 EdgePartition ,顶点 Master 分配到各个 VertexPartition,EdgePartition 也会缓存本地边关联点的Ghost 副本.划分策略的不同会影响到所需要缓存的 Ghost 副本数量,以及每个EdgePartition 分配的边的均衡程度,需要根据图的结构特征选取最佳策略.

Alluxio

Alluxio 是一个分布式内存文件系统,他是一个高容错的分布式文件系统,允许文件以内存的速度在集群框架内进行可靠的共享.

Alluxio 是假设在底层的分布式文件存储和上层的各种计算框架之间的一种中间件.主要职责是将不需要落到 DFS 里的文件,落地到分布式内存文件系统中,来达到共享内存等目的.

JAVA-Like File API
兼容性:实现了 HDFS 接口, 所以 Spark 和 MapReduce 程序不需要任何修改即可运行.
可插拔的底层文件系统:提供容错功能,将内存数据记录在底层文件系统.