中通大資料平臺在大促中的進化

PingCAP發表於2021-11-26

一年一度的雙十一又雙叒叕來了,給技術人最好的禮物就是大促技術指南! 而經過這些年的發展,大促早已不僅僅侷限於電商行業,現在各行各業其實都會採用類似方式做運營活動,汽車界有 818,電商有 618 、11.11 等等,各種各樣的大促場景,對包括資料庫在內的基礎軟體提出了很多新挑戰,同時也積累了諸多最佳實踐。

在雙十一到來前,PingCAP 與汽車之家、易車網、京東、中通等使用者展開一系列深入探討,希望為大家揭祕逐年飆升的銷量背後隱藏著什麼樣的技術難題?用什麼技術架構才能平穩地扛住流量洪峰?

點選此處觀看完整採訪參與互動,有機會獲得 TiDB 定製周邊!

大促中,大家買買買後最期盼的事情就是收到快遞。成立於 2002 年的中通快遞,是一家以快遞為主體,以國際、快運、雲倉、商業、冷鏈、金融、智慧、星聯、傳媒為輔的綜合物流服務品牌。2020年,中通完成業務量 170 億件,市場佔有份額達到 20.4%。

整個快遞的生命週期、轉運週期可以用五個字來概括——收、發、到、派、籤
在這裡插入圖片描述

而支撐整個快遞生命週期的平臺就是中通大資料平臺。中通從離線到實時的資料相容再到數倉,有著一套比較完善的大資料平臺體系。ETL 建模也會依託該大資料平臺,最終通過大資料平臺對外提供資料應用的支援以及基於離線 OLAP 分析的支援,整個資料建模的頻率可以支援到半小時級別。在這個完善的大資料平臺基礎上,中通開始更多地思考如何增強實時多維分析能力

在這裡插入圖片描述

中通與 TiDB 的結緣是在 2017 年調研分庫分表場景時開始的。當時中通分庫分表達到 16000 張表,業務上已經無法再繼續擴充套件下去。2018 年底,中通開始測試 TiDB 2.0,主要關注的是大資料量的儲存,以及分析效能。2019 年年初,中通上線了生產應用的支援。目前生產上穩定的版本是 TiDB 3.0.14 。2020 年底,中通開始測試 TiFlash,目標期望有兩點:一是提高時效,二是降低硬體使用情況

1.0 時代——滿足需求

1.0 是滿足需求的時代,業務需求主要包含以下幾點:

  • 業務發展非常快,資料量非常大,每筆訂單更新有 5-6 次,操作有峰值;
  • 做過調研的技術方案,很難支撐多維分析的需求;
  • 業務方對資料分析的週期要求比較長;
  • 對分析時效要求也很高;
  • 單機效能瓶頸,包括單點故障、風險高,這些也是在業務上不能忍受的;
  • 除此之外,QPS 也很高,應用要求毫秒級響應。

技術需求方面,中通需要打通多個業務場景 + 多個業務指標;需要強一致的分散式事務,在原有業務模式下切換的代價很小;還需要對整個分析計算工程化,下線原來的儲存過程;能夠支援高併發的讀寫、更新;能夠支援線上的維護,保證單點的故障對業務是沒有影響;同時,還要與現有的大資料技術生態緊密結合在一起,做到分鐘級的統計分析;最後是中通一直在探索的,即要建立 100 + 列以上的大寬表,基於這張寬表,要做到多維度的查詢分析
在這裡插入圖片描述
目前 TiDB 在中通應用的一些落地場景

時效系統應用場景

其中,時效系統是中通原有的一套系統,現在已經進行了重構。這套系統原來的儲存和計算主要是依賴 Oracle 設計的,計算依賴儲存過程。這套架構也比較簡單,一邊是訊息的接入,一邊是負載。
在這裡插入圖片描述

