希望實(shí)現(xiàn)數(shù)據(jù)基礎(chǔ)設(shè)施的現(xiàn)代化并將Hadoop遷移到云平臺(tái)中嗎？以下是組織在數(shù)據(jù)遷移之前需要問(wèn)的五個(gè)問(wèn)題：

1.遷移的數(shù)據(jù)量是多少？

組織有幾種方法可以將少量數(shù)據(jù)傳輸?shù)皆破脚_(tái)，特別是在數(shù)據(jù)是靜態(tài)并且不變的情況下。其面臨的風(fēng)險(xiǎn)在于認(rèn)為同樣的方法也適用于大量數(shù)據(jù)，尤其是當(dāng)這些數(shù)據(jù)在遷移到云中時(shí)發(fā)生變化時(shí)。如果數(shù)據(jù)集很大并且是靜態(tài)的，則組織需要在開(kāi)始遷移之前了解是否有足夠的時(shí)間和帶寬，或者是否有足夠的時(shí)間將其加載到批量傳輸設(shè)備上（如AWS Snowball或Azure data Box），將設(shè)備運(yùn)送到云計(jì)算服務(wù)提供商那里進(jìn)行上傳。

當(dāng)遷移大量不斷變化的數(shù)據(jù)時(shí)，可能會(huì)出現(xiàn)真正的挑戰(zhàn)。在這種情況下，適用于小型數(shù)據(jù)集的方法不會(huì)有效，可能面臨系統(tǒng)停機(jī)，從而導(dǎo)致嚴(yán)重的業(yè)務(wù)中斷和數(shù)據(jù)遷移項(xiàng)目失敗。選擇通過(guò)網(wǎng)絡(luò)傳輸大量數(shù)據(jù)的組織，通常無(wú)法考慮為其他業(yè)務(wù)流程共享這一網(wǎng)絡(luò)資源。即使有專用的網(wǎng)絡(luò)通道也需要考慮到這一點(diǎn)，因?yàn)榻M織通常不會(huì)在影響其他用戶和進(jìn)程的情況下使用所有帶寬進(jìn)行數(shù)據(jù)遷移。

組織需要確保有適當(dāng)?shù)臋C(jī)制來(lái)確保充分控制數(shù)據(jù)，以免對(duì)業(yè)務(wù)造成不良影響。在許多情況下，沒(méi)有進(jìn)行控制就開(kāi)始移動(dòng)數(shù)據(jù)的組織最終會(huì)影響其他業(yè)務(wù)的運(yùn)行，因此不得不停止遷移，并在工作日結(jié)束時(shí)重新啟動(dòng)數(shù)據(jù)遷移。

2.在遷移過(guò)程中，如何在數(shù)據(jù)源和目的地之間保持一致的數(shù)據(jù)？

當(dāng)組織需要遷移不斷變化的數(shù)據(jù)時(shí)（無(wú)論是接收新數(shù)據(jù)還是更新或刪除現(xiàn)有數(shù)據(jù)），都可以進(jìn)行選擇。組織可以在數(shù)據(jù)源凍結(jié)數(shù)據(jù)直到遷移完成，或者允許數(shù)據(jù)在目的地繼續(xù)更改。在這種情況下，需要弄清楚如何考慮這些更改，以便在遷移完成后不會(huì)獲得已經(jīng)嚴(yán)重過(guò)時(shí)的副本。

為了防止數(shù)據(jù)源和目的地之間的數(shù)據(jù)不一致，需要找到一種方法來(lái)識(shí)別和遷移可能發(fā)生的任何更改。典型的方法是執(zhí)行多次迭代以重新掃描數(shù)據(jù)集，并捕獲自從上次迭代以來(lái)的更改。這種方法使組織可以迭代到一致?tīng)顟B(tài)。但是，如果組織有足夠大的數(shù)據(jù)量并且經(jīng)常變化，則可能永遠(yuǎn)無(wú)法趕上更改的步伐。這是一個(gè)相當(dāng)復(fù)雜的問(wèn)題，組織很多時(shí)候并沒(méi)有真正預(yù)料到這將對(duì)其資源和業(yè)務(wù)產(chǎn)生全面的影響。

另一種選擇是在數(shù)據(jù)源凍結(jié)數(shù)據(jù)，以防止發(fā)生任何更改。這無(wú)疑使遷移任務(wù)變得簡(jiǎn)單得多。使用這種方法，無(wú)論是通過(guò)網(wǎng)絡(luò)連接還是通過(guò)批量傳輸設(shè)備上傳到新位置的數(shù)據(jù)副本，都與數(shù)據(jù)源中存在的數(shù)據(jù)一致，因?yàn)樵谶w移過(guò)程中不允許進(jìn)行任何更改。

這種方法的問(wèn)題在于，它可能導(dǎo)致系統(tǒng)停機(jī)并且業(yè)務(wù)可能中斷。這些系統(tǒng)是對(duì)業(yè)務(wù)至關(guān)重要的，而依賴它們的業(yè)務(wù)流程通常無(wú)法嘗試將其關(guān)閉或凍結(jié)很長(zhǎng)時(shí)間。使用批量傳輸設(shè)備，可能需要幾天到幾周的時(shí)間才能完成傳輸。如果通過(guò)專用網(wǎng)絡(luò)連接傳輸數(shù)據(jù)，則取決于可用的網(wǎng)絡(luò)帶寬。為了在1GB的網(wǎng)絡(luò)鏈路上移動(dòng)1PB的數(shù)據(jù)，則需要90天以上的時(shí)間。對(duì)于絕大多數(shù)組織來(lái)說(shuō)，數(shù)天、數(shù)周或數(shù)月的停機(jī)時(shí)間和業(yè)務(wù)中斷是無(wú)法接受的。

