挑战

菜鸟物流作为承接全国最大流量的快递运输平台之一, 在重大购物狂欢节日中扮演了重要角色。近年来, 尽管菜鸟 物流的仓配系统进行了多业务端的优化, 但仓配业务链路长、节点多、分析维度复杂的业务特点, 使其在开发仓配 实时数据的过程中仍面临了不少挑战。如何保障其仓配实时数据的丝滑顺畅, 建立带有“仓配特色”的实时数据 版图是菜鸟物流当前亟待解决的关键问题。

解决方案

实时数据的丝滑顺畅离不开各业务系统的密切配合, 为此菜鸟物流从全局设计上制定了一套端到端的整体解决方 案。在数据模型、数据服务、数据应用、数据保障等多方面进行了优化。其中，与实时数据息息相关的数据计算, 菜鸟物流选择了一站式、高性能实时大数据处理平台阿里云实时计算作为其主要的实时计算引擎。实时计算强大 的 SQL 功能, 提供 SQL 语义的流式数据分析能力(Flink SQL), 不仅支持两条数据流 join ，并且可以在一段代码 中实现多条数据流 join 操作;其子查询功能、视图功能、维表 join 功能等大幅降低了实时计算流数据分析的门 槛。实时计算强大的流计算性能，如 MiniBatch 优化、维表 cache&async、ignore delete、RocksDB 进行状态管 理以及可以灵活配置资源参数等，经过菜鸟物流的多次压测结果显示阿里云实时计算的数据处理速度远超预期。

另外，简单描述两个阿里云实时计算非常优秀的特性:高效的状态管理机制, 实时计算过程中(如 group-by、join 等)都会产生大量的 state ， 传统的流计算引擎基本都是选择外部存储(如 HBase)作为 state 存储方案，实时计 算的选择是单机性能十分优异的 Gemini , 这个方案大大缩短了 IO latency , 从而获得倍数的性能提升。强大的 Retraction 机制, 数据库的同一记录不断变化，会往 TT 中流入多条消息, 如果依赖这个 TT 订阅直接进 行一些汇总操作, 可能得到的记录是不对的。举例, 一笔订单原计划配送公司是 A , 后来计划配送公司改为 B , 那么 直接针对配送公司进行汇总可能得到的结果是 A 和 B 各一笔。此时, 借助实时计算的 Retraction 机制即可处理类似 的“变 Key ”场景, 可以先使用 last 函数作特殊处理, 然后再做聚合, 这样能确保最终汇总数据的准确性。

业务优势

菜鸟物流从全局设计、数据模型、数据计算、数据服务、数据应用、数据保障等各方面进行业务系统的整体优化, 搭建了菜鸟物流的仓配实时链路体系, 完善了带有”仓配特色”的实时数据版图。在数据计算上, 2018 年双 11 期 间经过实时链路压测的检验实现了 100% 的数据可用性;在数据服务上，能够针对不同应用场景提供相应服务; 在数据保障上建设了仓配实时链路的主备方案、数据服务的主备双活方案以及多条实时链路压测“特色”方案。

客户评价

我们经过调研发现阿里云实时计算强大的 Flink SQL 以及强大的流计算性能对菜鸟物流极具吸引力, 简直是理 想的实时计算引擎。在实操中我们还用到了并发调优、MinBatch 调整、写 TT 使用 hashFields 保序、特殊场景写 ads ignore delete 等不少非常实用的开发和优化技能;当然，我们还挖掘出了实时计算非常惊艳的小功能, 如 First&Last、Retraction 机制、小而美的 nullValues 参数以及高效的状态管理机制等。

实时计算 Flink 版产品交流群

阿里云实时计算Flink - 解决方案：
https://developer.aliyun.com/article/765097
阿里云实时计算Flink - 场景案例：
https://ververica.cn/corporate-practice
阿里云实时计算Flink - 产品详情页：
https://www.aliyun.com/product/bigdata/product/sc