Spark Streaming使用场景及优化总结

SparkStreaming适合场景

Storm 流式计算(扶梯)
优点: 数据延迟度很低,Storm的事务机制要比SparkStreaming的事务机制要完善(什么是事务机制?对于一条数据,不多处理也不少处理,对于一条数据恰好处理一次,比如金融,股票等要求实时性比较高,那么就需要选Storm)

缺点:一直持有着资源,每一条数据都要在集群中某一台节点处理,要计算的数据会进行网络传输,吞吐量小,另外Storm不适合做复杂的业务逻辑(适合汇总)

SparkStreaming 微批处理(类似于电梯),它并不是纯的批处理
优点:吞吐量大,可以做复杂的业务逻辑(保证每个job的处理小于batch interval)
缺点:数据延迟度较高

公司中为什么选用SparkStreaming要多一些?
1.秒级别延迟,通常应用程序是可以接受的,
2.可以应用机器学习,SparkSQL...可扩展性比较好,数据吞吐量较高

Spark性能优化

代码优化

  • 多个Action计算最好基于同一个RDD进行计算操作, 并且对相同的RDD进行Cache操作,避免重复计算,增加任务的执行时间;并且持久化级别最好使用MEMORY_ONLY_SER来减少内存使用;

  • 在使用join的地方看是否可以使用map算子和广播变量的方式替代;

  • 使用高效的算子, 例如:使用reduceByKey/aggregateByKey来代替groupByKey,因为前者可以进行combiner操作,减少网络IO;

当进行联合规约操作时,避免使用 groupByKey。举个例子,rdd.groupByKey().mapValues(_ .sum) 与 rdd.reduceByKey(_ + _) 执行的结果是一样的,但是前者需要把全部的数据通过网络传递一遍,

  • 使用MapPartition来代替Map操作, 尤其是在需要网络连接的地方;
  • 使用foreachPartition代替foreach操作,可以对数据进行批量处理;
  • 在filter操作后,可以使用colease操作,可以减少任务数;
  • 序列化尽量使用Kyro方式, 其性能更好;
  • 减少对复杂数据结构的使用,可以有效减少序列化时间;
  • 对应简单的函数,最好使用闭合结构,可以有效减少网络IO;
  • 使用Repartition操作可以有效增加任务的处理并行度;

参数调整优化部分

经过实践验证,调整后有效的参数如下:

设置合理的资源;
Java垃圾回收器;
清理不必要的空间;

  • 根据资源情况,可以添加Executor的个数来有效,参数为 spark.executor.instances
  • 调整每个Executor的使用内核数, 参数为 spark.executor.cores
  • 调整每个Executor的内存, 参数为 spark.executor.memory
  • shuffle write task的buffer大小, 参数为 spark.shuffle.file.buffer
  • shuffle read task的buffer大小, 参数为 spark.reducer.maxSizeInFlight
  • 每一个stage的task的默认并行度, 默认为200, 建议修改为1000左右, 参数 spark.default.parallelism
  • 用于RDD的持久化使用的内存比例,默认0.6, 参数 spark.storage.memoryFraction
  • 用户shuffle使用的内存比例, 默认为0.2, 参数 spark.shuffle.memoryFraction

其它优化

  • 增加数据读取的并行度,比如读取Kafka的数据,可以增加topic的partition数量和executor的个数;
  • 限制读取Kafka数据的速率,参数 spark.streaming.kafka.maxRatePerPartition
  • 对于存在数据倾斜问题,有两类情况:
  • 进行join操作,产生skew问题, 可以使用map+广播变量类进行处理;
  • 对redece/aggregate等聚合操作,参数skew问题, 可以进行两次聚合的思想来解决, * 核心是先进行key进行随机数操作,是数据分布均匀,并进行聚合,最后是剔除随机数据,用实际数据来进行聚合操作。

SQL 优化

  • 开启spark.sql.autoBroadcastJoinThreshold
  • 合理配置spark.sql.shuffle.partition

参考:

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,905评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,140评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,791评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,483评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,476评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,516评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,905评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,560评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,778评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,557评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,635评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,338评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,925评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,898评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,142评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,818评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,347评论 2 342

推荐阅读更多精彩内容