摘要：截至年底，貝殼金服業(yè)務已覆蓋全國多個城市及地區(qū)，為超過萬用戶提供了金融服務。老機房下線完成則表示數(shù)據(jù)遷移完成。機房遷移實施過程操作描述配置防火墻，將兩個機房所需端口開通。執(zhí)行下線命令，一次性下線所有舊機房的。跨機房遷移，網(wǎng)絡延遲不能高于。

作者介紹 ：
李振環(huán)，貝殼金服數(shù)據(jù)基礎架構(gòu)負責人，目前負責數(shù)據(jù)平臺和企業(yè)級數(shù)據(jù)倉庫開發(fā)。

貝殼金服是專注居住場景的金融科技服務商，起步于2006年成立的鏈家金融事業(yè)部，并于 2017年3月正式獨立運營。

貝殼金服聚焦于居住場景，在租賃、買賣、家裝、安居等場景中為用戶提供定制化的居住金融服務。貝殼金服以獨家大數(shù)據(jù)與場景風控能力見長，致力于解決居住金融需求，以Fintech驅(qū)動產(chǎn)業(yè)升級，讓每個家庭都能享受高品質(zhì)的居住生活。

截至2018年底，貝殼金服業(yè)務已覆蓋全國90多個城市及地區(qū)，為超過130萬用戶提供了金融服務。

貝殼金服數(shù)據(jù)中臺使用 TiDB 和 TiSpark 平臺，基于 Syncer 將業(yè)務數(shù)據(jù)實時從 MySQL 備庫抽取到 TiDB 中，并通過 TiSpark 對 TiDB 中的數(shù)據(jù)進行數(shù)據(jù)分析處理，供上游業(yè)務消費，現(xiàn)已服務于 70 多名數(shù)據(jù)開發(fā)人員。現(xiàn)有集群已經(jīng)使用 100 多個 Syncer 同步上游 MySQL 數(shù)據(jù)，目前已經(jīng)達到 4.7TB 熱數(shù)據(jù)，上百張離線和實時報表。由于機房調(diào)整，數(shù)據(jù)中臺也需要同步遷移到新機房，結(jié)合 TiDB 的特性，我們探索了一種在線不停機遷移機房的方式。

TiDB 是一個分布式 NewSQL 數(shù)據(jù)庫。它支持水平彈性擴展、ACID 事務、MySQL 語法，具有數(shù)據(jù)強一致的高可用特性，是一個不僅適合 OLTP 場景還適合 OLAP 場景的混合數(shù)據(jù)庫。而 TiSpark 是為解決較重的 OLAP 需求而推出的產(chǎn)品。它借助 Spark 平臺，同時融合 TiKV 分布式集群的優(yōu)勢，和 TiDB 一起為用戶一站式解決 HTAP 的業(yè)務需求。TiSpark 依賴于 TiKV 集群和 PD 組件，使用同一個數(shù)據(jù)源，減少對于 ETL 工具的維護，并且可以使用 Spark 進行復雜查詢計算。

由于原有 MySQL 數(shù)據(jù)庫提供服務非常吃力，使用 100 多個 Syncer 同步上游的 MySQL 數(shù)據(jù)，而 TiDB 作為一個數(shù)據(jù)中臺，主要使用 TiSpark 在做查詢。

本次數(shù)據(jù)遷移主要有兩個關(guān)鍵因素：

盡可能減少對業(yè)務的影響，業(yè)務方希望服務不能中斷超過 1 小時。

由于跨機房網(wǎng)絡帶寬有限，并且與線上業(yè)務共用跨機房網(wǎng)絡專線，在遷移過程中需要能控制遷移速度，在白天線上業(yè)務繁忙時以較慢的速度遷移，等到晚上業(yè)務空閑時加快遷移速度。另外網(wǎng)絡運維同事如果發(fā)現(xiàn)流量過載，為了不影響其他業(yè)務正常網(wǎng)絡資源使用，可能隨時限制正在遷移的網(wǎng)絡帶寬，切斷遷移網(wǎng)絡連接，因此遷移方案必須要支持“斷點續(xù)傳功能”。

本次遷移最初設想了三套方案（如下），最終通過技術(shù)考察和驗證，采用了技術(shù)上更有優(yōu)勢的第三套方案。

