Hadoop 速成大法(理论)

Posted JintuZheng

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hadoop 速成大法(理论)相关的知识,希望对你有一定的参考价值。

本文笔记仅自用,杠勿cue


编程题:Hadoop 实验MR编程速记

1. 绪论

  1. 大数据4V特征:

    • Volume(容量大)
    • Variety(种类多)
    • Value(有价值)
    • Velocity(追求速度时效)
  2. Hadoop 是分布式系统开发的框架,由三部分组成:HDFS(分布式文件系统),MapReduce(分布式运算框架),Yarn(资源分配系统)。

  3. Google的论文和Apache开发的框架关系:
    BigTable和HBase,MapReduce和MapReduce,GFS和HDFS。

  4. 特点:

    • Hadoop可以存储和处理PB级别的数据(1PB=1024TB)
    • 成本低:服务器的集群节点达到上千个节点
    • 可靠性:自动维护多份副本
    • 高效率:可以并行调度资源处理
  5. 大数据产生模式的三个阶段:运营式系统阶段,用户原创内容阶段,感知式系统阶段

  6. 大数据和科学研究:实验,理论,计算,数据密集型

  7. 大数据和思维方式:全样非采样,效率非准确,相关非因果

  8. 大数据计算模式:批处理计算(MapReduce),流计算(Storm,Flink,SPark streaming),图计算(Pregel,SPark GraphX),查询分析计算(Hive,Dremel,Impala)

  9. 运行模式:本地单机,伪分布式,全分布式

真正的分布式,由3个及以上的实体机或者虚拟机组件的机群。

伪分布式,这种模式也是在一台单机上运行,但用不同的Java进程模仿分布式运行中的各类结点(NameNode,DataNode,JobTracker,TaskTracker,SecondaryNameNode)

从分布式存储的角度来说,集群中的结点由一个NameNode和若干个DataNode组成,另有一个

从分布式应用的角度来说,集群中的结点由一个JobTracker和若干个TaskTracker组成,JobTracker负责任务的调度,TaskTracker负责并行执行任务。TaskTracker必须运行在DataNode上,这样便于数据的本地计算。JobTracker和NameNode则无须在同一台机器上。一个机器上,既当namenode,又当datanode,或者说 既 是jobtracker,又是tasktracker。没有所谓的在多台机器上进行真正的分布式计算,故称为"伪分布式"。

NameNode(1)+DataNode(n)
JobTracker调度(1)+TaskTracker执行(n)

TaskTracker一定要在DataNode上,JobTracker则可以在任意机器上


2. HDFS 分布式文件系统

预备知识:

  1. 什么是元数据?:元数据就是描述数据的数据
  2. 什么是快照:我们在很多情况下都需要备份文件,但是往往需要备份的那台机器不能即时停止运行,这个时候我们需要对文件系统进行打快照,我们对文件系统锁所进行的所有操作都是有记录的,因此,快照系统的操作就是把元数据保存下来,我们可以根据这份快照对文件系统恢复到某个时间点(用Git的思维思考一下)。

HDFS的相关知识:

  1. HDFS系统适合处理超大文件,流式访问数据,不适合低延迟的数据访问,不适合大量小文件的存储,不支持多用户写入和任意修改

在这里插入图片描述
fsimage - 它是在NameNode启动时对整个文件系统的快照
edit logs - 它是在NameNode启动后,对文件系统的改动序列

SecondaryNameNode所完成的工作就是合并fsimage和edit logs

  1. 一些常用的概念:

    • Block:大小默认是256M
    • NameNode:管理文件系统的命名空间,维护整个文件系统的目录树和文件的索引目录。有两种信息,一种是命名空间镜像,一种是编辑日志,namenode在每次系统启动的时候动态重建这些信息,当运行任务的时候,客户通过NameNode获取元数据信息,元数据(描述数据的数据)运行保存在NameNode的内存当中。
    • 副本策略:副本1存放在上传文件的DN,如果是在集群外提交过来的放在磁盘空闲CPU不忙的节点。副本2放在和副本1 不同Rack(机架)的节点
    • 文件操作:NameNode负责文件元数据的操作,DataNode负责处理文件内容的读写请求,数据流不经过NameNode,读取文件的时候NamNode会尽量让用户先读取最近的副本
    • SecondaryNamenode不是备份节点,主要工作是阶段性的合并fsimage和edits文件,以此来控制 edits 的文件大小在合理的范围
    • HDFS系统启动的时候,NamNode进入安全模式,所谓安全模式就是禁止文件系统修改,NameNode先检查DataNode数据块的副本数量是否达到最小值再考虑退出安全模式。
  2. HDFS的读写操作:

    管道式写入(Pipeline),写入遵循这样的步骤:先创建一个任务到NameNode上,然后同时驱使DataOutputStream写入数据,OutputStream(缓冲区)将数据写入某一个DN里面,边写这个DN的时候向其他的DN也写入,并发管道写入,写入的同时不断有ACK报文回复写入的状态,最后关闭缓冲区,OK,完成。如图:
    在这里插入图片描述
    HDFS的读操作:
    在这里插入图片描述

