2023.12.12 HDFS的三大机制,数仓的关系,维度建模

白白的wj

已于 2024-05-01 14:00:06 修改

阅读量410

点赞数 7

文章标签： hdfs hadoop 大数据 hive 数据仓库

于 2023-12-13 15:14:08 首次发布

本文链接：https://blog.csdn.net/m0_49956154/article/details/134952546

版权

星型模型:只有一个事实表,只有一个分析的主题, 那一张事实表被多个维度表插着,维度表之间没有任何关联(前期)

雪花模型:只有一个事实表,被多个维度表插着,维度表之间有关联,但这样会特别乱,需要避免

星座模型:有多个事实表,也就意味着有了多个分析的主题,事实表被多个维度插着,条件吻合的情况下事实表之间是可以共享维度表.(中后期)

一.HDFS的架构

1.Client

发请求就是客户端.

文件切分,文件上传HDFS的时候,Client 将文件文件切分成一个一个的Block,然后进行存储,

与NameNode交互,获取文件的位置信息.

与DataNode交互,读取或者写入数据.

Client提供一些命令来管理和访问HDFS,比如启动或者关闭HDFS.

2.NameNode

就是master,他是一个主管,管理者.

处理客户端写入请求.

管理HDFS元数据(文件路径,文件的大小,文件的名字,文件权限,文件切割后的快BLOCK信息)

配置3副本备份策略.

3.DataNode

就是Slave 奴隶. NameNode 下达命令,DataNode执行实际的操作.

存储实际的数据块(block).

执行数据块的读/写操作

定时向namenode汇报block信息.

4.Secondary Namenode

并非NameNode的备份节点.当NameNode挂掉的时候,他并不能马上替换NameNode并提供服务.

只是辅助NameNode,对HDFS元数据进行合并,合并后再交给NameNode.

在紧急情况下,可辅助NameNode部分数据.

二.块和副本

block块:HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件,他将文件拆分成一系列的数据块进行存储,这个数据块被称为block,除了最后一个,所有的数据块都是同样大小的.

block块的大小默认为128M(为了容错,文件的所有block都会有副本,每个文件的数据块大小和副本系数都是可配置的)

副本系数默认3个

三.块副本机制

因为分布式存储会存在文件大小不一,不利于统一管理.

所以设定统一的管理单位,block块,块的统一大小128M,是为了方便统一管理

副本默认3个的原因:为了保证数据的安全性,通过多个副本备份解决,每个block块都有2个备份,每个副本都复制到其他服务器一份,每个块都有两个备份在其他服务器上,保证了数据的安全性.

四.三大机制

副本机制:为了保证数据安全和效率,block块信息存储多个副本,第一副本保存在客户端所在服务器,第二副本保存在和第一副本不同机架服务器上,第三副本保存在和第二副本相同机架不同服务器.

负载均衡机制:namenode为了保证不同的datanode中block块信息大体一致,分配存储任务的时候会优先保存在距离较近并且余量较大的datanode上.

心跳机制:datanode每隔三秒向namenode汇报自己的状态信息,如果某个时刻,datanode连续10次不汇报了,namenode会认为datanode有可能宕机了,namenode每5分钟发送一次确认消息,连续两次都没有收到恢复,就可以确认datanode宕机了.

机架感知机制:如何选择写入副本的datanode?

1.第一个副本选择本地机架,距离近,上传速度快.

2.第二个副本选择远程机架的随机节点,保证数据的可靠性.

3.第三个副本第二个副本所在机架的随机节点,而不是其他机架,是可以同时兼顾可靠性和效率的.

五.edits和fsimage文件

namenode管理元数据:基于edits和fsimaga的配合,完成整个文件系统文件的管理,每次对HDFS的操作,均被edits文件记录,edits达到大小上线后,开启新的edits记录,定期进行edits的合并操作

如果当前没有fsimage文件,则将全部edits合并为第一个fsimage文件

如当前已经存在fsimage文件,将全部edits和已存在的fsimage进行合并,形成新的fsimage

edits编辑文件:记录hdfs的每次操作

fsimage镜像文件:记录某一时间节点前的当前文件系统全部文件的状态和信息.

Seconddary NameNode辅助合并元数据:SecondaryNameNode会定期从namenode拉取数据(edits和fsimage)然后合并完成后提供给NameNode使用.

检查点的两个指标:默认3600秒,1小时 ,还有100w次事务,60秒检查一次,只要有一个达到条件就执行拉取合并

六.内存/文件元数据

namenode和secondarynamenode: 配合完成对元数据的保存

元数据: 内存元数据和文件元数据两种分别在内存和磁盘上

内存元数据: namnode运行过程中产生的元数据会先保存在内存中，再保存到文件元数据中。
内存元数据优缺点: 优点: 因为内存处理数据的速度要比磁盘快。缺点: 内存一断电，数据全部丢失

文件元数据: Edits 编辑日志文件和fsimage 镜像文件
Edits编辑日志文件: 存放的是Hadoop文件系统的所有更改操作（文件创建，删除或修改）的日志，文件系统客户端执行的更改操作首先会被记录到edits文件中
Fsimage镜像文件: 是元数据的一个持久化的检查点，包含Hadoop文件系统中的所有目录和文件元数据信息，但不包含文件块位置的信息。文件块位置信息只存储在内存中，是在 datanode加入集群的时候，namenode询问datanode得到的，并且不间断的更新

fsimage和edits关系: 两个文件都是经过序列化的，只有在NameNode启动的时候才会将fsimage文件中的内容加载到内存中，之后NameNode把增删改查等操作记录同步到edits文件中.使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作，也是最完整的元数据。