2023年馬上結束，這一年做了不少事情，有一項我可以吹好幾年，忍不住和大家分享一下啊。
需求
去年底收到一項需求，要求2個月內從某雲端儲存遷移100PB資料到微軟雲端儲存，包含幾百億個檔案。當時聽到這個數字我都驚呆了，別說100PB，100TB之前我都沒遷移過，心裡完全沒底。但是老闆說部門目前沒有開發人員可以幹這個專案，希望我能帶隊參與。沒辦法，我只能頂著巨大的壓力參與專案的推進，核心開發人員就4位，還有售前架構師若干。
第一步就是和客戶對接瞭解業務需求和當前資料現狀，分析下來發現有幾點要處理：
- 客戶有很多零碎小檔案，這部分頻寬利用率不高，肯定無法在規定時間內傳完的，需要排除在本次任務範圍外。
- 存在很多檔案有事務性，檔案級別傳輸無法保證業務資料一致性，這部分檔案一般是各種資料表，但總量佔比低，需要單獨處理。
- 傳輸期間資料來源不下線，意味著要做增量傳輸。
- 跨雲傳輸頻寬上限不確定有多大，一開始以500Gbps為目標，後來發現天真了。
以上只是一小部分問題，實際數個月專案做下來積攢了一堆問題。
這個專案工期太緊，而且資料量巨大，傳輸一次就要數十萬美元的流量費，只能成功不能失敗，代價及其巨大！
技術方案及開發
回到開發部分，我們是4人的小型敏捷團隊，我擔任開發兼專案經理兼架構師。我們只花了2天時間就完成了各種方案和工具調研，並給出了設計的傳輸方案。
- 開源資料遷移工具，如 Hadoop 叢集 distcp 遠端複製
Apache DistCp 是一個開源工具，可用於複製大量資料。使用者可以將 DistCp 命令作為一個步 驟新增到 Hadoop 叢集中。使用 DistCp，使用者可以高效地將大量資料從來源雲端儲存複製到目標 HDFS 儲存服務中。
DistCp使用MapReduce以分散式方式進行復制。它將檔案和目錄列表擴充套件為對映任務的輸入，每個任務將複製源列表中指定的檔案的分割槽。它跨多個伺服器排程複製、錯誤處理、恢復和報告結果等任務。因此我們經常在Hadoop叢集之間使用DistCp進行大規模分散式資料複製。
該方案優點如下：
-
- 開源工具，無任何許可成本
- 支援Hadoop叢集間大規模複製資料
- 對HDFS支援很完善
- Apache基金會專案，專案持續被維護更新
缺點：
-
- 存在功能使用限制，如不能在預先存在的目標目錄下建立父源目錄等問題
- 雲端Hadoop叢集使用需要適配並整合DistCp驅動
- 難以定製複製邏輯，擴充性差
- 無法限制頻寬佔用
- 無法處理來源雲端儲存中檔案發生版本更新的情況，不滿足需求
- 商用SaaS資料遷移方案，如Azure Data Factory、AWS Glue、GCP Cloud Data Fusion等
以Azure Data Factory為例，它是基於雲的ETL和資料整合服務，可讓你建立資料驅動型工作流，用於大規模排程資料移動和轉換資料。可以使用Azure資料工廠建立和計劃資料驅動型工作流（稱為管道），以便從不同的資料儲存引入資料，同時直觀地轉換資料到目標儲存中。
但該類SaaS產品傳輸效能有限無法滿足當前專案的高效能要求，適合常規資料遷移任務。
因此無論是商用的傳輸服務還是開源的Apache DistCp，都不能做到在規定時間內完成如此高的傳輸目標，最終還是決定自己定製化開發傳輸應用。
對此我們設計瞭如下關鍵特性：
- 採用1 Master Node，N個Work Node模式，實現分散式並行排程任務機制
- 採用高可用設計，單個複製任務應當能夠自動重試
- 能夠限制頻寬呼叫
- 分散式資料儲存
- 完整的任務記錄
- 高效能。能夠吞吐量達到250Gbps
我們對AzCpoy工具做了深度魔改，為此我臨時學了Go語言，將其從單機程式修改為可以群集化彈性擴張的分散式並行資料複製應用，執行在複製節點上。針對大規模任務，我們還開發了控制程式，負責管理和派發複製任務給複製節點，並引入了額外的訊息佇列和Redis快取，來實現整個分散式系統的排程。
針對併發任務的監控，我們額外引入了Azure CosmosDB作為高效能可彈性擴容的NoSQL資料庫，能夠承受每秒數萬次的查詢和寫入。此外還針對增量更新檔案的場景，開發了事件驅動的應用，用於偵聽來源雲端儲存的檔案更新事件，非同步觸發資料複製任務。
整套系統我們只花了1周時間就開發完成第一個版本，額外花了1周進行測試。4個開發每天除了吃飯睡覺就在寫程式碼，投入了巨大的心血，特別敬業。
上線
去年元旦我們的分散式複製系統正式上生產，結果第一天就出bug了，資料遷移數小時後卡住。經過緊急排查發現是排程程式的迴圈邏輯存在問題，永遠跳不出來，這是相當低階的錯誤。主要原因還是工期太趕，大家各幹各的，沒有互聯交叉審閱程式碼，因此質量不高。緊急修復後，重新上線。
結果第二天收到遷移來源的雲端儲存廠商投訴，因為我們的複製速度太快，已經擠爆了他們公網400Gbps總頻寬，影響其他客戶的使用。如果不限制資料遷移任務，將會在平臺層面封掉資料流量。
這點我很欣慰，至少證明我們開發的工具效能極高，有多少頻寬可以佔滿多少。因此緊急著手限速工作，最後將傳輸的吞吐速度限制在200-250Gbps。
上線第一個月，我們就傳輸了50PB的資料。最終傳輸了100PB的資料，整個過程中我們的工具總體魯棒性不錯，比較符合設計預期。
總結
那幾個月是我8年職業生涯以來壓力最大的時間，也是我這些年來做過最具挑戰性的專案。當然輸出的成果也非常牛，這個牛我可以吹好多年。從來沒想到我們可以做到這麼超大規模的任務，僅僅流量費就要幾十萬美元，測試一次就要幾千美元，燒掉好多臺iPhone。
面對極限的壓力，我們程式設計師總能爆發出超乎想象的能力，完全吹爆！！！