如何用形象的比喻描述大数据的技术生态？Hadoop、Hive、Spark 之间是什么关系？

对于我们这些文科，商科生来说。我们刚刚搞懂服务器，数据库，C++，Java等基础语言是个什么东西的时候，大数据时代来了，科技蜀黍又玩起Hadoop，HDFS，MapReduce，Common，Spark，Mahout，HBase，NoSQL，Cassandra，GFS, MapReduce, BigTable，Hive，Pig……这些蛇精病和大怪兽了。我不认识它们，还有什么妖怪没记进来的，请各位继续在评论里补充。
可各位大神能不能把这些混乱的技术妖词（对不起，正是因为不懂，所以很乱），做一个生态的比喻？比成，一棵树？一个城市？一个人的循环系统？随便你比……总之让我们这些技术白痴也能搞明白，它们之间是什么关系，谁是干什么的？
叩谢。

草地上开满鲜花，可牛群来到这里发现的只是饲料。
                                                      --王朔
这也许就是很多人对这些看似杂乱无章的开源项目的感觉吧。以下是原回答。
那我就把大数据生态比喻成马戏团吧
hadoop是头大象，能吃（hdfs能存很多数据），力气大（Map-Reduce有很强而且scalable的计算能力），还聪明（有还不错的任务管理调度能力）。但有点笨重。
hive是个训练大象的师傅，其实hive自己并不“干活”，它是指挥着前面那头大象做事。最早的hive on mapreduce，其实就是把sql翻译成map- reduce任务给Hadoop做。有了hive这个驯兽师之后，很多只会写sql小孩子们也可以很轻松的和大象玩了。
spark是个老虎，力量强，速度快。老虎是看到早先大象计算方面就只会map-reduce这一招，而且这一招十分死板，每做完一步，都要写回到hdfs。那spark说，我就灵活一点吧，那就把一些操作放到内存中，而不是每次都要写回到存储了。
这时候hive就看到了机会，那我不驯大象了，我训老虎吧，于是就有了hive on spark, 其实是一样的，简单来说，hive还是起到sql翻译的作用，让spark去干真正的工作。当然，类似的还有hive on tez，这时候hive就是一个全面的驯兽师了。
很多人发现spark这个猫科动物比较聪明，人们又让他学了sql，ai， graph等技能，于是就有了spark-sql， spark-ai 和spark-graphx等模块或者说library。这时候我们也把spark作为一个完善的生态圈来看待，可以叫马戏团之spark老虎分团。
后来还有了presto这种猎豹，完全依靠自己的调度器和内存进行计算，只是用hdfs存原始的数据，这个速度就又快了不少，但豹子毕竟力量有限，特别是如果你presto集群规模比较小，有些特大数据量的query就跑不了了。
再后来，大家觉得大象的hdfs存储也有些不够用了，于是又有了对象存储s3等，也有了alluixo这些缓存层。
马戏团的动物可以各种各样，但戏法（应用场景）却就那么些，也就是analytic sql query, AI, ETL, graph等，老虎能钻火圈，豹子没准也能，所以会有不少的重叠，这个时候就需要根据自己的具体情况酌情选用。
最后，祝大家在大数据马戏团玩的开心。

