故事背景

企業現狀

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命令：如何清理孤兒檔案
• 面對資料不一致性，排查思路可以從資料庫、同步邏輯出發
• 專業的事交給專業的人做，

標籤：其他

上一篇：培訓機構出來的程式員和科班比？看看這個科班畢業生怎么說~

下一篇：【自考】資料結構第五章圖，期末不掛科指南，第9篇