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

PingCAP發表於2019-03-01

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

改造前系統架構

一面資料的核心 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 是非常好的特性,對需要使用關係型資料庫作為儲存方案的業務有極大的誘惑力,避免了傳統分表、分庫方案帶來的上層應用的複雜性,解決了我們目前迫切的關係型資料儲存的需求。”

相關文章