方案一：只使用 Syncer 在新機房同步 ODS（Operational Data Store 操作性數(shù)據(jù)存儲）數(shù)據(jù)，然后從 ODS 數(shù)據(jù)再次全部計算 DW 和 ADM 層等數(shù)據(jù)。此方案需要遷移的數(shù)據(jù)最小，但是只從 ODS 計算出所有的其它數(shù)據(jù)是不現(xiàn)實的。其中很多拉鏈表（拉鏈表是數(shù)據(jù)倉庫的數(shù)據(jù)模型設計中常用的數(shù)據(jù)模式，該模型記錄歷史，通常記錄一個事務從開始，一直到當前狀態(tài)的所有變化的信息）的數(shù)據(jù)都是基于歷史時間點計算出來的結(jié)果，由于 TiDB 目前版本剛剛開始支持部分分區(qū)表功能，不能馬上用于生產(chǎn)。并且歷史數(shù)據(jù)沒有分區(qū)備份，歷史的拉鏈數(shù)據(jù)無法真實還原。另外此方案業(yè)務遷移成本也很高，兩邊需要不斷校準數(shù)據(jù)，查漏補缺，重新計算所有非 ODS 層數(shù)據(jù)計算量也過大，導致遷移時間和大量人力投入。

方案二：在某個時間點將老機房數(shù)據(jù) Dump 出來，全量導入到新機房。之后再開啟 TiDB 集群的 Binlog 增量同步老集群數(shù)據(jù)，待新集群慢慢追上老集群之后再遷移業(yè)務。這個方案中 Dump 數(shù)據(jù)無法實現(xiàn)單庫 Dump。因為 Dump 出來的 Position 值不一樣，而且有的表沒有主鍵，多次導入會導致數(shù)據(jù)重復。因此全量 Dump 所有數(shù)據(jù)是一個很“重”的操作，Dump 后的大文件傳輸也存在無法斷點續(xù)傳的問題。具體存在問題如下：

鎖問題：全量備份時，需要對庫進行加鎖操作，如果數(shù)據(jù)量很大，備份時間較長，可能會影響業(yè)務。

備份失敗可能性較高：如果數(shù)據(jù)量較大，比如對 2T 的數(shù)據(jù)進行備份，可能會達到 3h 以上的備份時間，如果備份失敗，那么這次備份就相當于不可用。

Binlog 增量同步延遲問題：如果上游 MySQL 壓力較大，或者跨機房的網(wǎng)絡帶寬成為了瓶頸，那么增量同步可能追不上，Binlog 同步無法控制速度，斷點續(xù)傳也需要人工參與。

最終數(shù)據(jù)校驗任務較重：數(shù)據(jù)遷移完成之后，需要對上下游數(shù)據(jù)進行校驗，最簡單的方式是業(yè)務校驗和對比上下游標的行數(shù)。或者使用 pt-toolkit 工具進行數(shù)據(jù)校驗。

停業(yè)務風險：在機房遷移完成后，業(yè)務需要停止，等待同步和數(shù)據(jù)校驗完成才可以啟動。

方案三：采用 TiDB 原生的 Raft 三副本機制自動同步數(shù)據(jù)。在新機房添加 TiKV 節(jié)點，待數(shù)據(jù)均衡之后再下線老機房 TiKV 節(jié)點。老機房 TiKV 下線完成則表示數(shù)據(jù)遷移完成。此方案操作簡單，業(yè)務影響在分鐘級別。網(wǎng)絡層面可以通過 PD 調(diào)度參數(shù)控制 TiKV 遷移速度，Raft 副本遷移如果網(wǎng)絡中斷會自動重新傳輸。具體優(yōu)點如下：

遷移數(shù)據(jù)期間不會影響線上業(yè)務，整個遷移過程都是在線提供服務的。

遷移效率非常高。一個機房內(nèi)部 balance 3T 的數(shù)據(jù)只需要 10 小時左右，跨機房遷移一般受限于網(wǎng)絡。

容錯性高，沒有很多的人工干預，集群高可用依然保留。

操作描述：

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

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

執(zhí)行下線 TiKV 命令，一次性下線所有舊機房的 TiKV。

PD Leader 手動切換到新機房，業(yè)務遷移到新機房，等待 TiKV balance 完成之后，下線舊機房的 TiKV、PD 和 TiDB。

整個過程人為操作較少，耗時較長的只有 TiKV balance 數(shù)據(jù)的過程，可以調(diào)整調(diào)度并發(fā)度來加速整個過程。

注意事項：

新機房的 TiKV 節(jié)點盡量要多于舊機房，否則在下線過程中，可能由于集群 TiKV 實例數(shù)比以前要少，導致 TiKV 壓力較大。

跨機房遷移，網(wǎng)絡延遲不能高于 3ms。

TiKV 下線過程中， Region Leader(s) 會逐漸遷移到新機房，這時業(yè)務已經(jīng)可以并行的遷移，將壓力轉(zhuǎn)移到新機房去。

Syncer 二次開發(fā)：在貝殼金服，有 100 多個 Syncer 實時同步線上數(shù)據(jù)，由于 TiDB 語法與 MySQL 語法不是 100% 兼容，特別是上游修改 DDL 操作，比如從 INT 改成 VARCHAR，會導致 Syncer 同步失敗。在貝殼金服實戰(zhàn)中，優(yōu)化了失敗恢復工作，監(jiān)控程序會監(jiān)控失敗原因并自動化恢復 Syncer 錯誤。