在这里插入图片描述


3. MapReduce 计算框架

MR是一种分布式计算框架,首先传统的并行计算框架是共享内存或者共享存储的,实时的,计算密集型的,但是MR是非共享式的,非实时,适合数据密集型的任务。

开发应用我们遵循这样的:计算-<数据>-写结果。

计算密集型(CPU资源紧张)
比如视频高清解码,严重依赖CPU资源,对代码的运行效率重要。因此用C语言比像Python的脚本语言要好。

IO密集型:(CPU消耗少,对网络和磁盘IO依赖严重的)
大部分的WEB1.0应用都是IO密集型,我们优先使用脚本语言。(WEB1指的是简单的门户)

数据密集型:(需要处理的数据量非常多)
我们面临的数据是海量的,我们的Web2应用(提供即时服务的)

MapReduce采用分而治之的思想,一个非常大的数据集分布地存储在不同的机器上,这样的数据集被切分成多个独立的分片(逻辑上的),这些分片被多个Map任务并行处理,我们遵循计算向数据靠拢,因此节省了移动数据的开销。

在Hadoop中所有的MR程序按照Job的形式提交给集群运行。

MR的核心思想

Split → \\rightarrow RecordReader → \\rightarrow Map → \\rightarrow Partitioner → \\rightarrow Sort → \\rightarrow Reduce

在这里插入图片描述

Map任务:
我们对每一个分片进行进一步的切分,变成多个的<K1,V1>,一般来说,一个<K1,V1>就是一行数据,一个<K1,V1>会被映射成一个或多个<K2,V2>

合并:
我们会将同样的K2进行整合,在逻辑上变成了:<K2,List[V2]>

Reduce任务:
输入是:<K2,List[V2]>,根据每个K2,映射成<K3,V3>

每个(k1、v1)键值对调用一次 map 函数,一个 Reduce 任务处理一个分区数据

不同的Map任务不会通信,不同的Reduce不会发生任何信息交换,记住:用户是不允许干预MR框架的信息交换过程的

在这里插入图片描述
在这里插入图片描述
Map任务的阶段:

【1】读取该分片的数据,解析成KV对,一般来说针对每一行解析成一个K1V1,然后对K1V1的V1进程处理,然后映射成多个或者一个K2V2
【2】对输出的K2V2进行分区,一个分区将形成:K2,{V2,V2,V2},默认是一个分区
【3】此时可进行合并Combiner(可选)
【4】将Map的结果写入本地磁盘

Reduce任务的阶段:

【1】根据多个map任务的输出,按照不同的分区复制到不同的Reduce节点,一个Map可以产生多个分区的结果,但是一个Reduce只能处理一个分区的任务。(这样的重新分配过程称为shuffle,中文意思是洗牌)
【2】对map任务K2的V2s们进行合并Combiner操作
【3】将Reduce的结果写入本地磁盘

分片splits是一个逻辑概念,我们真实存储数据是分桶Blocks,最理想的情况是一个Block对应一个Map一个分片。

例子:一个文件800MB,集群的Block大小是256MB,Split分片的大小是150MB,启动的Map数量是800MB / 150MB = 7splits。我们分片的时候直接无视Blocks

我们都知道Reduce任务的数量是根据我们的Map分区数量得到的,因此最优的Reduce任务个数取决于集群中可用的reduce任务槽slots。我们通常设置比reduce任务槽署目稍微小一些的reduce任务个数,目的是预留系统资源处理可能发生的错误。

Shuffle 洗牌
在这里插入图片描述

需要注意的是分区是针对全局分区而言的。

Shuffle 是从map到reduce之间的过程,也是hadoop最核心的部分,原理:

先看基本概念:

