过了一段时间没有更新了，这段时间一直在啃hadoop方面的知识，按照之前的计划本来是应该讲linux的命令操作，但是这些涉及的方方面面还是比较深，我们要继续深入了解的话还是需要自己多查阅相关的书籍才能更上一层楼。
HDFS的概念
数据块：
每个磁盘都有默认的数据块大小，这是磁盘进行数据读写的最小单位。
构建于单个磁盘上的文件系统通过磁盘块来管理该文件系统中的块，该文件系统中的块的大小可以是磁盘块的整数倍磁盘块一般是512个字节。
HDFS同样有块的概念，默认位64位，HDFS上的文件也被划分为块大小的多个分块，作为独立的存储单元。
HDFS中小于一个块大小的文件不会占据整个块的空间。
注意点：HDFS的块比磁盘的块大，目的是为了最小化寻址开销，如果块设置的足够大，
从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。因此，传输一个由多个块
组成的文件的时间取决于磁盘的传输速率。如果寻址时间约为10ms，而传输速率为100M/s。
为了使寻址时间仅占传输时间的1%，我们要将块的大小设置为100M，默认的块的大下实际是
64M，但是很多情况下HDFS使用的是128M的块设置。但是块的大小不会被设置的过大MapReduce
中的map任务通常一次只处理一个块中的数据，如果任务数少于集群中的节点数量，作业的运行
速度就会变慢。
对分布式文件系统中的块进行抽象会带来很多好处。1：一个文件的大小可以大于网络
中任意一个磁盘的容量。文件中的所有块并不需要存储在同一个磁盘上，因此他们可以
利用集群上的任意一个磁盘进行存储。实际中：对于整个HDFS集群而言，也可以仅储存
一个文件，该文件的块占满集群中的所有磁盘。
2：使用抽象块而非整个文件作为存储单元，大大简化了存储子系统的设计，简化是
所有系统的目标，但是这对于故障种类繁多的分布式系统来说尤为重要。将存储子系统
控制单元设置为块，可简化存储管理（因为块的大小是固定的，因此计算单个磁盘能储存
多少个块就相对容易）。同时也消除了对元数据的顾虑（块只是数据的一部分，而文件的元数据
，如权限信息，并不需要与块一同储存，这样一来，其他系统就可以单独管理这些元数据）。
块还非常适合用于数据备份进而提高数据容错能力和提高可用性。将每个块复制到少数几个机器
上（默认为3个）。可以确保在块，磁盘，或机器发生故障后数据不丢失。如果发现一个块不可用
，系统会从其他地方读取另一个副本，而过程对用户是透明的。一个因损坏或机器故障而丢失的
块可以从其他候选地点复制到另一台可以正常运行的机器上，以保证复本的数量回到正常水平。
hadoop fsck / -files -blocks 列出文件系统中各个文件由哪些块构成。
namenode和datanode
HDFS集群中有两类节点以管理者-工作者模式运行，即一个namenode和多个datanode。namenode
管理文件系统的命名空间。它维护着文件系统树及整颗树内所有的文件和目录。这些信息以两个
文件形式永久保存在本地磁盘上：命名空间镜像文件和编辑日志文件。namenode也记录着每个文件
中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时
由数据节点重建。
客户端代表用户通过与namenode 和datanode 交互来访问整个文件系统。客户端提供一个
可移植操作系统界面的文件系统接口，因此用户在编程时无需知道namenode和datanode也可实现其功能
datanode是文件系统的工作节点，他们根据需要储存并检索数据块（受客户端或namenode调度），
并定期向namenode发送他们所存储的块的列表。
没有namenode，文件系统将无法使用,事实上，如果运行namenode服务的机器损坏，文件系统
上所有的文件将会丢失，因为我们不知道如何根据datanode的块重建文件。
Hadoop提供了2种机制对namenode实现容错：
1：备份那些组成文件系统元数据持久状态的文件。hadoop可以通过配置使namenode在多个
文件系统上保存元数据的持久状态。这些写操作系统是实时同步的，是原子操作，一般的配置是
，将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统(NFS).
2:运行辅助namenode，但它不能被用作namenode，这个辅助namenode的重要作用是定期通过编辑
日志合并命名空间镜像，以防止编辑日志过大，这个辅助namenode一般在另一台单独的物理计算机上
运行，因为它需要占用大量CPU时间与namenode相同容量的内存在执行合并操作，它会保存合并后的
命名空间镜像的副本，并在namenode发生故障时随时启用。但是辅助namenode保存的状态总是落后
于主节点，所以在主节点全部失效时，难免会丢失一部分数据，在这种情况下，一般把储存在
NFS上的namenode元数据复制到辅助namenode并作为新的主namenode运行。
联邦HDFS
namenode在内存中保存文件系统中每个文件和每个数据块的引用关系，这意味着对于一个拥有
大量文件的超大集群来说，内存将成为限制系统横向发展的瓶颈。在2.x发行版本系列中引入的联邦HDFS
允许系统通过添加namenode实现扩展，其中每个namenode管理文件系统命名空间的一部分，例如
，一个namenode可能管理/user目录下的所有文件，而另一个namenode可能管理/share目录下的
所有文件。
在联邦环境下，每个namenode维护一个命名空间卷，包括命名空间的源数据和在该空间下的文件的所有
数据块的数据池。命名空间卷之间是相互独立的，两者之间并不相互通信，甚至其中一个namenode
失效也不会影响由其他Namenode维护的命名空间的可用性。数据块池不再进行切分，因此集群中的
datanode需要注册到每个namenode，并且存储着来自多个数据块池中的数据块。
要想访问联邦hdfs集群，客户端需要使用客户端挂载数据表将文件路径映射到namenode。该功能
可以通过ViewFileSystem和viewfs：//URI进行配置和管理。
HDFS的高可用性
通过联合使用在多个文件系统中备份namenode的元数据和通过备用namenode
创建监测点能防止数据丢失，但是依旧无法实现文件系统的高可用性。namenode
依旧存在单点失效问题。如果namenode失效，那么所有的客户端——包括
MapReduce作业均无法读写或列文件。因为namenode是唯一存储元数据与文件
到数据块映射的地方。在这一情况下，Hadoop系统无法提供服务直到有新的
namenode上线。
在这样的情况下，要想从一个失效的namenode恢复，系统管理员得启动一个拥有
文件系统元数据副本的新的namenode，并配置datanode和客户端以便使用这个
新的namenode。新的namenode 要满足一下情形才能响应服务：将命名空间的映像
导入内存中。重做编辑日志。接收到足够多的来自datanode的数据块报告并退出
安全模式。对于一个大型并拥有大量文件和数据块的集群,namenode冷启动需要
30分钟，甚至更长时间。
事实上，namenode失效的可能性非常的低，所以实际应用中计划系统失效的时间
就显得尤为重要。
Hadoop在2.x发行版本系列针对上述问题在HDFS中增加了对高可用性的支持。
在这一实现中，配置了活动——备用namenode。当活动namenode失效，备用namenode
就会接管它的任务并开始服务于来自客户端的请求，不会有明显的中断。
实现这一目标：
1：namenode之间需要通过高可用的共享存储编辑日志的共享当备用namenode接管
工作之后，它将通读共享编辑日志直至末尾，以实现与活动namenode的状态同步，并
继续读取由活动namenode写入的新条目。
2：datanode需要同时向两个namenode发送数据块处理报告，因为数据块的映射
信息存储在namenode的内存中，而非磁盘。
3：客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的
在活动namenode失效之后，备用namenode能够快速实现任务接管，因为最新的
状态存储在内存中：包括最新的编辑日志条目和最新的数据块映射信息。实际观察到的
失效时间略长一点，因为系统需要保守确定活动namenode是否真的失效了。
在活动namenode失效且备用Namenode也失效的的情况下，当这类情况发生的概率极低，
管理员依旧可以申明一个备用namenode并实现冷启动。
故障切换和规避
一个称为故障转移控制器的系统中有一个新实体管理着将活动namenode转移为
备用namenode的转换过程，故障转移控制器是可以插拔的，但其最初的实现是
基于Zookeepr的并由此确保有且仅由一个活动namenode。每一个namenode运行着
一个轻量的故障转移控制器，其工作就是监视宿主namenode是否失效（通过一个
简单的心跳机制实现）并在namenode失效时进行故障切换。
管理员也可以手动发起故障转移，例如在进行日常维护时，这称为“平稳故障转移”，
因为故障转移控制器可以组织两个namenode有序切换角色。
但在非平稳转移的情况下，无法确切知道失效namenode是否已经停止运行，例如在
网速非常慢或者网络被分割的情况下，同样也可能激发故障转移，但是先前的活动
namenode也依然运行并且依旧是活动的namenode。高可用实现做了更进一步的优化，
以确保先前活动的Namenode不会执行危害系统并导致系统崩溃的操作——该方法
称为“规避”。系统引入一系列的规避机制，包括杀死namenode进程，收回访问共享
存储目录的权限，通过远程管理命令以屏蔽相应网络端口。诉诸的最后手段是，
先前活动namenode可以通过相当形象的称为STONITH的技术进行规避，该方法主要通过
一个特定的供电单元对相应主机进行断电操作。
客户端的故障切换通过客户端类库实现透明处理，最简单的实现是通过客户端的配置文件
实现故障切换的控制。HDFS URI使用一个逻辑主机名，该主机名映射到一对namenode
地址，客户端类库会访问每一个namenode地址直至处理完成。
命令行接口
HDFS有许多接口，但是命令行是最简单的。
在我们设置伪分布配置时，有两个属性需要进一步解释
1:
fs.default.name 设置为hdfs://localhost/，用于设置Hadoop的默认文件系统
该文件系统是由URI指定的，这里用hdfs URI 来配置HDFS 为Hadoop的默认文件
系统。HDFS的守护程序通过该属性来确定HDFS namenode的主机及端口。这样一来
，HDFS客户端可以通过该属性得知namenode在哪里运行进而连接到它。
2：
dfs.replication 我们设为1，这样一来，HDFS就不会按默认设置将文件系统
块复本设为3.在单独一个datanode上运行时，HDFS无法将块复制到3个datanode上
，所以会持续给出块复本不足的警告。设置这个属性之后，就不会再有问题了。
文件系统的基本操作
输入hadoop fs -help命令获取每个命令的详细帮助文件
hadoop fs：使用面最广，可以操作任何文件系统。
hadoop dfs与hdfs dfs：只能操作HDFS文件系统相关（包括与Local FS间的操作），前者已经Deprecated，一般使用后者。
所以现在一般用 hadoop fs 和 hdfs dfs
1:从本地文件系统将一个文件复制到HDFS
hadoop fs -copyFromLocal input/a.txt
hdfs://localhost/user/chx/a.txt
解释：该命令调用Hadoop文件系统的shell命令fs,后者提供了一系列子命令，在这个例子
中我们执行的是-copyFromLocal。本地文件a.txt被复制到运行在localhost上的
HDFS实例中，路径为/user/chx/a.txt。事实上，我们可以简化命令格式以省略
主机的URI并使用默认设置，即省略 hdfs://localhost 因为该项已在core-site.xml中指定
变成：
hadoop fs -copyFromLocal inout/a.txt /user/chx/a.txt
我们把文件复制回本地文件系统，并检查是否一致
hadoop fs -copyToLocal /user/chx/a.txt
md5 ~/a.txt ~/a.copy.txt
md5键值相同，表面在hdfs中保存完整
---------------------------------------------------------------
这里出现一个问题 输入这个命令时，显示未找到md5这个命令
---------------------------------------------------------------
hadoop fs -ls .
放回结果显示的是 /user/chx/下的文件
第一列显示的是文件模式，第二列显示的是这个文件的备份数，第5列是文件大小，目录为0
---------------------------------------------------------------
这里出现一个问题 dfs.replication 是修改备份数值的，这个在哪里修改
解决：在配置目录的 hdfs-size.xml文件中，如果没有配置，就系统自动默认是3
---------------------------------------------------------------
HDFS 中的文件访问权限
提供三类权限模式：只读（r）,写入权限（w）,可执行权限（x）.
读取文件或列出目录时只要r,写入一个文件或在目录上新建及删除文件或目录
，需要写入权限，对于文件而言，可执行权限可以忽略，因为在hdfs中不能执行文件，
但在访问一个目录的子项时需要该权限。
每个文件和目录都有所属用户，所属组别，及模式。
模式是由所属用户的权限，组内成员的权限及其他用户的权限组成的。
在默认情况下，可以通过正在运行进程的用户名和组名来确定唯一客户端的标识
但客户端是远程的，权限只能供合作团体中的用户使用，而不能在不友好的
环境中保护资源。为了防止用户或自动工具及程序意外修改或删除文件系统的
重要部分，启用权限控制还是很重要的，也是默认的配置在 dfs.permissions属性
如果启用权限检查，就会检查所属用户权限，以确认客户端的用户名与所属用户
是否匹配，另外也将检查所属组别权限，以确认该客户端是否是该用户组成员
这里有一个超级用户（super-user）的概念，超级用户是namenode进程的一个标识
，对于超级用户，系统不会执行任何权限检查。
Hadoop文件系统
Hadoop有一个抽象的文件系统概念，HDFS只是其中的一个实现。Java抽象类
org.apache.hadoop.fs.FileSystem定义了Hadoop中的一个文件系统接口，并且
接口
Hadoop是用Java写的，通过Java API可以调用所有Hadoop文件系统的交互
操作。例如：文件系统的命令解释器就是一个Java应用，它使用Java的FileSystem类
来提供文件系统操作。这些接口通常与HDFS一同使用，因为hadoop中的其他
文件系统一般都有访问基本文件系统的工具。
hangsing宣传栏
网友评论