Hive跟hbase在功能上也有小部分重叠的地方，它们的主要区别是：Hbase本质是一个数据库，提供在存储层的低延时数据读写能力，可用在实时场景，但没有提供类SQL语言的查询方式，所以数据查询和计算不太方便（PIG学习成本较高）；hive本质是将SQL语句映射成MapReduce作业，延时较高但使用方便，适合离线场景，自身不做存储。此外，hive可以搭建在Hbase之上，访问Hbase的数据。
Hive的出现桥接了Hadoop与数据仓库领域，但随着hive的逐步应用，人们发现hive的效率并不是太高，原因是hive的查询是使用MapReduce作业的方式实现的，是在计算层而不是存储层，因此受到了MapReduce框架单一的数据传输和交互方式的局限、以及作业调度开销的影响。为了让基于Hadoop的数据仓库操作效率更高，在hive之后出现了另一个不同的实现方案——impala，它的基于Hadoop的数据查询操作，并不是使用MapReduce作业的方式实现，而是跳过了Hadoop的计算层，直接读写hadoop的存储层——hdfs来实现。由于省去了计算层，因此也就省去了计算层所有的开销，避免了计算层的单一数据交互方式的问题，以及多轮计算之间的磁盘IO问题。直接读写hdfs，可以实现更加灵活的数据交互方式，提高读写效率。它实现了嵌套型数据的列存储，同时采用了多层查询树，使得它可以在数千节点中快速地并行执行查询与结果聚合。据一些公开的资料显示，impala在各个场景下的效率可以比hive提升3~68倍，尤其在某些特殊场景下的效率提升甚至可达90倍。
Hadoop极大降低了海量数据计算能力的门槛，使得各个业务都可以快速使用Hadoop进行大数据分析，随着分析计算的不断深入，差异化的需求慢慢浮现了。人们开始发现，某些计算，如果时效性更快，收益会变得更大，能提供给用户更好的体验。一开始，在Hadoop平台上为了提高时效性，往往会将一整批计算的海量数据，切割成小时级数据，甚至亚小时级数据，从而变成相对轻量的计算任务，使得在Hadoop上可以较快地计算出当前片段的结果，再把当前片段结果跟之前的累积结果进行合并，就可以较快地得出当前所需的整体结果，实现较高的时效性。但随着互联网行业竞争越来越激烈，对时效性越来越看重，尤其是实时分析统计的需求大量涌现，分钟级甚至秒级输出结果，是大家所期望的。hadoop计算的时效性所能达到的极限一般为10分钟左右，受限于集群负载和调度策略，要想持续稳定地低于10分钟是非常困难的，除非是专用集群。因此，为了实现更高的时效性，在分钟级、秒级、甚至毫秒级内计算出结果，Storm应运而生，它完全摆脱了MapReduce架构，重新设计了一个适用于流式计算的架构，以数据流为驱动，触发计算，因此每来一条数据，就可以产生一次计算结果，时效性非常高，一般可以达到秒级。而且它的有向无环图计算拓扑的设计，提供了非常灵活丰富的计算方式，覆盖了常见的实时计算需求，因此在业界得到了大量的部署应用。
Storm的核心框架保证数据流可靠性方式是：每条数据会被至少发送一次，即正常情况会发送一次，异常情况会重发。这样会导致中间处理逻辑有可能会收到两条重复的数据。大多数业务中这样不会带来额外的问题，或者是能够容忍这样的误差，但对于有严格事务性要求的业务，则会出现问题，例如扣钱重复扣了两次这是用户不可接受的。为了解决此问题，Storm引入了事务拓扑，实现了精确处理一次的语义，后来被新的Trident机制所取代。Trident同时还提供了实时数据的join、groupby、filter等聚合查询操作。
跟storm类似的系统还有yahoo的S4，不过storm的用户远远多于S4，因此storm的发展比较迅速，功能也更加完善。
随着大数据平台的逐步普及，人们不再满足于如数据统计、数据关联等简单的挖掘，渐渐开始尝试将机器学习/模式识别的算法用于海量数据的深度挖掘中。因为机器学习/模式识别的算法往往比较复杂，属于计算密集型的算法，且是单机算法，所以在没有Hadoop之前，将这些算法用于海量数据上几乎是不可行，至少是工业应用上不可行：一是单机计算不了如此大量的数据；二是就算单机能够支撑，但计算时间太长，通常一次计算耗时从几个星期到几个月不等，这对于工业界来说资源和时间的消耗不可接受；三是没有一个很易用的并行计算平台，可以将单机算法快速改成并行算法，导致算法的并行化成本很高。而有了Hadoop之后，这些问题迎刃而解，一大批机器学习/模式识别的算法得以快速用MapReduce框架并行化，被广泛用在搜索、广告、自然语言处理、个性化推荐、安全等业务中。