近年來，我國快遞行業呈現出快速增長和產業升級的趨勢。隨著電商市場的不斷擴張和人們對物流服務品質要求的提高，順豐在技術、設備、分揀、配送等方面進行了大量投入和創新。

隨著客戶對物流服務質量的要求越來越高， 順豐針對貨物的運輸，制定了更嚴格的運輸流程和操作，并期望對快件的全流程進行追溯。在此背景下，全鏈路追溯系統應運而生。

全鏈路追溯系統，從“快件”維度，通過提取快件在操作過程中產生的關鍵結構化信息，匹配場地攝像頭監控，匹配分揀線數據，獲取快件產生的圖片，視頻等非結構化數據，將數據聚合，形成快件查找的完整鏈路。

在傳統物流運輸過程中，難以做到對單票快件的全流程追溯，無法留下視頻，圖片，等有效數據來證明快件的狀態，導致快件異常難以定位。

全鏈路追溯系統，以路由數據為基礎，按時間維度，提取快件在中轉場和終端產生的所有數據，包括掃描記錄，外包裝照片，安檢圖片，分揀行為檢測視頻，違規碼貨視頻，部署在場地的 AI 算法產生的數據，等等都納入到追溯數據記錄里來。

一、系統設計與實現

1. 設計目標

• 非結構化數據現狀：

• 每天有數億圖片產生，每張圖片大小不等，每天新產生的圖片占用存儲近百 T；

• 圖片從業務功能劃分，有數百種，每一種業務類型的圖片 需要留存的時間各不相同；

• 作業場所網絡帶寬各不相同，需要優先滿足結構化數據的快速傳輸，無法滿足全量非結構化數據的上傳；

• 部分業務對圖片實時性要求高，在數秒內如果無法上傳圖片，可能會造成危險品放行，導致損失和危險；

• 全部中轉場數百萬攝像頭，每個攝像頭所監控的區域不同，對應業務能力不同，在全鏈路追溯中，攝像頭必須與之對應的業務能力關聯起來，才能事后有效追溯。

針對現狀，需設計一套通用圖片存儲系統，攝像頭管理系統，滿足以下要求：

1. 當業務方想訪問某些圖片時，在要求時間內，能看到圖片；

2. 所有的圖片要求可查詢，可統計；

3. 對于實時性要求很高的業務，要求保證相關圖片上傳的實時性；

4. 綁定攝像頭所監控區域對應的業務能力。

   2. 通用存儲系統架構

2.1. 技術選型

針對非結構化數據的存儲問題，要求所有的圖片可查詢，可統計，所以每天需要把這 1 到 2 億的圖片記錄存儲起來，包括圖片名稱，圖片的業務數據，設備數據，與之對應的快遞數據等。

同時，如果圖片上傳成功，還需要記錄圖片地址以供后續讀取。每個中轉場都部署了多臺不同功能的圖片視頻采集設備，自動化分揀線高速運轉，對于上層應用來說就意味著每秒會有大量圖片生成，在高峰期可能會達到 數萬記錄 / 秒，還需保存數百億歷史記錄以供復雜查詢，這就對存儲技術有了很高的要求。

2.2. 對比評測

最終可能需要選擇多種 DB 組合來存儲數據，因此首先必須對每種 DB 在各種條件下的讀寫性能做測評。經過初步分析，可選的組合有 :

• Elasticsearch 處理所有數據，數據的存儲，更新，復雜查詢，全部由 Elasticsearch 完成；

• MongoDB 處理所有數據，存儲，更新，復雜查詢，全部由 MongoDB 完成；

• Elasticsearch+HBase，Elasticsearch 存儲記錄數據，HBase 存儲后續的數據更新，Elasticsearch 提供復雜查詢，HBase 提供簡單關鍵查詢；

• MongoDB+HBase，MongoDB 存儲記錄數據，HBase 存儲后續的數據更新，MongoDB 提供復雜查詢，HBase 提供簡單關鍵查詢；

• Elasticsearch+MySQL 或 MongoDB+MySQL，同樣的 Elasticsearch 或 MongoDB 提供大數據存儲和復雜查詢，MySQL 提供數據更新存儲和簡單查詢。

2.3.ElasticSearch 和 MongoDB 性能對比

Elasticsearch 和 MongoDB 是兩種不同類型的數據庫，Elasticsearch 屬于搜索引擎，而 MongoDB 則是文檔型數據庫。

