基于複雜時空分析的物流"一本賬"大資料基礎設施：先知引擎

01

引擎建設背景

随着申通進入到數字化、數智化深水區，早期粗放的營運方式已經無法滿足業務精細化管理的訴求。在大資料時代，資料實時化變愈發重要，離線分析隻能診斷“曆史重演”的問題，無法看清整個快遞網絡目前實操現狀，也無法進行事中幹預。此外，準确預測物流資料同樣至關重要，因為及時的幹預可以在實際操作中“亡羊補牢”，但如果未能提前進行規劃，物流實操場景将面臨資源配置設定不足的挑戰，進而導緻營運效率低下，最終影響商業成果的實作。

近年來大資料人工智能在各行各業攻城略地，但在快遞行業實踐中還有很多問題，如資料品質低下、數字常常不準、口徑總是對不齊、排期越來越長，機器費用比業務漲得快，招個開發比中心經理還貴，做個“智障路由”還沒什麼用數字化紅利步履蹒跚，智能化藍圖遙遙無期。但這些現象不是因為快遞技術不夠努力，問題的關鍵是這個行業的技術挑戰遠超想象，技術路線和架構至今并未成熟。

這些挑戰特别在于資料層面——資料量巨大、生命周期漫長、實時性要求高、網狀資料難以高效組織。為此我們從“地基”開始，重新設計了面向未來的快遞大資料基礎設施。經過多年的實踐和改進，形成了一套基于複雜時空分析的物流“一本賬”大資料基礎設施：先知引擎（logiSage time-space HSAP)。以下就讓我們詳細展開申通在引擎建設上的前因後果。

02

行業痛點

令人抓狂的資料不一緻問題

物流行業由于履約周期長、包裹量大、線下實操環境複雜等因素，導緻實時數倉建設面臨諸多挑戰和困難，數字不準确、彙總和明細對不上、口徑不一緻等問題時有發生。是以，各個部門為了解決這些問題，瘋狂地進行“資料基建”，但這樣的做法往往會導緻資料出入口不一緻資料備援等問題，反而加劇了資料不一緻的問題，同時也增加了大資料基礎設施的成本和費用。

很簡單的需求要排期做好久

以時效控制塔産品為例，業務需要在移動端實作多個實時彙總名額的展示。傳統的實作方式上來就是一套組合拳：領域設計、表設計、接口設計等，就是這樣一個很簡單的需求，往往排期需要一兩個月時間。由于物流業務環節緊密性強、協作成本高，是以簡單的人力堆積并不能解決傳遞周期長的問題。

物流預測不及時問題

在物流運作中，轉運中心經理需要在規劃實操場景時，充分考慮所需實操勞工數量、車輛數量以及車型類型，并進行科學合理的排程，以實作時效、品質、成本的最優化管理。是以，資源預配置設定的重要性不容忽視。在真實的實操場景中，比如安排多少實操勞工去裝車這樣一個看似很簡單的問題，背後卻蘊含着複雜的計算，因為待裝車量既包括昨日滞留場地未操作的貨物，又包含剛到場地待裝車的貨物，還包括即将到來的貨物。針對即将到來的貨物，實時準确地預測包裹到達時間對于中心化物流管理至關重要，隻有在實時預測的基礎上，才能實作對貨物的合理調配。但是物流行業資料規模大、存儲周期長，物流預測結果産出往往需要耗費數個小時，延後的預測結果對于實操來說已經毫無意義。

03

大規模資料下物流行業面臨的技術挑戰

技術上不可能三角

中國快遞業務高速發展，每天産生幾億包裹，幾十億的包裹軌迹資訊，快遞技術産品幾乎都是大資料産品。不僅需要支援高并發的明細資料點查，還需要提供海量資料的實時統計分析，再疊加恐怖的資料寫入量，傳統的OLTP以及OLAP産品都不能滿足要求。在混合模式下，近期比較火熱的HTAP架構并不符合場景的特點，快遞物流沒有強事務性，反而對實作成本非常敏感。在架構選型上，這就是個典型的HSAP (Hybrid Serving And Analytical Processing)場景。

