标签：操作日志 大数据集 获取 加载 height 方便 用户 内存数据 等级
分布式文件系统HDFS
需要实现以下的一些目标：
1. 廉价的硬件设备
2. 流数据读写（和传统系统区别的地方，全部的数据一股脑的读取）
3. 大数据集（一个文件可能有时候大到好几个T）
4. 简单的文件模型（获取了批量处理的特性，只能追加，不可以修改）
5. 强大的跨平台特性（java开发的）
HDFS的一些局限性：
1. 不适合低延迟的数据访问（不能满足实时的处理需求）
2. 无法高效存储大量的小文件（小文件目录索引太大会让内存数据变大）
3. 不支持多用户写入及任意修改文件
HDFS块：
块要比普通文件大很多，面向大规模存储，为了减少寻址时候的开销。
优点：
1. 支持大规模文件的存储，将一个大文件切割，放到不同的机器上面
2. 简化系统的设计，块的大小是固定的，方便管理元数据
3. 方便数据的备份
| NameNode | DataNode |
| 存储元数据（数据目录） | 存储文件内容 |
| 元数据保存在内存中 | |
NameNode的数据结构：
FsImage：用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
（文件的复制等级，修改和访问时间，访问权限，块大小，组成文件的块）
EditLog：操作日志文件，记录了所有对文件的创建，删除，重命名等操作
NameNode的启动：
FsImage加载到内存，然后与EditLog合并，得到一个新的FsImage，然后创建一个空的EidtLog。这样做的原因是，FsImage太大，数据的修改会让系统变慢，所以文件的修改操作会在EditLog中执行，这样就快多了。
当EditLog变大怎么办？
SecondaryNameNode！！！！
（1） SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新 的操作写到一个新的edit.new上面，这个操作是瞬间完成的
（2） SecondaryNameNode通过HTTP GET从NameNode上获取FsImage和EditLog文件，下载到本地对应的目录下
（3） 将下载的FsImage载入内存，一条条执行EditLog文件中的更新，这个过程就是FsImage和EditLog的合并操作
（4） SecondaryNameNode执行完（3）之后，通过POST方式将新的FsImage文件发送给NameNode
（5）NameNode替换FsImage，edit.new替换EditLog
DataNode负责具体数据的存储：
每个数据节点的数据保存到本地的linux文件系统当中
标签：操作日志 大数据集 获取 加载 height 方便 用户 内存数据 等级
原文地址：https://www.cnblogs.com/da-peng/p/9085374.html
