对于一些文科生、商科生来说，刚刚搞懂服务器、数据库、C++、Java等基础语言是个什么东西的时候，大数据时代来了。大数据时代，科技蜀黍们又玩起Hadoop、HDFS、MapReduce、Spark、HBase、NoSQL、Hive、pig……这些蛇精病和大怪兽了。看着这些彷若天书的大怪兽说明书，那叫一个崩溃。
于是，就有小伙伴跑来找小编能不能把能把这些混乱的技术妖词，做一个生态的比喻？比成，一棵树？一个城市？一个人的循环系统？随便比……总之让他们这些技术白痴也能搞明白，它们之间是什么关系，谁是干什么的？
于是，这篇文章就这样诞生了……（请原谅以下我风格的转变，因为我要说一个很严肃的问题）
大数据本身是个很广泛的概念，Hadoop生态圈基本上都是为了处理超过单个计算机所能计算处理的数据而诞生的。你可以把它想象成一个厨房中的各种厨具。什么锅碗瓢盆啊，各自有各自的用处，相互之间功能既能配合又有所重合。比如，你可以用锅直接当碗吃饭，或者你可以用小刀去皮。虽然把奇怪的工具组合起来也能工作，但这未必是最佳选择。
所以为了方便理解大数据生态工具的主要作用，我们先从大数据的存储说起。
之前的数据文件系统是单机的，不能链接不同的机器。HDFS的诞生本质上是为了使大量的数据能横跨成百上千台机器，让这些机器使用一个文件系统。比如你说我要获取hdfs/tmp/file1的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。你作为用户，不需要知道这些，就好比你根本不用关心你电脑的文件分别存储在什么磁道什么扇区一样。HDFS就像一个大管家，为你管理这些数据，你只需要调用即可。
存好数据以后，你必须考虑怎么处理这些数据。虽然HDFS可以帮你宏观上管理不同机器上存的数据，但是这些数据太多太多了。
一台机器读取TB级别乃至PB级别的数据（这个数据非常非常大哦，比你看的小电影有史以来所有高清的总和还要大很多哟），需要慢慢跑好几天甚至好几周。对于许多公司来说，这种时长是不可忍受的，比如各种小时更新、每天更新的热搜，它必须在规定时间之内跑完这些处理。
那如果用很多台机器处理是不是就会快很多？使用多台机器我们就面临了如何分配工作的问题，以及如果一台机器挂了如何重新启动相应的任务，机器之间如何互相通信交换数据以完成复杂的计算等等。
处理这些问题就是MapReduce / Tez / Spark的功能。MapReduce是第一代计算引擎，Tez和Spark是第二代。MapReduce的设计，采用了简化的计算模型，只有Map和Reduce两个计算过程（中间用Shuffle串联），用这个模型，已经可以处理大数据领域很大一部分问题了。
那什么是Map？什么是Reduce？
假如你要统计一个巨大的文本文件存储在HDFS上，你想知道文本所有词的出现频率。你启动了一个MapReduce程序，在Map阶段，几千台机器同时读取这个文本的各个部分，然后分别把各自获取的部分分别统计单词的出现频率，产生类似（hello, 12100次），（world，15214次）的对应词组；这几千台机器各自都产生了如上的集合，然后又有几千台机器启动Reduce处理。
Reducer机器1将从Mapper机器获取所有以A开头的统计结果，机器2将获取以B开头的统计结果（实际上不会真的以字母作为开头依据，而是用函数产生Hash值以避免数据互串。因为英文中X开头的词比其他的要少很多，而我们并不希望各个机器的工作量相差太大）。
然后这些Reducer将再次汇总，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每个Reducer都像上方那样处理，你就得到了整个文件的词语出现频率的结果。
这是个很简单的模型，很多算法都可以用这个模型来描述。
Map＋Reduce的模型粗暴简单，虽然很好用，但是很笨重。第二代的Tez和Spark除了内存存储之类的新特征，本质上来说，是让Map/Reduce模型更具有适用性，让Map和Reduce之间的数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量。
有了MapReduce，Tez和Spark之后，程序员蝈蝈们发现，MapReduce的程序写起来真TM复杂，他们希望简化这个过程。
于是就有了Pig和Hive。Pig是用接近脚本方式去描述MapReduce，Hive则用的是SQL。它们把脚本和SQL语言翻译成MapReduce程序，丢给计算引擎去计算，而你就从复杂的MapReduce程序中解脱出来，用更简单更直观的语言去写程序了。
有了Hive之后，人们发现SQL对比Java有巨大的优势。SQL太容易写了，刚才词语出现频率的问题，用SQL写就是一两行的事儿，而MapReduce写起来要几十上百行。更重要的是，这解放了非计算机背景的用户：我也是会写SQL的！
于是数据分析人员终于从每天跪舔工程师蝈蝈中解脱出来，工程师蝈蝈也从写奇奇怪怪的一次性处理程序中释放出来，这样你好我好大家好，都开心了。因此，Hive逐渐成长为大数据仓库的核心组件，因为易写易改，一看就懂，容易维护。
自从数据分析人员开始用Hive分析数据之后，它们发现，Hive在MapReduce上跑，真TM慢！流水线作业也许还能用用，比如24小时更新的推荐，反正24小时内跑完就算了。
但是数据分析作业，人们总是希望能跑更快更快。比如我希望看过去一个小时内有多少人在情趣小道具的页面驻足，分别停留了多长时间，对于一个像某宝这样拥有海量数据的网站，这个处理过程可能要花几十分钟甚至N个小时。而这个分析只是你漫漫长路的第一步，你还要看多少人浏览了情趣衣服、多少人看了贝多芬的CD，以便跟boss汇报，我们的用户是猥琐男、闷骚女更多还是文艺青年更多。你无法忍受等待的折磨，只能跟帅帅的工程师蝈蝈说，快，快，再快一点！
于是Impala，Presto，Drill诞生了。这三个系统的核心设计理念是，MapReduce引擎太慢，因为它适用性太强，太强壮，太保守，我们SQL需要更轻量，更激进地获取资源，更专门地对SQL做优化，而且不需要那么多容错性保证（因为出错了大不了重启，如果整个时间更短的话，比如几分钟之内）。
这三个系统让用户更快的处理SQL任务，牺牲了通用性和稳定性等。如果说MapReduce是大砍刀，砍啥都不怕，那上面三个就是剔骨刀，灵巧锋利，但是不能搞太大太硬的东西。
这些系统，说实话一直没有达到人们期望的流行度，因为这时候有两个异类被造出来了。他们是Hive on Tez / Spark和SparkSQL。它们的设计想法是，MapReduce实在是太慢了，但是如果我用新一代通用计算引擎Tez或者Spark来跑SQL，那我就能跑的更快，而且用户不需要维护两套系统。这就好比如果你厨房小，人又懒，对吃的精细程度要求有限，那你可以买个电饭煲，能蒸能煲能烧，省了好多厨具。
上面的介绍，基本就是一个数据仓库的构架了。底层HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。这解决了中低速数据处理的要求。
那如果我追求更高速的处理呢？
如果微博是我家的，我希望显示不是24小时热博，我想看一个不断变化的热播榜，更新延迟在一分钟之内，上面的方法就无法胜任了。
于是又一种计算模型被开发出来，这就是Streaming（流）计算。流计算的思路是，如果想要实时的更新，我为什么不在数据流进来的时候就处理了？比如词频统计的那个例子，数据流是一个一个的词，我就让他们一边流过一边统计。
流计算非常牛逼，基本没有什么延迟，但是它的缺点是，不灵活，想要统计的东西必须提前知道，毕竟数据流过就没了，没算的东西是没有办法补算的。因此它很方便，但是没办法替代上面数据仓库和批处理系统。
有了这么多乱七八糟的工具，都在同一个计算机集群上运转，大家需要互相尊重有序的工作，所以这其中一个非常重要的组件是调度系统。现在最流行的是Yarn，你可以把他看作指挥工作的。好比你妈妈在厨房监工指挥，叫你切菜切完去拿刀杀鸡。只要大家都服从你妈妈分配，那大家都能愉快滴烧菜。
所以大数据生态圈就是一个厨房工具生态圈，为了做中国菜，日本菜，法国菜，你需要各种不同的工具。而且随着客人的需求越来越复杂，你使用的厨具也会不断被发明，也没有一个万用的厨具可以处理所有情况，因此整个生态圈里的工具会变的越来越多、越来越复杂。
閱讀更多 睿帆大數據 的文章
