故事背景
企業現狀
2019年年初，我接到了一個神秘電話，電話那頭竟然准確的說出了我的昵稱：上海小胖。
我想這事情不簡單，就回了句：您好，我是小胖，請問您是？
“我就是剛剛加了你微信的 xxx 啊”
哦……他只是把我的微信昵稱報出來了……
隨着深入溝通，了解到對方是某央企保密單位的大數據部門技術負責人，因為目前整個集團在進行數字化轉型。在決策過程中，遇到了幾個阻力。
首先，大部分部門和科室的數據基礎還很薄弱，存在數據標准混亂、 數據質量層次不齊、各條塊之間數據孤島化嚴重等現象，阻礙了數據的共享應用。
其次，受限於數據規模和數據源種類的豐富程度，多數企業的數據應用剛剛起步，主要集中在精准營銷，輿情感知和風險控制等有限場景，應用深度不夠，應用空間亟待開拓。
再次，由於數據的價值很難評估，企業難以對數據的成本以及其對業務的貢獻進行評估，從而難以像運營有形資產一樣管理數據資產。
而這位技術負責人本着認真、負責、專研的精神，死磕大數據領域，試圖在市面上找到一款能夠滿足他需求的產品，幫助他解決數據痛點。
經過溝通，了解到目前的企業數據現狀是：
- 數據散落在各部門科室，8大部門共50+科室
- 數據量非常大，高峰期每小時可產生100GB數據，每天存量數據 1TB
- 數據類型豐富，包括：
- 關系型數據庫：Oracle，MySQL，PostgreSQL，GBase，GauseDB等
- 非關系型數據庫：MongoDB
- 結構化文件：XML，Excel，CSV，TXT
- 非結構化文件：音頻，視頻，pdf
- 每個月都會有 5 個新項目，而每次對接新項目都需要花費 1-3個月時間在數據對接上
- 項目周期長，而大多數時間都在數據冗余、清洗、過濾上
- 多副本數據帶來的數據維護成本也在不斷增加，影響了研發進度
考慮遷移
在堅定不移的執行數字化轉型戰略，打贏傳統數據組織轉向大數據生態的攻堅戰中，技術負責人悟出了一個道理，要打贏這場硬仗，必須得做數據整合！
要做數據整合，那不就是傳統數據倉庫和數據湖嗎？在技術負責人經過一番市場調研后發現，數據倉庫和數據湖都無法滿足他心中的未來大數據架構。
那是什么樣的數據架構無法滿足呢？面向應用開發的共享數據
簡而言之就是，數據倉庫和數據湖無法做即時交付，目前的應用場景還是如上文提到的：應用深度不夠，應用空間亟待開拓。
經過幾番調研后，技術負責人找到一款產品Tapdata，用他的原話說就是：“這款產品的理念很先進，可以說和我的想法不謀而合。”
擴展開來說就是：
- 通過數據同步完成數據匯聚、采集工作
- 通過數據發布對外提供數據服務
- 通過數據治理對數據資產進行有效管理
而最重要的是數據是可被重復使用，可實時交付的。
解決方案
架構
Tapdata 的數據同步工具，只需要簡單的拖拉拽，就可以完成多源數據庫的同步。同時依賴於靈活的 js 腳本能力，對復雜的 ETL 場景也可以非常輕松搞定。
那這里就上一個當時給技術負責人就他們企業現狀做的架構圖，因為本篇文章是在討論數據遷移，所以我就給出數據同步的架構圖。
整個架構采取 mongodb 分片集群作為底層存儲，使用數據同步工具將多源數據實時抽到 mongodb 中，在抽取過程中完成數據清洗、過濾。
技術實現
在使用數據同步工具做數據遷移的時候，需要和用戶溝通具體場景，比如：
- 本次目標是一次性數據導入，還是需要之后保持增量同步
- 數據遷移中有沒有復雜的ETL場景
- 對同步延時要求
- 同步的數據量預估，高峰預估
在明確目標和需求后，我們采取了多節點分布式采集的方式來滿足應用高峰時產生的數據量，根據當時預估高峰每小時 100GB，一天存量 500GB 計算。
通過數據工具將不同的數據源，通過任務編排的方式進行組合，完成數據清理工作。
用戶本次數據同步要求更多是在數據同步性能及數據量上，對數據的ETL沒有過多的要求，都是一些簡單的字段重命名，字段類型轉換
所以通過數據同步工具只需要 1 分鍾即可完成從源端數據庫到目標端 mongodb 的同步工作。
創建數據源
編排任務
和實施前對比
目前上線的數據源有 Oracle、MongoDB、MySQL、PostgreSQL、GBase。數據庫集群數量達到10+套，同時支撐3條完整業務線運作，並發高峰達到 18w/秒。
有效解決了當時阻礙技術負責人執行的最大障礙：大數據量的數據同步工作，及落地后的數據管理。
新增業務時，用戶技術人員只需要做簡單的拖動就可以完成。減少了技術人員的開發工作，幫助技術人員將更多的時間聚焦在核心業務上。極大縮短了項目上線周期。
孤兒文檔
現象
在運行了一段時間后，在一次新應用接入后，發現接入的數據有重復，通過TD的數據比對工具發現源端 mongo 和目標端 mongodb 在相同表的數據量上確實存在差異。
這個事情對於數據同步工具來說是非常致命的，數據同步最核心的能力就是要保障數據的一致性，而數據同步工具的數據冪等性也是經過中國軟件評測中心的測試認證的。
對於該現象的發生，我們團隊非常重視，如果真是同步工具導致的數據不一致性，那就是致命bug。需要回歸所有功能。
排查
隨機便在第一時間聯系上用戶技術，並開展了一系列的排查工作。
確認數據庫類型
排查第一步就是確認源端和目標端的數據庫類型和操作系統配置。
本次出現數據重復的任務涉及到的數據庫情況是：
- 源端數據庫
- mongo 3.2
- 單實例副本集
- 64c 256GB SAS硬盤
- 萬兆光纖內網
- 目標端數據庫
- mongo 4.0
- 6分片集群
- 64c 256GB SAS硬盤
- 萬兆光纖內網
找出重復數據
既然有重復數據，那我們就要先找出這些數據來。
源端數據庫是 mongo，目標端也是 mongo，這就比較好辦了，寫一套 js 腳本即可。這里會有一個坑，后面會說到，就是分片集群需要去每個節點上查，而不要在 mongos 上查。
腳本很簡單，因為數據同步工具在同步的時候是會根據業務主鍵同步的，所以我就可以在目標端集合中，遍歷每條數據，然后拿着業務主鍵去源端數據庫查詢，比對所有值。
這個過程會很慢，但只能等。
當然要注意的是，由於源端數據庫是單節點，所以理論上應該同步一份數據出來作比對會好些，但是由於該業務還沒上線，所以影響不大。而目標端數據的話是可以通過查找從節點數據進行比對的。
比對結果就是二十幾張表一共 1kw 的數據，有十幾萬重復。看起來這個重復的數據量還不少。
這里我定義的重復數據就是相同的業務主鍵應該是數據唯一的，但在目標端卻查到不止一條。
檢查數據同步工具日志
現在有了重復數據，就可以去數據同步工具日志里查詢了。
在同步過程中是否有出現數據重復，或者 ERROR，如果發現有 duplicate key 字樣，那就可以順着這條記錄往下排查。
但很遺憾，在日志中並沒有發現類似字眼
檢查 mongodb 日志
數據同步工具日志無果，轉戰 mongodb 日志，通過查看 mongodb 日志，發現有大量的recvChunk 和 moveChunk 日志
看到這個，我一下子就不困了呀。
我簡單給大家說下這段日志在干嘛。因為目標端 mongodb 是分片集群，分片中有一個很重要的概念叫塊移動。分片集群是以數據塊（chunk）為最小單位進行存儲的，默認一個塊可以存儲64MB大小數據。
那這和本次的數據不一致又有什么關系呢？抖精神的地方來了，mongodb 對於均衡分片的處理方式是：先將 shard 1 節點的 chunk 拷貝到 shard 2 節點去，當 chunk 完全拷貝完成后，在將 shard 1 節點的 chunk 刪了。
那么在這個轉移的過程中，大家就可以想到，有好幾個環節都會發生意外，從而導致塊遷移失敗。
排查到這里，就有必要和用戶確認當天的操作流程了。
果不其然，當天其實發生過服務器斷網，而這個斷網就是在業務剛剛接入的10分鍾后。讓我們來還原案發現場。
用戶開啟同步任務，數據開始按預期向目標端數據庫按規則同步。
同步10分鍾后，機房斷網，此時數據同步任務處於重試階段，mongodb 集群全部斷開網絡。
斷開網絡期間，mongodb 在進行的塊遷移被迫終止。
一段時間后，網絡恢復，數據同步自動重試機制保證用戶無需人工干預，繼續開始同步任務。
mongodb 繼續開始塊遷移。
發現沒有，在第五步的時候，mongodb 的塊遷移並沒有去干預之前塊遷移失敗的結果，其實這么說不嚴謹，mongodb config server 上記錄的元數據還是認為這個塊在 shard1 上，而已經從 shard 1 節點 copy 到 shard 2 節點的數據並沒有被刪除。因此最終 count 出來的數據就會有大於原來數據總數的情況。
解決
那為了解決這個問題，其實官方是有預見的。給出了官方的解決方案。
這里我幫大家總結好了，執行下面這段腳本在各個分片節點上。
var nextKey = { };
vard result;
while ( nextKey != null ) {
result = db.adminCommand( { cleanupOrphaned: "<COLLECTION>", startingFromKey: nextKey } );
if (result.ok != 1)
print("Unable to complete at this time: failure or timeout.")
printjson(result);
nextKey = result.stoppedAtKey;
}
這段腳本就在做一件事情：找出不屬於 config 節點記錄的數據標識范圍，並將其刪除。
總結
那通過這件事情，查看官方文檔，我們總結了幾點：
在使用數據同步工具遷移數據到 mongodb 分片集群的時候，需要作如下動作
- 停止平衡器：如何停止平衡器
- 使用cleanOrphan命令：如何清理孤兒文檔
- 面對數據不一致性，排查思路可以從數據庫、同步邏輯出發
- 專業的事交給專業的人做。