Hadoop 2.7.5命令 （1）

概述：

     文件系统（FS）shell包含各种类似shell的命令，可直接与Hadoop分布式文件系统（HDFS）以及Hadoop支持的其他文件系统（如Local FS，HFTP FS，S3 FS等）交互。FS外壳的调用方式如下：

 hadoop fs <args>

    所有FS shell命令都将路径URI作为参数。URI格式是scheme：// authority / path。对于HDFS，scheme是hdfs，而对于本地FS，scheme是文件。该scheme是可选的。如果未指定，则使用在配置中指定的默认方案。像/ parent / child这样的HDFS文件或目录可以被指定为hdfs：// namenodehost / parent / child，或者简单地指定为/ parent / child（假设你的配置被设置为指向hdfs：// namenodehost。

FS shell中的大多数命令都像对应的Unix命令一样。每个命令都会描述差异。错误信息发送到stderr，输出发送到stdout。

如果正在使用HDFS，hdfs dfs  = hadoop fs

appendToFile--文件内容追加

用法：hadoop fs -appendToFile <localsrc> ... <dst>

将单个src或多个srcs从本地文件系统追加到目标文件系统。

也可以从stdin读取输入并追加到目标文件系统。

• hadoop fs -appendToFile localfile /user/hadoop/hadoopfile
• hadoop fs -appendToFile localfile1 localfile2 /user/hadoop/hadoopfile
• hadoop fs -appendToFile localfile hdfs://nn.example.com/hadoop/hadoopfile
• hadoop fs -appendToFile - hdfs://nn.example.com/hadoop/hadoopfile (从标准输入读取输入,CRTL+C退出)。

退出代码：

成功时返回0，错误时返回1。

cat  --文件查询

用法: hadoop fs -cat [-ignoreCrc] URI [URI ...]

将源路径复制到标准输出

操作

• 选项

  • 该-ignoreCrc选项禁用checkshum验证。

  例：

• hadoop fs -cat hdfs://nn1.example.com/file1 hdfs://nn2.example.com/file2
• hadoop fs -cat /user/admin/1.sh      

退出代码：

成功时返回0，错误时返回-1。

 

checksum 校验

用法：hadoop fs -checksum URI

返回文件的校验和信息。

例：

•  hadoop fs -checksum hdfs：//nn1.example.com/file1
• hadoop fs -checksum file：/// etc / hosts

 

chgrp命令

用法：hadoop fs -chgrp [-R] GROUP URI [URI ...]

更改文件的组关联。用户必须是文件的所有者，否则是超级用户。其他信息在 详情：如下

选项

• -R选项将通过目录结构递归地进行更改。

详情：

Hadoop分布式文件系统（HDFS）为许多共享POSIX模型的文件和目录实现权限模型。每个文件和目录都与一个所有者和一个组相关联。文件或目录对作为所有者的用户，作为组成员的其他用户以及所有其他用户具有单独的权限。

对于文件，需要r权限才能读取文件，并且需要w权限才能写入或附加到文件。

对于目录，r权限需要列出目录的内容，需要w权限才能创建或删除文件或目录，并且需要x权限才能访问目录的子目录。

与POSIX模型不同，由于没有可执行文件的概念，因此没有用于文件的setuid或setgid位。对于目录，不存在setuid或setgid位目录作为简化。粘滞位可以设置在目录上，防止除超级用户，目录所有者或文件所有者以外的任何人删除或移动目录中的文件。为文件设置粘滞位不起作用。总而言之，文件或目录的权限是其模式。通常，将使用用于表示和显示模式的Unix习俗，包括在此描述中使用八进制数字。创建文件或目录时，其所有者是客户端进程的用户标识，其组是父目录（BSD规则）的组。

HDFS还提供对POSIX ACL（访问控制列表）的可选支持，以针对特定命名用户或命名组使用更细粒度的规则来扩大文件权限

