hdfs写入文件的时候能读取这个文件么

如果第三方配置文件不是特别大（几百M以上），则可以使用DistributeCache。

如果第三方配置文件比较大，则需要在MapReduce中实现join来做。

关于 DistributeCache的用法，请搜索“mapreduce DistributeCache”。

关于在MapReduce中实现两个文件的join，请搜索"mapreduce实现join"。

我只能说到这了。

一、es生产集群备份恢复之基于snapshot+hdfs进行数据备份

1、es集群数据备份

任何一个存储数据的软件，都需要定期的备份数据。es replica提供了运行时的高可用保障机制，可以容忍少数节点的故障和部分数据的丢失，但是整体上却不会丢失任何数据，而且不会影响集群运行。但是replica没法进行灾难性的数据保护，比如说机房彻底停电，所有机器全部宕机，等等情况。对于这种灾难性的故障，我们就需要对集群中的数据进行备份了，集群中数据的完整备份。

要备份集群数据，就要使用snapshot api。这个api会将集群当前的状态和数据全部存储到一个外部的共享目录中去，比如NAS，或者hdfs。而且备份过程是非常智能的，第一次会备份全量的数据，但是接下来的snapshot就是备份两次snapshot之间的增量数据了。数据是增量进入es集群或者从es中删除的，那么每次做snapshot备份的时候，也会自动在snapshot备份中增量增加数据或者删除部分数据。因此这就意味着每次增量备份的速度都是非常快的。

如果要使用这个功能，我们需要有一个预先准备好的独立于es之外的共享目录，用来保存我们的snapshot备份数据。es支持多种不同的目录类型：shared filesystem，比如NAS；Amazon S3；hdfs；Azure Cloud。不过对于国内的情况而言，其实NAS应该很少用，一般来说，就用hdfs会比较多一些，跟hadoop这种离线大数据技术栈整合起来使用。

2、创建备份仓库

（1）创建和查询仓库的命令

这里用了shared filesystem作为仓库类型，包括了仓库名称以及仓库类型是fs，还有仓库的地址。这个里面就包含了仓库的一些必要的元数据了。可能还有其他的一些参数可以配置，主要是基于我们的node和网络的性能来配置。max_snapshot_bytes_per_sec，这个参数用于指定数据从es灌入仓库的时候，进行限流，默认是20mb/s。max_restore_bytes_per_sec，这个参数用于指定数据从仓库中恢复到es的时候，进行限流，默认也是20mb/s。假如说网络是非常快速的，那么可以提高这两个参数的值，可以加快每次备份和恢复的速度，比如下面：

创建一个仓库之后，就可以查看这个仓库的信息了：GET /_snapshot/my_backup，或者是查看所有的仓库，GET /_snapshot/_all。可能返回如下的信息：

（2）基于hdfs创建仓库

首先先要在es插件目录安装repository-hdfs的插件：bin/elasticsearch-plugin install repository-hdfs，必须在每个节点上都安装，然后重启整个集群。

在3个hdfs node上，都加入hdfs-sitexml，禁止权限检查，如果要修改这个配置文件，要先在/usr/local/hadoop/sbin，运行/stop-dfssh，停止整个hdfs集群，然后在3个node上，都修改hdfs-sitexml，加入下面的配置，禁止权限的检查

hdfs snapshot/restore plugin是跟最新的hadoop 2x整合起来使用的，目前是hadoop 271。所以如果我们使用的hadoop版本跟这个es hdfs plugin的版本不兼容，那么考虑在hdfs plugin的文件夹里，将hadoop相关jar包都替换成我们自己的hadoop版本对应的jar包。即使hadoop已经在es所在机器上也安装了，但是为了安全考虑，还是应该将hadoop jar包放在hdfs plugin的目录中。

安装好了hdfs plugin之后，就可以创建hdfs仓库了，用如下的命令即可：

（3）验证仓库

在课程演示中，最好都是用root用户去演示，一般来说就够了，因为在不同的公司里，你可能linux用户管理，权限，都不太一样

