陜西公司網(wǎng)站建設(shè)一條龍全包（快遞企業(yè)競爭的未來趨勢有哪些?）快遞行業(yè)面臨的挑戰(zhàn)及未來方向，
原標(biāo)題：HTAP 在快遞行業(yè)助力時效分析的落地實踐本文節(jié)選自《基礎(chǔ)軟件之路 - 企業(yè)級實踐及開源之路》一書，該書集結(jié)了中國幾乎所有主流基礎(chǔ)軟件企業(yè)的實踐案例，由 28 位知名專家共同編寫，系統(tǒng)剖析了基礎(chǔ)軟件發(fā)展趨勢、四大基礎(chǔ)軟件（數(shù)據(jù)庫、操作系統(tǒng)、編程語言與中間件）的領(lǐng)域難題與行業(yè)實踐以及開源戰(zhàn)略、生態(tài)建設(shè)與人才培養(yǎng)。
當(dāng)前，網(wǎng)購已經(jīng)成為千家萬戶主要的購物方式，隨著快遞體 量的飛速膨脹，分析時效成了擺在快遞公司面前的重要課題，有 沒有辦法既能降低成本又能提升時效呢？整個快遞的生命周期可以用“收發(fā)到派簽”五個字概括“收” 是指用戶下單，快遞小哥來收件，網(wǎng)點建包；“發(fā)”是指快遞在轉(zhuǎn) 運過程中發(fā)往運轉(zhuǎn)中心，發(fā)往目的地；“到”是指末端中心到件，分揀到網(wǎng)點；“派”是指派件網(wǎng)點分揀，快遞小哥開始派件；“簽” 是指快遞小哥派件以后，客戶簽收。
中通快遞有一套完善的自研的大數(shù)據(jù)平臺（見圖 2-3-1 ）， ETL（Extract Transformation Load，抽取、轉(zhuǎn)換、裝載）數(shù)據(jù)建模 支持到半小時的級別中通快遞大數(shù)據(jù)平臺支持多種數(shù)據(jù)源的接入，如關(guān)系數(shù)據(jù)庫 MySQL 、Oracle，文檔數(shù)據(jù)庫 MongoDB 以及 Elasticsearch（ES）。
基本上，所有實時任務(wù)都是通過大數(shù)據(jù)平臺 來管理的，支持 Kafka、消息隊列（MQ）等的接入不論是離線 ETL 還是 Spark/Flink 的實時任務(wù)，都通過大數(shù)據(jù)平臺接入整個大 數(shù)據(jù)的計算集群，最終進(jìn)行計算。
計算分析的結(jié)果再通過大數(shù)據(jù) 平臺提供給使用方：一是將數(shù)據(jù)推送到數(shù)據(jù)應(yīng)用端，用于分析和報表；二是提供給 OLAP 的查詢引擎，供用戶或其他系統(tǒng)查詢
圖 2-3-1 中通快遞自研大數(shù)據(jù)平臺2.3.1 1.0 時代：滿足業(yè)務(wù)和技術(shù)需求1. 業(yè)務(wù)與技術(shù)需求分析大數(shù)據(jù)平臺首先要滿足業(yè)務(wù)的需求中通快遞的業(yè)務(wù)具有如下特點：1）體量很大：業(yè)務(wù)發(fā)展很快，數(shù)據(jù)量很大，而且每筆訂單會 有 5～6 次更新，甚至更多次更新。
2）分析周期長：業(yè)務(wù)方要求的數(shù)據(jù)分析所覆蓋的周期越來越長3）時效要求高：對分析時效的要求也越來越高，已經(jīng)不滿足于 T+1 離線計算，或者半小時級別的分析4）多維度：技術(shù)方案支撐多維的靈活分析5 ）可用性要求高：要突破單機(jī)性能瓶頸、單點故障，縮短甚至消除故障恢復(fù)時間。
6）并發(fā)高：QPS（Queries Per Second，每秒查詢率）高，應(yīng)用要求達(dá)到毫秒級的響應(yīng)以技術(shù)為出發(fā)點，需要實現(xiàn)：1）打通多個業(yè)務(wù)場景，設(shè)置多個業(yè)務(wù)指標(biāo)2）實現(xiàn)強(qiáng)一致的分布式事務(wù)，實現(xiàn)原有業(yè)務(wù)模式切換代價小。
3）分析計算的工程化，以及離線存儲過程4）支持高并發(fā)寫、高并發(fā)更新5）支持二級索引與高并發(fā)查詢6 ）支持在線維護(hù)，單點故障對業(yè)務(wù)無影響7 ）支持熱點自動調(diào)度8）與現(xiàn)有技術(shù)生態(tài)緊密結(jié)合，做到分鐘級的統(tǒng)計分析。
9）支持 100 以上列的大寬表，支持多維度的查詢分析2. 重構(gòu)時效系統(tǒng)基于上述業(yè)務(wù)需求和技術(shù)需求，中通快遞引入了 TiDB，將多條業(yè)務(wù)線接到 TiDB 上，包括數(shù)據(jù)中臺、實時寬表、時效分析、 大促看板等。
中通快遞的時效系統(tǒng)是對原有時效系統(tǒng)的重構(gòu)原來的時效 系統(tǒng)整體架構(gòu)（見圖 2-3-2）比較簡單，消費隊列通過消息程序把 所有數(shù)據(jù)寫入到數(shù)據(jù)庫，最終在數(shù)據(jù)庫上建立很多存儲過程，來 對數(shù)據(jù)進(jìn)行統(tǒng)計分析，最終將統(tǒng)計分析的結(jié)果提供給應(yīng)用程序用于查詢。
圖 2-3-3 是升級后的時效系統(tǒng)架構(gòu)在原有的架構(gòu)上，升級后的時效系統(tǒng)引入了 TiDB 和 TiSpark，消息接入 Spark/Flink，最終的數(shù)據(jù)寫入 TiDB把原來 的存儲過程全部下線，替換成 TiSpark。
數(shù)據(jù)會寫入兩端：輕量 級的匯總數(shù)據(jù)直接寫入 Hive（Hadloop 的一個數(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 中通快遞原來的時效系統(tǒng)整體架構(gòu)
圖 2-3-3 升級后的時效系統(tǒng)架構(gòu)升級后的時效系統(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òu)的升級帶來了很多收益 1）已有系統(tǒng)的數(shù)據(jù)存儲周期從原來的 15 天增加到 45 天， 接下來會到 60 天，以后甚至?xí)L在擴(kuò)展性方面，升級后的架 構(gòu)能支持在線的橫向擴(kuò)展，隨時上下線存儲和計算節(jié)點，對此應(yīng) 用基本上是無感知的。
2）在高并發(fā)方面，升級后的架構(gòu)能滿足高性能的 OLTP 業(yè)務(wù) 需求，查詢性能略低于原系統(tǒng)，但是滿足需求3 ）數(shù)據(jù)庫單點的壓力沒有了，實現(xiàn)了 TP 和 AP 的“分離”， 做到了資源隔離4）支持更多維度的業(yè)務(wù)分析，滿足了更多業(yè)務(wù)分析的需求。
整體架構(gòu)清晰，可維護(hù)性增強(qiáng)，相比之前的存儲過程，升級 后整個架構(gòu)體系非常清晰。3. 大寬表建設(shè)接下來給大家簡單地介紹中通快遞的大寬表建設(shè)情況，如 圖 2-3-4 所示。
圖 2-3-4 大寬表建設(shè)情況1）目前寬表有 200 多個字段，至今還在繼續(xù)增加2）接入了 10 多個主題（Topic）數(shù)據(jù)來源3）打通各業(yè)務(wù)產(chǎn)生的數(shù)據(jù)，并匯聚到 TiDB 生成業(yè)務(wù)寬表，借助流處理系統(tǒng) Flink/Spark Streaming 把各個業(yè)務(wù)端的數(shù)據(jù)最終 寫入 TiDB 的寬表。
4）借助 TiSpark，從業(yè)務(wù)寬表輸出分析結(jié)果，同步 3 億余條數(shù)據(jù)到 Hive5）提供實時數(shù)據(jù)建設(shè)與離線數(shù)據(jù) T+1 的整合，基本上可 在 10min 以內(nèi)完成下邊是各個接入端，如運單中心、訂單中心等以及其他業(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 報表，會讀取關(guān)系數(shù)據(jù)庫的匯總數(shù)據(jù)以及 ST 層的數(shù)據(jù)另外，寬表也會對外提供大量 API 的服務(wù)，數(shù)據(jù)中臺、時效系統(tǒng)、數(shù)據(jù)看板系統(tǒng)等產(chǎn)品，都會調(diào)用寬表提供的數(shù)據(jù)服務(wù)。
在使用的過程中，我們也遇到了很多問題，我總結(jié)為量變引起質(zhì)變1 ）熱點問題：在業(yè)務(wù)高峰時，索引熱點較為突出，很多業(yè)務(wù)是基于時間來查詢的，在連續(xù)的時間段寫入或更新會導(dǎo)致索引的 熱點在大促的時候尤為明顯，這樣會導(dǎo)致部分 TiKV 的壓力非常大。
2）內(nèi)存碎片化的問題：在系統(tǒng)運行穩(wěn)定一段時間之后，大量的更新和刪除會導(dǎo)致內(nèi)存碎片化這個問題已經(jīng)在后續(xù)的版本中修復(fù)，系統(tǒng)升級之后沒有發(fā)現(xiàn)異常3）正確使用參數(shù)的問題：當(dāng)讀取的數(shù)據(jù)量達(dá)到總體數(shù)據(jù)量的 1/10 以上時，建議關(guān)閉 tispark.plan.allow_index_read 參數(shù)。
因為在這種情況下，這個參數(shù)的收益會變成很小，甚至?xí)硪恍┴?fù)收益4. 運維監(jiān)控TiDB 已經(jīng)有很豐富的監(jiān)控指標(biāo)，它使用的是現(xiàn)在主流的 Prometheus + Grafana，監(jiān)控指標(biāo)非常多、非常全TiDB 支持用戶的線上業(yè)務(wù)，同時也支持開發(fā)人員查詢數(shù)據(jù)，因此可能會遇到一些異常的操作，甚至遇到一些 SQL 影響 Server 運行，對生產(chǎn)產(chǎn)生影響。
基于 TiDB 提供的監(jiān)控功能，并針對使用過程中遇到 的一些問題，我們自建了自動監(jiān)管和告警系統(tǒng)，監(jiān)控線上特殊賬 號的慢查詢，自動“殺掉”異常 SQL，并通知運維和應(yīng)用負(fù)責(zé)人我們還開發(fā)了查詢平臺讓用戶使用 Spark SQL 去查詢 TiDB 的數(shù) 據(jù)，兼顧了并發(fā)和安全。
對一些很核心的指標(biāo)，我們額外接入了自研的監(jiān)控，將核心的告警信息電話告知到相關(guān)的值班人員2.3.2 2.0 時代：HTAP 提升業(yè)務(wù)方的需求不斷升級，他們不再滿足于數(shù)據(jù)存得越來越多，還希望系統(tǒng)跑得更快，不僅希望系統(tǒng)要滿足分析數(shù)據(jù)周期的增長，還希望更快地感知業(yè)務(wù)的變化。
下游系統(tǒng)需要更多的訂閱信息，希望信息不滿足需求時，能主動調(diào)取在開展大促活動時，TiKV 的壓力非常大，我們需要真正地實現(xiàn)計算和存儲分離集群太大，不容易管理，問題排查很困難所以，我們對架構(gòu)再次進(jìn)行升級，再次升級后的架構(gòu)如圖 2-3-5 所示。
2.0 時代我們引入了 TiFlash 和 TiCDC，為什么引入 TiFlash？因為 TiFlash 是一個列存數(shù)據(jù)庫，當(dāng)在 TiDB 上建一條同步鏈時，整個架構(gòu)包括 TiDB 都不需要改動數(shù)據(jù)寫入的整個架構(gòu)是不變 的，仍然可以通過 Flink/Spark 寫入 TiDB 寬表。
我們雖然引入了 TiFlash，但是依然保留了部分 TiSpark 任務(wù)由于業(yè)務(wù)特性，由一些數(shù)據(jù)匯總得到的結(jié)果數(shù)據(jù)可能會達(dá)到了幾百萬或者上千萬的 級別，全部通過 TiFlash 寫入 TiDB，時效性跟不上。
TiDB 對此 需求提供了后續(xù)的解決方案，數(shù)據(jù)計算會部分切換到 TiFlash 上， TiSpark 和 TiFlash 是共存的TiSpark 或者 TiSpark 的匯總數(shù)據(jù)還是會寫到 Hive，也有一部分會寫到 MySQL，它們都會對外提供數(shù)據(jù)服務(wù)。
我們通過引入 TiCDC 把 TiDB 的 Biglog 同步到消息隊列里，供下游的業(yè)務(wù)方使用，進(jìn)行地域式消費
圖 2-3-5 再次升級后的架構(gòu)架構(gòu)再升級的收獲共有兩點：一 是增強(qiáng)時效，部分分析進(jìn)入了分鐘級，運行間隔從 5～15min 降到了 1～2min二是降低了資源的使用，降低了 Spark 集群所需的資源量， 物理節(jié)點大概從 137 個降到了 77 個。
2.3.3 3.0 時代：展望未來未來，仍然有很多問題等著我們處理，也有很多地方需要進(jìn) 一步提升1）監(jiān)控一直是我們比較頭疼的一個問題—我們的集群規(guī)模 比較大，指標(biāo)很多，而且有的時候加載非常慢，排查問題的效率得不到保證。
監(jiān)控雖然很全，但是出了問題無法快速定位，這也 給我們線上排查問題帶來了一些困擾2 ）執(zhí)行計劃偶發(fā)不準(zhǔn)，會影響集群的指標(biāo)，導(dǎo)致業(yè)務(wù)相互 影響這個情況可能與表的統(tǒng)計信息相關(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）實現(xiàn) TiSpark 對 TiFlash Batch 的支持5）支持用戶、資源隔離，避免相互影響。
6）實現(xiàn)分區(qū)表支持、數(shù)據(jù)過濾，提高計算性能7）緩解計算抖動問題作者介紹 朱友志，中通快遞大數(shù)據(jù)架構(gòu)師，負(fù)責(zé)中通大數(shù)據(jù)基礎(chǔ)架構(gòu)工作圖書推薦 隨著云計算和生成式 AI 的逐漸發(fā)展，基礎(chǔ)軟件的技術(shù)棧也在發(fā)生變化，市場現(xiàn)存的基礎(chǔ)軟件領(lǐng)域的圖書相對較少，且多數(shù)最近兩年沒有更新。
但是，基礎(chǔ)軟件領(lǐng)域已經(jīng)發(fā)生了巨大變化，我們現(xiàn)在所講的基礎(chǔ)軟件是以云、AI 為底座的基礎(chǔ)軟件，這些新的變化都可以在這本書里找到答案
返回搜狐，查看更多責(zé)任編輯：