https://cloud.tencent.com/developer/article/1042387 转载自该文章，加上了自己的一些删减和补充。
Hadoop
Hadoop生态圈(或者泛生态圈)基本上都是为了处理超过单机尺度的数据处理而诞生的。
你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。
你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，
虽然奇怪的组合也能工作，但是未必是最佳选择。
Hadoop不是一个工具，也不是一种技术，是一种技术的合称。
HDFS
传统的文件系统是单机的，不能横跨不同的机器。
HDFS(Hadoop Distributed FileSystem)的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。
比如你说我要获取/hdfs/tmp/file1的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。
你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你管理这些数据。
Map Reduce
虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。
一台机器读取成T上P的数据，也许需要好几天甚至好几周。
对于很多公司来说，单机处理是不可忍受的。
如果要用很多台机器处理，我就面临了如何分配工作，如果一台机器挂了如何重新启动相应的任务，
机器之间如何互相通信交换数据以完成复杂的计算等等。
这就是MapReduce / Tez / Spark的功能。
举个例子，所有的书籍信息都存放在HDFS上，我需要统计每个单词的出现次数（经典的wordcount任务）。我们可以理解为在一千台电脑上，每一台上面都存放了很多的书的具体信息，在map阶段，我们让每一台电脑都统计这台电脑上面的书中的单词的出现次数，得到中间结果。在reduce阶段，我们让某些电脑综合所有电脑统计的中间结果，例如hello在第一台电脑出现了5次，在第二台电脑出现了3次，等等等等，那么在所有的电脑上就是出现了3+5+…次，最终把结果汇总返回给调用者。
Spark
第二代的Tez和Spark除了内存Cache之类的新feature，
本质上来说，是让Map/Reduce模型更通用，让Map和Reduce之间的界限更模糊，
数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量。
Hive
有了MapReduce，Tez和Spark之后，程序员发现，MapReduce的程序写起来真麻烦。
他们希望简化这个过程。这就好比你有了汇编语言，虽然你几乎什么都能干了，但是你还是觉得繁琐。
之前的Map Reduce类似于汇编语言，那么现在的spark就类似于python了，功能和Map Reduce类似，但是对于开发人员更加的友好，更方便使用。
Hive
你希望有个更高层更抽象的语言层来描述算法和数据处理流程。于是就有了Hive。
Hive用SQL描述MapReduce。它把脚本和SQL语言翻译成MapReduce程序，丢给计算引擎去计算，而你就从繁琐的MapReduce程序中解脱出来，用更简单更直观的语言去写程序了。
之前直接利用spark需要处理map和reduce的过程对于使用者来说都是隐形的了，就像使用本地数据库一样使用大数据文件。
例如之前的wordcount任务来说，通过hive，我们可以通过几句sql语句就可以达到类似的目的。类似于select word, count(*) from word_table group by word;
SqarkSQL和Hive on Spark
自从数据分析人员开始用Hive分析数据之后，它们发现，Hive在MapReduce上跑，很慢!
它们的设计理念是，MapReduce慢，但是如果我用新一代通用计算引擎Tez或者Spark来跑SQL，那我就能跑的更快。
而且用户不需要维护两套系统。
这就好比如果你厨房小，人又懒，对吃的精细程度要求有限，那你可以买个电饭煲，能蒸能煲能烧，省了好多厨具。
Yarn
有了这么多乱七八糟的工具，都在同一个集群上运转，大家需要互相尊重有序工作。所以另外一个重要组件是，调度系统。
现在最流行的是Yarn。你可以把他看作中央管理，好比你妈在厨房监工，哎，你妹妹切菜切完了，你可以把刀拿去杀鸡了。
只要大家都服从你妈分配，那大家都能愉快滴烧菜。
上面的介绍，基本就是一个数据仓库的构架了。底层HDFS，上面跑MapReduce/Tez/Spark，再上面跑Hive。
对于一个算法工程师来说，平时接触比较多的就是spark和hive。spark一般用来对于数据进行一次性提取，得到训练数据等。hive一般用来创建日常任务加到公司里面的调度系统中，每天都可以得到相对应分区的数据。
