hdfs整理

1.hdfs ha架构图梳理

• HA使用active NN, standby NN两个节点解决单点问题。两个NN节点通过JN集群，共享状态，通过ZKFC选举active，监控状态，自动备援。DN会同时向两个NN节点发送心跳。

• 重演:active状态下的nn1把editlog本地写一份,再把数据写到jn,nn2从jn读出来editlog的信息.保证nn1和nn2的元数据信息一致

• zkfc
  ZooKeeperFailoverController, 是Hadoop中通过ZK实现FC功能的一个实用工具。作为一个ZK集群的客户端，用来监控NN的状态信息。 每个运行NN的节点必须要运行一个zkfc
  监控NN的健康状态
  向ZK集群定期发送心跳 ，让自己被选举，当自己被ZK选举为主时，zkfc进程通过rpc调用让nn转换为active状态

• journalnode
  作用是在HA的两个namenode之间保持editlog的共享同步。
  用于active nn,standby nn的同步数据，本身由一组的JN节点组成的集群，奇数，3台(CDH)，是支持Paxos协议。
  保证高可用。

• active nn：
  接收client的rpc请求并处理，同时自己editlog写一份，也向JN的共享存储上的editlog写一份。
  也同时接收DN的block report，block location updates 和 heartbeat

• standby nn:
  同样会接受到从JN的editlog上读取并执行这些log操作，使自己的NN的元数据和activenn的元数据是同步的，
  使用说standby是active nn的一个热备。一旦切换为active状态，就能够立即马上对外提供NN角色的服务。
  也同时接收DN的block report，block location updates 和 heartbeat

• Edits
  日志

• FsImage
  目录

2.yarn ha架构图梳理

• RM:
  a.启动时会通过向ZK的/hadoop-ha目录写一个lock文件，写成功则为active，否则standby。
  standby RM会一直监控lock文件的是否存在，如果不存在就会尝试去创建，争取为active rm。
  b.会接收客户端的任务请求，接收和监控nm的资源的汇报，负责资源的分配与调度，启动和监控 ApplicationMaster（AM）

• NM:
  节点上的资源的管理，启动container 容器 运行task的计算，上报资源，container情况汇报给RM和任务的处理情况汇报给 ApplicationMaster（AM）

• ApplicationMaster（AM）driver :

• nm机器上的container
  单个application(job)的task的管理和调度，并向rm进行资源的申请，
  向nm发出 launch container指令，接收NM的task的处理状态信息。

• RMstatestore:
  a.RM的作业信息存储在ZK的/rmstore下，active RM向这个目录写app信息
  b.当active rm挂了，另外一个standby rm成功转换为active rm后，会从/rmstore目录读取相应的作业信息，
  重新构建作业的内存信息。然后启动内部服务，开始接收NM的心跳，构建集群资源的信息，并接收客户端的提交作业的请求等。

• zkfc不是进程,是线程

3.总结hdfs yarn ha架构区别

1. zkfc

• hdfs中zkfc为进程
• yarn中zkfc为线程

2.从节点

• HDFS中的DataNode 会向两个NameNode同时发送心跳。
• Yarn中NodeManager只会向activeRM上报资源

3.中间件

• hdfs有独立的中间件jn
• yarn的中间件rm state store是在zookeeper中的

hdfs yarn 都是主从架构.幕前幕后
产生区别的原因:hdfs是做存储,yarn是分配资源存储在生产当中更加重要

4.hdfs dfs -ls 结果是哪个目录

[kfk@hadoop102 sbin]$ hdfs dfs -ls
ls: `.': No such file or directory

[kfk@hadoop102 sbin]$ hdfs dfs -ls /
Found 3 items
drwxr-xr-x   - kfk supergroup          0 2019-07-01 18:23 /benchmarks
drwx------   - kfk supergroup          0 2019-08-12 20:29 /tmp
drwxr-xr-x   - kfk supergroup          0 2019-08-12 23:58 /user

[kfk@hadoop102 sbin]$ hdfs dfs -ls hdfs://10.211.55.20:9000/
Found 3 items
drwxr-xr-x   - kfk supergroup          0 2019-07-01 18:23 hdfs://10.211.55.20:9000/benchmarks
drwx------   - kfk supergroup          0 2019-08-12 20:29 hdfs://10.211.55.20:9000/tmp
drwxr-xr-x   - kfk supergroup          0 2019-08-12 23:58 hdfs://10.211.55.20:9000/user

5.双写的理解

• 结果双写
  一部分数据短期数据数(2个月)据存在es上,便于查看.搜索快
  另一部分数据存在hbase,存着所有数据
• 数据同步双写
  双线 A线分配的资源少, B线分配的资源多. 非节假日采用A线,节假日采用B线

6.小文件的理解 什么是小文件，危害，如何避免(产生前，产生后)

• 小文件是指文件size小于HDFS上block大小的文件。这样的文件会给hadoop的扩展性和性能带来严重问题。
  1,在HDFS中，任何block，文件或者目录在内存中均以对象的形式存储，每个对象约占150byte，如果有1000 0000个小文件，每个文件占用一个block，则namenode大约需要2G空间。如果存储1亿个文件，则namenode需要20G空间。这样namenode内存容量严重制约了集群的扩展。
  2,访问大量小文件速度远远小于访问几个大文件。HDFS最初是为流式访问大文件开发的，如果访问大量小文件，需要不断的从一个datanode跳到另一个datanode，严重影响性能。
  3,处理大量小文件速度远远小于处理同等大小的大文件的速度。每一个小文件要占用一个slot，而task启动将耗费大量时间甚至大部分时间都耗费在启动task和释放task上。

7.主从架构的hbase读写经过master进程吗？

没有.

---

8.其他

1.命名空间

nameservice不是进程,只是参数化的配置
挂载着nn1,nn2,读写操作直接操作命名空间的
hdfs://nameservice1/

2.zookeeper

zk: 2n+1 投票选举(谁做active/standby)
<=20节点 : 5台
20~100节点: 7/9/11台
>=100节点: 11台

1.zookeeper有条件的话,可以单独部署在独立的服务器上.因为如果和其他和集群部署在同一台机器上,有可能机器太繁忙,zookeeper太过繁忙,无法切换nn状态.
2.zookeeper不是越多越好.数量越多,选举时间越长,对外提供服务的时间也长,用户体验不好

3.datanode,namenode部署在同一台机器上

数据本地化

4. zookeeper和kafka不是主从架构