TiDB 助力一面數據實現消費領域的決策分析平臺

深圳市一面網絡技術有限公司（下稱：一面數據）是一家爲消費領域的領導企業提供實時、精準、全面的數據洞察和決策指導的創新型企業，利用人工智能和算法，進行天然語言處理，語義情感分析，迴歸預測模型等，幫助客戶實現精準產品運營和預測市場變化。一面數據服務於國內外一流企業，包括世界最大的對衝基金、國際一線汽車品牌、快消品龍頭廠商，以及時尚鞋服大牌等。

改造前系統架構

一面數據的核心 IT 系統覆蓋了從數據獲取、數據清洗處理、數據建模到數據可視化的全套數據分析流程。核心系統天天有海量從互聯網採集的公開數據和來自企業內部的數據，對數據存儲的容量、擴展性和可用性都有很高的要求。

起初，一面數據的核心繫統採用的是多個 MySQL 實例和一個 Cassandra 集羣。MySQL 多實例集羣主要存儲指定特徵的爬蟲數據，Cassandra 主要存儲數據量大、不適合存儲 MySQL 的全頁面緩存的數據。在數據量/請求量小的時候系統運行正常。下圖爲：一面數據改造前系統構架圖

隨着數據量的增加，逐漸暴露出不少問題：

MySQL：
隨着數據增加，存儲容量接近單機的磁盤極限，單機的磁盤 IO 繁忙且易阻塞，查詢性能難以知足業務增加的需求。數據量大了之後，傳統的 MySQL 水平擴展能力弱，性能和穩定性容易產生問題，在數據量和訪問量增加到必定階段將沒法知足常見的 OLAP 場景分析需求。技術團隊經過診斷系統性能問題，認識到現有數據庫已經成爲瓶頸。

Cassandra：
Cassandra 對磁盤 IO 和內存要求高，添加一個實例，須要從其餘實例遷數據，對網絡帶寬、 磁盤要求特別高。另外 CQL 支持的特性太少，業務開發麻煩，例如不能聯表，不支持主鍵以外的索引，對主鍵之外的查詢比較困難，雖然有 Secondary Index，可是使用限制大。生態圈不完善，例如很難找到好用的監控。

改造後的系統架構 - 引入 TiDB 替換 MySQL 和 Cassandra

爲從根本上解決以上問題，一面數據的技術團隊決定經過增長部署一套高性能的數據庫系統，以解決當前業務的痛點。 在評估和驗證了 MySQL Sharding 和 MongoDB 等傳統技術手段以後，團隊認識到：基於 MySQL Sharding (即利用 MySQL 中間件分庫分表) 架構在高可用安全能力，業務和查詢的靈活支持以及運維管理難度和成本上都不盡如人意，有着諸多架構上和技術上的缺陷；而 MongoDB 比較適合存儲爬蟲數據，但遷移成本高，不論是數據仍是應用程序都須要作侵入性修改和調整，難度和開發成本驟升。另外，做爲 NoSQL 數據庫，MongoDB 不支持 SQL 和 JOIN ，對 BI 工具的支持也不完善，數據分析師們沒法直接使用。 最終從知足業務需求、下降切換成本和減小運維成本等角度考慮，一面數據選擇了分佈式關係型數據庫－TiDB 做爲業務的首選事務型數據庫。

TiDB 支持包括跨行事務，JOIN 及子查詢在內的絕大多數 MySQL 的語法，用戶能夠直接使用現有的 MySQL 客戶端鏈接。若是現有的業務已經基於 MySQL 開發，大多數狀況不須要修改代碼便可直接替換單機的 MySQL。同時現有的大多數 MySQL 運維工具（如 PHPMyAdmin, Navicat, MySQL Workbench 等），以及備份恢復工具（如 mysqldump, mydumper / myloader）等均可以在 TiDB 直接使用，這也讓開發運維人員不用關注數據庫 scale 的細節問題，專一於業務開發，極大的提高研發的生產力。下圖爲：一面數據改造後系統構架圖

一面數據的生產環境部署了數十個 TiKV 節點及幾個 TiDB 節點。遷移原有 MySQL 集羣數據時使用 Percona 的 mydumper 以及 TiDB 專有優化的 loader 工具，逐個爬蟲進行遷移。目前 TiDB 集羣存儲了接近數十 TB 的數據，把另外幾個應用遷移完成後將會每日新增近億條記錄。

完成遷移之後，系統再也不須要維護多個 MySQL 實例以及 Cassandra 集羣，運維成本大幅縮減，監控使用 Prometheus/Grafana，而且能夠經過 Prometheus 的 AlertManager 定製規則複雜的報警規則。這些改變都讓一面數據的爬蟲存儲側的工做便利許多，可讓一面數據的研發把精力更多放在業務研發而不是運維多個不一樣技術棧的複雜集羣。

將來的架構規劃

目前 TiDB 新增了 TiSpark 組件，而且在 TiKV 層實現了 Spark 的下推算子，使得能夠直接在 TiDB 集羣上跑 Spark 程序，這樣能夠省去 ETL 的步驟。後續一面數據也考慮深刻使用 TiSpark 組件，讓一面數據的整個系統增長必定的實時複雜查詢的能力。長遠來看，能夠把如今 ElasticSearch，Impala，Hive 的業務都遷移到 Spark 集羣上，這樣一方面統一了分析側的技術棧，另外一方面鏈接了 Spark 豐富龐大的生態。下圖爲：一面數據將來系統構架圖

在一面數據 CTO 張錦傑看來：「 TiDB 水平擴展性、兼容 MySQL 是很是好的特性，對須要使用關係型數據庫做爲存儲方案的業務有極大的誘惑力，避免了傳統分表、分庫方案帶來的上層應用的複雜性，解決了咱們目前迫切的關係型數據存儲的需求。」