一、HDFS

1、hdfs概述

HDFS (全称Hadoop Distributed File System),即hadoop的分布式文件系统

  • 高容错(数据库blcok备份),可扩展,
  • 适合存大文件,一次写入、多次读写
  • 不能并发写入,不适合小文件,不能修改文件,不适合处理低延时的数据(HBase更好),

hdfs dfs -put localpath hdfspath 上传文件

常用命令 hdfs dfs -help/-ls/-put/-get/-cat/-rm/-cp/-mkdir/-touchz/-appendToFile

运行jar包

[hadoop@node01 ~]$  hadoop  jar  com.hadoop-1.0-SNAPSHOT.jar  com.hadoop.hdfs.CopyFileFromLocal /kkb/install/hadoop-2.6.0-cdh5.14.2  /README.txt   /README.txt

 

组件

节点

默认端口

HDFS

DataNode

50020

HDFS

NameNode

50070

YARN

ResourceManager

8032

ZooKeeper

Server

2181

Hive

Metastore

9083

HBase

Master

60010

 

1.2、HDFS框架

hbase ceph hbase ceph hdfs_hive

三个核心组件是什么, 有什么作用?

  • (1)NameNode. 集群的核心, 是整个文件系统的管理节点. 负责存储HDFS集群的元数据,存在内存中 
  • (2)DataNode. 存放具体数据块的节点, 主要负责数据的读写, 定期向NameNode发送心跳,超过10分钟节点不可用,6小时上报当前DataNode上的块状态
  • (3)SecondaryNameNode. 辅助节点, 同步NameNode中的元数据信息, 辅助NameNode对fsimage和editsLog进行合,对HDFS元数据做checkpoint操作,每1分钟检查一次,每1小时创建一个检查点

集群的心跳机制,让集群中各节点形成一个整体;主节点知道从节点的死活

节点的上下线,导致存储的不均衡,可以手动触发负载均衡

 

元数据:关于文件或目录的描述信息,如文件所在路径、文件名称、文件类型等等,这些信息称为文件的元数据metadata

  • ①编辑日志文件 edits log,保存至namenode中
  • edits log为hdfs-site.xml中属性dfs.namenode.edits.dir的值决定;用于namenode保存edits.log文件
  • ②命名空间镜像文件 fsimage,保存磁盘中
  • 将namenode内存中的元数据落入磁盘生成的文件;
  • fsimage为hdfs-site.xml中属性dfs.namenode.name.dir的值决定;用于namenode保存fsimage文件
     

 

2、HDFS读写流程

2.1、HDFS写流程

请求上传——检查文件是否存在——可以上传——查询Datanode信息——分配datanode——建立数据流——发送数据

hbase ceph hbase ceph hdfs_数据_02

1、当客户端开始写入文件的时候,客户端会将文件切分成多个 packets,并在内部以数据队列“data queue(数据队列)”的形式管理这些 packets,并向 namenode 申请 blocks,获 取用来存储 replicas 的合适的 datanode 列表,列表的大小根据 namenode 中 replication 的设定而定;

2、开始以 pipeline(管道)的形式将 packet 写入所有的 replicas 中。客户端把 packet 以流的 方式写入第一个 datanode,该 datanode 把该 packet 存储之后,再将其传递给在此 pipeline 中的下一个 datanode,直到最后一个 datanode,这种写数据的方式呈流水线的形式。

3、最后一个 datanode 成功存储之后会返回一个 ack packet(确认队列),在 pipeline 里传递 至客户端,在客户端的开发库内部维护着"ack queue",成功收到 datanode 返回的 ack packet 后会从"data queue"移除相应的 packet。

4、如果传输过程中,有某个 datanode 出现了故障,那么当前的 pipeline 会被关闭,出现故 障的 datanode 会从当前的 pipeline 中移除,剩余的 block 会继续剩下的 datanode 中继续 以 pipeline 的形式传输,同时 namenode 会分配一个新的 datanode,保持 replicas 设定的 数量。

5、客户端完成数据的写入后,会对数据流调用 close()方法,关闭数据流;

2.2、HDFS读流程

hbase ceph hbase ceph hdfs_hive_03

1、客户端调用FileSystem 实例的open 方法,获得这个文件对应的输入流InputStream。