在性能上我們的場景也是極端苛刻的，整個網絡動辄每秒有數十萬條事件實時寫入，并要求在亞秒級就能被服務與分析所消費，而不是一個冗長的離線ETL過程。十億級别的包裹，百億級别物流事件，每秒數萬的QPS查詢，點查毫秒級别的延遲，千萬量級的統計亞秒級别的延遲。面對這樣的要求，市面上很多産品都在這個問題上敗下陣來。由于複雜多變的時空業務分析場景，技術同學需要數周的傳遞周期，傳統的系統建設方式已經趕不上業務疊代的速度。在行業傳統的基礎架構中，例如通Flink+Solr+Hbase+ADB這種複雜的技術棧組合方式，期間不可避免的會出現資料孤島、資料不一緻等問題，給開發帶來了巨大的複雜性，給運維提出了巨大的挑戰。

基于以上描述，我們提出物流技術上的不可能三角。在支撐業務的同時既要滿足高并發低延遲，又要滿足低成本傳遞還要實作業務鍊路宏觀微觀一緻，是以對我們的這個大資料“地基”提出了突破性技術要求，這也是目前困擾整個行業的“難解之困”。

複雜的時空問題

物流事件之間有時序關系，如檢索出長沙轉運中心2023年6月1号中午12點後從南充轉運中心發往福建泉州轉運中心的包裹，傳統的資料結構很難表達。任意兩個相距很遠的操作站點之間依舊可以發生業務往來，包裹在網絡中可能會經過多次中轉，還會産生錯分或者退回等異常情況，具體需要經過多少網絡節點在複雜的實操環境中并不确定，不同操作站點之間不是一個傳統的樹型結構而是一個複雜的圖。是以基于空間特性的傳統分庫分表方案雖然解決了寫入的性能瓶頸，但很難滿足複雜時空分析的要求。

04

一本賬理念&架構

一本賬理念

①什麼是“一本賬”

賬本是由具有一定格式與若幹賬頁組成，以會計憑證為依據，對所有經濟業務進行序時分類記錄的本籍，也就是通常我們所說的賬冊。

我們首先從一緻性入手。賬本這個術語是來自财務領域，而什麼是“一本賬”的架構理念呢？

供應鍊物流的核心是“庫存”（車上的貨、轉運中心裡的包裹、件量預測都是不同形态的庫存)，我們産品上用到的各種數字和名額都可以了解為一種特别口徑的庫存。庫存是基于賬本計算出來的表，對應到在一本賬的架構設計中，我們的資料産品都隻是包裹庫存的報表，這樣我們就把包裹的所有資料分成了“賬”和“表”，每個包裹的狀态的任何變化都記錄在賬上，這個賬本在技術實作上是統一并且唯一的，這就是“一本賬”的技術架構，我們的所有相關資料應用，都必須從“一本賬”統計彙總而來，這樣就實作了宏觀微觀一緻性，對于鍊路上的一緻性問題，都可以穿透到每一個包裹的“賬本”，通過查賬來實作快速對齊。

②為什麼是“一本賬”

一本賬的核心一個是解決資料一緻性問題，因為目前大部分技術架構都是以“表”為核心的，加工了很多不同視角的基礎資料，不一緻性廣泛存在；另一個核心就是通過“一本賬”減少重複建設來達到降本的目标，由于物流行業資料規模大、存儲周期長、并發極高，導緻大資料基礎設施費用動辄300萬起，成本高昂，而且整個行業目前沒有成熟的實踐案例，是以常常還會出現錢花了病治不好的現象。

下面我将庖丁解牛，來一步步介紹我們是如何實作“一本賬”的架構理念。

先知引擎架構

先知，是在宗教信仰與世俗中對宇宙萬物與人類社會、自然科學方面的大事有較早研究與了解或能準确預言的人類。而我們的産品寓意不僅具有客觀世界的實時掌控能力也具備主觀世界的準确預測能力。

我們通過建立複雜時空分析的物流"一本賬"大資料基礎設施：先知引擎（logiSage time-space HSAP)，旨在打造主觀客觀一體的高性能、統一智慧的包裹引擎。

在先知引擎架構設計中，資料鍊路層作為上遊資料統一輸入口負責引擎資料模型建構，網關負責冷熱資料路由和統一業務名額查詢出入口，預測子產品主要針對物流詳情以及末端中心進行主觀預測，AI·OS引擎是我們高性能存儲計算引擎，名額管理平台回答的是易用、統一性，而引擎管理平台主要負責穩定性子產品，這樣我們将實作集易用性、穩定性、先進性、高性能為一體的全方位的産品體系。先知引擎作為“一本賬”的架構理念的先行者，下面我将詳細介紹存儲計算引擎、資料鍊路層、物流預測、網關、引擎管理平台這5個大子產品。

①AI·OS存儲計算引擎

