返回信息流spark运行时随着数据规模的增大，单个executor所需要的内存大小也需要增加，这样是正常的吗？[ema13]
当然不会随规模线性增长,但还是需要相应调整，比如 在处理百万条数据时，单点内存需要20G，在处理千万条数据的时候，单点内存需求就增大到40G，不然就各种fail，请问这是正常的吗，还是程序对数据处理的不够好，有一点数据倾斜[ema13]
求我邮走过路过的各路大神帮忙解答[ema23]
这是一条镜像帖。来源：北邮人论坛 / ml-dm / #25745同步于 2017/9/14
该镜像源已超过 30 天没有更新，可能在源站已被删除。
ML_DM机器人发帖
问一个spark随着运算规模增大单点内存需求变化的问题
airfan
2017/9/14镜像同步7 回复
订阅后，新回复会通过你的通知中心匿名送达。
7 条回复
1、大神的意思是确实是不正常的？
2、为什么需要替代join，是因为join操作特别耗资源吗？
【 在 kayla 的大作中提到: 】
: 先去优化代码，比如 groupByKey 是不是可以用 reduceByKey 来替代，比如 join 是不是可以用其他方式来代替。
1. 不是说不正常，而是你这样的话自动化不好弄，难不成你要先看数据大小然后再改配置吗？
2. join 当然耗资源。
【 在 airfan 的大作中提到: 】
: 1、大神的意思是确实是不正常的？
: 2、为什么需要替代join，是因为join操作特别耗资源吗？
1、其实是我们想说服甲方在数据量大的时候相应增大executor的资源，但甲方的意思是我们自己可扩展性的问题，正常情况下只需要增加及其规模，单个executor的资源是不需要变动的；所以想搞清楚到底需要增加资源是情有可原，还是真的是我们自己代码的问题；
2、我们现在是一个大表（数据量很大，但是只有几个不同的key值）和另外一个很小的表做join，而不是两个大规模的表做join，这样也会耗资源吗？如果将join操作改成map操作会解决这个问题吗？
【 在 kayla 的大作中提到: 】
: 1. 不是说不正常，而是你这样的话自动化不好弄，难不成你要先看数据大小然后再改配置吗？
: 2. join 当然耗资源。
1. 都有可能，但是你要做的就是尽量把 executor 资源的扩展替换成增加规模。
2. join 需要 shuffle 啊，肯定比 map 慢。
【 在 airfan 的大作中提到: 】
: 1、其实是我们想说服甲方在数据量大的时候相应增大executor的资源，但甲方的意思是我们自己可扩展性的问题，正常情况下只需要增加及其规模，单个executor的资源是不需要变动的；所以想搞清楚到底需要增加资源是情有可原，还是真的是我们自己代码的问题；
: 2、我们现在是一个大表（数据量很大，但是只有几个不同的key值）和另外一个很小的表做join，而不是两个大规模的表做join，这样也会耗资源吗？如果将join操作改成map操作会解决这个问题吗？
大概懂了，谢谢大神的解答[ema11]；就是先尽量去尝试将耗资源的操作，像join和rudeucebykey这种换成轻量级、不太可能产生数据倾斜的操作，提高可扩展性；提高资源的事再说
【 在 kayla 的大作中提到: 】
: 1. 都有可能，但是你要做的就是尽量把 executor 资源的扩展替换成增加规模。
: 2. join 需要 shuffle 啊，肯定比 map 慢。
Spark是不会把数据都加载到内存的，Spark一个task对应一个你原来数据的partition,一个executor在一个时刻上执行的Task数可以理解成（executor.cores/ taskperCore）,执行每个task的时候获取数据也是通过RDD compute返回那个分区的迭代器来执行的。 所以按理来说，如果不做cache，或者persist,数据量增加了executor配置不变也是可以跑的，可能需要的时间相对较长。然后 join 怎么换成map，我很好奇。。如果是大表关联小表的话，个人建议将小表BroadCast,然后网上也有很多解决数据倾斜的方法。可以多看看