HDFS和本地文件系统文件互导

HDFS和本地文件系统文件互导,第1张

初步了解一下情况,后续根据给出案例

一、从本地文件系统到HDFS

使用hdfs自带的命令

命令:hdfs dfs -copyFromLocal inputPath outputPath

inputPath:本地文件目录的路径

outputPath:hdfs文件目录路径,即存储路径

二、从HDFS到本地文件系统

命令:hdfs dfs -copyToLocal inputPath outputPath

inputPath:hdfs文件目录

outputPath:本地文件文件目录,即本地存储路径

因为Hbas和Hive都在存储在HDFS中,所以可以通过该条命令可以把Hbase和Hive存储在HDFS中的文件复制出来。但是经过实践,通过这种方式复制出来的Hbase文件是乱码。Hive里的文件有时候也会乱码,这取决于Hive数据的插入方式。

三、文件在HDFS内的移动

1、从Hbase表导出数据到HDFS

命令:hbase orgapachehadoophbasemapreduceExport tableName outputPaht

例子:hbase orgapachehadoophbasemapreduceExport test /user/data

test为需要从Hbase中导出的表,/user/data为hdfs上的路径,即存储路径,如果最后一个参数有前缀file:// 则为本地上的文件存储系统

2、从HDFS导入到Hbase表中,需要事先建立好表结构

命令:hbase orgapachehadoophbasemapreduceExport tableName inputPaht

例子:hbase orgapachehadoophbasemapreduceImport test1 /temp/part-m-00000

案列:

两个不同环境数据,数据导入

过程描述:

            导出正式环境数据到hdfs中,然后从hdfs中导出到本地,本地传到测试环境主机,然后从本地导入到hdfs中,再从hdfs中导入到hbase中。

处理过程:

1、注意事项:1、权限问题使用hdfs:sudo -u hdfs ;

                      2、存放上传路径最好不要在root下

                      3、上传完成后,查看是否在使用,数据已经插入。

1、sudo -u hdfs hbase orgapachehadoophbasemapreduceExport  /hbase/_bak  (导出到hdfs中的_bak)

2、hdfs dfs -copyToLocal /hbase/sw_bak /test  (导出hdfs中文件到本地test,注:提前建好目录)

3、scp -r test_bak root@19216890:/root/test  (传送目录到测试环境主机目录下,注:传到测试环境后,把文件不要放到root的目录下,换家目录下)

4、sudo -u hdfs hdfs dfs -copyFromLocal /chenzeng/text_bak /data (把sw传到hdfs 中,注意上传时,文件路径要对,放在data路径下比较好)

5、sudo -u hdfs hbase orgapachehadoophbasemapreduceImport test /data/test_bak/part-m-0000 (注意上次文件)

6、在hbase shell 中查看test :count 'test' 确认是否上传成功

优化:

truncate ‘’

正式环境导入至hdfs中时,

可以直接在另一个环境的执行sudo -u hdfs hbase orgapachehadoophbasemapreduceImport test hdfs://server243:8020/hbase  可以直接加主机和对应路径进行put。

这种情况应该是hive分区已经创建了,hive的元数据已经有了,你还没有给分区插入数据。

可以执行show partitions xxxx,看看分区是否已经存在。

show create table xxxx,看看表对应的HDFS目录是否有。

然后你往分区里插入一点数据,看一下分区目录是否创建。

经过一段时间的使用发现原本存入HDFS的数据量不是很大,但是50多个T的存储空间缺被占满了,
解决:
hadoop fs -du -h /
使用该命令查看HDFS中文件占用的大小,发现/tmp目录占用较大

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 。一个检查点可以在固定周期(dfsnamenodecheckpointperiod)(以秒为单位)触发,也可以文件系统事物数量达到某个值(dfsnamenodecheckpointtxns)的时候触发。

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://outofmemory.cn/yw/13392841.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-27
下一篇 2023-07-27

发表评论

登录后才能评论

评论列表(0条)

保存