首先hadoop有两个含义，一个是广义相对论，一个是狭义相对论。狭义的就是指Hadoop这个分布式任务平台，不包括其他含义。如果从广相的角度来说，Hadoop不仅仅指的是这个分布式任务平台，还包括建立在Hadoop平台上的一系列软件，比如HDFS，Hive，HBase等等。这里面还有个特别的地方，HDFS从目前来看，已经超出了组件的概念，可以认为是等同于Hadoop平台存在的一个框架了。基本上只要涉及到大数据和云计算的，都离不开HDFS。
HDFS是一个分布式的文件系统，实现了分布式计算框架里最重要的一环，资源的跨物理机分布。任何分布式系统都需要解决一个问题，就是资源如何分布式存放。这里面涉及到高效的读写，多副本复制的安全措施，CRC校验等等确保文件不出错，还要考虑到节点之间的高可用等等问题。最后，还要尽可能的透明，尽可能的简单易用。整体来说，还是个很复杂的工程。HDFS以实践的方式证明了自己的高效和易用，以至于在喜欢出同类项的开源世界都没有同类项目存在。可以负责任的说，肯定有人也想做出类似于HDFS一样的东西来，但是出于种种原因，不管是技术难度还是时间问题，都没有能够匹敌的项目。
在Hadoop和HDFS的基础上，最常用的两个组件分别是Hive和HBase。可以简单的认为，Hive是离线分析引擎，使用类似SQL的 DSL来操作数据。Hive最擅长的是大数据分析，类似于Oracle的OLAP。HBase是一个面向高并发事务处理的框架，类似于OLTP。由于 HBase是列式存储，在做部分运算时效率要远超Oracle。现在陆陆续续有人在基于HBase开发一些使用SQL做DSL的应用，比如说CDH的 Impala。这部分框架还不是很成熟，对SQL92的支持也不是很完备。不过根据一些路线图来看，在不远的将来，会有完整支持SQL92的版本出现的。毕竟支持SQL92只是时间问题，并没有技术鸿沟。
接下来，我们来聊聊任务处理和调度部分的框架。最早也最原始的，是大名鼎鼎的三驾马车之一的MapReduce框架。MR从HDFS上读取文件作为数据来源，在经过map和(或)reduce阶段后，把计算结果提交给用户。MR的中间结果，会以文件的方式存放在HDFS上，简称落盘。这种处理方式，可想而知的，处理效率不会很好。毕竟分布式磁盘读写的效率取决于每一块磁盘的效率，还要扣除软件的消耗，整体效率不会很好。
正是由于这一系列原因，伯克利的高人们揭竿而起，创造了Spark内存处理框架。Spark和MR最大的不同，在于Spark的处理过程数据是不落盘的，全部在内存输出。此外，Spark不但可以按照传统的方式接受数据，还可以读取HBase上的数据，以及MQ里的数据。虽然说MR也可以做，但是自己做和原生自带的契合度，是不可同日而语的。
Spark对大数据贡献最大的部分，是他真正实现了流计算，Streaming。举个例子，我们需要进行实时数据分析，一旦有超速车辆，立刻扣分。如果不使用流计算，那么大致上我们需要不断扫描接口或者MQ，在触发以后生成MR任务或者Spark任务，计算完毕以后再关闭。好麻烦。
但是有了Streaming就不一样了，我们可以把数据丢进Kafka队列，Spark会帮我们做好剩下的事情。
Spark还有机器学习包MLLib，还有SQL实现，未来还会有更多更多的东西。好吧我是Spark粉。只是最近事情太多，一直没完整的时间来做这个。
