什麼是資料遷移,如何正確進行?
已發表: 2023-12-14眾所周知,對於任何企業或組織來說,資料即使不是最大的資產,也是最大的資產之一。 這項資訊並不新鮮,幾乎不需要進一步闡述,因為越來越多的大大小小的組織正在認識到數據的真正價值——尋求利用其變革力量。 僅在 2023 年,就有 91.9% 的組織透過數據和分析投資實現了可衡量的業務價值。
在某些時候,嚴重依賴數據進行策略決策的公司需要遷移其業務數據,無論是作為效能優化工作還是大規模數位轉型專案的一部分。 企業可能需要進行資料遷移並尋求資料遷移顧問協助的原因因情況而異。
在這篇文章中,我們將定義什麼是資料遷移、何時需要遷移,以及製定穩健的資料遷移策略的步驟。 此外,我們將解析企業在遷移資料時可能面臨的一些關鍵挑戰和風險,並分享 ITRex 提供的一些關於如何處理這些挑戰和風險的最佳實務技巧和建議。 繼續閱讀。
什麼是資料遷移?
從廣義上講,資料遷移意味著在 IT 系統之間移動資料。 具體來說,資料遷移是將資料從一種儲存類型傳輸到另一種儲存類型,或從一個應用程式傳輸到另一種儲存類型的過程,通常由新應用程式或軟體的實現驅動。
但是,在我們深入研究資料遷移的細節之前,解釋資料遷移、資料整合和資料複製之間的區別至關重要,這些資料可能會被錯誤地互換對待並組合在一起。 儘管它們都涉及資料移動,但這些術語是截然不同的,因為它們服務於不同的目的。 那麼,讓我們定義這些術語的含義。
資料遷移涉及處理內部訊息,而資料整合是指將異質內部和外部來源中的資料組合到單一資料倉儲或資料庫中的過程。 這樣做是為了提供整個企業所有關鍵業務資料的統一視圖。 但差異不止於此。 雖然資料遷移是一項一次性活動,當所有資料都到達其目標位置時結束,但資料整合可以是一個持續的過程。 這個持續的過程允許數據不斷即時地來回流動,這有助於加速分析,實現穩健和明智的決策,並支援日常營運。
與一次性遷移過程相反,資料複製意味著即時、根據計劃批量或按需建立多個資料副本並將其儲存在多個位置的永久過程。 該方法可以在災難發生後快速有效地恢復數據,實現更快的數據訪問,提高數據可用性,並幫助優化伺服器效能。 而且,在複製過程中,來源儲存永遠不會被刪除或放棄。 相反,資料遷移意味著一旦資料遷移到目標儲存系統,來源資料庫就停止運作。
什麼時候需要進行資料遷移?
現在我們已經為您提供了一個簡潔的資料遷移定義,並解釋了它與整合和複製過程的不同之處,讓我們探討企業可能需要進行資料遷移的原因。
以下列出了需要資料遷移時最常見的場景。
- 升級或替換可能已有數十年歷史的遺留軟體和資料庫系統
- 將來自多個不同來源的業務資料整合到一個集中儲存庫中,以消除資料孤島並獲得企業範圍資訊的單一 360 度視圖
- 可能需要資料整合或隔離的業務重組和擴張,例如合併、收購或剝離
- 遷移到基於雲端的儲存以實現可擴展性和安全性並降低與本地資料儲存相關的成本
- 採用大數據分析、物聯網、機器學習等新技術,需要不同的資料儲存與處理能力
- 遵守越來越多的數據隱私法律和法規——例如,根據數據本地化法律在受監管的數據離開本國之前對其進行本地化,或者由於居住規則的變化而重新定位數據
無論出於何種原因,資料遷移都是一項不小的任務,更不用說是一項冒險的任務,有時甚至會產生不確定的結果。 然而,選擇不遷移往往風險更大。 為了降低風險並使資料遷移變得輕而易舉,您可能需要聘請值得信賴且經驗豐富的合作夥伴來完成所有繁重的工作。
資料遷移的類型
資料遷移有多種類型,根據所涉及的特定業務需求、系統和數據,這些類型可能會重疊。 以下是最常見的資料遷移場景的概述。
儲存遷移
作為最基本的資料遷移類型,儲存遷移涵蓋了所有遷移場景,例如從本地伺服器過渡到基於雲端的儲存、從一個雲端儲存供應商切換到另一個雲端儲存供應商、或將資料從區域資料中心遷移到其他雲端儲存提供者。中央資料中心。
資料庫遷移
鑑於資料庫是透過資料庫管理系統 (DBMS) 進行管理的,資料庫遷移通常意味著從一個 DBMS 遷移到另一個 DBMS(異質遷移)或升級到相同 DBMS 的較新版本(所謂的同質遷移)。 前者的例子是從MySQL切換到PostgreSQL,或是從Oracle資料庫切換到MongoDB。
應用程式遷移
應用程式遷移是指將應用程式從一種運算環境遷移到另一種運算環境。 這只是可以結合其他幾種遷移類型的遷移類型。 此遷移場景的一些範例是將本地客戶關係管理 (CRM) 應用程式遷移到基於雲端的 Salesforce 解決方案,或將整體電子商務應用程式遷移到一組微服務。
雲端遷移
雲端遷移的關鍵面向是指將資料從本機資料庫服務移至雲端,以及在不同的基於雲端的環境之間移動,例如,從本機 Microsoft SQL Server 遷移到 Microsoft Azure SQL 資料庫。
業務流程遷移
與大規模業務流程重組計劃相關,這種類型的資料遷移需要將應用程式和關鍵業務資料(例如業務指標、流程或營運資訊)轉移到新環境。
資料遷移方法
儘管制定資料遷移策略的方法不只一種,但大多數方法基本上屬於兩個最常見的類別之一,每種方法都有自己的優點和限制。 他們來了。
大爆炸移民
在大爆炸遷移中,整個資料資產透過單一操作從來源系統傳輸到目標環境。 雖然可能需要一段時間,但對於用戶來說,感覺就像擺脫舊系統並在某個時間點啟動新系統,這類似於大爆炸,因此得名。
從好的方面來說,大爆炸方法允許在盡可能短的時間內切換到新系統,從而省去了同時使用舊系統和新資料庫的麻煩。
不利的一面是,大爆炸式遷移通常需要係統停機,這意味著只要資料經過轉換並移動到目標儲存系統,系統就會對其用戶保持不可用。 考慮到這一點,此類遷移需要在下班後或非高峰時段(例如週末或公共假期)執行,因為此時用戶預計不會使用系統。 此外,來源系統中累積的千兆位元組和兆兆位元組的資料可能會導致傳輸過程中的網路擁塞,從而可能導致資料遺失,或在最好的情況下導致資料傳輸緩慢。 因此,Big Bang 的採用可能適合那些不產生大型資料集且能夠承受停機時間的小型公司。
涓流遷移
顧名思義,Trickle Migration 方法相反,是以更小的、可管理的區塊的形式遷移資料。 此策略允許同時運行舊系統和目標系統,直到企業準備好最終切換到新系統。 這有助於消除停機時間並減少網路擁塞問題,從而降低錯誤或意外故障的可能性。 資料遷移在背景持續進行,這對於需要在資料傳輸期間保持運作的系統尤其重要。
然而,與大爆炸策略不同,迭代遷移無論是在規劃或執行方面都是一個時間和資源密集的過程。 遷移團隊必須確保目標系統與來源系統保持同步,並執行持續的資料驗證和測試,以確保整個遷移過程中資料的一致性和完整性。 在這方面,對於使用大型資料集且停機時間容忍度較低的組織來說,選擇採用滴流遷移方法可能是最佳選擇。
資料遷移過程:如何順利進行
現在您已經完全了解了資料遷移的含義、其類型、重要性和方法,現在是我們深入研究資料遷移過程的細節的時候了。
無論採用哪種方法,每個資料遷移專案都會經歷相同的關鍵階段。 在較高層面上,這些階段通常包括遷移前規劃、實施和遷移後審核。 每個階段又可以根據具體的業務需求和要求進一步細分為多個階段。 以下概述了正確進行資料遷移的基本步驟。
規劃
全面的策略規劃是資料遷移專案成功的關鍵。 通常從評估現有資料集並制定清晰的計劃開始 - 您應該準確地了解需要遷移哪些資料、需要遷移到哪裡以及如何將其遷移到那裡。 規劃階段也可能涉及以下步驟。
- 檢查來源資料並識別資料格式、位置、結構和屬性
- 選擇合適的目標儲存解決方案並分析目標系統,以確定來源資料是否適合新環境以及需要重構哪些內容以適應目標的規範
- 選擇最合適的資料遷移方法(大爆炸或涓流)
- 分配最適合的資源、設定預算並定義資料傳輸時間表
- 資料審核
在資料遷移之前,對要移動的資料執行完整的審核至關重要。 資料審計的目的是檢測資料品質問題,例如重複記錄、不準確或不一致,並在繼續之前排除這些問題,以確保只有高品質的資料傳輸到新系統。 這就是統包資料品質解決方案可能派上用場的地方。
刪除過時的數據
識別並刪除新系統中不需要的未使用或過時的物件。 刪除過時的資料可以使您的遷移更加順利,同時還允許您的團隊在遷移後使用乾淨的資料集。
資料備份
儘管在技術上不是強制性的,但備份資料(最好是在多個位置)是實施遷移時的最佳實踐。 這將在遷移失敗時提供額外的保護層。
遷移設計
這裡詳細介紹遷移過程,即設定目標環境、執行徹底的資料映射、定義遷移和測試規則、編寫驗收標準、分配遷移角色和職責以及指定資料遷移技術和方法。
對於後者,有多種資料遷移方法可以將資料從來源系統傳輸到目標系統。 例如實體儲存遷移、備份與復原、1:1 複製(批次 EL)或 ETL 技術(代表擷取、轉換、載入)等。 至於資料遷移工具,最常見的工具包括 AWS Database Migration Service、Azure Data Box、Apache NiFi 或符合特定和複雜遷移需求的自訂 Python 腳本。
執行和測試
這是遷移實際發生的地方。 強大的資料遷移過程需要定期測試,以確保資料按照規範進行轉換和載入。 隨著資料的移動,測試和重新測試遷移的資料以驗證其完整性、準確性和可靠性至關重要。 頻繁或持續的測試是絕對必要的,以查看來源系統是否有任何故障和停機的跡象,並儘快糾正問題。
遷移後審計
實施完成後,對遷移結果進行審核至關重要,以確認資料是否已安全遷移到目標基礎設施以及是否完整且可行。 一旦新系統上線並完美運行,您就可以安全地停用舊環境。
資料遷移挑戰:需要注意什麼
一旦您意識到您的業務需要資料遷移作為現代化專案的一部分,那麼清楚地了解您可能遇到的挑戰就至關重要。
遷移可能是實施中最複雜和最具挑戰性的部分之一,因為有許多問題可能會阻礙資料遷移過程。 考慮一下:根據 Gartner 的數據,超過 83% 的資料遷移專案要么失敗,要么超出預算和時間表。 大多數時候,這是因為組織忽略了風險或低估了成功的資料遷移過程所需的工作,將資料遷移視為只是從 A 點遷移到 B 點。為了防止資料遷移工作付諸東流,強烈建議您在開始資料遷移計劃之前註意資料遷移風險和挑戰。 以下是關鍵考慮因素的清單。
營運中斷和停機
在資料遷移方面實現業務連續性可能非常具有挑戰性,因為組織必須平衡資料完整性的需求和保持系統正常運作的要求。 對於產生大量數據且無法承受任何停機時間的公司來說尤其如此。 雖然存在不可避免的計劃內停機(就像大爆炸資料遷移方法一樣),但您的業務流程可能會由於傳輸故障、應用程式效能問題或您未能計劃的其他一系列緊急情況而意外停止。初始階段。
低估成本
預算可能決定資料遷移計劃的成敗。 正是對成本的低估使資料遷移專案面臨風險。 如果您未能考慮資料遷移實施的所有方面,包括隱藏的間接成本,例如與計劃外停機或緊急情況相關的成本,您可能會發現自己處於意外地遠遠超出指定預算的情況。 正如 Gartner 所說,對於資料遷移項目,成本平均超支 30%。
數據映射不良
由於資料庫架構的差異,舊系統中的資料欄位可能與新系統中的資料欄位不同步。 因此,僅嘗試映射欄位並將資料塞入目標系統可能會造成損失。 不完整或不準確的資料映射可能會導致某些資料元素被放置在不正確的欄位中,這可能需要大量時間和精力來進行定期更新和欄位重新映射。
資料安全與合規性
在遷移過程中確保法律合規性和敏感資料的安全性會增加專案的複雜性。 在處理客戶的個人資料時,您必須了解並尋求遵守不同地區不同的隱私和資料保護法規的方法。 問題是,在美國,沒有全面的聯邦資料保護立法。 相反,各州和行業的法規差異很大。 相較之下,在歐盟,資料受到《一般資料保護規範》(GDPR) 的保護。 這個統一的資料隱私規則框架對資料持有者施加了嚴格的義務,並禁止將個人資料轉移到缺乏足夠資料保護措施的第三國。 只有在歐盟委員會發布充分性決定的情況下,才能進行這些轉移。
因此,在跨大西洋資料流方面,尋求防止 GDPR 違規的方法成為首要問題,因為這些違規行為可能會招致制裁,科技巨頭 Meta 就被處以破紀錄的 13 億美元 GDPR 罰款。— GDPR 歷史上規模最大的一次。
抵制變革
大規模資料遷移會立即產生整個宇宙的變化,這總是讓系統使用者感到沮喪。 由於習慣了在現有資料庫上執行查詢,使用者可能很難適應新的環境和資料格式的變化,這往往表現為對變化的抵制。
ITRex 團隊的資料遷移最佳實踐
以下是 ITRex 大數據顧問提供的一些明確指南,可協助您應對上述列出的資料遷移風險和挑戰:
- 制定中斷計劃,以最大程度地減少停機時間或減輕其發生時的影響。 是的,你沒聽錯。 您肯定想知道如何在任何情況下都能繼續前進,不是嗎? 這就是為什麼建立強大的顛覆準備策略至關重要。 制定一個具體的業務連續性計劃,概述一系列災難場景和恢復方法,是保護您的業務運營免受長期中斷並幫助其在最短的時間內恢復正常的可靠方法。 對於不可避免的停機時間,在組織方便的時間正確安排停機時間是確保無縫資料遷移的好方法,同時最大限度地減少意外問題或意外減速的可能性。
- 準確估算資料遷移成本,同時專注於潛在的隱性成本。 其中包括管理應用程式依賴性、僱用外部承包商、運行額外測試週期以及解決資料品質問題的成本。 運行同一系統的重複版本以及生產力損失和遷移後問題也會顯著增加成本。 總的來說,從長遠來看,這些因素加起來會導致預算超支。
- 在編寫映射腳本之前,必須分析所有來源資料以確定其結構、品質和關係。 在資料載入之前執行全面的來源到目標資料映射是確保所有資料準確放置的關鍵步驟。
- 在遷移敏感資料時,優先考慮資料安全和隱私因素變得至關重要。 確保敏感資料在傳輸過程中和新環境中得到安全處理。 您可能希望應用資料加密、匿名或屏蔽技術來在整個遷移過程中保護敏感資料。 此外,請確保資料遷移符合相關資料保護法規,例如 GDPR 或行業特定指南。
- 儘管經常被忽視,但基於角色和職責的客製化使用者培訓可以使您的資料遷移過程和結果發生巨大變化。 分配足夠的時間和預算來重新培訓現有團隊有助於在資料遷移期間和之後實現更平穩的過渡,確保用戶接受度,並有助於最大限度地減少營運中斷。 最好儘早即將進行的資料遷移和實踐培訓課程進行溝通,以便讓用戶有機會在實際資料遷移發生之前接受變革。 這種溝通還可以幫助他們做好準備,更好地理解新環境並在新環境中運作。
以下是 ITRex 資料遷移團隊提供的一些同樣重要的提示:
- 評估、理解並證明遷移到新技術的必要性,而不是匆忙加入潮流——您應該對自己想要什麼以及為什麼想要它有一個清晰的願景。 遷移會有什麼好處?
- 建立概念驗證 (PoC) — 首先進行小規模嘗試並試水,然後再完全致力於資料遷移。
- 探索替代方案並評估與每個選項相關的風險和效益。 還有哪些技術可以完成相同的工作? 為什麼選擇這個?
- 評估新技術的限制。 例如,Oracle 和許多其他關聯式資料庫管理系統 (RDBMS) 常見的儲存程序可能無法以相同的形式在基於雲端的大規模平行處理 (MPP) 資料倉儲中使用。
- 評估是否需要重寫資料處理邏輯。
- 評估您的用戶可能受到的影響,並考慮為您的客戶和員工建立單點聯絡點,以幫助應對他們遇到的任何挑戰。
整合所有內容:為何進行資料遷移
在數位轉型方面,開展資料遷移計畫是必然而非選擇。 就資料遷移而言,變更是不可避免的,但也充滿了一定的風險、不確定性和考慮因素。 將資料遷移視為重要創新過程的一部分就成功了一半。
現在您已經充分了解了什麼是資料遷移以及為什麼需要它,您將可以更輕鬆地開始資料遷移專案。
83% 的失敗率並不一定意味著您的資料遷移計劃從一開始就注定會失敗。 雖然資料遷移可能具有挑戰性並且有些令人沮喪,但只要製定了精心策劃的資料遷移策略,一切都應該一帆風順。 我們希望我們的頂級資料管理專家提出的針對性建議和最佳實踐將為您帶來好處。
想要了解什麼是資料遷移以及如何正確進行資料遷移? 請隨時給我們留言。 透過我們的資料遷移團隊提供的經過驗證的方法,最大限度地發揮資料遷移的優勢。
本文最初發佈於 ITRex 網站。