Ossimport 大数据量迁移方案总结

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 背景: 面临客户不断的将友商的存储数量迁移到阿里云上。ossimport 工具越来越多的暴露在用户端,但是合理的利用 ossimport 工具以及良好的迁移架构数据能否帮助用户高效的快速迁移。但是如果对 ossimport 不熟知,而且迁移架构没有经过测试,反而会降低我们的迁移效率,影响客户的全面战略上云计划安排。

背景:

面临客户不断的将友商的存储数量迁移到阿里云上。ossimport 工具越来越多的暴露在用户端,但是合理的利用 ossimport 工具以及良好的迁移架构数据能否帮助用户高效的快速迁移。但是如果对 ossimport 不熟知,而且迁移架构没有经过测试,反而会降低我们的迁移效率,影响客户的全面战略上云计划安排。

 

迁移架构的演进:

传统的迁移方式:

本地 localfile -> 迁移到 OSS 云端

第三方存储 -> 迁移到 OSS 云端

以上的传统迁移方式都会遇到一个功能的问题就是公网的干扰因素不可以避免,尤其是当下的国内网络环境错综复杂,很难保证公网没有拥塞抖动,即便是大物理带宽的情况也不可幸免。于是有了 vpc 网络环境的改进。

进化 VPC 环境迁移:

在引入了 VPC 的概念后,用户解决了网络上带来的慢速的头疼问题,带来了一系列好处,,这里的  VPC 概念是指(通过 OSS 内网传输 or 走 VPC 专线传输)

  • 迁移数据源到 OSS 端,没有带宽流量的限制(不包括 ECS 内部限制)
  • VPC 内网环境迁移,使用 OSS 内网域名,不收取流量费用。
  • VPC 环境延迟对比公网极低,基本无丢包,除非遇到线路故障

第三方 storage -> 数据盘 copy -> IDC 机器 -> VPC 专线 push->  OSS 云端


第三方 storage <- pull ECS -> VPC 专线 push -> OSS 云端


第三方 storage <- pull ECS  -> OSS 内网 endpoint push -> OSS 云端


本地文件 -> OSS 内网 endpoint push -> OSS 云端


本地文件 -> VPC 专线 push -> OSS 云端


 

合理迁移配置:

目前还是推荐客户按照 VPC 的环境方式进行迁移,在服务体验感上有很大提升。在迁移过程中 OSS SLA 没有承诺迁移速度有明确指标,而且迁移数据和多因素有关(机器配置、数据量、网络、线程、限流等),所以根据实际情况进行问题诊断。

首先在迁移之前,要求使用者要先大致的学习一下我们的配置属性说明,和相关文件的作用,日志存储,异常处理等。

https://help.aliyun.com/document_detail/56990.html?spm=a2c4g.11174283.6.1079.sbu1ch

 

配置迁移文件单机版:

迁移前要明确用户的迁移体量和文件数量。目的是合理的配置 task 和线程数量,以及 ossimport 的工作模型。

一般迁移体量小于 30TB 的完全可以采用单机模式进行迁移,单机版可以配置多线程的方式进行迁移,调节 workerTaskThreadNum 参数,需要注意的是如果是高配,物理机的话,数量可以调大,可以参考 平均文件 size * 线程数量,对比 memory 是否够用,同时也要参考 CPU 核心数量是否能否抗住这种并发量。

当高并发,且文件的 size 较大时,如果配置数量不合理,会出现设备 OOM 的情况,可以通过 /var/log/message 看到,这是要么选择降低并发线程数量,要么是增大机器配置。

如果是本地 ECS 或者第三方存储迁移到 OSS ,请注意源是否有限流,目前经常会出现源发现有大流量流出后直接给限制住,导致迁移速度无法增长。关键参数 workerMaxThroughput(KB/s),如果源没有限制,可以释放调大这数。

其他 sys.properties 文件中的属性不要随意改动。

 

在迁移中可能遇到的问题:

数据流量一直涨不上去速度不快,这种情况,检查几个相关因素

  • 迁移的网络环境
  • 源流是否有限制
  • 线程配置数量是否合理。
  • 本机带宽是否被打满
  • 机器负载是否飚高

 

console.sh 各项指标不明白,我们来解释一下

JobName:local_test 迁移的任务名称可改

JobState:Running 任务运行中

PendingTasks:0 挂起的任务指已经扫描完被挂起的任务数

DispatchedTasks:1 已经扫描完的任务

RunningTasks:0 运行中的任务

SucceedTasks:0 成功任务

FailedTasks:0 失败任务

ScanFinished:true 是否已经扫描完成,如果配置了增量迁移,这个数一直都是 False

