Hadoop生态学习总结

Hadoop生态

hdfs

架构

hdfs是一个分布式文件系统。底层的存储采用廉价的磁盘阵列RAID，因为能够并发读写因此效率很高。

基本架构是一个namenode和多个dataNode。node的意思是节点，通常指主机，也能够是虚拟机。

每一个文件都会有两个副本存放在datanode中。

读写

客户端写入文件时，先把请求发送到namenode，namenode会返回datanode的服务地址，接着客户端去访问datanode，进行文件写入，而后通知namenode，namenode接收到写入完成的消息之后，会另外选两个datanode存放冗余副本。

读取文件时，从namenode获取一个datanode的地址，而后本身去读取便可。

当一个文件的副本不足两份时，namenode自动会完成副本复制。而且，因为datanode通常会放在各个机架。namenode通常会把副本一个放在同一机架，一个放在其余机架，防止某个机架出问题致使整个文件读写不可用。

高可用

namenode节点是单点，因此宕机了就没救了，因此咱们可使用zookeeper来保证namenode的高可用。可使用zookeeper选主来实现故障切换，namenode先注册一个节点在zk上，表示本身是主，宕机时zk会通知备份节点进行切换。

Hadoop2.0中加入了hdfs namenode高可用的方案，也叫HDFS HA。namenode和一个备份节点绑定在一块儿，而且经过一个共享数据区域进行数据同步。同时支持故障切换。

MapReduce

架构和流程

MapReduce是基于Hadoop集群的分布式计算方案。通常先编写map函数进行数据分片，而后经过shuffle进行相同分片的整合，最后经过reduce把全部的数据结果进行整理。

具体来讲，用户提交一个MapReduce程序给namenode节点，namenode节点启动一个jobtracker进行子任务的调度和监控，而后派发每一个子任务tasktracker到datanode进行任务执行，因为数据分布在各个节点，每一个tasktracker只须要执行本身的那一部分便可。最后再将结果汇总给tasktracker。

wordcount

首先是一个文本文件:hi hello good hello hi hi。 三个节点，则进行三次map。hi hello，good hello，hi hi分别由三个节点处理。结果分别是hi 1 hello 1,good 1 hello 1,hi 1,hi 1。 shuffle时进行combine操做，获得hi 1,hello 1,good 1 hello 1,hi 2。最终reduce的结果是hi 3 hello 2 good 1.

hive

hive是一个基于hdfs文件系统的数据仓库。能够经过hive sql语句执行对hdfs上文件的数据查询。原理是hive把hdfs上的数据文件当作一张张数据表，把表结构信息存在关系数据库如mysql中。而后执行sql时经过对表结构的解析再去hdfs上查询真正的数据，最后也会以结构化的形式返回。

hbase

简介

hbase是基于列的数据库。

他与传统关系数据库有很大不一样。

首先在表结构上，hbase使用rowkey行键做为惟一主键，经过行键惟一肯定一行数据。

同时，hbase使用列族的概念，每一个表都有固定的列族，每一行的数据的列族都同样，可是每一行所在列族的实际列均可以不同。 好比列族是info，列能够是name age，也能够是sex address等。也就是说具体列能够在插入数据时再进行确认。

而且，hbase的每一行数据还能够有多个版本，经过时间戳来表示不一样的数据版本。

存储

通常状况下hbase使用hdfs做为底层存储，因此hdfs提供了数据的可靠性以及并发读写的高效率。

hbase一个表的 每n行数据会存在一个region中，而且，对于列来讲，每个列族都会用一个region来存储，假设有m个列族，那么就会有n * m个region须要存储在hdfs上。

同时hbase使用regionserver来管理这些region，他们可能存在不一样的datanode里，因此经过regionserver能够找出每个region的位置。

hbase使用zookeeper来保证regionserver的高可用，会自动进行故障切换。

zk

zk在Hadoop的做用有几个，经过选主等机制保证主节点高可用。

使用zk进行配置资源的统一管理，保证服务器节点无状态，全部服务信息直接从zk获取便可。

