當(dāng)前，網(wǎng)購已經(jīng)成為千家萬戶主要的購物方式，隨著快遞體 量的飛速膨脹，分析時(shí)效成了擺在快遞公司面前的重要課題，有 沒有辦法既能降低成本又能提升時(shí)效呢？

整個(gè)快遞的生命周期可以用“收發(fā)到派簽”五個(gè)字概括?！笆铡?是指用戶下單，快遞小哥來收件，網(wǎng)點(diǎn)建包；“發(fā)”是指快遞在轉(zhuǎn) 運(yùn)過程中發(fā)往運(yùn)轉(zhuǎn)中心，發(fā)往目的地；“到”是指末端中心到件，分揀到網(wǎng)點(diǎn)；“派”是指派件網(wǎng)點(diǎn)分揀，快遞小哥開始派件；“簽” 是指快遞小哥派件以后，客戶簽收。

中通快遞有一套完善的自研的大數(shù)據(jù)平臺（見圖 2-3-1 ）， ETL（Extract Transformation Load，抽取、轉(zhuǎn)換、裝載）數(shù)據(jù)建模 支持到半小時(shí)的級別。中通快遞大數(shù)據(jù)平臺支持多種數(shù)據(jù)源的接入，如關(guān)系數(shù)據(jù)庫 MySQL 、Oracle，文檔數(shù)據(jù)庫 MongoDB 以及 Elasticsearch（ES）?；旧?，所有實(shí)時(shí)任務(wù)都是通過大數(shù)據(jù)平臺 來管理的，支持 Kafka、消息隊(duì)列（MQ）等的接入。不論是離線 ETL 還是 Spark/Flink 的實(shí)時(shí)任務(wù)，都通過大數(shù)據(jù)平臺接入整個(gè)大 數(shù)據(jù)的計(jì)算集群，最終進(jìn)行計(jì)算。計(jì)算分析的結(jié)果再通過大數(shù)據(jù) 平臺提供給使用方：一是將數(shù)據(jù)推送到數(shù)據(jù)應(yīng)用端，用于分析和報(bào)表；二是提供給 OLAP 的查詢引擎，供用戶或其他系統(tǒng)查詢。

圖 2-3-1 中通快遞自研大數(shù)據(jù)平臺

2.3.1 1.0 時(shí)代：滿足業(yè)務(wù)和技術(shù)需求 1. 業(yè)務(wù)與技術(shù)需求分析

大數(shù)據(jù)平臺首先要滿足業(yè)務(wù)的需求。中通快遞的業(yè)務(wù)具有如下特點(diǎn)：

1）體量很大：業(yè)務(wù)發(fā)展很快，數(shù)據(jù)量很大，而且每筆訂單會 有 5～6 次更新，甚至更多次更新。

2）分析周期長：業(yè)務(wù)方要求的數(shù)據(jù)分析所覆蓋的周期越來越長。

3）時(shí)效要求高：對分析時(shí)效的要求也越來越高，已經(jīng)不滿足于 T+1 離線計(jì)算，或者半小時(shí)級別的分析。

4）多維度：技術(shù)方案支撐多維的靈活分析。

5 ）可用性要求高：要突破單機(jī)性能瓶頸、單點(diǎn)故障，縮短甚至消除故障恢復(fù)時(shí)間。

6）并發(fā)高：QPS（Queries Per Second，每秒查詢率）高，應(yīng)用要求達(dá)到毫秒級的響應(yīng)。

以技術(shù)為出發(fā)點(diǎn)，需要實(shí)現(xiàn)：

1）打通多個(gè)業(yè)務(wù)場景，設(shè)置多個(gè)業(yè)務(wù)指標(biāo)。

2）實(shí)現(xiàn)強(qiáng)一致的分布式事務(wù)，實(shí)現(xiàn)原有業(yè)務(wù)模式切換代價(jià)小。

3）分析計(jì)算的工程化，以及離線存儲過程。

4）支持高并發(fā)寫、高并發(fā)更新。

5）支持二級索引與高并發(fā)查詢。

6 ）支持在線維護(hù)，單點(diǎn)故障對業(yè)務(wù)無影響。

7 ）支持熱點(diǎn)自動調(diào)度。

8）與現(xiàn)有技術(shù)生態(tài)緊密結(jié)合，做到分鐘級的統(tǒng)計(jì)分析。

