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

一、业务背景

菜鸟智能物流剖析引擎是基于搜寻架构建设的物流查问平台，日均解决包裹事件几十亿，承载了菜鸟物流数据的大部分解决工作。
智能物流剖析引擎将基于运配网络的各类利用场景集中到了对立的一个技术架构，以此提供弱小的吞吐和计算能力。基于原架构的数据处理流程为：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 的时候字段名写错立刻报错，错误信息很明确，防止了潜在的谬误危险，还能节省时间。

原文链接
本文为阿里云原创内容，未经容许不得转载。