2、通过RPC 远程调用NameNode ,获得NameNode 中此文件对应的数据块保存位置,包括这个文件的副本的保存位置( 主要是各DataNode的地址) 。

3、获得输入流之后,客户端调用read 方法读取数据。选择最近的DataNode 建立连接并读取数据。如果客户端和其中一个DataNode 位于同一机器(比如MapReduce 过程中的mapper 和reducer),那么就会直接从本地读取数据。

4、到达数据块末端,关闭与这个DataNode 的连接,然后重新查找下一个数据块。不断执行第2 - 5 步直到数据全部读完。

5、客户端调用close ,关闭输入流DF S InputStream。

2.3、HDFS高可用与联邦

HDFS2.x采用了HA(High Availability高可用)架构。解决了“单点故障”问题

zookeeper确保一主一备,

  • Active状态的NN,负责响应所有客户端的请求;Standby状态的NN作为热备份节点,保证与active的NN的元数据同步。
  • Active节点发生故障时,zookeeper集群会发现此情况,通知Standby节点立即切换到活跃状态对外提供服务,确保集群一直处于可用状态

虽然HDFS HA解决了“单点故障”问题,但HDFS在扩展性、整体性能和隔离性方面仍有问题

HDFS联邦可以解决以上三个问题

 

3、HDFS文件

3.1、HDFS不适合存储小文件的原因:

NameNode存储着文件系统的元数据,每个文件、目录、块大概有150字节的元数据;

小文件数量多会大量占用namenode的内存; 使namenode读取元数据速度变慢, 启动时间延长; 还因为占用内存过大, 导致gc时间增加等.

3.2、解决办法:两个角度,

  • 一是,从数据来源入手,   如每小时抽取一次改为每天抽取一次等方法来积累数据量.
  • 二是,选择合并.   HAR文件方案,Sequence Files方案

如果小文件无可避免, 一般就采用合并的方式解决. 可以写一个MR任务读取某个目录下的所有小文件, 并重写为一个大文件.

SequenceFile文件,是一种由header信息和一条条record记录组成的文件。每个record是键值对形式,小文件名作为当前record的键,小文件的内容作为当前record的值;

3.3 、文件压缩

  • 减少数据所占用的磁盘空间
  • 加快数据在磁盘、网络上的IO

查看集群是否支持本地压缩(所有节点都要确认)

[hadoop@node01 ~]$ hadoop checknative

 

二、MapReduce

1、MapReduce概述

 MapReduce是采用一种分而治之的思想设计出来的分布式计算框架,由两个阶段组成:

  • Map阶段(切分成一个个小的任务)
  • map任务一次读取block的一行数据,以kv对的形式输入map()
  • map()的输出作为reduce()的输入
  • 文件有几个block,就会生成几个map任务
  • Reduce阶段(汇总小任务的结果)
  • reduce任务,通过网络将各map任务输出结果中属于自己的数据取过来
  • key相同的键值对作为一组,调用一次reduce(),reduce任务生成一个结果文件,文件写入HDFS
  • educe任务的个数,由程序中编程指定:job.setNumReduceTasks(4)

2、shuffle

map端的shuffle

  • (1)环形内存 缓冲:
  • 每个map任务都有一个对应的环形内存缓冲区;
  • map()输出kv对,先写入到环形缓冲区(默认大小100M),当内容占据80%缓冲区空间后,由一个后台线程将缓冲区中的数据溢出写到一个磁盘文件。
  • 在溢出写的过程中,map任务继续向环形缓冲区写入数据;但若写入速度大于溢出写的速度,最终造成100m占满后,map任务会暂停向环形缓冲区中写数据的过程;只执行溢出写的过程;直到环形缓冲区的数据全部溢出写到磁盘,才恢复向缓冲区写入
  • (2)后台线程溢写磁盘过程,
  • 1)分区:先对每个溢写的kv对做分区;分区的个数由MR程序的reduce任务数决定;默认使用HashPartitioner计算当前kv对属于哪个分区;计算公式:(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks
  • 2)排序: 每个分区中,根据kv对的key做内存中排序;
  • 3)combine(可选):若设置了map端本地聚合combiner,则对每个分区中,排好序的数据做combine操作;
  • 4)压缩(可选):若设置了对map输出压缩的功能,会对溢写数据压缩

 

