Apache Spark在内存数据处理领域有很多创新。有了这个框架，你可以上传数据到集群内存，并在交互模式下以非常快的速度处理这些数据(交互模式是Spark另一个重要特性)。2014年 Databricks宣布 Apache Spark能在23分钟内完成100T数据的排序。
这里有一个有趣的问题—— 你可以在集群中以交互方式处理的数据量的上限是什么?如果你的集群中有100T数据呢? 你可能惊讶内存竟然如此之快。直觉告诉你可以内存可以交互式处理100T的输入数据或者至少能处理一半的规模。然而，像往常一样，在分布式系统的世界，我们的直觉是错误的。
- 响应时间
对于一个简单的数据处理场景和一个比较复杂的，各自的响应时间是什么?那我们还是在一个交互模式吗?我们应该这样思考，但是很不幸，我们没有。我看到的是，在实际的场景中，一个有8T数据的“where sum(), count()”语句的简单场景的响应时间是20-40秒。对于更复杂更实际的情形(有几个“group by”和几个“join”)，响应时间是3-5分钟。这绝不是我说的交互模式!
在日常生活中，我只会在响应时间比较关键的情形下作分析。对我来说，3到10秒之后我就会放弃，好吧也许会到15秒之后我仍然认为这是交互模式。除此之外，我会认为它是批处理模式。和MapReduce之类的磁盘处理相比，几秒钟或是3-5分钟替代了15-60分钟可能看起来比较不可置信。然而，这不是交互式的。
- 交互在哪里结束?
交互模式下几秒延迟内我能处理的最大内存数量限制在1TB以内。尽管这样，效率还算不错的。然而，超出了1TB，我发现响应时间被极度延长了。
我猜测是为了提高效率(5-10TB只有几秒钟延迟)，我们需要更新硬件(我想尝试一个拥有非常强大的EC2机器，250GB的RAM存储的集群)，以及调整软件设置(Apache Spark驱动设置，内存列格式，可能还有YARN设置)。
即使软硬件都更新了，我很清楚，交互模式的限制也不会接近100TB。
- 先把数据读入内存
正如你回想起的一样，要记住你每迭代一次数据处理都会花费数秒甚至数分钟。然而，这并不是故事的结局。如果你正用Ad Hoc分析或者是创建机器学习模型，你的初始数据集很大可能都存放在一个HDFS存储集群中。这意味着在内存迭代操作之前，你应该先从耗时较长的磁盘中读入数据。按往常，性能通常依赖于硬件和软件设置。更可能的是，读一个5-8TB的数据集耗时在15-30分钟之间。即使是1TB数据也会消耗5分钟左右。
总结
在接触Apache Spark内存处理之前，特别是数据集超过1TB时，好好计划分析场景并评估响应时间还是很有价值的。
请提供关于你以交互方式处理的数据量的上限的相关经验反馈。
