spark架构(spark架构中的组件)
本篇文章给大家谈谈spark架构,以及spark架构中的组件对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
本文目录一览:
Spark对硬件的要求
Spark对硬件的要求
估计所有的spark开发者都很关心spark的硬件要求。恰当的硬件配置需要具体情况具体分析,在这里给出以下建议。主要译自官网
一,存储系统
因为大多数Spark工作可能需要从外部存储系统(例如Hadoop文件系统或HBase)中读取输入数据,所以将spark尽可能部署到靠近存储系统很重要。所以,有如下建议:
1,如果可能,在与HDFS相同的节点上运行Spark。最简单的方式是将spark的Standalone集群和hadoop集群安装在相同的节点,同时配置好Spark和hadoop的内存使用,避免相互干扰(对于hadoop,每个task的内存配置参数是mapred.child.java.opts;mapreduce.tasktracker.map.tasks.maximum 和mapreduce.tasktracker.reduce.tasks.maximum决定了task的数目)。也可以将hadoop和spark运行在共同的集群管理器上,如mesos和 yarn。
2,如果不可能,请在与HDFS相同的局域网中的不同节点上运行Spark。
3,对于低延迟数据存储(如HBase),可能优先在与存储系统不同的节点上运行计算任务以避免干扰。
二,本地磁盘
虽然Spark可以在内存中执行大量的计算,但它仍然使用本地磁盘来存储不适合RAM的数据,以及在stage之间,也即shuffle的中间结果。建议每个节点至少有4-8块磁盘,并且不需要RAID,仅仅是独立的磁盘挂在节点。在Linux中,使用noatime选项安装磁盘,以减少不必要的写入。在spark任务中,spark.local.dir配置可以十多个磁盘目录,以逗号分开。如果运行在hdfs上,与hdfs保持一致就很好。
使用noatime选项安装磁盘,要求当挂载文件系统时,可以指定标准Linux安装选项(noatime),这将禁用该文件系统上的atime更新。磁盘挂在命令:
mount -t gfs BlockDevice MountPoint -onoatime
BlockDevice 指定GFS文件系统驻留的块设备。
MountPoint 指定GFS文件系统应安装的目录。
例子:
mount -t gfs /dev/vg01/lvol0 /gfs1 -onoatime
三,内存
单台机器内存从8GB到数百GB,spark都能运行良好。在所有情况下,建议仅为Spark分配最多75%的内存;留下其余的操作系统和缓冲区缓存。
需要多少内存取决于你的应用程序。要确定你的应用的特定数据集需要多大内存,请加载部分数据集到内存,然后在Spark UI的Storage界面去看它的内存占用量。
请注意,内存使用受到存储级别和序列化格式的极大影响 - 有关如何减少内存使用的技巧,请没哪参阅另一篇调优的文章。
最后,请注意,对于超过200GB的内存的机器JAVA VM运行状态并不一直表现良好。如果买的机器内存超过了200GB,那么可以在一个节点上运行多个worker。Spark Standalone模式下,可以在配置文件 conf/spark-env.sh中设置SPARK_WORKER_INSTANCES的值来设置单节点worker的数目。也可以设置SPARK_WORKER_CORES参数来设置每个Worker的cpu数目。
四,网络
根据以往的经验,假如数据是在内存中,那么spark的应用的瓶颈往往就在网络。用10 Gigabit或者更高的网络,是使spark应用跑的最更快的最佳方式。特别是针对“distributed reduce”应用,如group-bys,reduce-bys和sql joins,就表现的更加明显。在任何给定的应用程序中,可以通过spark ui查看spark shuffle过程夸网络传输了多少数据。
五, cpu
对于每台机器几十个cpu的机器,spark也可以很好的扩展,因为他在线程谨脊之间执行最小的共享cpu。应该每台机器至少配置8-16个内核。根据cpu负载,可能需要更多的cpu:一旦数据在内存中,大多数应用程序的瓶颈就在CPU和网络。
推荐阅读:祥察渗
面试必备|spark 高层通用调优
Spark Adaptive Execution调研
Spark 的硬件配置
从MapReduce的兴起,就带来一种思路,就是希望通过大量廉价的机器来处理以前需要耗费昂贵资源的海量数据。这种方式事实上是一种架构的水平伸缩模式——真正的以量取胜。毕竟,以现在的硬件发展来看,CPU的核数、内存的容量以及海量存储硬盘,都慢慢变得低廉而高效。然而,对于商业应用的海量数据挖掘或分析来看,硬件成本依旧是开发商非常关注的。当然最好的结果是:既要马儿跑得快,还要马儿少吃草。
\\
Spark相对于Hadoop的MapReduce而言,确乎要跑得迅捷许多。然而,Spark这种In-Memory的计算模式,是否在硬件资源尤其是内存资源的消耗上,要求更高呢?我既找不到这么多机器,也无法租用多台虚拟instance,再没法测评的情况下,只要寻求Spark的官方网站,又或者通过Google搜索。从Spark官方网站,Databricks公司Patrick Wendell的演讲以及Matei Zaharia的Spark论文,找到了一些关于Spark硬件配置的支撑数据。
\\
Spark 与存储系统
\\
如果Spark使用HDFS作为存储系统,则可以有效地运用Spark的standalone mode cluster,让Spark与HDFS部署在同一台机器上。这种模式的部署非常简单,且读取文件的性能更高。当然,Spark对内存的使用是有要求的,需要合理分配它与HDFS的资源。因此,需要配置Spark和HDFS的环境变量,为各自的任务分配内存和CPU资源,避免相互之间的资源争用。
\\
若HDFS的机器足够好,这种部署可以优先考虑。若数据处理的执行效率要求非常高,那么还是需要采用分离的部署模式,例如部署在Hadoop YARN集群上。
\\
Spark 对磁盘的要求
\\
Spark是in memory的迭代式运算平台,因此它对磁盘的要求不高。Spark官方推荐为每个节点配置4-8块磁盘,且并不需要配置为RAID(即将磁盘作为单独的mount point)。然后,通过配置spark.local.dir来指定磁盘列表。
\\
Spark 对内存的要求
\\
Spark虽然是in memory的运算平台,但从官方资料看,似乎本身对内存的要求并不是特别苛刻。官方网站只是要求内存在8GB之上即可(Impala要求机器配置在128GB)。当然,真正要高效处理,仍然是内存越大越好。若内存超过200GB,则需要当心,因为JVM对超过200GB的内存管理存在问题,需要特别的配置。
\\
内存容量足够大,还得真正分给了Spark才行。Spark建议需要提供至少75%的内存空间分配给Spark,至于其余的内存空间,则分配给操作系统与buffer cache。这就需要部署Spark的机器足够干净。
\\
考虑内存消耗问题,倘若我们要处理的数据仅仅是进行一次处理,用完即丢弃,就应该避免使用cache或persist,从而降低对内存的损耗。若确实需要将数据加载到内存中,而内存又不足以加载,则可以设置Storage Level。0.9版本的Spark提供了三种Storage Level:MEMORY_ONLY(这是默认值),MEMORY_AND_DISK,以及DISK_ONLY。
\\
关于数据的持久化,Spark默认是持久化到内存中。但它也提供了三种持久化RDD的存储方式:
\\
• \\t
in-memory storage as deserialized Javaobjects
\\t\\t
• \\t
in-memory storage as serialised data
\\t\\t
• \\t
on-disk storage
\\t\
第一种存储方式性能最优,第二种方式则对RDD的展现方式(Representing)提供了扩展,第三种方式则用于内存不足时。
\\
然而,在最新版(V1.0.2)的Spark中,提供了更多的Storage Level选择。一个值得注意的选项是OFF_HEAP,它能够将RDD以序列化格式存储到Tachyon中。相比MEMORY_ONLY_SER,这一选项能够减少执行垃圾回收,使Spark的执行器(executor)更小,并能共享内存池。Tachyon是一个基于内存的分布式文件系统,性能远超HDFS。Tachyon与Spark同源同宗,都烙有伯克利AMPLab的印记。目前,Tachyon的版本为0.5.0,还处于实验阶段。
\\
注意,RDDs是Lazy的,在执行Transformation操作如map、filter时,并不会提交Job,只有在执行Action操作如count、first时,才会执行Job,此时才会进行数据的加载。当然,对于一些shuffle操作,例如reduceByKey,虽然仅是Transformation操作,但它在执行时会将一些中间数据进行持久化,而无需显式调用persist()函数。这是为了应对当节点出现故障时,能够避免针对大量数据进行重计算。要计算Spark加载的Dataset大小,可以通过Spark提供的Web UI Monitoring工具来帮助分析与判断。
\\
Spark的RDD是具有分区(partition)的,Spark并非是将整个RDD一次性加载到内存中。Spark针对partition提供了eviction
policy,这一Policy采用了LRU(Least Recently Used)机制。当一个新的RDD分区需要计算时,如果没有合适的空间存储,就会根据LRU策略,将最少访问的RDD分区弹出,除非这个新分区与最少访问的分区属于同一个RDD。这也在一定程度上缓和了对内存的消耗。
\\
Spark对内存的消耗主要分为三部分:
\\
1. \\t
数据集中对象的大小;
\\t\\t
2. \\t
访问这些对象的内存消耗;
\\t\\t
3. \\t
垃圾回收GC的消耗。
\\t\
一个通常的内存消耗计算方法是:内存消耗大小= 对象字段中原生数据 * (2~5)。这是因为Spark运行在JVM之上,操作的Java对象都有定义的“object header”,而数据结构(如Map,LinkedList)对象自身也需要占用内存空间。此外,对于存储在数据结构中的基本类型,还需要装箱(Boxing)。Spark也提供了一些内存调优机制,例如执行对象的序列化,可以释放一部分内存空间。还可以通过为JVM设置flag来标记存放的字节数(选择4个字节而非8个字节)。在JDK 7下,还可以做更多优化,例如对字符编码的设置。这些配置都可以在spark-env.sh中设置。
\\
Spark 对网络的要求
\\
Spark属于网络绑定型系统,因而建议使用10G及以上的网络带宽。
\\
Spark 对 CPU 的要求
\\
Spark可以支持一台机器扩展至数十个CPU
core,它实现的是线程之间最小共享。若内存足够大,则制约运算性能的就是网络带宽与CPU数。
\\
Spark官方利用Amazon EC2的环境对Spark进行了基准测评。例如,在交互方式下进行数据挖掘(Interative Data Mining),租用Amazon EC2的100个实例,配置为8核、68GB的内存。对1TB的维基百科页面查阅日志(维基百科两年的数据)进行数据挖掘。在查询时,针对整个输入数据进行全扫描,只需要耗费5-7秒的时间。如下图所示:
在Matei Zaharia的Spark论文中还给出了一些使用Spark的真实案例。视频处理公司Conviva,使用Spark将数据子集加载到RDD中。报道说明,对于200GB压缩过的数据进行查询和聚合操作,并运行在两台Spark机器上,占用内存为96GB,执行完全部操作需要耗费30分钟左右的时间。同比情况下,Hadoop需要耗费20小时。注意:之所以200GB的压缩数据只占用96GB内存,是因为RDD的处理方式,使得我们可以只加载匹配客户过滤的行和列,而非所有压缩数据。`
Spark集群硬件配置推荐
计算与存储:
大多数Spark作业可能需要从外部存储系统(例如 :Cassandra、Hadoop文件系统或HBase)读取输入数据,所以要让Spark计算引擎尽可能靠近数据持久层。如果使用HDFS作为数据存储集群,可以在相同的集群上部署Spark集群,并配置Spark和Hadoop的内存和CPU使用率以避免干扰。我们的生产存储使用的是Cassandra集群,spark
master 服务单独部署,其它节点同时部署:Cassandra
+ spark worker,保证spark
worker 节点可以快速从本地读取数据进行计算汇总。
磁盘:
虽然Spark可以在内存中执行大量的计算,但它仍然可能会使用本地磁盘来存储不适用于RAM的数据,建议每个节点配置4-8个磁盘,不需要配置RAID(磁盘阵列),磁盘成本越来越低,可以考虑配置ssd硬盘,可以大幅提升性能。另外;在Linux中,使用noatime选项挂载磁盘,以减少不必要的写入操作。 在Spark中,可以将spark.local.dir变量配置为多个本地磁盘的地址,多个地址之间以逗号分隔。
内存
建议为Spark分配的内存容量不大于机器总内存容量的75%;确保为操作系统和缓冲区留下足够的内存。根据业务特点评估需要多少内存。请注意,当内存容量超过200GB时Java 虚拟机的性能表现会不稳定。如果您购买的RAM大于200G,则可以为每个节点运行多个worker
JVM。在Spark的standalone模式下,您可以通过conf/spark-env.sh中的SPARK_WORKER_INSTANCES变量设置每个节点运行的worker进程数,以及通过SPARK_WORKER_CORES变量设置每个worker可用的cpu核心数。
网络
当数据已经存储在内存中时,很多Spark应用程序的性能瓶颈在于网络的传输速率。推荐最低使用10G的网络。
CPU
Spark运行汇总计算任务比较多,推荐配置更多的cpu核数,性能提升还是比较明显,推荐:每台机器至少配置8-16个核。可以根据Spark作业的CPU负载情况,进行配置调整。一旦数据已经在内存中,大多数应用程序的性能瓶颈在于CPU和网络。
参考文档
[img]主流的数据分析平台构架有哪些?
1、Hadoop
Hadoop 采用 Map Reduce 分布式计算咐旦框架,根据 GFS开发了 HDFS 分布式文件系统,根据 Big Table 开发了 HBase数据存储系统。Hadoop 的衡举扰开源特性使其成为分布式计算系统的事实上的国际标准。Yahoo,Facebook,Amazon 以及国内的百度,阿里巴巴等众多互联网公司都以 Hadoop 为基础搭建自己的分布。
2、Spark
Spark 是在 Hadoop 的基础上进行了一些架构上的改良。Spark 与Hadoop 最大的不同点在于,Hadoop 使用硬盘来存储数据,而Spark 使用内存来存储数据,因此 Spark 可以提供超过 Ha?doop 100 倍的运算速度。由于内存断电后会丢失数据,Spark不能用于处理需要长期保存的数据。
3、Storm
Storm是 Twitter 主推的分布式计算系统。它在Hadoop的基础上提供了实时运算的特性,可以实时的处理大数据流。不同于Hadoop和Spark,Storm不进行数据的收集和存储工作,它直接通过网络实时的接受数据并且实时的处理数据,然后直接通过网络实时的传回结果。
4、Samza
Samza 是由 Linked In 开源的一项技术,是一个分布式流处理框架,专用于实时数据的处理,非常像Twitter的流处理系统Storm。不同的是Sam?za 基于 Hadoop,而且使用了 Linked In 自家的 Kafka 分布式消息系统。
Samza 非常适用于实时流数据处理的业务,如数据跟踪、日志服务、实时服务等应用,它能够帮助开发者进行高速消答灶息处理,同时还具有良好的容错能力。
科普Spark,Spark是什么,如何使用Spark
科普Spark,Spark是什么,如何使用Spark
1.Spark基于什么算法的分布式计算(很简单)
2.Spark与MapReduce不同在什么地方
3.Spark为什么比Hadoop灵活
4.Spark局限是什么
5.什么情况下适合使用陵袜Spark
什么是Spark
Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用的并行计算框架,Spark基于map reduce算法实现的分布式计算,拥有Hadoop MapReduce所具有的优点;但不同于MapReduce的是Job中间输出和结果可以保存在内存中,从而不再需要读写HDFS,因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的map reduce的算法。其架构如下图所示:
Spark与Hadoop的对比
Spark的中间数据放到内存中,对于迭代运算效率更高。
Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面,有RDD的抽象概念。
Spark比Hadoop更通用
Spark提供的数据集操作类型有很多种,不像Hadoop只提供了Map和Reduce两种操作。比如map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort,partionBy等多种操作类型,Spark把这些操作称为Transformations。同时还提供Count, collect, reduce, lookup, save等多种actions操作。
这些多种多样的数据集操作类型,给给开发上层应用的用户提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的Data Shuffle一种模式。用户可以命名,物化,控制中间结果的存储、分区等。可以说编程模型比Hadoop更灵活。
不过由于RDD的特性,Spark不适用那种异步细粒度更新状态的应用,例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合。
容错性
在分布式数据集计算时通过checkpoint来实现容错,而checkpoint有两种方式,一个是checkpoint data,一个是logging the updates。用户可以控制采用哪尺世激种方式来实现容错。
可用性
Spark通过提供丰富的Scala, Java,Python API及交互式Shell来提高可用性。
Spark与Hadoop的结合
Spark可以直接对HDFS进行数据的读写,同样支持Spark on YARN。Spark可以与MapReduce运行于同集群中,共享存储资返粗源与计算,数据仓库Shark实现上借用Hive,几乎与Hive完全兼容。
Spark的适用场景
Spark是基于内存的迭代计算框架,适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多,所需读取的数据量越大,受益越大,数据量小但是计算密集度较大的场合,受益就相对较小(大数据库架构中这是是否考虑使用Spark的重要因素)
由于RDD的特性,Spark不适用那种异步细粒度更新状态的应用,例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合。总的来说Spark的适用面比较广泛且比较通用。
运行模式
本地模式
Standalone模式
Mesoes模式
yarn模式
Spark生态系统
Shark ( Hive on Spark): Shark基本上就是在Spark的框架基础上提供和Hive一样的H iveQL命令接口,为了最大程度的保持和Hive的兼容性,Shark使用了Hive的API来实现query Parsing和 Logic Plan generation,最后的PhysicalPlan execution阶段用Spark代替Hadoop MapReduce。通过配置Shark参数,Shark可以自动在内存中缓存特定的RDD,实现数据重用,进而加快特定数据集的检索。同时,Shark通过UDF用户自定义函数实现特定的数据分析学习算法,使得SQL数据查询和运算分析能结合在一起,最大化RDD的重复使用。
Spark streaming: 构建在Spark上处理Stream数据的框架,基本的原理是将Stream数据分成小的时间片断(几秒),以类似batch批量处理的方式来处理这小部分数据。Spark Streaming构建在Spark上,一方面是因为Spark的低延迟执行引擎(100ms+)可以用于实时计算,另一方面相比基于Record的其它处理框架(如Storm),RDD数据集更容易做高效的容错处理。此外小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法。方便了一些需要历史数据和实时数据联合分析的特定应用场合。
Bagel: Pregel on Spark,可以用Spark进行图计算,这是个非常有用的小项目。Bagel自带了一个例子,实现了Google的PageRank算法。
End.
关于spark架构和spark架构中的组件的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。