Hadoop体系架构概述备份.ppt

Hadoop体系架构概述备份.ppt

《Hadoop体系架构概述备份.ppt》由会员分享，可在线阅读，更多相关《Hadoop体系架构概述备份.ppt（23页珍藏版）》请在冰豆网上搜索。

Hadoop体系架构概述,Hadoop体系架构,HDFS简介,Map/Reduce模型,分布式列式数据库Hbase,Hadoop概述,基于Apache基金会下的一个开源项目，致力于开发一个可靠的、大规模的分布式计算框架用户可采用简单的计算模型在计算机集群下对大规模的数据进行分布式处理设计理念之一是扩展单一的服务器为成千上万机器的集群，且集群中每一个机器同时提供本地计算力和存储力Hadoop框架是在应用层检测和处理硬件失效问题，而不是依赖于硬件自身来维持高可用性。

在Hadoop框架集群中硬件失效被认为是一种常态，集群的高可用性服务是建立在整个集群之上的,分布式文件系统（HadoopDistributedFileSystem，HDFS）并行计算模型（Map/Reduce）列式数据库（HBase）数据仓库（Hive）数据分析语言（Pig）数据格式转化工具（Sqoop）协同工作系统（Zookeeper）数据序列化系统（Avro）,Hadoop整体框架,Hadoop整体框架下特点,Hadoop主要在多节点集群环境下以数据存储为基础最大限度兼容结构化数据格式以数据处理为目的且其数据操作技术多样化,Hadoop体系架构,HDFS简介,Map/Reduce模型,分布式列式数据库Hbase,HDFS概述-基本特征,基于商用硬件环境HDFS具有高容错性，并且被部署在廉价的硬件之上HDFS向应用程序提供高的数据吞吐访问，适合于需要处理大规模海量数据集的应用HDFS遵循部分POSIX协议要求，可以确保应用程序以流的方式访问文件系统数据,HDFS的对现实应用环境的假设及其目标,硬件失效流式数据访问海量数据集追加写入及文件同步“移动计算比移动数据的代价小”跨异构硬件和软件平台的可移植性,1.硬件失效。

在HDFS中，硬件失效是常态而不是意外。

一个真实的HDFS环境可能由上百或上千的机器组成，每一个机器存储文件系统中的部分数据。

集群中大量的机器都有极高的可能性会发生硬件故障而失效，这一真实的情况表明HDFS集群中的部分机器总是处于非正常工作状态。

因此，检测机器失效并快速自动恢复发生故障的机器是HDFS的核心架构目标。

2.流式数据访问。

运行在HDFS之上的应用程序需要流式访问其数据集，这与运行在常规文件系统上的通用应用程序不一样。

HDFS更适用于批量数据处理而不是用户的交互性使用。

HDFS的重点是强调数据的高吞吐访问而不是数据的低延迟访问。

POSIX规定了很多的硬性要求，这些要求对运行在HDFS上的应用程序而言是非必须的。

但是，HDFS在几个关键领域引入了POSIX语义来提高数据的吞吐率。

3.海量数据集。

运行在HDFS上的应用是建立在海量数据集之上的。

HDFS被设计来存储大文件，通常HDFS中的文件大小应该是千兆字节到兆兆字节。

HDFS必须具备有很高的总数据带宽，其单一集群规模能够容乃成千上万的机器节点，并且一个HDFS集群能够支撑数以万计的文件量。

4.追加写入及文件同步。

大多数的HDFS应用都需要“一次写多次读”的文件访问模式。

HDFS具有两种高级特征：

刷新缓存（hflush）和文件添加（append）。

刷新缓存使得一个未关闭文件的最后一个块对访问者可见的同时提供了读一致性和数据持久性。

文件添加提供了在一个已关闭文件的末尾添加额外数据的机制。

5.“移动计算比移动数据的代价小”。

应用所需要的计算如果在数据的附近实施效率更高，这一特性在数据量特别庞大时会显得更加明显。

数据处理的本地化会最大限度地减少网络拥塞，并且提高系统整体的吞吐量。

