Hadoop:
是一个由Apache基金会所开发的分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力进行高速运算和存储。
Hadoop实现了一个分布式文件系统(Hadoop Distributed File System),简称HDFS。HDFS有高容错性的特点,并且设计用来部署在低廉的(low-cost)硬件上;而且它提供高吞吐量(high throughput)来访问应用程序的数据,适合那些有着超大数据集(large data set)的应用程序。HDFS放宽了(relax)POSIX的要求,可以以流的形式访问(streaming access)文件系统中的数据。
Hadoop的框架最核心的设计就是:HDFS和MapReduce。HDFS为海量的数据提供了存储,则MapReduce为海量的数据提供了计算。
Hadoop的设计目的:
应对海量数据 2.对大数据进行分布式处理,实现google的mapreduce编程模型和框架,能够把应用程序分割成许多小的工作单元,并把这些单元放到任何集群节点上执行。
Hadoop的元素构成:
最底部是Hadoop Distributed File System(HDFS):存储Hadoop集群中所有存储节点上的文件
HDFS的上一层引擎是MapReduce引擎:由JobTracker和TaskTracker组成
HDFS:
对外部客户机而言,HDFS就像一个传统的分级文件系统,可以创建、删除、移动或重命名文件等等。
HDFS的框架是基于一组特定的节点构建的,这是由它自身的特点决定的,这些节点包括:
NameNode(仅一个):在HDFS中提供元数据服务;NameNode 是一个通常在 HDFS 实例中的单独机器上运行的软件。它负责管理文件系统名称空间;记录文件数据块在每个DataNode上的位置和副本信息;协调客户端对文件的访问;记录命名空间内的改动或命名空间本身属性的改动。
DataNode:为HDFS提供存储块,把HDFS数据块读写到本地的文件系统(存储实际的数据)。DataNode 也是一个通常在 HDFS实例中的单独机器上运行的软件。它负责所在物理节点上的存储管理。
客户端联系NameNode以获取文件的元数据,而真正的IO操作是直接和DataNode进行交互的。
NameNode使用事务日志(Editlog)记录HDFS,元数据变化使用映像文件存储文件系统的命名空间,包括文件的映射,文件的属性信息等。事务日志和映像文件都存储在NameNode的本地文件系统中。NameNode启动的时候,从磁盘中读取映像文件和事务日志,把事务日志的事物都应用到内存中的映像文件中,然后将新的元数据刷新到本地磁盘的新的映像文件中,这样可以截去旧的事务日志,这个过程被称为检查点。
副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称之为Rack-Aware的策略来改进数据的可靠性、有效性和网络带宽的利用。
如果一个HDFS集群跨越了多个数据中心,那么也将首先尝试读本地数据中心的副本,NameNode自动会进入一个称之为SafeMode的特殊状态,处在这个状态的NameNode是不会进行数据块的复制的,NameNode从所有的DataNode接收心跳包(heartbeat)和Blockreport(块状态报告),Blockreport包括了某个DataNode所有的数据块列表,每个Block都有指定的数目的副本。当NameNode检测确认某个DataNode的数据块副本的最小数目,那么该DataNode就会被确认是安全的;如果一定百分比的数据确认是安全的,那么NameNode将退出SafeMode的状态,接下来它会确定还有哪些数据块的副本没有达到指定数目,并将这些Block复制到其他DataNode。
NameNode在内存中保存着整个文件系统的namespace(命名空间)和Blockmap的映像。
HDFS的特点:
高度容错性的系统,并且设计用来部署在低廉的(low-cost)硬件上。
提供高吞吐量的数据访问,适合那些有着超大数据集(large data set)的应用程序。
放宽了一部分POSIX约束,可以以流的形式访问(streaming access)文件系统中的数据。
Apache Nutch搜索引擎项目的基础架构
HDFS的缺点:
仅存在一个NameNode(单点失败)
HDFS的传输:
存储在HDFS中的文件被分成块,然后将这些块复制到多个计算机中。块的大小通常为64MB,和复制的块数量在创建时由客户机决定。Namenode可以控制所有文件操作。HDFS内部的所有通信都基于标准的TCP\IP协议
HDFS的主要目的
是支持以流的形式访问写入的大型文件,如果客户机想将文件写到HDFS上,首先需要将该文件缓存到本地的临时存储,如果缓存的大于所需的HDFS块大小,创建文件的请求将发送给NameNode,NameNode将以DataNode标志和目标块响应客户机,同时也通知将要保存文件块副本的DataNode为客户机开始将临时文件发送给第一个DataNode时,将立即通过管道方式将块内从转发给副本DataNode,客户机也负责创建保存在相同HDFS上名称空间中的校验和文件,在最后的文件块发送后NameNode将文件创建块提交到它的持久化元素、数据存储,在分布式存储和分布式计算方面,Hadoop使用主从,也就是master和slave架构,在一个配置完整的集群上有不同的角色行使各自的权利,来让Hadoop运行起来。
MapReduce:
是一种处理海量数据的并行编程模型的计算框架,用于对大规模数据集的并行运算。
在Hadoop中,分布式文件系统很大程度上是为各种分布式计算需求所服务的。从计算的角度,MapReduce框架接受各种格式的介质对文件作为输入、读取、计算后,最终生成了自定义格式的输出文件;从分布式角度,分布式计算的文件往往规模巨大,且分布在多台机器上,单机计算完全不可支撑且效率低下。
在MapReduce框架中,每一次计算请求称之为作业。
作业:
1.将作业拆分成若干个Map任务,分配到不同的机器上进行,每个Map拿输入文件的一部分作为自己的输入,经过一些计算生成某种格式的中间文件,这种格式与最终所需的文件格式完全一致
2.系统生成若干个Reduce 任务,也是分配到不同的机器中执行,它的目标就是将若干个Map任务生成的中间文件汇总到最后的输出文件。
作业服务器
在Hadoop中被称为Job Tracker:管理运行在此框架下的所有作业
在Google论文中被称为Master:为各个作业分配任务的核心
客户端:是一组API
RPC服务器:由RPC的代理进行调用
Map函数的输出是一系列的Key/Value对,这些Key/Value对是给Reduce函数使用的,Map函数的输出参数也是Key/Value,与输入的Key/Value不是同一组东西。对于一个Map函数调用,输入的是一个Key/Value对,而输出是一组Key/Value对。
用户程序中的MapReduce Library会将输入的文件切分,由cluster(集群)的机器拷贝一份master,多份workers,master会将任务分配给workers。Master连接Map函数和Reduce函数,ReduceWorker将Key/Value对从MapWorker处通过RPC(远程过程调用协议)读取,读取完成后,将这些Key/Value对按照Key进行排序。ReduceWorker迭代整个被排序后的Key/Value对数据。
Master的三个作用:
将任务分配给了Worker
维护了所有Worker的信息和所处的状态
将Map任务结果的位置告诉给Reduce任务
Master会每隔一段时间ping一次workers,如果一定时间内没有返回,那么Master会会认为这个机器宕掉了。
宕机状态分类:
Map任务正在执行。该Map任务需要分配到其他Worker上重新执行。
Map任务已经完成。该Map任务需要分配到其他Worker上重新执行。
Reduce任务正在执行。该任务需要重新执行。
Reduce任务已经完成。这个情况下,该任务不需要重新执行,因为Reduce任务的结果是放在一个公共的分布式文件系统中,机器挂了,对于该结果的读取不会有任何影响。
如果Master宕掉了,整个MapReduce任务会被异常终止,用户程序能够捕获到这种异常,并决定是否重新执行。
Hadoop使用架构:
Master节点部署
NameNode
Secondary NameNode:用来监控HDFS状态的辅助后台程序。每个集群都有一个Secondary NameNode,并且部署在一台单独的服务器上。与NameNode的区别在于它不接受或记录任何的数据变化,但它会与NameNode进行通信,定期保存HDFS的元数据快照。可作为NameNode备用使用。
JobTracker:跟踪所有运行的Task,一旦某个Task失败,JobTracker会自动重启这个Task:它还负责当用户代码提交到集群以后决定哪个文件被处理,并为不同的Task分配节点。每个Hadoop集群只有一个JobTracker,一般运行在Master节点上。
注:
1) 在小集群中,Secondary NameNode可以属于某个从节点
2) 在大型集群中,NameNode和JobTracker被分别部署在两台服务器上
Slave节电部署
DataNode
TaskTracker:与DataNode配合,主要职责是与JobTracker交互。每个从节点仅有唯一的一个TaskTracker,用于并行处理多个Map以及Reduce任务
Hadoop集群运行模式:
单机模式:开始的调试工作
伪分布式模式:用不同的JAVA进程模拟分布式运行中的节点
完全分布式模式:不同的系统会有不同的节点划分方式
在HDFS方面,节点分为NameNode(只有一个)、DataNode(有多个);
在MapReduce方面,节点分为JobTracker(只有一个)、TaskTracker(有多个)。
Hbase:
Hbase是一个分布式的、面向列的开源数据库。
NoSQL,泛指非关系型数据库。
Hbase的设计初衷是在商业服务器集群中完成从基础建设到水平扩展阶段。
在生产环境中使用Hbase的选择:使用Cloudera的CDH3版本;自行编译Hadoop branch-0.20-append源码分支
Hbase的优缺点
优点:消除了磁盘的随机写。
缺点:将最新的数据保存在了内存表中,对内存有较大需求。
解决方案:设计compaction(压缩)操作;设计split(分割)操作
Hbase的RegionServer(Hbase的服务,部署在一台物理服务器上)宕机超过一定时间后,HMaster会将会将其所管理的Region(类似分区)重新分布到其他存活的RegionServer,由于数据和日志都持久的存在于HDFS中,因此不会导致数据丢失。
RegionServer的内存表memstore如何在节点间做到更高的可用,是一个较大的挑战。
Hbase使用了较新的CMS GC(算法),默认触发GC的时机是当年老代内存达到90%的时候,这个百分比由CMSlnitiatingOccupancyFraction=N这个参数设置。
Hbase的适用场合
有足够多的数据存入Hbase
要确认即便不使用传统关系型数据库提供的额外功能,系统也能顺畅工作
有足够的硬件服务器来支撑Hbase的运行
Hbase的特点
高可靠性、高性能、列存储、可伸缩、实时读写
Hbase仅支持单行事务,主要用来存储非组结构化和半结构化的松散数据
Hive:
Hive是建立在Hadoop上的数据仓库基础构架,它提供了一系列工具,可以用来进行数据提取转化加载,这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。
Hadoop用户接口主要有三个:CLI、Client、WUI。
CLI是最常用的,它启动的时候,会同时启动一个Hive副本。
Client是Hive的客户端,用户连接至Hive Sever,在启动Client模式的时候,需要指出Hive Sever所在节点,并在该节点启动Hive Sever。
WUI是通过浏览器访问Hive
Hive的元数据包括表的名字、表的列。表的分区及属性、表的属性、表的数据所在目录,等。
Hive连接到数据库的模式
Single User Mode(单用户模式):连接到In-memory(存储器)的数据库Derby,一般用于Unit Test(单元测试)。
Multi User Mode(多用户模式):通过网络连接到数据库,最常使用的模式。
Hive的数据模型:
Table
External table
Partition
Bucket
Hive的服务:
-service 指定服务
-service help 帮助
Hive支持的服务列表:Beeline、CLI、Help、Hive Service2、Hive Service、HWI、JAR、Lineage、Metastore、Metatool。
CLI:Hive的命令行界面,可直接在命令行中使用。
Hive Service:可以让Hive以提供Thrift(软件框架)服务的服务器形式来运行,可允许多不同语言编写的客户端进行通信。
HWI :Hive的Web接口;Hive CLI的Web替换方案。
JAR:与Hadoop JAR包等价Hive的接口,这是运行在类路径中,同时包含Hadoop和Hive表的Java应用程序的简便方式。
Metastore:和Hive服务运行在同一个进程中;可让Metastore作为单独的进程运行;可通过METASTORE_PORT指定监听的端口号。
ZooKeeper:
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
ZooKeeper中的角色:
l 领导者:负责进行投票的发起和决议;更新系统状态
l 学习者
n 跟随者:用于接收客户请求并向客户端发送结果;参与投票
n 观察者:接收客户端连接;将写请求转发给领导者;不参与投票,只同步领导者的状态。目的:扩展系统,提高读取速度
l 客户端
ZooKeeper的设计目的:
最终的一致性
可靠性
实时性
等待无关
原子性
顺序性
全局有序
偏序
ZooKeeper的工作原理:
ZooKeeper的核心是原子广播,这个机制保证了各个Server之间的同步,实现这个协议的协议是Zab协议,这个协议有俩个模式,分别是恢复模式和广播模式。当服务启动,或者在领导者崩溃后Zab就进入了恢复模式,当领导者被选举出来且大多数的Server完成了和领导者的状态同步以后,恢复模式结束。
Server的工作状态:
LOOKING:当前的Server不知道Leader是谁,正在搜寻
LEADING:当前的Server即为选举出来的Leader
FOLLOWING: Leader已经选举出来 ,当前Server与之同步
ZooKeeper的选举算法:
基于Basic Paxos算法实现的:
基于Fast Paxos算法实现的(系统默认)
Zoopeeper的同步流程:
1.Laeder等待Server连接
2.Follower连接Leader,将最大的zxid发送给Leader
3.Leader根据Follower的zxid确定同步点
4.完成同步后通知Follower已经成为UpToDate状态
5.Follower收到UpTo Date消息后,又可以重新接受Client的请求进行服务
Leader的功能:
恢复数据
维持与Learner的心跳,接收Learner的请求并判断Learner的请求消息类型
Follower的功能
向Leader发送请求
接收Leader消息并处理
接收Client的请求,如果为写请求,发送给Leader进行投票
返回Client结果
Follower的消息处理
PING消息
PROPOSAL消息
COMMIT消息
UPTODATE消息
REVALIDATE消息
l SYNC消息