3.將如何處理遷移過(guò)程的人工處理或任何中斷？

如果組織停止了數(shù)據(jù)遷移或發(fā)生了中斷，如何確定要從中恢復(fù)的點(diǎn)，以確切地知道已經(jīng)正確遷移了多少數(shù)據(jù)。根據(jù)所使用的工具，是否有可能從那時(shí)開(kāi)始恢復(fù)工作，或者組織是否必須從頭開(kāi)始有效地重新開(kāi)始該過(guò)程？這是一個(gè)復(fù)雜的問(wèn)題，如果組織不得不意外中斷并繼續(xù)進(jìn)行遷移，則采用人工處理流程會(huì)帶來(lái)巨大的風(fēng)險(xiǎn)和成本。人工同步處理數(shù)據(jù)的任何嘗試都會(huì)占用大量資源，成本高昂且容易出錯(cuò)。嘗試在兩個(gè)環(huán)境中人工執(zhí)行這一操作都很困難，如果嘗試在多個(gè)環(huán)境中執(zhí)行這一操作，則要復(fù)雜得多。

在Hadoop中擁有深厚技術(shù)專長(zhǎng)的組織將采用DistCp（分布式副本），并且希望利用這一免費(fèi)開(kāi)源工具來(lái)開(kāi)發(fā)自己的自定義遷移腳本。然而，DistCp是為集群間/集群內(nèi)復(fù)制而設(shè)計(jì)的，而不是為大規(guī)模數(shù)據(jù)遷移而設(shè)計(jì)的。DistCp只支持特定時(shí)間點(diǎn)的單向數(shù)據(jù)復(fù)制。它不能適應(yīng)不斷變化的數(shù)據(jù)，并且需要對(duì)數(shù)據(jù)源進(jìn)行多次掃描以獲取每次運(yùn)行之間所做的更改。這些限制帶來(lái)了許多復(fù)雜的問(wèn)題。組織最好使用新的云計(jì)算環(huán)境，將其資源用于開(kāi)發(fā)和創(chuàng)新，而不是構(gòu)建自己的遷移解決方案。

4.是否需要一個(gè)同時(shí)支持?jǐn)?shù)據(jù)源和目標(biāo)更改的混合云環(huán)境？

混合云的部署越來(lái)越受歡迎。這可能需要將公共云與私有云或組織的內(nèi)部部署基礎(chǔ)設(shè)施一起使用。對(duì)于真正的混合云方案，更改必須能夠在任何位置發(fā)生，并且其更改需要傳遞到其他系統(tǒng)。而只考慮單向數(shù)據(jù)遷移的方法不支持真正的混合云方案，因?yàn)樗鼈冃枰獢?shù)據(jù)源和目的地的聯(lián)系。

當(dāng)組織在超出兩個(gè)端點(diǎn)遷移數(shù)據(jù)時(shí)，這將變得更加復(fù)雜。人們看到越來(lái)越多的分布式環(huán)境中不僅有一個(gè)數(shù)據(jù)源和一個(gè)目的地，而且有多個(gè)云計(jì)算區(qū)域用于冗余目的，甚至采用多個(gè)云計(jì)算提供商的服務(wù)。為了避免將鎖定在單點(diǎn)解決方案中，組織需要能夠跨多個(gè)端點(diǎn)管理實(shí)時(shí)數(shù)據(jù)。在這種情況下需要一個(gè)解決方案，該解決方案可以跨多個(gè)環(huán)境復(fù)制更改，并解決任何潛在的數(shù)據(jù)更改沖突（最好在沖突發(fā)生之前解決）。

5.存在哪些導(dǎo)致數(shù)據(jù)引力驅(qū)動(dòng)的應(yīng)用程序依賴關(guān)系？

數(shù)據(jù)引力是指數(shù)據(jù)吸引應(yīng)用程序、服務(wù)和其他數(shù)據(jù)的能力。數(shù)據(jù)量越大，吸引更多應(yīng)用程序和服務(wù)所需要的引力就越大。數(shù)據(jù)引力通常還會(huì)驅(qū)動(dòng)應(yīng)用程序之間的依賴關(guān)系。

例如，可能有一個(gè)應(yīng)用程序?qū)⒘硪粋€(gè)應(yīng)用程序的輸出作為輸入，進(jìn)而可以向更下游的其他應(yīng)用程序提供數(shù)據(jù)。設(shè)計(jì)給定應(yīng)用程序的業(yè)務(wù)部門或用戶將知道他們的輸入是什么，但他們可能并不知道每個(gè)人都在使用他們創(chuàng)建的數(shù)據(jù)。錯(cuò)過(guò)這種依賴關(guān)系變得非常容易。當(dāng)應(yīng)用程序移至云平臺(tái)中時(shí)，其生成的結(jié)果數(shù)據(jù)將不會(huì)同步遣返回內(nèi)部部署環(huán)境，并且其他工作流中的其他應(yīng)用程序可能突然無(wú)法獲取當(dāng)前的數(shù)據(jù)。

許多組織在嘗試將其數(shù)據(jù)遷移到云平臺(tái)時(shí)遭遇失敗?；卮鹨陨线@五個(gè)問(wèn)題可以在成功遷移或陷入數(shù)據(jù)遷移陷阱（可能會(huì)浪費(fèi)組織的時(shí)間和資金，并影響業(yè)務(wù)運(yùn)營(yíng)）之間進(jìn)行區(qū)分。
責(zé)編AJX