关于后端:电商-SaaS-全渠道实时数据中台最佳实践

摘要：本文整顿自聚水潭数据专家张成玉，聚水潭高级数据工程师应圣楚，在 FFA 2022 行业案例专场的分享。本篇内容次要分为四个局部：

1. 实时数仓的建设和倒退
2. 数据中台的产品体系及架构
3. 实时计算的实际和优化
4. 对实时计算的将来瞻望

点击查看直播回放和演讲 PPT

聚水潭是一家做电商 ERP 的公司，ERP 次要由四个模块组成，OMS、WMS、SCM、DRM，其中 OMS 是订单管理系统。从 2014 年倒退至今，聚水潭曾经对接了 300+ 线上平台渠道 ，客户通过咱们的 ERP 产品能够对立做订单的治理，防止了须要去各个线上平台独自解决，全渠道也是由此而来。基于 ERP 的底座，咱们的数据团队打造了为商家服务的实时数据中台，目前曾经有两万 + 商家付费订阅。

一、实时数仓的建设和倒退

聚水潭倒退至今大略经验了四个阶段。

第一阶段，为了满足商家报表的看数需要，提供了 SqlServer 的在线查问。但它有一些弊病：

• 无奈提供丰盛统计指标；
• 业务库耦合，RT 不稳固，商家体验差。
• 分库分表很难全局聚合统计，影响经营剖析。

第二阶段，通过 AnalyticDB、多集群 ETL 做 T+1 的离线剖析，补足 SqlServer AP 能力的有余。

第三阶段，通过 Flink+MC 实现实时 / 离线 Lambda 架构的双链路，MC 补齐了模型、调度、跨集群统计的短板。计算引擎实现了秒级更新，反对业务高时效的统计需要。

第四阶段，实时数仓 1.0 落地，通过 Flink 实时模型标准、数仓分层落地，包含自建 DB 提供实时维表和外置状态存储，用 Hologres/PolarDB 作为 ADS 层存储，提供不同场景高效查问。

上图是咱们实时数仓的架构。咱们大多数的数据都在 SqlServer 的业务库，而后通过咱们自研的同步中间件，同步数据到 Kafka 或者 SLS 里，作为 Flink 的 ODS 层。接着通过 Flink 荡涤到 DWD 层，DWD 层和咱们自建 DB 做了很多维表关联，包含外置状态交互。接着通过 Flink 做 ADS 层的聚合运算，ADS 的后果依据不同的业务场景落到不同的存储引擎里。

目前在聚水潭次要分为两个模块。第一个是在线服务，它目前撑持咱们的实时数据门户、实时大屏的业务场景，次要由 PolarDB 和 Redis 承接。第二个是 AD-HOC 剖析，它目前撑持实时物流场景，次要由 Hologres 和 AnalyticDB 承接。

二、数据中台的产品体系及架构

聚水潭的数据中台次要为商家服务，基于商家的看数场景，咱们形象了三个外围因素，别离是角色、数据、场景。简而言之，就是什么样的人，在什么样的场景，看什么样的数据。

上面通过两个场景，带大家感受一下，为什么咱们要通过实时计算的形式来满足商家高时效的看数需要。

场景 1：在线交易实时多维分析。商家经营人员常常要面对在线交易实时多维分析的场景。最开始咱们通过在线库提供简略的反对，但在线库有大商家 RT 响应慢，多表关联性能差，AP 查问性能差的问题。所以咱们基于实时计算，在中间层做多表关联，在应用层实时聚合，将数据量级升高。通过 KV 做疾速查问，来满足商家高时效的疾速场景。

场景 2：仓管发货实时跟踪。咱们的商家很多都有本人的仓库或者三方仓库，对于仓库内的仓管，他们须要对每天的发货状况做实时跟踪。最开始咱们通过离线计算的形式产出 T+1 的数据，但这就会导致今日发货进度无奈感知，发货不及时产生资损，所以商家有很强烈的实时看数需要。咱们通过实时计算保证数据的秒击产出，且咱们提供了多个仓库发货进度的实时统计，仓管能够基于咱们的实时剖析数据来做实时驱动，调配发货。