Combiner是对相同key的多个values进行某种操作得到一个新的value的操作,Merge是对相同Key的多个values进行cat操作

  • 合并:Combine:例如:<"a",1>,<"a",1> = <"a",2>
  • 归并:Merge:例如:<"a",1>,<"a",1> = <"a",[1,1]>
  • 排序:会根据指定Key的compare方法进行排序

在这里插入图片描述
我们来这个图的一些细节:

首先一个Map任务有一个缓存,这个缓存区域在内存里面,默认是100MB,默认的溢写Spill比例是0.8,也就是说当我们的数据占了缓存的80%的时候就需要进行溢写(排序 → \\rightarrow 合并Combiner → \\rightarrow 归并Merge)到指定分区,写入对应的分区磁盘文件。

对于Reduce任务而言,一个分区一个Reduce任务,针对来自不同的map任务的数据再做一次归并Merge。需要注意的是:Reduce是主动拉取Map处理之后的数据。我们的JobTracker角色会监视map任务的执行,并且通知Reduce任务来领取。

在这里插入图片描述
任务调度的原理

在MR1.0的时候,我们的JobTracker完成的任务如下:

在这里插入图片描述

到MR2.0的时候,我们有了更加系统化的任务调度系统YARN。Yarn分为NodeManager,ResourceManager。(其中,最大的改进是把Applicationmanager应用管理和ResurceScheduler资源调度分开了)。RM相当于MR1.0里面的JobTracker,Nodemanager相当于MR1.0里面的TaskTracker负责管理节点的运行,当接收到任务的时候启动Container(容器)完成(Map或者Reduce任务)
在这里插入图片描述


4. Yarn 资源任务分配系统

容器:Container 资源容器,集群节点将自身内存CPU磁盘等资源封装在一起的抽象概念

Yarn组件

  • ResourceManager:处理Client的请求,启动和监控AppMaster(简称AM),监控NM,资源分配和调度
  • NodeManager:单个节点上的资源调度,处理来自RM上的命令,处理来自AM的命令
  • ApplicationMaster:动态生成,任务完成之后注销,数据切分,为应用程序申请资源分配给内部任务,负责任务监控和容错

Yarn的作用流程

在这里插入图片描述
【1】Client 向RM提交APP(Job)
【2】RM为APP分配第一个Container,并与这个节点的NM进行通信,要求这个Contatiner启动Appmaster,然后开始执行自己的任务
【3】之后AppMaster保持和RM之间的监控报告
【4】然后AppMaster采用轮询的方式向RM申请和领取资源
【5】一旦AppMaster领取到了资源就会和对应的NM通信,要求他启动任务
【6】NM负责为任务设置好运行环境包括环境变量JAR包,等二进制程序,然后启动任务
【7】每一个任务通过轮询的方式向AppMaster汇报自己的运行状态,如果发生任务失败AppMaster可以重新启动任务
【8】APP(Job)完成之后,AppMaster向RM注销并且关闭自己

具体记忆下面的:

  1. 客户端向ResourceManager(简称RM)提交任务;
  2. RM选择一台节点,安排其启动该任务的AppMaster(以下简称AM);
  3. 被选择的节点,启动AM;
  4. AM向RM申请执行该任务需要的资源(节点,CPU,内存等),RM分配节点给AM;AM与RM保持通信;
  5. AM要求RM分配的节点上执行任务;
  6. 节点按照要求启动容器,执行MAP或者REDUCE操作;节点定期向AM汇报进展情况;
  7. 最后,节点执行任务完毕后,释放所占用的容器资源;AM在任务结束后关闭;

JOB的执行流程

  1. 提交作业
  2. 初始化作业
  3. 分配任务
  4. 执行任务
  5. 更新任务执行进度和状态

如果某个节点的任务执行过慢,会启动备份任务(替代它)

作业调度机制

  1. FIFO,先来先服务
  2. Fair Scheduler,公平调度器
  3. Capacity Scheduler,容量调度器

FIFO只有一个队列

容量调度器支持多个队列,每个队列可配置一定的资源量,每个队列采用FIFO调度策略
在这里插入图片描述
公平调度器:同队列的作业公平共享队列所有的资源
在这里插入图片描述


5. HBase

HBase 是分布式,面向列的数据库,可伸缩,实时读写,可靠,高性能,

介于NoSQL和RDBMS之间,仅能通过主键RowKey和主键的range来检索数据,仅支持单行事务