AI·OS是阿裡巴巴搜尋團隊開發的搜尋引擎平台，它為阿裡集團包括淘寶、天貓在内的核心業務提供搜尋服務支援。在雙十一10萬以上TPS穩定持續寫入24小時以上，寫入延遲在1秒以内，十萬以上的QPS性能，并且寫入即可讀(毫秒級)，是一款高性能低延遲的存儲計算引擎。

a.産品選型

在物流包裹基礎資料中訂單、段碼、軌迹是核心三要素，如上圖所示，其中運單号和訂單、段碼屬性資訊是一對一的關系，而運單号和物流軌迹是一對多的關系，但是十億級别的包裹，百億級别的物流事件，如果用線上join的方式，性能是一個很大的瓶頸。由于包裹具體會經過多少操作站點，包裹在操作站點具體會經曆哪些操作流程這些都是不固定的，早期傳統的解法，通過預留一個200+字段的大寬表去存儲這些物流詳情事件資訊，從設計上來說擴充性很差。是以基于我們的業務特性，我們在選型的時候需要産品首先支援嵌套文檔結構，對應到資料結構存儲上可以是一個List或者是一個多值的數組等，市面上符合條件的有基于HA3引擎的AI·OS、開源列式資料庫Clickhouse（後文簡稱"CK"）、以及基于Lucene引擎的ElasticSearch（後文簡稱"ES"）。

ES采catter-gather計算模型來轉化資料為反向索引，以擷取很好的查詢性能。然而，對于以掃描聚合為主的查詢，随着資料量的增加，響應會退化到分鐘級，是以我們放棄了ES。并且我們在3T索引、12T資料規模的CK叢集規格(在16c64g、48節點、PL2磁盤)下進行了場景化探索實驗，以評估CK在複雜業務聚合查詢場景下的性能。然而，我們的實驗結果表明，在30QPS的負載情況下，叢集的CPU已經滿負載并且無法滿足我們複雜業務的響應要求。

AI·OS引擎嵌套子文檔序列将子文檔資料在索引層按順序緊密相連，支援主子字段單獨建立索引并通過主子文檔關系表進行轉換，這種提前JOIN的模式極大地提高了查詢性能，同時儲存了主子文檔之間的關聯性，這是市面上很多産品不具備的能力，在符合業務特性的同時，AI·OS極緻的性能表現是我們選擇該引擎的原因。在AI·OS引擎底層我們隻保留物流基礎詳情資料，所有的業務分析名額通過引擎OLAP實時聚合透出，天然地避免了資料孤島問題，還實作了資料宏觀微觀一緻。并且AI·OS支援HA3 query文法和SQL文法，使用者隻需要将對應的業務翻譯成對應的SQL文法就可以實作低成本、快速傳遞的能力。AI·OS引擎作為實時高性能引擎，可供業務查詢近期熱資料的線上實時分析。

b.引擎定制

我們基于AI·OS sub doc子文檔嵌套功能，定制的存儲模型如下。

我們将時序多變的物流實操事件列存儲到子文檔上，然後将子文檔和主文檔合并到一個文檔上。子文檔上所有的物流詳情根據sub_occur_time按照時間順序遞增排序存儲，所有子文檔上同一位置的資料構成空間上實體實操站點發生的完整實操事件，實作資料擴充的同時也解決了複雜的時空問題。并且自研了32個高性能時空算子，比如快速檢索到最後一個子文檔屬性sub_attribute_last(sub_node_code,"-1",sub_node_type=3)、文檔的下一個子文檔的指定字段get_next_first(sub_node,sub_node,sub_nat_type=0,”fake”,sub_node=“1234”)等功能，來應對傳統關系資料庫無法高效處理的時序列分析需求。

c.性能表現

每秒數十萬的資料寫入吞吐能力，并可實時載入被消費（亞秒級），毫秒級延遲且寫入即可讀。數萬級查詢并發下，在基于14天10億規模的資料，幾百個屬性、狀态、特征，再結合時間和空間次元的任意組合檢索可以滿足業務即席查詢毫秒級别響應。目前AI·OS引擎已經在申通廣泛應用，100%覆寫時效域實時線上分析名額，并支撐品質域、客服域等多個線上分析業務場景。利用AI·OS引擎強大的Serving和AP能力，已經支撐申通共計11個應用100+個業務場景實時線上分析，如圖6所示線上90%的業務場景都可以實作Rt 200毫秒以内。

d.降本增效