reduce端的shuffle

  • (1)拉取:
  • reduce task会在每个map task运行完成后,通过HTTP获得map task输出中,属于自己的分区数据(许多kv对)
  • 如果map输出数据比较小,先保存在reduce的jvm内存中,否则直接写入reduce磁盘
  • (2)归并merge:
  • 一旦内存缓冲区达到阈值(默认0.66)或map输出数的阈值(默认1000),则触发归并merge,结果写到本地磁盘
  • (3)combine(可选):若MR编程指定了combine,在归并过程中会执行combine操作
  •  

3、数据倾斜

  • 数据中不可避免地会出现离群值(outlier),并导致数据倾斜。这些离群值会显著地拖慢MapReduce的执行。
  • 数据倾斜会导致map和reduce的任务执行时间大为延长,也会让需要缓存数据集的操作消耗更多的内存资源
  • 在代码里实现追踪每个键的最大值,诊断哪些键存在数据倾斜。

常见的数据倾斜有以下几类:

  • 数据频率倾斜——某一个区域的数据量要远远大于其他区域。比如某一个key对应的键值对远远大于其他键的键值对。
  • 数据大小倾斜——部分记录的大小远远大于平均值。

减小数据倾斜

  • map端:使用combine,通过抽样和范围分区,而不是HashPartitioner
  • reduce端:自定义分区,限制读取的最大长度

4、java编程

hbase ceph hbase ceph hdfs_数据_04

hbase ceph hbase ceph hdfs_数据_05

hbase ceph hbase ceph hdfs_hive_06

 

三、YARN

1、YARN概述

  • YARN (Yet Another Resource Negotiator,另一种资源协调者),是一种新的 Hadoop 资源管理器,为分离Hadoop2.0资源管理和计算组件而引入
  • YARN的基本思想是  将JobTracker的两个主要功能(资源管理和作业调度/监控)分离,
  • 主要方法是创建一个全局的ResourceManager(RM)和若干个针对应用程序的ApplicationMaster(AM)。

 

2、YARN架构

Client 向 ResourceManager 提交的每一个应用程序都必须有一个 ApplicationMaster,它经过 ResourceManager 分配资源后,运行于某一个 Slave 节点的 Container 中,具体做事情的 Task,同样也运行与某一个 Slave 节点的 Container 中。

hbase ceph hbase ceph hdfs_hbase ceph_07

  • 1)Resource Manager:全局资源管理器
  • 一个集群只有一个RM。
  • 负责和AM(Application Master)交互,资源调度、资源分配等工
  • 2)Node Manager:一台机器上的管理者,类似于部门经理。
  • 管理本机上若干Containers的生命周期、监视资源和跟踪节点健康并定时上报给RM;
  • 接收并处理来自AM的Container启动/停止等各种请求。
  • 3)Application Master:应用程序的管理器,类似项目经理,
  • 一个应用程序只有一个AM。
  • 负责任务开始时找RM要资源,任务完成时向RM注销自己,释放资源;
  • 与NM通信以启动/停止任务;接收NM同步的任务进度信息。
  • ApplicationMaster可以在容器内运行任何类型的任务,不同的 ApplicationMaster 被分布到不同的节点上,因此它们之间不会相互影响。
  • 4)Container:一台机器上具体提供运算资源,
  • 将设备上的内存、CPU、磁盘、网络等资源封装在一起的抽象概念——“资源容器”,
  • Container是一个动态资源分配单位,为了限定每个任务使用的资源量。

3、任务提交

Application在Yarn中的执行过程,整个执行过程可以总结为三步:

  • 应用程序提交
  • 启动应用的ApplicationMaster实例
  • ApplicationMaster 实例管理应用程序的执行

精简版的:

  • 1:客户端程序向 ResourceManager 提交应用,请求一个 RM的ApplicationMaster 实例,并请求传递给RM的scheduler(调度器);调度器分配container(容器)
  • 2:ResourceManager 找到一个可以运行一个 Container 的 NodeManager,并在这个 Container 中启动 ApplicationMaster 实例;
  • 3:ApplicationMaster 与 ResourceManager 注册进行通信,为内部要执行的任务申请资源,一旦得到资源后,将于 NodeManager 通信,以启动对应的 Task;
  • 4:所有任务运行完成后,ApplicationMaster 向 ResourceManager 注销,整个应用程序运行结束。