Hbase的表:
【1】:上亿,上百万列
【2】面向列:面向列族的存储和权限控制,列族的独立检索
【3】稀疏:null的列不占用存储空间

HBase的概念:
【1】RowKey:主键行键
【2】Column family:列族,列中的数据按照二进制存储,没有数据类型
【3】Timestamp:时间戳,64bit,版本信息
【4】Cell:[rowkey] [column+qualifer] [version] 决定一个唯一数据

Hbase的管理架构:

数据存放按照Region来存,每个Region按照startKey和endKey来决定,Region里面的一个列族存成一个Store

在这里插入图片描述
HMaster:负责Table的Schema(增删改),HRegion的拆分和迁移
HRegionServer:管理一系列的HRegion。每一个HRegion对应Table的一个Region。HRegion由多个HStore组成,每一个HStore对应Table的一个Column Family的存储,Client可以通过HMaster快速定位RowKey在哪个HRegion里面
HStore:是HBase的存储核心,由MemSore和StoreFiles组成,当StoreFiles的数量达到一定阈值的时候,就会触发紧缩操作(Compaction)
Hbase 物理上只会增加数据,所有的更新和删除操作都是在Compaction进行的

数据紧缩(Compaction):

Minor Compaction 小紧缩,对一些小的,相邻的StoreFiel将他们合并成更大的StoreFile。这个过程不会处理已经Deleted和Expired的Cell。

Major Compaction 大紧缩,将所有的StoreFile合并一个StoreFile,这个过程里面Deleted的Cell就会被删除,Expired的Cell就会被丢弃,超过版本数量的Cell也会被丢弃,一个Major Compaction操作下来,每个HStore就只剩下一个StoreFile了,Major Compaction 会引起非常多的IO操作因此会触发性能问题,因此他发生在集群比较空闲的时间。

HBase和RDBMS的对比

  • 数据只有字符串
  • 数据操作简单,没有复杂的关联和连接操作
  • 存储模式是列存储
  • 数据维护是用插入替代修改和删除操作
  • 可伸缩行性可以轻松增加和减少硬件数量
  • HBase适合大量插入和大量读的情况
  • Hbase的瓶颈是传输速度,Oracle的平均是磁盘寻道时间
  • Hbase适合寻找按照时间排序的 top n的场景
  • Oracle可以做OLTP(联机事务处理,比如银行交易)又可以做OLAP(联机数据分析,数据仓库,复杂的分析,提供直观的查询结果)

HBase的局限

  • 只能做简单的KV查询,不能做复杂的SQL统计
  • 只能在row Key上做快速查询(索引)

HBase的读写

  • :先向RegionServer提交请求找到对应的region,获取系统的时间戳,更新Wallog,将更新写入Memstore,然后判断MemStore是否需要flush为Store
  • :依次扫描BlockCache,MemStore,StoreFile,然后将结果合并

HBase的模式设计

  • 尽量使用一个列族,列族的数据多少称为”势“
  • 行键的设计:加盐(分配随机数),哈希,反转(比如手机号,前面是有规律的,后面的随机的。我们反转过来,没有意义的放前面,有意义的放后面)
  • 尽量最小化行键和列的大小,列族名最好一个字符
  • 版本数量合适

HBase Shell操作:

create,put,get,scan,delete,drop,disable

  • create ‘表名’, ‘列族名’ #创建一个新表
  • alter ‘表名’, {NAME=> ‘列族名’, METHOD=> ‘delete’} #删除一个列族
  • alter ‘表名’, NAME => ‘列族名’, VERSIONS => 5 # 修改某个列族的版本数量
  • describe ‘表名’ # 获取一个表的描述
  • put ‘表名’, ‘行键’, ‘列’, ‘数据’
  • get ‘表名’, ‘行键’, {COLUMN => ‘列名’, VERSIONS => 3}
  • scan ‘表名’, ROWPREFIXFILTER => ‘行键’
  • delete ‘表名’, ‘行键’, ‘列名’
  • disable ‘表名’
  • drop ‘表名’
  • a=get_table ‘表名’
  • a.scan
  • a.get ‘行键’

6. ZooKeeper 协调分布式应用的服务

ZooKeeper提供通用的分布式锁服务,用以协调分布式应用

  • Hadoop,使用Zookeeper的事件处理确保整个集群只有一个**(active)NameNode**,存储配置信息等。实现NameNode自动切换;
  • HBase,使用Zookeeper的事件处理确保整个集群只有一个**(active)HMaster**,察觉HRegionServer联机和宕机,存储访问控制列表等。

