大数据分析平台之 OLAP 架构的最佳实践

畅谈Fintech 2024-02-22

导读本文将分享聚水潭云原生 OLAP 架构的最佳实践。

内容分为五部分：

1. 业务介绍

2. 数仓架构

3. OLAP 最佳实践-物流预警

4. 未来展望

5. 问答环节

业务介绍

首先来简要介绍一下聚水潭。

1. 我们是什么样的公司

聚水潭是一家以电商行业为基础，以 ERP 为核心，提供全域、全链路业务解决方案的科技公司。其中数据团队在商家全链路和全域场景的协同中扮演了非常重要的职责。聚水潭从 2014 年成立至今，已经服务了累计超过一百万商家，这其中积累了丰富的 B 类商家服务经验。这里可能很多人不了解聚水潭，简单分享一组数据，20 年后每年双十一大促有百分之二十以上的订单都是通过聚水潭系统打包发货的。

聚水潭的业务，可以由 SAAS 和 ERP 两个关键词来解释，SAAS 的核心即企业级云计算，云原生的核心也是云计算，和我们今天的主题是一脉相承的。ERP 是一个相对古老的词，简单理解就是一个企业级的商家操作台，这两个词结合在一起，会碰撞出来怎样的火花呢？

这也就引出了聚水潭的核心价值和发展历程，伴随 14 年淘宝的开放、16 年拼多多、19 年抖音等各大电商平台的蓬勃发展，商家们不得不在各个平台做业务经营，聚水潭伴随电商的蓬勃发展，聚焦商家发展诉求，逐步积累起在串联线上线下全渠道的经营生意的能力。

ERP 核心的产品模块，包括订单管理、仓库管理等。订单管理就是把各个平台的订单汇总在 ERP 界面，进行订单的编辑、推送（推单给供应商一件代发）、商品的操作等。仓库管理主要是承接商家的仓库作业，进行货品的拣货、打包、发货到物流的履约。过程中 ERP 除了帮助商家内部实现多角色的业务串联同样也同外部合作商家完成了高效的协同，如一键推单供应商、三方仓按时发货等。当我们去理解抖音的直播电商或者达人经济、超级个体的这种新商业模式时，我们会发现以 ERP 为核心的效率才是其中最核心的竞争力。

2. 我们的产品

这部分围绕数据产品展开，经过近十多年的业务积累和产品迭代，我们理解数据的价值不止于 BI，在同业务场景的融合中会有更大的价值体现，这离不开对于业务场景的深入理解，我们用数据来帮助商家降低业务资损、合规及操作中的一些风险，同时也注重数据资产的沉淀，帮助业务多场景的串联（同聚水潭协同产品理念一脉相承），包括能够协同、多角色，降本增效，满足整个链路上的多方合作。这三种能力综合起来，才能定义我们的数据产品。

简言之，我们在做的是一款将数据融入业务，服务于团队的协同型产品，核心就是去满足商家降本增效的需求，帮助商家发现机会取得商业成功。

3. 产品场景

（1）发现商机

先简单的从全链路角度介绍一下电商行业，订单从各大电商平台，包括淘宝、抖音、拼多多等完成从流量到成交，之后通过 ERP 帮助商家完成订单完成后的履约和售后服务。

过去 10 年的电商是流量经济，未来 10 年我们相信是以 ERP 为核心的效率经济，涉及订单、履约到售后管理及仓储、供应链的全流程。数据产品当前完整地覆盖了：渠道分析、商品分析、直播分析和分销分析。

渠道分析能够帮助商家找到流量、钱往哪个平台去投。有一些大的商家，有上千个店铺，到底每个店铺承载的流量效果怎么样；另外也会有供应商有几十、上几百个分销商，到底要往哪个分销商去倾斜资源。渠道分析能够提供非常好的数据作为辅助。

商品分析模块，重点受益于 OLAP 引擎的能力，能够实现商品级别的监控和自助式的分析。核心包括两部分，一是基于规则的商品监控，比如引流款、利润款、潜力款等等。二是自助式分析，将底层商品丰富的资产开放给商家进行自由多维分析和统计，帮助商家综合流量、效率、售后等方面进行商品的个性化运营。