隨著業務體量的增長,這一套架構的效能已經逐漸出現瓶頸。在對這套系統進行架構升級時,中通把整個儲存遷移到 TiDB 上,整個計算遷移到 TiSpark。訊息接入依賴於 Spark Link,通過訊息佇列最終到 TiDB。TiSpark 會提供分鐘級的一些計算,輕度彙總會到 Hive,中度彙總會到 MySQL。基於 Hive,通過 Presto 對外提供應用的服務。相較原來關係型資料庫的分表,無論是 OLTP 還是 OLAP 都極大地降低了開發的工作量,並且和現有的大資料生態技術棧相融合。

在這裡插入圖片描述
1.0 時代中通的資料庫系統架構

遷移帶來的收益有很多:第一是容量的增長,原來的資料中心有三倍的富餘,已有系統資料儲存週期增加到三倍以上;第二,在可擴充套件性方面,支援線上橫向擴充套件,運維可以隨時上下計算和儲存節點,應用的感知很小;第三,滿足了高效能的 OLTP 業務需求,查詢效能雖略有降低的,但是符合業務需求;第四,資料庫單點壓力沒有了,OLTP 和 OLAP 實現“分離”,互不干擾;第五,支援了更多維度的分析需求;第六,整體架構看起來比原來更清晰,可維護性增強,系統的可擴充套件性也增強了許多。

大寬表應用場景

另一個場景是中通一直在做的寬表的建設與摸索。其實之前中通測過很多系統,包括 Hbase、Kudu。Kudu 的寫入效能還是很不錯的,但是其社群活躍度在國內一般。同時,中通使用 impala 作為 OLAP 查詢引擎,但主流使用的是 Presto,相容性有待考慮,也很難滿足所有業務場景需求。此外,中通的業務特性要求系統能夠快速地計算分析幾十億的資料,並能同步到離線的叢集裡與 T+1 資料做融合,還要能提供給資料產品和資料服務直連拉取明細資料。最後是海量資料的處理,中通有很多訊息源的接入,需要針對每一票進行全鏈路路由和時效的預測,定位到每一票的轉運環節,資料量很大,對時效的要求也很高。

在這裡插入圖片描述
中通的大寬表建設

目前,寬表已經建設有 150 多個欄位。資料來源於 10 多個 Topic 。主要的專案接入是通過 Flink 和 Spark ,打通了各個業務產生的資料,彙總到 TiDB 形成業務寬表。額外一部分,依賴於 TiSpark,從業務寬表輸出分析結果,同步 3 億條資料到 Hive。此外,還提供了十分鐘級別的實時資料建設和離線 T+1 的整合。

中通目前的叢集規模在使用過程中,中通也遇到了一些問題,總結起來就是量變引起質變。第一,熱點問題。索引熱點在目前情況下表現較為突出,因為中通的業務量規模十分大,操作存在高峰,在大時候該熱點問題表現特別明顯。第二,記憶體碎片化問題。在之前的低版本里,在穩定執行了一段時間後,因為有業務特性和大量的更新和刪除,導致記憶體碎片化比較嚴重,這個在反饋給了 TiDB 後,已經修復了這個問題。第三,著重介紹一個引數——TiFlash 讀取 index 的引數。通過測試,當讀取的資料量/總資料量大於 1/10 的時候,建議該引數關閉。為什麼這麼說?因為 Test 數可能會變少,但是單位 Test 過渡的時間會變長。

運維監控

使用 TiDB 後會發現它的監控指標特別豐富,使用了流行的 Prometheus + Grafana ,多而全。之前,中通因為在支援線上業務的同時,還會有開發人員來查資料,遇到了 SQL 把 TiKV Server 拉掛的情況。針對這個問題以及監控的問題,中通進行了一些開發定製。第一,相容線上特殊帳號的慢 SQL,會自動殺掉,並通知到相應的應用負責人。第二,中通開發了支援 Spark SQL 去查詢 TiDB 的工具,併發和安全性在開發的過程中得到一些保障。此外,中通還會把一些額外的核心指標,接入到自研的監控體系。核心的告警會電話通知到相關的值班人員。
在這裡插入圖片描述

