1.Hadoop、spark、storm下产品以及应用场景
hadoop起源于Nutch,目标是为了构建一个大型的全网搜索工具或者说是引擎吧,包括网页的抓取、建立索引以及查询等功能。但是,当抓取的内容量越来越大时,单机存储量严重受限。
谷歌的GFS和MapReduce两篇文章给出了可行的方案,其中GFS目的是处理海量数据的存储,而MapReduce目的是处理海量网页的索引计算问题。
进而,开发Nutch的同时,从Nutch剥离处理独立的这个项目,称为hadoop。
hadoop的应用场景,也就是对海量的数据进行分布式存储,根据用户自定义的业务逻辑,对海量数据的分布式计算。
---------------------------------------------------------------
Spark是加州伯克利分校的一个数据分析栈,号称可以一栈式解决大数据的问题,包括但不限于图计算、流计算、机器学习等。那么,既然存在hadoop生态圈的各个工具了,比如hive就可以快速的呗翻译成MapReduce程序,HBASE可以列式存储海量数据;此外,hadoop也有mahout机器学习API,那么为什么spark会发展速度这么快呢?
分析,对于hadoop的MapReduce程序,由输入的一个个split,进入map task 和reduce task 一步步的计算,细小话计算的粒度,这样是好的,方便任务的切分。但是,MapReduce的shuffle过程包含了partition、sort、combine,之后这个结果是要落地的,也就是如果数据量大,比如内存缓冲区的大小默认是100M,当着一部分内存快要被使用完毕的时候,就会发生spill过程,数据从HDFS读取之后再次落地,这样的是很消耗时间的。此外,溢写到本地之后,reduce task 要主动来读取数据的时候,在reduce end 一样是加载内存,合并然后存储在本地,这样的过程更是好费时间。
那么,spark怎么做的呢?
spark的重要工具,一个RDD(弹性分布式数据集 Resilience Distributed set),另一个就是DAG(任务的切分依据),最后不是工具,是基于内存计算,而不是基于内存存储计算。
关于RDD的五个特性:
一个分区列表 a list of partitions
每个分区对应的一个计算算子
与上级RDD的依赖关系集
对于键值对RDD,默认存在一个hash 分区器 hash partitioner
对于每个分区都存在一个最优的位置计算。
个人理解说明:
RDD是分布式、加载不可变的数据集,对应每个分区,我直接给出一个compute的task ,那么对应的这个计算就可以分发到数据存储的机器上。关于弹性:由于RDD有容错机制(persist or cache or checkpoint),当任务计算失败,可以重新进行计算,这个特性我理解为弹性的。
关于依赖关系集的理解:RDD是抽象出来的模型,RDD的两个操作分类一个是Transformation ,另一个是Action,只有Action操作之后,才会进行真正的计算;那么其他大量的Transformation 操作是干嘛的呢?难道是看戏的?对,个人理解,那些Transformation 操作就是记录一系列的依赖关系,map--->flatmap----groupBykey---count等等,这些都是一系列的瞬时计算状态,记录上级RDD操作的暂态,只有遇到Action操作才真正的进行就是。
关于分区器,spark一共提供的两种分区器,一个是hash 分区器,另一个是page 分区器;默认使用hash 分区器,那么为什么需要hash分区器呢?spark的这些RDD在计算的过程也是存在数据混洗的,也就是shuffle,不然groupBYKey,聚不到一起还叫group吗?那么多台机器之间数据混洗是需要大量的时间和性能的消耗的。spark优化,就考虑了hash分区器,对于二元操作,预先数据分区会导致至少一个RDD不发生数据混洗,如果第二个RDD使用相同的分区方式,并且他们还缓存在同样的机器上,那么就不会发生数据的混洗了。
总结:
hadoop的MapReduce构建可以被spark快速的计算所替换,但是hadoop的HDFS却不会,海量数据始终是需要存储的嘛!
------------------------------------------
Storm
作为实时计算的大佬,spark-streaming虽然可以提高流计算,但是时间上却打不到秒级甚至是微妙集的,而storm就可以轻松get。关于storm本人水平有限,没有了解太多,-_-;
2.Hadoop的shuffle是如何排序的?
排序关键字有两个:partition和key
归并排序和快排