大家好，我是明哥!

最近有小伙伴問到 hadoop distcp 的使用，對其中的一些細(xì)節(jié)和容易踩的坑不是很清楚，所以今天我們來看下 hadoop distcp 的原理，細(xì)節(jié)和容易踩的坑。

1.DistCp 概述

我們知道大數(shù)據(jù)集群內(nèi)部都有節(jié)點(diǎn)級(jí)別和機(jī)架級(jí)別的容錯(cuò)機(jī)制(存儲(chǔ)層對應(yīng)的就是傳統(tǒng)的三副本或糾刪碼機(jī)制)，但對于一些數(shù)據(jù)安全性要求更改的場景，比如在金融行業(yè)典型的兩地三中心場景下，經(jīng)常有跨區(qū)域跨集群災(zāi)備的需求，此時(shí)就會(huì)涉及到跨集群的數(shù)據(jù)同步。

DistCp (distributed copy) 就是一款跨集群的數(shù)據(jù)同步工具。

DistCp 可以用來做 hdfs 集群內(nèi)部或集群之間的大規(guī)模的數(shù)據(jù)同步，由于在底層使用了 MapReduce 框架會(huì)通過多個(gè) mapper 來拷貝需要拷貝的文件列表，其性能相比 hdfs dfs -get/put 等通過本地文件系統(tǒng)中轉(zhuǎn)的數(shù)據(jù)同步方案，要高效快速很多。

同時(shí)由于 DistCp 可以跨 hdfs 大版本進(jìn)行數(shù)據(jù)同步，且新版本的 DistCp(distcp version 2) 相比老版本的DistCp(legacy DistCp，version 1.2.1)在很多方面都做了優(yōu)化和改進(jìn)，所以大規(guī)模的數(shù)據(jù)同步，不論是集群內(nèi)部還是集群之間，首選的方案都是DistCp。

很多商業(yè)的hdfs數(shù)據(jù)同步方案，其底層都是原生的 DistCp，比如 cdh 的 bdr 工具，比如 tdh 的 backup工具，其原理都是如此。

2.關(guān)于集群間數(shù)據(jù)同步

• 集群間數(shù)據(jù)同步，可以從原集群推送數(shù)據(jù)到目標(biāo)集群，此時(shí)會(huì)為會(huì)占用原集群 yarn 中的資源;
• 集群間數(shù)據(jù)同步，也可以從目標(biāo)集群發(fā)起作業(yè)，主動(dòng)拉取原集群的數(shù)據(jù)，此時(shí)消耗的是目標(biāo)集群的YARN資源;
• 如果原集群是生產(chǎn)集群，一般在目標(biāo)集群執(zhí)行命令hadoop distcp來發(fā)起作業(yè)，通過拉的方式來同步數(shù)據(jù)，此時(shí)不會(huì)消耗原集群即生產(chǎn)集群的YARN資源;
• 當(dāng)原集群和目標(biāo)集群大版本不同時(shí)，(比如在 hadoop 1.x 跟 hadoop 2.x 之間同步數(shù)據(jù))，需要使用 webhdfs 協(xié)議，即通過以下格式指定遠(yuǎn)端集群：webhdfs://:;(當(dāng)然，既可以從原集群推數(shù)據(jù)，也可以從目標(biāo)集群拉數(shù)據(jù));
• 當(dāng)原集群和目標(biāo)集群大版本相同時(shí)，(比如都是 hadoop 2.x或都是hadoop 3.x)，推薦使用 hdfs 協(xié)議，此時(shí)性能比 webhdfs 更好;
• 如果 webhdfs 配置了 SSL 加密，則需要使用協(xié)議 “swebhdfs://” ;

3.關(guān)于開啟了 kerberos 安全認(rèn)證后的數(shù)據(jù)同步

• 如果原集群和目標(biāo)集群都啟用了kerberos認(rèn)證 (hadoop.security.authentication=kerberos)，需要首先做 kerberos 的 realm 互信，然后才能通過推或拉的方式執(zhí)行 dictcp 進(jìn)行數(shù)據(jù)同步;
• 如果原集群與目標(biāo)集群一個(gè)啟用了kerberos認(rèn)證，另一個(gè)沒有啟用kerberos認(rèn)證，為簡單起見，可以在啟用了kerberos認(rèn)證的集群中執(zhí)行distCp，通過推或拉的方式進(jìn)行數(shù)據(jù)同步;