访问HDFS的每个客户端进程都具有由用户名和组列表组成的两部分标识。每当HDFS必须对客户端进程访问的文件或目录foo执行权限检查时，

• 如果用户名与foo的所有者相匹配，则测试所有者权限;
• 否则，如果foo组与组列表中的任何成员相匹配，则测试组权限;
• 否则，foo的其他权限会被测试。

如果权限检查失败，则客户端操作失败

用户身份

从Hadoop 0.22开始，Hadoop支持两种不同的操作模式来确定由hadoop.security.authentication属性指定的用户身份：

• 简单

  在这种操作模式下，客户端进程的身份由主机操作系统决定。在类Unix系统上，用户名与“whoami”等价。

• Kerberos的

  在Kerberized操作中，客户端进程的身份由其Kerberos凭据决定。例如，在Kerberized环境中，用户可以使用kinit实用程序来获取Kerberos票据授予票据（TGT）并使用klist来确定其当前主体。将Kerberos主体映射到HDFS用户名时，除主节点以外的所有组件都被删除。例如，主体todd/foobar@CORP.COMPANY.COM将充当HDFS上的简单用户名todd。

不管操作模式如何，用户身份机制对于HDFS本身都是外在的。HDFS中没有提供用于创建用户身份，建立组或处理用户凭证的规定。

对文件系统API的更改

如果权限检查失败，所有使用路径参数的方法都会抛出AccessControlException。

新方法：

• public FSDataOutputStream create（Path f，FsPermission权限，boolean覆盖，int bufferSize，短复制，long blockSize，Progressable progress）throws IOException;
• public boolean mkdirs（Path f，FsPermission permission）throws IOException;
• public void setPermission（Path p，FsPermission permission）throws IOException;
• public void setOwner（Path p，String username，String groupname）throws IOException;
• public FileStatus getFileStatus（Path f）throws IOException; 将另外返回与该路径相关联的用户，组和模式。

在umask设置为配置参数时，新文件或目录的模式受到限制。当使用现有的create（path，...）方法（不带permission参数）时，新文件的模式为0666＆^ umask。当使用新的create（path，permission，...）方法（使用权限参数P）时，新文件的模式是P＆^ umask＆0666。当使用现有的mkdirs（path）方法（不带permission参数）创建新目录时，新目录的模式为0777＆^ umask。当使用新的mkdirs（path，permission）方法（带有权限参数P）时，新目录的模式是P＆^ umask＆0777。

对应用程序Shell的更改

新业务：

• chmod [-R]模式文件...

  只有文件的所有者或超级用户才可以更改文件的模式。

• chgrp [-R]组文件...

  调用chgrp的用户必须属于指定的组，并且是文件的所有者，或者是超级用户。

• chown [-R] [所有者] [：[组]]文件...

  文件的所有者只能由超级用户修改。

• ls文件...

• lsr文件...

  输出被重新格式化以显示所有者，组和模式。

超级用户

超级用户是具有与名称节点进程本身相同的身份的用户。松散地说，如果你启动了namenode节点，那么你就是超级用户。超级用户可以做任何事情，因为超级用户的权限检查决不会失败。没有谁是超级用户的一贯概念; 当名称节点启动时，进程标识现在确定谁是超级用户。HDFS超级用户不必是名称节点主机的超级用户，也不一定所有的集群都拥有相同的超级用户。另外，在个人工作站上运行HDFS的实验者，无需任何配置即可成为该安装的超级用户。

另外，管理员使用配置参数来识别一个可分辨的组。如果设置，该组的成员也是超级用户。

Web服务器

默认情况下，Web服务器的身份是一个配置参数。也就是说，name node节点没有真实用户身份的概念，但Web服务器的行为就好像它具有管理员选择的用户的身份（用户和组）。除非所选身份与超级用户相匹配，否则Web服务器可能无法访问部分名称空间。

ACL（访问控制列表）