4、调度器

  • FIFO Scheduler ,先进先出调度器
  • Capacity Scheduler, 容器调度器
  • FairS cheduler, 公平调度器

 

四、ZooKeeper

hbase ceph hbase ceph hdfs_数据_08

 

1、ZooKeeper概述

  • 是一个分布式的,开放源码的分布式应用程序协调服务,
  • 提供基于类似于文件系统的目录节点树方式的数据存储,解决分布式集群中应用系统的一致性问题
  • 维护和监控存储的数据的状态变化,通过监控这些数据状态的变化,从而达到基于数据的集群管理

ZooKeeper  =   ①简版文件系统(Znode) :基于类似于文件系统的目录节点树方式的数据存储

                         +②原语                            :可简单理解成ZooKeeper的基本的命令

                         +③通知机制(Watcher)。
 

启动ZooKeeper集群;在ZooKeeper集群中的每个节点执行此命令
${ZK_HOME}/bin/zkServer.sh start

 

  • ZNode 分为四类:

 

持久节点

临时节点

非有序节点

create

create -e

有序节点

create -s

create -s -e

 

 

 

2、ZooKeeper原子广播协议

ZooKeeper使用原子广播协议叫做Zab(ZooKeeper Automic Broadcast)协议,有两种模式

  • 恢复模式(选主):因为ZooKeeper也是主从架构;当ZooKeeper集群没有主的角色leader时,从众多服务器中选举leader时,处于此模式
  • 广播模式(同步):当集群有了leader后,客户端向ZooKeeper集群读写数据时,集群处于此模式

为了保证事务的顺序一致性,ZooKeeper采用了递增的事务id号(zxid)来标识事务,所有提议(proposal)都有zxid

事务zxid:是一个64位的数字。由32位epoch+32位counter组成
 

3、Zookeeper读写操作

常见的读取操作,如ls /查看目录;get /zktest查询ZNode数据

读操作

  • 客户端先与某个ZK服务器建立Session
  • 然后,直接从此ZK服务器读取数据,并返回客户端即可
  • 关闭Session

客户端写操作

  • ①客户端向zk集群写入数据,如create /kkb;与一个follower建立Session连接,从节点follower01
  • ②follower将写请求转发给leader
  • ③leader收到消息后,发出proposal提案(创建/kkb),每个follower先记录下要创建/kkb
  • ④超过半数quorum(包括leader自己)同意提案,则leader提交commit提案,leader本地创建/kkb节点ZNode
  • ⑤leader通知所有follower,也commit提案;follower各自在本地创建/kkb
  • ⑥follower01响应client
     

4、Leader选举

分两种情况:全新集群leader选举、非全新集群leader选举

选举原则:集群中过半数Server启动后(多数派quorum),才能选举出Leader;;

投票信息vote信息结构为(sid, zxid) 
选举公式:

①zxid大的server胜出;
②若zxid相等,再根据判断sid判断,sid大的胜出
 

五、Hive

1、Hive概述

  • Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供类SQL查询功能。
  • 本质是将SQL转换为MapReduce任务进行运算,底层由HDFS来提供数据的存储,
  • hive不提供数据存储,也不提供数据计算,数据保存在hdfs,计算使用的mr的程序
  • hive当中建库建表的元数据信息保存在mysql里面,只适合用来做离线数据统计分析,也就是数据仓库
  • 查询延迟严重,不支持记录级别的增删改操作,不支持事务

2、用户接口:Client

  • (1)CLI(hive shell):bin/hive
  • (2)JDBC/ODBC(java访问hive):
  • 启动hiveserver2服务:
  • bin/hive --service hiveserver2
  • beeline连接hiveserver2
  • bin/beeline
  • beeline> !connect jdbc:hive2://node01:10000
  • (3)WEBUI(浏览器访问hive)
  • (4)hive 命令行:hive -e执行SQL语句。hive-f 执行sql文件。
  • hive -e sql语句 :执行hql语句;
  • bin/hive -e “show databases;” 不进入hive的客户端,直接执行hql语句
  • hive -f sql文件: 执行hql文件
  • bin/hive -f hive.sql 不进入hive的客户端,直接执行sql脚本文件
  • hive cli命令窗口查看本地文件系统
  • 与操作本地文件系统类似,这里需要使用 ! (感叹号),并且最后需要加上 ;(分号) 。例如!ls /;