上图是咱们实时数据中台的残缺架构图。目前最底层的数据源曾经对接了 300+ 平台，100+ 物流公司，通过实时计算的分层来撑持多业务场景、多主题的数据分析。目前咱们的实时场景能够分为两局部，实时场景剖析和实时风控监控。

实时场景剖析能够分全渠道今日销量统计、多平台多店铺汇总统计、重点商品多维统计、多平台直播剖析、售后类型实时剖析、发货进度实时跟踪。

实时风控监控目前做的比拟多的是物流实时预警，将来将要做的库存实时监控、价格实时预警。

商家的业务同学能够大抵分为经营同学、售后同学、直播同学、仓库同学。他们在咱们的实时门户里都能找到本人对应的业务场景，满足他们实时看数的需要。大抵咱们分为了以下六个板块。

• 多平台多店铺汇总指标，实时趋势历史比照。
• 重点店铺外围渠道置顶，新店铺新渠道孵化。
• 主推样式重点商品关注，新款新品销售跟踪。
• 发货进度及未发货状况，要害节点超时危险。
• 主播带货反对跨天统计，头部主播直播爆品。
• 售后订单退货金额统计，售后单据起因跟踪。

以上板块能够满足不同的业务同学，其中“多平台多店铺汇总指标、重点店铺外围渠道置顶、主推样式重点商品关注”能够帮忙经营同学疾速响应。“发货进度即及发货状况”能够帮忙仓库同学做发货的实时跟踪。“主播带货反对跨天统计”能够帮忙主播做跨店统计。“售后订单退货金额统计”能够帮忙售后同学做售后订单的实时跟踪。

咱们的全渠道实时数据大屏次要满足商家平时或者大促阶段的投放诉求。岂但涵盖了实时数据中台的大部分模块，又做了销量热力地图，让散布高深莫测。

三、实时计算的实际和优化

咱们把 Flink 的一些难题演绎为以下三类。

• 第一类，多流关联。这里特指多事实流状态关联，关联周期长。
• 第二类，大状态治理。它可能会有 TB 级的状态，甚至更大，且它的 TTL 可能会超过一个月。
• 第三类，高时效体验。包含稳定性、工作提早的概念。

举个例子，商品摊派、拆分是 Flink 的一个工作，它属于数仓的公共层。这个工作背景是客户想要看到商品粒度金额、件数、成本价等等信息。对于这样的需要，咱们把整个流程拆成三步。

• 第一步，三流关联。三流别离是订单流、订单明细流、操作日志流。订单流里是领取工夫等根本的订单信息；明细流里是商品粒度的成本价等信息；操作日志流会记录一些删除的信息、update、更改其余字段的信息。关联之后的数据，咱们再依据业务逻辑做商品摊派。
• 第二步，商品摊派。这一步咱们会把订单上的金额，摊派到具体的每个商品上。这样咱们就能够失去商品的金额和件数了。
• 第三步，组合装拆分。它有个非凡的业务场景，商家会把不同的商品打包成另外的商品来卖。比方 a 和 b 商品，会打包成 c。如果产生 c 的订单，须要拆分成 a 和 b 做统计，具体去看它的成本价和销售金额。

在下面的场景中，有一个多事实流关联的问题。最后咱们是用 Join 来解决的，也就是把三条流分为两次 Join 去解决，但工作效率不太现实，状态也较大。之后咱们参考了一些行业案例，并理解到 UNION ALL+KEY BY 是关联键统一的，所以起初咱们用 UNION ALL+KEY BY 代替了屡次 Join。这个计划的原理是咱们能够复用它的状态，即 UNION ALL+KEY BY 每条流的状态只保留一份，而 Join 保留多份。

另外，多事实流关联还有一个关联周期长的问题。在某些场景下，比方订单今日发货了，而明细表却是一个月前的，这时它的状态保留工夫不确定，甚至可能超过了一个月。对此，咱们会引入额定的状态管理机制。

在分享状态管理机制前，先来论述一下 Flink 对一些大状态的痛点。