數據模型：Elasticsearch 使用文檔數據模型，類似于 NoSQL 中的鍵值存儲模型，每個文檔由幾個鍵值對組成；而 MongoDB 基于 BSON(Binary JSON) 文檔模型，BSON 是 JSON 的一種二進制表示形式，是一個由鍵值對組成的有序元素列表。

存儲方式：Elasticsearch 采用分布式存儲技術，在多節點下存儲和處理海量數據。Elasticsearch 索引、分片、副本等配置決定了它在橫向擴展性方面具有非常好的優勢；MongoDB 也支持分布式存儲，但相比較而言不如 Elasticsearch 靈活便捷。

查詢語言：Elasticsearch 支持復雜查詢語句以及全文檢索、地理位置檢索等高級查詢方式。而 MongoDB 使用基于 JSON 語法的強大查詢語言來實現數據檢索與聚合。

文檔操作性能：MongoDB 在大量增刪改查操作時，該數據庫可以快速響應；而 Elasticsearch 主要用于全文檢索、日志收集等領域，其性能表現主要取決于硬件和配置條件。

實時性：Elasticsearch 優化了全文搜索相關算法，并且可交互性更強，適合實時搜索場景。MongoDB 普適性更強些，在實際需求中往往會與 Redis 等緩存方案作為結合使用。

應用場景：Elasticsearch 主要應用于全文搜索領域，比如企業內部知識庫搜索、電商平臺商品搜索；MongoDB 被廣泛應用到社交網絡、博客發布、內容管理系統（CMS）、以及產品數據管理等領域中。

一般來說，Elasticsearch 在處理大規模文本數據時具有更好的搜索和分析能力，而 MongoDB 則更適用于規范化結構化數據。

我們采用幾種不同類型的測試：單次寫入（Write）和批量寫入（Bulk Write）。在單次寫入中，我們將對每個文檔進行一次寫操作。在批量寫入中，我們將同時插入多個文檔并測量響應時間和吞吐量等指標。

寫入性能對比：

查詢性能對比：

復雜查詢性能對比：

2.4. HBase 和 MySQL 性能對比

數據模型：MySQL 基于表格模型，采用關系模型來存儲數據；而 HBase 基于列族模型，它包含一組行鍵和列族，每個列族中又包含多個列。這使得 HBase 在大規模并發讀寫方面表現更加出色。

存儲方式：HBase 采用分布式存儲技術，將數據分散至不同的節點上進行存儲；MySQL 則使用傳統的客戶端 / 服務器結構。這導致 HBase 在短時間內能夠處理大量并發請求。

事務支持：HBase 沒有像 MySQL 那樣強大的事務支持功能。雖然 HBase 提供了一些原子性操作以及對“寫前日志”(WAL) 的支持來確保數據一致性，但不支持 ACID 特性。

查詢語言：MySQL 使用 SQL 作為查詢語言，而 HBase 需要使用 API 或者 Shell 命令行工具進行查詢。

擴展性：HBase 可以非常容易地水平擴展以滿足讀 / 寫負載增加時需要使用更多節點時的需求。MySQL 也可以通過分區或者分庫分表等方式擴展，但相比較而言相對繁瑣、復雜。

應用場景：MySQL 主要適合那些需求靈活度高且需要迅速恢復到任何一個歷史時間點（rollback） 的在線應用程序，在 Web 應用、移動設備和桌面應用程序等領域廣泛應用；HBase 則通常用于 Web 應用程序中涉及超大規模數據處理和實時操作等領域，例如社交網絡、廣告服務為核心的互聯網生態領域、物流跟蹤系統、金融交易記錄等領域應用案例。

寫入性能對比：

查詢性能對比：

可以看到 Elasticsearch 和 MongoDB 在大部分條件下性能相近，在復雜查詢條件下，Elasticsearch 略優，也可根據實際已有資源選擇 MongoDB。

簡單條件查詢 HBase 和 MySQL 性能接近，考慮到數據量級及可拓展性，在簡單業務場景下使用 HBase 更優，如果有更復雜查詢業務場景，也可選擇 MySQL。

3. 系統架構

3.1. 數據存儲架構

中轉場集成端，監控圖片文件的生成，讀取相關信息，生成記錄上報；

業務系統接收消息，補充信息，通過 Flink 等組件，將數據寫入 Elasticsearch 或 MongoDB；

下游業務系統查看圖片，調用相應接口；

上傳相應圖片，上傳完成后將結果寫入到 HBase 或 MySQL 供查詢；

業務端等待一段時間后，看到圖片。

系統上線運行，數據量逐漸增大，集群經過多次擴容，有效滿足了業務需求。