9）支持 100 以上列的大寬表，支持多維度的查詢分析。

2. 重構(gòu)時(shí)效系統(tǒng)

基于上述業(yè)務(wù)需求和技術(shù)需求，中通快遞引入了 TiDB，將多條業(yè)務(wù)線接到 TiDB 上，包括數(shù)據(jù)中臺、實(shí)時(shí)寬表、時(shí)效分析、 大促看板等。

中通快遞的時(shí)效系統(tǒng)是對原有時(shí)效系統(tǒng)的重構(gòu)。原來的時(shí)效 系統(tǒng)整體架構(gòu)（見圖 2-3-2）比較簡單，消費(fèi)隊(duì)列通過消息程序把 所有數(shù)據(jù)寫入到數(shù)據(jù)庫，最終在數(shù)據(jù)庫上建立很多存儲過程，來 對數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析，最終將統(tǒng)計(jì)分析的結(jié)果提供給應(yīng)用程序用于查詢。

圖 2-3-3 是升級后的時(shí)效系統(tǒng)架構(gòu)。

在原有的架構(gòu)上，升級后的時(shí)效系統(tǒng)引入了 TiDB 和 TiSpark，消息接入 Spark/Flink，最終的數(shù)據(jù)寫入 TiDB。把原來 的存儲過程全部下線，替換成 TiSpark。數(shù)據(jù)會寫入兩端：輕量 級的匯總數(shù)據(jù)直接寫入 Hive（Hadloop 的一個(gè)數(shù)據(jù)倉庫工具），通過 OLAP 對外提供查詢服務(wù)；中途匯總的數(shù)據(jù)，直接寫入關(guān)系數(shù)據(jù)庫，如 MySQL。另外，每日使用 DataX 將 T+1 的數(shù)據(jù)從 TiDB 的數(shù)據(jù)庫同步到 Hive，以便在第二天做離線的 ETL（提取、轉(zhuǎn)換、加載）操作。

圖 2-3-2 中通快遞原來的時(shí)效系統(tǒng)整體架構(gòu)

圖 2-3-3 升級后的時(shí)效系統(tǒng)架構(gòu)

升級后的時(shí)效系統(tǒng)架構(gòu)相較以前的關(guān)系數(shù)據(jù)庫的分表，無論是 TP 業(yè)務(wù)還是 AP 業(yè)務(wù)，都極大地減少了開發(fā)人員的工作量，并且把原來的消息接入切換成大數(shù)據(jù)的 Spark / Flink，擁抱了現(xiàn)有 的大數(shù)據(jù)生態(tài)，和現(xiàn)有的技術(shù)棧融合。

整個(gè)架構(gòu)的升級帶來了很多收益。

1）已有系統(tǒng)的數(shù)據(jù)存儲周期從原來的 15 天增加到 45 天， 接下來會到 60 天，以后甚至?xí)L。在擴(kuò)展性方面，升級后的架 構(gòu)能支持在線的橫向擴(kuò)展，隨時(shí)上下線存儲和計(jì)算節(jié)點(diǎn)，對此應(yīng) 用基本上是無感知的。

2）在高并發(fā)方面，升級后的架構(gòu)能滿足高性能的 OLTP 業(yè)務(wù) 需求，查詢性能略低于原系統(tǒng)，但是滿足需求。

3 ）數(shù)據(jù)庫單點(diǎn)的壓力沒有了，實(shí)現(xiàn)了 TP 和 AP 的“分離”， 做到了資源隔離。

4）支持更多維度的業(yè)務(wù)分析，滿足了更多業(yè)務(wù)分析的需求。

整體架構(gòu)清晰，可維護(hù)性增強(qiáng)，相比之前的存儲過程，升級 后整個(gè)架構(gòu)體系非常清晰。

3. 大寬表建設(shè)

接下來給大家簡單地介紹中通快遞的大寬表建設(shè)情況，如 圖 2-3-4 所示。

圖 2-3-4 大寬表建設(shè)情況

1）目前寬表有 200 多個(gè)字段，至今還在繼續(xù)增加。

2）接入了 10 多個(gè)主題（Topic）數(shù)據(jù)來源。