第一，效率。效率问题在小状态的时候是没有问题的，效率很快，但当状态达到 TB 级别，甚至几十 TB，它的读写效率就会显著降落，且状态复原工作的工夫也比拟长，通常须要几十分钟的工夫。

第二，稳定性。Flink 的状态越大，Checkpoint 的工夫越长，这就会导致一些提早的稳定，也就会不满足咱们对于高时效的要求。

第三，灵活性。目前社区版 Flink 和商业版 Flink 都只提供了 TTL 这个清理策略，所以咱们无奈依据业务的一些个性，定制删除这个状态。

基于以上痛点，咱们提出了状态外置 + 冷热拆散的计划。对于大状态的业务场景，咱们会把状态齐全外置到 KV 数据库里，而后把 StateBackend 作为外置数据库的缓存。在缓存里 Flink 算子与数据交互，优先读取 StateBackend 的数据，当流式读取读不到的时候，才会走到外置的冷数据层，也就是外置的 KV 数据库。这样咱们就能够尽量减少的拜访内部的数据库了。

写入的过程也是 StateBackend 流式写入，但写入冷数据层是 Batch 写入。它尽管不能保障 StateBackend 和 KV 数据库的状态一致性，但咱们的业务场景是 AtleastOnce 语义，能够在代码里判断它的业务逻辑，通过业务逻辑躲避数据反复。

通过这个框架咱们能够实现以下劣势。

• 能够反对更大 TB 级的大状态。大状态的大小取决于外置数据库的存储大小。
• 月周期级别的 TTL。这个 TTL 能够十分长，可能超过一个月，但它的效率比拟高，因为 80% 的数据都走到了缓存层。
• 状态能够查问。比方你能够清晰的定位状态的流转变动，通过 SQL 语句查问以后的状态。另外，咱们也能够容忍状态失落危险，比方 StateBackend 因为版本升级或者其余起因，它的状态隐没了，咱们能够从 KV 数据库无状态重启。

在实时订阅场景中，咱们须要对商家保障比较稳定，且提早非常低的实时性体验，这就要求咱们须要保障工作的稳定性和提早。在这个工作里，咱们的服务包含：

• 第一，按需计算，即只有开明或者订购的商家才会做计算，这样能够节省成本。
• 第二，商家开明性能后，须要实时看到数据，这就要求咱们的订阅逻辑也须要是实时的。
• 第三，咱们须要保障今日新订阅商家今日指标的完整性，不能从第二天才开始算。

所以，咱们做了实时订阅工作，保障工作的稳定性。

热点商家业内俗称数据歪斜。数据歪斜问题咱们有两种解法。

第一个优化是订阅流的。咱们把原本依照商家粒度聚合的数据打散成商家 + 订单粒度来聚合。之前视为商家粒度，如果某个商家的数据十分大，它会散发到 TaskManager 上面的某一个 slot，导致 TaskManager 的 CPU 始终拉满。这样它就跑不上来了，提早也会相应变高。做了打散优化后，能够让所有的 TaskManager 同时触发订阅逻辑，工作的稳定性绝对就进步了。

第二个优化，针对摊派工作中有主表和明细表关联的时候，明细表可能呈现了几十万条甚至上百万条，主表和明细表关联时的 Key 就会十分大。这时咱们把工夫窗口划分为 3 秒一个窗口注册定时器，通过定时器触发摊派动作，限度单条订单下最多 3 秒触发一次摊派，无效缓解反压问题。

四、对实时计算的将来瞻望

对于实时计算将来的瞻望，咱们将围绕流批一体、数据挖掘、风控能力这几个关键词开展。

对于流批一体，咱们心愿找到可能具体利用 Kappa 架构的场景，进步咱们的数据复用性。对于标签体系，以后还没建设比拟残缺的标签体系，将来会思考在商家标签或者商品标签方面逐渐建设，进步咱们外部的经营能力。对于风控能力，咱们以后曾经有物流预警的风控产品，将来咱们将扩大其余的业务场景，比方库存预警、分销价格预警等等，帮忙商家解决资损问题。

点击查看直播回放和演讲 PPT

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/product/bigdata/sc