菜鸟+Hologres=智能物流

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

1、业务背景

菜鸟智能物流分析引擎是基于搜索架构建设的物流查询平台，日均处理包裹事件几十亿，承载了菜鸟物流数据的大部分处理任务。

智能物流分析引擎将基于运配网络的各种应用场景集中到了统一的一个技术架构，以此提供强大的吞吐和计算能力。基于原架构的数据处理流程为：Datahub实时采集数据源，包含仓、配、运和订单等数据，实时计算Flink基于流批一体的模式对数据预处理，造成一个以订单为单位，包含订单跟踪事件的宽表，写入存储引擎HBase中，再供外部查询。

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

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

基于以上背景，当前咱们最须要解决的问题是下降总体的资源消耗成本，那么就须要有一款产品既能提供存储能力还要提供高性能的写入能力。而在查询场景上，如果这款产品能同时知足KV查询和复杂OLAP查询将会是加分项，这样就会解决多个系统带来的数据孤岛问题，一次性知足全部需求。
咱们在集团内对多个产品进行了调研，最终选择了Hologres替换现有的HBase。

2、业务架构

菜鸟物流引擎须要处理大量的表和数据，全量任务快递线和仓配线经过MaxCompute（原ODPS）表的日分区快照作驱动源，增量任务经过对应的事件流作驱动，来进行引擎数据写入。

全量任务会根据包裹的历史履行进度进行聚合，生成这个包裹的客观履行和历史属性信息，并经过Flink Job实时同步更新到Hologres里，提供给数据任务进行关联。实时数据在接收到一条事件消息后，首先会去关联这条包裹历史履行，并会调用算法服务链，进行拆合单、末端网点预测、路由选择、时效预测等，生成新的预测履行进度。新的预测履行会做为回流数据写入TT（消息中间件，相似Kafka）和Hologres中，并再提供给数据任务进行关联。

经过数据任务之间的互相协同，咱们对数据关系进行了梳理，并尽可能下降数据之间的依赖，最终业务处理架构以下图所示：

• 数据驱动层 在数据驱动层中，包含几个部分：全量任务的主表驱动、增量任务的主表驱动、业务辅表的驱动。
• 数据关联层 数据关联层主要包括各类Flink的SQL Operator。为了提高全量任务和增量任务的吞吐，经过存储和计算优化，将数据关联尽量的分布到不一样的数据分区上，来进行性能提高。
• 数据交互层 索引数据经过Swift Sink的方式写入到索引构建服务中；要持久化的内部数据，经过写入接口保存到存储服务中。

3、业务价值

将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的时候字段名写错当即报错，错误信息很明确，避免了潜在的错误风险，还能节省时间。