专门去建一套用户和授权去演示，不太合适

如果一个仓库被创建好之后，我们可以立即去验证一下这个仓库是否可以在所有节点上正常使用。verify参数都可以用来做这个事情，比如下面的命令。这个命令会返回一个node列表，证明那些node都验证过了这个仓库是ok的，可以使用的

先停止整个es集群，然后在3个节点上，都加入下面的配置，然后用elasticsearch账号重启整个es集群

3、对索引进行snapshotting备份

（1）对所有open的索引进行snapshotting备份

一个仓库可以包含多分snapshot，每个snapshot是一部分索引的备份数据，创建一份snapshot备份时，我们要指定要备份的索引。比如下面这行命令：PUT _snapshot/my_hdfs_repository/snapshot_1，这行命令就会将所有open的索引都放入一个叫做snapshot_1的备份，并且放入my_backup仓库中。这个命令会立即返回，然后备份 *** 作会被后台继续进行。如果我们不希望备份 *** 作以后台方式运行，而是希望在前台发送请求时等待备份 *** 作执行完成，那么可以加一个参数即可，比如下面这样：PUT _snapshot/my_backup/snapshot_1wait_for_completion=true。

另一种方式

curl -XPUT ' >

Elasticsearch的副本机制提供了可靠性，可以容忍个别节点丢失而不影响集群的对外服务，但是并不能提供对灾难性故障的保护，所以需要对ES集群数据做一个完整的备份，以便在灾难性故障发生时，能快速恢复数据。ES官方提供了快照/恢复（Snapshot/Restore）的方式，支持的插件包括Azure Repository Plugin、S3 Repository Plugin、Hadoop HDFS Repository Plugin、Google Cloud Storage Respository Plugin，这里我使用Hadoop HDFS Repository插件，将ES中的数据备份到HDFS上。

本文基于Elasticsearch-560、hadoop-260-cdh570，使用的插件及版本是repository-hdfs-560zip，官网地址：

>

HDFS Permissions Guide

HDFS 实现了文件和目录的权限模型，很多跟POSIX模型共享。 每个文件、目录都关联到用户、组。文件、目录对于拥有者、组中的其他用户、其他用户有着不同的权限设置。对于文件，读取需要 r 权限，写入/追加需要 w 权限。对于目录，列出目录内容需要 r 权限，创建、删除文件或目录需要 w 权限，访问目录子项需要 x 权限。

与POSIX模型不同，因为没有可执行文件，所以文件没有 setuid or setgid bits。对于目录，也没有 setuid or setgid bits作为简化。粘滞位 sticky bit 可以被作用于目录，放置除superuser、目录所有者、文件所有者之外的任何用户删除、移动目录内的文件。粘滞位 sticky bit 对于文件不生效。 文件或目录的权限我们称为 mod 。一般来说，mdoe的展示使用Unix风格，比如描述的8进制数使用。当创建一个文件/目录后，它的所有者即为客户端进程的用户，它的组是父目录的组（BSD规则）。

HDFS 还支持POSIX ACLs (Access Control Lists)，给指定用户、组配置更新颗粒度的规则来加强权限管理。ACLs稍后会详细介绍。

每个访问HDFS的客户端进程身份都有两部分组成：用户名，组列表。无论什么时候，HDFS都必须会客户端进程访问的文件或目录foo做权限检查，

如果权限校验失败，客户端 *** 作失败。

自 Hadoop 022 起，Hadoop 支持两种不同的 *** 作模式来判断用户的身份，通过 hadoopsecurityauthentication 属性指定：

不管是哪种模式，用户身份机制都是HDFS的外部机制。HDFS中没有用于创建用户、建立组、处理用户凭据的规定。

一旦username被判定，如上，groups list将由group mapping service 判断，配置在 hadoopsecuritygroupmapping 属性。参见 Hadoop Groups Mapping 获取更多内容。

