大数据相关知识点总结汇总
(思维导图在页面最后)
分布式存储HDFS
1. Hadoop的历史
作者dogcutting
Doug Cutting是Lucene、Nutch 、Hadoop等项目的发起人
1.1.Hadoop的三驾马车
-
GFS
-
MapReduce
-
BigTable
1.2.hadoop生态圈
-
hdfs
-
mapreduce
-
yarn
-
common
2.HDFS的存储原理
2.1 各个角色的作用
2.1.1 NameNode
1. 接受客户端的读写请求
2. 管理元数据
-
上传的文件的权限
-
上传文件的属主以及属组
-
上传文件的时间
-
上传文件的block数以及ID号
-
每一个Block的位置信息是由DN在集群启动之时汇报的 不会持久化
-
各个DN位置信息
3、管理DN()
2.1.2 DataNode
-
接受客户端的读请求
-
存储block块
-
向active NN汇报心跳
-
构建pipeline
-
管理本机上block元数据
2.1.3 SNN(SecondaryNameNode)
负责持久化,拉取NN节点上的edits+fsimage文件合并
dits文件存储客户端对HDFS的操作
为什么要用edits来存储操作呢?
使用edits来存储操作是怕某个NN挂掉
合并过程
-
文件拉取之时,在NN节点上回创建edits_new 目的就是为了存储在合并期间对HDFS的操作
-
基于拉来的edits文件重演 产出元数据
-
将重演产出的元数据合并到fsimage中
-
将合并后fsimage推送给NN
-
将edits.new文件的后缀去掉
合并触发机制
-
超过3600s就合并一次
-
edits文件大小超过64M
2.1.4 zkfc
-
监控各自的NN,将监控的情况汇报给ZK集群
-
接受zk的选举结果,确认一下另外一个NN是否真的挂了,将自己监控的NN提升为active状态
2.1.5 journalnode
-
写数据的时候只需要保证半数以上的节点写入成功就可以了
为啥要超过半数?防止出现脑裂问题 网络分区问题 -
最终一致性/弱一致性
-
存储的是edits文件
2.1.6 备用的NN
-
监控journalnode中数据变化,实时更新自己的内存元数据
-
将内存中元数据持久化到fsimage中,然后推送给NN
2.2 备份机制
2.2.1如果是集群外操作,第一个block存储在负载不高的节点上
-
默认128M dfs.blocksize
-
严格按照字节切割,如果存储的是中文,会出现乱码问题
2.2.2如果集群内操作,在本机
2.2.3第二个block在其他机架随机一台节点还是那个
2.2.4第三个block与第二个block同机架的其他节点上
2.3HDFS的读写流程
读流程
- 客户端发送请求
- Namenode返回所有block的位置信息,并将这些信息返回给客户端
- 客户端拿到block的位置信息后调用方法读取block信息
- datanode返回给客户端
写流程
- 客户端发送请求
- namenode根据以上信息算出文件需要切成多少块block,以及block要存放在哪个datanode上,并将这些信息返回给客户端。
- 客户端调用方法首先将其中一个block写在datanode上,每一个block默认都有3个副本,并不是由客户端分别往3个datanode上写3份,而是由已经上传了block的datanode产生新的线程,由这个namenode按照放置副本规则往其它datanode写副本
- 写完后返回给客户端一个信息,然后客户端在将信息反馈给namenode
2.4搭建集群的三种模式
伪分布式 测试环境使用
完全分布式
高可用的完全分布式
-
配置hdfs-site,xnml
-
配置core-site,xml
-
配置slaves从节点hostname
-
先启动所有的journalnode
-
随机格式化一个NameNode
-
将本机的NN启动
-
去备用的NN节点,同步元数据
-
格式化zkfc (先启动zookeeper)
-
关闭所有的节点
-
启动HDFS start-dfs.sh
start-dfs.sh 安全模式
-
NN会将fsimage与edits合并
-
检查各个节点上的block块以及副本是否符合要求 若不符合要求,指挥存储数据丢失的DN做备份
-
检查各个DN的健康情况
start-dfs.sh正常对外提供存储服务
2.5 HDFS优缺点
优点
-
副本机制,所以数据更安全
-
因为是分布式存储,所以适合批处理
-
高可用行
-
元数据持久化
-
禁掉了一些功能,使得集群更加完美
1. 修改
2. 文件一旦上传成功,就不能修改block块的大小
缺点
-
无法毫秒级的读写数据
1. 读写复杂需要找nn请求
2. 形成管道,文件切割block block packet -
不适合存储大量的小文件
1.容易造成元数据过多,NN内存溢出
解决办法
1、将小文件合并成一个大文件
2、联邦机制 -
不能并发写入,但是可以并发的读
3.Java API
准备环境
-
本机配置HADOOP_HOME环境变量
-
替换bin目录
-
修改Windows本机用户名
-
导入hadoop所需jar包
-
安装插件,方便在eclipse中操作hdfs集群
分布式计算MR(待补充)
构建数据仓库的工具Hive(待补充)
分布式内存数据库Redis(待补充)
分布式的集群协调工具Zookeeper(待补充)
列式数据库HBase(待补充)
基于JVM的编程语言Scala(待补充)
分布式的计算Spark(待补充)
机器学习(待补充)
大数据学习思维导图

2249



被折叠的 条评论
为什么被折叠?



