⑴ HDFS 上的文件支持修改操作吗若支持，如何修改hdfs文件
看来你是开启了hdfs的权限检查功能，这样你访问hdfs，namenode都会检查访问用户的权限的。
你现在想要修改/process/startall.txt文件的权限，那process目录以及startall.txt的有效用户、有效组以及其权限是什么呢？
假设process目录与startall.txt原始的有效用户和有效组分别为root和supergroup，原始权限为750的话，你若在自己电脑运行上述程序，它会自动获取当前计算机的登录用户，假设为wyc,去访问hdfs，很显然，你的程序连process目录都进不去的。
此外，想要更改一个目录或文件的权限，当前用户则必须是有效用户或超级用户才可以。
想要解决的话，嘿嘿， 如果你设置的hadoop.security.authentication property，也就是认证方式为simple的话（默认就是simple），那还可以钻该认证方式的空子，运行程序是伪装成有效用户或者超级用户即可。
此外，有一行代码需要修改一下，我在实验后发现设置权限那一行有误，如下：
//hdfs.setpermission(dstpath, new fspermission((short) 775));
hdfs.setpermission(dstpath, new fspermission("755"));
⑵ HDFS和本地文件系统文件互导
初步了解一下情况，后续根据给出案例
一、从本地文件系统到HDFS
使用hdfs自带的命令
命令：hdfs dfs -FromLocal inputPath outputPath
inputPath：本地文件目录的路径
outputPath：hdfs文件目录路径，即存储路径
二、从HDFS到本地文件系统
命令：hdfs dfs -ToLocal inputPath outputPath
inputPath：hdfs文件目录
outputPath：本地文件文件目录，即本地存储路径
因为Hbas和Hive都在存储在HDFS中，所以可以通过该条命令可以把Hbase和Hive存储在HDFS中的文件复制出来。但是经过实践，通过这种方式复制出来的Hbase文件是乱码。Hive里的文件有时候也会乱码，这取决于Hive数据的插入方式。
三、文件在HDFS内的移动
1、从Hbase表导出数据到HDFS
命令：hbase org.apache.hadoop.hbase.maprece.Export tableName outputPaht
例子：hbase org.apache.hadoop.hbase.maprece.Export test /user/data
test为需要从Hbase中导出的表，／user/data为hdfs上的路径，即存储路径，如果最后一个参数有前缀file：// 则为本地上的文件存储系统
2、从HDFS导入到Hbase表中，需要事先建立好表结构
命令：hbase org.apache.hadoop.hbase.maprece.Export tableName inputPaht
例子：hbase org.apache.hadoop.hbase.maprece.Import test1 /temp/part-m-00000
案列：
两个不同环境数据，数据导入
过程描述：
导出正式环境数据到hdfs中，然后从hdfs中导出到本地，本地传到测试环境主机，然后从本地导入到hdfs中，再从hdfs中导入到hbase中。
处理过程：
1、注意事项：1、权限问题使用hdfs：sudo -u hdfs ；
2、存放上传路径最好不要在root下
3、上传完成后，查看是否在使用，数据已经插入。
1、sudo -u hdfs hbase org.apache.hadoop.hbase.maprece.Export ** /hbase/**_bak （导出到hdfs中的**_bak）
2、hdfs dfs -ToLocal /hbase/sw_bak /test (导出hdfs中文件到本地test，注：提前建好目录)
3、scp -r test_bak [email protected].**:/root/test （传送目录到测试环境主机目录下，注：传到测试环境后，把文件不要放到root的目录下，换家目录下）
4、sudo -u hdfs hdfs dfs -FromLocal /chenzeng/text_bak /data （把sw传到hdfs 中，注意上传时，文件路径要对，放在data路径下比较好）
5、sudo -u hdfs hbase org.apache.hadoop.hbase.maprece.Import test /data/test_bak/part-m-0000 （注意上次文件）
6、在hbase shell 中查看test ：count 'test' 确认是否上传成功
优化：
truncate ‘’
正式环境导入至hdfs中时，
可以直接在另一个环境的执行sudo -u hdfs hbase org.apache.hadoop.hbase.maprece.Import test hdfs://server243:8020/hbase**** 可以直接加主机和对应路径进行put。
⑶ 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文件
当前稳定版本的hdfs(1.1.2)不支持文件的修改操作，要修改文件只能先把文件从hdfs拷贝到本地硬盘，修改后删除hdfs里的文件，上传修改后的文件到hdfs。
⑸ 如何把hdfs上的多个目录下的文件合并为一个文件
hdfs dfs -cat /folderpath/folder* | hdfs dfs -FromLocal - /newfolderpath/file
1
1
这样可以把文件hdfs上 /folderpath目录下的/folder开头的文件，还不合并到/newfolderpath目录下的file一个文件中 注意/folder*必须是文件，而不能是文件夹，如果是文件夹，可以/folder*/*
cat test.txt | ssh test@masternode "hadoop dfs -put - hadoopFoldername/"
1
1
可以这样把本机的文件put到HDFS上面，而不用先复制文件到集群机器上
⑹ HDFS文件
Hadoop支持的文件系统由很多（见下图），HDFS只是其中一种实现。Java抽象类 org.apache.hadoop.fs.FileSystem 定义了Hadoop中一个文件系统的客户端接口，并且该抽象类有几个具体实现。Hadoop一般使用URI（下图）方案来选取合适的文件系统实例进行交互。
特别的，HDFS文件系统的操作可以使用 FsSystem shell 、客户端（http rest api、Java api、C api等）。
FsSystem shell 的用法基本同本地shell类似，命令可参考 FsSystem shell
Hadoop是用Java写的，通过Java Api（ FileSystem 类）可以调用大部分Hadoop文件系统的交互操作。更详细的介绍可参考 hadoop Filesystem 。
非Java开发的应用可以使用由WebHDFS协议提供的HTTP REST API，但是HTTP比原生的Java客户端要慢，所以不到万不得已尽量不要使用HTTP传输特大数据。通过HTTP来访问HDFS有两种方法：
两种如图
在第一种情况中，namenode和datanode内嵌的web服务作为WebHDFS的端节点运行（是否启用WebHDFS可通过dfs.webhdfs.enabled设置，默认为true）。文件元数据在namenode上，文件读写操作首先被发往namenode，有namenode发送一个HTTP重定向至某个客户端，指示以流的方式传输文件数据的目的或源datanode。
第二种方法依靠一个或多个独立代理服务器通过HTTP访问HDFS。所有集群的网络通信都需要通过代理，因此客户端从来不直接访问namenode或datanode。使用代理后可以使用更严格的防火墙策略和带宽策略。
HttpFs代理提供和WebHDFS相同的HTTP接口，这样客户端能够通过webhdfs URI访问接口。HttpFS代理启动独立于namenode和datanode的守护进程，使用httpfs.sh 脚本，默认在一个不同的端口上监听（14000）。
下图描述了
读文件时客户端与 HDFS 中的 namenode， datanode 之间的数据流动。
对上图的解释如下：
在读取过程中， 如果 FSDataInputStream 在和一个 datanode 进行交流时出现了一个错误，他就去试一试下一个最接近的块，他当然也会记住刚才发生错误的 datanode 以至于之后不会再在这个 datanode 上进行没必要的尝试。 DFSInputStream 也会在 datanode 上传输出的数据上核查检查数(checknums).如果损坏的块被发现了， DFSInputStream 就试图从另一个拥有备份的 datanode 中去读取备份块中的数据。
在这个设计中一个重要的方面就是客户端直接从 datanode 上检索数据，并通过 namenode 指导来得到每一个块的最佳 datanode。这种设计允许 HDFS 扩展大量的并发客户端，因为数据传输只是集群上的所有 datanode 展开的。期间，namenode 仅仅只需要服务于获取块位置的请求（块位置信息是存放在内存中，所以效率很高）。如果不这样设计，随着客户端数据量的增长，数据服务就会很快成为一个瓶颈。
我们知道，相对于客户端(之后就是 maprece task 了)，块的位置有以下可能性：
我们认为他们对于客户端的带宽递减，距离递增（括号中表示距离）。示意图如下：
如果集群中的机器都在同一个机架上，我们无需其他配置，若集群比较复杂，由于hadoop无法自动发现网络拓扑，所以需要额外配置网络拓扑。
基本读取程序，将文件内容输出到console
FileSystemCat
随机读取
展开原码
下图描述了写文件时客户端与 HDFS 中的 namenode， datanode 之间的数据流动。
对上图的解释如下：
如果在任何一个 datanode 在写入数据的时候失败了，接下来所做的一切对客户端都是透明的：首先， pipeline 被关闭，在确认队列中的剩下的包会被添加进数据队列的起始位置上，以至于在失败的节点下游的任 何节点都不会丢失任何的包。然后与 namenode 联系后，当前在一个好的 datanode 会联系 namenode， 给失败节点上还未写完的块生成一个新的标识ID， 以至于如果这个失败的 datanode 不久后恢复了，这个不完整的块将会被删除。失败节点会从 pipeline 中移除，然后剩下两个好的 datanode 会组成一个的新的 pipeline ，剩下的 这些块的包(也就是刚才放在数据队列队首的包)会继续写进 pipeline 中好的 datanode 中。最后，namenode 注意到块备份数小于规定的备份数，他就安排在另一个节点上创建完成备份，直接从已有的块中复制就可以。然后一直到满足了备份数( dfs.replication )。如果有多个节点的写入失败了，如果满足了最小备份数的设置( dfs.namenode.repliction.min ),写入也将会成功，然后剩下的备份会被集群异步的执行备份，直到满足了备份数( dfs.replication )。
创建目录
文件压缩有两大好处：
Hadoop 对于压缩格式的是自动识别。如果我们压缩的文件有相应压缩格式的扩展名（比如 lzo，gz，bzip2 等）。Hadoop 会根据压缩格式的扩展名自动选择相对应的解码器来解压数据，此过程完全是 Hadoop 自动处理，我们只需要确保输入的压缩文件有扩展名。
Hadoop中有多种压缩格式、算法和工具，下图列出了常用的压缩方法。
表中的“是否可切分”表示对应的压缩算法是否支持切分，也就是说是否可以搜索数据流的任意位置并进一步往下读取数据，可切分的压缩格式尤其适合MapRece。
所有的压缩算法都需要权衡空间/时间：压缩和解压缩速度更快，其代价通常是只能节省少量的空间。不同的压缩工具有不同的特性：
更详细的比较如下
1.压缩性能比较
2.优缺点
另外使用hadoop原生（native）类库比其他java实现有更快的压缩和解压缩速度。特征比较如下：
使用容器文件格式结合压缩算法也能更好的提高效率。顺序文件、Arvo文件、ORCFiles、Parqurt文件同时支持压缩和切分。
压缩举例（Java）
压缩
解压缩
六、文件序列化
序列化是指将结构化数据转换为字节流以便在网络上传输或写到磁盘进行永久存储。反序列化狮子将字节流转换回结构化对象的逆过程。
序列化用于分布式数据处理的两大领域：进程间通信和永久存储。
对序列化的要求时是格式紧凑（高效使用存储空间）、快速（读写效率高）、可扩展（可以透明地读取老格式数据）且可以互操作（可以使用不同的语言读写数据）。
Hadoop使用的是自己的序列化格式 Writable ，它绝对紧凑、速度快，但不太容易用java以外的语言进行扩展或使用。
当然，用户也可以使用其他序列化框架或者自定义序列化方式，如 Avro 框架。
Hadoop内部还使用了 Apache Thrift 和 Protocal Buffers 来实现RPC和数据交换。
⑺ “HDFS 采用数据流方式来访问文件，只支持单个客户端向一个文件追加数据”是什么意思啊
上半句话，访问文件不外乎读和写，需要读写时调用函数FileSystem&open()和FileSystem&create()，返回的对象是FSDataInputStream和FSDataOutputStream。 data直译成中文就是数据，stream直译成中文就是流。 这两个对象分别继承于java.io.DataInputStream和java.io.DataOutputStream， 是java的常用的文件读写类。 需要读时用DataInputStream的函数readInt(), readFloat()...，写时也差不多。
下半句话，两个关键词， ”单个客户“和”追加“。单个客户指不能有两个线程同时写；追加指写的形式只能是在文件后加内容(append)，不能覆盖(overwrite)。 这两个限制都是设计上简化考虑。 多个线程同时append时，由于hdfs是一份文件存于多个机器，保证在每台机器上两个线程写的顺序一致(从而结果一致)是一个很难的问题（当然不是做不到）， 出于简单考虑， 就不这么做了。 多个线程同时overwrite就更麻烦。
⑻ 什么是HDFS
Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（Distributed File System）。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。
HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求（requirements）这样可以实现流的形式访问（streaming access）文件系统中的数据。