每次HDFS *** 作都需要用户拥有指定权限（读，写，执行的组合），通过文件的 ownership，group membership or 其他权限进行授权。 一个 *** 作会进行路径多个组件的权限检查，而不仅是最后一个组件。另外，一些 *** 作依赖于路径owner的检查。

所有的 *** 作都需要遍历访问（traversal access）。遍历访问需要对路径上的所有存在的组件拥有执行权限，最终路径组件除外。比如，任一访问 /foo/bar/baz 的 *** 作，调用者需要拥有 /, /foo and /foo/bar 的可执行权限。

[1] 如果调用使用overwrite配置，并且该路径已经存在文件，那么 create *** 作只需要对最终路径组件拥有写权限即可。

[2] 如果设置了 sticky bit ，对父目录写权限的检查 *** 作，同样也会检查ownership。

[3] 调用 setOwner 来改变文件的拥有着需要 HDFS super-user 访问权限。变更组不需要HDFS super-user 访问权限，但是调用者必须是文件的拥有者并且是指定组的成员。

每个文件、目录 *** 作都会将完全路径发送给NameNode，对每个 *** 作都会沿着path进行权限检查。客户端框架隐式的将用户身份与到NameNode的连接关联，减少对现有客户端API的改动的需求。常见一种情况，当某文件的一个 *** 作已经成功完成了，再 *** 作的时候会失败，因为该路径上的文件、目录已经不存在了。举个例子，当客户端第一次开始读取一个文件，它向NameNode发出第一个请求，以发现文件的第一个块的位置。第二个请求查找其他的块可能会失败。另一方面，删除一个文件并不会撤回客户端对该文件的访问，该客户端已经知道该文件的块。通过添加权限，客户端对文件的访问可以在请求之间被撤回。同样，变更权限不会撤回客户端的访问，该客户端已经知道文件的块。

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

新方法：

新文件、目录的mode受umask设置限制，umask设置是配置项。

当使用现有方法 create(path, …) (不带权限参数)，新文件的 mode 是 0666 & ^umask 。

当使用新方法 create(path, permission, …) (带权限参数 P) ，新文件的 mode 是 P & ^umask & 0666 。

当使用现有方法 mkdirs(path) (不带权限参数)创建一个新目录， 新目录的 mode 是 0777 & ^umask 。

当使用新方法 mkdirs(path, permission) (带权限参数 P)， 新目录的 mode 是 P & ^umask & 0777 。

新 *** 作：

谁启动NameNode，谁就是super-user。 super-user可以执行任意 *** 作，权限校验从不失败。HDFS super-user 不必是NameNode 主机上的super-user，也不是说集群内的说有主机都需要有这个super-user。

如果在个人电脑上实验运行HDFS，为方便起见无须任何配置该用户即成为安装的super-user。

另外，管理员还可以通过配置参数标识一个特定组。该组内的成员也是super-users。

默认，web server的身份是一个可配置项。即，NameNode不知道真实用户的身份，但是web server以管理员选定的用户的身份（用户/组）行动。 除非选择的身份匹配super-user，部分命名空间是不可以被web server访问的。

除了传统的POSIX权限模型，HDFS还支持POSIX ACLs (Access Control Lists)。ACLs 对于实现区分用户、组的自然组织层次结构的权限需求非常有用。ACL提供了一个方法，可以给指定用户、组设置不同的权限，而不仅仅是文件的拥有着和所属组。

默认，ACLs的支持是关闭的，并且NameNode不允许创建ACLs。要开启ACLs的支持，在NameNode配置内设置 dfsnamenodeaclsenabled 为 true。

一个ACL由一系列ACL entries组成。每条ACL entry 命名了特定用户/组，并授于/拒绝 读、写、执行 权限。比如：

ACL entries 由 type ，可选的 name 和 permission 组成。为了便于展示，‘:’ 用作分隔符。 在这个范例内，文件的owner有read-write权限，文件的group有read-execute权限，others有读取权限。因此，等同于设置文件的权限为654。

