Linux永久修改日期时间
永久修改时间：
hwclock --show 查看硬件的时间
hwclock --set --date '2020-9-21 10:25:00' 设置硬件时间
hwclock --hctosys 设置系统时间和硬件时间同步
clock -w 保存时钟
HDFS元数据管理机制
元数据三种形式
内存元数据（meta data）
磁盘元数据镜像文件（fsimage）不包含文件块位置的信息
数据操作日志文件（edits）
文件和目录是文件系统的基本元素，HDFS将这些元素抽象成INode
INode对象储存在内存.要保证宕机后数据的正确性,故要储存在磁盘,这个功能是由FSImage(一个桥梁架构在内存元数据与磁盘元数据文件之间)完成的
备份机制
HDFS元数据存储机制
1.在内存中有一份完整的元数据(meta data)
2."准完整"元数据镜像文件（fsimage）存储在namenode工作目录中
3.完整数据 = 准完整数据 + 操作日志文件（edits）
4.当客户端对hdfs进行操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，再更新到meta data
元数据存储流程
1.客户端操作HDFS
2.hdfs将用户的操作日志保存在edits，每份edits有固定大小，达到大小后保存成文件tmp/dfs/name/current/edits_0000000000000000881-0000000000000000882
3.正在记录的未达到固定大小的edits文件，保存为edits_inprogress_0000000000000000892
4.按一定触发条件，会由SecondaryNameNode将所有edits和一个最新的fsimage（第一次需要）下载到SecondaryNameNode本地，并加载到内存进行merge，生成一个新的fsimage这个过程叫checkpoint
5.SecondaryNameNode将新生成的fsimage覆盖到原来的镜像文件
SecondaryNameNode的作用
问题的描述:
edit logs 文件会变的很大，怎么去管理这个文件是一个挑战。
NameNode 重启会花费很长时间，因为有很多改动要合并到 fsimage 文件上。
如果 NameNode 挂掉了，那就丢失了一些改动。因为此时的 fsimage 文件非常旧。
问题的解决:
SecondaryNameNode 就是来帮助解决上述问题的，它的职责是合并 NameNode 的 edit logs 到 fsimage 文件中。
checkpoint机制描述和触发条件
描述:
NameNode和SecondaryNameNode的工作目录存储结构完全相同，所有当NameNode故障需要重新恢复时，可以从SecondaryNameNode的工作目录中将fsimage拷贝到NameNode的工作目录，以恢复NameNode的元数据
Checkpoint 触发条件:
Checkpoint 操作受两个参数控制，可以通过 core-site.xml 进行配置：
<property>
<name> dfs.namenode.checkpoint.period</name>
<value>3600</value>
<description>
两次连续的 checkpoint 之间的时间间隔。默认 1 小时
</description>
</property>
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
<description>
最大的没有执行 checkpoint 事务的数量，满足将强制执行紧急 checkpoint，即使
尚未达到检查点周期。默认设置为 100 万。
</description>
</property>
checkpoint机制步骤
1.NameNode 管理着元数据信息，其中有两类持久化元数据文件：edits 操作日志文件和 fsimage 元数据镜像文件。新的操作日志不会立即与 fsimage 进行合并，也不会刷到 NameNode 的内存中，而是会先写到 edits 中(因为合并需要消耗大量的资源)，操作成功之后更新至内存。
2.有 dfs.namenode.checkpoint.period 和 dfs.namenode.checkpoint.txns 两个配置，只要达到这两个条件任何一个，secondarynamenode 就会执行 checkpoint 的操作。
当触发 checkpoint 操作时，NameNode 会生成一个新的 edits 即上图中的 edits.new 文件，同时 SecondaryNameNode 会将 edits 文件和 fsimage 复制到本地（HTTP GET 方式）。
3.secondarynamenode 将下载下来的 fsimage 载入到内存，然后一条一条地执行 edits 文件中的各项更新操作，使得内存中的 fsimage 保存最新，这个过程就是 edits 和 fsimage文件合并，生成一个新的 fsimage 文件即上图中的 Fsimage.ckpt 文件。
4.secondarynamenode 将新生成的 Fsimage.ckpt 文件复制到 NameNode 节点。在 NameNode 节点的 edits.new 文件和 Fsimage.ckpt 文件会替换掉原来的 edits 文件和 fsimage 文件，至此刚好是一个轮回，即在 NameNode 中又是 edits 和 fsimage 文件。
5.等待下一次 checkpoint 触发 SecondaryNameNode 进行工作，一直这样循环操作。
HDFS不适合的应用类型
低延时的数据访问
大量小文件(文件的元数据（如目录结构，文件block的节点列表，block-node mapping）保存在NameNode的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小。)
多方读写，需要任意的文件修改
数据流(读写流程）
1）客户端传递一个文件Path给FileSystem的open方法
2）DFS采用RPC远程获取文件最开始的几个block的datanode地址。Namenode会根据网络拓扑结构决定返回哪些节点（前提是节点有block副本），如果客户端本身是Datanode并且节点上刚好有block副本，直接从本地读取。
3）客户端使用open方法返回的FSDataInputStream对象读取数据（调用read方法）
4）DFSInputStream（FSDataInputStream实现了改类）连接持有第一个block的、最近的节点，反复调用read方法读取数据
5）第一个block读取完毕之后，寻找下一个block的最佳datanode，读取数据。如果有必要，DFSInputStream会联系Namenode获取下一批Block 的节点信息(存放于内存，不持久化），这些寻址过程对客户端都是不可见的。
https://blog.csdn.net/bingduanlbd/article/details/51914550#t26
在读数据过程中，如果与Datanode的通信发生错误，DFSInputStream对象会尝试从下一个最佳节点读取数据，并且记住该失败节点， 后续Block的读取不会再连接该节点
读取一个Block之后，DFSInputStram会进行检验和验证，如果Block损坏，尝试从其他节点读取数据，并且将损坏的block汇报给Namenode。
客户端连接哪个datanode获取数据，是由namenode来指导的，这样可以支持大量并发的客户端请求，namenode尽可能将流量均匀分布到整个集群。
Block的位置信息是存储在namenode的内存中，因此相应位置请求非常高效，不会成为瓶颈。