直播分析是我们即将推出的新产品，同样备受期待，我们通过直播场次、达人、商品多维分析，提供商家开播时间、达人、备货、组款等综合建议。一场小的直播，能够走完所有从商品企划到最后的效果分析、售后服务这一套流程，这也是数据产品中极具竞争力的一部分。

分销分析是与直播、渠道交叉在一起的，更多地聚焦于供应商和分销商。在供分销合作的关系之间，最关键就是靠谱系数，商家靠谱指的就是对于供应商来讲，这个分销商是否能帮我去赚钱，是否有很好的带货和影响力传播能力。作为分销商，也会考量某一个供应商的品货、库存保障、发货时效及售后服务等。在 ERP的场景中，分销分析能够为供应商和分销商提供非常好的参考。

大家如果感兴趣，可以注册为一个简单的个体商家或者是达人商家去感受一下我们的产品。在这里就不做详细介绍了。

（2）降低资损

降低资损，也是商家最关心的场景。围绕全流程的商家决策，我们做到了监控能力的全部覆盖，确保商家，包括消费者的综合体验做到最好。

物流预警是商家使用最多的产品，解决的是发货效率的问题，有了它，大家再也不用担心延迟发货被平台处罚，被消费者投诉了。大家知道各平台有类似二十四小时或是四十八小时将货发掉的时效规则。物流预警核心就是将不同平台的规则应用于订单，及时提醒快超时的订单，当然商家也可以自定义发货时效。

再往后，比如售后要退货，我们会同时考虑到商家和消费者的交互过程。对于商家不能出现钱货两空的情况，消费者提出退货，货进入了物流体系钱还不能退，只有仓库验收之后才能退。从商家视角来看，很多情况下售后发生时间是不确定的，可能消费者刚买完还没有发货，单子还没有进到仓库，就提交退款了，这时候可以快速退款，自动售后。如果货已经发出且买家还没有签收的时候发生了售后，那么需要拦截快递，降低物流成本，快速止损，对消费者来讲就是无感知的退款链路。在这个过程中，无论从消费者视角还是从商家视角，我们都做到了体验和成本最优。

关于库存，在讲到商品分析的时候，可以看到我们对于商品有全生命周期的监控，库存预警体现的是怎么让货被更高效地管理起来。这是由商品的属性决定的，一个很现实的场景是不可能所有商品都会卖爆，所以需要帮助商家发现卖的好的商品，快速补货，不能断货；卖得不好的商品要识别出来是否做促销。今天把资产管理好了，是能赚钱的，管理不好，是要产生资损、产生成本的。

订单预警部分，我们也发现非常多的订单混乱问题，包括价格、拆合并单等等，商家今天卖一单可能根本就不知道能不能赚钱，所以我们要做一些价格上的监控。保证商家尽可能规避本身系统运作或商家操作环节产生的风险。

数仓架构

接下来介绍数仓架构。

1. 数仓演进历程

公司的发展经历了五个阶段。

在发展初期，核心以产品在线化的能力为主，就是做系统级的服务，这个时间段其实没有数仓。

第二阶段，基于在线的数据库，像 MySQL、SQL Server 这样的一些产品。商家统计今年的订单、今年的商品成交情况分布，需要引入具有分析能力的数据库。

第三个阶段，就是在 16 年的时候，我们自己的数据同步到我们的 Greenplum里边，来满足大企业面向未来增长的不确定性，包括多商家的隔离、安全需求。

业务团队在集群规划方面也积累了丰富的经验，目前维持了数千套生产集群，满足了商家隔离和充分资源弹性的需求。数仓这边的一个核心问题，就是数据怎么整合在一起，最终我们通过自研同步中间件解决了这一难题，完成了数据的 S 级抽取。