因此，在HDFS中假设移动计算至数据的存储位置比移动数据至应用程序运行位置更好。

为了实现这一假设，HDFS为应用提供了接口来移动应用自身到接近数据的储存点。

6.跨异构硬件和软件平台的可移植性。

HDFS设计的目标之一是能够简单的从一个平台移植到另一平台。

这便于大量的应用选择HDFS作为一个平台而广泛使用。

HDFS架构,主从（Master/Slave）体系结构只含有一个NameNode主服务节点这个节点管理文件系统中的命名空间和调度客服端对文件的访问通常一个机器就是一个DataNode数据节点，DataNode管理本节点上数据的存储在HDFS内部，一个文件被分割为一个或多个数据块，并且这些数据块被存储在一批DataNode中。

NameNode执行文件系统中命名空间的操作（打开、关闭、重命名文件和目录），NameNode需要执行数据块到DataNode映射的决策DataNode负责响应来自客户端的文件读写要求，也要负责执行来自NameNode的关于数据块创建、删除和冗余存储的指令,NameNode同DataNode都是可以架设在普通商品机上，一个典型的HDFS集群中部署一个专用机做为NameNode，其余的机器部署为DataNode。

虽然，这个体系结构并不排除把一个机器做为多个DataNode节点，但是这样的情况在实际部署中很少发生。

单NameNode结构极大的简化了集群的系统结构，NameNode主管并且存储所有的HDFS的元数据（MetaData），系统中用户数据绝不会流过NameNode节点。

Hadoop体系架构,HDFS简介,Map/Reduce模型,分布式列式数据库Hbase,Map/Reduce简介,一种用于在大型商用硬件集群中（成千上万的节点）对海量数据（多个兆兆字节数据集）实施可靠的、高容错的并行计算的软件系统一个最先由Google提出的分布式计算软件构架基本原理将一个复杂的问题，分成若干个简单的子问题进行解决。

然后，对子问题的结果进行合并，得到原有问题的解,Map/Reduce概念,Map和Reduce是编程语言中的概念，都是处理数据集合的函数Map在处理数据序列的过程中只处理当前的数据信息，不需要跟之前处理的状态信息交互主结点读入输入数据，把它分成可以用相同方法解决的小数据块，然后把这些小数据块分发到不同的工作节点上，每一个工作节点循环做同样的事，这就形成了一个树行结构，而每一个叶子节点来处理每一个具体的小数据块，再把这些处理结果返回给父节点Reduce在处理过程中却依赖之前处理的结果，同时生成的结果也被后续的处理使用。

结点得到所有子节点的处理结果，然后把所有结果组合并且返回到输出一个Map/Reduce任务会把一个输入数据集分割为独立的数据块，然后Map任务会以完全并行的方式处理这些数据块。

Map/Reduce系统自动对Map任务的输出分类，再把这些分类结果做为Reduce任务的输入。

无论是任务的输入还是输出都会被存储在文件系统中。

Map/Reduce系统关注任务调度、任务监测和重新执行失败的任务,Map/Reduce模型,计算节点和存储节点的一致性是因为Map/Reduce系统和HDFS运行在同样的节点结合上。

这样的配置允许Hadoop框架有效的调度任务在那些数据已经准备好了的节点上，这样的好处是整个集群中总带宽非常的高。

Map/Reduce的一个特点是可以用Map和Reduce方法来处理分布式计算问题时，尽可能的实现数据处理的本地化，降低由数据移动而产生的代价。

这里的每一个Map操作都是相对独立的，所有的Maps都是并行运行的，虽然实践中会受到数据源和CPU个数的影响。

同样的，这里用一个Reduce集合来执行Reduce操作，所有带有相同key的Map输出会聚集到同一个Reduce。

虽然这个过程看上去没有串行计算来得高效，但是Map/Reduce能够处理一般服务器所不能处理的大数据量处理问题。

大型的服务器集群可以在几个小时内处理千兆兆数据量的排序问题。

而并行处理可以提供部分容错和出错恢复的功能。

