大数据组件原理总结-Hadoop、Hbase、Kafka、Zookeeper、Spark

Hadoop原理

分为HDFS与Yarn两个部分。HDFS有Namenode和Datanode两个部分。每一个节点占用一个电脑。Datanode定时向Namenode发送心跳包，心跳包中包含Datanode的校验等信息，用来监控Datanode。HDFS将数据分为块，默认为64M每一个块信息按照配置的参数分别备份在不一样的Datanode，而数据块在哪一个节点上，这些信息都存储到Namenode上面。Yarn是MapReduce2，能够集成更多的组件，如spark、mpi等。MapReduce包括Jobtraker与Tasktraker两个部分。其中JobTraker是在主节点上，负责总体的调度。Tasktraker在slave节点上，当提交任务后，将其交给Jobtraker进行调度，调度到该任务以后就会将jar包发送到响应的Tasktraker，以实现分布式中移动计算资源而非移动数据。由于这些任务都是并发执行的，因此每一个任务须要调用哪一个节点的数据必须很是的明确，一般这一部分是经过Jobtraker进行指挥。

在MapReduce的开始，每一个block做为一个Map输入，Map输入后就进入shuffle阶段。Shuffle阶段主要分为Map和Reduce两个阶段。在Map Shuffle阶段，Map输入按用户的程序进行处理，生成的结果按key排序，而后进入内存，溢出后造成一个spill写入磁盘，这样多个spill在这个节点中进行多路归并排序（胜者树）造成一个排序文件写入磁盘，这期间那些Map文件交给那些节点处理由Jobtraker进行调度，最后生成一个大排序的文件，而且删除spill。以后，再将多个节点上已经排序的文件进行行多路归并排序（一个大文件N分到n个节点，每一个节点分为k个spill，一个spill长度s，时间复杂度是N(logn（n个节点多路归并排序） + logk（每一个节点内k个spill排序） + logs（每一个spill内部进行排序）)，N=nks,因此最后的复杂度仍是NlogN）。

完成Map Shuffle阶段后通知Jobtraker进入Reduce Shuffle阶段。在这个阶段，由于已经排序，很容易将用户的程序直接做用到相同key的数据上，这些数据做为Reduce的输入进行处理，最终将输出的结果数据写入到HDFS上，并删除磁盘数据。Map通常多，Reduce少，因此经过Hash的方法将Map文件映射到Reduce上，进行处理，这个阶段叫作Patition。为了不譬如全部数据相加这种操做使得数据负载移动的数量少的Reduce阶段，形成效率低下的结果，咱们能够在在Map Shuffle阶段加一个Combine阶段，这个Combine是在每一台节点上将已经排序好的文件进行一次Reduce并将结果做为Reduce Shuffle阶段的输入，这样能够大大减小数据的输入量。一般Reduce的个数经过用户来指定，一般和CPU个数相适应才能使其效率达到最大。

HBase原理

Hbase是列存储数据库。其存储的组织结构就是将相同的列族存储在一块儿，所以得名的。Hbase存储有行键，做为惟一标识，列表示为 <列族> : <列> 存储信息，如address：city，address：provice，而后是时间戳。

Hbase物理模型中，有一个总结点HMaster，经过其自带的zookeeper与客户端相链接。Hbse做为分布式每个节点做为一个RegionServer，维护Region的状态和管理。Region是数据管理的基本单位。最初只有一个，经过扩充后达到阈值而后分裂，经过Server控制其规模。在RegionServer中，每个store做为一个列族。当数据插入进来，新数据成为Memstore，写入内存，当Memstore达到阈值后，经过Flashcache进程将数据写入storeFile，也就是当内存数据增多后溢出成一个StoreFile写入磁盘，这里和Hadoop的spill相似，这个过程是在HDFS上进行的操做。因此数据的插入并非追加的过程，而是积累成大块数据后一并写入。当StoreFile数量过多时，进行合并，将造成一个大的StoreFile而且删除掉原来的StoreFile。再当StoreFile大小超过必定阈值后，分裂成Region。

HBase有一个ROOT表和META表。META表记录用户Region的信息，可是随着数据增多，META也会增大，进而分裂成多个Region ，那咱们用ROOT表记录下META的信息，是一个二级表，而zookeeper中记录ROOT表的location。当咱们需找找到一条信息时，先去zookeeper查找ROOT，从ROOT中查找META找到META位置，在进入META表中寻找该数据所在Region，再读取该Region的信息。HBase适合大量插入又同时读的状况，其瓶颈是硬盘的传输速度而再也不是像Oracle同样瓶颈在硬盘的寻道速度。

Zookeeper原理

Zookeeper是一个资源管理库，对节点进行协调、通讯、失败处理、节点损坏的处理等，是一个无中心设计，主节点经过选举产生。Zookeeper的节点是Znode。每个节点能够存放1M的数据，client访问服务器时建立一个Znode，能够是短暂的Znode，其上能够放上观察Watcher对node进行监控。Zookeeper有高可用性，每一个机器复制一份数据，只要有通常以上的机器能够正常的运行，整个集群就能够工做。好比6台的集群容忍2台断开，超过两台达到通常的数量就不能够，所以集群一般都是奇数来节约资源。

Zookeeper使用zab协议，是一个无中心协议，经过选举的方式产生leader，经过每台机器的信息扩散选举最闲的资源利用较少的节点做为主控。同时当配置数据有更改更新时，在每一个节点上有配置watcher并触发读取更改，。所以可以保证一致性。每一个节点经过leader广播的方式，使全部follower同步。

