Flink-Connector 客户实践案例

看下京东物流的数据特色，以及面临的主要挑战。大家知道在京东 APP 下单之后，订单由商城域进入物流域，从仓储进分拣，从配送到妥投，最后到消费者手里。整体的物流业务很复杂，流程也很长。随着实体包裹在物流位置上的运输，数据经过了很多环节，还有物流批次的一些行业概念，又多了一些时间维度。整体的数据环节复杂，呈现出多维立体分布的特征。

除此之外，流程复杂，业务系统也很多。因为既有架构演进的历史原因，仍然存在多种数据源。所以京东物流的数据架构上，比较依赖联邦查询的能力。

在业务层面，有很多宏观的数据汇总指标，来指导生产。需要把聚合后的结果，进行关联出统一数据指标。所以聚合查询，和多表关联也是一个特色。

我们可以看下京东物流的早期架构，整体分为数据服务链路和数据分析链路，这两条线基本上是割裂的。

数据服务的链路，由 Flink 消费消息队列的数据，送入到一些数据库产品当中。主要有 ClickHouse，ES 还有 MySQL，为了接口能够提供稳定高效的查询服务。而灵活分析的场景，没有固定的模型能够应对所有查询，可能会基于 Hive 或者 Presto，以 Adhoc 的形式完成比较复杂的 SQL。

总体分析，早期架构有这样一些问题。

• 数据源多样，维护成本比较高。
• 性能不足，写入延迟大，大促的场景会有数据积压，交互式查询体验较差。
• 各个数据源割裂，无法关联查询，形成众多数据孤岛。然后从开发的角度，每个引擎都需要投入相应的学习开发成本，程序复杂度比较高。

京东物流经历了大数据产业化的整个历程，数据应用多种多样，使用数据的方式也各不相同。于是，着力打造了 UData 平台，作为数据资产和数据应用之间的桥梁，以数据接入或者外表关联的形式，形成统一数据收口。StarRocks 作为 UData 平台的核心底座，支撑了两个主要场景：

1. 以接口的形式，提供稳定可靠的数据服务模块。
2. 给业务人员提供极速的灵活分析模块。让业务可以在数据指标地图上，在线查找自己需要的数据指标。

并且做了指标配置化开发、指标积木式编排、可视化 SQL 编辑等平台侧赋能，解决数据使用的最后一公里问题。