3、hive的几种表

  • 内部表:
  • 创建内部表的时候,没有external关键字;
  • 删除内部表的时候,会同步的删除hdfs的数据
  • 外部表:
  • 创建外部表的时候有external关键字;
  • 删除外部表的时候,不会删除hdfs的数据
  • 外部表删的只是表结构, 数据存在hdfs,元数据在mysql
  • 分区表:
  • 实际工作当中,数据一般都是按照每天进行采集的,每天的数据都会放到某一个日期文件夹,
  • 分区表,就是分文件夹
  • 分桶表:
  • 分桶表就是分文件,将一个大的文件分成多个小的文件,每个文件里面保存部分数据,到时候如果需要获取数据的时候,可以直接从对应的文件里面获取即可
  • 分桶将整个数据内容,按照某列属性值取hash值进行区分,具有相同hash值的数据进入到同一个文件中,可以过滤掉大量不相关的文件,提高查询效率
  • 加载数据,不能使用load,只能通过insert select方式加载数据

外部表一般都是用在数据仓库的ODS层

内部表一般都是用在数据仓库的DW层

4、having 与 where ,4个By区别

  • where针对表中的列发挥作用,查询数据;having针对查询结果中的列发挥作用,筛选数据
  • where后面不能写分组函数,而having后面可以使用分组函数,having只用于group by分组统计语句

4个By区别

  • 1)Sort By:分区内有序;
  • 2)Order By:全局排序,只有一个Reducer;
  • 3)Distrbute By:类似MR中Partition,进行分区,结合sort by使用。
  • 4) Cluster By:= distribute by + sort by,当Distribute by和Sorts by字段相同时,可以使用Cluster by方式。
  • Cluster by除了具有Distribute by的功能外还兼具Sort by的功能。但是排序只能是升序排序,不能指定排序规则为ASC或者DESC
  • 5)Group By 分组:按照一个或者多个列队结果进行分组,然后对每个组执行聚合操作。

5、hive的静态分区和动态分区

  • 静态分区。下载数据时,需要手动指定分区字段的具体指。
  • 动态分区。加载数据时,只需要指定分区字段。

6、hive的复合类型 array map struct 

  • array 中的数据为相同类型
  • map中的数据为kv类型
  • struct中的数据可以为不同类型

7、Hive中有三种UDF:

  • 用户定义函数(user-defined function)UDF;返回对应值,一对一
  • 用户定义聚集函数(user-defined aggregate function,UDAF);返回聚类值,多对一
  • 用户定义表生成函数(user-defined table-generating function,UDTF)。返回拆分值,一对多

编写UDF函数
  a)自定义UDF需要继承org.apache.hadoop.hive.ql.UDF。
  b)需要实现evaluate函数,evaluate函数支持重载。

LATERAL VIEW的使用:
侧视图的意义是配合explode(或者其他的UDTF),一个语句生成把单行数据拆解成多行后的数据结果集。

 

8、hive调优

  • 1、开启Fetch抓取是指,对某些情况的查询不使用MapReduce计算。全局查找,字段查找,filter查找,limit查找。
  • 2、表的优化
  • 1)大表join小表,小表放join左边 老版本
  • 2)大表join大表,key为空的字段付一个随机值。
  • 3)对小表使用mapjoin,
  • 4)避免join不加on条件
  • 3、使用分区裁剪与列裁剪,过滤部分数据
  • 4、开启并行执行、严格模式、JVM重用、数据压缩
  • 5、避免数据倾斜
  • 1)小文件合并 
  • 2)mapjoinmap端预聚合
  • 3)调整map与reduce的个数

六、hbase

1、HBase的概念

  HBase是构建在 HDFS上的分布式NoSql数据库,主要用于大数据领域,支持高并发读写与节点扩容,适合列式存储稀疏数据,一般都可以通过JavaAPI来进行各种数据的操作。

