那么问题来了，上述的机器学习/模式识别算法往往都是迭代型的计算，一般会迭代几十至几百轮，那么在Hadoop上就是连续的几十至几百个串行的任务，前后两个任务之间都要经过大量的IO来传递数据，据不完全统计，多数的迭代型算法在Hadoop上的耗时，IO占了80%左右，如果可以省掉这些IO开销，那么对计算速度的提升将是巨大的，因此业界兴起了一股基于内存计算的潮流，而Spark则是这方面的佼佼者。它提出了RDD的概念，通过对RDD的使用将每轮的计算结果分布式地放在内存中，下一轮直接从内存中读取上一轮的数据，节省了大量的IO开销。同时它提供了比Hadoop的MapReduce方式更加丰富的数据操作方式，有些需要分解成几轮的Hadoop操作，可在Spark里一轮实现。因此对于机器学习/模式识别等迭代型计算，比起Hadoop平台，在Spark上的计算速度往往会有几倍到几十倍的提升。另一方面，Spark的设计初衷就是想兼顾MapReduce模式和迭代型计算，因此老的MapReduce计算也可以迁移至spark平台。由于Spark对Hadoop计算的兼容，以及对迭代型计算的优异表现，成熟之后的Spark平台得到迅速的普及。
人们逐渐发现，Spark所具有的优点，可以扩展到更多的领域，现在Spark已经向通用多功能大数据平台的方向迈进。为了让Spark可以用在数据仓库领域，开发者们推出了Shark，它在Spark的框架上提供了类SQL查询接口，与Hive QL完全兼容，但最近被用户体验更好的Spark SQL所取代。Spark SQL涵盖了Shark的所有特性，并能够加速现有Hive数据的查询分析，以及支持直接对原生RDD对象进行关系查询，显著降低了使用门槛。在实时计算领域，Spark streaming项目构建了Spark上的实时计算框架，它将数据流切分成小的时间片段（例如几秒），批量执行。得益于Spark的内存计算模式和低延时执行引擎，在Hadoop上做不到的实时计算，在Spark上变得可行。虽然时效性比专门的实时处理系统有一点差距，但也可用于不少实时/准实时场景。另外Spark上还有图模型领域的Bagel，其实就是Google的Pregel在Spark上的实现。它提供基于图的计算模式，后来被新的Spark图模型API——GraphX所替代。
当大数据集群越来越大，出现局部故障的概率也越来越高，集群核心数据的分布式一致性变得越来越难保证。Zookeeper的出现很好地解决了这个棘手的问题，它实现了著名的Fast Paxos算法，提供了一个集群化的分布式一致性服务，使得其他平台和应用可以通过简单地调用它的服务来实现数据的分布式一致性，不需要自己关心具体的实现细节，使大数据平台开发人员可以将精力更加集中在平台自身特性上。例如Storm平台就是使用Zookeeper来存储集群元信息（如节点信息、状态信息、任务信息等），从而可以简单高效地实现容错机制。即使某个组件出现故障，新的替代者可以快速地在Zookeeper上注册以及获取所需的元信息，从而恢复失败的任务。除了分布式一致性以外，Zookeeper还可以用作leader选取、热备切换、资源定位、分布式锁、配置管理等场景。
数据在其生命周期是流动的，往往会有产生、收集、存储、计算、销毁等不同状态，数据可以在不同状态之间流动，也可以从同一个状态的内部进行流动（例如计算状态），流动时上下游的载体有很多种，例如终端、线上日志服务器、存储集群、计算集群等。在后台，多数情况下都是在大数据平台之间流动，因此各个大数据平台并不是孤立的，处理数据时，它们往往成为上下游的关系，而数据从上游流往下游，就需要一个数据管道，来正确连接每份数据正确的上下游，这个场景的需求可以使用Kafka集群来很好地解决。Kafka最初是由LinkedIn开发的，是一个分布式的消息发布与订阅系统。Kafka集群可以充当一个大数据管道的角色，负责正确连接每种数据的上下游。各个上游产生的数据都发往Kafka集群，而下游则通过向Kafka集群订阅的方式，灵活选择自己所需的上游数据。Kafka支持多个下游订阅同一个上游数据。当上游产生了数据，Kafka会把数据进行一定时间窗口内的持久化，等待下游来读取数据。Kafka的数据持久化方式及内部容错机制，提供了较好的数据可靠性，它同时适合于离线和在线消息消费。
以上平台的诞生时间点如下图所示：
