Huawei BigData HCNA

大数据工作内容

  1. 数据获取
  2. 数据存储
  3. 数据分析
  4. 数据挖掘

大数据的4V定义

  1. 巨量化
  2. 多样性
  3. 价值
  4. 速度

分布式

  1. 一个任务分成N个子任务运行。

RAID6

HDFS

高容错

硬件不可靠

支持大文件存储

  1. 与其它文件系统相比,最大的区别在于HDFS无数据的固定(150b),不管多大的文件都是150b,元数据平时加载在内存中运行,因此,当内存值固定。

作业

  1. 写出RAID级别的相关概念和对应的参数比较(创建充许的优劣,利用率)
  2. 写出EC中,N+M和N+M:B的原理
  3. 写出HDFS的特点不少于4个.
  4. 写出HDFS的读写流程

大数据的基础定义:
由于本身大数据是由很多的相关的技术所构成,所以大数据从自身角度上来说,是无法有一个非常严格的定义的。

当人们处理一个数据集所需要消耗的时间超过人们所容忍的范围的时候,那么我们就称该数据集为大数据

大数据的工作内容:
1.数据获取:对于传统的互联网厂商来说,可以通过底层的用户反馈得到数据。对于传统行业可以通过传感器来进行获取。对于个人可以使用python爬虫。
2.数据存储:将获取到的数据存储在本地。存储设备、HDFS、Hbase、Hive。
3.数据分析:对数据进行表象性的分析操作,得到一个基础性的结果。
4.数据挖掘:对数据进行深入的挖掘操作,找到数据与数据,类别与类别,属性与属性之间的深层次的关联。

大数据的4V定义:
1.巨量化:当数据集的大小超过PB级的时候,我们就可以称之为大数据。
2.多样性:来源多样性,数据多样性
3.价值:价值高,价值密度低。
4.速度:速度快。趋近于实时性

scale-up:什么不够加所有,开销大,性能先行拓展
scale-out:什么不够加什么。节约开销,但是仅供一时之需

NAS结构:
NAS的结构主要分成三部分
首先第一部分是存储,存储用于提供共享的容量。
引擎:NAS引擎主要用于接收存储提供的容量,并且 给这一部分的容量赋予文件系统,最终提供对应的文件系统给用户去进行使用通过文件共享的协议CIFS(windows专用)和NFS(其他操作系统使用)。
网络



RAID技术
RAID组状态:
创建:创建RAID组
正常:RAID组 正常工作
降级:当RAID 组 中的硬盘损坏的数目没有超过最大允许损坏的硬盘数的时候,RAID组就进入到了降级的状态、
失效:当RAID组中损坏的硬盘数目超过了所允许的最大失效的盘数的时候,RAID组就失效了,数据无法进行 恢复

RAID 0:无差错控制的条带化阵列,该RAID级别没有提供数据的安全性保护机制,但是由于每个硬盘和条带上所存储的数据都不相同,所以在进行数据写入的时候,其采用的是并发写操作,那么硬盘的数目越多,并发写进程就越多,写的速度就越快、读也是一样的。所以对于 RAID 0来说,其组内的盘越多,读写效率就会越快。但是由于RAID 0并没有提供数据保护机制 ,所以一旦其中任意一块 硬盘出现故障,那么整个RAID组就失效

RAID 1:RAID 1叫做镜像结构的条带化阵列,每个硬盘中存储的数据是一样的。那么在进行写操作的时候,由于组内的每一块硬盘存储的数据都是一样的,所以其写效率和单盘写操作是一样的。进行读操作的时候,由于RAID 1的硬盘区分了主备,所以在进行读操作的时候,只会从主硬盘中读数据,其他硬盘不进行读取,所以读操作的效率就是单盘读操作。所以RAID  1的读写和单盘其实本质没区别。但是 RAID 1可以提供非常安全的数据保护,组内的盘坏到只剩下1块都可以正常读取。

综合总结:RAID0效率高,安全性差,所有的硬盘都用来存储数据,使用率100%。RAID1效率低,安全性好,所有的硬盘只有一块的容量用于存储数据,使用率1/n

由于RAID 0和RAID 1在安全性和效率上各有优劣,所以我们 为了均衡两者 的效果,提出了RAID 3
RAID 3叫做 带奇偶校验码的磁盘阵列。那么RAID3引入了校验盘,通过校验盘存储校验数据,可以保证整体的安全性和效率。RAID 3通过对写入的数据计算校验值来保障整体的数据安全。那么一个分条内,我们会写入数据,然后在校验盘对应的该分条的条带上计算校验数据并且存储在里面。
RAID 3的效率比RAID 0低,但是比RAID 1高,安全性比RAID 0高,但是比RAID 1低。RAID 3最多允许损坏1块硬盘。使用率为n-1/n
在RAID 3中,无论我们更改那一部分的数据,校验盘都会随之改变,所以 校验盘成为了热点盘,负载过重,所以校验盘非常容易损坏。

