什麼是資料移轉？：如何規劃資料移轉

主題

分享本頁

資料移轉這項程序是指在不同的地點、格式或應用程式之間移動資料，通常是由於引進新的資料系統或資料地點所致。其商業驅力通常是應用程式遷移或整併，而需要以全新的應用程式取代或增強老舊系統，以共享同一資料集。如今，企業往往是為了最佳化或業務轉型而開始資料移轉，以便從內部部署的基礎架構和應用程式，將資料移轉至雲端型儲存設備和應用程式。

為什麼資料移轉會被認為困難且風險重重？

簡單來說，是因為資料引力 (data gravity)。雖然資料引力的概念已有一段時日，但隨著資料移轉到雲端基礎架構，挑戰也變得更艱鉅。簡而言之，資料引力是一個比喻，它描述了：

資料在成長時如何吸引其他資料
資料如何整合到業務中
資料如何隨時間進行自訂

為了將應用程式和資料移轉到更有利的環境，Gartner 建議「梳理」資料和應用程式，作為克服資料引力的一種手段。企業可以在專案開始階段理清資料和應用程式之間的複雜性，藉此改善資料管理，實現應用程式的移動性，並完善資料管制。

主要問題在於，每個應用程式都會將應用程式的邏輯元素引進資料管理層，這會使資料管理變得越來越複雜，而且每個應用程式並不在乎下一個資料使用案例，不同的業務流程都是獨自使用資料，輸出自己的格式，然後將整合問題留給下一個流程自己去解決。因此，雖然應用程式設計、資料架構和業務流程必須相互呼應，但往往總有一方無法或不願意更改自己的做法。於是，應用程式管理員不得不放棄理想中的簡單工作流程，導致設計結果總是差強人意。而且，儘管當時可能基於必要而採取某種權宜做法，但這些遺留留下的技術債最終還是必須在資料移轉或整合專案期間加以解決。

鑑於這種複雜性，請考慮將資料移轉提升至「策略武器」等級，使其獲得適當的認知和資源水準。為了確保專案獲得所需的關注，請將重點放在移轉過程中最能鼓舞士氣的元素上，也就是舊系統將關閉的事實，您一定可以吸引重要相關人員的注意，我們保證。

資料移轉的類型

升級系統或將資料中心延伸至雲端，具有諸多商業優勢。對許多企業來說，這是一個非常自然的演變過程。使用雲端的公司希望能協助員工將精力集中在業務優先事項上、帶動頂尖業務成長、提高敏捷度、降低資本支出，並隨需付費。然而，所進行的移轉類型將決定 IT 員工可以騰出多少時間來處理其他專案。

首先，我們來定義移轉類型：

儲存設備移轉：此過程會將資料從現有陣列移至更現代化的陣列，以供其他系統存取。這樣做可顯著提高效能，進行更具成本效益的擴充，同時使用如複製、快照、備份與災難恢復等符合期望的資料管理功能。
雲端移轉：此過程會將資料、應用程式或其他業務元素，從內部部署資料中心移至雲端，或是從一個雲端移至另一個雲端。在許多情況下，這也需要進行儲存設備移轉。
應用程式移轉：將應用程式從一個環境移至另一個環境的過程。可能包括將整個應用程式從內部部署 IT 中心移至雲端、在雲端之間移動，或者只是將應用程式的基礎資料移至軟體供應商代管的新形式應用程式。

如何規劃資料移轉

資料移轉需要 3 個基本步驟：

擷取資料
轉換資料
載入資料

移轉重要或敏感資料，還有汰換舊有系統，都可能會讓相關人員如履薄冰。完善的計畫是一定要的；但是，您不必多此一舉，因為在網路上就可以找到許多資料移轉計畫範例和檢查清單。譬如，Data Migration Pro 就是一個由資料移轉專業人員組成的社群，他們提供一份完整的檢查清單，其流程粗略包括以下 7 個階段：

