貝殼金服 TiDB 在線跨機房遷移實踐

做者介紹 ： 李振環，貝殼金服數據基礎架構負責人，目前負責數據平臺和企業級數據倉庫開發。

公司介紹

貝殼金服是專一居住場景的金融科技服務商，起步於2006年成立的鏈家金融事業部，並於 2017年3月正式獨立運營。

貝殼金服聚焦於居住場景，在租賃、買賣、家裝、安居等場景中爲用戶提供定製化的居住金融服務。貝殼金服以獨家大數據與場景風控能力見長，致力於解決居住金融需求，以Fintech驅動產業升級，讓每一個家庭都能享受高品質的居住生活。

截至2018年末，貝殼金服業務已覆蓋全國90多個城市及地區，爲超過130萬用戶提供了金融服務。

項目背景

貝殼金服數據中臺使用 TiDB 和 TiSpark 平臺，基於 Syncer 將業務數據實時從 MySQL 備庫抽取到 TiDB 中，並經過 TiSpark 對 TiDB 中的數據進行數據分析處理，供上游業務消費，現已服務於 70 多名數據開發人員。現有集羣已經使用 100 多個 Syncer 同步上游 MySQL 數據，目前已經達到 4.7TB 熱數據，上百張離線和實時報表。因爲機房調整，數據中臺也須要同步遷移到新機房，結合 TiDB 的特性，咱們探索了一種在線不停機遷移機房的方式。

TiDB 是一個分佈式 NewSQL 數據庫。它支持水平彈性擴展、ACID 事務、MySQL 語法，具備數據強一致的高可用特性，是一個不只適合 OLTP 場景還適合 OLAP 場景的混合數據庫。而 TiSpark 是爲解決較重的 OLAP 需求而推出的產品。它藉助 Spark 平臺，同時融合 TiKV 分佈式集羣的優點，和 TiDB 一塊兒爲用戶一站式解決 HTAP 的業務需求。TiSpark 依賴於 TiKV 集羣和 PD 組件，使用同一個數據源，減小對於 ETL 工具的維護，而且可使用 Spark 進行復雜查詢計算。

圖 1 貝殼金服總體數據架構圖

業務類型

因爲原有 MySQL 數據庫提供服務很是吃力，使用 100 多個 Syncer 同步上游的 MySQL 數據，而 TiDB 做爲一個數據中臺，主要使用 TiSpark 在作查詢。

集羣規模

圖 2 集羣拓撲圖

遷移實踐

遷移業務挑戰

本次數據遷移主要有兩個關鍵因素：

1. 儘量減小對業務的影響，業務方但願服務不能中斷超過 1 小時。

2. 因爲跨機房網絡帶寬有限，而且與線上業務共用跨機房網絡專線，在遷移過程當中須要能控制遷移速度，在白天線上業務繁忙時以較慢的速度遷移，等到晚上業務空閒時加快遷移速度。另外網絡運維同事若是發現流量過載，爲了避免影響其餘業務正常網絡資源使用，可能隨時限制正在遷移的網絡帶寬，切斷遷移網絡鏈接，所以遷移方案必需要支持「斷點續傳功能」。

遷移方案設計

本次遷移最初設想了三套方案（以下），最終經過技術考察和驗證，採用了技術上更有優點的第三套方案。

方案一：只使用 Syncer 在新機房同步 ODS（Operational Data Store 操做性數據存儲）數據，而後從 ODS 數據再次所有計算 DW 和 ADM 層等數據。此方案須要遷移的數據最小，可是隻從 ODS 計算出全部的其它數據是不現實的。其中不少拉鍊表（拉鍊表是數據倉庫的數據模型設計中經常使用的數據模式，該模型記錄歷史，一般記錄一個事務從開始，一直到當前狀態的全部變化的信息）的數據都是基於歷史時間點計算出來的結果，因爲 TiDB 目前版本剛剛開始支持部分分區表功能，不能立刻用於生產。而且歷史數據沒有分區備份，歷史的拉鍊數據沒法真實還原。另外此方案業務遷移成本也很高，兩邊須要不斷校準數據，查漏補缺，從新計算全部非 ODS 層數據計算量也過大，致使遷移時間和大量人力投入。