使用zookeeper进行节点间的通讯等，也可使用zk的目录顺序节点实现分布式锁，以及服务器选主。不只在Hadoop中，zk在分布式系统中总能有用武之地。

zookeeper自己的部署方式就是一个集群,一个master和多个slave。

使用zab协议保证一致性和高可用。

zab协议实现原理：

1 使用两段式提交的方式确保一个协议须要半数以上节点赞成之后再进行广播执行。

2 使用基于机器编号加时间戳的id来表示每一个事务，经过这个方式当初始选举或者主节点宕机时进行一轮选主，每一个节点优先选择本身当主节点，在选举过程当中节点优先采纳比较新的事务，将本身的选票更新，而后反馈个其余机器，最后当一个机器得到超过半数选票时当选为master。

3选主结束之后，主节点与slave进行主从同步，保证数据一致性，而后对外提供服务，而且写入只能经过master而读取能够经过任意一台机器。

sqoop

将hive表中的内容导入到MySQL数据库，也能够将MySQL中的数据导入hive中。

yarn

没有yarn以前，hdfs使用jobtracker和tasktracker来执行和跟踪任务，jobtracker的任务过重，又要执行又要监控还要获取结果。 而且不一样机器的资源状况没有被考虑在内。

yarn是一个资源调度系统。提供applicationmaster对一个调度任务进行封装，而后有一个resourcemanager专门负责各节点资源的管理和监控。同时nodemanager则运行每一个节点中用于监控节点状态和向rm汇报。还有一个container则是对节点资源的一个抽象，applicationmaster任务将由节点上的一个container进行执行。rm会将他调度到最合适的机器上。

kafka

架构

kafka是一个分布式的消息队列。

它组成通常包括kafka broker，每一个broker中有多个的partition做为存储消息的队列。

而且向上提供服务时抽象为一个topic，咱们访问topic时实际上执行的是对partition的写入和读取操做。

读写和高可用

partition支持顺序写入，效率比较高，而且支持零拷贝机制，经过内存映射磁盘mmap的方式，写入partition的数据顺序写入到映射的磁盘中，比传统的IO要快。

因为partition可能会宕机，因此通常也要支持partition的备份，1个broker ，master一般会有多个 broker slave，是主从关系，经过zookeeper进行选主和故障切换。

当数据写入队列时，通常也会经过日志文件的方式进行数据备份，会把broker中的partition被分在各个slave中以便于均匀分布和恢复。

生产者和消费者

生产者消费者须要访问kafka的队列时，若是是写入，直接向zk发送请求，通常是向一个topic写入消息，broker会自动分配partition进行写入。而后zk会告诉生产者写入的partition所在的broker地址，而后进行写入。

若是是读取的话，也是经过zk获取partition所在位置，而后经过给定的offset进行读取，读取完后更新offset。

因为kafka的partition支持顺序读写。因此保证一个partition中的读取和写入时是顺序的，可是若是是多个partition则不保证顺序。

正常状况下kafka使用topic来实现消息点对点发送，而且每一个consumer都要在一个consumer group中，并且comsumer group中每次只能有一个消费者能接受对应topic的消息。由于为了实现订阅也就是一对多发送，咱们让每一个consumer在一个单独的group，因而每一个consumer均可以接受到该消息。

flume

flume用于数据的收集和分发，flume能够监听端口的数据流入，监视文件的变更以及各类数据形式的数据流入，而后再把数据从新转发到其余须要数据的节点或存储中。

一、Flume的概念

flume是分布式的日志收集系统，它将各个服务器中的数据收集起来并送到指定的地方去，好比说送到图中的HDFS，简单来讲flume就是收集日志的。

二、Event的概念 在这里有必要先介绍一下flume中event的相关概念：flume的核心是把数据从数据源(source)收集过来，在将收集到的数据送到指定的目的地(sink)。为了保证输送的过程必定成功，在送到目的地(sink)以前，会先缓存数据(channel),待数据真正到达目的地(sink)后，flume在删除本身缓存的数据。