特点

  • (1)海量存储:可以存储大批量的数据,
  • (2)列式存储:数据是基于列族进行存储,数据以字节数组进行存储,可以有多个版本值
  • (3)极易扩展:可以通过增加服务器(底层HDFS)对集群的存储进行扩容
  • (4)高并发读写:支持高并发的读写请求
  • (5)不支持小文件,不支持并发写,不支持文件随机修改,查询效率也低

启动时,需要提前启动 HDFS 及 ZooKeeper集群

2、HBase的架构

  • HMaster- HRegionServer- Region
  • Region:是HBase集群中分布式存储的最小单元一个Region对应一个Table表的部分数据
  • HBase集群只有一张meta表,此表只有一个region,该region数据保存在一个HRegionServer上
  • meta表中存储了所有用户表的region信息,我们可以通过scan 'hbase:meta'来查看meta表信息

3、HBase存储数据结构

  • rowkey行键 – Column-Family列族 – Column列 – cell单元格 – Timestamp时间戳
  • 一个HRegionServer管理多个region ,一个region包含很多个store,一个列族就划分成一个store,一个store里面有一个memstore和多个StoreFile, 最后数据是以很多个HFile这种数据结构的文件保存在HDFS上。
  • cell中的数据是没有类型的,全部是以字节数组进行存储;可以对表中的Cell多次赋值,每次赋值操作时的时间戳,可看成Cell值的版本号,
  • HBase上Regionserver的内存分为两个部分
  • 一部分作为Memstore,主要用来写;
  • 另外一部分作为BlockCache,主要用于读数据;
  • -创建
  • create 'user', 'info', 'data'
  • create 'user', {NAME => 'info', VERSIONS => '3'},{NAME => 'data'}
  • --赋值
  • put 'user', 'rk0001', 'info:name', 'zhangsan'
  • --查询--get
  • get 'user', 'rk0001'
  • get 'user', 'rk0001', 'info:name', 'info:age'
  • scan 'user', {COLUMNS => 'info', RAW => true, VERSIONS => 5}

4、Hbase读写数据

  • 1、客户端首先与zk进行连接,从zk找到包含meta表的HRegionServer,连接此包含HRegionServer,读取meta表中的数据;
  • 2、根据要查询信息,先找到数据对应的region信息,在找到这个region对应的regionServer,然后发送请求
  • 3、查找并定位到对应的region,
  • 4、先从memstore查找数据—如果没有从BlockCache上读取----如果也没有再到StoreFile上进行读取。
  • 5、从storeFile中读取到数据之后,不是直接把结果数据返回给客户端,而是把数据先写入到BlockCache中,目的是为了加快后续的查询;然后在返回结果给客户端。

Hbase写数据

  • 1、客户端首先与zk进行连接,从zk找到zk找到meta表的region位置,即包含meta表的HRegionServer,连接此包含HRegionServer,读取meta表中的数据;
  • 2、根据要查询信息,先找到数据对应的region信息,在找到这个region对应的regionServer,然后发送请求
  • 3、查找并定位到对应的region,
  • 4、写数据时,把数据分别写到HLog 和memstore各一份进行缓冲,
  • 5、flush:memstore达到阈值后,把数据刷到磁盘生成多个storeFile文件。
  • Region中任意一个memstore达到128MB
  • Region中所有Memstore的大小总和达到block.multiplier * flush.size
  • Region Server中HLog数量达到上限
  • 6、compact:
  • 小合并:小的store file合并成相对较大的store file,
  • 大合并:合并Store中所有的HFile为一个HFile
     

5、rowkey设计 (三原则)

长度原则、散列原则、唯一原则

1)rowkey长度原则,建议尽可能短,但是也不能太短

2)rowkey散列原则,将rowkey的高位作为散列字段,
3) rowkey唯一原则,rowkey是按照字典顺序排序存储的

 

6、HBase协处理器

HBase 在 0.92 之后,引入了协处理器(coprocessors),能够轻易建立二次索引、复杂过滤器(谓词下推) 以及 访问控制等。

协处理器有两种:Observer协处理器 endpoint协处理器

HBase二级索引:Phoenix+hbase方案