进入成熟期，面对的最大挑战就是商家的快速增长。我们发现自建大规模集群的难度、运维的难度以及快速满足新需求的开发难度。由于人力有限，我们开始与阿里云的数据团队合作。早期是引入 ADB for postgres 产品进行 ETL 的处理加工及报表服务。之后，为满足一些超大规模商家的报表体验，我引入 ADB For MySQL 产品。

最后，进入到升级期，我需要思考的问题是，什么样的架构可以支撑数百个数据研发的协同开发，存储处理万亿（10P）级别的业务场景。

充分地调研和试错后，我们选择采用 DataWorks+MaxCompute 离线数仓架构。在迭代过程中，我们发现 ADB PG 非常合适作为在线实时数仓的补充。

实时方面，为了满足更高时效的要求，我们引入了以 Flink 作为实时计算、Hologres 作为云原生数仓的产品组合，实现在线服务一体化的业务架构，支持商家高时效的、以大屏为核心或者是以业务预警为核心的一些场景。

进入到当前这个阶段，还是回归到数仓的能力上，即如何把复杂的架构整合在一起。不管是基于 Hologres，还是基于整个数仓的分层模型，能够把我们的成本、调度、计算、业务服务的多租户以及智能运维等各种能力整合，是我们目前非常重要的诉求。

以上就是我们数仓的演进过程，十年间不断迭代，来满足百万商家的需求。相对来讲，实时的数仓架构有一定的安全合规风险。这个实时的架构是我们目前核心依赖的产品，也借鉴了 21 年左右阿里的流批一体的概念。

2. 现有技术架构

我们将在线数据实时传输到自研的同步中间件中，并通过 Kafka 链路进行处理。接下来，通过 Flink 实现一些公共层的抽象，然后做一些计算。

通过 MC 和 Flink 的实时计算能力，进行离线和实时的双链路计算，实时链路里面特别重要的一个点就是关于状态处理。我们的数据量其实比各个平台的数据量都要大。因为我们汇集了各个平台的订单，包括出库、售后、物流等等。

面对这样一个实时链路，我们自己也做了非常多的外置状态，Flink 本身内置的状态满足不了我们高达二十亿级别的数据量。我们做了非常重要的一点，就是把整个实时链路、离线链路，包括在线服务、外置状态做了很好的抽象。在线服务，在 Hologres 和 MC 有一个非常好的外表加速功能，数据链路的同步也有很高的效率。Hologres 承担了非常重要的工作。

我们现在也在尝试用 PolarDB 的在线服务,通过并发能力满足一些特定的场景，包括 StarRocks 这样统一的引擎。这里只是列了一些产品，让大家感受面向 SaaS 级的 ERP 场景。

OLAP 最佳实践-物流预警

1. 功能介绍

接下来介绍当前物流预警的技术链路和数据链路。我们当前通过同一个 Hologres 集群对外提供了两类服务，分别是在线服务和分析。商家可以通过在线服务，对告警结果表进行查询，帮助商家快速筛选出风险单，方便下一步进行快速操作，比如联系物流、审单发货等。商家也可以对告警结果进行操作，比如忽略告警订单，或者把告警结果导出。另外也提供了订单轨迹的实时查询。然后通过订阅的形式生成告警历史结果表，我们可以对告警结果表进行分析，比如判断订单是否符合预期、是否发生过告警，或者进行商家之前的操作日志分析。

另外也结合订单各阶段的时间规则，对时效统计进行分析，为商家后续的发货时效提供一个提升依据。

2. 物流预警数据链路

接下来简单介绍一下当前的数据链路图。

如图上所示，涉及到四张业务表，通过同步中间件的方式，把数据实时集成到 Kafka，供下游实时计算。我们的规则存储在 Hologres，规则由 Flink 实施，会分钟级定时同步，获取到最新规则。

以最新的规则和订单的最新状态进行匹配，生成对应的告警时间，把消息下发给告警任务，告警任务收到消息之后会把对应的超时时间进行注册，同时也会把定时器维护到当前时间的 Aerospike 集群里。定时器触发后，会把对应的订单信息以及告警信息一并写入到告警结果表里。然后通过 Binlog 生成告警历史结果表。整体上通过自研的接口平台对外提供服务。