在整个数据的传输的过程当中，流动的是event，即事务保证是在event级别进行的。那么什么是event呢？—–event将传输的数据进行封装，是flume传输数据的基本单位，若是是文本文件，一般是一行记录，event也是事务的基本单位。event从source，流向channel，再到sink，自己为一个字节数组，并可携带headers(头信息)信息。event表明着一个数据的最小完整单元，从外部数据源来，向外部的目的地去。

flume使用

ambari

ambari就是一个Hadoop的Web应用。

spark

spark和MapReduce不一样的地方就是，把计算过程放在内存中运行。

spark提出了抽象的RDD分布式内存模型，把每一步的计算操做转换成一个RDD结构，而后造成一个RDD链接而成的有向图。

好比data.map().filter().reduce(); 程序提交到master之后，会解析成多个RDD，而且造成一个有向图，而后spark再根据这些RD结构在内存中执行对应的操做。固然这个拓扑结构会被拆分为各个子任务分发到各个spark节点上，而后计算完之后再造成下一个rdd。最后汇总结果便可。

因为是在内存中对数据进行操做，省去了没必要要的IO操做，，不须要像Mapreduce同样还得先去hdfs读取文件再完成计算。

storm

在运行一个Storm任务以前，须要了解一些概念：

1. Topologies
2. Streams
3. Spouts
4. Bolts
5. Stream groupings
6. Reliability
7. Tasks
8. Workers
9. Configuration

Storm集群和Hadoop集群表面上看很相似。可是Hadoop上运行的是MapReduce jobs，而在Storm上运行的是拓扑（topology），这二者之间是很是不同的。一个关键的区别是： 一个MapReduce job最终会结束， 而一个topology永远会运行（除非你手动kill掉）。

在Storm的集群里面有两种节点： 控制节点（master node）和工做节点（worker node）。控制节点上面运行一个叫Nimbus后台程序，它的做用相似Hadoop里面的JobTracker。Nimbus负责在集群里面分发代码，分配计算任务给机器， 而且监控状态。

每个工做节点上面运行一个叫作Supervisor的节点。Supervisor会监听分配给它那台机器的工做，根据须要启动/关闭工做进程。每个工做进程执行一个topology的一个子集；一个运行的topology由运行在不少机器上的不少工做进程组成。

Nimbus和Supervisor之间的全部协调工做都是经过Zookeeper集群完成。另外，Nimbus进程和Supervisor进程都是快速失败（fail-fast)和无状态的。全部的状态要么在zookeeper里面， 要么在本地磁盘上。这也就意味着你能够用kill -9来杀死Nimbus和Supervisor进程， 而后再重启它们，就好像什么都没有发生过。这个设计使得Storm异常的稳定。

storm比起spark它的实时性能更高更强，storm能够作到亚秒级别的数据输入分析。而spark的方式是经过秒级的数据切分，来造成spark rdd数据集，而后再按照DAG有向图进行执行的。

storm则否则。

一：介绍Storm设计模型

1.Topology

  Storm对任务的抽象，其实 就是将实时数据分析任务 分解为 不一样的阶段    

  点： 计算组件 Spout Bolt

  边： 数据流向 数据从上一个组件流向下一个组件 带方向

2.tuple

  Storm每条记录 封装成一个tuple

  其实就是一些keyvalue对按顺序排列

  方便组件获取数据

3.Spout

  数据采集器

  源源不断的日志记录 如何被topology接收进行处理？

  Spout负责从数据源上获取数据，简单处理 封装成tuple向后面的bolt发射

4.Bolt

  数据处理器    二：开发wordcount案例

1.书写整个大纲的点线图

  

   topology就是一个拓扑图，相似于spark中的dag有向图，只不过storm执行的流式的数据，比dag执行更加具备实时性。

topology包含了spout和bolt。 spout负责获取数据，而且将数据发送给bolt，这个过程就是把任务派发到多个节点，bolt则负责对数据进行处理，好比splitbolt负责把每一个单词提取出来，countbolt负责单词数量的统计，最后的printbolt将每一个结果集tuple打印出来。

这就造成了一个完整的流程。