另外，有2个扩展ACL entries给用户 bruce 和组 sales，并全部赋予所有权限。 mask 是一个特殊的ACL entry，过滤给所有命名的user entries 和命名的group entries 以及非命名的group entry的权限。 在范例内， mask 仅有写权限，并且我们可以看到几个ACL entries的有效权限被相应的过滤了。

每个ACL都必要要有一个 mask 。如果在设置ACL的时候用户没有提供 mask ，那么会通过计算来自动插入，计算将被过滤的所有entries的权限的并集。

在拥有ACL的文件上运行 chmod 实际上改变了 mask 的权限。既然 mask 作为过滤器，这有效的约束了所有扩展ACLs的权限，而不仅是变更group entry并且可能会丢失其他扩展ACL entries。

模型还有效区分了 “access ACL” 和 “default ACL” 。

“access ACL” ，定义权限检查期间强制执行的规则； “default ACL” ，定义新子文件或子目录创建期间自动接受的规则。

比如：

只有目录可以拥有默认 ACL。当一个新文件或者子目录创建，它会自动的拷贝父级的默认ACL作为自己的ACL。新子目录还将其作为默认 ACL。这样，当新目录创建时，默认 ACL 会被复制到该文件系统数的任意深度层。

新子级的ACL的确切权限值将由mode参数进行过滤。考虑到默认umask 是 022，则新目录是755，新文件是644。mode参数给unnamed user (file owner), the mask and other过滤过滤拷贝过来的权限值。 使用这个特定范例ACL，并创建一个mod 755的子目录，该mode过滤器对最终结果没有影响。但是，如果我们考虑创建一个mode 644 的文件，mode过滤器会导致新文件的ACL接受unnamed user(file owner)的读写权限，mask的读权限，以及其他的读权限。 该mask意味着named user bruce 和 named group sales 的有效权限是只读。

注意，拷贝发生在创建新文件或子目录的时候。对父级默认ACL的后续修改不会影响存在的子级。

默认 ACL 必须拥有所有必要的ACL entries，包括unnamed user (file owner)， unnamed group (file group) and other entries。当设置默认ACL的时候，如果用户没有指定其中某个entry，那么entries会自动插入，通过拷贝访问ACL相应的权限、如果没有访问ACL则拷贝permission bits来实现。默认ACL必须拥有mask。如上所属，如果没有指定会自动插入一个计算的值。

对拥有ACL的文件，权限的检查算法变更为：

最佳实践依赖传统的权限位来实现大多数权限需求，并定义较少数量的ACL来加强，用一些异常规则来扩充权限位。与只有权限位的文件相比，具有ACL的文件在NameNode中会增加内存开销。

新方法：

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;

参考 File System Shell 文档获取命令的全部内容。

如果是，则使用这里描述的权限系统。如果否，关闭权限检查，但是其他行为不变。从一个参数值切换到其他值不会改变mode、文件或目录的owner or group。无论权限是开还是关， chmod 、 chgrp 、 chown and setfacl 总是会检查权限。 这些功能仅在权限上下文有用，因此不存在向后兼容问题。此外，这允许管理员可靠的设置所有者和权限，在打开常规权限检查前。

web server使用的用户名。设置为super-user允许所有客户端看到任何内容。改为其他未使用的身份允许web客户端仅可以查看"other"权限可见的内容。其他将其他组添加到逗号分隔列表内。

super-users 的组。

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

集群的管理员被配置为ACL。这控制谁可以访问HDFS默认的servlets 等。

设置为true，开启HDFS ACLs (Access Control Lists)的支持。默认，ACLs是关闭的。当ACLs关闭的时候，NameNode拒绝所有设置ACL的企图。

设置为true，开启 POSIX风格的ACL继承。默认开启。当它被启动时，并且create请求来自于兼容客户端，NameNode会从父目录应用默认ACL来创建mode并忽视客户端umask。如果没有默认ACL，它将应用客户端umask。

以上就是关于hdfs写入文件的时候能读取这个文件么全部的内容，包括:hdfs写入文件的时候能读取这个文件么、Hadoop系列之HDFS架构、hadoop MapReduce 读取配置参数等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！