3）打通各業(yè)務(wù)產(chǎn)生的數(shù)據(jù)，并匯聚到 TiDB 生成業(yè)務(wù)寬表，借助流處理系統(tǒng) Flink/Spark Streaming 把各個(gè)業(yè)務(wù)端的數(shù)據(jù)最終 寫入 TiDB 的寬表。

4）借助 TiSpark，從業(yè)務(wù)寬表輸出分析結(jié)果，同步 3 億余條數(shù)據(jù)到 Hive。

5）提供實(shí)時(shí)數(shù)據(jù)建設(shè)與離線數(shù)據(jù) T+1 的整合，基本上可 在 10min 以內(nèi)完成。

下邊是各個(gè)接入端，如運(yùn)單中心、訂單中心等以及其他業(yè)務(wù)系統(tǒng)，接入端會把業(yè)務(wù)寫入 MQ/Kafka。Flink/Spark Streaming 會將 Kafka 里面的消息寫入 TiDB 的寬表 （TDB）。TiDB 的寬表上面是 TiSpark，它會通過 TiSpark 的批處 理最終將數(shù)據(jù)寫入 DW 或者 DIM 層，也會將一些匯總數(shù)據(jù)寫入 ST 層，而逐步匯總的數(shù)據(jù)會寫入關(guān)系數(shù)據(jù)庫。最終 Java 應(yīng)用或者 FineReport 報(bào)表，會讀取關(guān)系數(shù)據(jù)庫的匯總數(shù)據(jù)以及 ST 層的數(shù)據(jù)。

另外，寬表也會對外提供大量 API 的服務(wù)，數(shù)據(jù)中臺、時(shí)效系統(tǒng)、數(shù)據(jù)看板系統(tǒng)等產(chǎn)品，都會調(diào)用寬表提供的數(shù)據(jù)服務(wù)。在使用的過程中，我們也遇到了很多問題，我總結(jié)為量變引起質(zhì)變。

1 ）熱點(diǎn)問題：在業(yè)務(wù)高峰時(shí)，索引熱點(diǎn)較為突出，很多業(yè)務(wù)是基于時(shí)間來查詢的，在連續(xù)的時(shí)間段寫入或更新會導(dǎo)致索引的 熱點(diǎn)。在大促的時(shí)候尤為明顯，這樣會導(dǎo)致部分 TiKV 的壓力非常大。

2）內(nèi)存碎片化的問題：在系統(tǒng)運(yùn)行穩(wěn)定一段時(shí)間之后，大量的更新和刪除會導(dǎo)致內(nèi)存碎片化。這個(gè)問題已經(jīng)在后續(xù)的版本中修復(fù)，系統(tǒng)升級之后沒有發(fā)現(xiàn)異常。

3）正確使用參數(shù)的問題：當(dāng)讀取的數(shù)據(jù)量達(dá)到總體數(shù)據(jù)量的 1/10 以上時(shí)，建議關(guān)閉 tispark.plan.allow_index_read 參數(shù)。因?yàn)樵谶@種情況下，這個(gè)參數(shù)的收益會變成很小，甚至?xí)硪恍┴?fù)收益。

4. 運(yùn)維監(jiān)控

TiDB 已經(jīng)有很豐富的監(jiān)控指標(biāo)，它使用的是現(xiàn)在主流的 Prometheus + Grafana，監(jiān)控指標(biāo)非常多、非常全。TiDB 支持用戶的線上業(yè)務(wù)，同時(shí)也支持開發(fā)人員查詢數(shù)據(jù)，因此可能會遇到一些異常的操作，甚至遇到一些 SQL 影響 Server 運(yùn)行，對生產(chǎn)產(chǎn)生影響?；?TiDB 提供的監(jiān)控功能，并針對使用過程中遇到 的一些問題，我們自建了自動監(jiān)管和告警系統(tǒng)，監(jiān)控線上特殊賬 號的慢查詢，自動“殺掉”異常 SQL，并通知運(yùn)維和應(yīng)用負(fù)責(zé)人。我們還開發(fā)了查詢平臺讓用戶使用 Spark SQL 去查詢 TiDB 的數(shù) 據(jù)，兼顧了并發(fā)和安全。對一些很核心的指標(biāo)，我們額外接入了自研的監(jiān)控，將核心的告警信息電話告知到相關(guān)的值班人員。

2.3.2 2.0 時(shí)代：HTAP 提升