3.2. 網絡傳輸優化

除了大數據的處理，網絡的傳輸也是一個很大的問題，非結構化數據的傳輸會占用很大的網絡帶寬，現有帶寬無法滿足全量非結構化數據的上傳，必須要設置優先級，優先保證重要業務的運行。

部分業務的數據不允許出現大的延時，例如安檢等設備，檢測到違禁品后在數秒內要求立刻上報截流，所以安檢數據的傳輸要有最高的優先級。

在不同的作業時間和作業區域，是不同類型業務數據的生產高峰，處理不及時會對業務功能產生很大的影響。

對于低優先級的業務數據，采用觸發的方式，在查詢時下發上傳指令，生成上傳任務隊列，等待合適的時機上傳。

4. 攝像頭管理系統

4.1. 攝像頭匹配邏輯

隨著物流產業的不斷發展，中轉場已經成為物流運輸過程中不可或缺的一環。在中轉場內，貨物需要進行裝卸、掃描等各種作業操作，這些操作需要受到安全監控和管理。而攝像頭則是一項重要的監控設備，在保障運輸安全、提高管理效率方面發揮著非常重要的作用。

對于一個大型中轉場而言，其監控區域通常較廣泛，但具體的作業操作則需要在特定的區域內進行。為了更精確地對這些區域進行監控，并能夠及時識別相關事件并處理，需對不同作業區域進行編碼管理。

同時，在現代物流管理中普遍采用信息化手段來提高效率和準確性。在實際作業過程中，工人會將作業數據上報，系統會將該信息與攝像頭匹配，確定該攝像頭能夠覆蓋到該特定位置。

這樣一來，在查找攝像頭時也就變得更加簡易和直接：只需通過快件的特定信息進行查找即可獲得該位置對應的攝像頭。

獲取攝像頭數據，綁定區域信息；獲取到快件基礎數據，匹配相應的攝像頭；根據不通的作業類型，設定業務規則，精確獲取追溯數據；

二、實踐與應用效果

1. 應用范圍

目前全鏈路追溯功能已在順豐內部全面使用，為客戶追溯快件狀態，定位異常原因。全鏈路追溯功能還可以用于跟蹤包裹的狀態、檢查員工操作是否規范等，從而確保服務質量和快遞安全。

順豐內部使用視頻全鏈路追溯功能有兩個主要優勢：首先，它可以提高快遞配送過程中的可視化管理水平。通過該技術，在各個環節進行匹配、監控和評估等工作時會具備數據支持，做到精細化管理；其次，這項技術還可以提高服務質量。利用視頻全鏈路追溯功能，順豐能夠對減少人員工作失誤，提高服務的準確性和安全性。

在實際應用中，順豐的視頻全鏈路追溯功能常常與物聯網技術相結合使用。例如，在倉庫中增加智能感應設備可以基于傳感器監測收發件、貨物和人員流動等信息，并通過云指揮系統進行管理和調度。物聯網技術完美地與視頻全鏈路追溯功能結合使用，從而實現了更科學化和高效的快遞配送。

2. 應用效果

視頻全鏈路追溯功能幫助順豐提高了服務質量。快遞業務需要準確、及時地完成收寄、派送等多個環節，鏈路長、場景多，使用視頻全鏈路追溯功能后，可以通過對數據分析來有效識別和防范問題，從而最大限度地保障客戶需求。

三、面臨技術挑戰，視頻全鏈路

追溯功能期待更高層次發展

為了更好地提升服務水平與效率，視頻全鏈路追溯功能得以應用并得到廣泛關注。該功能主要通過設備安裝傳感器、獲取數據、上傳云端等技術手段實現對快遞運輸過程全方位監控與追蹤。具體而言，在寄件環節中，用戶在下單后將貨物交由物流公司，并通過視頻監控系統獲取到快遞員取貨過程、入庫過程等信息；在配送環節中，則可以通過實時視頻監控幫助現場工作人員及時發現異常情況，并及時處理。

但是，隨著數據量越來越大、技術要求越來越高和運營場景的多樣化，在實踐中視頻全鏈路追溯功能面臨著諸多技術問題和挑戰。其中，對存儲空間的要求、傳輸質量的保障、數據分析處理能力的提升都是不可避免的問題。

在物流業與技術交融日益深入的今天，人們對視頻全鏈路追溯功能也有了更高層次的期待。未來，該功能將更加廣泛應用，并且結合實時數據與大數據分析技術，更好地助力物流服務。