中通快遞成立于2002 年，是一家以快遞為主體，以國際、快運、云倉、商業、冷鏈、金融、智能、星聯、傳媒為輔的綜合物流服務品牌。 2020 年，中通完成業務量170 億件，市場占有份額達到20.4%。中通科技是中通快遞旗下的互聯網物流科技平臺，擁有一支千余人規模的研發團隊，秉承“互聯網 + 物流”的理念，與公司的戰略、業務緊密銜接，為中通生態圈業務打造全場景、全鏈路的數字化工具，為用戶提供卓越的科技產品和優質的服務體驗。
整個快遞的生命周期、轉運周期可以用五個字來概括——收、發、到、派、簽：
而支撐整個快遞生命周期的平臺就是中通大數據平臺。中通從離線到實時的數據兼容再到數倉，有著一套比較完善的大數據平臺體系。ETL 建模也會依托該大數據平臺，最終通過大數據平臺對外提供數據應用的支持以及基于離線 OLAP 分析的支持，整個數據建模的頻率可以支持到半小時級別。在這個完善的大數據平臺基礎上，中通開始更多地思考如何增強實時多維分析能力。
中通與 TiDB 的結緣是在2017 年調研分庫分表場景時開始的。當時中通分庫分表達到16000 張表，業務上已經無法再繼續擴展下去。2018 年底，中通開始測試 TiDB2.0，主要關注的是大數據量的存儲，以及分析性能。2019 年年初，中通上線了生產應用的支持。目前生產上穩定的版本是 TiDB3.0.14 。2020 年底，中通開始測試 TiFlash，目標期望有兩點：一是提高時效，二是降低硬件使用情況。
1.0 時代——滿足需求
1.0 是滿足需求的時代，業務需求主要包含以下幾點：
- 業務發展非常快，數據量非常大，每筆訂單更新有5-6 次，操作有峰值；
- 做過調研的技術方案，很難支撐多維分析的需求；
- 業務方對數據分析的周期要求比較長；
- 對分析時效要求也很高；
- 單機性能瓶頸，包括單點故障、風險高，這些也是在業務上不能忍受的；
- 除此之外，QPS 也很高，應用要求毫秒級響應。
技術需求方面，中通需要打通多個業務場景 + 多個業務指標；需要強一致的分布式事務，在原有業務模式下切換的代價很小；還需要對整個分析計算工程化，下線原來的存儲過程；能夠支持高并發的讀寫、更新；能夠支持在線的維護，保證單點的故障對業務是沒有影響；同時，還要與現有的大數據技術生態緊密結合在一起，做到分鐘級的統計分析；最后是中通一直在探索的，即要建立100 + 列以上的大寬表，基于這張寬表，要做到多維度的查詢分析。
目前 TiDB 在中通應用的一些落地場景
01、時效系統應用場景
其中，時效系統是中通原有的一套系統，現在已經進行了重構。這套系統原來的存儲和計算主要是依賴 Oracle 設計的，計算依賴存儲過程。這套架構也比較簡單，一邊是消息的接入，一邊是負載。
隨著業務體量的增長，這一套架構的性能已經逐漸出現瓶頸。在對這套系統進行架構升級時，中通把整個存儲遷移到 TiDB 上，整個計算遷移到 TiSpark。消息接入依賴于 Spark Link，通過消息隊列最終到 TiDB。TiSpark 會提供分鐘級的一些計算，輕度匯總會到 Hive，中度匯總會到 MySQL。基于 Hive，通過 Presto 對外提供應用的服務。相較原來關系型數據庫的分表，無論是 OLTP 還是 OLAP 都極大地降低了開發的工作量，并且和現有的大數據生態技術棧相融合。
1.0 時代中通的數據庫系統架構
遷移帶來的收益有很多：第一是容量的增長，原來的數據中心有三倍的富余，已有系統數據存儲周期增加到三倍以上；第二，在可擴展性方面，支持在線橫向擴展，運維可以隨時上下計算和存儲節點，應用的感知很小；第三，滿足了高性能的 OLTP 業務需求，查詢性能雖略有降低的，但是符合業務需求；第四，數據庫單點壓力沒有了，OLTP 和 OLAP 實現“分離”，互不干擾；第五，支持了更多維度的分析需求；第六，整體架構看起來比原來更清晰，可維護性增強，系統的可擴展性也增強了許多。
02、大寬表應用場景
另一個場景是中通一直在做的寬表的建設與摸索。其實之前中通測過很多系統，包括 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 過渡的時間會變長。
03、運維監控
使用 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 ，對函數的支持也越來越豐富。目前中通生產上應用的版本是 TiDB5.1 。
上圖右側是整個5.0 集群在618 期間的負載情況。在剛剛結束的618 中，5.0 上線的一些任務已經在支持618 移動端的大促看板。中通有6 個核心的指標是基于 TiFlash 計算的。集群響應整體平穩，報表達到了分鐘級以內的時效。整體的數據體量在40 億 -50 億 +，報表分析數據達到10 億 +。
3.0 時代——展望未來
3.0 時代主要是對未來的一些展望：
第一是監控。提到監控，由于中通的集群比較大，所以面臨的問題和遇到的問題可能會多一點。大集群的實例多，指標加載慢，排查問題的效率得不到保障。監控雖然很全，但是出了問題的時候無法快速定位到問題；
第二是解決執行計劃偶發不準的問題。這種偶發不準有時候會影響到一些線上的負載相互影響，拉高集群的指標，導致業務相互影響。
第三是實現自動清理。目前中通數據的清理是通過自己寫成 SQL 清理的，但是過期數據清理比較麻煩。希望之后可以支持舊數據自動 TTL。
第四，隨著5.0 列式存儲的引入，中通計劃把 TiSpark 的任務逐漸全部切到 TiFlash 上面，期望達成提高時效和降低硬件成本的目標。
