小紅書MySQL數據一致性校驗能力探索與實踐
01 背景
1.1 什么是數據一致性校驗
在數據遷移、數據同步以及多數據中心部署等場景中，數據的一致性要求極為嚴格。然而冗長的同步計算鏈路產生的誤寫或丟失、主從復制延遲產生的臟讀，業務雙寫、人為誤操作產生的臟數據等眾多因素，都可能導致數據不一致。
通過建設數據一致性校驗能力，能夠及時、準確的發現并解決數據不一致問題，有效降低對業務的影響。
1.2 數據一致性校驗應具備的能力
在小紅書內部，數據傳輸服務每天服務著眾多的業務，保障著眾多的數據同步任務，在數據同步過程中，源端和目標端的數據一致性需要嚴格保證，否則將會產生業務損傷。同時，在面對不同的業務場景下，數據一致性校驗工具能夠進行無損且快速的數據校驗。因此，針對數據一致性校驗工具我們需要面對以下難點：
- 數據量和內容不斷地變化：在數據校驗過程中，源端和目標端數據的總量和內容可能都在變化，是一個動態的過程，數據校驗能力需要應對不斷變化的數據，防止產生誤報；
- 無鎖且不停服的數據校驗：數據一致性校驗不能影響現有的業務，需要在業務不停服的情況下進行，且應該在無鎖狀態進行，避免影響業務讀寫操作；
- 對數據庫的性能影響要可控：校驗工具一般都會高并發讀取數據庫的數據，然而，數據庫同時承擔著線上的業務應用。如何有效平衡數據校驗速度以及數據庫穩定性是校驗工具應該解決的重要命題。
- 適配不同數據源：由于校驗數據源具有多樣性，數據校驗需要考慮到不同數據源之間的差異，能夠在不同數據源之間實現數據校驗工作；
- 數據分布不均勻：在源端和目標端數據分布不均勻的場景下（如源端和目標端分表數量不一致），數據校驗程序能夠將源端數據正確映射到目標端，并進行數據校驗工作。
- 快速定位不一致內容：數據校驗的目的是為了驗證數據一致性，并針對不一致數據進行快速補救。所以，能夠定位并提供具體不一致的內容也是數據校驗工具的重要特質。
- 快速訂正數據的能力：當數據校驗定位到不一致內容后，是否能夠提供數據訂正腳本幫助用戶快速修復不一致數據也是校驗工具必不可少的基礎能力。
02 現狀分析
隨著小紅書公司業務的不斷發展，原先的MySQL集群容量已經無法滿足業務的發展，因此需要對原先的MySQL集群進行擴容等操作，以滿足業務不斷增長的需求。數據遷移一般需要將全部數據從源端遷移到目標數據源上，遷移通常是一次性的，遷移之后鏈路即停止。常見的場景有：
- 集群擴縮容，當預期流量增長或者資源達到瓶頸，對整個數據庫集群分片擴容，以減輕各個分片的壓力，同理預期流量下降或者資源利用率偏低時，要對集群縮容，避免資源浪費。
- 庫表遷移，由于容量或者業務邏輯變動，將數據庫集群上的部分庫或表遷出，到新的集群中，或者分表規則變更（分表鍵，分表數，分表規則變更）都需要將原有數據同步一份至新表中。
- 異構數據源遷移，比如技術升級或者存儲介質變更，需要將歷史數據同步至新的數據源。
在數據遷移過程中，我們利用自研的數據傳輸服務將數據從源集群同步到新集群。然而，網絡抖動、臟寫污染等問題可能導致源端與目標端數據出現不一致。然而，現在的一些業界解決方案可能無法滿足現在小紅書內部的復雜業務場景，我們需要一款適配上述各種場景的數據一致性校驗工具，來確保在數據傳輸過程中的數據質量，保障數據的一致性。因此，我們決定為小紅書打造一套全新的數據校驗系統，以應對內部業務的多樣化和現有基礎架構的挑戰，它融合了業界成熟的校驗技術。其主要具有以下特性：
- 允許源端和目標端數據分布不一致：數據一致性校驗工具能夠適應數據分布不一致的情況，針對單表、分庫分表等場景都能夠很好的進行校驗工作。
- 自動選擇最佳校驗方式：根據源端和目標端的表結構以及數據分布等信息，數據一致性校驗工具會自動選擇最合適的校驗方法，從而快速進行數據校驗。
- 適應動態數據變化：數據一致性校驗工具支持在數據量和內容不斷變化的情況下進行校驗。
- 無中斷&無鎖校驗：數據一致性校驗工具能在不中斷服務且無需鎖定的狀態下進行數據校驗，確保業務和同步鏈路的順暢運行。
- 校驗參數動態可配置：數據一致性校驗工具提供了一系列可配置參數，允許用戶根據需要動態調整校驗速度和批次大小。
- 快速定位不一致內容：數據一致性校驗工具在發現數據不一致時，能夠快速發現具體不一致的內容。
- 自定義列校驗和規則轉化：數據一致性校驗工具支持自定義列校驗，即使源端和目標端列名不同，也能通過配置列映射實現校驗。同時支持用戶自定義列轉化規則。
03 數據一致性校驗在小紅書內部得實現
3.1 校驗類型
按照數據校驗的方式，可以劃分為全量數據校驗和增量數據校驗：
- 全量校驗：這種方法涉及對數據庫中所有數據的一次性檢查，確保高準確度。然而，它反映的僅是校驗時刻的數據狀態。全量數據校驗又被分為同構全量數據校驗和異構全量數據校驗，通常情況下，全量數據校驗建議多次周期性運行，以確保數據一致性。
- 增量校驗：此方法基于數據變更事件，僅校驗新變更的數據，減少了校驗量并提高了實時性。但它無法覆蓋歷史數據的一致性校驗。
在實際應用中，我們會根據具體情況靈活結合這兩種校驗方式，以更有效地確保數據的準確性和時效性。
在實際實踐中，我們將全量數據校驗根據源端和目標端校驗表結構的差異又細分為同構校驗和異構校驗，它們的主要區別如下：
在實際進行全量數據校驗時，數據一致性校驗工具會自動根據源端和和目標端的數據源類型、校驗表的數據分布以及數據校驗任務配置等多種因素為校驗任務選擇合適的校驗方式，此過程中用戶不感知。
3.2 方案實現
基于實時數據流傳輸服務的特點，我們抽象了讀取端（Reader）、寫入端（Writer）和處理端（Processor）組件，實現了業務邏輯解耦。
- 讀取端（Reader）：主要負責從源端獲取數據，分為Selector和Replicator。Selector主要負責在全量數據校驗時對全量數據的抽取，而Replicator主要負責在增量數據校驗時對Binlog的解析。
- 處理端（Processor）：主要負責數據的處理、過程和加工。在數據校驗時，如果用戶自定義了列映射或者數據轉化規則，此時通過Processror可以對數據進行一次二次轉化，然后和目標端數據進行對比。
- 寫入端（Writer）：主要負責將數據寫入下游，主要包括數據校驗實時位點更新、校驗摘要更新以及校驗不一致數據的持久化等。
3.3 全量數據校驗
全量數據校驗是指對數據庫中的全量數據進行一次對比，它是一次性任務。在實際實踐中，全量數據校驗一般會被多次運行，從而確保數據的完整性和準確性。全量數據校驗需要在數據傳輸服務全量同步任務運行完成后，且增量同步任務追平延遲后開啟，否則會因為數據同步延遲導致大量數據不一致誤判。
全量數據校驗分為同構校驗和異構校驗，兩者均采用分塊抽樣校驗法。數據一致性校驗工具在執行全量校驗時，會分批次從源端和目標端提取數據塊，然后對比這些數據塊以驗證一致性。分塊策略允許用戶配置數據塊的大小，每次從數據庫中提取固定數量的數據進行校驗。一旦完成一個數據塊的校驗，程序就會繼續下一個數據塊。當提取的數據量小于設定的數據塊大小時，校驗結束。若在某個數據塊中發現不一致，將進行復檢，僅當多次校驗均不一致時，才會記錄為數據不一致。采用分塊校驗的原因包括：
- 提高校驗效率：避免一次性處理大量數據，減少對比時間，加快整體校驗速度。
- 減少業務影響：分塊校驗減輕了對業務數據庫的讀取壓力，避免對業務操作造成顯著影響。
同構全量數據校驗通過校驗和（checksum）實現，因為上下游數據分布是均勻的，我們可以通過主鍵對數據進行分塊的checksum校驗。在此過程中，待校驗表的數據被劃分為多個固定大小的校驗塊（chunk）。在特定時刻，源端和目標端的對應數據塊將進行整體Hash校驗和（如CRC32），以判斷數據是否一致，同構校驗過程中，校驗塊的大小可以動態調整，設置過大可能會增大數據庫壓力，同時可能會因為區間過大導致區間數據不一致概率大；設置過小，可能會降低校驗速度。在實際應用中，業務可以根據上下游數據庫的指標以及數據變化情況進行動態調整數據塊的大小。
當校驗過程中，發現某個 chunk 的上下游的 checksum 不一致，通過二分法將原來的 chunk 劃分成大小接近的兩個子 chunk，對子 chunk 進行 checksum 對比，進一步縮小不一致行的可能范圍。通過 checksum 對比不斷的縮小不一致行的可能范圍，可以減少需要進行逐行對比的數據行，加快對比速度，減少內存損耗，并且由于每次計算 checksum 都相當于遍歷一次二分后的子 chunk，理論上不考慮多次額外消耗，二分檢驗的開銷相當于只對原 chunk 多做兩次 checksum，當chunk大小變成1時，即可找到對應的不一致記錄。但是，在一個校驗塊內，如果我們發現源端的數據比目標端數據要少，我們會通過逐行對比的方式去尋找出不一致的數據。
異構全量數據校驗采用逐行對比的方法。在執行校驗時，系統會分批次從源端提取數據，并通過一系列預設規則進行處理，以便與目標端的數據進行比較。一旦發現數據不一致，系統將自動進行復檢，且復檢的間隔時間會逐漸延長，呈指數級增長。這種機制旨在減少對系統的不必要負擔，同時確保數據的準確性。
3.4 增量數據校驗
增量數據校驗專注于驗證數據遷移、同步或更新過程中新增或修改的數據，確保數據的完整性和準確性，對保持數據一致性和可靠性至關重要。數據一致性校驗工具的增量校驗功能實時監控源端數據變更，并與目標端數據進行比對。它與全量數據校驗獨立運行，用戶可按需選擇是否啟用增量校驗。
增量校驗以源端數據庫為基準，利用其binlog來驅動校驗過程。通過主鍵或唯一鍵，系統會檢索目標數據庫中相應的行數據，進行一致性對比。考慮到數據同步或校驗任務可能存在延遲以及數據頻繁變更等問題，實際的源端與目標端數據庫數據可能比已消費的binlog位點更新。為應對這種情況，我們設計了延遲點查以及復查機制來對兩邊數據庫的當前數據執行一致性比對，確保數據的準確性。
04 總結與展望
4.1 階段性總結
小紅書MySQL數據一致性校驗工具自上線以來，已經在數據庫遷移、單元化等重要場景得到了很好的應用，為小紅書內部業務提供了數據一致性保障。
4.2 展望
后續關于數據一致性校驗將在以下方面繼續深入建設。
- 增強產品成熟度：持續深化現有功能，簡化操作流程，提升用戶體驗。后續會豐富數據源，支持更多的端到端異構數據校驗。
- 擴展產品應用范圍：進一步擴展至數據入湖入倉、數據變更訂閱、緩存更新等場景，以全面提升數據傳輸的服務質量，同時支持用戶定制業務邏輯，支持對賬等復雜場景。
- 提升數據修復效率：完善數據修復功能，減少手動操作，降低成本，提供一鍵生成修復SQL能力，快速進行回歸驗證。
- 完善數據質量大盤：提供歸因分析能力，對產生的不一致數據進行原因推測，建立質量大盤。
05作者簡介
初原（張勇）
小紅書關系型數據庫部研發工程師，數據庫中間件小組成員，畢業于西北工業大學，現主要負責小紅書數據傳輸服務的日常維護與迭代。
元甲（鄭云龍）
小紅書關系型數據庫部研發工程師，數據庫中間件小組成員，畢業于浙江大學，曾就職于美團基礎架構中間件中心，目前是小紅書數據傳輸服務負責人。
克邪（沈力鍇）
小紅書關系型數據庫部研發工程師，數據庫中間件小組負責人，畢業于中國科學技術大學，現主要負責小紅書數據傳輸服務、數據庫代理和數據庫SDK等數據庫中間件產品的整體架構和技術演進。
