Hadoop的出现，解决了大数据的两个核心问题：海量的数据怎么存储==>HDFS；海量的数据如何计算==>MapReduce。因此，大数据从业者需要对Hadoop的这两个系统有足够的认识，特别是对MapReduce的原理有深入的理解。作者使用Hadoop已有三个年头，使用经验总结起来就是五个问题，如果能答好，说明Hadoop是过关了。
但是，在大数据圈子混，光混Hadoop已经远远不够了。原因很简单，Hadoop有几个局限：
Hive的出现极大地降低了大数据的使用门槛，使大批数据分析师通过SQL语句就能拥有操控大数据集群的能力。Hive的出现完美地解决了Hadoop的局限1。然而，仅仅会写SQL完成大数据分析任务，只能说这位从业者及格了，但离优良还有一段距离。作者以为，掌握Hive的标志是给定任何一个SQL语句，从业者能够推导出其底层的MapReduce任务，并能据此对SQL的性能进行调优。
有一段时间，Spark真是火得不行，唱衰Hadoop的声音不断，让Spark成了新宠，几乎成了大数据的新代名词。事实上，Spark的核心贡献是开创性地引入了分布式内存RDD，从而在根本上解决了Hadoop的局限2。由于分布式内存的引入，使得批处理模式的延时变得很小，因而也突破了局限3，在实时计算领域打开了局面。Spark对数据从业者也十分友好，提供了一套语义表达非常丰富的API，使得开发者可以优雅地使用代码完成常见的数据操作。不得不说，Spark的商业设计确实精致，拳拳击中了老大哥Hadoop的要害。
Storm号称实时计算领域的Hadoop，但其实它跟“大数据”并无任何关系，只和“数据”有关，因为实时计算是在数据产生的时候就处理它，而不是攒一批数据到一定规模统一处理它，自然数据量就大不起来。Storm的作用是提供了一套API，用户依照API实现数据计算的业务逻辑，然后提交给Storm；Storm会把这个任务在多台机器上调度起来，7X24小时执行，并且在某个任务挂掉的时候将它重启。
HDFS解决了数据的分布式存储，但是要从海量的数据中查询某一条记录，是一件延时很高的事情。HBase的出现就是为了解决HDFS的这个问题，能够支持海量数据的快速查询和实时查询。
大数据必然依赖于多台机器，或者说一个集群。这些集群就像是一个动物园，需要有个管理者，否则乱成一团。ZooKeeper就是这个动物园的管理者，它是一套文件系统加通知机制，能够将各个机器有效地协调起来。