3 HDFS 架构
3.1 前提和设计目标
1. 硬件错误
a) 硬件错误是常态而不是异常。
b) HDFS 可能由成百上千的服务器所构成,单机故障概率的存在意味着总有一部分服务器不工作的。
c) 错误检测和快速自动恢复是 HDFS 最核心架构目标。
2. 流式数据访问
a) 运行在 HDFS 上的应用需要流式访问它们的数据集。
b) HDFS 的设计重点是批处理,而不是交互处理。是高吞吐量而不是低延迟。
c) 为了提高数据的吞吐量,在关键方面修改 POSIX 的语义。
3. 大规模数据集
a) HDFS 上的一个典型文件大小一般都在 G 字节至 T 字节。MB GB TB PB ZB
b) HDFS 支持大文件存储。
c) 单一 HDFS 实例能支撑数以千万计的文件。
4. 简单的一致性模型
a) HDFS 应用遵循“一次写入多次读取”的文件访问模型。
b) 简化了数据一致性问题,并且使高吞吐量的数据访问成为可能。
c) Map/Reduce 应用或者网络爬虫应用都非常适合这个模型。
5. 移动计算比移动数据更划算
a) 降低网络阻塞的影响,提高系统数据的吞吐量。
b) 将计算程序发送到数据所在的主机,比 GB 级别 TB 级别的数据移动更便捷。
6. 异构软硬件平台间的可移植性
a) HDFS 在设计的时候就考虑到平台的可移植性。
b) 这种特性方便了 HDFS 作为大规模数据应用平台的推广。
3.2HDFS 架构 剖析
问题:
100 台服务器,存储空间单个 200GB 20T
5T 文件如何存储?
128MB 一块 128MB*8=1GB 128*8*1024=1TB
5T 数据分成的 128MB 的块数 8192 *5。
清单:
5TB 文件分的块:
元数据:
文件名称:web.log 大小:5TB 创建时间: 权限: 文件所有者: 文件所属的用户组: 文件类型: 文件块列表信息: 0~128*1024*1024 -1:128MB:node1:path,node3:path,node8:path 128*1024*1024~2*128*1024*1024 -1:128MB:node2:path,... 2*128*1024*1024~3*128*1024*1024 -1:128MB:node3:path 0~128*1024*1024 -1:128MB:node1: 0~128*1024*1024 -1:128MB:node1: 0~128*1024*1024 -1:128MB:node1: 0~128*1024*1024 -1:128MB:node1: 0~128*1024*1024 -1:128MB:node1: |