【OBS数据迁移实践】基于URL列表，使用CDM批量数据迁移至OBS的高效实践指南

       我们经常会遇到需要通过Http URL列表的形式，进行海量源数据迁移到OBS的场景，此时我们可以使用CDM中的HTTP连接器作为源端类型，创建迁移任务。本文将详细描述针对此场景进行的实践配置指南。

前提条件: 适当规模的CDM集群已经创建完毕并正常运行

cdm.medium 规格的CDM集群，支持单表规模<1000万条，适合大多数迁移场景，并支持多任务；理论支持的最大传输流量约为200MB/s

步骤一： 准备url列表文件，并保存到一个OBS桶中

截止2019-06-24，在数据迁移实践中，CDM HTTP连接器中的“列表文件”使用的文件格式如下所示，每一行直接为一个目标url。 

我们一定需要将该文件保存到OBS用户能够访问的一个目标桶中（例如 obs://tempfile/test/just_test.csv）

步骤二: 进入CDM集群的“作业管理”

步骤2.1 首先各创建 一个OBS连接器 和 一个HTTP连接器

• HTTP连接器作为迁移作业的数据输入源，OBS连接器作为迁移作业的数据输出目标， 

     

步骤2.2 在“表/文件迁移”下新建作业

步骤2.3 作业的基本信息配置

特别提示：如果需要，一定不要忘记点击本页中的“显示高级属性”进行配置

步骤2.4 点击下一步，进入作业的字段映射配置

任务配置完成后，只“保存”即可，因为还需要进行后续的作业JSON配置

步骤2.5 对创建的作业执行“JSON配置”

在作业的JSON编辑页面，我们搜索找到配置项 toJobConfig.duplicateFileOpType，该选项的值决定了在数据迁移过程中，如何处理OBS目标桶中已存在目标对象的情况：

• 如果我们希望直接覆盖目标对象，将值设为 "REPLACE" （默认也是此值）

• 如果我们希望跳过该对象，则需要设置为 "SKIP"

• 无论是 "REPLACE" 还是 "SKIP"，引号一定不能漏了
  

这里需要注意的是，截止当前版本（2019-06-24），CDM判断“源端对象”与 “OBS中已有对象”是否一致的规则是：对象名一致 且 对象大小一致，具体的算法步骤概括为：

1. 根据源url，发起HTTP HEAD请求获取对象元数据，其中包括对象大小size。——如果成功，执行步骤2；如果失败，执行步骤3

2. 根据源url中的对象key，查询OBS目标桶中是否存在同名对象，如果有则判断size是否与源对象一致 —— 如果匹配一致，则直接返回并跳过；如果匹配不一致，则执行步骤3

3. 从源url下载对象并上传到OBS目标桶——执行成功则返回，执行失败则重试，最多重试的次数根据步骤2.4的配置来决定，重试仍然失败的话则直接报失败

   
   

配置完成后，可以保存并运行

步骤三： 作业运行结果的分析

作业开始运行后，可以在作业列表可以看到当前作业的执行执行状态。点击“历史记录”可以看到同一个作业配置的多次执行记录

在作业的“历史记录”表中，每一行为一次作业的执行结果的详情，其中每一条任务运行记录最后侧的“日志”中包含了批量对象迁移的详细过程记录

迁移任务成功:   跳过文件数 + 写入文件数 = 读取文件数

迁移任务失败（一）:  CDM集群异常重启引起的迁移任务失败

迁移任务失败（二）:  CDM从源服务器读取数据失败引起的迁移任务失败

迁移任务失败（三）:  迁移任务被中断引起的失败

无论哪种失败，都可以直接在作业列表中直接点击“运行”重启该作业的一次新的执行

重要提示：一个迁移作业成功完成后，应该再启动一次该作业，确认 读取文件数 == 跳过文件数 == 总文件数

因为CDM迁移上传数据至OBS的时候，存在上传完成后的校验不全面的风险，在实践中我们强烈建议：即使一个迁移作业显示Success，还是应该再启动一次该作业，确认 读取文件数 == 跳过文件数 == 总文件数 

FAQ

• 一个作业的连续两次执行，前一次执行失败了，重新执行的这次正在Running执行中，截图如下：
  

  • 问题

    作业的前一次执行虽然失败了，不过统计数据显示：总文件数24198 - 读取文件数24197 = 1，读取文件数24197 = 跳过文件数24120 + 写入文件数77——这说明其实只有一个源文件没有上传到OBS成功了
    
    但是随后再次启动的这次执行，虽然还没有完成，不过统计数据却显示已经完成了124个源文件到OBS的写入上传，这不是和前一次执行的结论冲突吗？
    
    CDM的跳过机制出问题了吗？

    
    

  • 分析
    在步骤2.5的CDM判断源对象是否已经在OBS目标桶中的算法分析中，我们已经指出，当前的CDM版本首先尝试获取源端数据的元数据信息，不过无论这一步是否成功，CDM对该对象的迁移步骤都会继续往下走——这就意味着一旦CDM从源端获取对象元数据失败了（源端Server在面对数据迁移的大规模Http请求时出现异常是常见的情况），CDM就无法与OBS中的现有对象进行文件大小的比较了，也就会强制进行源对象向目标OBS桶中的覆盖型写入。
           这也就是为什么会出现第二次运行作业写入的文件数远超过预期的原因。
    

• 解决
  该问题的解决需要依赖于CDM版本的更新，优化和修改HTTP连接类型作为源输入的场景下，判断源对象是否已经存在于OBS桶中的算法。截止本文初稿完成时（2019-06-24），OBS已经和CDM进行了新算法的联调测试，并在现网客户的批量URL列表数据迁移任务中成功运行。该方法需要如下两个步骤：

  步骤一： 提供给CDM的URL列表文件中，可以在每一个url后面新增源文件大小的内容，形如下图：
  
  步骤二：目标CDM集群部署版本进行升级，兼容对URL列表文件中源对象大小信息的支持（具体可联系CDM的同事 l00308111，计划在CDM的640版本中，该补丁将正式合入）。
  
  这样一来，CDM判断“源端对象”与 “OBS中已有对象”是否一致的算法步骤变更为：

  1、根据源url，发起HTTP HEAD请求获取对象元数据，其中包括对象大小size。——如果成功，执行步骤3；如果失败，执行步骤2
  2、判断url列表文件中，该url后面是否有对象大小字段信息——如果有，则执行步骤3；如果没有，则执行步骤4
  3、根据得到的对象key和对象大小，查询OBS目标桶中是否存在同名对象，如果有则判断size是否与源对象一致 —— 如果匹配一致，则直接返回并跳过；如果匹配不一致，则执行步骤4
  4、从源url下载对象并上传到OBS目标桶——执行成功则返回，执行失败则重试，最多重试的次数根据步骤2.4的配置来决定，重试仍然失败的话则直接报失败