在一本賬的架構理念指導下，AI·OS引擎為申通提供了全方位的時效監控、實操控制等産品支援，在保持全年單量上漲30%的情況下，依然達到了年降本200萬+的目标。通過多層次、多角度的資料分析和協同機制，實作了對業務流程的全面監控和精細化管理，進而大大地提升了企業的效率和競争力。

②資料鍊路

資料鍊路層是物流系統中不可或缺的組成部分，其主要功能包括實時消費訂單、實操軌迹、物流段碼、物流預測事件等，同時将原始資料轉換成相應的模型後，通過增量合并客觀資料、預測資料、網絡修複的資料，并最終轉換成AI·OS引擎所需要的資料模型。資料鍊路層作為上遊資料的統一輸入口，可以避免資料備援問題，進而解決基礎資料重複建設的問題。然而，資料鍊路層作為底層存儲引擎的統一輸入口，一旦資料産生延遲，整個使用者查詢鍊路将受到影響，是以穩定性至關重要。

為了提高系統的穩定性，我們通過鍊路更新後增加異常包裹識别、精準流控、快恢等能力，進而增加系統的魯棒性，大大減少了故障發生率。通過資料鍊路層的優化和更新，提高了整個系統的可靠性和性能，更好地滿足使用者的需求。

③“穿越時空的包裹”之物流預測

在實操場景中對于轉運中心經理來說需要安排多少實操勞工，需要排程多少車、安排什麼型号的車這些都需要提前規劃好。如果我們能提前預測有多少包裹什麼時候達到某個轉運中心，将會極大程度上能夠幫助中心提前做出規劃、排程資源并做出科學的決策。而資源預配置設定，将會自上而下傳導到實操層，最終反映到時效、品質、成本上，是以關于物流預測的重要性不言而喻。

如上圖所示，Blink流作業通過實時消費并調用算法服務生成未來的履行軌迹，以預測所有客觀的訂單和包裹詳情情況。基于最新的物流軌迹和曆史資料進行預測，通過算法來生成未來第一個事件将在XX時間發生的結果。依賴定時任務機制，檢查到預測時間時預測事件是否有發生，如未發生則重新觸發一次預測進行修正，以保證包裹預測始終基于最新的物流軌迹向後進行預測。客觀物流消息和預測資訊在包裹引擎中無縫融合實時寫到AI·OS引擎，通過AI·OS引擎實時OLAP能力同樣也實作了預測包裹的宏觀微觀一緻。

我們基于AI·OS引擎強大的實時算力，将最新的物流事件以及末端資訊作為預測輸入因子，依據大資料采集曆史上目前這個操作站點當時(同一個小時)的途徑路徑以及發生的時間，然後我們通過随機采樣的方式，實時輸出唯一的包裹預測物流詳情結果。也就是先知引擎可以實時自動補全賬本中包裹的所有未來狀态，并且實時更新預測。這樣在引擎中就形成一個過去現在未來的完整時間軸，使我們的業務需求可以自由的穿越時空，無需特别定制。通過曆史統計正态分布的采集點，然後随機篩選一個采樣點的方式，可以在宏觀上滿足實操站點對于件量預測的訴求。

在準确率達成方面，直屬中心出港件量平均準确率95.5%，其中75%的中心準确率達到95%以上；直屬中心進港平均準确率94.1%，其中60%的中心準确率達到95%以上。并且為了滿足時效準确預測路徑、包裹的标準路由規則定制，我們依據大資料統計分析，将物流末中心、末網點、收發件位址作為輸入因子按照曆史正态分布，推測末中心。通過這種方式預測的末中心準确率接近98%，相比直接使用物流分單的末中心段碼準确率提高8%。

④網關

由于底層AI·OS引擎不具備場景級别的精準限流、熔斷降級、業務分類監控等能力，而我們通過建設統一名額開放平台，增加熔斷、限流、冷熱分離、監控等能力，提升底層引擎查詢鍊路的整體魯棒性。通過統一收斂業務場景名額，保障了出入口統一的同時使得業務名額可監控、可治理、可灰階、可擴充。

業務名額查詢關鍵設計

在業務網關這層，我們通過內建SDK讓使用者在無感覺的狀态下将冷熱資料分離，14天内的熱資料通過實時線上分析引擎查詢實作了高效業務查詢，而14天外的冷資料則通過離線引擎查詢實作了資料的擴充。

⑤引擎管理平台

a.引擎管控平台

引擎管控平台集易用性和穩定性為一體，具備流量回放、業務名額場景灰階測試、引擎資料一鍵修複、資料治理、查詢鍊路溯源、引擎性能監控等産品能力。

