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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最終數(shù)據(jù)校驗(yàn)任務(wù)較重：數(shù)據(jù)遷移完成之后，需要對上下游數(shù)據(jù)進(jìn)行校驗(yàn)，最簡單的方式是業(yè)務(wù)校驗(yàn)和對比上下游標(biāo)的行數(shù)?；蛘呤褂?pt-toolkit 工具進(jìn)行數(shù)據(jù)校驗(yàn)。

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

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

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

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

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

操作描述：

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

新機(jī)房擴(kuò)容 3+ 個 TiKV，3 個 PD，2+ 個 TiDB。

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

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

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

注意事項(xiàng)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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