HDFS并行复制

1)Distcp(分布式拷贝)是用于大规模集群内部和集群之间拷贝的工具。

2)distcp命令是以MR作业(没有R任务)的形式实现的,把文件和目录的列表作为M任务的输入。每一个文件是由一个M任务来拷贝的,distcp尽量把大小之和相同的各个文件导入到同一个M任务中。这样可以每个M任务拷贝的数据量大致相同。

3)集群之间的拷贝(HDFS版本相同):

bash$ hadoop distcp hdfs://nn1:8020/foo/bar hdfs://nn2:8020 /bar/foo

这个命令会把nn1集群的 /foo/bar 目录下的所有文件或目录名展开并存储到一个临时文件中,这些文件内容的拷贝工作被分配给多个M任务,然后每个TT分别执行从nn1到nn2的拷贝操作。【distcp使用绝对路径进行操作

4) 多个源目录拷贝

bash$ hadoop distcp hdfs://nn1:8020/foo/a hdfs://nn1:8020/foo/b hdfs://nn2:8020/bar/foo

5) 更新-update和覆盖-overwrite

默认情况下,如果在拷贝的目的地同名文件已经存在,则会默认跳过这些文件。可以通过-overwrite选项指定覆盖掉同名文件,或者通过-update选项来更新同名文件。 关于distcp的更多用法,可以不加参数运行“hadoop distcp”命令来查看其用法。

6) 不同版本HDFS之间拷贝

如果两集群Hadoop版本不一致不能使用hdfs标识符来拷贝文件了,因为两者的RPC系统是不兼容的。

  • 一种方法是使用基于只读的HTTP的HFTP文件系统来读取源数据(此命令在目标集群上执行,以确保RPC版本兼容),在命令中需要指定nn1的网络端口,它是由dfs.http.address指定的,默认为50070.
% hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar
  • 另一种方法是使用webhdfs协议(替换hftp协议),这样在拷贝的源和目的地都可以使用http而不用担心版本不兼容的问题:
% hadoop distcp webhdfs://namenode1:50070/foo webhdfs://namenode2:50070/bar

M任务的个数是按如下方式决定的:

1)     考虑到创建M任务的开销,每个M任务至少处理256MB的数据(如果总输入文件小于256MB,则把这些输入数据全部交给一个M任务执行)。例如,一个1GB大小的输入数据会被分配四个M任务来拷贝。

2)  如果待拷贝的数据实在很大,这时候就不能只按每个M任务256MB输入数据的标准来划分了,因为这样可能需要创建很多M任务。这时可以按每个DN有20个M任务来划分,例如,如果有1000GB的输入数据和100个节点,这是就会启动100*20=2000个M任务来拷贝数据,每个M任务拷贝512MB数据。同时我们也可通过-m选项指定要使用的M数,例如,-m 1000就会启动1000个M任务,每个M任务拷贝1GB数据。

时间: 2024-11-07 09:55:33

HDFS并行复制的相关文章

InnoSQL/MySQL并行复制的实现与配置

InnoSQL/MySQL并行复制的实现与配置 http://www.innomysql.net/article/6276.html 并行复制之前的解决方案 InnoSQL在5.5.30-v4版本中支持了从机并行复制的功能.总所周知,MySQL数据库slave服务器延迟的现象是非常普遍的,这导致了虽然对比Oracle.Microsoft SQL Server,MySQL复制允许从机进行SELECT操作,但是在实际线上环境下,由于从机延迟的关系,很难将读取操作转向到从机.这就导致了有了以下一些潜规

MariaDB Parallel Replication 并行复制

官方文档: https://mariadb.com/kb/en/mariadb/parallel-replication 从10.0.5版本开始,MariaDB开始支持并行复制 MariaDB10.0的从服务器能并行的执行查询和复制操作,这篇文章将会解释是如何实现的和你可以做的调优. 注意:主从服务器上的 MariaDB 的版本必须是10.0.5和10.0.5的以后的版本,才能启用并行复制 Parallel replication overview -- 并行复制概述 MariaDB 的复制通过

MySQL 5.7 并行复制实现原理与调优

MySQL 5.7并行复制时代 众所周知,MySQL的复制延迟是一直被诟病的问题之一,然而在Inside君之前的两篇博客中(1,2)中都已经提到了MySQL 5.7版本已经支持“真正”的并行复制功能,官方称为为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进,甚至在Inside君所在的网易电商应用中已经完全消除了之前延迟长达几小时的问题.然而,Inside君发现还是有很部分小伙伴不了解这个足以载入史册的“伟大”的特性,故作分享.总之,

MySQL5.6 基于db的并行复制

slave的几个类结构: Master_info:用于IO线程的参数,包括连接master实例的信息. Relay_log_info:用于sql线程,表示relay log相关的信息. Slave_worker:继承Relay_log_info,包括一个job队列,用于并行的worker线程. binlog event的类结构: slave启动的函数栈: dispatch_command start_slave start_slave_threads start_slave_thread sta

《Hadoop权威指南》笔记 第三章 并行复制及存档

distcp并行复制 ? ? ? ? ? ? ? ? ? ? Hadoop存档 ? ? ? ? ? ? ? ? ? ?

mysql 并行复制

并行复制,主要是解决sql_thread在高并发环境下,存在性能瓶颈.mysql5.7并行复制的思想简单易懂,一个组提交的事务都是可以并行回放,因为这些事务都已进入到事务的prepare阶段,则说明事务之间没有任何冲突(否则就不可能提交). 为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有: (1)DATABASE:默认值,基于库的并行复制方式 (2)LOGICAL_CLOCK:基于组提交的并行复制方式 操作步骤: 数据库版

MySQL5.7的组提交与并行复制

从MySQL5.5版本以后,开始引入并行复制的机制,是MySQL的一个非常重要的特性. MySQL5.6开始支持以schema为维度的并行复制,即如果binlog row event操作的是不同的schema的对象,在确定没有DDL和foreign key依赖的情况下,就可以实现并行复制. 社区也有引入以表为维度或者以记录为维度的并行复制的版本,不管是schema,table或者record,都是建立在备库slave实时解析row格式的event进行判断,保证没有冲突的情况下,进行分发来实现并行

MariaDB 10之并行复制--延迟测试结果

测试参数: sysbench  --test=/root/sysbench0.5/sysbench/tests/db/insert.lua  --mysql-table-engine=innodb --oltp-table-size=1000000  --max-requests=0 --max-time=300 --num-threads=16  --oltp-tables-count=10 --report-interval=10  --mysql-host=10.8.8.100 --mys

MySQL 5.7 并行复制

一.缘由: 某天看到主从复制延时的告警有点频繁,就想着是不是彻底可以解决一下. 一般主从复制,有三个线程参与,都是单线程:Binlog Dump(主) ----->IO Thread (从) -----> SQL Thread(从).复制出现延迟一般出在两个地方 1)SQL线程忙不过来(可能需要应用数据量较大,可能和从库本身的一些操作有锁和资源的冲突:主库可以并发写,SQL线程不可以:主要原因) 2)网络抖动导致IO线程复制延迟(次要原因). 二.解决办法: MySQL从5.6开始有了SQL