一说到开源大数据处理平台，就不得不说此领域的开山鼻祖Hadoop，它是GFS和MapReduce的开源实现。虽然在此之前有很多类似的分布式存储和计算平台，但真正能实现工业级应用、降低使用门槛、带动业界大规模部署的就是Hadoop。得益于MapReduce框架的易用性和容错性，以及同时包含存储系统和计算系统，使得Hadoop成为大数据处理平台的基石之一。Hadoop能够满足大部分的离线存储和离线计算需求，且性能表现不俗；小部分离线存储和计算需求，在对性能要求不高的情况下，也可以使用Hadoop实现。因此，在搭建大数据处理平台的初期，Hadoop能满足90%以上的离线存储和离线计算需求，成为了各大公司初期平台的首选。
一共81个，开源大数据处理工具汇总（下），包括日志收集系统/集群管理/RPC等
随着Hadoop集群越来越大，单点的namenode渐渐成为了问题：第一个问题是单机内存有限，承载不了越来越多的文件数目；第二个问题是单点故障，严重影响集群的高可用性。因此业界出现了几种分布式namenode的方案，用以解决单点问题。此外，为了实现多种计算框架可以运行在同一个集群中，充分复用机器资源，Hadoop引进了YARN。YARN是一个通用资源管理器，负责资源调度和资源隔离。它试图成为各个计算框架的统一资源管理中心，使得同一个集群可以同时跑MapReduce、storm、Tez等实例。
Hadoop解决了大数据平台的有无问题，随着业务和需求的精细化发展，在一些细分领域人们对大数据平台提出了更高的期望和要求，因此诞生了一批在不同领域下的更高效更有针对性的平台。首先基于对Hadoop框架自身的改良，出现了haloop和dryad等变种平台，不过这些平台后来基本上都没有被大规模部署，其原因要么是改良效果不明显，要么是被跳出Hadoop框架重新设计的新平台所取代了。
为了解决在hadoop平台上更好地进行海量网页分析，进而实现通用的分布式NoSQL数据库的问题，HBase诞生了。Hadoop参照了Google的GFS和MapReduce的设计。而Google的BigTable在Hadoop的生态圈里对应的则是HBase。HBase丰富了Hadoop的存储方式，在hdfs的文件式存储的基础上，提供了表格式存储，使得可以将网页的众多属性提取出来按字段存放，提升网页查询分析的效率。同时，HBase也广泛被用作通用的NoSQL存储系统，它是基于列存储的非关系型数据库，弥补了hdfs在随机读写方面的不足，提供低延时的数据访问能力。但HBase本身没有提供脚本语言式（如SQL）的数据访问方式，为了克服数据访问的不便捷问题，最开始用于Hadoop的PIG语言开始支持HBase。PIG是一种操作Hadoop和Hbase的轻量级脚本语言，不想编写MapReduce作业的人员可以用PIG方便地访问数据。
跟HBase类似的另一个较为有名的系统是C++编写的Hypertable，也是BigTable的开源实现，不过由于后来维护的人员越来越少，以及Hadoop生态系统越来越活跃，渐渐地Hypertable被人们遗忘了。还有一个不得不提的系统是Cassandra，它最初由Facebook开发，也是一个分布式的NoSQL数据库。但与HBase和Hypertable是Bigtable的复制者不同，Cassandra结合了Amazon的Dynamo的存储模型和Bigtable的数据模型。它的一大特点是使用Gossip协议实现了去中心化的P2P存储方式，所有服务器都是等价的，不存在任何一个单点问题。Cassandra与HBase的区别在于：Cassandra配置简单，平台组件少，集群化部署和运维较容易，CAP定理侧重于Availability和Partition tolerance，不提供行锁，不适合存储超大文件；HBase配置相对复杂，平台组件多，集群化部署和运维稍微麻烦，CAP定理侧重于Consistency和Availability，提供行锁，可处理超大文件。
虽然Hadoop的MapReduce框架足够易用，但是对于传统使用SQL操作的数据仓库类需求时，直接调用Map和Reduce接口来达到类似效果，还是相对繁琐，而且对不熟悉MapReduce框架的使用者来说是一个门槛，因此hive就是为了解决此问题而诞生。它在Hadoop上建立了一个数据仓库框架，可以将结构化的数据文件映射成一张数据库表，并提供类似SQL的查询接口，弥补了Hadoop和数据仓库操作的鸿沟，大大提高了数据查询和展示类业务的生产效率。一方面，熟悉SQL的使用者只需要很小的成本就可以迁移至hive平台，另一方面，由于量级大而在传统数据仓库架构下已无法存放的数据，也可以较为容易地迁移到hive平台。因此hive平台已经成为了很多公司的大数据仓库的核心方案。