大数据

hdfs的设计理念

硬件故障是常态而非例外。HDFS实例可能包含数百或数千台服务器计算机，每台计算机都存储文件系统数据的一部分。事实上，存在大量组件并且每个组件具有非平凡的故障概率意味着HDFS的某些组件始终不起作用。

因此，检测故障并从中快速自动恢复是HDFS的核心架构目标。

 

在HDFS上运行的应用程序需要对其数据集进行流式访问。

它们不是通常在通用文件系统上运行的通用应用程序。HDFS设计用于批处理而不是用户的交互式使用。

重点是数据访问的高吞吐量而不是数据访问的低延迟。

POSIX强加了许多针对HDFS的应用程序不需要的硬性要求。

交易几个关键领域的POSIX语义以提高数据吞吐率。

 

在HDFS上运行的应用程序具有大型数据集。HDFS中的典型文件大小为千兆字节到太字节。

因此，HDFS被调整为支持大文件。它应该提供高聚合数据带宽并扩展到单个集群中的数百个节点。

它应该在单个实例中支持数千万个文件。

 

HDFS应用程序需要一个一次写入多次读取的文件访问模型。

除了追加和截断之外，无需更改创建，写入和关闭的文件。支持将内容附加到文件末尾，但无法在任意点更新。该假设简化了数据一致性问题并实现了高吞吐量数据访问。

MapReduce应用程序或Web爬虫应用程序完全适合此模型。

 

应用程序请求的计算如果在其操作的数据附近执行则更有效。

当数据集的大小很大时尤其如此。这可以最大限度地减少网络拥塞并提高系统的整体吞吐量。

假设通常更好的是将计算迁移到更靠近数据所在的位置，而不是将数据移动到运行应用程序的位置。

HDFS为应用程序提供了接口，使其自身更靠近数据所在的位置。

数据块

存储在hdfs中的最小单位

默认大小128M

这么大的原因：

为了最小化寻址开销，一般寻址时间为10ms，传输速率为100MB/s

为了寻址时间占传输时间的1%，所以。。。。

10.13

元数据：

查看fsimage

整个文件系统命名空间（包括块到文件和文件系统属性的映射）

hdfs oiv -i 要查看的文件名 -o输出的文件名 -p XML

查看edites

文件系统元数据发生的每个更改

hdfs oev -i 要查看的文件名 -o输出的文件名

 

namenode启动过程

加载fsimage

加载edites

进行检查点保存

等待datanode汇报块信息
协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_42721694/article/details/85001434