Zookeeper能够实现分布式锁机制。经过watcher监控，对每一个Znode的锁都有一个独一的编号，按照序号的大小比较，来分配锁。当一个暂时Znode完结后删除本节点，通知leader完结，以后下一个Znode获取锁进行操做。

Kafka原理
Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，以后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。它被设计为一个分布式系统，易于向外扩展；它同时为发布和订阅提供高吞吐量；它支持多订阅者，当失败时能自动平衡消费者；它将消息持久化到磁盘，所以可用于批量消费，例如ETL，以及实时应用程序。broker和生产者、消费者各自都是集群，集群中的各个实例他们之间是对等的，集群扩充节点很方便。

Kafka的基本概念包括话题、生产者、消费者、代理或者kafka集群。话题是特定类型的消息流。消息是字节的有效负载，话题是消息的分类名或种子名。生产者是可以发布消息到话题的任何对象。已发布的消息保存在一组服务器中，它们被称为代理或Kafka集群。消费者能够订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。

Kafka的存储布局很是简单。话题的每一个分区对应一个逻辑日志。物理上，一个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区，代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者通过必定的时间后，段文件真正写入磁盘中。写入完成后，消息公开给消费者。段文件机制和Hadoop中spill相似。消费者始终从特定分区顺序地获取消息，若是消费者知道特定消息的偏移量，也就说明消费者已经消费了以前的全部消息。消费者向代理发出异步拉请求，准备字节缓冲区用于消费。每一个异步拉请求都包含要消费的消息偏移量与其它消息系统不一样，Kafka代理是无状态的。这意味着消费者必须维护已消费的状态信息。这些信息由消费者本身维护，代理彻底无论。消费者能够故意倒回到老的偏移量再次消费数据。这违反了队列的常见约定，但被证实是许多消费者的基本特征。

kafka的broker在配置文件中能够配置最多保存多少小时的数据和分区最大的空间占用，过时的和超量的数据会被broker自动清除掉。

Kafka会记录offset到zk，同时又在内存中维护offset，容许快速的checkpoint，若是consumer比partition可能是浪费，由于kafka不容许partition上并行consumer读取。同时，consumer比partition少，一个consumer会对应多个partition，有可能致使partition中数据的读取不均匀，也不能保证数据间的顺序性，kafka只有在一个partition读取的时候才能保证时间上是有顺序的。增长partition或者consumer或者broker会致使rebalance，因此rebalance后consumer对应的partition会发生变化。

Spark原理

spark 能够很容易和yarn结合，直接调用HDFS、Hbase上面的数据，和hadoop结合。配置很容易。spark发展迅猛，框架比hadoop更加灵活实用。减小了延时处理，提升性能效率实用灵活性。也能够与hadoop切实相互结合。

spark核心部分分为RDD。Spark SQL、Spark Streaming、MLlib、GraphX、Spark R等核心组件解决了不少的大数据问题，其完美的框架日受欢迎。其相应的生态环境包括zepplin等可视化方面，正日益壮大。大型公司争相实用spark来代替原有hadoop上相应的功能模块。Spark读写过程不像hadoop溢出写入磁盘，都是基于内存，所以速度很快。另外DAG做业调度系统的宽窄依赖让Spark速度提升。

RDD是弹性分布式数据也是spark的核心，彻底弹性的，若是数据丢失一部分还能够重建。有自动容错、位置感知调度和可伸缩性，经过数据检查点和记录数据更新金象容错性检查。经过SparkContext.textFile()加载文件变成RDD，而后经过transformation构建新的RDD，经过action将RDD存储到外部系统。

RDD使用延迟加载，也就是懒加载，只有当用到的时候才加载数据。若是加载存储全部的中间过程会浪费空间。所以要延迟加载。一旦spark看到整个变换链，他能够计算仅需的结果数据，若是下面的函数不须要数据那么数据也不会再加载。转换RDD是惰性的，只有在动做中才可使用它们。

Spark分为driver和executor，driver提交做业，executor是application早worknode上的进程，运行task，driver对应为sparkcontext。Spark的RDD操做有transformation、action。Transformation对RDD进行依赖包装，RDD所对应的依赖都进行DAG的构建并保存，在worknode挂掉以后除了经过备份恢复还能够经过元数据对其保存的依赖再计算一次获得。看成业提交也就是调用runJob时，spark会根据RDD构建DAG图，提交给DAGScheduler，这个DAGScheduler是在SparkContext建立时一同初始化的，他会对做业进行调度处理。当依赖图构建好之后，从action开始进行解析，每个操做做为一个task，每遇到shuffle就切割成为一个taskSet，并把数据输出到磁盘，若是不是shuffle数据还在内存中存储。就这样再往前推动，直到没有算子，而后运行从前面开始，若是没有action的算子在这里不会执行，直到遇到action为止才开始运行，这就造成了spark的懒加载，taskset提交给TaskSheduler生成TaskSetManager而且提交给Executor运行，运行结束后反馈给DAGScheduler完成一个taskSet，以后再提交下一个，当TaskSet运行失败时就返回DAGScheduler并从新再次建立。一个job里面可能有多个TaskSet，一个application可能包含多个job。

引用自：http://www.javashuo.com/article/p-hzgwbcll-dz.html 若有侵权，请联系我删除