以上所有的 task 相加一定等于 DispatchedTasks。如果遇到文件先用 bash console.sh stat 看下任务数量是否都正常。如果出现失败任务一定要看下日志目录下的记录 ossimport2.log ,分布式是 import.log


三、JOB running 中日志出现了以下异常

channels.OverlappingFileLockException 是在扫描源文件,拉取源流超时导致,在 log 中可以看到是哪个文件超时,手动 curl 测试一下源是否能否访问。

 

四、如果出现的 FailTask 以后怎么办

ossimport 会对每个失败的文件有三次重试,如果依然失败,请在第一遍以后直接使用 bash console.sh retry 重试。

 

配置分布式迁移文件

分布式迁移模式的数据体量都是大于 30TB ,甚至上 PB 的级别才会用到,迁移模型也比较特殊,是通过 master 带多个 worker 协同工作,类似 nginx 的模型,master 只是用来切割任务和分配任务,对数据量庞大的用户,worker 的数量也要配置好,才能高效迁移。

首先通过用户文件数量,来计算任务数,该项目中用户总文件数 424421917 个,源头限制 3Gbps ,客户的机器数量有 12 台。

计划分成 20000 个 task ,每个 task 迁移 21221 个文件。每个 worker 机器开 200 线程,并发处理 200 个 task ,并发也就是能处理 2400 个,升级 17600 个 task 在队列中。

源流限制是 3000Mbps ,其实并发 worker 全部也就能跑到 375MB ,所以即便是你的线程开的再多,机器配置在高其他的线程也只能阻塞住。

job.cfg 迁移数据配置文件


sys.properties 迁移工具调优配置文件

 

迁移过程中可能遇到的问题:

一、设备日志中出现 OOM

这种问题基本都是用户选型的机器配置不够导致 worker 的迁移进程被干掉。

 

二、master 的 workers  文件中 IP 顺序随便写?

master 的 worker 文件一定要将 master IP 放在第一行,worker 机器放在下面,不要随意乱放,不然用户会将 master 机器也当做 worker 分配任务,造成 master 流量过高被打死。

 

三、JOB running 中日志出现了以下异常

这个错误和单机版的原因是一致的。

 

四、使用分布式模式迁移过程中出现 hang 住

使用 bash console.sh stat  看下文件是否已经扫描完,如果扫描完后出现在执行任务过程中 hang 住 并且伴随有失败任务,已经超过了几个小时,直接用 bash console.sh retry 再 bash console.sh stat 看下,如果数量有再变,就已经恢复,如果任务数量依然没有变化,请提交工单到阿里云售后。

其余报错可以根据 logs/ 下的 import.log 来查找原因。

 

FAQ 

Q:配置文件中 srcPrefix 填写什么