去年雙十一期間,中通訂單量突破 8.2 億,整個業務規模突破 7.6 億,雙十一當天的 QPS 峰值達到 35 萬 +。整個雙十一期間,資料的更新體量達到了數千億級別,整個叢集上執行的 TiSpark 任務是 100 多個,支援的線上應用 7 個。整個分析的時效在 10 分鐘以下達到了 98% ,整個分析的資料週期達到 7-15 天

2.0 時代——HTAP 提升

2.0 時代的主要特點是 HTAP 的提升。中通應用 HTAP 主要來自於業務方需求的升級:
基於業務方的需求,中通在 2.0 時代進行了一次架構再升級。首先,引入了 TiFlash 和 TiCDC 。這帶來的收益其實是增強了時效,部分分析進入了分鐘級級別,降低了 Spark 叢集資源的使用情況。
在這裡插入圖片描述
2.0 時代中通的資料系統架構

下圖是 TiSpark 和 TiFlash 的對比,中通線上有兩套叢集,一個基於 3.0,一個基於 5.0。簡單地對比一下 3.0 和 5.0 的情況:3.0 主要的分析是基於 TiSpark,5.0 是基於 TiFlash 。目前 3.0 叢集有 137 個物理節點, 5.0 有 97 個節點。整個執行的週期中,3.0 是 5 - 15 分鐘,基於 5.0 的 TiFlash 已經做到 1-2 分鐘,整個 TiKV 的負載降低是比較明顯的。另外, 在 3.0 上 Spark 的資源大概有 60 臺,而在 5.0 上,線上的加上在測試的,大概有 10 臺就足夠了。
在這裡插入圖片描述

在整個測試周期中,生產的叢集是 3.0 ,4.0 的測試周期其實是非常短的。在測試時,業務的場景有一些維表 Join 的情況,當時 4.0 對 MPP 沒有支援,對一些函式的支援可能也不是那麼完善,測試結果不是很理想。對 HTAP 的測試主要是在 5.0 階段,5.0 已經支援 MPP ,對函式的支援也越來越豐富。目前中通生產上應用的版本是 TiDB 5.1 。
在這裡插入圖片描述

上圖右側是整個 5.0 叢集在 618 期間的負載情況。在剛剛結束的 618 中, 5.0 上線的一些任務已經在支援 618 移動端的大促看板。中通有 6 個核心的指標是基於 TiFlash 計算的。叢集響應整體平穩,報表達到了分鐘級以內的時效。整體的資料體量在 40 億 - 50 億 +,報表分析資料達到 10 億 +。

3.0 時代——展望未來

在這裡插入圖片描述

  • 第一是監控。提到監控,由於中通的叢集比較大,所以面臨的問題和遇到的問題可能會多一點。大叢集的例項多,指標載入慢,排查問題的效率得不到保障。監控雖然很全,但是出了問題的時候無法快速定位到問題;
  • 第二是解決執行計劃偶發不準的問題。這種偶發不準有時候會影響到一些線上的負載相互影響,拉高叢集的指標,導致業務相互影響。
  • 第三是實現自動清理。目前中通資料的清理是通過自己寫成 SQL 清理的,但是過期資料清理比較麻煩。希望之後可以支援舊資料自動 TTL。
  • 第四,隨著 5.0 列式儲存的引入,中通計劃把 TiSpark 的任務逐漸全部切到 TiFlash 上面,期望達成提高時效和降低硬體成本的目標。

大促對於企業而言,除了支援業務創新,也是一次對自身技術架構的大練兵和全鏈路演練。通過大促的極致考驗,企業的 IT 架構、組織流程、人才技能都獲得了大幅提升。而在大促中的經驗和思考,也會加速企業日常的業務創新節奏,提升技術驅動的創新效率,打造增長新引擎。

相關文章