RAID 5叫做 分布式的奇偶校验磁盘阵列,那么这次就不再有专门的校验盘,而是将校验盘中的条带散布到了各个磁盘中,每个磁盘既存储数据,也存储校验数据。这样做整个阵列的热点就被均匀的散布到了 各个磁盘上。减小了磁盘的损坏率。

RAID 6:RAID 6采用了两块校验盘来进行数据的保护,一块是横向校验盘,一块是斜向校验盘,横向校验盘用于保护数据,斜向校验盘保护横向校验盘和数据,RAID 6最多允许损坏两块硬盘。利用率为n-2/n,最少需要4块盘

EC
1.将写入的文件按照4G大小 切分为chunk
,如果文件的大小不足4G,那么就不切分。
2.将chunk切分为strip,按照16k、32k、128k、256k进行切分。
3.根据用户配置的策略,我们取出N份源条带,通过矩阵计算计算出M份冗余条带,构成一个N+M 份数据的分条,然后讲N+M份数据写入到不同的硬盘或者设备上。

N+M(M冗余数据的份数,或者是最多允许损坏的设备数)式保护:N+M式的保护是高安全性保护 ,其要求分条强制将自身的每个 条带 写入到不同的设备上。所以对于N+M式的保护,如果需要 满足该条件则至少需要N+M个节点。

N+M:B(M冗余数据的份数,或者是最多允许损坏的硬盘数,B最多允许损坏的设备数)


元数据和数据的关系
数据:就是一个文件中的具体的内容
元数据:描述数据的数据,可以片面的理解为数据的属性信息

那么我们在进行相关的数据读写的时候 ,首先我们会查找元数据,通过元数据获取该文件的数据的对应的存储位置和状态信息,之后在存储介质上进行数据的读写操作。

文件系统和数据和元数据的关系
文件系统组织了底层的存储,负责维护数据以及元数据

文件系统就相当于是字典
数据就相当于是字典中的正文
元数据就相当于是字典中的目录


HDFS(Hadoop分布式文件系统)
1.硬件不可靠,HDFS在进行数据保护的时候,是不依托于硬件,硬件的数据保护只作为一个数据保护的辅助手段,HDFS自带了数据保护机制来保护数据的整体完整性和可靠性。
2.支持大文件存储:HDFS和其他的文件系统最大的不同就在于HDFS的元数据是固定大小的,150b,不管多大的文件都可以用150b的元数据进行描述,元数据平时是加载在内存中进行维护的。那么在这种情况下。内存的量是固定的,存的数据文件越大,大数据的支持度就越好。因为不管是大文件还是小文件,其所消耗的元数据开销都是相同的。那么这样做的话,实际上存储大文件会有更大的优势,本身HDFS其实也支持存储小文件,但是只不过支持度没有大文件那么好。
3.支持高吞吐量:HDFS会对数据进行相关的性能提升,如果某个应用其读取的文件量级比较大,那么HDFS会优先给该任务分配相关的处理资源,比如CPU、内存和网络资源等。

HDFS在自身设计了很多的读写进程。在这些进程中,读进程有很多,写进程只有一个。并且这些进程中,写进程的优先级最低

WORM(write once read many)
当一个文件系统应用了WORM模型之后,一个文件写入到文件系统之后,就只能做读操作,而不能做写操作(改写),WORM只支持做新写和追加写。

HDFS架构
1.Client:所谓说Client并不是指用户,而是指一个访问的接口和处理模块,用户向HDFS发送请求的时候,通过调用HDFS-Client的API接口可以访问到HDFS,然后用户将自身的请求下发到Client上,由Client作为代理对用户下发的请求进行执行,在HDFS上进行相关的处理操作,最终向用户反馈执行的结果或者是相关的数据
2.NameNode:元数据节点,用于维护HDFS中的元数据
3.DataNode:用于维护HDFS中的数据

HDFS写入流程
1.用户调用API接口连接HDFS的Client组件,并且将对应的应用下发到HDFS-Client上、
2.Client收到请求之后,首先会通过Distributed File System接口连接到NameNode,之后申请创建元数据,并且做申请写空间的操作。
3.NameNode同意请求,分配写空间,并且创建一个元数据(注意:此处的元数据是一个不完整的元数据)
4.创建完成之后,下一步Client会调用FSDataOutPutStream进程下发数据到DataNode,各个DataNode之间做数据的安全性保护
5.DataNode写完成之后,下一步就会反馈写完成给FSDataOutPutStream,之后被转发到Client上,Client收到之后会首先关闭掉FSDataOutPutStream进程。随后Client会联系NameNode反馈写完成,并且完善相关的元数据。之后反馈给用户写完成。整个写入流程完成。

