InfoQ 在策划 2024 年 6 月 14-15 日深圳 ArchSummit 架构师峰会"，本次 ArchSummit 大会设置了大模型基础框架、AI 运维、数据架构、应用架构、业务架构、微服务、高可用以及 AIOps 和智能监控等多个层面的话题，欢迎到官网查看详细议题介绍。

近年来，我国快递行业呈现出快速增长和产业升级的趋势。随着电商市场的不断扩张和人们对物流服务品质要求的提高，顺丰在技术、设备、分拣、配送等方面进行了大量投入和创新。

随着客户对物流服务质量的要求越来越高， 顺丰针对货物的运输，制定了更严格的运输流程和操作，并期望对快件的全流程进行追溯。在此背景下，全链路追溯系统应运而生。

全链路追溯系统，从“快件”维度，通过提取快件在操作过程中产生的关键结构化信息，匹配场地摄像头监控，匹配分拣线数据，获取快件产生的图片，视频等非结构化数据，将数据聚合，形成快件查找的完整链路。

在传统物流运输过程中，难以做到对单票快件的全流程追溯，无法留下视频，图片，等有效数据来证明快件的状态，导致快件异常难以定位。

全链路追溯系统，以路由数据为基础，按时间维度，提取快件在中转场和终端产生的所有数据，包括扫描记录，外包装照片，安检图片，分拣行为检测视频，违规码货视频，部署在场地的 AI 算法产生的数据，等等都纳入到追溯数据记录里来。

一、系统设计与实现

1. 设计目标

非结构化数据现状：每天有数亿图片产生，每张图片大小不等，每天新产生的图片占用存储近百 T；图片从业务功能划分，有数百种，每一种业务类型的图片 需要留存的时间各不相同；作业场所网络带宽各不相同，需要优先满足结构化数据的快速传输，无法满足全量非结构化数据的上传；部分业务对图片实时性要求高，在数秒内如果无法上传图片，可能会造成危险品放行，导致损失和危险；全部中转场数百万摄像头，每个摄像头所监控的区域不同，对应业务能力不同，在全链路追溯中，摄像头必须与之对应的业务能力关联起来，才能事后有效追溯。

针对现状，需设计一套通用图片存储系统，摄像头管理系统，满足以下要求：

当业务方想访问某些图片时，在要求时间内，能看到图片；所有的图片要求可查询，可统计；对于实时性要求很高的业务，要求保证相关图片上传的实时性；绑定摄像头所监控区域对应的业务能力。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. 应用效果

视频全链路追溯功能帮助顺丰提高了服务质量。快递业务需要准确、及时地完成收寄、派送等多个环节，链路长、场景多，使用视频全链路追溯功能后，可以通过对数据分析来有效识别和防范问题，从而最大限度地保障客户需求。

三、面临技术挑战，视频全链路

追溯功能期待更高层次发展

为了更好地提升服务水平与效率，视频全链路追溯功能得以应用并得到广泛关注。该功能主要通过设备安装传感器、获取数据、上传云端等技术手段实现对快递运输过程全方位监控与追踪。具体而言，在寄件环节中，用户在下单后将货物交由物流公司，并通过视频监控系统获取到快递员取货过程、入库过程等信息；在配送环节中，则可以通过实时视频监控帮助现场工作人员及时发现异常情况，并及时处理。

但是，随着数据量越来越大、技术要求越来越高和运营场景的多样化，在实践中视频全链路追溯功能面临着诸多技术问题和挑战。其中，对存储空间的要求、传输质量的保障、数据分析处理能力的提升都是不可避免的问题。

在物流业与技术交融日益深入的今天，人们对视频全链路追溯功能也有了更高层次的期待。未来，该功能将更加广泛应用，并且结合实时数据与大数据分析技术，更好地助力物流服务。

【活动推荐】

InfoQ 在策划 2024 年 6 月 14-15 日深圳 ArchSummit 架构师峰会"，本次 ArchSummit 大会设置了大模型基础框架、AI 运维、数据架构、应用架构、业务架构、微服务、高可用以及 AIOps 和智能监控等多个层面的话题，行业覆盖既涉及互联网企业，也包括金融、工业制造、汽车等非互联网企业。希望无论从技术还是行业维度都能为听众呈现多元、丰富且有深度的干货实践内容，提供自由畅快的学习交流平台。

如果你想来会议上分享实践案例，或者经过验证的技术方案，欢迎扫码提交你的内容。目前会议 8 折优惠购票，火热进行中。购票或咨询其他问题请联系票务同学：17310043226