方案二：在某個時間點將老機房數據 Dump 出來，全量導入到新機房。以後再開啓 TiDB 集羣的 Binlog 增量同步老集羣數據，待新集羣慢慢追上老集羣以後再遷移業務。這個方案中 Dump 數據沒法實現單庫 Dump。由於 Dump 出來的 Position 值不同，並且有的表沒有主鍵，屢次導入會致使數據重複。所以全量 Dump 全部數據是一個很「重」的操做，Dump 後的大文件傳輸也存在沒法斷點續傳的問題。具體存在問題以下：

• 鎖問題：全量備份時，須要對庫進行加鎖操做，若是數據量很大，備份時間較長，可能會影響業務。

• 備份失敗可能性較高：若是數據量較大，好比對 2T 的數據進行備份，可能會達到 3h 以上的備份時間，若是備份失敗，那麼此次備份就至關於不可用。

• Binlog 增量同步延遲問題：若是上游 MySQL 壓力較大，或者跨機房的網絡帶寬成爲了瓶頸，那麼增量同步可能追不上，Binlog 同步沒法控制速度，斷點續傳也須要人工參與。

• 最終數據校驗任務較重：數據遷移完成以後，須要對上下游數據進行校驗，最簡單的方式是業務校驗和對比上下游標的行數。或者使用 pt-toolkit 工具進行數據校驗。

• 停業務風險：在機房遷移完成後，業務須要中止，等待同步和數據校驗完成才能夠啓動。

方案三：採用 TiDB 原生的 Raft 三副本機制自動同步數據。在新機房添加 TiKV 節點，待數據均衡以後再下線老機房 TiKV 節點。老機房 TiKV 下線完成則表示數據遷移完成。此方案操做簡單，業務影響在分鐘級別。網絡層面能夠經過 PD 調度參數控制 TiKV 遷移速度，Raft 副本遷移若是網絡中斷會自動從新傳輸。具體優勢以下：

• 遷移數據期間不會影響線上業務，整個遷移過程都是在線提供服務的。

• 遷移效率很是高。一個機房內部 balance 3T 的數據只須要 10 小時左右，跨機房遷移通常受限於網絡。

• 容錯性高，沒有不少的人工干預，集羣高可用依然保留。

機房遷移實施過程

操做描述：

1. 配置防火牆，將兩個機房所需端口開通。

2. 新機房擴容 3+ 個 TiKV，3 個 PD，2+ 個 TiDB。

3. 執行下線 TiKV 命令，一次性下線全部舊機房的 TiKV。

4. PD Leader 手動切換到新機房，業務遷移到新機房，等待 TiKV balance 完成以後，下線舊機房的 TiKV、PD 和 TiDB。

整個過程人爲操做較少，耗時較長的只有 TiKV balance 數據的過程，能夠調整調度併發度來加速整個過程。

注意事項：

1. 新機房的 TiKV 節點儘可能要多於舊機房，不然在下線過程當中，可能因爲集羣 TiKV 實例數比之前要少，致使 TiKV 壓力較大。

2. 跨機房遷移，網絡延遲不能高於 3ms。

3. TiKV 下線過程當中， Region Leader(s) 會逐漸遷移到新機房，這時業務已經能夠並行的遷移，將壓力轉移到新機房去。

在 TiDB 中的二次開發

1. Syncer 二次開發：在貝殼金服，有 100 多個 Syncer 實時同步線上數據，因爲 TiDB 語法與 MySQL 語法不是 100% 兼容，特別是上游修改 DDL 操做，好比從 INT 改爲 VARCHAR，會致使 Syncer 同步失敗。在貝殼金服實戰中，優化了失敗恢復工做，監控程序會監控失敗緣由並自動化恢復 Syncer 錯誤。