除了传统的POSIX权限模型外，HDFS还支持POSIX ACL（访问控制列表）。ACL对实现与用户和组的自然组织层次结构不同的权限要求很有用。ACL提供了一种为特定命名用户或命名组（不仅是文件所有者和文件组）设置不同权限的方法。

默认情况下，禁用对ACL的支持，并且NameNode不允许创建ACL。要启用对ACL的支持，请在NameNode配置中将dfs.namenode.acls.enabled设置为true。

ACL由一组ACL条目组成。每个ACL条目都会命名特定的用户或组，并授予或拒绝该特定用户或组的读取，写入和执行权限。例如：

   user :: rw- 
   user：bruce：rwx #effective：r-- 
   group :: rx #effective：r-- 
   group：sales：rwx #effective：r-- 
   mask :: r-- 
   other :: r--

ACL条目由一个类型，一个可选名称和一个权限字符串组成。出于显示目的，'：'用作每个字段之间的分隔符。在本示例ACL中，文件所有者具有读写访问权限，文件组具有读取执行权限，而其他权限具有读取权限。到目前为止，这相当于将文件的权限位设置为654。

此外，有两个扩展ACL条目用于指定用户bruce和指定的组销售，均授予完全访问权限。该掩码是一个特殊的ACL条目，用于过滤授予所有命名用户条目和命名组条目的权限以及未命名的组条​​目。在该示例中，掩码只具有读取权限，我们可以看到几个ACL条目的有效权限已被相应地过滤。

每个ACL都必须有一个掩码。如果用户在设置ACL时不提供掩码，则通过计算将被掩码过滤的所有条目的权限的联合，自动插入掩码。

在具有ACL的文件上运行chmod实际上会更改掩码的权限。由于掩码起到了过滤器的作用，因此这会有效地限制所有扩展ACL项的权限，而不是仅更改组项，并且可能会丢失其他扩展ACL项。

该模型还区分定义在权限检查期间执行的规则的“访问ACL”和定义创建期间新子文件或子目录自动接收的ACL条目的“默认ACL”。例如：

   user :: rwx 
   group :: rx 
   other :: rx 
   default：user :: rwx 
   default：user：bruce：rwx #effective：rx 
   default：group :: rx 
   default：group：sales：rwx #effective：rx 
   default：mask： ：rx 
   默认：other :: rx

只有目录可能有一个默认ACL。创建新文件或子目录时，会自动将其父级的默认ACL复制到其自己的访问ACL中。新的子目录也将其复制到其自己的默认ACL。通过这种方式，当创建新的子目录时，默认ACL将被复制到文件系统树的任意深度级别。

新的子访问ACL中的确切权限值可以通过mode参数进行过滤。考虑到022的默认umask，新目录通常为755，新文件通常为644。mode参数筛选未命名用户（文件所有者），掩码和其他的复制权限值。使用这个特定的示例ACL，并为模式创建一个755的新子目录，此模式过滤对最终结果没有影响。但是，如果我们考虑为该模式创建一个文件为644，那么模式过滤会导致新文件的ACL接收未命名用户（文件所有者）的读写，读取掩码并读取其他文件。此掩码还意味着只读取命名用户bruce和命名组销售的有效权限。

Note that the copy occurs at time of creation of the new file or sub-directory. Subsequent changes to the parent’s default ACL do not change existing children.

请注意，复制发生在创建新文件或子目录时。对父级默认ACL的后续更改不会更改现有的子目录或文件。

默认ACL必须包含所有最低要求的ACL条目，包括未命名用户（文件所有者），未命名组（文件组）和其他条目。如果用户在设置默认ACL时没有提供这些条目中的一个，则通过复制访问ACL中的相应权限或没有访问ACL时的权限位来自动插入条目。默认ACL也必须具有掩码。如上所述，如果未指定掩码，则通过计算将被掩码过滤的所有条目的权限联合，自动插入掩码。

在考虑具有ACL的文件时，权限检查算法将更改为：

