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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5）支持二級(jí)索引與高并發(fā)查詢(xún)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 大寬表建設(shè)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7）緩解計(jì)算抖動(dòng)問(wèn)題。

作者介紹

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

審核編輯：劉清