巧用符號連結遷移 HDFS 資料，業務完全無感知！

問題

JuiceFS 是一個基於物件儲存的分散式檔案系統，在之前跟物件儲存比較的文章中已經介紹了 JuiceFS 能夠保證資料的強一致性和極高的讀寫效能，因此完全可以用來替代 HDFS。但是資料平臺整體遷移通常是一個費時費力的大工程，需要做到遷移超大規模資料的同時儘量不影響上層業務。下面將會介紹如何通過 JuiceFS 的遷移工具來實現平滑遷移 HDFS 中的海量資料到 JuiceFS。

平滑遷移方案

資料平臺除了我們在 HDFS 上實際看到的檔案以外，其實還有一些同樣重要的資訊，也就是所謂的「元資料」，這些元資料儲存在類似 Hive Metastore 這樣的系統裡。因此當我們談論資料遷移時不能把這兩種資料拆分開來，必須同時考慮，遷移完資料以後需要同時更新 Hive 表或者分割槽的位置（LOCATION）資訊，如果任何一種資料出了問題都會對業務方造成影響。

為了保證資料和元資料的一致性，通常的做法是在遷移完資料以後同步更新元資料中的位置資訊，但當資料規模比較大，並且業務又可能更新資料時，很難保證資料拷貝和更新位置資訊是個原子操作，遷移過程中可能導致資料丟失，影響整體遷移的可靠性。甚至需要以暫停業務為代價來實現，或者在業務中採用雙寫等機制來實現線上遷移，侵入業務邏輯，費時費力。

如果能夠在遷移過程中為資料訪問提供統一的路徑來遮蔽實際的資料位置，實現元資料和真實資料位置的解耦，將會大大降低整體遷移的風險。檔案系統的符號連結就可以達到這個效果，JuiceFS 也支援符號連結，並且支援跨檔案系統的符號連結，藉助它可以為多個檔案系統提供統一的訪問入口，形成統一名稱空間。

符號連結是作業系統中廣泛應用的概念，你可以通過符號連結實現在一個目錄樹中管理分散在各個地方的資料。對應的，我們也可以通過 JuiceFS 的符號連結特性實現在一個檔案系統中管理多個儲存系統。其實符號連結這個功能早在 2013 年 Hadoop 社群就已經想要在 HDFS 上實現（HADOOP-10019），但遺憾的是目前為止還沒完整支援。藉助符號連結即可在 JuiceFS 上管理包括但不限於 HDFS、物件儲存在內的各種儲存系統，表面上看起來訪問的是 JuiceFS，但實際訪問的是底層真實的儲存。

同時，JuiceFS 的原子重新命名（rename）操作也能在資料遷移過程中發揮關鍵作用。JuiceFS 通過符號連結來跳轉回原始資料，但當資料完全拷貝過來以後需要覆蓋這個符號連結，這個時候原子重新命名就能保證資料的安全性和可靠性，避免出現數據丟失和損壞。

此外，JuiceFS 還可以通過配置檔案和特殊的標誌檔案來動態感知到遷移過程，並在新增和刪除檔案時進行額外的檢查，確保新建立的檔案也會出現在遷移後的目錄中，並且確保要刪除的檔案也能從新系統中刪掉。對於更復雜的重新命名操作，也有類似的機制來保證正確性。

有了剛才介紹的 JuiceFS 的這些特性，就可以實現在資料遷移時分別遷移資料和元資料，同時整個遷移過程對於業務是完全透明的。下面講解具體的遷移操作步驟。

操作步驟

步驟一：將 JuiceFS 作為 HDFS 的訪問入口

在 JuiceFS 上給 HDFS 的所有第一級目錄（或檔案）建立對應的符號連結（假定不會再在 HDFS 根目錄建立內容），之後通過 jfs://name/<path> 就能完整訪問 HDFS 裡面的內容，兩者是完全等價的。如下圖所示。

步驟二：使用 JuiceFS 來訪問 HDFS 中的資料

這一步有兩種實現方法。第一種是修改 Hive Metastore 中表或者分割槽的 LOCATION 為對應的 JuiceFS 路徑，例如之前是 hdfs://ns/user/test.db/table_a，新路徑則為 jfs://name/user/test.db/table_a。第二種方法是將 fs.hdfs.impl 修改為 com.juicefs.MigratingFileSystem，這樣可以維持 LOCATION 不變。

這兩種方法的目的都是為了將所有訪問 HDFS 的入口改成訪問 JuiceFS，因為步驟一已經建立了指向 HDFS 的符號連結，所以不會影響現有業務訪問 HDFS。

步驟三：遷移目錄結構

從這一步開始我們會正式進行遷移工作，不過先不著急把資料拷貝過來，我們需要先把目錄結構從 HDFS 中對映過來。你可以選擇你想要遷移的表或目錄，然後通過 JuiceFS 提供的工具快速將 HDFS 上的目錄結構遷移到 JuiceFS 上。以遷移 hdfs://ns/user/test.db/table_a 為例，這個目錄中的所有子目錄將會逐級在 JuiceFS 中建立。因為這一步僅涉及元資料操作，沒有資料拷貝，因此可以以極快的速度將歷史資料的目錄結構從 HDFS 遷移到 JuiceFS 上。同時需要注意的是，所有檔案仍然通過符號連結的方式指向 HDFS 中的路徑。如下圖所示，紅色部分即表示在 JuiceFS 上新建立的目錄。

同樣的，完成這一步以後不會影響現有業務訪問 HDFS，但是新寫入的資料將會直接儲存到 JuiceFS 中。

步驟四：遷移資料

這一步將會真正開始拷貝資料，通過 JuiceFS 的遷移工具併發地將上一步遺留的指向 HDFS 中普通檔案的符號連結替換為真實的資料。最終遷移目錄中將不再會有符號連結，也就表示這個目錄已經遷移完成。如下圖所示，紅色部分已經從符號連結變成了普通檔案。

反向遷移

在資料遷移過程中也可以通過反向遷移隨時回滾，來撤銷遷移操作。如果已經修改了元資料中的位置資訊，JuiceFS 遷移工具能確保反向遷移時恢復回原來的狀態。如果已經有新增的資料寫入到 JuiceFS 中，也能把這些新增資料拷貝回原始的儲存系統。

總結

通過前面的操作步驟介紹，可以看到整個遷移過程完全不會影響現有業務繼續訪問 HDFS，從開始到結束對於業務來說都是無感知的。JuiceFS 提供了完善的工具來簡化遷移流程，詳細的操作指南請參考 JuiceFS 官方文件。

本篇文章以將 HDFS 遷移到 JuiceFS 為例說明了 JuiceFS 的符號連結特性，其實你完全可以發揮腦洞，把 JuiceFS 的符號連結應用在更多更廣的場景，例如在不同 HDFS 叢集之間進行資料遷移、跨雲跨區的資料遷移等。正是因為有了強大的符號連結特性，通過 JuiceFS 來提供統一的資料訪問層和檢視，才使得很多時候無法平滑操作的事情成為了可能。

推薦閱讀：知乎 x JuiceFS：利用 JuiceFS 給 Flink 容器啟動加速

如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)