因为状态是存储在外部自建的 Aerospike 集群进行维护，所以三个任务都能实现无状态的重启。

整个链路，每天处理的数据大概是 100 亿。告警的定时器级别在 10 亿左右，外置状态大概有 20 亿。会存放在 Aerospike 集群里面，存储容量在 10T 左右。

3. Hologres 模型设计

如何借助 Hologres 的在线分析一体化的能力。首先我们在表模型设计时，采用了 Hologres 行列共存的存储方式。能够满足我们高 QPS 点查以及 OLAP 的查询，因为有高频实时更新。

我们也用了分区表，通过 Hologres 的分区表能力，实现了商家级别的物理分表。也可以加速后续的查询。

我们还采用了 Hologres 的位图索引及字典编码，帮助我们有效进行快速查询以及具体查询。通过合理的分布键，保证数据的分布合理，减少了数据的倾斜度。此外，在读写的时候，利用了后面的 Fixed Plan，可以进行读写的优化。通过表级别的 Binlog 加 Flink 的方式实现告警，满足后续的分析需求。接下来是一个迭代。为了体验优先，当前这个链路是没有长周期回放能力的。如果要实现订阅能力的话，需要借助于离线的能力。

4. 物流预警技术迭代

22 年的时候，我们是全量计算，所以有延迟的问题，并且资源计算成本比较高。5 月份有一个订阅的需求。所以基于这个链路，当前用的是 max compute 加 Flink 实时订阅的方式补齐商家近三十天的订单轨迹数据，满足商家订单轨迹的查询需求。

可以看到当前的链路由于缺少了长周期回放，所以需要借助于离线的能力。导致了订阅链路比较长，计算较为复杂，并且实时链路复用度也不高。我们当前主要用的是自建的 Aerospike 集群，它的运维成本也比较高。基于以上几点，我们为后续的架构做了几个调整。如上所述，我们在上游新增了几个回放任务，主要是支持长周期的回放。

通过长周期回报，我们可以实现后续新增订阅，从而实现按需计算，能减少下游的计算成本。我们也尝试把集群替换成云组件，比如说 Lindorm，以降低运维成本。我们还新增了订单/售后轨迹公共层，便于后续的业务展开。通过这个链路，可以看到。如果后续新增订阅逻辑的话，只需要通过实时链路即可，不需要再借助于离线的任务。这样就可以实现一个流批一体的有状态计算。

未来展望

最后是我们对未来工作的展望。

希望后续有更灵活的资源弹性策略，自动感知业务流量增长，实现分钟级的弹性。同时也希望有更好的租户方案，在满足业务资源分时复用的同时也满足业务负载互不影响。希望能够提供更强的智能运维能力。

我们希望在故障隔离的同时，也能提供在线更新或者更专业的自助服务。我们希望后续除了表模型，还能够提供更多的明细模型或者聚合的业务模型。我们也希望有更简单的实时订阅链路。最后，我们希望通过Hologres和MaxCompute，形成资源能力的互补。

以上就是本次分享的内容，谢谢大家。

问答环节

Q1：在数据链路这部分，Flink 的规则匹配是用 Flink CEP 还是写的 Flink 低阶函数自定义代码实现的。能不能提供一个 case，讲解一下规则匹配是通过 Flink API 自定义代码实现的吗？

A1：Flink 主要用于执行规则匹配，匹配成功后，它会注册对应的告警定时器，并生成对应的风险单。定时器触发之后，会写入到 Holo 的结果表里面。结果表里面是当前商家需要关注的一些风险订单。我们通过 BInlog 生成告警日志，提供分析能力。比如这个商家近期一定时间范围内有多少单是报过警的，发货时效是怎么样的，我们主要提供查询以及分析的能力。

Q2：物流预警，Flink 的实时数据中间层是怎么做的？在多流 join 时候，晚到的问题又是如何处理的。最后的规则匹配是如何分工的？

A2：中间层的话，我们当前是使用 Flink 加外置存储。例如我们使用的是之前的 Aerospike 集群。如果有实时的数据，我们可以暂存在外部存储里面，等后续消息来了，就能关联到。这样就能够解决这个管道的情况。

