返回信息流初学spark，看到14年spark在Sort Benchmark比赛中利用23分钟完成了100TB的数据，很好奇spark是怎么处理这么大数据的；
1、对于这种超大数据，spark是尽量利用内存运算，每个task在内存能够容纳的范围内尽量读取数据；还是每个task读取不管内存能不能够承受，每个task都处理固定大小的数据块，内存承受不下的就利用磁盘辅助运算？
2、spark可以利用磁盘辅助运算，但是有时还是能够观察到会出现OOM和堆上内存不足的错误，这个是为什么，spark能够处理的数据的极限大概是内存的多少倍？
3、根据报道，databrick公司在比赛上使用了207台机器运行spark，假设SSD的读取速度大概为500M/s，207台机器同时读取，依然需要16min左右，难道spark真的7分钟内同时可以处理100TB数据的排序问题？
希望大神能够解答
这是一条镜像帖。来源：北邮人论坛 / ml-dm / #25275同步于 2017/8/10
该镜像源已超过 30 天没有更新，可能在源站已被删除。
ML_DM机器人发帖
spark是如何处理远超自己内存大小的数据的呢？
airfan
2017/8/10镜像同步9 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
1. 用磁盘做缓存。
2. 没有极限，取决于你的计算逻辑。比如如果仅仅是 map -> filter -> save 的话，多少数据都能处理；但如果是 groupBy 的话，那就不一样了。
3. SSD 没那么慢，另外这可是207台机器啊，你再乘以 cpu 的核数……
能处理这么大数据的排序有两个原因：
1. 从算法本身来看，这么大的 sort 肯定是外排序，100TB 的数据并不是全部加载上来，然后再做 sort 的，而是「加载一部分 -> 处理一部分 -> 再加载一部分 -> 再处理一部分」。
2. 从 Spark 的原理来看，Spark 也不是需要所有数据都事先加载到内存的，它是利用 lineage，从后往前，在运行某个 task 的时候，把这个 task 最终用到的那部分 partition 的数据给加载上来，用完过一会儿如果没有其他 task 需要这部分数据，就会被 clean 掉的。
不一定对哈。
首先感谢大神的回答[ema3]，因为之前正好在暑假期间，没有及时看到和回复，很抱歉
1、get it;
2、不是很明白，大神能不能举个例子说一下group by是咋回事，是因为shuffle的原因吗；听说在shuffle过程中可能会出现hash表过大导致的内存溢出，是不是类似于这种情况？是不是说并不是所有的内存操作，在spark的运算逻辑都能利用磁盘来辅助运算，摆脱内存大小限制？有些操作就只能通过内存运行，超过就会OOM？
3、我是从京东看到的参数，一块三星的SSD，参数标明“连续读取不超过540MB/秒，连续写入不超过520MB/秒”；
cpu的核数应该和读取速度没关系啊，这是本身硬盘转速的限制，不能因为多核就在这个速度上乘以核数吧？
【 在 kayla 的大作中提到: 】
: 1. 用磁盘做缓存。
: 2. 没有极限，取决于你的计算逻辑。比如如果仅仅是 map -> filter -> save 的话，多少数据都能处理；但如果是 groupBy 的话，那就不一样了。
: 3. SSD 没那么慢，另外这可是207台机器啊，你再乘以 cpu 的核数……
: ...................
2. 一个理解，不一定对哈：磁盘是用来辅助存储的，不是用来辅助计算的，也就是说如果当前的某个 task 需要用到某些数据，那这些数据即便存在磁盘上，也是必须先加载到内存里才行的。比如 groupByKey 操作，你针对某个 key 计算的时候，这个 key 对应的 values 还是得加载到内存里面的。
3. 首先，你看的是消费级 SSD，不是商用级。其次，即便是消费级，MacBook Pro 2017 的硬盘在官网上的标称速度是 3.2GB/s。
【 在 airfan 的大作中提到: 】
: 首先感谢大神的回答，因为之前正好在暑假期间，没有及时看到和回复，很抱歉
: 1、get it;
: 2、不是很明白，大神能不能举个例子说一下group by是咋回事，是因为shuffle的原因吗；听说在shuffle过程中可能会出现hash表过大导致的内存溢出，是不是类似于这种情况？是不是说并不是所有的内存操作，在spark的运算逻辑都能利用磁盘来辅助运算，摆脱内存大小限制？有些操作就只能通过内存运行，超过就会OOM？
: ...................
恩，这个明白了，速度应该不是啥问题了[ema11]
【 在 qyz0123321 的大作中提到: 】
: 服务器要做了RAID 0的话，速度还能比这个高很多吧
2、如果是这种情况的话，是不是可以通过增大分区个数的方式，减少每个task处理的数据量，来避免OOM，承受更大的计算量？[ema11]
【 在 kayla 的大作中提到: 】
: 2. 一个理解，不一定对哈：磁盘是用来辅助存储的，不是用来辅助计算的，也就是说如果当前的某个 task 需要用到某些数据，那这些数据即便存在磁盘上，也是必须先加载到内存里才行的。比如 groupByKey 操作，你针对某个 key 计算的时候，这个 key 对应的 values 还是得加载到内存里面的。
: 3. 首先，你看的是消费级 SSD，不是商用级。其次，即便是消费级，MacBook Pro 2017 的硬盘在官网上的标称速度是 3.2GB/s。
没用，如果其他 key 都只对应100条数据，但有一个 key 对应 100万 条数据，你无论怎么分区，这100万条数据都会跑到同一个 task 下面去，即便你有办法让它不 OOM，处理速度也太慢了。
【 在 airfan 的大作中提到: 】
: 2、如果是这种情况的话，是不是可以通过增大分区个数的方式，减少每个task处理的数据量，来避免OOM，承受更大的计算量？
也对哦，谢谢大神指点
【 在 kayla 的大作中提到: 】
: 没用，如果其他 key 都只对应100条数据，但有一个 key 对应 100万 条数据，你无论怎么分区，这100万条数据都会跑到同一个 task 下面去，即便你有办法让它不 OOM，处理速度也太慢了。