使用DistCp將Hadoop進行雲遷移時注意事項

這個免費工具最初與 Hadoop 捆綁在一起，用於在單個時間點傳輸資料的大型叢集間和叢集內資料複製。隨著組織著手將其資料和基礎架構遷移到雲中，DistCp 開始被視為遷移專案的一部分。
問題是 DistCp 從未被設計用於大規模 Hadoop 到雲的遷移。
需要明確的是，DistCp 有其用途，但也有非常明顯的侷限性。讓我們來看看 DistCp 有什麼好處，它對雲遷移有什麼問題，以及使用它將海量資料集遷移到雲中的風險。
 

DistCp 對 Hadoop 到雲遷移的好處
DistCp 是一種可行的解決方案，用於複製在 Hadoop 叢集之間不經常更改的相對較少量的資料。DistCp 適用於資料量相對較小（例如小於 100 TB）且遷移期間資料更改最少的情況。如果要移動的資料集在遷移過程中沒有發生快速變化（例如每秒少於 50-100 個事件），那麼 DistCp 可以是一種具有成本效益的資料遷移技術。DistCp 非常適合在遷移完全不變的歷史資料時使用。
 

使用 DistCp 進行 Hadoop 到雲遷移的缺點
在使 DistCp 成為基於雲的遷移的首選解決方案時，公司會陷入三個常見的資料陷阱。

1. 在遷移方面，公司錯誤地認為小資料和大資料是相同的。公司錯誤地假設用於小資料的方法同樣適用於大量資料。如果資料集是靜態的，那麼問題是是否有足夠的頻寬來遷移資料，或者是否有足夠的時間將其載入到批次傳輸裝置上，例如 AWS Snowball 或 Azure Data Box，並將該裝置運送到雲服務提供商，然後上傳。這類解決方案很少實用，因為大多數大型資料集都在不斷變化，而且公司很少承擔關閉運營的費用，即使是很短的一段時間。
2. 遷移開始後，公司錯過了對源資料進行的更新。在遷移正在發生變化的資料時，一種解決方案是讓資料在源頭繼續變化，在這種情況下，需要考慮所有這些變化，以確保在遷移完成時，沒有複製到已經嚴重過時的雲中。為了防止源和目標之間的資料不一致，需要有一種方法來識別和遷移可能發生的任何更改。典型的方法是執行多次迭代，重新掃描資料集，並捕獲自上次迭代以來的變化。這種方法允許架構師迭代地接近一致的狀態。但是，如果有大量資料頻繁更改，則可能無法完全趕上對源資料所做的更改。
3. 公司錯誤地選擇了需要在源頭凍結資料的遷移方法，從而導致業務中斷另一種選擇是在源處凍結資料以防止發生任何更改。這使遷移任務變得更加簡單，因為管理員可以確信上傳到新位置的資料副本與源中存在的資料副本是一致的，因為在遷移過程中不允許進行任何更改。這種方法的問題是系統需要關閉，導致業務中斷的時間不可接受。透過 1 Gb 的鏈路移動 PB 的資料需要 90 多天，而且對於絕大多陣列織來說，數天、數週或數月的停機時間是不可接受的。

使用 DistCp 進行 Hadoop 到雲的遷移是有風險的
許多公司最初被DistCp吸引，因為它很熟悉--他們已經使用DistCp進行叢集內的資料移動--而且它是免費的。然而，使用DistCp往往會導致隱性成本、專案延遲和某種形式的業務中斷，因為DistCp是為舊的、企業內部的備份用例而建立的，而云計算架構師正朝著新的、基於雲的模式發展。使DistCp適應這些現代資料架構和基於雲的策略的勞動密集型性質意味著，使用DistCp需要定製指令碼開發、手動遷移管理和複雜的變化調節--所有這些往往會增加整個遷移專案的隱藏成本、時間和精力。原本可能被認為是一個具有成本效益的、簡單的將資料遷移到雲端的方法，往往會變成一個複雜的問題，沒有簡單的解決方案。