2. TiSpark 二次開發：TiSpark 沒法實現 TiDB 數據插入和刪除。貝殼金服基於 TiSpark 二次開發封裝了 TiSpark，所以能夠實現 TiSpark 直接原生 SparkSQL 執行 Insert 、Create 操做。實現新增 executeTidbSQL 實現 delete、update、drop 操做。增長 TiSpark View 的功能，彌補現階段 TiDB 不支持 View 的問題。

3. TiSpark 權限控制：TiDB 和 TiSpark 都沒法實現基於組和大量用戶的權限控制。貝殼金服基於 Catalyst 自研了一套兼容 TiSpark SQL 和 TiDB SQL 的 SQL 解析引擎，並基於此引擎之上開發權限驗證、權限申請、權限審批、數據發現等功能。

趟過的坑

1. Region 過多：因爲 TiDB 目前版本暫不支持 Partition 功能，咱們的 job 都是須要支持能夠重複跑，所以有一些業務會直接先 drop table 而後再建立 table。默認狀況下每次建立 table 都會申請一套 Region，致使如今單臺 TiKV Region 數過載。

2. DDL 排隊執行：有一次對一個 2 億級別的大表添加索引，但願提升基於時間查詢的效率，結果致使集羣業務中全部 drop table 、create table 相關 job 所有卡住。最終了解到 DDL 是串行化操做。Add index 大操做讓其餘 DDL 操做 pending，手動 kill add index 操做後集羣恢復。目前 TiDB 2.1 版本已經將添加索引操做和其餘的 DDL 操做分開，這個問題已經解決。

3. Syncer 恢復自動化：TiDB 如今對某些 alter column sql（字段從 INT 改成 VARCHAR 的跨類型修改操做）依然不兼容，所以在上游執行不兼容 SQL 以後，Syncer 同步會失敗。修復過程須要使用到 Syncer 同步 position，DB name，table name。獲取這些信息以後能夠一個 shell 自動恢復 Syncer 同步，可是上面的三個信息輸出不夠友好，須要人爲查看才能獲取到。若是在失敗 Syncer 日誌中能夠格式化輸出以上三個信息，Syncer 恢復能夠更自動化。目前新版本的 Syncer 已經解決這個問題。

4. Decimal Hash Join 結果不正確：在使用兩個 Decimal 字段作表 join 時，發現使用 limit 能夠查詢出來數據，不 limit 返回無結果。查看執行計劃發現 limit 以後改變了執行計劃，將 HashLeftJoin 改成了 IndexJoin。調查以後發現 Decimal 在計算 hash 值時返回結果不正確，致使相同 Decimal 沒法 join 上。可使用 hint 強制使用 IndexJoin 來解決此問題。目前 TiDB 2.0.11 及以上版本已經解決了這個問題。

5. 列式存儲：因爲如今 TiDB 是行存，即便是 TiSpark 讀取 TiDB 一個字段也會在底層取出此記錄全部值，致使性能問題。在 OLAP 大寬表場景中使用列式存儲性能會顯著提高。

後續計劃

機房順利遷移完成後，後續計劃升級到 TiDB 3.0，利用 TiDB 3.0 產品路線圖中提供的新功能來優化和提高使用效果：

• 開啓 Region merge 功能，自動在後臺合併空 Region 從而減小 Region 的數量。

• 使用 3.0 所提供的視圖 View 和分區 Partition 功能。

• 嘗試 PingCAP 新一代的列計算/存儲引擎 TiFlash ，提高 OLAP 寬表查詢性能。

此外，在應用 TiDB 支持業務的過程當中，貝殼金服的技術團隊也經過自身對數據中臺的業務理解和技術實踐，打磨出瞭如下配套工具及平臺：

• 基於 TiDB 的數據發佈平臺

• 基於 TiDB 的元數據管理平臺

• 支持 TiSpark+TiDB 的權限管理系統

• 基於 Flink + TiDB 的在線 SQL 流式處理平臺

在上面這些技術成果的基礎上，貝殼金服的技術團隊正在作將來的數據中臺技術棧演進規劃，即基於 TiDB + Azkaban + 自研的數據質量平臺。