⼤数据组件原理总结-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同步。hbase工作原理
Zookeeper可以实现分布式锁机制。通过watcher监控，对每个Znode的锁都有⼀个独⼀的编号，按照序号的⼤⼩⽐较，来分配锁。当⼀个暂时Znode完结后删除本节点，通知leader完结，之后下⼀个Znode获取锁进⾏操作。
Kafka原理
Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项⽬的⼀部分。Kafka是⼀种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交⽇志服务。它被设计为⼀个分布式系统，易于向外扩展；它同时为发布和订阅提供⾼吞吐量；它⽀持多订阅者，当失败时能⾃动平衡消费者；它将消息持久化到磁盘，因此可⽤于批量消费，例如ETL，以及实时应⽤程序。broker和⽣产者、消费者各⾃都是集，集中的各个实例他们之间是对等的，集扩充节点很⽅便。
Kafka的基本概念包括话题、⽣产者、消费者、代理或者kafka集。话题是特定类型的消息流。消息是字节的有效负载，话题是消息的分类名或种⼦名。⽣产者是能够发布消息到话题的任何对象。已发布的消息保存在⼀组服务器中，它们被称为代理或Kafka集。消费者可以订阅⼀个或多个话题，并从Broke
r拉数据，从⽽消费这些已发布的消息。
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的核⼼，完全弹性的，如果数据丢失⼀部分还可以重建。有⾃动容错、位置感知调度和可伸缩性，通过数据检查点和记录数据更新⾦象容错性检查。通过File()加载⽂件变成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。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。