業(yè)務(wù)方的需求不斷升級，他們不再滿足于數(shù)據(jù)存得越來越多，還希望系統(tǒng)跑得更快，不僅希望系統(tǒng)要滿足分析數(shù)據(jù)周期的增長，還希望更快地感知業(yè)務(wù)的變化。下游系統(tǒng)需要更多的訂閱信息，希望信息不滿足需求時(shí)，能主動調(diào)取。在開展大促活動時(shí)，TiKV 的壓力非常大，我們需要真正地實(shí)現(xiàn)計(jì)算和存儲分離。集群太大，不容易管理，問題排查很困難。所以，我們對架構(gòu)再次進(jìn)行升級，再次升級后的架構(gòu)如圖 2-3-5 所示。

2.0 時(shí)代我們引入了 TiFlash 和 TiCDC，為什么引入 TiFlash？因?yàn)?TiFlash 是一個(gè)列存數(shù)據(jù)庫，當(dāng)在 TiDB 上建一條同步鏈時(shí)，整個(gè)架構(gòu)包括 TiDB 都不需要改動。數(shù)據(jù)寫入的整個(gè)架構(gòu)是不變 的，仍然可以通過 Flink/Spark 寫入 TiDB 寬表。我們雖然引入了 TiFlash，但是依然保留了部分 TiSpark 任務(wù)。由于業(yè)務(wù)特性，由一些數(shù)據(jù)匯總得到的結(jié)果數(shù)據(jù)可能會達(dá)到了幾百萬或者上千萬的 級別，全部通過 TiFlash 寫入 TiDB，時(shí)效性跟不上。TiDB 對此 需求提供了后續(xù)的解決方案，數(shù)據(jù)計(jì)算會部分切換到 TiFlash 上， TiSpark 和 TiFlash 是共存的。TiSpark 或者 TiSpark 的匯總數(shù)據(jù)還是會寫到 Hive，也有一部分會寫到 MySQL，它們都會對外提供數(shù)據(jù)服務(wù)。我們通過引入 TiCDC 把 TiDB 的 Biglog 同步到消息隊(duì)列里，供下游的業(yè)務(wù)方使用，進(jìn)行地域式消費(fèi)。

圖 2-3-5 再次升級后的架構(gòu)

架構(gòu)再升級的收獲共有兩點(diǎn)：

一 是增強(qiáng)時(shí)效，部分分析進(jìn)入了分鐘級，運(yùn)行間隔從 5～15min 降到了 1～2min。

二是降低了資源的使用，降低了 Spark 集群所需的資源量， 物理節(jié)點(diǎn)大概從 137 個(gè)降到了 77 個(gè)。

2.3.3 3.0 時(shí)代：展望未來

未來，仍然有很多問題等著我們處理，也有很多地方需要進(jìn) 一步提升。

1）監(jiān)控一直是我們比較頭疼的一個(gè)問題—我們的集群規(guī)模 比較大，指標(biāo)很多，而且有的時(shí)候加載非常慢，排查問題的效率得不到保證。監(jiān)控雖然很全，但是出了問題無法快速定位，這也 給我們線上排查問題帶來了一些困擾。

2 ）執(zhí)行計(jì)劃偶發(fā)不準(zhǔn)，會影響集群的指標(biāo)，導(dǎo)致業(yè)務(wù)相互 影響。這個(gè)情況可能與表的統(tǒng)計(jì)信息相關(guān)。過去數(shù)據(jù)清理還是比 較麻煩的，我們現(xiàn)在是通過自己寫腳本來支持舊數(shù)據(jù)的自動 TTL （Time to Live）功能。TiFlash 現(xiàn)在雖然已經(jīng)支持很多函數(shù)知識下 推，但是我們希望可以更多地支持一些應(yīng)用中遇到的函數(shù)。

3）提升集群穩(wěn)定性。

4）實(shí)現(xiàn) TiSpark 對 TiFlash Batch 的支持。

5）支持用戶、資源隔離，避免相互影響。

6）實(shí)現(xiàn)分區(qū)表支持、數(shù)據(jù)過濾，提高計(jì)算性能。

7）緩解計(jì)算抖動問題。

作者介紹

朱友志：中通快遞大數(shù)據(jù)架構(gòu)師，負(fù)責(zé)中通大數(shù)據(jù)基礎(chǔ)架構(gòu)工作。

審核編輯：劉清