移轉前規劃：評估要移動的資料以確保穩定性。
專案啟動：找出重要相關人員並向其進行簡報。
環境分析：建立健全的資料品質規則管理程序，並向業務部門簡報專案目標，包括關閉舊有系統。
解決方案設計：決定要移動的資料，以及移動前後資料的品質。
構建與測試：編寫移轉邏輯程式碼，然後使用正式作業環境的鏡射來測試移轉作業。
執行與驗證：證明移轉作業可符合所有要求，且移轉後的資料可供業務使用。
卸任與監控：關閉並處置舊系統。

這似乎是一項艱鉅的工作，但並非每次移轉都需要執行上述所有步驟。每種情況各不相同，每家公司都會以不同的方式來處理這項任務。

十大資料移轉挑戰

儘管幾十年來資料移轉一直是 IT 運作中的一部分，但每年仍有令人震驚的事件發生。以下是企業在移動資料時面臨的十大挑戰：

未聯繫重要相關人員：無論移轉規模為何，都有人在意您要搬移的資料。在開始執行任務之前，請先找出這些人，向其說明專案的必要性及影響。否則，您肯定會在某個階段聽到議論聲，他們很可能會打亂您的時間表。
不與企業溝通：向相關人員說明專案後，請務必讓他們瞭解您的進度。最好固定在每週的某一天提供狀態報告，尤其是在實際情況偏離預期時。定期溝通對於與所有受影響的人建立信任，有很大的幫助。
缺乏資料管制：請務必清楚知道誰有權在來源系統中建立、核准、編輯或移除資料，並將這些資訊以書面形式記錄在專案計畫中。
專業知識匱乏：雖然這是一項簡單的工作，但移轉資料涉及許多複雜因素。擁有經驗豐富的專業人員及出色的參考資料，有助於順利完成此過程。
缺乏規劃：一個家庭平均花 10 至 20 小時規劃度假行程，而 IT 團隊可能只有一半時間來規劃小型資料移轉。費心數小時的規劃，不一定能保證成功，但制定可靠的資料移轉計畫，確實可以省下數小時的實際資料移動時間。
資料準備軟體和技能不足：如果是大規模移轉（數百萬筆記錄或數百張資料表），請投資一流的資料品質軟體，並考慮聘請專業公司協助。好消息：有外部公司可能將軟體租給您，協助您節省成本。
等待目標到達完美規格：如果實作團隊正在彙整設計準則，請繼續執行步驟 2 和 3。目標就緒在專案後期會很重要，但現在不要讓它阻礙您。
移轉方法未經實證：進行一些研究，以確保資料移動程序對像您這樣的其他公司來說效果卓著。請克制住誘惑，不要接受供應商提供的泛用程序。
供應商與專案管理：廠商與專案必須加以管理。如果您同時還要處理日常工作，請確保有時間管理專案及任何相關供應商。
跨物件相依性：雖然目前有可用的資料管理工具技術和功能，但發現原始計畫中未包含相關資料集依然晴天霹靂。由於常常到遷移過程的後期才發現跨物件相依性，因此請務必擬定應變計畫，以免無法達成整體交付日期。

資料移轉 vs.資料轉換 vs.資料整合

資料移轉和資料轉換這兩個詞彙，有時會在網際網路上交替使用，所以讓我們來澄清一下：它們的含義不同。如前面所述，資料移轉是指在不同位置、格式或系統之間移動資料的過程。資料移轉包括目標系統中的資料剖析、資料清理、資料驗證，以及持續的資料品質保證流程。在典型的資料移轉情境中，資料轉換只是複雜程序的第一步。

「資料轉換」一詞是指將資料從一種格式轉換為另一種格式的過程。將資料從舊版應用程式移至同一個應用程式的升級版本，或者移至具有新結構、完全不同的應用程式時，則必須執行轉換。進行轉換時，必須根據一組需求，從來源擷取資料、進行變更，然後載入新的目標系統。

另一個詞彙有時會與資料移轉混淆，那就是資料整合。資料整合是指組合不同來源的資料，讓使用者能夠統一檢視所有資料的過程。整合來自多個來源的資料，是資料分析不可或缺的要素。資料整合的範例包括資料倉儲、資料湖和 NetApp^® FabricPools，它們可在內部部署資料中心和雲端之間自動進行資料分層，或者在 AWS EBS 區塊儲存與 AWS S3 物件存放區之間自動分層資料。