TiSpark 二次開發(fā)：TiSpark 無法實現(xiàn) TiDB 數(shù)據(jù)插入和刪除。貝殼金服基于 TiSpark 二次開發(fā)封裝了 TiSpark，因此可以實現(xiàn) TiSpark 直接原生 SparkSQL 執(zhí)行 Insert 、Create 操作。實現(xiàn)新增 executeTidbSQL 實現(xiàn) delete、update、drop 操作。增加 TiSpark View 的功能，彌補現(xiàn)階段 TiDB 不支持 View 的問題。

TiSpark 權(quán)限控制：TiDB 和 TiSpark 都無法實現(xiàn)基于組和大量用戶的權(quán)限控制。貝殼金服基于 Catalyst 自研了一套兼容 TiSpark SQL 和 TiDB SQL 的 SQL 解析引擎，并基于此引擎之上開發(fā)權(quán)限驗證、權(quán)限申請、權(quán)限審批、數(shù)據(jù)發(fā)現(xiàn)等功能。

Region 過多：由于 TiDB 目前版本暫不支持 Partition 功能，我們的 job 都是需要支持可以重復跑，因此有一些業(yè)務會直接先 drop table 然后再創(chuàng)建 table。默認情況下每次創(chuàng)建 table 都會申請一套 Region，導致現(xiàn)在單臺 TiKV Region 數(shù)過載。

DDL 排隊執(zhí)行：有一次對一個 2 億級別的大表添加索引，希望提高基于時間查詢的效率，結(jié)果導致集群業(yè)務中所有 drop table 、create table 相關(guān) job 全部卡住。最終了解到 DDL 是串行化操作。Add index 大操作讓其他 DDL 操作 pending，手動 kill add index 操作后集群恢復。目前 TiDB 2.1 版本已經(jīng)將添加索引操作和其他的 DDL 操作分開，這個問題已經(jīng)解決。

Syncer 恢復自動化：TiDB 現(xiàn)在對某些 alter column sql（字段從 INT 改為 VARCHAR 的跨類型修改操作）依然不兼容，因此在上游執(zhí)行不兼容 SQL 之后，Syncer 同步會失敗。修復過程需要使用到 Syncer 同步 position，DB name，table name。獲取這些信息之后可以一個 shell 自動恢復 Syncer 同步，但是上面的三個信息輸出不夠友好，需要人為查看才能獲取到。如果在失敗 Syncer 日志中可以格式化輸出以上三個信息，Syncer 恢復可以更自動化。目前新版本的 Syncer 已經(jīng)解決這個問題。

Decimal Hash Join 結(jié)果不正確：在使用兩個 Decimal 字段做表 join 時，發(fā)現(xiàn)使用 limit 可以查詢出來數(shù)據(jù)，不 limit 返回無結(jié)果。查看執(zhí)行計劃發(fā)現(xiàn) limit 之后改變了執(zhí)行計劃，將 HashLeftJoin 改為了 IndexJoin。調(diào)查之后發(fā)現(xiàn) Decimal 在計算 hash 值時返回結(jié)果不正確，導致相同 Decimal 無法 join 上?？梢允褂?hint 強制使用 IndexJoin 來解決此問題。目前 TiDB 2.0.11 及以上版本已經(jīng)解決了這個問題。

列式存儲：由于現(xiàn)在 TiDB 是行存，即使是 TiSpark 讀取 TiDB 一個字段也會在底層取出此記錄所有值，導致性能問題。在 OLAP 大寬表場景中使用列式存儲性能會顯著提升。

機房順利遷移完成后，后續(xù)計劃升級到 TiDB 3.0，利用 TiDB 3.0 產(chǎn)品路線圖中提供的新功能來優(yōu)化和提升使用效果：

開啟 Region merge 功能，自動在后臺合并空 Region 從而減少 Region 的數(shù)量。

使用 3.0 所提供的視圖 View 和分區(qū) Partition 功能。

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

此外，在應用 TiDB 支持業(yè)務的過程中，貝殼金服的技術(shù)團隊也通過自身對數(shù)據(jù)中臺的業(yè)務理解和技術(shù)實踐，打磨出了以下配套工具及平臺：

基于 TiDB 的數(shù)據(jù)發(fā)布平臺

基于 TiDB 的元數(shù)據(jù)管理平臺

支持 TiSpark+TiDB 的權(quán)限管理系統(tǒng)

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

在上面這些技術(shù)成果的基礎上，貝殼金服的技術(shù)團隊正在做未來的數(shù)據(jù)中臺技術(shù)棧演進規(guī)劃，即基于 TiDB + Azkaban + 自研的數(shù)據(jù)質(zhì)量平臺。