| 組織需要確保有適當的機制來確保充分控制數據，以免對業務造成不良影響。在許多情況下，沒有進行控制就開始移動數據的組織最終會影響其他業務的運行，因此不得不停止遷移，並在工作日結束時重新啓動數據遷移。 |
希望實現數據基礎設施的現代化並將Hadoop遷移到雲平臺中嗎?以下是組織在數據遷移之前需要問的五個問題：
組織有幾種方法可以將少量數據傳輸到雲平臺，特別是在數據是靜態並且不變的情況下。其面臨的風險在於認爲同樣的方法也適用於大量數據，尤其是當這些數據在遷移到雲中時發生變化時。如果數據集很大並且是靜態的，則組織需要在開始遷移之前瞭解是否有足夠的時間和帶寬，或者是否有足夠的時間將其加載到批量傳輸設備上(如AWS Snowball或Azure data Box)，將設備運送到雲計算服務提供商那裏進行上傳。
當遷移大量不斷變化的數據時，可能會出現真正的挑戰。在這種情況下，適用於小型數據集的方法不會有效，可能面臨系統停機，從而導致嚴重的業務中斷和數據遷移項目失敗。選擇通過網絡傳輸大量數據的組織，通常無法考慮爲其他業務流程共享這一網絡資源。即使有專用的網絡通道也需要考慮到這一點，因爲組織通常不會在影響其他用戶和進程的情況下使用所有帶寬進行數據遷移。
組織需要確保有適當的機制來確保充分控制數據，以免對業務造成不良影響。在許多情況下，沒有進行控制就開始移動數據的組織最終會影響其他業務的運行，因此不得不停止遷移，並在工作日結束時重新啓動數據遷移。
當組織需要遷移不斷變化的數據時(無論是接收新數據還是更新或刪除現有數據)，都可以進行選擇。組織可以在數據源凍結數據直到遷移完成，或者允許數據在目的地繼續更改。在這種情況下，需要弄清楚如何考慮這些更改，以便在遷移完成後不會獲得已經嚴重過時的副本。
爲了防止數據源和目的地之間的數據不一致，需要找到一種方法來識別和遷移可能發生的任何更改。典型的方法是執行多次迭代以重新掃描數據集，並捕獲自從上次迭代以來的更改。這種方法使組織可以迭代到一致狀態。但是，如果組織有足夠大的數據量並且經常變化，則可能永遠無法趕上更改的步伐。這是一個相當複雜的問題，組織很多時候並沒有真正預料到這將對其資源和業務產生全面的影響。
另一種選擇是在數據源凍結數據，以防止發生任何更改。這無疑使遷移任務變得簡單得多。使用這種方法，無論是通過網絡連接還是通過批量傳輸設備上傳到新位置的數據副本，都與數據源中存在的數據一致，因爲在遷移過程中不允許進行任何更改。
這種方法的問題在於，它可能導致系統停機並且業務可能中斷。這些系統是對業務至關重要的，而依賴它們的業務流程通常無法嘗試將其關閉或凍結很長時間。使用批量傳輸設備，可能需要幾天到幾周的時間才能完成傳輸。如果通過專用網絡連接傳輸數據，則取決於可用的網絡帶寬。爲了在1GB的網絡鏈路上移動1PB的數據，則需要90天以上的時間。對於絕大多數組織來說，數天、數週或數月的停機時間和業務中斷是無法接受的。
如果組織停止了數據遷移或發生了中斷，如何確定要從中恢復的點，以確切地知道已經正確遷移了多少數據。根據所使用的工具，是否有可能從那時開始恢復工作，或者組織是否必須從頭開始有效地重新開始該過程?這是一個複雜的問題，如果組織不得不意外中斷並繼續進行遷移，則採用人工處理流程會帶來巨大的風險和成本。人工同步處理數據的任何嘗試都會佔用大量資源，成本高昂且容易出錯。嘗試在兩個環境中人工執行這一操作都很困難，如果嘗試在多個環境中執行這一操作，則要複雜得多。
在Hadoop中擁有深厚技術專長的組織將採用DistCp(分佈式副本)，並且希望利用這一免費開源工具來開發自己的自定義遷移腳本。然而，DistCp是爲集羣間/集羣內複製而設計的，而不是爲大規模數據遷移而設計的。DistCp只支持特定時間點的單向數據複製。它不能適應不斷變化的數據，並且需要對數據源進行多次掃描以獲取每次運行之間所做的更改。這些限制帶來了許多複雜的問題。組織最好使用新的雲計算環境，將其資源用於開發和創新，而不是構建自己的遷移解決方案。
混合雲的部署越來越受歡迎。這可能需要將公共雲與私有云或組織的內部部署基礎設施一起使用。對於真正的混合雲方案，更改必須能夠在任何位置發生，並且其更改需要傳遞到其他系統。而只考慮單向數據遷移的方法不支持真正的混合雲方案，因爲它們需要數據源和目的地的聯繫。
當組織在超出兩個端點遷移數據時，這將變得更加複雜。人們看到越來越多的分佈式環境中不僅有一個數據源和一個目的地，而且有多個雲計算區域用於冗餘目的，甚至採用多個雲計算提供商的服務。爲了避免將鎖定在單點解決方案中，組織需要能夠跨多個端點管理實時數據。在這種情況下需要一個解決方案，該解決方案可以跨多個環境複製更改，並解決任何潛在的數據更改衝突(最好在衝突發生之前解決)。
數據引力是指數據吸引應用程序、服務和其他數據的能力。數據量越大，吸引更多應用程序和服務所需要的引力就越大。數據引力通常還會驅動應用程序之間的依賴關係。
例如，可能有一個應用程序將另一個應用程序的輸出作爲輸入，進而可以向更下游的其他應用程序提供數據。設計給定應用程序的業務部門或用戶將知道他們的輸入是什麼，但他們可能並不知道每個人都在使用他們創建的數據。錯過這種依賴關係變得非常容易。當應用程序移至雲平臺中時，其生成的結果數據將不會同步遣返回內部部署環境，並且其他工作流中的其他應用程序可能突然無法獲取當前的數據。
許多組織在嘗試將其數據遷移到雲平臺時遭遇失敗。回答以上這五個問題可以在成功遷移或陷入數據遷移陷阱(可能會浪費組織的時間和資金，並影響業務運營)之間進行區分。