4.DistCp 的底層工作機(jī)制

新版 DistCp 底層有以下組件，其各自的職責(zé)如下：

• DistCp Driver：負(fù)責(zé)解析 DistCp 的命令行參數(shù)，并編排協(xié)調(diào)具體的拷貝任務(wù)(首先調(diào)用 copy-listing-generator 獲得需拷貝的文件列表，然后配置并提交 Map-Reduce 拷貝任務(wù)，最后根據(jù)配置項(xiàng)返回 MR 任務(wù)句柄并推出，或等待 MR任務(wù)執(zhí)行結(jié)束;)
• Copy-listing generator：負(fù)責(zé)解析給定的 source-paths(目錄或文件，可以包含通配符)，生成待拷貝的文件/目錄列表，并輸出到一個(gè) SequenceFile;
• Input-formats 和 Map-Reduce：負(fù)責(zé)讀取 Copy-listing generator 生成的 SequenceFile 中的待烤包的文件列表，并執(zhí)行實(shí)際的文件拷貝;

5.DistCp 的重要參數(shù)講解

DistCp 提供了多種參數(shù)，來控制拷貝任務(wù)的各種細(xì)節(jié)，經(jīng)常使用到的關(guān)鍵參數(shù)有 -update, -delete, -overwrite, -m, -bandwidth，-diff，-p，-i 等：

• -m ：控制 map 任務(wù)的最大個(gè)數(shù);(實(shí)際的 map 任務(wù)數(shù)，不會(huì)大于待拷貝的文件的個(gè)數(shù);更多的 map 數(shù)不一定會(huì)提升整體IO吞吐);
• -bandwidth：控制每個(gè) map 任務(wù)可用的最大帶寬，單位 MB;
• -p[rbugpcaxt]：控制是否保留源文件的屬性，rbugpcaxt 分別指：replication number, block size, user, group, permission,checksum-type, acl, xattr,以及 tiemstamp;
• skipcrccheck：控制檢查源和目標(biāo)文件差異以生成待拷貝文件列表時(shí)，是否跳過 CRC 校驗(yàn);
• update: 如果源和目標(biāo)目錄下的文件，在 文件大小/塊大小/checksum 上有不同，就用;
• -update: 拷貝目標(biāo)目錄下不存在而源目錄下存在的文件，或目標(biāo)目錄下和源目錄在文件大小/塊大小/checksum 上不同的文件;
• -overwrite: 覆蓋目標(biāo)目錄下的同名文件。(如果某個(gè) map 任務(wù)執(zhí)行失敗且沒有指定 -i 參數(shù)，則所有的待拷貝的文件，包括拷貝失敗的文件，都會(huì)被重新拷貝);
• -i： 忽略拷貝過程中某些 MAP 任務(wù)的錯(cuò)誤，繼續(xù)執(zhí)行其余的 map拷貝任務(wù)，而不是直接失敗整個(gè)作業(yè);(默認(rèn)情況下，如果有某個(gè) map 任務(wù)失敗的次數(shù)達(dá)到了 mapreduce.map.maxattempts，則未完成的 map 任務(wù)都會(huì)被 kill;);
• -delete: 刪除目標(biāo)目錄下存在，但源目錄下不存在的文件;該參數(shù)只能和 -update 或 -overwrite 配合使用;
• -diff 和 -rdiff：控制是否結(jié)合使用快照機(jī)制，會(huì)基于兩個(gè)快照的差異(snapshot diff)來確定待拷貝的文件列表，以下要點(diǎn)需要注意：
  • -diff 和 -rdiff，需要配合選項(xiàng) -update 一起使用;
  • -diff 和 -rdiff，不能和 -delete 一起使用，否則會(huì)報(bào)錯(cuò)：java.lang.IllegalArgumentException: -delete and -diff/-rdiff are mutually exclusive. The -delete option will be ignored;
  • 該命令的前提條件：需要源目錄下有指定的兩個(gè)快照 from_snapshot 和 to_snapshot;
  • 該命令的前提條件：需要目標(biāo)目錄下有快照 from_snapshot;
  • 該命令的前提條件：需要目標(biāo)目錄在前期制作了 from_snapshot 快照后，沒有新的文件寫操作 (create, rename, delete);
  • 該命令執(zhí)行完畢后，目標(biāo)目錄下并不會(huì)自動(dòng)創(chuàng)建快照 to_snapshot，如果后續(xù)還需要基于快照來做增量同步，需要手工在同步完畢后對目標(biāo)目錄制作快照 to_snapshot，為后續(xù)基于快照的同步(hadoop distcp -diff -update)做好準(zhǔn)備;

