簽收率系統試運營以來，每天算出高額罰款，雖然沒有真正執行，但也挺嚇人的。并且，完完全全的把全網人員積極性提升起來了。

總部網絡管理中心每天給出各省區前一天的簽收率報表，來了個排名和點名；

各省區管理中心給出本區域大網點的簽收率報表，也來了個排名和點名；

大網點把超時單號導出（它們導致簽收率下降），按承包區和業務員分組排名；

排行榜這一招，在中國幾千年以來的各行各業，真的是屢試不爽。甭管是為了降低罰款還是為了面子，所有人都跟打了雞血一般。

各層級領導和管理人員拿著數據說話，更是理直氣壯。“A網點就在你家隔壁，為什么它的派送比你好那么多”。底下一頓之乎者也，各種解釋。此時，管理人員恨不得看著這些業務員派送，為什么那么慢。于是提出，要是能夠馬上看到網點的派送數據和簽收率就好了！

?

【改架構】

系統架構是每天凌晨計算T-1（前一天）全網的簽收率，因為這個時候大部分數據都已經上傳完畢。按照日期和網點過濾數據，然后分組聚合，幾個小時下來就能計算完。

如果實時計算當天數據，就得修改架構，幾個小時才能算一次的辦法顯然不適用。

離線全量計算需要改為增量計算，否則到了下午晚上，隨著當天數據變多，幾千個網點要算很久；

業務策略越完善越復雜，最難的在于如何界定每一票件屬于哪個網點哪一天的派送任務，只要定好日期、網點和頻次（一二三派），那么計算網點今天的簽收率最多就是一個分組統計的事情；

把末中心發件數據，派件網點的派件和簽收掃描數據等，當作源源不斷的數據流，以每秒幾百行到幾千上萬行的速度流入系統。只需要對每一次操作進行增量式處理，即可達到我們的目標。這就是流式計算的思想。

?

【技術選型】

系統前期采用Oracle存儲過程進行數據批量計算，.Net做數據展示。

原計劃采用Hadoop替換存儲過程來進行離線計算，就此夭折，因其做不到實時增量計算。當時也完全沒有人會Spark和Kafka。

同時，業務策略日漸復雜，需要更多外部數據輔助計算，存儲過程必然得換掉。

在這個背景下，我們選擇了公司內最強的.Net開發技術，自主設計一套增量計算系統。（當時Java占比很低）

參考了多年前的系統經驗（只有每月百萬級數據），把數據按照入庫時間切分為小片，每5秒作為一片，從數據庫抽取出來，進行邏輯計算。判定每一票屬于哪個網點哪一天的派件任務后，放入簽收明細表中，按照省份進行分表。完美的把一個大數據計算系統，轉化為大家熟知的數據庫類應用系統，充分利用現有的人力資源和技術儲備優勢。

新架構可以多線程并行計算，并且可以大量利用Redis等眾多中間件進行優化。

?

【系統上線】

系統很快開發完成，試跑數據，每10分鐘對明細表跑一次分組聚合更新簽收率統計表。末端中心發件以及快遞員簽收后，簽收率的確變了，不過需要等10分鐘才會變動。用戶不答應了，10分鐘不變啊，這不算實時……真沒想到，系統上線前夕，還遇到這么個小插曲！

整個系統用了一個Oracle數據庫和一臺32G內存的計算服務器，按省份分了12張表，保存6個月歷史數據，平均每張表2億多行數據。（當時2016年每天業務量1000萬，現在2019年每天業務量4000萬）

盡管有分區索引，但對2億行數據表進行聚合統計，效率是相當低下的，10分鐘周期不能縮短。最后用了個很出人意料的辦法，給12張明細表加插入觸發器，在其中對統計表進行累加更新，最終效果就是，派件量和簽收率數據，每秒都在改變，用戶非常滿意！用觸發器會讓很多程序員笑話，但它很有效，最重要的是用戶很滿意，那就足夠了！

?

【業務賦能】

簽收率各個指標數據每秒都在跳動，全國各地分公司和數千網點的管理人員，猶如獲得了一個派件端的數據大屏。

網點管理者通過積累本網點每個小時點的簽收率，比如A網點每天11點簽收率應該在70%左右，某天發現快11點了才做到60%，那么底下一定出了問題，馬上電話聯系溝通；

省分公司早上10點，發現某個網點簽收率還不足1%，即懷疑網點是否遇到了困難，或者網點老板跑路？

電商旺季，網點在派車去中心拉件之前，就已經在系統看到了當日應派件量，可以準確地安排車輛和派件人員；

……一個簽收率系統，不斷向數據鏈的前后拓展，不斷增加各種業務需求，儼然已經成為了派件端數據標桿，遠超設計預期。

?

……閉關十天攻克一個技術問題，也寫了十多天的代碼，導致《在路上》系列斷了十多天，今天恢復。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的【在路上5】实时计算助力派件管控的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。