🤖airfan@airfan

“1、其实是我们想说服甲方在数据量大的时候相应增大executor的资源，但甲方的意思是我们自己可扩展性的问题，正常情况下只需要增加及其规模，单个executor的资源是不需要变动的；所以想搞清楚到底需要增加资源是情有可原，还是真的是我们自己代码的问题； 2、我们现在是一个大表（数据量很大，但是只有几个不同的key值）和…”

“1、大神的意思是确实是不正常的？ 2、为什么需要替代join，是因为join操作特别耗资源吗？ 【 在 kayla 的大作中提到: 】 : 先去优化代码，比如 groupByKey 是不是可以用 reduceByKey 来替代，比如 join 是不是可以用其他方式来代替。”

“也对哦，谢谢大神指点 【 在 kayla 的大作中提到: 】 : 没用，如果其他 key 都只对应100条数据，但有一个 key 对应 100万 条数据，你无论怎么分区，这100万条数据都会跑到同一个 task 下面去，即便你有办法让它不 OOM，处理速度也太慢了。”

“2、如果是这种情况的话，是不是可以通过增大分区个数的方式，减少每个task处理的数据量，来避免OOM，承受更大的计算量？[ema11] 【 在 kayla 的大作中提到: 】 : 2. 一个理解，不一定对哈：磁盘是用来辅助存储的，不是用来辅助计算的，也就是说如果当前的某个 task 需要用到某些数据，那这些数据即便存在…”

“恩，这个明白了，速度应该不是啥问题了[ema11] 【 在 qyz0123321 的大作中提到: 】 : 服务器要做了RAID 0的话，速度还能比这个高很多吧”

“首先感谢大神的回答[ema3]，因为之前正好在暑假期间，没有及时看到和回复，很抱歉 1、get it; 2、不是很明白，大神能不能举个例子说一下group by是咋回事，是因为shuffle的原因吗；听说在shuffle过程中可能会出现hash表过大导致的内存溢出，是不是类似于这种情况？是不是说并不是所有的内存操作，在…”

“代理，偶尔sleep，活实在急的话就去阿里云租几台服务器，或者借几台同学的机器一起跑，自己做好防重复”

“每个站点403的原因都不一样的吧 【 在 maomao2hao 的大作中提到: 】 : 你的403问题解决了么？ 我是需要爬豆瓣数据”