A:代表文件迁移的前缀,如果是 bucket/ 迁移到 bucket/ 或者 本地 local/ 迁移到 bucket/ ,直接默认为空就行,如果源是 bucket/test/* 迁移到 bucket ,prefix 填写为 bucket/test,默认所有前缀为 bucket/test 的bucket 都会迁移到目标 bucket。

 

Q:配置文件中 destPrefix 填写什么

A:同上

 

Q:源文件是 URL list 该如果迁移

A:可以采用 ossimport 的 HTTPLIST 迁移方法

 

Q:分布式版如果分配 task 给 worker

A:通过在 master 上生成公私钥,然后在 sys.properties 文件配置好你的秘钥文件。

 

Q:是否有迁移案例可以参考

A:600TB 数据。12台 8U 16G 内存,千兆网卡,源流限制 3000Mbps/s迁移时间大概 25 田。

 

Q:源文件想定期扫描如有新文件就迁移到 OSS

A:OSSimport 支持增量迁移,可以先全量迁移,然后在开启增量迁移,设置好 interval 间隔时间,定期 OSS 会去源头扫描。

 

Q:能否限制 worker 的迁移速度。

A: OSSimport 通过 workerMaxThroughput(KB/s) 参数进行速度限制。

或者降低内存 javaHeapMaxSize 

 

Q:任务启动后 worker 上没有 ossimport 迁移进程

A:检查 conf/sys.properties 文件中配置的是否正确,不要和你的 脚本同级目录。

 


重点来了:ossimport 迁移工具白屏化提供出来了。


访问地址:http://oss2.zhangyb.mobi/ossimport


迁移步骤:

迁移服务化解决的问题:

对于用户的大数据量迁移,以及不懂编写迁移配置或者不善于计算迁移线程等配置的用户进自动配置下发和安装包下载以及任务数、线程数的配置

实现 master 的一键部署

1、 迁移服务化的地址

URL : http://oss2.zhangyb.mobi/ossimport

 


2、 迁移模式

a)       目前分为了 3 种模式

b)       Localfile-to-oss  本地文件迁移到 OSS

c)        Httpurl-to-oss  通过 httpurl 的方式迁移,需要用户提供迁移列表地址

                     i.            格式举例 http://www.taobao.com/1/2/3/  1.jpg

                   ii.            格式举例 http://www.taobao.com/1/  2/3/1.jpg

d)       Cloud-to-oss 第三方云存储迁移到 oss

 


 

3、 迁移数据量

大于 30TB 使用分布式迁移 小于 30TB 使用单机模式


 

4、 迁移模式:

4.1本地文件迁移到 OSS

用户将空白地方按照实际情况填写即可,srcprefix 以及 destprefix 如果都是跟下面,可以直接填写 / 即可,所有配置项都是必选,迁移数据量是已经选择好的,不用客户自己填写


         4.2、httpurl 迁移到 OSS

         所有配置项都是必选,迁移数据量是已经选择好的,不用客户自己填写


         4.3、       第三方云存储迁移到 OSS

         所有配置项都是必选,迁移数据量是已经选择好的,不用客户自己填写


 

5、 执行效果

举例:第三方云存储迁移到 OSS


 

6、 一键部署




相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps&nbsp;
目录
打赏
0
相关文章
S3存储服务间数据同步工具Rclone迁移教程
目前大多项目我们都会使用各种存储服务,例如oss、cos、minio等。当然,因各种原因,可能需要在不同存储服务间进行数据迁移工作,所以今天就给大家介绍一个比较通用的数据迁移工具Rclone。
S3存储服务间数据同步工具Rclone迁移教程
支持全量&增量迁移!YashanDB增量迁移实现原理解读
本文基于YashanDB高可用架构师马志宏在“2024年国产数据库创新生态大会”的演讲,深入阐述了YashanDB的数据迁移流程及增量迁移组件的技术原理。崖山迁移平台YMP提供异构RDBMS与YashanDB间的迁移评估、数据迁移和校验功能。最新版本V23.3新增增量迁移组件,支持在线全量和增量迁移的无缝衔接,确保业务无感知迁移,保障数据一致性和业务连续性。迁移组件由source、transform、sink三个模块组成,具备一键式迁移、支持多种数据类型和DDL操作、无侵入式部署等关键能力,确保高效、可靠的迁移体验。未来将优化兼容性、支持双向复制和提升数据质量管理。
【YashanDB 知识库】用 yasldr 配置 Bulkload 模式作单线程迁移 300G 的业务数据到分布式数据库,迁移任务频繁出错
问题描述 详细版本:YashanDB Server Enterprise Edition Release 23.2.4.100 x86_64 6db1237 影响范围: 离线数据迁移场景,影响业务数据入库。 外场将部分 NewCIS 的报表业务放到分布式数据库,验证 SQL 性能水平。 操作系统环境配置: 125G 内存 32C CPU 2T 的 HDD 磁盘 问题出现的步骤/操作: 1、部署崖山分布式数据库 1mm 1cn 3dn 单线启动 yasldr 数据迁移任务,设置 32 线程的 bulk load 模式 2、观察 yasldr.log 是否出现如下错
【性能优化下】组织结构同步优化二,全量同步/增量同步,断点续传实现方式
【性能优化下】组织结构同步优化二,全量同步/增量同步,断点续传实现方式
如何选择离线数据集成方案-全量&增量
如何选择数据离线集成方式,哪些表适合全量集成,哪些表适合增量集成
773 0
如何选择离线数据集成方案-全量&增量
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
前言 前文架构篇,可以看到 MySQL + Tablestore 非常适合大规模订单系统这一类需求场景。那么,我们首先要做的是,利用 CDC(Change Data Capture) 技术将订单数据实时从 MySQL 同步到 Tablestore 中。对于订单系统的数据同步,我们需要关注同步的稳定性、实时性。目前,存在多款工具可以实现这一功能,他们有的是开源工具如 Canal,有的是阿里云端服务如
1160 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
Ossimport 大数据量迁移方案总结
背景: 面临客户不断的将友商的存储数量迁移到阿里云上。ossimport 工具越来越多的暴露在用户端,但是合理的利用 ossimport 工具以及良好的迁移架构数据能否帮助用户高效的快速迁移。但是如果对 ossimport 不熟知,而且迁移架构没有经过测试,反而会降低我们的迁移效率,影响客户的全面战略上云计划安排。
Ossimport 大数据量迁移方案总结
MongoShake全量迁移功能
从v1.5版本开始,MongoShake新增了全量迁移功能,该功能可以让用户更快地对数据量较大的MongoDB数据库做数据复制。MongoShake不再需要源数据库保留全部的oplog,只要依赖当前的oplog就能做数据同步复制。
3549 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等