菜鸟+Hologres=智能物流

简介： 菜鸟智能物流分析引擎是基于搜索架构建设的物流查询平台，日均处理包裹事件几十亿，随着业务量的增加，数据在原存储系统HBase中的导入时间也越来越长。本文将会为你分享菜鸟团队如何使用Hologres成功替换原HBase架构，打造新一代智能物流平台。

作者：阿里巴巴菜鸟物流团队（弃疾，孝江，姜继忠）

一、业务背景

菜鸟智能物流分析引擎是基于搜索架构建设的物流查询平台，日均处理包裹事件几十亿，承载了菜鸟物流数据的大部分处理任务。
智能物流分析引擎将基于运配网络的各类应用场景集中到了统一的一个技术架构，以此提供强大的吞吐和计算能力。基于原架构的数据处理流程为：Datahub实时采集数据源，包含仓、配、运和订单等数据，实时计算Flink基于流批一体的模式对数据预处理，形成一个以订单为单位，包含订单跟踪事件的宽表，写入存储引擎HBase中，再供外部查询。

在数据处理部分，随着数据量的增加，原有的存储系统HBase在维表全量导入中所需要的时间越来越长，这就需要耗费大量的资源，另外其单机吞吐的表现不是很好，单位成本高。在数据量较小时，成本不是需要考虑的关键因素，但当数据量规模变大时，成本的重要性就体现出来了。菜鸟智能物流每天需要处理大批量的数据，这也就意味着每天将会浪费大量的资源。

同时，在我们的场景中，有些表是作为Flink维表基于PK进行PointQuery，有些表需要进行OLAP分析，而HBase并不能两种场景都满足。为了OLAP分析，需要将数据同步到批处理系统中，为了KV查询，需要将数据同步到KVStore。不同的查询需求就需要借助多个系统，数据在不同系统之间的导入导出不仅会加深数据同步的负担，也会带来冗余存储，也极容易出现数据不一致的情况，并且多个系统也会给开发和运维带来一定的成本。

基于以上背景，当前我们最需要解决的问题是降低整体的资源消耗成本，那么就需要有一款产品既能提供存储能力还要提供高性能的写入能力。而在查询场景上，若是这款产品能同时满足KV查询和复杂OLAP查询将会是加分项，这样就会解决多个系统带来的数据孤岛问题，一次性满足所有需求。

我们在集团内对多个产品进行了调研，最终选择了Hologres替换现有的HBase。

二、业务架构

菜鸟物流引擎需要处理大量的表和数据，全量任务快递线和仓配线通过MaxCompute（原ODPS）表的日分区快照做驱动源，增量任务通过对应的事件流做驱动，来进行引擎数据写入。
全量任务会根据包裹的历史履行进度进行聚合，生成这个包裹的客观履行和历史属性信息，并通过Flink Job实时同步更新到Hologres里，提供给数据任务进行关联。实时数据在接收到一条事件消息后，首先会去关联这条包裹历史履行，并会调用算法服务链，进行拆合单、末端网点预测、路由选择、时效预测等，生成新的预测履行进度。新的预测履行会作为回流数据写入TT（消息中间件，类似Kafka）和Hologres中，并再提供给数据任务进行关联。
通过数据任务之间的互相协同，我们对数据关系进行了梳理，并尽量降低数据之间的依赖，最终业务处理架构如下图所示：

• 数据驱动层 在数据驱动层中，包含几个部分：全量任务的主表驱动、增量任务的主表驱动、业务辅表的驱动。

• 数据关联层 数据关联层主要包括各种Flink的SQL Operator。为了提升全量任务和增量任务的吞吐，通过存储和计算优化，将数据关联尽可能的分布到不同的数据分区上，来进行性能提升。

• 数据交互层 索引数据通过Swift Sink的方式写入到索引构建服务中；要持久化的内部数据，通过写入接口保存到存储服务中。

 

三、业务价值

将HBase替换成Hologres之后，给业务带来的价值主要有以下几个方面：

1.整体硬件资源成本下降60%+
对比HBase，相同配置的Hologres有着更强的写入性能，能够提供更好的吞吐量，也就是说我们可以用更少的资源来满足现有数据规模的处理需求。在实际业务应用中，整体硬件资源成本下降60%+，解决了我们最棘手的问题。

2.更快的全链路处理速度（2亿记录端到端3分钟）
全量数据处理所需的时间是非常重要的指标，设想某一天新发布的数据处理代码有bug，新产出的数据不可用，即使修复了代码，还得继续解决已经存在的错误数据，此时就要跑一次全量，用正常的数据覆盖错误的数据。全量任务的运行时间决定了故障的持续时间，全量运行的速度越快，故障才能越快解决。
在物流分析引擎的全量中，我们需要先通过所有维表的数据，确保维表自身的数据是正确的，这是一个非常耗时的操作。以其中一张表为例，2亿多的数据量，使用Hologres同步只需要3分钟左右，这也意味着可以更快的执行完毕全量数据，以便我们能够更从容应对突发情况。

3.一个系统，满KV和OLAP两个场景，没有数据冗余
Hologres在存储上支持行存和列存两种存储模式。列存适合海量数据的交互式分析，而行存适合基于Primary Key的整行读取。这就意味着我们可以将所有的数据存储在Hologres中，需要PointQuery就选择行存模式，需要复杂OLAP分析就选择列存模式，满足了OLAP和KV查询，无需再借助其他系统，既保证了数据存储的唯一性，也避免了各种系统之间的导入导出和复杂运维。

4.大维表实时SQL查询
以前如果想查一下维表中的数据，由于是KV接口，并不是很方便。Hologres兼容PostgreSQL生态，可以直接使用psql客户端访问，通过标准的PostgreSQL语法查询表中的数据，支持各种过滤条件，能够很方便的实时检查数据是不是有问题。

5.强Schema
原有的维表存储是一个弱Schema的存储服务，在Flink任务中，即使访问不存在的字段也不会报错，只是获取到的字段值为空。代码里不小心写错了字段名，一是很难立刻发现，通常要等到数据产出时候才能发现，甚至只能等用户发现，另外排查起来也很麻烦，没法直接定位。使用Hologres的时候字段名写错立即报错，错误信息很明确，避免了潜在的错误风险，还能节省时间。