- 1. 在 NameNode HA 中,会出现脑裂问题吗?怎么解决脑裂
- 2.小文件过多有什么危害,如何避免
- 3.请说下HDFS的组织架构
假设NameNode1 当前为Action状态,NameNode2为Standby状态。如果某一时刻NameNode1对应的ZKFailoverController进程发生了"假死"现象,那么Zookeeper服务端会认为NameNode1挂掉了,根据前面的主备切换逻辑,NameNode2会代替NameNode1进入Active状态,但是此时NameNode1可能仍然处于Active状态正常运行,这样NameNode1和NameNode2都处于Active状态,都可以对提供服务。这种情况称为脑裂
脑裂对于NameNode这类对数据一致性要求非常高的系统来说是灾难性的,数据会发生错乱且无法恢复。Zookeepr社区对这种问题的解决方法叫做fencing,中文翻译为隔离,也就是想办法把旧的Active NameNode 隔离起来,使它不能正常对外提供服务。
在进行fencing的时候,会执行以下的 *** 作:
1)首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的transitionToStandby 方法,看能不能把它转换为Standby状态。
2) 如果transitionToStandby 方法调用失败,那么就执行Hadoop配置文件中预定义的隔离措施,Hadoop目前主要提供两个隔离措施,通常会选择sshfence:
1)sshfence:通过SSH登录到目标机器上,执行命令fuser将对应的进程杀死
2)shellfence:执行一个用户自定义的shell脚本来将对应的进程隔离
Hadoop上大量HDFS元数据信息存储在NameNode内存中,因此过多的小文件必定会压垮NameNode的内存
每个元数据对象约占150byte,所以如果有1千万个小文件,每个文件占用一个block,则NameNode大约需要2G空间。如果存储1亿个文件,则NameNode需要20G空间
显而易见的解决这个问题的方法就是合并小文件,可以选择在客户端上传时执行一定的策略先合并,或者是使用Hadoop的CombineFileinputFormat
1)Client:客户端
(1)切分文件。文件上传HDFS的时候,Client将文件切分成一个一个的Block,然后进行存储
(2)与NameNode交互,获取文件的位置信息
(3)与DataNode交互,读取或者写入数据
(4)Client提供一些命令来管理HDFS,比如启动关闭HDFS,访问HDFS目录及内容
2)NameNode:名称节点,也称主节点,存储数据的元数据信息,不存储具体的数据
(1) 管理HDFS的名称
(2) 管理数据块(Block)映射信息
(3) 配置副本策略
(4) 处理客户端读写请求
3)DataNode:数据节点,也称从节点。NameNode下达命令,DataNode执行实际的 *** 作
(1)存储实际的数据块
(2)执行数据块的读/写 *** 作
4)Secondary NameNode:并非NameNode的热备。当NameNode挂掉的时候,它并不能马上替换NameNode并提供服务
(1)辅助NameNode,分担其工作量
(2)定期合并Fsimage和Edits,并推送给NameNode
(3)在紧急情况下,可辅助恢复NameNode
寄语:小伙伴们写到此篇的时候,我已经找到实习工作,回望这一路的努力,印证了努力是有回报的,只是早来晚来的区别,所以如果你坚定的决定做好这个事情,希望大家不要中途放弃,也许你离找到自己理想的工作就差一步,其次活到老,学到老,所以之后我也继续写面试题的,希望大家都能找到自己理想的工作,加油。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)