6.易踩的坑 - skipcrccheck

• 參數(shù) -skipcrccheck 的意思是 “Whether to skip CRC checks between source and target paths.”，即是否跳過原路徑和目標(biāo)路徑下文件的 crc 校驗(yàn)(CRC：Cyclic Redundancy Check)。
• 如果指定了該參數(shù)，會(huì)跳過crc校驗(yàn)，同步作業(yè)速度會(huì)快些;
• 但指定該參數(shù)后，由于不校驗(yàn) crc，而是通過文件名和文件大小來發(fā)現(xiàn)哪些文件需要進(jìn)行同步，在極端情況下，可能會(huì)漏掉某些需要同步的小文件，比如某些只有少數(shù)幾條記錄的小文件，從而造成數(shù)據(jù)不一致;
• 下圖展示的就是，某兩個(gè) hive orc 表都只有1條記錄，對應(yīng)的 HDFS 文件也比較小且都是 299 BYTE, 指定參數(shù) skipcrccheck 執(zhí)行同步操作時(shí)，就遺漏了該文件，造成了源目錄與目標(biāo)目錄數(shù)據(jù)的不一致：“sudo -u hdfs hadoop distcp -update -delete -skipcrccheck -pugpb hdfs://nameservice1/user/hive/warehouse/hs_liming.db/test_single_row_scp hdfs://nameservice1/user/hive/warehouse/hs_liming.db/test_single_row_scp2“：

skipcrccheck 的坑-hdfs

skipcrccheck 的坑-hive sql

7.關(guān)于 hive 的跨集群數(shù)據(jù)同步

• 關(guān)于 hive的跨集群數(shù)據(jù)同步，hive 社區(qū)在推動(dòng) hive replication 的方案，但因?yàn)樵摲桨傅母鞣N前提和限制，目前該方案在業(yè)界采用的比較少;
• 市面上采用的較多的hive的跨集群數(shù)據(jù)同步，是對hive的元數(shù)據(jù)和數(shù)據(jù)分別進(jìn)行數(shù)據(jù)同步;
• 對于 hive 數(shù)據(jù)的同步，本質(zhì)上就是對于底層 hdfs 數(shù)據(jù)的同步，可以采用上述hdfs的distcp方案;
• 對于hive元數(shù)據(jù)的同步，本質(zhì)上就是對底層 metastore db，如 mysql/posggresql 等rdbms中的數(shù)據(jù)的同步，可以采用成熟的 mysqldump 和 source方案。

8.常用命令總結(jié) 

• 執(zhí)行數(shù)據(jù)同步操作時(shí)，需要停止對目標(biāo)目錄的其它寫操作;
• 當(dāng)沒有對原目錄的寫操作時(shí)(即停止了對源目錄的寫操作)，可以使用以下命令來跨集群同步數(shù)據(jù)：hadoop distcp -delete -update -pugpb -m 10 -bandwidth 5 hdfs://xx.xx/ hdfs://yy.yy/
• 當(dāng)有對原目錄的寫操作時(shí)(即有對原目錄的并發(fā)寫操作)，需要結(jié)合快照機(jī)制來同步數(shù)據(jù)：hadoop distcp -diff -update -pugpb
• 結(jié)合快照機(jī)制來同步數(shù)據(jù)時(shí)，有以下前提要求：
  
  • 需要源目錄下有指定的兩個(gè)快照 from_snapshot 和 to_snapshot;
  • 需要目標(biāo)目錄下有快照 from_snapshot;
  • 需要目標(biāo)目錄在前期制作了 from_snapshot 快照后，沒有新的文件寫操作如 create/rename/delete (即要求目標(biāo)目錄的當(dāng)前狀態(tài)跟原目錄的from-snapshot一致);
  • 該命令執(zhí)行完畢后，目標(biāo)目錄下并不會(huì)自動(dòng)創(chuàng)建快照 to_snapshot，如果后續(xù)還需要基于快照來做增量同步，需要手工在同步完畢后對目標(biāo)目錄制作快照 to_snapshot，為后續(xù)基于快照的同步(hadoop distcp -diff -update)做好準(zhǔn)