在这里插入图片描述
通信端口:2181
主要功能统一命名服务、配置管理、集群管理、共享锁、队列管理;
ZK 服务器的数量,奇数(3、5、7 等);
最大允许当机的个数,一半以下,即一半以上可以工作时,ZK 集群才算正常

zkServer.sh	start/stop	//启动/停止
zkServer.sh status	//查看状态

High Availability 高可用性

在这里插入图片描述

HA 集群的规划和启动进程

在这里插入图片描述


7. Hive

Hive是一种数据仓库技术,用于查询和管理存储在分布式环境下的大数据集

数据仓库是一个过程而不是一个项目;数据仓库是一个环境,而不是一件产品。
数据仓库提供用户用于决策支持的当前和历史数据,这些数据在传统的操作型数据库中很难或不能得到。

构建于Hadoop的HDFS和MapReduce上,用于管理和查询分析结构化/非结构化数据的数据仓库;

使用 HQL(类 SQL 语句)作为查询接口
使用 HDFS 作为底层存储
使用 MapReduce 作为执行层,即将HQL语句转译成M/R Job在Hadoop执行;

HIVE 的元数据存储(MetaStore): 可以是内置的dearby数据库;也可以是通用关系型数据库(如mysql

内部表与外部表

  • 相同点:需要指定元数据,都支持分区;
  • 不同点:实际数据的存储方式不同;
  1. 内部表。实际数据存储在数据仓库目录(默认/user/hive/warehouse下)。删除表时,表中的数据和元数据将会被同时删除
  2. 外部表。需要 external 关键字;实际数据存储在创建语句 location 指定的 HDFS 路径中,不会移动到数据库目录中。如果删除一个外部表,仅会删除元数据,表中的数据不会被删除。

Hive的分区,分桶

分区:是指按照数据表的某列或某些列分为多个区,区从形式上可以理解为文件夹,比如我们要收集某个大型网站的日志数据,一个网站每天的日志数据存在同一张表上,由于每天会生成大量的日志,导致数据表的内容巨大,在查询时进行全表扫描耗费的资源非常多。那其实这个情况下,我们可以按照日期对数据表进行分区,不同日期的数据存放在不同的分区,在查询时只要指定分区字段的值就可以直接从该分区查找。

Hive表中的一个分区对应表下的一个目录,所有分区的数据都存储在对应的子目录中。
例如:htable 包含ds、city两个分区,则相同日期、不同城市的hdfs目录分别为:

/datawarehouse/htable/ds=20100301/city=GZ
/datawarehouse/htable/ds=20100301/city=BJ

分桶:相对分区进行更细粒度的划分。桶对指定列进行哈希(hash)计算时,根据哈希值切分数据,每个桶对应一个文件

数据上传命令

LOAD DATA LOCAL INPATH '/path/to/local/files'
OVERWRITE INTO TABLE test
PARTITION (country='CHINA')

有LOCAL表示从本地文件系统加载(文件会被拷贝到HDFS中)
无LOCAL表示从HDFS中加载数据(注意:文件直接被移动!!!而不是拷贝!!! 并且。。文件名都不带改的。。)
OVERWRITE 表示是否覆盖表中数据(或指定分区的数据)(没有OVERWRITE 会直接APPEND,而不会滤重!)


8. 其他Hadoop 生态系统

Lambda 架构整合离线计算和实时计算,融合不可变性(Immutability),读写分离和复杂性隔离等一系列架构原则,可集成 Hadoop,Kafka,Storm,Spark,HBase 等各类大数据组件。
Lambda 三层架构:批处理层、实时处理层、服务层

  • 数据采集工具:Flume、Kafka
  • 工作流OOzie
  • 数据分析工具:Pig(基于数据流)
  • RDBMS 与 Hadoop 数据迁移工具:Sqoop
  • 数据挖掘分析工具:Mahout
  • Spark基于内存的大型的、低延迟的数据分析应用程序;

以上是关于Hadoop 速成大法(理论)的主要内容,如果未能解决你的问题,请参考以下文章

Hadoop速成大法(实践)

Hadoop速成大法(实践)

华南农业大学期末 Linux速成大法(理论)

华南农业大学期末 Linux速成大法(理论)

JQuery速成大法

云计算期末速成大法