(1)复杂的批量数据处理，通常的时间跨度在数十分钟到数小时之间。
(2)基于历史数据的交互式查询，通常的时间跨度在数十秒到数分钟之间。
(3)基于实时数据流的数据处理，通常的时间跨度在数百毫秒到数秒之间。
目前已有很多相对成熟的开源和商业软件来处理以上三种情景 ：第一种业务，可以利用 MapReduce 来进行批量数据处理 ;第二种业务，可以用 Impala 来进行交互式查询 ;对于第三种流式数据处理，可以想到专业的流数据处理工具 Storm。但是这里有一个很重要的问题 ：对于大多数互联网公司来说，一般会同时遇到以上三种情景，如果采用不同的处理技术来面对这三种情景，那么这三种情景的输入/ 输出数据无法无缝共享，它们之间可能需要进行格式转换，并且每个开源软件都需要一支开发和维护团队，从而提高了成本。另外一个不便之处就是，在同一个集群中对各个系统协调资源分配比较困难。
那么，有没有一种软件可以同时处理以上三种情景呢? Spark 就可以，或者说有这样的潜力。Spark 同时支持复杂的批处理、互操作和流计算，而且兼容支持HDFS 和 Amazon S3 等分布式文件系统，可以部署在 YARN 和 Mesos 等流行的集群资源管理器上。
从 Spark 的设计理念(基于内存的迭代计算框架)出发，其最适合有迭代运算的或者需要多次操作特定数据集的应用场合。并且迭代次数越多，读取的数据量越大，Spark 的应用效果就越明显。因此，对于机器学习之类的“迭代式”应用，Spark 可谓拿手好戏，要比 Hadoop MapReduce 快数十倍。另外，Spark Streaming因为内存存储中间数据的特性，处理速度非常快，也可以应用于需要实时处理大数据的场合。
当然，Spark 也有不适用的场合。对于那种异步细粒度更新状态的应用，例如 Web 服务的存储或增量的 Web 爬虫和索引，也就是对于那种增量修改的应用模型不适合。Spark 也不适合做超级大的数据量的处理，这里所说的“超级大”是相对于这个集群的内存容量而言的，因为 Spark 要将数据存储在内存中。一般来说，10TB 以上(单次分析)的数据就可以算是“超级大”的数据了。
一般来说，对于中小企业的数据中心而言，在单次计算的数据量不大的情况下，Spark 都是很好的选择。另外，Spark 也不适合应用于混合的云计算平台，因为混合的云计算平台的网络传输是很大的问题，即便有专属的宽带在云端 Cluster 和本地 Cluster 之间传输数据，相比内存读取速度来说，依然不抵。