b.名額平台

名額平台緻力于業務個性化名額以及通用名額的維護、名額口徑定義、描述、名額訂閱、名額預警等，使用者在這裡可以自定義線上或者離線名額模版，實作業務名額統一化管理的同時也解決了業務資料名額一緻性的問題。通用名額業務負責口徑收斂，基于包裹基礎資料定義的同一個名額，保持口徑一緻，已定義的業務名額可供各部門使用者訂閱，避免重複造輪子。業務個性化名額支援使用者特定場景模版配置、定義、描述等。

05

典型業務場景落地

先知引擎在申通已經覆寫了衆多的業務場景，下面我将通過兩個廣泛使用的範例來講解引擎在業務中的應用。首先我們來了解時效控制塔中的中心視角資料看闆。

中心出港的網點實時攬收量

申通營運産品移動昆侖中的“時效控制塔”主要是通過對現場實時資料的分析，指導一線從業人員按時完成工作，保障包裹在鍊路中的時效生命。産品頁面上非常多的實時名額和數字，其中我們選取第一個數字“中心出港的網點實時攬收量”進行詳解。

快遞公司中心的網點攬收量是個複雜的業務含義，樸素的了解就是該中心下轄的所有網點，在今天已經收了多少貨，這個資料名額可以提前知道中心今天的工作量，越早越準地知道這個數字就可以更好的安排今天的勞動力和資源。就是這麼一個最普通的名額也有着非常複雜的業務口徑。

1.每個網點的交貨關系并不是完全一對一的，也就是中心下轄的網點，也有可能把貨交到其他中心去，需要根據包裹的目的地來區分交件關系。在引擎中，我們使用預測路徑完美的解決了這個問題。

2.該名額是用來指導中心當日的工作安排，是以也包含了之前網點滞留的包裹。

3.網點和中心之間還可能有集散中心，是以還要考慮集散中心内部的包裹。

4.還有一些特殊的運作模式，如義烏永康的網點直發，這些包裹雖然是從網點發到中心的，但屬于進港，而“網點攬收量”需要看出港包裹來安排出港工作。是以這部分要排除在外。

5.外省中心發過來的包裹肯定不符合“下轄網點”的定義，屬于進港包裹，也要排除在外。

6.單中心的同城件，按照業務的定義，不在出港範圍内，也要排除在外。

經過上面詳細的業務解讀， 我們進入資料名額的開發。包裹引擎最重要的功能就是sql即應用。我們隻需要把上面的業務細節，翻譯成引擎的查詢語句，就完成了業務開發。并且可以實時查詢實時更新。引擎的查詢語句是類SQL的，見下面的較長的描述：

#廣東廣州轉運中心出港包裹網點實時攬收量
#引擎配置和叢集資訊
config=start:0,sub_doc:group,get_all_sub_doc:true,timeout:60000&&
cluster=express_history.defalt_agg &&
#召回部分，在海量包裹裡通過索引快速找到符合條件的，got_time限定攬收時間
query=got_time:[1675785600,1675836644] AND
  #sub_nat_type是軌迹資訊的類型，0或者1代表真實軌迹和預測軌迹都可以
  #sub_node_code是軌迹消息發生地點
  #029167代表廣東轉運中心，也就過去、現在、未來有一條軌迹在廣州中心發生
sub_nat_type:0|1 AND source:1 AND sub_node_code:"029167"
  #包裹的末中心不是廣東，剔除同中心的省内件
  ANDNOT predict_last_terminal:"029167" &&
#使用複雜時空計算函數sub_attribute“擷取第一個符合條件的軌迹消息的某個字段”
#重新定義一個臨時變量first_trunk_node
virtual_attribute=first_trunk_node:
  #要擷取回報符合條件的站點中心id，如果沒有找到，回報預設值為空
sub_attribute(sub_node_code,"",
        #限制條件：提出提第一條軌迹是轉運中心（但包括義烏永康），同時跳過廣東的下屬集散，
        #擷取到的包裹的第一個中心。
       (sub_node_type=3 OR sub_node_code="322000" OR  sub_node_code="321300")
        AND (sub_node_code!="511088" AND sub_node_code!="516650"
             AND sub_node_code!="517050" AND sub_node_code!="518140"
             AND sub_node_code!="518189" AND sub_node_code!="525060"
             AND sub_node_code!="530355")); &&
#上面擷取的包裹的第一個中心是廣州的留下
filter=first_trunk_node="029167" &&
#聚合及展示參數
aggregate=group_key:got_gac_code,agg_fun:count(),max_group:10000;           