没想到凌晨随便一写竟然有人看，刚好最近在招大数据实习生，发现简历很多都是只知道些算法，对大数据生态一点都不知道。如果真想做数据，除了SQL，这些该知道的还是需要知道的。
<hr/>1
Hadoop只是一套工具的总称，它包含三部分：HDFS，Yarn，MapReduce，功能分别是分布式文件存储、资源调度和计算。
按理来说，这就足够了，就可以完成大数据分析了。
但第一个问题就是麻烦。这一套相当于用Yarn调度资源，读取HDFS文件内容进行MR计算。要写Java代码，但做数据的最好的工具是什么？SQL！所以Hive相当于这一套标准流程的SQL化。
Hive可以简单理解为，Hadoop之上添加了自己的SQL解析和优化器，写一段SQL，解析为Java代码，然后去执行MR，底层数据还是在HDFS上。
这看起来挺完美，但问题是程序员发现好慢啊。原因是MR，它需要频繁写读文件。这时基于内存的Spark出现了，Spark是替代MR的，它会为SQL生成有向无环图，加上各种算子和宽窄依赖的优化，使得计算速度达到了新的高度。
按理说这就完美解决了呀。
但是，我们回头想想，这些数据怎么来的呢？我们是不是到目前为止都是在处理静态的数据呢？像比如线上支付校验这种需要实时返回结果的总不能等着Spark批量算吧。
解决问题之前，我们回头再想想，数据怎么来的。一般数据包含两种：业务数据和日志数据。
业务数据就是数据库中的结构性的数据，规规整整。业务数据怎么到Hive呢？开源上一般通过Sqoop进行导入，比如一张表，数据少每天我把表全部导入一遍，这叫全量同步；数据特别大，就只同步每天变化和新增的，这是增量同步。
但这种同步比较滞后，都是在夜深人静集群的计算资源比较空闲的时候做的，对应的也是离线分析。
实时的数据产生了该怎么拿到呢？
2
实时怎么理解？来一批处理一批，再细一点儿，来一条，处理一条。
比如，你买一件东西，平台数据库中会多一条订单数据，app会产生行为日志数据。订单数据插入数据库时一般会有binlog，即记录插入、更新或删除的数据，我们只要能实时拿到这一条binlog，就相当于拿到了实时数据。
binlog怎么拿呢？这就要说道数据库的主从备份机制，一般本身就是拿主库的binlog同步到备份库，刚好有一个叫canal的工具可以把自己伪装成备份库，来拉取主库的binlog，再解析、包装最后抛出，就相当于实时拿到数据了！
canal拿到了binlog就能直接处理了吗？可以，但有件事儿大家想一想。马上五一了，加入一下子超级多人下单消费，canal抛出的消息我们下游一下子消费不完咋办呢？比如快递员每天都只给你派送一件快递，你拿到之后钱货两清。然后突然一天快递员给你送一千件到你楼下，你下楼一件一件搬，快递员还得等你搬完才能回去，这得等到啥时候。聪明的你马上想到了，放快递柜呀，你有时间慢慢搬不就行了，也不占用快递员的时间了。
这就是消息队列，Kafka 就是起这样的作用：异步、解耦、消峰。canal的数据一般会抛到kafka或RocketMQ，可以保存一段时间。然后下游程序再去实时拉取消息来计算。
3
说了这么多下游，下游到底由谁来消费计算这些实时数据呢？还记得Spark吗，没错它又来了，Spark streaming就是处理实时流数据的好手。
Spark 是一整套组件的统称，比如你可以用 Java 写 Spark 任务，用 Spark SQL 去写 SQL，可以用 Spark MLib 完成机器学习的模型训练等等，Spark Streaming 就是用来微批地处理流式数据的。
具体而言，离线数据我们是等半夜数据都抽到 Hive 中再计算，而 Spark Streaming 则是实时数据来一小批，它就处理一小批。所以本质上讲，Spark Streaming 还是批处理，只不过是每一批数据很少，并且处理很及时，从而达到实时计算的目的。
Spark 本身的流行使得 Spark Streaming 也一直大范围使用。
这一套有什么逻辑缺陷吗？
我们可以想一想，实时数据和离线数据最大的差异，是时效性。离线数据像湖水，该多少就多少，就在那里；实时数据像水流，绵绵不绝。时间，便是非常重要的一个特质。当一条数据来的时候，我们需要知道这条数据是什么时候产生的，这便是业务时间。但我们拿到这条数据时往往是业务时间之后的一小会，这边是处理时间。真正世界里的实时数据肯定不是像 Spark Streaming 那样一批一批来的，而是一个一个的事件。对此，Flink 帮助我们解决了这些问题。
4
无论是业务数据还是日志数据，往往都有相应的时间标志字段，代表着这条消息的业务时间。你可以让 Flink 选择这个时间，这样，Flink 就知道当前处理到哪个时间点了。
Flink 不同于 Spark Streaming 的微批次处理，它是一条一条数据处理的。这样的数据一般是先来后到的，但难免会有些数据沿途受阻晚来了几秒钟，这就会导致两个问题：数据延迟和乱序数据。这也是做实时数据的非常关注的问题。
如何防止数据延迟？如果是上游数据迟了，就加大上游资源；如果是数据突然激增，导致 Flink 处理不过来导致任务出现延迟，就加大 Flink 的资源，比如并发。
数据乱序呢？
同样的，我们一般也通过上游和 Flink 本身来分别保证。
我们上面提到了消息的快递柜 Kafka，Kafka 有分区的概念，就像是不同的通道，一条消息来了后，可以走 A，也可以走 B，也可以走 C。那么问题来了，现在面试官问你，业务数据抛入 Kafka，如何保证消息的顺序性呢？
(5月4日 更）
顺序性一般有两方面需要保证。我们举一个小小的例子，一个用户下单的场景，有两个基本共识：

• 同一个用户的订单状态会先后变化；
  
• 不同用户的不同订单也有先后之分。
  

所以我们解决数据的顺序性一般也是从这两方面考虑。如果你还记得大学高数里的多元函数求偏导，对于 x 和 y 两个变量，求 x 的偏导会假设 y 为常量，反之同理。我们考虑这个问题也一样，如果不能同时兼顾这两方面，那就一个一个去优化吧！这种思想也称为贪婪算法，在很多地方都有应用，这里暂时说到这里。
回到问题，那么如何保证同一用户的订单顺序呢？很简单，前面我们提到的链路是，数据库中插入或更新数据时，会实时产生该条数据的 binlog，canal 获取、解析、包装这条 binlog 并抛入 Kafka。
而 Kafka 由于有分区的存在，很可能同一个订单的消息会被发送到不同的分区中，这样的话，如果下游的 Flink 任务消费不同分区速率不同，就可能导致先到的数据反而被后消费，产生顺序误差。解决的办法即保证同一订单的消息进入 Kafka 的同一分区即可。
Kafka 的每一条消息都会有 messageKey 和 message 两个结构，如果没有直接给消息指定分区，那么 messageKey 决定了消息进入哪个分区，在 canal 中，我们便可以设定消息如何进入 Kafka。数据库中的业务数据，会存在一张张的表中，表一般都会有主键，来唯一标识一条数据，我们一般也就是通过设定 canal 选择 binlog 所在表的主键来决定其进入 Kafka 的分区。这样，就基本解决了第一个问题。
（5月9日 更）
但这只保证了同一订单数据的顺序性，并未保证不同订单之间的顺序性。聪明的你可能已经想到，如果 Kafka 只设定一个分区那不就保证了吗？但这其实算是本末倒置，Kafka 本身相当于快递柜，多个分区相当于多个柜子，能存储更多的数据，提高并发，如果为了顺序性而牺牲并发量，那就得不偿失了，而且一般本身数据的乱序无论是在概率和重要性方面都不如并发重要的。就比如我要统计每小时的订单数，即使数据乱序了，只要在窗口区间内计算结果也不怎么受影响。
但这并不是说我们就不考虑数据在全局的顺序性了。
我们如何去认识乱序或延迟数据呢？
既然这种情况是偶发性的，那么一般可以这么做，在实时的流数据中，如果想要拿到 T 时刻的数据，只要等一小会儿比如 1s，就能保证在 T+1s 的时刻拿到 T 时刻的所有数据。
上面这句话其实理解起来也很简单，比如幼儿园老师组织小朋友们春游，约定了早上 8:00 集合发车，即 8:00 触发一个事件。但总有那么几个调皮捣蛋的学生会迟到几分钟，于是老师说好的 8 点发车实际上是8:05，大家觉得也没啥问题，回家就跟家长说，我们今天 8:00 发车春游啦。
在 Flink 中，这种机制就叫做 watermark。
上面我们说过，每一条数据一般都会自带一个时间字段，来标志这条数据的业务时间，即什么时候发生的。然后 Flink 提取这个时间字段，就知道了目前 Flink 任务进行到几点了。
那么既然要考虑乱序或迟到数据，我们一般也会让 Flink 当前的时间稍微迟几秒钟。比如我们认为大部分情况下乱序或迟到的数据都在 1s 以内，那么来一条数据，比如这条数据自带的时间是 08:00:01，那我们就认为 08:00:00 时刻的数据才刚到齐。但回过头来说，在大多数场景下，毕竟乱序或迟到数据算是占比很小了。
5
是不是看到这里有点抽象了？下一节我们聊聊 SQL 吧。

你叫杰杰马，你来到了青青草原，找了一块风水宝地插了个旗子，上面写着淘淘村，于是你成为了一个小村庄的村长。
（你创建了个互联网应用）
你还别说，这个小村庄还真有人来住，慢慢的有了几十号村民，还有过来吃住玩的旅人游客。
（你有了用户）
他们每天都会产生很多的生活垃圾，有残羹剩饭排泄物，有蛛丝马迹猫抓板，有记载着海贼王宝藏的藏宝图，有昨夜被谋杀的无名女尸，也有无人认领的大金链子……
（他们使用的同时产生各种各样的数据）
你暂时还没觉得这些垃圾有什么用，直接丢掉又有些可惜，你说我们建个大房子，把他们都装起来。
（你找了台服务器把数据（日志）存储起来）

第一章 HDFS
有一天，你的手下喜羊羊告诉你，这些垃圾对我们是有用的，残羹剩饭我们可以喂猪，无名女尸我们可以用来破案抓凶手，大金链子可以用来拴村口的大黄。
（你发现了数据的价值）
于是你又建立了个垃圾处理站，分类垃圾，处理垃圾。将处理好的垃圾变成资源，放到垃圾房的另一个角落摆的整整齐齐。
（你在这台服务器上写了几个数据（日志）处理程序，变成可用的数据）
生产大队、派出所、军需官都会不时过来取一些资源。
（各部门发现数据的价值）
日子一天天过去，你的小村庄慢慢发展成了小镇，之后又变成了一座城市。
（你的用户暴涨、飞速发展）
你的手下告诉你，垃圾生产的速度太快了，我们的垃圾房已经装不下垃圾了，垃圾处理站也处理不过来垃圾了！
（单机无法处理爆炸的数据）
“我们盖更大的垃圾房，找更能干的人来处理垃圾”
（你换更大硬盘更高处理器的服务器）
“不行啊城主，我们已经重建好几次垃圾站了，这个垃圾房是目前技术能盖的最大的房子了”
（除非你上超级计算机）
“那怎么办呢？”你着急的问道。
“”城主大人，你是沙雕吗？一座垃圾房放不下，我们多盖几座不就行了？”
“城主大人我当然不是沙雕，你呀，喜羊羊，你就是图样图森破，sometimes naive！我多盖几座，又没有钱每座都花大价格精装修消防，万一某一座失火了怎么办？”
（多台廉价商用机可能需要容错处理）
喜羊羊得意一笑:“城主大人，要解决这个问题其实一点都不难”喜羊羊吃了口羊肉串，喝了口扎啤接着说到:“城主大人，你忘了吗，我们只是把数据比喻成生活垃圾，数据有一点特别的地方，就是我可以拷贝复制，如果我进行多重备份，如此这般”



“这样，任意一台，啊不，一座垃圾房失火了，1234号垃圾箱都还在的，而且如果1号垃圾箱需要的人不较多，去abc三座垃圾房都可以取，也不会产生某一座垃圾房需要排队，其他垃圾房无人问津的问题。”
（HDFS即Hadoop Distribute File System，分布式文件储存系统，解决了数据分布式存储解决了多台存储单机热点、数据不安全、文件整理困难等问题，突破了存储限制）
喜洋洋看着一脸白痴的你，得意的接着说道：“我把这些存储垃圾与资源的垃圾房命名为垃圾仓库（datanode），在垃圾仓库ABCD之外，还有一个垃圾仓库管理中心（namenode）每次垃圾入库，需要管理中心安排垃圾自我复制多份放到不同的仓库，每次有人来取，需要去管理中心查询所需垃圾在哪些仓库并就近获取”
（namenode管理元数据，负责HDFS上数据的读写）
你觉得没有问题，得意的大笑：“有了这个套方案，不论再多的垃圾我都可以放的下，哈哈哈。喜羊羊，你不再是一只羊，以后你就叫做哑虎吧，你的部门就叫做Hadoop吧，这套方案就叫HDFS吧”

第二章 MapReduce
你以为有了这要垃圾存储方案，你就可以高枕无忧了，然后没几天就收到了很多问题。
（只解决海量数据存储是不行的）
你的各部门收下告诉你，虽然我们的垃圾都够放，并且井然有序，可以我们只有一个垃圾处理站，根本满足不了各个部门的需求，每天垃圾处理站门口排队的人比回龙观早高峰的地铁人还多。
（还需要解决海量数据计算）
于是，你又把哑虎叫了进来，“你们Hadoop部门顺便把海量计算也解决了吧”
喜羊羊早有准备，娓娓道来：“首先，我们肯定是要建很多的垃圾处理站，但是这些垃圾处理站是不能各干各的活的，因为垃圾直接是存在各种联系的”喜羊羊吃了口烤狼腰子，接着说道：“为了解决这个问题，我决定建一个叫做MapReduce的车队，Map阶段车队把垃圾分发给多个处理站，Reduce阶段车队把多个处理站处理的解决汇总给一个处理站再处理”
“你在说什么我完全听不懂”
“好的城主大人，举个例子。派出所的夏洛克同学想要知道昨天我们城死了多少男人和多少女人。第一步Map，把昨天五百吨的垃圾交给五个垃圾站，每个垃圾站统计分到的100吨垃圾中有多少男人尸体和多少女人尸体。第二步Reduce，把五个处理站的结果汇总到一起加起来，得到昨天我们城一共死了多少男人、多少女人。”
“等等，我大概理解了，你能不能换个例子”
“好的，请看下图”



“我们在垃圾中发现了面包和蔬菜，交给各个处理站处理切碎，然后Reduce给一个处理站就得到了面包，然后放到HDFS就是资源啦”
“好的，我明白了，你不用再举这些恶心的例子了。以后HDFS、MapReduce都是你们垃圾部，不对，Hadoop部门管辖，希望你们把大垃圾处理事业发扬光大。啊，我仿佛看到了大垃圾时代的到来！”
（于是，有HDFS和MapReduce这两个组件组成的Hadoop1.0诞生了）




<hr/>2019-01-24 更新
第三章 Haddop2.0
有人的地方，就有江湖。
（这句话没什么用）
我们的喜羊羊同学麾下的大垃圾部越来越庞大。
除了之前负责分布式存储垃圾的HDFS部门和负责分布式处理垃圾的MapReduce部队。为了解决部队资源的使用问题，喜羊羊成立了军机处：YARN。将所有的车、马、人等资源牢牢掌握在自己手中，每一次MapReduce部队的任务都需要在yarn这里申请、分配资源，喜羊羊对外宣称这是为了资源统一管理，提高利用率，然而坊间传闻，这是喜羊羊日益膨胀的野心与掌控欲的结果。
（YARN是Hadoop 2.0中的资源管理系统,它把集群的内存、cpu等资源抽象为资源池，负责整个系统的资源管理和分配，同时也可以监控管理程序应用。）
当喜羊羊推出他的特设组织Hive的时候，更是赢得了此时已经称王的你：杰杰马一世的欢心 和各部门大臣的信任。
（嗯，杰杰马接下来没多少戏份了）
Hive组织由一群高素质的人才组成。他们首先解决了一个痛点：各部门去使用垃圾的人习惯了说SQL这种语言，而MapReduce那群外邦过来的彪形大汉只会讲Java语言。让所有使用垃圾的人都会Java有些困难，并且还需要用java指挥他们去干活！所以真正能指挥MapReduce这个部队的只有一部分人。
（学习成本很高，一般数据分析、产品经理用不了，专业的工程师才会写MapReduce）
但是Hive出现了，他们充当了翻译官，并且熟悉MapReduce的工作方式，各部门只需要去找Hive组织，HIve再将SQL翻译给MapReduce。并且Hive这群复合型人才把HDFS上的各种处理好的垃圾分门别类管理的井井有条。
（Hive是一个基于HDFS的数据仓库工具，可以将Hive SQL转化为MapReduce进行数据处理查询的工具）
而当NoSQL家族的Hbase一支族人也来投奔，弥补了Hadoop部的重大短板，喜羊羊大宴三天，骄傲的说：大垃圾处理的大厦已经落成了，后人只需要在此基础上修修补补就好啦。
（Hbase是Hadoop项目的子项目，是一个分布式的、面向列的NoSQL数据库，虽然不是基于MapReduce，但是也是可以存储、处理大规模的数据，是Hadoop家族重要的一员）
（我找了一张Hadoop2.0的图）



喜羊羊成为了王国第一大红人，他位极人臣的权利带给他以奢靡著称的生活。据说喜羊羊大人杀了三千头狼取其腰子做烤狼腰子招待远道而来的Hbase的族人们，一时间导致王城方圆百里没有狼敢靠近。同时，喜羊羊傲慢的性格，蛮横的作风也让很多大臣敢怒不敢言。
（这一段是伏笔，没错，本程序员还会写伏笔）
然而，在一个叫做伯克利的地方，一个叫做Spark的组织建立并发展，号称一站式垃圾处理平台，妄图革了Hadoop和喜羊羊的命！
<hr/>2019年9月11日更新
第四章 Spark
十二时辰
"不..不好啦,不好啦喜羊羊大人!!!"
喜羊羊懒洋洋的从美羊羊身边起身:"吵什么吵?什么事情大惊小怪"
"报告大人,据垃(数)圾(据)异常监控部门报告,今日午时左右一伙狼卫偷偷入城了! 明日可是杰杰马圣人,大宴万国的中元夜,可不能出任何差池呀!!!"
喜羊羊大惊:"快,快!联系storm部门,实时分析垃(数)圾(据),限你十二个时辰内找到这伙狼卫的位置!联系hive和mapreduce部门,分析出他们的目的"
(storm 是一个分布式实时大数据处理系统)
"好哒大人"
手下退去,喜羊羊着急的来回踱步
"这群可恶的狼,我不就杀了他们一点族人么"
......
四个个时辰过后,喜羊羊还在踱步.
"报告大人~"
"怎么样,狼卫抓到了没有?"喜羊羊着急的问道.
"还没有啊大人,storm吞吐量有限,无法实时处理全皇城的垃圾,这群狡猾的狼卫好像对我们比较了解,没有避开了我们监控的垃圾站点"
(storm实时性高,但是吞吐量有限)
"唉! 这群不争气的东西,那hive部门有没有分析出狼卫的目的呀?"
"报告大人,还在算! "
"怎么还没好?虽然我们比较懒散腐败,没有建立完善合理的垃圾仓库(数据仓库),导致MR任务需要算全城的垃(日)圾(志),这样比较慢,也不至于这么慢吧"
(建立晚上的数据仓库,分层分表有助于提高数据查询效率)
"大人,原来您心里有B树呀.原因是这群狡猾的狼卫昨晚在全城各处散播了很多脏垃圾(数据),数据挖掘部门的同学正建立新的模型,清洗垃圾(数据),算出他们真正的目的"
(脏数据会影响数据分析与数据挖掘建模)
"快去快去,对话这么多读者看的很累的"
......
十个时辰过后,喜羊羊还在踱步.
"报告大人~"
"怎么样,狼卫抓到了没有?"喜羊羊着急的问道.
"找到了大人,狼卫们,在花萼相辉!和杰杰马圣人在一起,圣人令您马上召见"
喜羊羊脸青一阵白一阵:"快!备马"


--- 花萼相辉楼.---
万国朝拜,开过大帝,杰杰马一世.
喜羊羊拜见,看到杰杰马身旁之人后,大惊:"啊! 似他,似他,似他,就似他!""
"我们的朋友,小哪吒?"
(哪吒:你个瓜皮,怎么抠能是我呐)
喜羊羊咬牙切齿的说道:"他就是Spark的首领狼王--------灰!太!狼!"
(duang~ duang~ duang~ spark 登场)
灰太狼的眼神冷冷的看着喜羊羊.心中叹到:"我儿小灰灰,今日就是你大仇得报之日"

杰杰马咳嗽了一声:"喜羊羊,听说今日有一伙刺客进了皇城想要行刺朕,你可查明?"
喜羊羊背上一身冷汗,还未开口,杰杰马接着说道:"不用回答我也知道,整整一天,你们一无所获.我身边这位是从遥远的伯克利投奔而来的Spark首领灰太狼同学,他们的spark streaming进行实时垃圾处理,吞吐量巨大,全城的垃圾都可以实时监控,比你们的strom高到不知哪里去了"
(spark streaming 微批次准实时处理数据吞吐量巨大,应用于很多的实时数据统计场景)
喜羊羊张口无言,还想说什么.
杰杰马接着到:"你想说你们的MR离线处理吗?哼!朕给了你们一下午时间,什么都没有算出来,看看人家Spark,计算速度比你们快多了,而且可以处理的垃圾量也不比你们少,而且在清洗刺客留下的脏垃圾(脏数据)上,进行多次迭代运算,更是你们快的多,灰太狼爱卿告诉朕,他们是基于内存..啊,DAG有向无环图还有什么RDD的反正朕也不懂,朕只看结果,如果没有灰太狼,今日朕被刺客暗杀了都不知道!"
(Spark core相比与MR,计算速度更快,特别是迭代运算,提供众多算子和支持多种语言,通用性上也更好,基于的RDD数据模型可以在不存储中间结果数据的情况下容错等优势)
"可是!圣人!"喜羊羊刚想说这伙狼卫很有可能就是和灰太狼一伙的,但是又苦于没有证据,哑口无言.
杰杰马道:"你是说你们部门有hdfs,yarn,hive这些吗?灰太狼爱卿已经告诉朕了,他们的spark团队可以和你们这些部门完美配合,如果他们死忠于你,灰太狼爱卿也从伯克利带来了mesos,,tachyon,spark sql等替代品"
(伯克利数据栈也有分布式存储系统和资源管理系统,不过目前很多公司选择yarn,hdfs,hive和spark结合)
喜羊羊脸色雪白,"不!hbase,Cassandra,redis他们这些nosql呢?"
(spark可以很方便的读写各种nosql)
"他们不来也不是你们hadoop专属,他们表示很乐意和spark合作"
"还有我新招募的kafka,rabbitmq呢?"
(消息队列也支持)
"哼!" 杰杰马只回答了一个字.接着说道 "之前一直听说你不在乎zookeeper,今天算是见识到了".
(之前忘说zk了,这次补上zookeeper是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的)
"喜羊羊,你任人唯亲,贪污腐败,骄奢淫逸,不思进取,尸位素餐!你可知罪"
"呃,圣人你怎么突然会那么多成语了"
"少废话,把喜羊羊压入天牢,三司会审!"
"圣人,不要啊圣人,雅蠛蝶,饶命呀"
杰杰马面无表情看着喜羊羊被拖下去,显然内心早就不满各种吐槽hadoop家族了.然后笑眯眯的转向灰太狼
"灰太狼爱卿,我们淘淘帝国的大垃圾处理确实要技术升级了,你们spark和伯克利数据栈的其他同学们就接手喜羊羊下的各个部门吧"
"臣领旨,定不负皇恩"
众人高呼万岁
"圣人万岁,圣人英明,青青草原,淘淘千秋~"

--- 天牢.---
喜羊羊目光呆滞,心如死灰.
这时,一个声音从暗中传来:"喜羊羊,你想打败灰太狼吗"
"想!"喜羊羊脱口而出"你是谁???"
"嘎嘎嘎嘎嘎~ 我是谁?我比spark还大一岁,但是他们总说spark比我成熟,我知道我迟早有一天会取代他,你说我是谁?"
喜羊羊吃鲸到:"难道你就是"
"Flink!"
第五章 Flink
<hr/>转载请署名，图侵删

学习很重要的是能将纷繁复杂的信息进行归类和抽象。
对应到大数据技术体系，虽然各种技术百花齐放，层出不穷，但大数据技术本质上无非解决4个核心问题。

• 存储，海量的数据怎样有效的存储？主要包括hdfs、Kafka；
  
• 计算，海量的数据怎样快速计算？主要包括MapReduce、Spark、Flink等；
  
• 查询，海量数据怎样快速查询？主要为Nosql和Olap，Nosql主要包括Hbase、 Cassandra 等，其中olap包括kylin、impla等，其中Nosql主要解决随机查询，Olap技术主要解决关联查询；
  
• 挖掘，海量数据怎样挖掘出隐藏的知识？也就是当前火热的机器学习和深度学习等技术，包括TensorFlow、caffe、mahout等；
  

大数据技术生态其实是一个江湖....
在一个夜黑风高的晚上，江湖第一大帮会Google三本阵法修炼秘籍流出，大数据技术江湖从此纷争四起、永无宁日...
这三本秘籍分别为：

• 《Google file system》：论述了怎样借助普通机器有效的存储海量的大数据；
  
• 《Google MapReduce》：论述了怎样快速计算海量的数据；
  
• 《Google BigTable》：论述了怎样实现海量数据的快速查询；
  

以上三篇论文秘籍是大数据入门的最好文章，通俗易懂，先看此三篇再看其它技术；
在Google三大秘籍流出之后，江湖上，致力于武学开放的apache根据这三本秘籍分别研究出了对应的武学巨著《hadoop》，并开放给各大门派研习，Hadoop包括三大部分，分别是hdfs、MapReduce和hbase：
hdfs解决大数据的存储问题。
mapreduce解决大数据的计算问题。
hbase解决大数据量的查询问题。
之后，在各大门派的支持下，Hadoop不断衍生和进化各种分支流派，其中最激烈的当属计算技术，其次是查询技术。存储技术基本无太多变化，hdfs一统天下。
以下为大概的演进：
1，传统数据仓库派说你mapreduce修炼太复杂，老子不会编程，老子以前用sql吃遍天下，为了将这拨人收入门下，并降低大数据修炼难度，遂出了hive，pig、impla等SQL ON Hadoop的简易修炼秘籍；
2，伯克利派说你MapReduce只重招数，内力无法施展，且不同的场景需要修炼不同的技术，太过复杂，于是推出基于内力（内存）的《Spark》，意图解决所有大数据计算问题。
3，流式计算相关门派说你hadoop只能憋大招（批量计算），太麻烦，于是出了SparkStreaming、Storm，S4等流式计算技术，能够实现数据一来就即时计算。
4，apache看各大门派纷争四起，推出flink，想一统流计算和批量计算的修炼；

以上，如有帮助，别忘了点个赞，谢谢

手撸【您可能感兴趣的内容】：
零基础学习 Hadoop 该如何下手？什么是机器学习？hbase和hive的差别是什么，各自适用在什么场景中？如何创建一个大数据平台？具体的步骤

7大数据本身是个很宽泛的概念，Hadoop生态圈（或者泛生态圈）基本上都是为了处理超过单机尺度的数据处理而诞生的。你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，虽然奇怪的组合也能工作，但是未必是最佳选择。
大数据，首先你要能存的下大数据。
传统的文件系统是单机的，不能横跨不同的机器。HDFS（Hadoop Distributed FileSystem）的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取/hdfs/tmp/file1的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你管理这些数据。
存的下数据之后，你就开始考虑怎么处理数据。虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。一台机器读取成T上P的数据（很大的数据哦，比如整个东京热有史以来所有高清电影的大小甚至更大），一台机器慢慢跑也许需要好几天甚至好几周。对于很多公司来说，单机处理是不可忍受的，比如微博要更新24小时热博，它必须在24小时之内跑完这些处理。那么我如果要用很多台机器处理，我就面临了如何分配工作，如果一台机器挂了如何重新启动相应的任务，机器之间如何互相通信交换数据以完成复杂的计算等等。这就是MapReduce / Tez / Spark的功能。MapReduce是第一代计算引擎，Tez和Spark是第二代。MapReduce的设计，采用了很简化的计算模型，只有Map和Reduce两个计算过程（中间用Shuffle串联），用这个模型，已经可以处理大数据领域很大一部分问题了。
那什么是Map什么是Reduce？
考虑如果你要统计一个巨大的文本文件存储在类似HDFS上，你想要知道这个文本里各个词的出现频率。你启动了一个MapReduce程序。Map阶段，几百台机器同时读取这个文件的各个部分，分别把各自读到的部分分别统计出词频，产生类似
（hello, 12100次），（world，15214次）等等这样的Pair（我这里把Map和Combine放在一起说以便简化）；这几百台机器各自都产生了如上的集合，然后又有几百台机器启动Reduce处理。Reducer机器A将从Mapper机器收到所有以A开头的统计结果，机器B将收到B开头的词汇统计结果（当然实际上不会真的以字母开头做依据，而是用函数产生Hash值以避免数据串化。因为类似X开头的词肯定比其他要少得多，而你不希望数据处理各个机器的工作量相差悬殊）。然后这些Reducer将再次汇总，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每个Reducer都如上处理，你就得到了整个文件的词频结果。
这看似是个很简单的模型，但很多算法都可以用这个模型描述了。
Map＋Reduce的简单模型很黄很暴力，虽然好用，但是很笨重。第二代的Tez和Spark除了内存Cache之类的新feature，本质上来说，是让Map/Reduce模型更通用，让Map和Reduce之间的界限更模糊，数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量。
有了MapReduce，Tez和Spark之后，程序员发现，MapReduce的程序写起来真麻烦。他们希望简化这个过程。这就好比你有了汇编语言，虽然你几乎什么都能干了，但是你还是觉得繁琐。你希望有个更高层更抽象的语言层来描述算法和数据处理流程。于是就有了Pig和Hive。Pig是接近脚本方式去描述MapReduce，Hive则用的是SQL。它们把脚本和SQL语言翻译成MapReduce程序，丢给计算引擎去计算，而你就从繁琐的MapReduce程序中解脱出来，用更简单更直观的语言去写程序了。
有了Hive之后，人们发现SQL对比Java有巨大的优势。一个是它太容易写了。刚才词频的东西，用SQL描述就只有一两行，MapReduce写起来大约要几十上百行。而更重要的是，非计算机背景的用户终于感受到了爱：我也会写SQL！于是数据分析人员终于从乞求工程师帮忙的窘境解脱出来，工程师也从写奇怪的一次性的处理程序中解脱出来。大家都开心了。Hive逐渐成长成了大数据仓库的核心组件。甚至很多公司的流水线作业集完全是用SQL描述，因为易写易改，一看就懂，容易维护。
自从数据分析人员开始用Hive分析数据之后，它们发现，Hive在MapReduce上跑，真鸡巴慢！流水线作业集也许没啥关系，比如24小时更新的推荐，反正24小时内跑完就算了。但是数据分析，人们总是希望能跑更快一些。比如我希望看过去一个小时内多少人在充气娃娃页面驻足，分别停留了多久，对于一个巨型网站海量数据下，这个处理过程也许要花几十分钟甚至很多小时。而这个分析也许只是你万里长征的第一步，你还要看多少人浏览了跳蛋多少人看了拉赫曼尼诺夫的CD，以便跟老板汇报，我们的用户是猥琐男闷骚女更多还是文艺青年／少女更多。你无法忍受等待的折磨，只能跟帅帅的工程师蝈蝈说，快，快，再快一点！
于是Impala，Presto，Drill诞生了（当然还有无数非著名的交互SQL引擎，就不一一列举了）。三个系统的核心理念是，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（流）计算。Storm是最流行的流计算平台。流计算的思路是，如果要达到更实时的更新，我何不在数据流进来的时候就处理了？比如还是词频统计的例子，我的数据流是一个一个的词，我就让他们一边流过我就一边开始统计了。流计算很牛逼，基本无延迟，但是它的短处是，不灵活，你想要统计的东西必须预先知道，毕竟数据流过就没了，你没算的东西就无法补算了。因此它是个很好的东西，但是无法替代上面数据仓库和批处理系统。
还有一个有些独立的模块是KV Store，比如Cassandra，HBase，MongoDB以及很多很多很多很多其他的（多到无法想象）。所以KV Store就是说，我有一堆键值，我能很快速滴获取与这个Key绑定的数据。比如我用身份证号，能取到你的身份数据。这个动作用MapReduce也能完成，但是很可能要扫描整个数据集。而KV Store专用来处理这个操作，所有存和取都专门为此优化了。从几个P的数据中查找一个身份证号，也许只要零点几秒。这让大数据公司的一些专门操作被大大优化了。比如我网页上有个根据订单号查找订单内容的页面，而整个网站的订单数量无法单机数据库存储，我就会考虑用KV Store来存。KV Store的理念是，基本无法处理复杂的计算，大多没法JOIN，也许没法聚合，没有强一致性保证（不同数据分布在不同机器上，你每次读取也许会读到不同的结果，也无法处理类似银行转账那样的强一致性要求的操作）。但是丫就是快。极快。
每个不同的KV Store设计都有不同取舍，有些更快，有些容量更高，有些可以支持更复杂的操作。必有一款适合你。
除此之外，还有一些更特制的系统／组件，比如Mahout是分布式机器学习库，Protobuf是数据交换的编码和库，ZooKeeper是高一致性的分布存取协同系统，等等。
有了这么多乱七八糟的工具，都在同一个集群上运转，大家需要互相尊重有序工作。所以另外一个重要组件是，调度系统。现在最流行的是Yarn。你可以把他看作中央管理，好比你妈在厨房监工，哎，你妹妹切菜切完了，你可以把刀拿去杀鸡了。只要大家都服从你妈分配，那大家都能愉快滴烧菜。
你可以认为，大数据生态圈就是一个厨房工具生态圈。为了做不同的菜，中国菜，日本菜，法国菜，你需要各种不同的工具。而且客人的需求正在复杂化，你的厨具不断被发明，也没有一个万用的厨具可以处理所有情况，因此它会变的越来越复杂。
<a data-draft-node="block" data-draft-type="mcn-link-card" data-mcn-id="1567115648773337088">