最終，同盾科技數(shù)據(jù)庫團隊構建了一整套基于 TiDB 的數(shù)據(jù)流轉(zhuǎn)架構，該架構共分為三層：
實時數(shù)據(jù)層
同盾內(nèi)部有 3000+ MySQL實例，在實時數(shù)據(jù)庫層通過 MySQL cloud 管控上游數(shù)千個 MySQL。
傳輸層
在傳輸層，從 MySQL Cloud 對接實時數(shù)據(jù)同步任務到內(nèi)部 Otter ，Otter 可以實現(xiàn)準實時同步 MySQL 數(shù)據(jù)，然后再由 OTTER 實時同步數(shù)據(jù)到 TiDB。
上下游同步組件決定了數(shù)據(jù)在下游離線場景的整體數(shù)據(jù)質(zhì)量，同盾對數(shù)千個 MySQL 實例同步數(shù)據(jù)的同時，需要保證其穩(wěn)定性、低延遲及整體可控的管理成本。雖然 PingCAP 數(shù)據(jù)遷移工具 DM 支持全量/增量靈活的數(shù)據(jù)導入場景，并具有較快的導入速率，但目前單個 DM worker 只支持綁定一個數(shù)據(jù)源，這限制了管理大量 MySQL 同步任務的需求。同盾最后選擇使用 OTTER 作為常態(tài)化的數(shù)據(jù)增量同步平臺，但 OTTER 只支持增量數(shù)據(jù)同步，且單任務吞吐有上限，同盾通過使用其支持 spark streaming 來進一步保障同步得吞吐和準實時性。未來在 TiDB 推出一個 DM worker 支持多個數(shù)據(jù)源的特性后，同盾會再考慮進行替換。
離線數(shù)據(jù)層
離線數(shù)據(jù)層中的大數(shù)據(jù)平臺主要管控 TiDB 的元數(shù)據(jù)和實際到下游的同步情況。 在 Spark 運行作業(yè)的過程中通過 TiSpark 去訪問 TiDB，最后接入 Hadoop 進行分析作業(yè)。
業(yè)務收益
通過打造 TiDB 數(shù)據(jù)產(chǎn)品鏈，同盾科技實現(xiàn)了數(shù)千個 MySQL 數(shù)據(jù)的離線匯聚管理。TIDB 有著便捷易操作的 Dashboard 管理界面，運維無心智負擔，大大提升了數(shù)據(jù)庫運維團隊的管理運維和使用數(shù)據(jù)的便捷性與效率。同時，TiDB 的高性能保障提供高質(zhì)量的數(shù)據(jù)服務，實現(xiàn)了準實時同步數(shù)據(jù)。
同盾科技數(shù)據(jù)庫運維梁高升介紹，同盾剛開始上線的是 TiDB 2.0 早期版本，在上下游數(shù)據(jù)同步過程中遇到了一些 TiDB 和 MySQL 不那么兼容的情況，如果在上游有大量數(shù)據(jù)更新的情況下，會出現(xiàn)同步阻塞的情況，導致同步的實時性、一致性出現(xiàn)問題。但 TiDB 版本迭代速度非?？?，每個版本都會對性能及穩(wěn)定性做出大量改進和優(yōu)化，在升級到 5.4 版本后，同盾就已經(jīng)解決了大部分的兼容問題。而且在基準測試中，TiDB 的性能也得到了質(zhì)的飛躍。
未來規(guī)劃
同盾科技是 TiDB 非常早期的用戶，多年的使用讓同盾確信 TiDB 是一款非常好的產(chǎn)品，未來也會繼續(xù)致力于在更多的場景依靠 TiDB 生態(tài)落地賦能一些業(yè)務場景。例如，雖然同盾的大部分作業(yè)是 T+1，但內(nèi)部也有很多實實在在的實時分析場景，比如實時展示的 BI 系統(tǒng)，通過TiFlash 實時分析查詢引擎可以進一步提升分析效率，更及時地滿足實時分析需求；同盾國內(nèi)在線業(yè)務針對海量關系型數(shù)據(jù)庫初始使用的是 MYCAT，但是 MYCAT 的運維非常困難，對開發(fā)也不是很友好，更像是上一代的分布式數(shù)據(jù)庫產(chǎn)品。后續(xù)，類似 MYCAT 這樣的場景也很有必要使用 TiDB 進行替換。
近幾年，隨著出海趨勢愈發(fā)火熱，同盾科技在出海業(yè)務勢頭也非常迅猛，業(yè)務涉及東南亞、北美、歐洲等多個區(qū)域，這就需要在谷歌云、AWS、阿里云等通用公有云上，有一款標準的分布式數(shù)據(jù)庫服務，幫助其在全球快速布局業(yè)務。而 TiDB Cloud 已經(jīng)在各大主流公有云上提供服務，這也給同盾科技構建堅實的技術底座提供了更好的選擇。