HDFS读流程:
1.用户调用API接口连接HDFS的Client组件,并且将对应的应用下发到HDFS-Client上、
2.Client调用Distributed FileSystem,连接到NameNode,之后申请读元数据。NameNode收到请求之后反馈对应的元数据给Client
3.Client调用FSInputStream接口连接DataNode,并且下发对应的读请求。
4.DataNode收到之后到对应的存储位置读取出相关的数据,然后通过调用FSInputStream接口,发送给Client
5.Datanode将数据发送完成之后,Client会关闭掉FSInputStream接口,然后将数据反馈给用户,之后任务结束


HDFS高可靠性
HDFS的高可靠性主要是用于保护组件安全性的。在HDFS的HA技术中,有一个典型的原则:底层组件由高层组件保护,高层组件由zookeeper保护。
DataNode保护:DataNode中存储的主要是数据,数据的保护主要是通过周期性的向NameNode上传心跳信息来进行保证的,一旦在周期内NameNode没有收到DataNode的心跳那么NameNode就认为DataNode已经故障,之后会启动故障切换。同时DataNode会周期性的上报自己所维护的数据的信息。为了节约整体信息开销,我们将心跳信息和维护的数据信息合为一个信息发送,其实就相当于,每次DataNode只发送了维护的数据信息,那么NameNode一旦没有收到该信息,就等同于没有收到心跳,一样会认为DataNode故障,所以实际上,DataNode只上传了一个信息,心跳只是一个理论设置的数据包。

NameNode保护:NameNode首先设置了主备,在一个HDFS中,NameNode其实有两个进程,一主一备,平时是主进程在执行相关的服务,当主进程出现故障的时候,备进程就会代替主进程执行任务和服务。备NameNode平时在没有升级为主的时候,还会帮主NameNode去做元数据持久化的操作(日志合并的操作)。所以主备之间需要传递日志信息,主备之间传递日志信息,是通过JN 进程实现的。
那么主备之间的切换需要心跳信息,但是NameNode没有该信息,所以主备NameNode的心跳信息都是通过Zookeeper进行协调的,主备NameNode通过ZKFC进程(zookeeper failover controller)上传自己的心跳到Zookeeper,一旦Zookeeper没有周期性的获取到主NameNode的心跳,则会下发故障切换的命令通过ZKFC到达备NameNode。

数据副本机制:
由于HDFS认为硬件不可靠,所以对于数据的安全性和可靠性都是由HDFS自身软件机制实现的,但是软件机制实现数据的保护本身就没有很多的方法去实现,出于绝对安全的考虑,HDFS采用的就是副本机制来实现相关的安全性保证、所谓副本机制就是指将数据直接复制多份,每个副本都是完全可用的相同的数据,HDFS默认将数据复制3份,那么4份数据就一起保证了数据的绝对安全性,我们也称该副本机制为HDFS3副本。
副本的存放遵循有相关的方法,是根据副本距离来判定的。
我们认为如果一个数据和其副本存储在了一台服务器上,那么他们的距离为0
我们认为如果一个数据和其副本存储在了相同机架的不同服务器上,其距离为2
我们认为如果一个数据和其副本存储在了不同的机架上,其距离为4.

第一份副本要和源数据放在一起,则距离为0
第二份副本随机进行存储,其实也就是指存储在除了源数据所在的服务器以外的任意的服务器上。
第三份副本,如果第二份副本的距离为4,那么第三份副本的距离为2,如果第二份副本的距离为2,那么第三份副本的距离为4


元数据持久化:
1.当Editlog每满64M或者时间到达1h的时候,就启动一次元数据持久化工作。
2.首先第一步备NameNode通知主NameNode开始执行元数据持久化,主NameNode收到信息之后会创建一个新的文件editlog.new文件用于存储最新的元数据操作日志。这么做的目的主要有两个 ,第一个是因为备NameNode读取Editlog的时候会对文件加锁,主无法写入。第二个原因是因为editlog本身记录的就是对元数据的操作,其主要存在的目的就是要在HDFS重启之后做元数据的回滚,而现在我们将editlog中记录的操作和镜像文件做了合并,那么本身editlog就没有意义了。新的editlog中记录的是本次持久化开始,到下一次持久化开始之前的所有的对元数据的操作日志。
3.备NameNode获取旧的editlog和元数据镜像文件。
4.备NameNode将editlog中记录的对元数据的操作合并到fsimage元数据镜像文件中。生成一个文件叫做Fsimage.ckpt(checkpoint)。
5.备NameNode生成完成之后,下一步会将该文件传输到主NameNode,然后使用最新的Fsimage.ckpt将旧的Fsimage文件回滚
6.回滚完成之后元数据镜像被更新,之后旧的Editlog文件直接删除,Editlog.new文件被直接重命名成Editlog。

首頁/2018-06-02 (last edited 2018-06-10 08:40:03 by localhost)