zoukankan      html  css  js  c++  java
  • 大数据(hadoop)

    大数据

    一.概述

    二.大数据特点

    三.大数据部门组织结构

    hadoop框架

    一.hadoop是什么

     

    • Hadoop是一个由Apache基金会所开发的分布式系统基础架构。
    • 主要解决,海量数据的存储和海量数据的分析计算问题。
    • 广义上来说,Hadoop通常是指一个更广泛的概念——Hadoop生态圈。

    二.hadoop三大发行版本

    • Hadoop三大发行版本:Apache、Cloudera、Hortonworks。
    • Apache版本最原始(最基础)的版本,对于入门学习最好。
    • Cloudera在大型互联网企业中用的较多。
    • Hortonworks文档较好。

    三.hadoop的优势

    • 高可靠性:Hadoop底层维护多个数据副本,所以即使Hadoop某个计算元素或存储出现故障,也不会导致数据的丢失。
    • 高扩展性:在集群间分配任务数据,可方便的扩展数以千计的节点。
    • 高效性:在MapReduce的思想下,Hadoop是并行工作的,以加快任务处理
    • 高容错性:能够自动将失败的任务重新分配。

    四.hadoop的组成

     

    HDFS

    一.HDFS概述

    • HDFS是大数据开源框架hadoop的组件之一,全称(Hadoop Distributed File System),它是一个分布式文件系统,由多台服务器联合起来实现文件存储功能,通过目录树来定位文件,集群中的服务器都有有各自的角色。

    二.HDFS架构的组成

    1.NameNode (nn):就是Master,它
    是—个主管、管理者。

    • 管理HDFS的名称空间;
    • 配置副本策略;
    • 管理数据块(B1ock)映射信息;
    • 处理客户端读写请求。

    2.DataNode:就是Slave。NameNode
    下达命令,DataNode执行实际的操作。

    • 存储实际的数据块;
    • 执行数据块的读/写操作。

    3.Client:就是客户端。

    • 文件切分。文件上传HDFS的时候,Clien将文件切分成一个一个的Block,然后进行上传;
    • 与NameNode交互,获取文件的位置信息;
    • 与DataNode交互,读取或者写入数据;
    • Clier提供一些命令来管理HDFS,比如NameNode格式化;
    • Client可以通过一些命令来访问HDFS,比如对HDFS增删查改操作;

    4.Secondary NameNode:并非NameNode的热备。当NameNode挂掉的时候,它并不
    能马上替换NameNode并提供服务。

    • 辅助NameNode,分担其工作量,比如定期合并Fsimage和Edits,并推送给NameNode ;
    • 在紧急情况下,可辅助恢复NameNode。

    三.HDFS优缺点

    优点:

    1.高容错性

    • 数据自动保存多个副本。它通过增加副本的形式,提高容错性。
    • 某一个副本丢失以后,它可以自动恢复。

    2.适合处理大数据

    • 数据规模:能够处理数据规模达到GB、TB、甚至PB级别的数据;
    • 文件规模:能够处理百万规模以上的文件数量,数量相当之大。

    3.可构建在廉价机器上,通过多副本机制,提高可靠性。

    缺点:

    1.不适合低延时数据访问,比如毫秒级的存储数据,是做不到的。
    2.无法高效的对大量小文件进行存储。

    • 存储大量小文件的话,它会占用NameNode大量的内存来存储文件目录和块信息。这样是不可取的,因为NameNode的内存总是有限的;
    • 小文件存储的寻址时间会超过读取时间,它违反了HDFS的设计目标

    3.不支持并发写入、文件随机修改。

    • 同一时间一个文件只能有一个用户执行写操作,不允许多个线同时写;
    • 仅支持数据append(追加),不支持文件的随机修改。

    四.HDFS中namenode和DataNode的作用

    1.namenode:

    • 负责接受客户端读写数据请求
    • 负责数据块副本的存储策略
    • 负责管理快数据的映射关系
    • 储存元数据信息

    2.datanode:

    • 存储实际的数据块
    • 真实处理数据块的读/写操作

    五.namenode、secondarynamenode和DataNode工作机制

    1.NameNode启动和工作内容:

    • 第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,会加载编辑日志和镜像文件到内存。
    • 客户端对元数据进行增删改的请求。
    • NameNode记录操作日志,更新滚动日志。
    • NameNode在内存中对元数据进行增删改。

    2.Secondary NameNode工作内容:

    • 2NN询问NN是否需要CheckPoint(合并镜像和编辑日志),并带回NameNode是否执行结果。
    • 2NN请求执行CheckPoint
    • NN滚动正在写的Edits编辑日志。
    • 将滚动前的编辑日志和镜像文件拷贝到2NN。
    • 2NN加载编辑日志和镜像文件到内存,并执行合并,生成新的镜像文件fsimage.chkpoint。
    • 2NN拷贝fsimage.chkpoint到NN。
    • NN将fsimage.chkpoint重新命名成fsimage,替换之间旧的fsimage

    3.DataNode:

    • 一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
    • DataNode启动后向NameNode注册,通过后,周期性(1小时)的向NameNode上报所有的块信息。
    • 心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用。
    • 集群运行中可以安全加入和退出一些机器。

    六.HDFS文件块大小

    HDFS中的文件在物理上是分块存储(B1ock),块的大小可以通过配置参数
    ( dfs.blocksize)来规定,默认大小在Hadoop2.x版本中是128M,老版本中是64M。

    • 集群中的block
    • 如果寻址时间约为10ms,即查找到目标block的时间为1Oms。
    • 3寻址时间为传输时间的1%时,则为最佳状态。   因此,传输时间=10ms/0.01=100Oms=1s
    • 而目前磁盘的传输速率普遍为100MB/s。
    • block大小   =1s*100MB/s=10OMB

    思考:为什么块的大小不能设置太小,也不能设置太大?

    • HDFS的块设置太小,会增加寻址时间,程序一直在找块的开始位置;
    • 如果块设置的太大,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时,会非常慢。

    总结:HDFS块的大小设置主要取决于磁盘传输速率。

    MapReduce

    一.MapReduce概述

    • MapReduce是一个分布式运算程序的编程框架,是用户开发“基于Hadoop的数据分析应用”的核心框架。
    • MapReduce核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序,并发运行在一个Hadoop集群上。

    二.MapReduce优缺点

    优点:

    1.MapReduce易于编程

    • 它简单的实现一些接口,就可以完成一个分布式程序,这个分布式程序可以分布到大量廉价的PC机器上运行。也就是说你写一个分布式程序,跟写一个简单的串行程序是一模一样的。就是因为这个特点使得MapReduce编程变得非常流行。

    2.良好的扩展性

    • 当你的计算资源不能得到满足的时候,你可以通过简单的增加机器来扩展它的计算能力。

    3.高容错性

    • MapReduce设计的初衷就是使程序能够部署在廉价的PC机器上,这就要求它具有很高的容错性。比如其中一台机器挂了,它可以把上面的计算任务转移到另外一个节点上运行,不至于这个任务运行失败,而且这个过程不需要人工参与,而完全是由Hadoop内部完成的。

    4.适合PB级以上海量数据的离线处理

    • 可以实现上千台服务器集群并发工作,提供数据处理能力。

    缺点:

    1.不擅长实时计算

    • MapReduce无法像MySQL—样,在毫秒或者秒级内返回结果。

    2.不擅长流式计算

    • 流式计算的输入数据是动态的,而MapReduce的输入数据集是静态的,不能动态变化。这是因为MapReduce自身的设计特点决定了数据源必须是静态的。

    3.不擅长DAG(有向图)计算

    • 多个应用程序存在依赖关系,后一个应用程序的输入为前一个的输出。在这种情况下,MapReduce并不是不能做,r而是使用后,每个MapReduce作业的输出结果都会写入到磁盘,会造成大量的磁盘IO,导致性能非常的低下。

    三.MapReduce核心思想

    • 分布式的运算程序往往需要分成至少2个阶段。
    • 第一个阶段的MapTask并发实例,完全并行运行,互不相干。
    • 第二个阶段的ReduceTask并发实例互不相干,但是他们的数据依赖于上一个阶段的所有MapTask并发实例的输出。
    • MapReduce编程模型只能包含一个Map阶段和一个Reduce阶段,如果用户的业务逻辑非常复杂,那就只能多个MapReduce程序,串行运行。
    • 总结:分析WordCount数据流走向深入理解MapReduce核心思想。

    四.MapReduce进程

    • 分布式的运算程序往往需要分成至少2个阶段。
    • 第一个阶段的MapTask并发实例,完全并行运行,互不相干。
    • 第二个阶段的ReduceTask并发实例互不相干,但是他们的数据依赖于上一个阶段的所有MapTask并发实例的输出。
    • MapReduce编程模型只能包含一个Map阶段和一个Reduce阶段,如果用户的业务逻辑非常复杂,那就只能多个MapReduce程序,串行运行。
    • 总结分析WordCount数据流走向深入理解MapReduce核心思想。

    五.MapReduce工作流程

    1.流程详解

    上面的流程是整个MapReduce最全工作流程,但是Shuffle过程只是从第7步开始到第16步结束,具体Shuffle过程详解,如下:

    • MapTask收集我们的map()方法输出的kv对,放到内存缓冲区中
    • 从内存缓冲区不断溢出本地磁盘文件,可能会溢出多个文件
    • 多个溢出文件会被合并成大的溢出文件
    • 在溢出过程及合并的过程中,都要调用Partitioner进行分区和针对key进行排序
    • ReduceTask根据自己的分区号,去各个MapTask机器上取相应的结果分区数据
    • ReduceTask会取到同一个分区的来自不同MapTask的结果文件,ReduceTask会将这些文件再进行合并(归并排序)
    • 合并成大文件后,Shuffle的过程也就结束了,后面进入ReduceTask的逻辑运算过程(从文件中取出一个一个的键值对Group,调用用户自定义的reduce()方法)

    注意

    • Shuffle中的缓冲区大小会影响到MapReduce程序的执行效率,原则上说,缓冲区越大,磁盘io的次数越少,执行速度就越快。
    • 缓冲区的大小可以通过参数调整,参数:io.sort.mb默认100M。

     

    六.MapReduce作业提交

      

    yarn

    一.yarn概述

    Yarn是一个资源调度平台,负责为运算程序提供服务器运算资源,相当于一个分布式的操作系统平台,而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。

    二.yarn架构组成   

    YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等组件构成.

    ResourceManager:

    • RM是一个全局的资源管理器,负责整个系统的资源管理和分配。它主要由两个组件构成:调度器(Scheduler)和应用程序管理器(Applications Manager,ASM)。
    • 调度器 调度器根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。需要注意的是,该调度器是一个“纯调度器”,它不再从事任何与具体应用程序相关的工作,比如不负责监控或者跟踪应用的执行状态等,也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务,这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配,而资源分配单位用一个抽象概念“资源容器”(Resource Container,简称Container)表示,Container是一个动态资源分配单位,它将内存、CPU、磁盘、网络等资源封装在一起,从而限定每个任务使用的资源量。此外,该调度器是一个可插拔的组件,用户可根据自己的需要设计新的调度器,YARN提供了多种直接可用的调度器,比如Fair Scheduler和Capacity Scheduler等。
    • 应用程序管理器应用程序管理器负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

    NodeManager:

    • NM是每个节点上的资源和任务管理器,一方面,它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态;另一方面,它接收并处理来自AM的Container启动/停止等各种请求。

    ApplicationMaster:

    用户提交的每个应用程序均包含一个AM,主要功能包括:

    • 与RM调度器协商以获取资源(用Container表示);
    • 将得到的任务进一步分配给内部的任务(资源的二次分配);
    • 与NM通信以启动/停止任务;
    • 监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务。

    当前YARN自带了两个AM实现,一个是用于演示AM编写方法的实例程序distributedshell,它可以申请一定数目的Container以并行运行一个Shell命令或者Shell脚本;另一个是运行MapReduce应用程序的AM—MRAppMaster。

    注:RM只负责监控AM,在AM运行失败时候启动它,RM并不负责AM内部任务的容错,这由AM来完成。

    Container:

       Container是YARN中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当AM向RM申请资源时,RM为AM返回的资源便是用Container表示。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。

    • 注:1. Container不同于MRv1中的slot,它是一个动态资源划分单位,是根据应用程序的需求动态生成的。
    • 2. 现在YARN仅支持CPU和内存两种资源,且使用了轻量级资源隔离机制Cgroups进行资源隔离。
    • YARN的资源管理和执行框架都是按主/从范例实现的——Slave ---节点管理器(NM)运行、监控每个节点,并向集群的Master---资源管理器(RM)报告资源的可用性状态,资源管理器最终为系统里所有应用分配资源。
    • 特定应用的执行由ApplicationMaster控制,ApplicationMaster负责将一个应用分割成多个任务,并和资源管理器协调执行所需的资源,资源一旦分配好,ApplicationMaster就和节点管理器一起安排、执行、监控独立的应用任务。
    • 需要说明的是, YARN不同服务组件的通信方式采用了事件驱动的异步并发机制,这样可以简化系统的设计。
     

    三.yarn 运行机制

    2.工作机制详解

    • MR程序提交到客户端所在的节点。
    • YarnRunner向ResourceManager申请一个Application。
    • RM将该应用程序的资源路径返回给YarnRunner。
    • 该程序将运行所需资源提交到HDFS上。
    • 程序资源提交完毕后,申请运行mrAppMaster。
    • RM将用户的请求初始化成一个Task。
    • 其中一个NodeManager领取到Task任务。
    • 该NodeManager创建容器Container,并产生MRAppmaster。
    • Container从HDFS上拷贝资源到本地。
    • MRAppmaster向RM 申请运行MapTask资源。
    • RM将运行MapTask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器。
    • MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动MapTask,MapTask对数据分区排序。
    • MrAppMaster等待所有MapTask运行完毕后,向RM申请容器,运行ReduceTask。
    • ReduceTask向MapTask获取相应分区的数据。
    • 程序运行完毕后,MR会向RM申请注销自己。

    四.yarn作业提交

    • 第1步:Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业。
    • 第2步:Client向RM申请一个作业id。
    • 第3步:RM给Client返回该job资源的提交路径和作业id。
    • 第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。
    • 第5步:Client提交完资源后,向RM申请运行MrAppMaster。

    2.作业初始化

    • 第6步:当RM收到Client的请求后,将该job添加到容量调度器中。
    • 第7步:某一个空闲的NM领取到该Job。
    • 第8步:该NM创建Container,并产生MRAppmaster。
    • 第9步:下载Client提交的资源到本地。

    3.任务分配

    • 第10步:MrAppMaster向RM申请运行多个MapTask任务资源。
    • 第11步:RM将运行MapTask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器。

    4.任务运行

    • 第12步:MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动MapTask,MapTask对数据分区排序。
    • 第13步:MrAppMaster等待所有MapTask运行完毕后,向RM申请容器,运行ReduceTask。
    • 第14步:ReduceTask向MapTask获取相应分区的数据。
    • 第15步:程序运行完毕后,MR会向RM申请注销自己。

    5.进度和状态更新

    • YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。

    6.作业完成

    • 除了向应用管理器请求作业进度外, 客户端每5秒都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和Container会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

    HDFS HA高可用

    一.HDFS-HA概述

    1.所谓HA(High Available),即高可用(7*24小时不中断服务)。

    2.实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制:HDFS的HA和YARN的HA。

    3.Hadoop2.0之前,在HDFS集群中NameNode存在单点故障(SPOF)。

    4.NameNode主要在以下两个方面影响HDFS集群

    • NameNode机器发生意外,如宕机,集群将无法使用,直到管理员重启
    • NameNode机器需要升级,包括软件、硬件升级,此时集群也将无法使用

    HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障,如机器崩溃或机器需要升级维护,这时可通过此种方式将NameNode很快的切换到另外一台机器。

    二.HDFS-HA工作机制

    • 通过双NameNode消除单点故障

    三.HDFS-HA工作要点

    1. 元数据管理方式需要改变

    • 内存中各自保存一份元数据;
    • Edits日志只有Active状态的NameNode节点可以做写操作;
    • 两个NameNode都可以读取Edits;
    • 共享的Edits放在一个共享存储中管理(qjournal和NFS两个主流实现);

    2. 需要一个状态管理功能模块

    • 实现了一个zkfailover,常驻在每一个namenode所在的节点,每一个zkfailover负责监控自己所在NameNode节点,利用zk进行状态标识,当需要进行状态切换时,由zkfailover来负责切换,切换时需要防止brain split现象的发生。

    3. 必须保证两个NameNode之间能够ssh无密码登录

    4. 隔离(Fence),即同一时刻仅仅有一个NameNode对外提供服务

     

    四.HDFS-HA自动故障转移工作机制

    1.故障检测:

    • 集群中的每个NameNode在ZooKeeper中维护了一个持久会话,如果机器崩溃,ZooKeeper中的会话将终止,ZooKeeper通知另一个NameNode需要触发故障转移。

    2.现役NameNode选择:

    • ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃,另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。
    • ZKFC是自动故障转移中的另一个新组件,是ZooKeeper的客户端,也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程;

    ZKFC负责:

    1.健康监测:

    • ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode,只要该NameNode及时地回复健康状态,ZKFC认为该节点是健康的。如果该节点崩溃,冻结或进入不健康状态,健康监测器标识该节点为非健康的。

    2.ZooKeeper会话管理:

    • 当本地NameNode是健康的,ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态,ZKFC也保持一个特殊的znode锁,该锁使用了ZooKeeper对短暂节点的支持,如果会话终止,锁节点将自动删除。

    3.基于ZooKeeper的选择:

    • 如果本地NameNode是健康的,且ZKFC发现没有其它的节点当前持有znode锁,它将为自己获取该锁。如果成功,则它已经赢得了选择,并负责运行故障转移进程以使它的本地NameNode为Active。故障转移进程与前面描述的手动故障转移相似,首先如果必要保护之前的现役NameNode,然后本地NameNode转换为Active状态。

  • 相关阅读:
    openssl生成CA和服务器SSL证书
    Windows编译安装openssl
    yasea浅析
    谈落后时的自卑感(三)
    更新Jekyll
    码云博客
    谈落后时的自卑感(二)
    谈落后时的自卑感(一)
    怎么才能更好的帮助企业进行数据挖掘
    云计算将来会面临什么样的安全威胁?
  • 原文地址:https://www.cnblogs.com/x10011314xxx/p/13384881.html
Copyright © 2011-2022 走看看