如何用形象的比喻描述大数据的技术生态（HadoopHiveS

　　看了很多人写的，认为都不够通俗，对于很多新人来说，可能连名词都不是很清楚，一些不明觉厉的高深的业内技术恐怕要把他们给劝退吧。
　　本帖力争让小白看了之后彻底搞懂大数据技术生态来龙去脉，让一些经验丰富的技术人也能在不同的视角有获得感。
　　PS：本文尽量以一个新手小白的角度带大家把这些名词讲清楚，全文会列举很多具象的小例子，尽可能做到通俗易懂。
　　在这里也给想入门大数据行业的新人或者想进一步在这个领域深耕的小伙伴奉上一套优质的学习资源。涵盖了大数据基础、大数据架构、数据仓库、数据治理、bat真实案例，科研绘图与工具、大厂面试真题附含答案以及简历模板等众多干货。文末自由获取。
　　在写完这篇文章后，我突然有了一个感触，就是技术人在学习一项新技术的时候，会常常习惯于在一个给定的问题场景下，把相关技术越挖越深，优化的也越来越好，希望去更好的解决它。
　　但是大家常常忽略这个问题当初是怎么产生的？以及我们为什么要去解决这个问题？
　　其实有的时候，一个好的问题定义，要比一个解决方案更重要。希望大家耐心看完！全文很干，大家在读的时候，手边可以准备一杯水！发车！Hadoop、Hive、Spark之间的关系
　　首先，大家都知道Hadoop、Hive、Spark都是大数据相关的系统和技术，大数据也属于数据管理系统的范畴。
　　因而我们可以从数据管理的解决的问题出发展开来讲解一下这个问题。
　　任何公司的数据管理系统无非涉及到两个问题：
　　1、数据怎么存？
　　2、数据怎么算？
　　为了让大家从根源上理解大数据技术的演进过程，我们从单机时代开始说起。
　　在单机数据管理系统时代，数据量是很少的，一台服务器基本就可以存下所有的数据，计算也不会碰到什么瓶颈，并且这种场景下，数据处理的任务都是IO密集型的，也就更谈不上什么分布式系统了。
　　以现在一个典型的服务器为例：
　　一个普通服务器一般可以配6块硬盘（每块硬盘选4T的），这样可以有24T的原始容量，再加上一些数据包口径的冗余和一些格式化的损失。所以保守估计，一台服务器至少也能存10T以上的数据。
　　再配上128g的内存、2个CPU，再装个数据库管理系统，微调一下，单表处理10亿条的数据就没有什么问题。
　　以上就是一个简单可行的单机数据处理方案。
　　实际上，这种单机方案目前也并未淘汰，如今也有很多公司都在继续沿用这种单机方案。
　　但是问题是，我们早已经进入了信息爆炸的时代，在另外一些场景下，数据量变得越来越大，大到一台机器已经存不下了。
　　一台机器存不下怎么办？其实很简单，一台机器存不下，那就用10台，10台存不下那就用100台。
　　所以问题就来了。
　　如果有100台机器去统一存储数据，那怎么去管理这100台机器呢？
　　毕竟人的精力是有限的，一个人怎么可能每天处理100台机器的数据存储任务呢？
　　这就好比，一个老板是不可能去直接对100个员工发号施令的，他要设立中层岗位，去帮助他管理这100个同事，好让大家融合成一个团队。
　　在Hadoop生态里面，HDFS就扮演这样一个中层管理的角色。
　　HDFS统一管理这100台机器上的存储空间，并提供一个接口，让这100台机器的存储空间看起来就像是在一台机器上，用户端会感觉这是一个无限大的存储空间，从而可以更方便地在上面写应用程序。
　　说完了数据存储，再聊聊数据计算。
　　毕竟数据存下来是为了算的，不可能单纯只是为了占硬盘内存。
　　那首先，上文说的那100台机器，每一台机器也都有自己的CPU内存，一个理想的愿景是，让这些计算资源得到最充分的利用，从而让数据计算可以更快的完成。
　　但问题来了。
　　如果你是一个程序员，你怎么去写程序，去操作这100台机器，然后通过协作完成一个完整的计算任务呢？
　　比如说，这些任务该怎么去分配到这些机器上？任务与任务之间怎么去做同步？如果这个过程中有一台机器掉链子了，怎么办？
　　为了解决这个问题，HDFS里面引入了一个模块，这就是大名鼎鼎的MapReduce，MapReduce模块本质上就是提供了一个任务并行计算的框架。
　　它可以把并行程序分成两个阶段，一个就是Map阶段，是一个是Reduce阶段。
　　这两个阶段，简单来讲：
　　如果你有一项任务，工作量很大，你找100个帮手把它平均分成100份，每人做一份，这就是Map阶段。
　　这100个小伙伴把任务完成，然后再把结果汇总到你这，然后从你这再出一个最终的结果，这就是Reduce阶段。
　　好了，至此我们可以看到，Hadoop里面有HDFS来处理存储，MapReduce来处理计算，一切貌似都齐备了，一切仿佛都很美好。
　　但是，技术发展的目标之一，就是要不断降低技术本身的使用门槛。
　　大家想象一下，在过去的单机数据库的时代，用户大部分都是可以用SQL语言去做数据处理的。
　　PS：SQL真的是一项很伟大的一个发明，它把数据处理的门槛下降了很多。
　　但是到了大数据的时代，大家发现不能写SQL了，如果要做数据处理，得去写一个MapReduce程序，这个MapReduce程序还得是一个非常专业的分布式处理的程序。
　　这其实是相当复杂的，需要大家具备很强的计算机背景和门槛的。
　　要是能在Hadoop上，也能通过写SQL就能完成数据处理的任务，那该多好啊！
　　于是，Hive就应运而生了。
　　Hive实际上是一个在Hadoop上进行结构化数据处理的解决方案，为了让用户能够写SQL来处理数据，数据就必须要进行结构化处理。SQL里面的S其实就是结构化处理的意思，如果不做结构化处理，我们就没法通过SQL查询数据了。
　　Hive里面的一个核心模块是metastore，它用来存储这些结构化的信息。简单来说就是一些表信息，比如说你有多少列？每个列是什么样的数据结构？然后Hive里面的执行引擎就会去把一条SQL语句进行语法分析，最后生成语法树。
　　这两个步骤实际上和普通的数据库没有什么区别，区别主要是在执行阶段Hive的执行引擎会把这个SQL语句翻译成一个MapReduce的任务去执行，然后再把执行结果进行加工返给用户。
　　这样一来，Hive就让一部分大数据开发工程师的工作就又变回了SQL了。
　　事实上，从工程的角度来看，效率和灵活性本身就是一对矛盾体。从Hive的这个例子里我们看出，SQL的出现使得大数据处理任务的开发效率提高了，但是在数据处理的表达力和灵活性上肯定是不如直接采用MapReduce。
　　因此，这两个技术也不是互相替代的关系，而是需要根据实际的场景去选择。
　　最后，再来说一下Spark。
　　Spark经常被用来和Hadoop进行对比，其实准确的说，应该是和Hadoop里面的MapReduce对比。
　　Spark本身也是一个计算框架，它和MapReduce不同就是，Spark基于内存计算，而MapReduce则是基于磁盘的计算。
　　因此Spark的优势就是快！
　　毕竟内存读取的速度要比磁盘读取的速度要快得多。
　　有多快呢？举一个比较极端的例子，如果你的数据集不大，机器的内存是可以装得下的，在这种极端的情况下，Spark甚至会比MapReduce能够快100倍。
　　即便放到一般场景下，Spark也会比MapReduce快23倍左右。
　　类似MapReduce有Hive可以让用户能够写SQL，Spark的生态里面也有SparkSQL的这个模块，去让用户在Spark上写SQL。
　　最后，Spark作为一个纯的计算引擎，还提供了其他的上层的抽象帮助用户去写其他类型的数据处理程序。比如说Spark提供了streaming的模块，可以让用户去写流处理的程序，提供了mllib内部的模块，让用户去写机器学习的程序以及图处理的模块GraphX。
　　当然这三个模块只是大数据生态里面的非常小的一部分，还有更多的更新的技术等大家自己去发掘。
　　最后附上一张结构图，以便于大家对以上内容做理解。
　　开头提到的大数据资源，涵盖了大数据基础、大数据架构、数据仓库、数据治理、bat真实案例，科研绘图与工具、大厂面试真题附含答案以及简历模板等众多干货。
　　需要领取的小伙伴，转发关注后私信大数据，联系小编获取资料。