规则匹配就是通过 Hologres 的规则表，同步加载到最新的规则表之后，根据后续来的一些订单信息，比如说轨迹信息，生成对应的告警时间，后续进行匹配。

对于规则匹配和 OLAP 的分工，其实是涉及到计算引擎和规则引擎的分工。从字面意义上来讲，就是我们现在的计算和规则匹配，都是在 Flink 里面做的。我们可能借助一些外部的状态去实现业务逻辑。

OLAP 有两部分，一部分是在线服务，我们所有的告警订单，包括可能超时的订单都会通过 Hologres 承载，可以简单理解成是一个数据库。基于这个数据库的订单推进，商家可以操作一些忽略，或者是规则。在线里边也可以设一些规则，例如某个店铺要优先处理类似的规则。优先告警、订阅、分析这一块，可能要看单个订单，告警从物流预警的周期上来讲，可以叫发货超时、揽收超时、中转超时，平台的各个阶段都有告警规则的要求。

所以一个订单来讲，还要知道全链路、全流程的超时逻辑，这里面就是分析的需求。关于分工，可以简单理解为计算、规则匹配，包括 OLAP 可以简单按照这个理解去分，只不过我们现在没有把规则引擎独立出来。未来这些预警类的产品，我们都会将规则能力跟现有能力做分工。

公共层的这一部分就是把计算剥离了一部分出来。规则匹配这一部分，我们还是会用 Flink 来做。基于现有的架构，我们不会去尝试用 CEP。因为 CEP 目前在性能和一些自定义能力方面还不太能满足我们大数据链路的需求。

Q3：当前数据量下，对于长周期回放有什么难点吗？是怎么解决的？

A3：长周期回报主要是对于当前我们为了商家的体验优先，是全量计算的。后续的话我们也想在商家新增订阅之后，能够分钟级帮商家展现出近三十天最新的风险单状态。主要难点还是时效，就是回放长周期数据在分钟级完成。下游的话，需要在分钟之内提供最新的结果。

回放大家可能不太理解，我们的预警产品都是把商家过去三十天的订单范围做监控，回放就是在产品初期商家做体验的时候，能够快速把这个商家三十天订单初始化。核心难点在于数据量大，时效要求高。怎么跟现有的系统无感知的确保商家或者是大促场景、多商家订阅，能够把这东西做好。技术链路本身的稳定性和产品体验的配合，这两方面都是有难点的。我觉得问问题的同学应该还是比较了解这个业务的。

Q4：整个架构 SAAS 化以后，如何做到自己的数据处理链路和阿里云各种产品的打通。因为很多操作在云平台上进行，在自己平台处理的动作主要有哪些？

第二个问题是整个链路的多租户是每个客户都开通一套阿里云产品吗？

A4：这两个问题我一起回答，首先我们除了自建的产品，其实也有第三方服务，我们积极同云平台和云原生开源组织合作。我们这些回放能力、各个产品组建的能力，都是基于云产品发展的，所以今天这个会也是抱着学习交流的态度来的。

其次关于部署形态，这里面分三部分来看。首先我们的产品的架构是统一的。目前是 SAAS 订阅制的这种方式提供服务，不会对每个商家都独立部署，所有的商家产品都是统一的一套服务。其次，也有存在差异的部分，体现在不同商家选购不同的产品版本集组合。未来有没有可能给特定的大的商家提供这种组合式的产品体验，我觉得这个是有可能的。从公司角度来看，也有一些大客户，他们希望把整个的 BI 体系，数仓能够和我们的整合起来。我们会以分层的方式考虑，即公共层这部分我们统一来规划设计，数据加工结果及应用我们是开放的，会借助 API、OLAP 这样的形态去进行产品能力的透出。最后就是一些商家特别个性化的场景，我们需要去满足商家关于数据保存周期、归档、合规等需求。我理解个性化的服务支撑其实是面向企业级特别重要的能力。

以上就是本次分享的内容，谢谢大家。