• 如果用户名与文件的所有者匹配，则测试所有者权限;

• 否则，如果用户名与其中一个指定的用户条目中的名称相匹配，则会测试这些权限，并按掩码权限进行过滤;

• 否则，如果文件组与组列表中的任何成员相匹配，并且这些权限由掩码授予访问权限过滤，则使用这些权限;

• 否则，如果存在与组列表的成员相匹配的命名组项，并且这些权限由掩码授权访问过滤，则使用这些权限;

• 否则，如果文件组或任何指定的组条目与组列表的成员相匹配，但访问权未被任何这些权限授予，则访问被拒绝;

• 否则，测试文件的其他权限。

最佳实践是依靠传统的权限位来实现大多数权限要求，并定义更少数量的ACL以通过一些特殊规则来扩充权限位。与仅具有权限位的文件相比，使用ACL的文件在NameNode的内存中会产生额外的开销。

ACL文件系统API

新方法：

• public void modifyAclEntries（Path path，List <AclEntry> aclSpec）throws IOException;
• public void removeAclEntries（Path path，List <AclEntry> aclSpec）throws IOException;
• public void public void removeDefaultAcl（Path path）throws IOException;
• public void removeAcl（Path path）throws IOException;
• public void setAcl（Path path，List <AclEntry> aclSpec）throws IOException;
• public AclStatus getAclStatus（Path path）throws IOException;

ACL Shell命令

• hdfs dfs -getfacl [-R] <path>

• 

• 显示文件和目录的访问控制列表（ACL）。如果目录具有默认ACL，则getfacl也会显示默认ACL。

• hdfs dfs -setfacl [-R] [-b | -k -m | -x <acl_spec> <path>] | [ - set <acl_spec> <path>]

  设置文件和目录的访问控制列表（ACL）。

• 

  

• zzq用户对/user/admin有rwx权限，用zzq用户可以创建目录

  创建用户的属主 是zzq

• 如果使用admin用户在/user/admin下创建目录，则对新建的目录zzq用户不会享有acl权限

• 

   可以为某个目录设置一个默认的ACL权限，使得以后在该目录中新建文件或者子目录时，新建的文件/目录的ACL权限都是之前设置的default ACLs。

• 采用default  如：hadoop fs -setfacl -m default:user:zzq:rwx /user/admin
• 

  

  

• hdfs dfs -ls <args>

  ls的输出将向任何具有ACL的文件或目录的权限字符串附加“+”字符。

  有关这些命令的完整介绍，请参阅File System Shell文档。

配置参数

• dfs.permissions.enabled = true

  如果是，请按照此处所述使用权限系统。如果否，则关闭权限检查，但其他所有行为均不变。从一个参数值切换到另一个参数值不会更改模式，所有者或文件或目录组。无论权限是打开还是关闭，chmod，chgrp，chown和setfacl都会检查权限。这些函数仅在权限上下文中有用，因此不存在向后兼容性问题。此外，这允许管理员在开启定期权限检查之前可靠地设置所有者和权限。

• dfs.web.ugi = webuser，webgroup

  Web服务器使用的用户名。将其设置为超级用户的名称可让任何Web客户端查看所有内容。将其更改为其他未使用的身份允许Web客户端仅使用“其他”权限查看那些可见的内容。其他组可能会添加到逗号分隔列表中。

• dfs.permissions.superusergroup = supergroup (默认hdfs)

  超级用户组的名称。

• fs.permissions.umask-mode = 0022  

  创建文件和目录时使用的umask。对于配置文件，可以使用十进制值18。

• dfs.cluster.administrators = ACL-for-admins (默认hdfs)

  群集的管理员指定为ACL。这可以控制谁可以访问HDFS中的默认servlet等。

• dfs.namenode.acls.enabled = true

  设置为true以启用对HDFS ACL（访问控制列表）的支持。默认情况下，ACL被禁用。当禁用ACL时，NameNode会拒绝所有尝试设置ACL。