hdfs分级存储
⑴ hdfs等分布式文件系统真的会存储数据吗
HDFS（Hadoop分布式文件系统）是一种分布式文件系统，它主要用于存储大量的数据，并提供高可靠性和高吞吐量的数据访问。因此，HDFS是能够真正存储数据的分布式文件系统。
与传统的文件系统相比，HDFS有如下优点：
容错性：HDFS可以自动修复硬件故障，并保证数据的完整性和安全性。
可配李扩展性：HDFS可以根据数据量的增长而庆卖掘扩展容量，并可以支持数千个节点。
数据并行处理：HDFS可以分割数据块并并行处理，提高数据处理速度。
总之，HDFS是真正的分布式文件系统，可以用于存储大量的数据，誉核并提供高性能的数据访问。
⑵ Hadoop系列之HDFS架构
本篇文章翻译了Hadoop系列下的 HDFS Architecture ，原文最初经过笔者翻译后大概有6000字，之后笔者对内容进行了精简化压缩，从而使笔者自己和其他读者们阅读本文时能够更加高效快速的完成对Hadoop的学习或复习。本文主要介绍了Hadoop的整体架构，包括但不限于节点概念、命名空间、数据容错机制、数据管理方式、简单的脚本命令和垃圾回收概念。
PS：笔者新手一枚，如果看出哪里存在问题，欢迎下方留言！
Hadoop Distributed File System（HDFS）是高容错、高吞吐量、用于处理海量数据的分布式文件系统。
HDFS一般由成百上千的机器组成，每个机器存储整个数据集的一部分数据，机器故障的快速发现与恢复是HDFS的核心目标。
HDFS对接口的核心目标是高吞吐量而非低延迟。
HDFS支持海量数据集合，一个集群一般能够支持千万以上数量级的文件。
HDFS应用需要对文件写一次读多次的接口模型，文件变更只支持尾部添加和截断。
HDFS的海量数据与一致性接口特点，使得迁移计算以适应文件内容要比迁移数据从而支持计算更加高效。
HDFS支持跨平台使用。
HDFS使用主从架构。一个HDFS集群由一个NameNode、一个主服务器（用于管理系统命名空间和控制客户端文件接口）、大量的DataNode（一般一个节点一个，用于管理该节点数据存储）。HDFS对外暴露了文件系统命名空间并允许在文件中存储用户数据。一个文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行文件系统命名空间的打开关闭重命名等命令并记录着块和DataNode之间的映射。DataNode用于处理客户端的读写请求和块的相关操作。NameNode和DataNode一般运行在GNU/Linux操作系统上，HDFS使用Java语言开发的，因此NameNode和DataNode可以运行在任何支持Java的机器上，再加上Java语言的高度可移植性，使得HDFS可以发布在各种各样的机器上。一个HDFS集群中运行一个NameNode，其他机器每个运行一个（也可以多个，非常少见）DataNode。NameNode简化了系统的架构，只用于存储所有HDFS元数据，用户数据不会进入该节点。下图为HDFS架构图：
HDFS支持传统的分层文件管理，用户或者应用能够在目录下创建目录或者文件。文件系统命名空间和其他文件系统是相似的，支持创建、删除、移动和重命名文件。HDFS支持用户数量限制和访问权限控制，不支持软硬链接，用户可以自己实现软硬链接。NameNode控制该命名空间，命名空间任何变动几乎都要记录到NameNode中。应用可以在HDFS中对文件声明复制次数，这个次数叫做复制系数，会被记录到NameNode中。
HDFS将每个文件存储为一个或多个块，并为文件设置了块的大小和复制系数从而支持文件容错。一个文件所有的块（除了最后一个块）大小相同，后来支持了可变长度的块。复制系数在创建文件时赋值，后续可以更改。文件在任何时候只能有一个writer。NameNode负责块复制，它周期性收到每个数据节点的心跳和块报告，心跳表示数据节点的正常运作，块报告包含了这个DataNode的所有块。
副本存储方案对于HDFS的稳定性和性能至关重要。为了提升数据可靠性、灵活性和充分利用网络带宽，HDFS引入了机架感知的副本存储策略，该策略只是副本存储策略的第一步，为后续优化打下基础。大型HDFS集群一般运行于横跨许多支架的计算机集群中，一般情况下同一支架中两个节点数据传输快于不同支架。一种简单的方法是将副本存放在单独的机架上，从而防止丢失数据并提高带宽，但是增加了数据写入的负担。一般情况下，复制系数是3，HDFS存储策略是将第一份副本存储到本地机器或者同一机架下一个随机DataNode，另外两份副本存储到同一个远程机架的不同DataNode。NameNode不允许同一DataNode存储相同副本多次。在机架感知的策略基础上，后续支持了 存储类型和机架感知相结合的策略 ，简单来说就是在机架感知基础上判断DataNode是否支持该类型的文件，不支持则寻找下一个。
HDFS读取数据使用就近原则，首先寻找相同机架上是否存在副本，其次本地数据中心，最后远程数据中心。
启动时，NameNode进入安全模式，该模式下不会发生数据块复制，NameNode接收来自DataNode的心跳和块报告，每个块都有一个最小副本数量n，数据块在NameNode接受到该块n次后，认为这个数据块完成安全复制。当完成安全复制的数据块比例达到一个可配的百分比值并再过30s后，NameNode退出安全模式，最后判断是否仍然存在未达到最小复制次数的数据块，并对这些块进行复制操作。
NameNode使用名为EditLog的事务日志持续记录文件系统元数据的每一次改动（如创建文件、改变复制系数），使用名为FsImage的文件存储全部的文件系统命名空间（包括块到文件的映射关系和文件系统的相关属性），EditLog和FsImage都存储在NameNode本地文件系统中。NameNode在内存中保存着元数据和块映射的快照，当NameNode启动后或者某个配置项达到阈值时，会从磁盘中读取EditLog和FsImage，通过EditLog新的记录更新内存中的FsImage，再讲新版本的FsImage刷新到磁盘中，然后截断EditLog中已经处理的记录，这个过程就是一个检查点。检查点的目的是确保文件系统通过在内存中使用元数据的快照从而持续的观察元数据的变更并将快照信息存储到磁盘FsImage中。检查点通过下面两个配置参数出发，时间周期（dfs.namenode.checkpoint.period）和文件系统事务数量（dfs.namenode.checkpoint.txns），二者同时配置时，满足任意一个条件就会触发检查点。
所有的HDFS网络协议都是基于TCP/IP的，客户端建立一个到NameNode机器的可配置的TCP端口，用于二者之间的交互。DataNode使用DataNode协议和NameNode交互，RPC包装了客户端协议和DataNode协议，通过设计，NameNode不会发起RPC，只负责响应来自客户端或者DataNode的RPC请求。
HDFS的核心目标是即使在失败或者错误情况下依然能够保证数据可靠性，三种常见失败情况包括NameNode故障、DataNode故障和network partitions。
网络分区可能会导致部分DataNode市区和NameNode的连接，NameNode通过心跳包判断并将失去连接的DataNode标记为挂掉状态，于是所有注册到挂掉DataNode的数据都不可用了，可能会导致部分数据块的复制数量低于了原本配置的复制系数。NameNode不断地追踪哪些需要复制的块并在必要时候进行复制，触发条件包含多种情况：DataNode不可用、复制乱码、硬件磁盘故障或者认为增大负值系数。为了避免DataNode的状态不稳定导致的复制风暴，标记DataNode挂掉的超时时间设置比较长（默认10min），用户可以设置更短的时间间隔来标记DataNode为陈旧状态从而避免在对读写性能要求高的请求上使用这些陈旧节点。
HDFS架构兼容数据各种重新平衡方案，一种方案可以在某个DataNode的空闲空间小于某个阈值时将数据移动到另一个DataNode上；在某个特殊文件突然有高的读取需求时，一种方式是积极创建额外副本并且平衡集群中的其他数据。这些类型的平衡方案暂时还未实现（不太清楚现有方案是什么...）。
存储设备、网络或者软件的问题都可能导致从DataNode获取的数据发生乱码，HDFS客户端实现了对文件内容的校验，客户端在创建文件时，会计算文件中每个块的校验值并存储到命名空间，当客户端取回数据后会使用校验值对每个块进行校验，如果存在问题，客户端就会去另一个DataNode获取这个块的副本。
FsImage和EditLog是HDFS的核心数据结构，他们的错误会导致整个HDFS挂掉，因此，NameNode应该支持时刻维持FsImage和EditLog的多分复制文件，它们的任何改变所有文件应该同步更新。另一个选择是使用 shared storage on NFS 或者 distributed edit log 支持多个NameNode，官方推荐 distributed edit log 。
快照能够存储某一特殊时刻的数据副本，从而支持HDFS在发生错误时会滚到上一个稳定版本。
HDFS的应用场景是大的数据集下，且数据只需要写一次但是要读取一到多次并且支持流速读取数据。一般情况下一个块大小为128MB，因此一个文件被切割成128MB的大块，且每个快可能分布在不同的DataNode。
当客户端在复制系数是3的条件下写数据时，NameNode通过目标选择算法收到副本要写入的DataNode的集合，第1个DataNode开始一部分一部分的获取数据，把每个部分存储到本地并转发给第2个DataNode，第2个DataNode同样的把每个部分存储到本地并转发给第3个DataNode，第3个DataNode将数据存储到本地，这就是管道复制。
HDFS提供了多种访问方式，比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ，而且还支持浏览器直接浏览。通过使用 NFS gateway ，客户端可以在本地文件系统上安装HDFS。
HDFS使用目录和文件的方式管理数据，并提供了叫做 FS shell 的命令行接口，下面有一些简单的命令：
DFSAdmin命令集合用于管理HDFS集群，这些命令只有集群管理员可以使用，下面有一些简单的命令：
正常的HDFS安装都会配置一个web服务，通过可配的TCP端口对外暴露命名空间，从而使得用户可以通过web浏览器查看文件内容。
如果垃圾回收配置打开，通过FS shell移除的文件不会立刻删除，而是会移动到一个垃圾文件专用的目录（/user/<username>/.Trash），类似回收站，只要文件还存在于那个目录下，则随时可以被回复。绝大多数最近删除的文件都被移动到了垃圾目录（/user/<username>/.Trash/Current），并且HDFS每个一段时间在这个目录下创建一个检查点用于删除已经过期的旧的检查点，详情见 expunge command of FS shell 。在垃圾目录中的文件过期后，NameNode会删除这个文件，文件删除会引起这个文件的所有块的空间空闲，需要注意的是在文件被删除之后和HDFS的可用空间变多之间会有一些时间延迟（个人认为是垃圾回收机制占用的时间）。下面是一些简单的理解删除文件的例子：
当文件复制系数减小时，NameNode会选择多余的需要删除的副本，在收到心跳包时将删除信息发送给DataNode。和上面一样，这个删除操作也是需要一些时间后，才能在集群上展现空闲空间的增加。
HDFS Architecture
⑶ 基于HDFS的存储有哪些
在正式介绍HDFS小文件存储方案轿铅祥之前，我们先介绍一下当前HDFS上文件存取的基本流程。
(1) 读文件流程
1）client端发送读文件请求给namenode，如果文件不存在，返回错误信息，否则，将该文件对应的block及其所在datanode位置发送给client
2） client收到文件位置信息后，与不同datanode建立socket连接并行获取数据。
(2) 写文件流程
1） client端发送写文件请求激腊，namenode检查文件是否存在，如果已存在，直接返回错误信息，否则，发送给client一些可用namenode节点
2） client将文件分块，并行存储到不同节点上datanode上，发送完成后，client同时发送信息给namenode和datanode
3） namenode收到的client信息闭搏后，发送确信信息给datanode
4） datanode同时收到namenode和datanode的确认信息后，提交写操作。
⑷ hdfs详解之块、小文件和副本数
1、block：block是物理切块，在文件上传到HDFS文件系统后，对大文件将以每128MB的大小切分若干，存放在不同的DataNode上。例如一个文件130M，那么他会存被切分成2个块，一个块128M，另一个块2M.
1、HDFS 适应场景: 大文件存储，小文件是致命的
2、如果小文件很多的，则有可能将NN(4G=42亿字节)撑爆。例如:1个小文件(阈值<=30M),那么NN节点维护的字节大约250字节。一亿个小文件则是250b * 1亿=250亿.将会把NN节点搜念撑爆。如果世兄困一亿个小文件合并成100万个大文件:250b * 1百万=2亿字节。
3、在生产上一般会:
1）调整小文件阈值
2）合并小文件:
a.数据未落地到hdfs之前合并
b.数据已经落到hdfs，调用spark service服务 。每天调度去合并 （-15天 业务周期）
3）小文件的危害:
a.撑爆NN。
b.影响hive、spark的计算。占用集群计算资源
1、如果是伪分布式，那么副本数只能为一。
2、生成上副本数一般也是官方默认参数尘枝: 3份
如果一个文件130M，副本数为3。那么第一个block128M，有三份。另外一个block2M，也有三份。
题目:
blockSize128M,副本数3份，那么一个文件260M，请问多少块，多少实际存储？
260%128=2....4M 3个块 3个副本=9块
260M 3=780M
⑸ 什么是HDFS硬盘分布式存储
Namenode 是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。
文件操作，NameNode 负责文件元数据的操作，DataNode负责处理文件内容的读写请求，跟文件内容相关的数据流不经过NameNode，只会询问它跟哪个DataNode联系，否则NameNode会成为系统的瓶颈。
副本存放在哪些DataNode上由 NameNode来控制，根据全局情况做出块放置决定，读取文件时NameNode尽量让用户先读取最近的副本，降低带块消耗和读取时延
Namenode 全权管理数据块的复制，它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。
NameNode支持对HDFS中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作。 块存储管理，在整个HDFS集群中有且只有唯一一个处于active状态NameNode节点，该节点负责对这个命名空间（HDFS）进行管理。
1、Name启动的时候首先将fsimage（镜像）载入内存，并执行（replay）编辑日志editlog的的各项操作；
2、一旦在内存中建立文件系统元数据映射，则创建一个新的fsimage文件（这个过程不需SecondaryNameNode） 和一个空的editlog；
3、在安全模式下，各个datanode会向namenode发送块列表的最新情况；
4、此刻namenode运行在安全模式。即NameNode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败)；
5、NameNode开始监听RPC和HTTP请求
解释RPC:RPC（Remote Procere Call Protocol）——远程过程通过协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议；
6、系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中；
7、在系统的正常操作期间，namenode会在内存中保留所有块信息的映射信息。
存储文件，文件被分成block存储在磁盘上，为保证数据安全，文件会有多个副本 namenode和client的指令进行存储或者检索block，并且周期性的向namenode节点报告它存了哪些文件的blo
文件切分成块（默认大小128M），以块为单位，每个块有多个副本存储在不同的机器上，副本数可在文件生成时指定（默认3）
NameNode 是主节点，存储文件的元数据如文件名，文件目录结构，文件属性（生成时间,副本数,文件权限），以及每个文件的块列表以及块所在的DataNode等等
DataNode 在本地文件系统存储文件块数据，以及块数据的校验和。
可以创建、删除、移动或重命名文件，当文件创建、写入和关闭之后不能修改文件内容。
NameNode启动流程
1、Name启动的时候首先将fsimage（镜像）载入内存，并执行（replay）编辑日志editlog的的各项操作；
2、一旦在内存中建立文件系统元数据映射，则创建一个新的fsimage文件（这个过程不需SecondaryNameNode） 和一个空的editlog；
3、在安全模式下，各个datanode会向namenode发送块列表的最新情况；
4、此刻namenode运行在安全模式。即NameNode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败)；
5、NameNode开始监听RPC和HTTP请求
解释RPC:RPC（Remote Procere Call Protocol）——远程过程通过协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议；
6、系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中；
7、在系统的正常操作期间，namenode会在内存中保留所有块信息的映射信息。
HDFS的特点
优点：
1）处理超大文件
这里的超大文件通常是指百MB、数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。
2）流式的访问数据
HDFS的设计建立在更多地响应"一次写入、多次读取"任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。
3）运行于廉价的商用机器集群上
Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。
缺点：
1）不适合低延迟数据访问
如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。
2）无法高效存储大量小文件
因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。
1280M 1个文件 10block*150字节 = 1500 字节 =1.5KB
1280M 12.8M 100个 100个block*150字节 = 15000字节 = 15KB
3）不支持多用户写入及任意修改文件
在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。
四、HDFS文件 读写流程
4.1 读文件流程
（1） 打开分布式文件
调用 分布式文件 DistributedFileSystem.open()方法。
（2） 从 NameNode 获得 DataNode 地址
DistributedFileSystem 使用 RPC 调用 NameNode， NameNode返回存有该副本的 DataNode 地址， DistributedFileSystem 返回一个输入流 FSDataInputStream对象， 该对象封存了输入流DFSInputStream。
（3） 连接到DataNode
调用 输入流 FSDataInputStream 的 read() 方法， 从而输入流DFSInputStream 连接 DataNodes。
（4） 读取DataNode
反复调用 read()方法， 从而将数据从 DataNode 传输到客户端。
（5） 读取另外的DataNode直到完成
到达块的末端时候， 输入流 DFSInputStream 关闭与DataNode 连接，寻找下一个 DataNode。
（6） 完成读取， 关闭连接
即调用输入流 FSDataInputStream.close() 。
4.2 写文件流程
（1） 发送创建文件请求： 调用分布式文件系统DistributedFileSystem.create()方法；
（2） NameNode中创建文件记录： 分布式文件系统DistributedFileSystem 发送 RPC 请求给namenode， namenode 检查权限后创建一条记录， 返回输出流 FSDataOutputStream， 封装了输出流 DFSOutputDtream；
（3） 客户端写入数据： 输出流 DFSOutputDtream 将数据分成一个个的数据包， 并写入内部队列。 DataStreamer 根据 DataNode 列表来要求 namenode 分配适合的新块来存储数据备份。一组DataNode 构成管线(管线的 DataNode 之间使用 Socket 流式通信)
（4） 使用管线传输数据： DataStreamer 将数据包流式传输到管线第一个DataNode， 第一个DataNode 再传到第二个DataNode ,直到完成。
（5） 确认队列： DataNode 收到数据后发送确认， 管线的DataNode所有的确认组成一个确认队列。 所有DataNode 都确认， 管线数据包删除。
（6） 关闭： 客户端对数据量调用close（） 方法。 将剩余所有数据写入DataNode管线， 并联系NameNode且发送文件写入完成信息之前等待确认。
（7） NameNode确认
（8） 故障处理： 若过程中发生故障， 则先关闭管线， 把队列中所有数据包添加回去队列， 确保数据包不漏。 为另一个正常DataNode的当前数据块指定一个新的标识， 并将该标识传送给NameNode, 一遍故障DataNode在恢复后删除上面的不完整数据块. 从管线中删除故障DataNode 并把余下的数据块写入余下正常的DataNode。 NameNode发现复本两不足时， 会在另一个节点创建一个新的复本
⑹ hdfs的特点有哪些
hdfs的特点
一、hdfs的优点
1.支持海量数据的存储：一般来说，HDFS存储的文件可以支持TB和PB级别的数据。
2.检测和快速应对硬件故障：在集群环境中，硬件故障是常见性问题。因为有上千台服务器连在一起，故障率很高，因此故障检测和自动恢复hdfs文件系统的一个设计目标。假设某一个datanode挂掉之后，因为数据是有备份的，还可以从其他节点里找到。namenode通过心跳机制来检测datanode是否还存活。
3.流式数据访问：（HDFS不能做到低延迟的数据访问，但是HDFS的吞吐量大）=》Hadoop适用于处理离线数据，不适合处理实时数据。HDFS的数据处理规模比较大，应用一次需要大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据库。主要的是数据的吞吐量，而不是访问速度。访问速度最终是要受制于网络和磁盘的速度，机器节点再多，也不能突破物理的局限。
4.简化的一致性模型：对于外部使用用户，不需要了解hadoop底层细节，比如文件的切块，文件的存储，节点的管理。一个文件存储在HDFS上后，适合一次写入，多次读取的场景。因为存储在HDFS上的文件都是超大文件，当上传完这个文件到hadoop集群后，会进行文件切块，分发，复制等操作。如果文件被修改，会导致重新触发这个过程，而这个过程耗时是最长的。所以在hadoop里，2.0版本允许数据的追加，单不允许数据的修改。
5.高容错性：数据自动保存多个副本，副本丢失后自动恢复。可构建在廉价的机器上，实现线性扩展。当集群增加新节点之后，namenode也可以感知，将数据分发和备份到相应的节点上。
6.商用硬件：Hadoop并不需要运行在昂贵且高可靠的硬件上。它是设计运行在商用硬件（在各种零售店都能买到的普通硬件）的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS遇到上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。
二、HDFS缺点（局限性）
1、不能做到低延迟数据访问：由于hadoop针对高数据吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟数据访问，不适合hadoop。对于低延迟的访问需求，HBase是更好的选择。
2、不适合大量的小文件存储 ：由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode的内存容量。根据经验，每个文件、目录和数据块的存储信息大约占150字节。因此，如果有一百万个小文件，每个小文件都会占一个数据块，那至少需要300MB内存。如果是上亿级别的，就会超出当前硬件的能力。
3、修改文件：对于上传到HDFS上的文件，不支持修改文件。Hadoop2.0虽然支持了文件的追加功能，但是还是不建议对HDFS上的文件进行修改。因为效率低下。HDFS适合一次写入，然后多次读取的场景。
4、不支持用户的并行写：同一时间内，只能有一个用户执行写操作。
⑺ HDFS架构
HDFS中的文件是以数据块（Block）的形式存储的，默认最基本的存储单位是128 MB（Hadoop 1.x为64 MB）的数据块。也就是说，存储在HDFS中的文件都会被分割成128 MB一块的数据块进行存储，如果文件本身小于一个数据块的大小，则按实际大竖岁答小存储，并不占用整个数据块空间。HDFS的数据块之所以会设置这么大，其目的是减少寻址开销。数据块数量越多，寻址数据块所耗的时间就越多。当然也不会设置过大，MapRece中的Map任务通常一次只处理一个块中的数据，如果任务数太少，作业的运行速度就会比较慢。HDFS的每一个数据块默认都有三个副本，分别存储在不同的DataNode上，以实现容错功能。因此，若数据块的某个副本丢失并不会影响对数据块的访问。数据块大小和副本数量可在配置文件中更改
NameNode是HDFS中存储元数据（文件名称、大小和位置等信息）的地方，它将所有文件和文件夹的元数据保存在一个文件系统目录树中，任何元数据信息的改变，NameNode都会记录。HDFS中的每个文件都被拆分为多个数据块存放，这种文件与数据块的对应关系也存储在文件系统目录树中，由NameNode维护。NameNode还存储数据块到DataNode的映射信息，这种映射信息包括：数据块存放在哪些DataNode上、每个DataNode上保存了哪些数据块。NameNode也会周期性地接收来自集群中DataNode的“心跳”和“块报告”。通过“心跳”与DataNode保持通信，监控DataNode的状态（活着还是宕机），若长时间接收不到“心跳”信息，NameNode会认为DataNode已经宕机，从而做出相应的调整策略。“块报告”包含了DataNode上所有数据块的列表信息。
DataNode是HDFS中真正存储数据的地方。客户端可以向DataNode请求写入或读取数据块，DataNode还在来自NameNode的指令下执行块的创建、删除和复制，并且周期性地向NameNode汇报数据块信息。
NodeSecondaryNameNode用于帮助NameNode管理元数据，从而使NameNode能够快速、高效地工作。它并不是第二个NameNode，仅是NameNode的一个辅助工具。HDFS的元数据信息主要存储于两个文件中：fsimage和edits。fsimage是文件系统映射文件，主余慧要存储文件元数据信息，其中包含文件系统所有目录、文件信息以及数据块的索引；edits是HDFS操作日志文件，HDFS对文件系统的修改日志会存储到该文件中。当NameNode启动时，会从文件fsimage中读取HDFS的状态，雀辩也会对文件fsimage和edits进行合并，得到完整的元数据信息，随后会将新HDFS状态写入fsimage。但是在繁忙的集群中，edits文件会随着时间的推移变得非常大，这就导致NameNode下一次启动的时间会非常长。为了解决这个问题，则产生了SecondaryNameNode，SecondaryNameNode会定期协助NameNode合并fsimage和edits文件，并使edits文件的大小保持在一定的限制内。SecondaryNameNode通常与NameNode在不同的计算机上运行，因为它的内存需求与NameNode相同，这样可以减轻NameNode所在计算机的压力。
⑻ HDFS 系统架构
HDFS Architecture
Hadoop Distributed File System (HDFS) 是设计可以运行于普通商业硬件上的分布式文件系统。它跟现有的分布式文件系统有很多相通的地方，但是区别也是显着的。HDFS具有高度容错性能，被设计运行于低成本硬件上。HDFS可以向应用提供高吞吐带宽，适合于大数据应用。HDFS 放宽了一些 POSIX 的要求，以开启对文件系统数据的流式访问。HDFS 最初是作为Apache Nutch web 搜索引擎项目的基础设施开发的。HDFS 现在是 Apache Hadoop 核心项目的一部分。
HDFS是主从架构。一个HDFS集群包含一个NameNode，一个管理文件系统命名空间和控制客户端访问文件的master server。以及，若干的 DataNodes，通常集群的每个node一个，管理运行DataNode的节点上的存储。HDFS 发布一个文件系统命名空间，并允许用户数据已文件的形式存储在上面。内部，一个文件被分成一个或多个块，存储在一组DataNodes上。NameNode 执行文件系统命名空间操作，比如：打开、关闭、重命名文件或目录。它还确定块到DataNodes的映射。DataNodes 负责向文件系统客户端提供读写服务。DataNodes 根据 NameNode 的指令执行块的创建、删除以及复制。
NameNode 和 DataNode 是设计运行于普通商业机器的软件。这些机器通常运行 GNU/Linux 操作系统。HDFS 是Java 语言编写的；任何支持Java的机器都可以运行NameNode or DataNode 软件。使用高移植性Java语言，意味着HDFS可以部署在很大范围的机器上。一个典型的部署就是一台特定的机器只运行NameNode 软件，而集群内的其他机器运行DataNode 软件的一个实例。这种架构不排除一台机器上运行多个DataNodes ，但是在实际部署中很少见。
单 NameNode 节点的存在大大简化了架构。NameNode 是所有HDFS 元数据的仲裁和仓库。系统设计上，用户数据永远不经过NameNode。
HDFS 支持传统的文件分级组织。用户或应用可以创建目录，并在目录内存储文件。 文件系统命名空间的层次结构跟其他文件系统类似；可以创建、删除、移动、重命名文件。HDFS 支持 user quotas 和 access permissions 。 HDFS 不支持软、硬链接。但是，HDFS 架构不排除实现这些功能。
虽然HDFS遵守 文件系统命名约定 ，一些路径和名称 (比如/.reserved 和.snapshot ) 保留了。比如功能 transparent encryption 和 snapshot 就使用的保留路径。
NameNode 维护文件系统命名空间。任何文件系统命名空间或属性的变化，都会被NameNode记录。 应用可以指定HDFS应维护的文件副本数量。文件副本的数量被称为该文件的复制因子 replication factor 。该信息存储于NameNode。
HDFS 被设计用于在一个大规模集群上跨机器可靠地存储巨大的文件。它以一序列的块的方式存储文件。每个文件都可以配置块尺寸和复制因子。
一个文件除了最后一个块外，其他的块一样大。在 append 和 hsync 添加了可变长度块的支持后，用户可以启动一个新的块，而不用填充最后一个块到配置的块大小。
应用可以指定一个文件的副本数量。复制因子可以在创建的时候指定，也可以以后更改。HDFS的文件只写一次(除了 appends 和 truncates) ，并在任何时候只允许一个 writer 。
NameNode 指定块复制的所有决策。它周期性的从集群的每个DataNodes 接受 Heartbeat 和 Blockreport。Heartbeat 的接受代表 DataNode 工作正常。Blockreport 包含了DataNode上所有块的清单。
副本的位置对HDFS的可靠性和性能至关重要。副本位置的优化是HDFS和其他大多数分布式文件系统的区别。这是一个需要大量调优和经验的特性。Rack-aware 复制策略的目的就是提高数据可靠性，可用性和网络带宽利用率。当前副本位置策略的实现是这个方向的第一步。实施该策略的短期目标是在生产环境验证它，了解其更多的行为，为测试和研究更复杂的策略打下基础。
大型HDFS实例运行在跨多个Rack的集群服务器上。不同rack的两个node通信需要通过交换机。大多数情况下，同一rack内的带宽大于rack之间的带宽。
NameNode 通过在 Hadoop Rack Awareness 内的进程描述 判断DataNode 属于哪个rack id。一个简单但是并非最佳的策略是将副本分布于不同的racks。这可以防止整个机架发生故障时丢失数据，并允许在读取数据时使用多个机架的带宽。该策略在群集中均匀地分布副本，使得组件故障时很容易平衡负载。 但是，该策略会增加写入成本，因为写入操作需要将块传输到多个机架。
一般，复制因子设置为3， HDFS 的分布策略是：如果writer在datanode上则将一个副本放到本地机器， 如果writer不在datanode上则将一个副本放到writer所在机柜的随机datanode 上；另一个副本位于不同机架的node上；最后一个副本位于同一远程机架的不同node上。 该策略减少了机架间的写流量，提升了写性能。机架故障的概率远小于节点故障的概率；此策略不会影响数据可靠性和可用性承诺。但是，在读取数据时，它确实减少了聚合带宽，因为块存储于两个机柜而不是三个机柜内。使用此策略，副本不会均匀的分布于机架上。1/3 副本 位于同一节点， 2/3 副本位于同一机架， 另1/3副本位于其他机架。该策略提升了写性能而不影响数据可靠性和读性能。
如果复制因子大于3，那么第4个及以后的副本则随机放置，只要满足每个机架的副本在(replicas - 1) / racks + 2)之下。
因为 NameNode 不允许 DataNodes 拥有同一个块的多个副本，所以副本的最大数就是DataNodes的数量。
在把对 存储类型和存储策略 的支持添加到 HDFS 后，除了上面介绍的rack awareness外， NameNode 会考虑其他副本排布的策略。NameNode 先基于rack awareness 选择节点，然后检查候选节点有文件关联的策略需要的存储空间。 如果候选节点没有该存储类型， NameNode 会查找其他节点。如果在第一条路径中找不到足够的节点来放置副本，NameNode会在第二条路径中查找具有回滚存储类型的节点。 、
当前，这里描述的默认副本排布策略正在使用中。
为了最小化全局带宽消耗和读取延迟， HDFS 会尝试从最靠近reader的副本响应读取请求。如果在reader节点的同一机架上上存在副本，则该副本有限响应读请求。如果HDFS集群跨多个数据中心，则本地数据中心优先。
启动时，NameNode 会进入一个称为 Safemode 的特殊状态。当NameNode处于Safemode状态时，不会复制数据块。NameNode从DataNodes接收Heartbeat和Blockreport消息。Blockreport包含DataNode托管的数据块列表。每个块都指定了最小副本数。当数据块的最小副本数已与NameNode签入时，该块被认为是安全复制的。在NameNode签入安全复制数据块的已配置百分比（加上额外的30秒）后，NameNode退出Safemode状态。然后，它判断列表内的数据块清单是否少于副本指定的数量。NameNode 然后复制这些块给其他 DataNodes。
HDFS 命名空间由 NameNode 存储。NameNode 使用事务日志 EditLog 来持久化的保存系统元数据的每次变更。比如，在HDFS创建一个新文件，NameNode会在 EditLog 插入一条记录来指示该变更。类似的，变更文件的复制因子也会在 EditLog 插入一条新记录。NameNode 以文件的形式，将 EditLog 保存在本地OS文件系统上。整个文件系统命名空间，包括块到文件的映射、文件系统属性，都存储于名字为 FsImage 的文件内。 FsImage 也以文件的形式，存储在NameNode的本地文件系统上。
NameNode 将包含整个文件系统和块映射的image保存在内存中。当NameNode启动时，或检查点被预先定义的阈值触发时，它会从磁盘读取 FsImage 和 EditLog ，把 EditLog 内的事物应用到内存中的FsImage，再将新版本刷新回磁盘的新 FsImage 。然后会截断旧的 EditLog ，因为它的事物已经应用到了持久化的 FsImage 上。 这个过程称为检查点 checkpoint 。检查点的目的是通过对文件系统元数据进行快照并保存到FsImage，来确保HDFS拥有文件系统元数据的一致性视图。尽管读取 FsImage 是高效的，但是对 FsImage 直接增量修改是不高效的。不是对每次编辑修改 FsImage ，而是将每次编辑保存到 Editlog 。在检查点期间，将 Editlog 的变更应用到 FsImage 。一个检查点可以在固定周期(dfs.namenode.checkpoint.period)(以秒为单位)触发，也可以文件系统事物数量达到某个值(dfs.namenode.checkpoint.txns)的时候触发。
DataNode 在本地文件系统上以文件的形式存储 HDFS data 。DataNode 不知道 HDFS 文件。它将HDFS data 的每个块以独立的文件存储于本地文件系统上。DataNode 不在同一目录创建所有的文件。而是，使用heuristic来确定每个目录的最佳文件数量，并适当的创建子目录。在一个目录创建所有的本地文件是不好的，因为本地文件系统可能不支持单目录的海量文件数量。当DataNode启动的时候，它扫描本地文件系统，生成与本地文件系统一一对应的HDFS数据块列表，然后报告给NameNode。这个报告称为 Blockreport。
所有的HDFS通信协议都在TCP/IP协议栈上。客户端与NameNode指定的端口建立连接。与NameNode以ClientProtocol 通信。DataNodes与NameNode以DataNode Protocol进行通信。远程过程调用(RPC)封装了Client Protocol 和 DataNode Protocol。设计上，NameNode从不启动任何RPCs。相反，它只应答DataNodes or clients发出的RPC请求。
HDFS的主要目标是可靠的存储数据，即使是在故障的情况下。常见故障类型有三种： NameNode failures , DataNode failures 和 network partitions 。
每个DataNode都周期性的向NameNode发送心跳信息。 一个 network partition 可能导致DataNodes子集丢失与NameNode的连接。NameNode会基于心跳信息的缺失来侦测这种情况。NameNode将没有心跳信息的DataNodes标记为 dead ，并不再转发任何IO请求给它们。任何注册到dead DataNode的数据对HDFS将不再可用。DataNode death会导致某些块的复制因子低于它们指定的值。NameNode不断跟踪需要复制的块，并在必要时启动复制。很多因素会导致重新复制：DataNode不可用，副本损坏，DataNode上硬盘故障，复制因子增加。
标记 DataNodes dead 的超时时间保守地设置了较长时间 (默认超过10分钟) 以避免DataNodes状态抖动引起的复制风暴。对于性能敏感的应用，用户可以设置较短的周期来标记DataNodes为过期，读写时避免过期节点。
HDFS 架构支持数据再平衡schemes。如果一个DataNode的空余磁盘空间低于阈值，sheme就会将数据从一个DataNode 移动到另外一个。在某些文件需求突然增长的情况下，sheme可能会在集群内动态的创建额外的副本，并再平衡其他数据。这些类型的数据再平衡schemes还没有实现。
有可能从DataNode获取的数据块，到达的时候损坏了。这种损坏可能是由于存储设备故障、网络故障、软件bug。HDFS客户端软件会HDFS的内容进行校验。当客户端创建HDFS文件的时候，它计算文件每个块的校验值，并以独立的隐藏文件存储在同一HDFS命名空间内。当客户端检索文件时候，它会校验从每个DataNode获取的数据，是否与关联校验文件内的校验值匹配。 如果不匹配，客户端可以从另外拥有副本块的DataNode检索。
FsImage 和 EditLog 是HDFS的核心数据结构。这些文件的损坏将导致HDFS实例异常。 因此，NameNode可以配置为支持多 FsImage 和 EditLog 副本模式。任何对 FsImage or EditLog 的更新都会导致每个 FsImages 和 EditLogs 的同步更新。 FsImage 和 EditLog 的同步更新会导致降低命名空间每秒的事物效率。但是，这种降级是可以接受的，因为HDFS应用是数据密集型，而不是元数据密集型。当NameNode重启的时候，它会选择最新的一致的 FsImage 和 EditLog 。
另外一种提供故障恢复能力的办法是多NameNodes 开启HA，以 shared storage on NFS or distributed edit log (called Journal)的方式。推荐后者。
Snapshots - 快照，支持在特定时刻存储数据的副本。快照功能的一个用法，可以回滚一个故障的HDFS实例到已知工作良好的时候。
HDFS被设计与支持超大的文件。与HDFS适配的软件都是处理大数据的。这些应用都只写一次，但是它们会读取一或多次，并且需要满足流式读速度。HDFS支持文件的 一次写入-多次读取 语义。 HDFS典型的块大小是128 MB.。因此，HDFS文件被分割为128 MB的块，可能的话每个块都位于不同的DataNode上。
当客户端以复制因子3写入HDFS文件时，NameNode以 复制目标选择算法 replication target choosing algorithm 检索DataNodes 列表。该列表包含了承载该数据块副本的DataNodes清单。然后客户端写入到第一个DataNode。第一DataNode逐步接受数据的一部分，将每一部分内容写入到本地仓库，并将该部分数据传输给清单上的第二DataNode。第二DataNode，按顺序接受数据块的每个部分，写入到仓库，然后将该部分数据刷新到第三DataNode。最终，第三DataNode将数据写入到其本地仓库。
因此，DataNode从管道的前一个DataNode获取数据，同时转发到管道的后一个DataNode。因此，数据是以管道的方式从一个DataNode传输到下一个的。
应用访问HDFS有很多方式。原生的，HDFS 提供了 FileSystem Java API 来给应用调用。还提供了 C language wrapper for this Java API 和 REST API 。另外，还支持HTTP浏览器查看HDFS实例的文件。 通过使用 NFS gateway ，HDFS还可以挂载到客户端作为本地文件系统的一部分。
HDFS的用户数据是以文件和目录的形式组织的。它提供了一个命令行接口 FS shell 来提供用户交互。命令的语法类似于其他shell (比如：bash, csh)。如下是一些范例：
FS shell 的目标是向依赖于脚本语言的应用提供与存储数据的交互。
DFSAdmin 命令用于管理HDFS集群。这些命令仅给HDFS管理员使用。如下范例：
如果启用了回收站配置，那么文件被 FS Shell 移除时并不会立即从HDFS删除。HDFS会将其移动到回收站目录(每个用户都有回收站，位于 /user/<username>/.Trash )。只要文件还在回收站内，就可以快速恢复。
最近删除的文件大多数被移动到 current 回收站目录 ( /user/<username>/.Trash/Current )，在配置周期内，HDFS给 current目录内的文件创建检查点 checkpoints (位于 /user/<username>/.Trash/<date> ) ，并删除旧的检查点。参考 expunge command of FS shell 获取更多关于回收站检查点的信息。
在回收站过期后，NameNode从HDFS命名空间删除文件。删除文件会将文件关联的块释放。注意，在用户删除文件和HDFS增加free空间之间，会有一个明显的延迟。
如下范例展示了FS Shell如何删除文件。我们在delete目录下创建两个文件(test1 & test2)
我们删除文件 test1。如下命令显示文件被移动到回收站。
现在我们尝试以skipTrash参数删除文件，该参数将不将文件发送到回收站。文件将会从HDFS完全删除。
我们检查回收站，只有文件test1。
如上，文件test1进了回收站，文件test2被永久删除了。
当缩减文件的复制因子时，NameNode选择可以被删除的多余副本。下一个Heartbeat会通报此信息给DataNode。DataNode然后会删除响应的块，相应的剩余空间会显示在集群内。同样，在setReplication API调用完成和剩余空间在集群显示之间会有一个时间延迟。
Hadoop JavaDoc API .
HDFS source code: http://hadoop.apache.org/version_control.html
⑼ HDFS 上每个数据节点最多能存多少，多大的数据
HDFS 上每个数据节点最多能存多少，多大的数据
HDFS 每数据节点能存储少数据取决于节点硬盘校 于单节点说其存储容量磁盘容量减hdfs-site.xml配置文件dfs.datanode..reserved参数值 于集群说取决于集群所DataNode节点硬盘
-
hadoop的datanode上存储多少数据就是由该datanode的磁盘空间决定的，配置文件中dfs.data.dir参数指定了hdfs数据存放目录（多个目录由逗号分隔）伏余缓缺模，设置好该参数后，这个datanode节点的最大存储空间就由设定目录的空间决定。hadoop各个datanode节点的数据量基本是一致的，可以通过balancer.sh来平衡各个节点的空间利用率。
HDFS 上每个数据节点最多能存储多少数据取决于节点的硬盘大小。
对于单个节点来说，其存储的容量为磁盘容量减去hdfs-site.xml配置文件中dfs.datanode..reserved参数值。
对于集群来说，取决于集群中所有DataNode节点的硬盘大小之和。但是需要注意考虑集群的备份数量，假设备份数量为3，集群总容量为3TB,则实际可以存储1TB的文件。
1.相同Hadoop版本同步数据
hadoop distcp -skipcrheck -update -m 20 hdfs:dchadoop002.dx:8020/user/dc/warehouse/test /user/dc/warehouse/test
2.不同hadoop版本同步数据
hadoop distcp -skipcrheck -update -m 20 hftp:ns1/user/test /user/dc/test
参数:
-m 表示并发数
-skipcrheck 跳过hdfs校验
-update 更新文件
-
solr每个数据节点最多能存多少，多大的数据
单个数据节点并无数据量的限制，整个集群能存多少数毁局据取决于名称节点的内存有多大，所存储的单个文件的大小取决于整个集群所有数据节点的存储容量之和有多大
sqlite最多能存多大的数据量
您好，我来为您解答：
sqlite本身最大支持2TB的数据量。
希望我的回答对你有帮助。