本期導讀 ：【數據遷移】第二講
主題：數據無憂：利用 checksum 遷移 HDFS 數據到 OSS
講師：焱冰，阿里巴巴計算平臺事業部 EMR 技術專家
主要內容：
- Checksum 技術科普
- DistCp 技術解密
- Jindo DistCp 操作實戰
直播回放鏈接：（1/2講）
https://developer.aliyun.com/live/246728
概念簡述
DistCp & Jindo DistCp
DistCp（分佈式拷貝）是用於大規模集群內部和集群之間拷貝數據的工具。使用Map/Reduce實現文件分發，錯誤處理和恢復，以及報告生成。
Jindo DistCp，則是基於 JindoFS SDK 的阿里雲數據遷移工具。Jindo DistCp 由阿里雲 E-MapReduce 團隊開發，目前支持 HDFS/OSS/S3 之間的數據拷貝場景，提供多種個性化拷貝參數和多種拷貝策略。重點優化 HDFS 到 OSS 的數據拷貝，通過定製化 CopyCommitter，實現 No-Rename 拷貝，並保證數據拷貝落地的完整性、一致性。
Jindo DistCp 具體文檔，可參見github：
https://github.com/aliyun/alibabacloud-jindofs/tree/master/docs/jindo_distcp
數據遷移場景中的 Checksum
大數據遷移使用場景：遷移後完整性校驗、差異比對/增量拷貝。
完整性校驗的場景，特別是異構存儲介質間的遷移場景。由於異構存儲介質間，默認的數據校驗方式往往無法通用。現有的方案往往只能跳過數據完整性校驗，這使得在遷移出現問題時無法及時發現。
現有的增量拷貝方案中，開源的 Hadoop DistCp 和 S3 DistCp 也會做差異比較，在異構存儲介質間只能對文件名，文件大小做比較，不能真實反應源文件和目標文件是否完全一致。哪怕在同構存儲介質間，在做差異比較時，往往也需要將目標存儲介質的數據重新讀取，並計算一次校驗和。
Checksum 技術科普
Checksum
數據校驗和，可用於差錯檢測和完整性校驗，常見的算法有：
- 奇偶校驗
- MD5
- SHA-1
- SHA-256
- SHA-512
- CRC32
- CRC64
奇偶校驗
奇偶校驗是最簡單的校驗算法。
具體做法是，在原始數據外，新增一位奇偶校驗位，奇偶校驗位有兩種類型：
- 以偶校驗位來說，如果一組給定數據位中1的個數是奇數，補一個bit為1，使得總的1的個數是偶數。
例：0000001, 補一個bit為1, 00000011。
- 以奇校驗位來說，如果給定一組數據位中1的個數是奇數，補一個bit為0，使得總的1的個數是奇數。
例：0000001, 補一個bit為0, 00000010。
數據摘要算法
MD5、SHA-1、SHA-256、SHA-512 都是數據摘要算法，均被廣泛作為密碼的散列函數。
但由於 MD5、SHA-1 已經被證明為不安全的算法，目前建議使用較新的 SHA-256 和 SHA-512。
所有算法的輸入均可以是不定長的數據。MD5 輸出是16字節（128位）， SHA-1 輸出為20字節（160位），SHA-256 為32字節（256位），SHA-512 為64字節（512位）。
可以看到，SHA 算法的輸出長度更長，因此更難發生碰撞，數據也更為安全。但運算速度與 MD5 相比，也更慢。
循環冗餘校驗
循環冗餘校驗又稱 CRC（Cyclic redundancy check），將待發送的比特串看做是係數為 0 或者 1 的多項式。
- M = 1001010
- M(x) = 1x^6 + 0x^5 + 0x^4 + 1x^3 + 0x^2 + 1x^1 + 0*x^0
- M(x) = x^6 + x^3 + x
CRC 編碼時，發送方和接收方必須預先商定一個生成多項式 G(x)。
發送方將比特串和生成多項式 G(x) 進行運算得到校驗碼，在比特串尾附加校驗碼，使得帶校驗碼的比特串的多項式能被 G(x) 整除。接收方接收到後，除以 G(x)，若有餘數，則傳輸有錯。
CRC 常用的生成多項式（ ITU-IEEE 規範）
CRC的優缺點
CRC算法的優點是算法實現相對簡單、運算速度較快。而且錯誤檢錯能力很強，因此被廣泛應用於通信數據校驗。
缺點是輸出長度較短，容易被偽造，碰撞率高。
性能參考：CRC32 > CRC64 > MD5 > SHA-1 > SHA-512 > SHA-256
DistCp 技術解密
Hadoop DistCp
默認 Checksum 算法：CRC32
跳過 Checksum 校驗的參數：-skipcrccheck
差異比較：直接調用參數 -diff
增量拷貝：直接調用參數 –update
Hadoop 3.1.1以上版本，支持了全新組合式 CRC 文件 Checksum 。讓Hadoop 實現與外部存儲系統一致的 CRC 算法，以滿足 HDFS 和其他外部存儲系統進行差異對比。但該方案有以下缺點：源存儲介質和目標存儲介質必須使用相同的 Checksum 算法，如果是往雲上遷移，往往只能改變源端私有化存儲介質的 Checksum 算法，去適配目標介質，有一定改造成本。
S3 DistCp
默認 Checksum 算法：MD5
不支持擴展 Checksum
不支持差異比較功能
不支持一鍵增量拷貝功能
- 拷貝結束時，在-outputManifest參數指定的路徑下生成Manifest文件。
- 下次拷貝時，指定-previousManifest參數，獲取Manifest中的差異文件列表來實現增量拷貝。
其他雲廠商
- 同樣不支持一鍵增量拷貝功能。
- 差異比較時，往往需要拉取源文件重複計算Checksum。
Jindo DistCp
Checksum 算法：默認CRC32，支持CRC64
Checksum 相關的參數：默認開啟，禁用參數-disableChecksum
差異比對，增量拷貝方式與 Hadoop 社區對齊：
- --diff：指定為差異比較模式。
- --update：指定為增量Copy模式。
- 默認先比較是否存在，再比較文件大小，最後比較文件Checksum。
- 如果不希望比較文件Checksum，可以通過增加--disableChecksum參數來關閉，即只比較文件名和文件大小。
- 差異比較/增量比較時不重複計算。
橫向比較
Jindo DistCp 操作實戰
執行命令
•hadoop jar jindo-distcp-3.5.0.jar --src /user/root/random-data --dest oss://yanbin-hd2-test/distcp/ --parallelism 10
•-src：hdfs 的源路徑
•--dest：oss 的目標路徑
•--ossKey：oss 的 AccessKey
•--ossSecret：oss 的 AccessSecret
•--ossEndPoint：oss 的 endpoint 信息，可以公網或者內網的 endpoint
•--parallelism：任務併發大小，根據集群資源可調整
Jindo DistCp 高階使用實戰
禁用Checksum
•hadoop jar jindo-distcp-3.5.0.jar --src /user/root/random-data --dest oss://yanbin-hd2-test/distcp/ --parallelism 10 --disableChecksum
增量拷貝
•hadoop jar jindo-distcp-3.5.0.jar --src /user/root/random-data --dest oss://yanbin-hd2-test/distcp/ --parallelism 10 --update
差異比較時，啟用CMS告警
•export cmsAccessKeyId=<your_key_id>
•export cmsAccessSecret=<your_key_secret>
•export cmsRegion=cn-shanghai
•export cmsToken=<your_cms_token>
•export cmsLevel=WARN
•hadoop jar jindo-distcp-3.5.0.jar --src /user/root/random-data --dest oss://yanbin-hd2-test/distcp/ --diff --enableCMS
直接觀看視頻回放，獲取實例講解~https://developer.aliyun.com/live/246728
不錯過每次直播信息、探討更多數據湖 JindoFS+OSS 相關技術問題，歡迎掃碼加入釘釘交流群！