Map/Reduce系统由单一的JobTracker主节点和若干个TaskTracker从节点组成，其中每一个集群节点对应一个TaskTracker节点。

主节点负责调度任务的各个组成任务到从节点上，监控并且重新执行失败的组成任务；从节点执行主节点安排的组成任务。

Map/Reduce的Map和Reduce过程都定义了键值对（）的数据结构，即系统视任务的输入数据为键值对集合，并且产生键值对结合做为任务的输出。

一次Map/Reduce任务的输入输出格式：

（input）-map-combine-reduce-（output）。

一次Map/Reduce任务过程。

用户提交任务给JobTracer，JobTracer把对应的用户程序中的Map操作和Reduce操作映射至TaskTracer节点中；输入模块负责把输入数据分成小数据块，然后把它们传给Map节点；Map节点得到每一个key/value对，处理后产生一个或多个key/value对，然后写入文件；Reduce节点获取临时文件中的数据，对带有相同key的数据进行迭代计算，然后把终结果写入文件。

Map/Reduce处理过程,Map/Reduce优缺点,Map/Reduce通过工作状态的返回有效处理了单点失效的问题Map/Reduce是隶属于大粒度的并行计算模式，并行节点间在Map阶段中和Reduce阶段中无法通信，也并非是一种万能的数据处理模型,Hadoop体系架构,HDFS简介,Map/Reduce模型,分布式列式数据库Hbase,Hbase简介,可提供随机的、实时的大数据读写访问目标是在商用硬件上存储非常大的表数十亿的行数百万的列开源的、分布式的、版本化的、面向列的存储模型对Google公司Bigtable系统的开源模仿，建立在Hadoop和HDFS之上提供类Bigtable的存储力,Hbase数据模型,按预先定义好的列族（Columnfamily）结构来存储数据，即每一条数据有一个key以及若干个列属性值组成，每列的数据都有自己的版本信息数据是按列进行有序存储的，不同于关系型数据库中按行存储两种方式的数据操作，通过对有序key值进行扫描查询，获取value值，或者借助强大的Hadoop来进行Map/Reduce查询采用了强一致性的读写保证，数据会在多个不同的域（region）中进行保存。

列族可以包含无限多个数据版本，每个版本可以有自己的TTL（TimetoLive，生命周期）通过行级锁来保证写操作的原子性，但是不支持多行写操作的事务性。

数据扫描操作不保证一致性,HBase下表的逻辑视图,行键（Rowkey）时间戳（Timestamp）列族（Columnfamily）列（Column）,在创建一张表时，必须定义行键名及所需列族的列族名，理论上一张表在创建时可以无限制地定义列族个数，而时间戳会由系统自动生成。

列无需在创建表时定义，可以在使用时随意定义使用，一个列族下同样可以无限制的定义列的个数。

虽然，HBase中可以任意的定义列族个数及附属列的个数，但是只需能够保证任意一列不为空时，该行即为有效行。

HBase下表的物理视图,在HBase中采用的稀疏存储，物理存储过程中细化到一个单元（Cell）。

在逻辑视图中，任意一行不会空的每一列都被称作为一个单元。

单元联同行键、时间戳、列族名、列名做为完整的一行存储到文件系统中，并且这个存储过程中会自动排序，先在各行键间以字母升序排列，再在同行键间以时间戳降序排列。

一张表创建的初始阶段其中只含有一个Region，随着表中数据的量的不断增多，一个Region会分裂为两个Region，然后不断重复上述过程，并且Region会被存储到HDFS中不同的DataNode上。

Region包含有一个或多个的Store，其数量增长过程同表中的Region数量增长过程一致。

但是Store中分为两个部分：

第一个部分是Memstore，一个Store中只包含一个Memstore，并且Memstore存储在内存空间中；第二个部分是Storefile，此部分由Memstore写入硬盘而得。

随着Memstore写入硬盘的次数增多，Storefile的数量也会增加，当文件个数增加到一定量时，系统会自动对Storefile文件进行合并。

合并过程中主要完成以下几个工作：

1.具有相同行键的行存放在一个文件中；2.扔掉被标志为删