接下來我們講解中心進港業務中的使用案例。

實時分析進港中心已到未發量

申通營運産品移動昆侖中的“時效控制塔”通過實時監控進港中心車輛排隊情況、操作工實操情況等實時幹預和指導現場實操。這裡選取“未發件量”名額進行詳解。

快遞公司中心進港是一個複雜的業務場景，若目前操作中心是目的中心，或者和目前中心有支線路由關系的集散中心，即算作中心進港。中心進港派次有單派，也有二派。

a. 對于進港中心來說，中心能合理按照規定時間操作完包裹，網點緊密銜接回貨,大大提升整體環節的時效。進港中心若趕不上網點一派最晚的時間完成發件操作，将通過及時的預警，提醒中心經理“努努力”不要再錯過網點二派截止時間。

b. 中心進港已到未發量，不僅包含昨日滞留中心的包裹，還包括今日已卸車但未發件的包裹，将會通過實時監控場地，實時預警，事中幹預的方式防止事情進一步“惡化”。

經過上面詳細的解讀，我們進入具體資料名額開發，見下面較長的描述：

config=metrics_src:sto-operation-plan-aging_aging_control_tower,start:0,
sub_doc:group,get_all_sub_doc:true,timeout:10000
&&cluster=express_history.default_agg
召回條件：召回廣州轉運中心作為末中心在2023-05-22 12:00:00到2023-05-23 12:00:00
區間操作的所有子文檔
&&query=sub_nat_type:0 AND source:1 AND sub_occur_time:[1684728000, 1684814400)
AND sub_node_code:029167 AND (predict_last_terminal:"029167")
&&virtual_attribute=
sent_flag:sub_attribute(sub_occur_time, -1, sub_nat_type=0
AND sub_action_code=210 AND sub_node_code="029167"
AND (sub_occur_time > 1684728000 OR sub_occur_time = 1684728000)
AND sub_occur_time < 1684814400);
arrive_time:sub_attribute(sub_occur_time, -1, sub_nat_type=0
AND sub_node_code="029167"
AND (sub_occur_time > 1684728000 OR sub_occur_time = 1684728000)
AND sub_occur_time < 1684814400);
last_center_code:sub_attribute_last(sub_node_code, "NULL", sub_nat_type=0); 
過濾條件：剔除廣州轉運中心作為首中心或者已發件掃描的包裹，保留未發件掃描的包裹
&&filter=arrive_time!=-1 AND sent_flag=-1 AND last_center_code="029167"
AND (first_trans_code!="029167" OR predict_last_terminal="029167")
&&aggregate=group_key:source,agg_fun:count(),max_group:100000;]           

通過上面兩個業務案例分析可以看到，開發者隻需要将對應的業務翻譯成對應的SQL代碼即可，靈活性非常高，Sql即業務，并且支援使用者複雜的Ad Hoc(即席查詢)，大大縮短了産品傳遞的周期。

并且我們從技術上實作了開發模式的革新，相比傳統的大資料業務實時名額分析開發模式：先處理原始物流訂單資料和物流詳情，然後根據統計分析場景将明細彙總後存儲到各種業務表，最後根據業務分析需求，提供前端查詢接口，供前端名額透出。基于物流一本賬的時空引擎新的開發模式如下：

1）處理原始物流訂單資料和物流詳情，實時同步到引擎

2）根據業務需求，使用SQL或者query進行查詢統計，實時産出名額，無需預聚合

06

展望

未來我們将持續完善架構，圍繞先知引擎，在使用者易用性上降低使用者接入的門檻。比如：通過低代碼平台支撐使用者拖拽元件即可完成業務分析名額配置、業務名額預警配置等；開發易用的時空算子插件，降低引擎接入成本，不斷完善周邊配套設施。支撐算法模型的嵌入，做智能的包裹狀态識别和比對，引擎隻保留客觀詳情不存儲使用者自定義狀态。預測算法更新，比如針對大促場景根據預售、市場趨勢等資料并結合曆史、實時資料做算法模型優化，提升預測準确率。

在業務應用上覆寫更廣的一本賬，冷熱資料的統一，工數算一體。物流包裹“一本賬”是我們在申通最佳技術沉澱，将來還會延伸出運輸“一本賬”、裝置“一本賬”等。為快遞的全面智能時代打造第一塊拼圖。

來源-微信公衆号:申通技術團隊

出處:https://mp.weixin.qq.com/s/iyrVuFvLh3M1EeQRccwZnA