Blink 有何特别之处？菜鸟供应链场景最佳实践

[原创文章：www.11jj.com]

阿里妹导读：菜鸟供应链业务链路长、节点多、实体多，使得技术团队在建设供应链实时数仓的过程中，面临着诸多挑战，如：如何实现实时变Key统计？如何实现实时超时统计？如何进行有效地资源优化？如何提升多实时流关联效率？如何提升实时作业的开发效率？ 而 Blink 能否解决这些问题？下面一起来深入了解。

[原创文章：www.11jj.com]

背景

菜鸟从2017年4月开始探索 Blink（即 Apache Flink 的阿里内部版本），2017年7月开始在线上环境使用 Blink，作为我们的主流实时计算引擎。

为什么短短几个月的探索之后，我们就选择Blink作为我们主要的实时计算引擎呢？

在效率上，Blink 提供 DataStream、TableAPI、SQL 三种开发模式，强大的 SQL 模式已经满足大部分业务场景，配合半智能资源优化、智能倾斜优化、智能作业压测等功能，可以极大地提升实时作业的开发效率；在性能上，诸如MiniBatch&MicroBatch、维表 Async&Cache、利用 Niagara 进行本地状态管理等内部优化方案，可以极大地提升实时作业的性能；在保障上，Blink 自带的 Failover 恢复机制，能够实现线程级的恢复，可以做到分钟级恢复，配合 Kmonitor 监控..、烽火台预警..，可以有效地实现实时作业的数据保障。

接下来，我将结合供应链业务的一些业务场景，简要说明，Blink 如何解决我们遇到的一些实际问题。

回撤机制

订单履行是供应链业务中最常见的物流场景。什么是订单履行呢？当商家 ERP 推单给菜鸟之后，菜鸟履行系统会实时计算出每笔订单的出库、揽收、签收等节点的预计时间，配送公司需要按照各节点的预计时间进行订单的配送。为了保证订单的准点履约，我们经常需要统计每家配送公司每天各个节点的预计单量，便于配送公司提前准备产能。

看似很简单的实时统计加工，我们在开发过程中遇到了什么问题呢？履行重算！当物流订单的上游某个节点延迟时，履行系统会自动重算该笔订单下游所有节点的预计时间。比如某个物流订单出库晚点后，其后的预计揽收时间、预计签收时间都会重算。而对于大部分的实时计算引擎来说，并不能很友好的支持这种变 Key 统计的问题。以前，数据量没那么大的时候，还可以通过 OLAP 数据库来解决这类场景，当量上来后， OLAP 方案的成本、性能都是很大的问题。

除了 OLAP 方案，我们提倡采用 Blink 已经内置的 Retraction 机制，来解决这类变 Key 统计的问题，这也是我们在2017年初就开始尝试 Blink 的重要原因。Blink 的Retraction 机制，使用 State 在内存或者外部存储设备中对数据进行统计处理，当上游数据源对某些汇总 Key 的数据做更新时，Blink 会主动给下游下发一个删除消息从而“撤回”之前的那条消息，并用最新下发的消息对表做更新操作。