1.前言

聚水潭成立于2014年，以电商SaaS ERP切入市场，凭借出色的产品和服务，快速获得市场领先地位。发展至今，聚水潭已对接300+线上平台渠道，服务商家超80万，2020双11季全网处理订单总量达8.52亿，现在，全国电商每发出5-6个包裹中就有1个来自聚水潭系统。

当前，聚水潭使用的阿里云数据库实例超2000个，这些实例用于以SaaS ERP为核心的胜算、聚货通、云会计、淘跟单、聚工单等聚水潭全系列业务中，产品包括OLTP的PolarDB MySQL、RDS MySQL、SQL Server等，用于OLAP分析的ADB MySQL和ADB PG，通过产品和方案组合来满足聚水潭在电商SaaS ERP业务下的各种需求。

聚水潭架构图

2022年双11前夕，聚水潭数据平台产品部协同ERP、分销事业部重磅推出数据中台产品矩阵，满足商家日常经营分析需求的同时，为大促带来了更实时、全景的决策能力。在刚刚结束的大促季，数据中台产品服务商家有数万家，支持了十亿级商品、百亿级订单明细的查询分析需求，这背后离不开阿里云原生数据库PolarDB及其新特性IMCI(In-Memory Column Index，列存索引，下简称IMCI)的能力加持，带来极致稳定的商家查询体验的同时，也帮助聚水潭沉淀了宝贵的技术架构资产。

接下来我们就数据中台业务场景及PolarDB IMCI相关的特性展开介绍。

2.数据中台的产品能力

疫情三年，对电商零售行业产出了广泛影响，作为零售服务商的聚水潭嗅到了其中产业数字化升级的大好机遇，聚水潭数据团队开始了数据中台产品的设计和开发，相比数据报表，数据中台需要让商家更容易洞察到销售、渠道、直播、商品、物流、售后等不同业务场景核心数据的分布、趋势、关系和异常，从而快速定位问题，提高内外部协同和决策效益，其中数据大屏、发货预警产品为商家提供了秒级实时的业务体验，出于极致性能及快速迭代的诉求，初期选购了阿里云原生数据库PolarDB来提供在线读写服务。

2.1 实时大屏

秒级更新的数据大屏可以说是企业经营管理层的驾驶舱，可以直观、全面的了解到每天的销售、发货情况，同时可以更快、更精准地发现问题，防控风险，提高管理的时效性。

数据中台大屏示意图

2.2 发货预警

除了数据大屏看，发货预警同样收获商家的点赞，在这里商家可以看到整体的发货进度和不同发货仓今日、昨日支付未发货的订单情况，点击【更多发货分析】后可以进一步跳转进入【物流实时预警】模块。

发货预警示意图

业务部门利用【物流实时预警】功能，快速定位发货和揽收快超时、物流信息未更新等或有赔付风险的订单，内外部及时沟通协调，以保障好峰值几十万订单的顺利发出，预防资损。商家反馈依靠这个功能，减少了不少的平台的延迟发货处罚。

物流实时预警示意图

赔付风险订单预警示意图

更多主播、售后、商品、合作商家的功能就不一一展开了，关于产品的介绍及商家使用反馈可移步《双11，他们都在聚水潭数据中台里看什么？》

3.数据中台是如何使用PolarDB IMCI的？

伴随产品功能迭代及数据安全要求的升级，业务场景在简单的聚合指标查询的基础上增加了商品、订单级别的明细多维分析，在选型的多款OLAP产品中，PolarDB IMCI以其极致性能、灵活弹性、简单易用等特点脱颖而出。

3.1 PolarDB IMCI的技术特点

IMCI是In-Memory Column Index的缩写，是在已有MySQL行存表Btree索引的基础上，扩展列存形式的索引，从其名称中也不难看出，行列索引共享了基础表的数据，从而让普通的MySQL表具备了同时支持行列场景的查询需求，可以称得上是行列共存表，列存索引特性在PolarDB MySQL引擎中的功能架构图如下：

列存索引特性在PolarDB MySQL引擎中的功能架构图

从以上架构图可以看到，PolarDB MySQL引擎从存储引擎、执行算子、优化器三个层面设计了列存索引的特性：

存储引擎：支持实时事务级别一致性的行列混合存储；
执行算子：面向列存的向量化并行执行算子，支持极速的单表和多表查询；
SQL Parser/优化器：面向行列混合存储的CBO优化器，可以根据代价自动选择行存或者列存执行查询请求；

在此架构下，是的原有PolarDB MySQL具备如下优势：

100%兼容MySQL：列存具有与MySQL一致的数据类型系统，支持灵活的类型转换，100%兼容MySQL协议；
极致的HTAP性能：PolarDB在OLTP方面本身具备极致性能。列存索引使其OLAP性能也与专用的OLAP数据库系统处于同一水平；
行列混合存储，降低成本：同时支持行存储和列存储两种格式，且实时保证行列的事务级一致，同时，列存更具有低成本的优势。

3.2 基于PolarDB IMCI的数仓架构

聚水潭数据中台产品的开发和实时数仓的演进是同步进行的，借助PolarDB，逐步形成了Flink+PolarDB的实时数仓架构。

聚水潭实时数仓架构图

从上图中不难发现，采用一套统一的PolarDB的同时支持了简单的读写事务型SQL和OLAP复杂聚合查询，事务型SQL路由在普通行存节点，分析型SQL运行在更适合做分析型查询的列式索引上，使得查询速度获得数个数量级的提升。同时利用了PolarDB读写分离、RO节点灵活扩展的优势，为系统设计带来诸多优势，如：

1. 资源隔离：复杂的OLAP查询与RW节点完全的资源隔离，OLTP和OLAP的请求互不受影响。

2. 自动分离：PolarDB提供的自动SQL分流功能，自动的将复杂查询指向分析型只读节点，业务无需手动对OLTP型SQL和OLAP型SQL进行手动分流。

3. 提效降本：读写节点共享存储，一份数据消除了主备延迟，同时支持OLTP+OLAP的业务，做到了成本最优。

这些能力帮助数据研发团队极大的提升研发速度，从而助力产品的快速迭代。

3.3 PolarDB IMCI是如何支撑百亿级的订单分析?

对于PolarDB IMCI到底提升了多少性能，以销售主题-分析商品销售金额的真实生产案例来说明，同时看下IMCI是如何做到单表模式支持HTAP混合负载的？场景1：查看单商品全渠道的销售金额

SELECT  sku_id
        ,max(sku_name) sku_name
        ,sum(order_item_amt) order_item_amt
FROM    (
            SELECT  sku_id
            ,sku_name
            ,order_item_amt
            FROM    ads_jst_erp_dataportal_shop_sku_detail    --店铺自营商品售后指标表
            WHERE   co_id = $coId
                #if($startDate && $startDate != '')    -- 开始时间&结束时间
                    AND biz_date >= '$startDate' 
                #else
                    AND biz_date >= date_add($globalTime ,interval - (replace('$statisticsPreriod','d','') - 1) DAY) 
                #end
                #if($endDate && $endDate != '')
                    AND biz_date <= '$endDate'
                #else
                    AND biz_date <= $globalTime
                #end
                #if($skuId && $skuId != '')    -- 商品编码
                    AND sku_id LIKE '%$skuId%'
                #end
                #if($skuName && $skuName != '')    -- 商品名称
                    AND sku_name LIKE '%$skuName%'
                #end
         ) temp_sku_data
GROUP BY sku_id
;

场景2：店铺、平台、商品、款、统计日期等多维度统计销售金额

SELECT  sku_id
        ,max(sku_name) as sku_name
        ,sum(order_item_amt) order_item_amt
FROM    ( 
             SELECT  sku_id
                    ,sku_name
                    ,sum(order_item_amt) order_item_amt
             from    ads_jst_erp_dataportal_shop_sku_detail    --店铺自营商品售后指标表
             WHERE   co_id = $coId 
             #if($startDate && $startDate != '')    -- 开始时间&结束时间
                     AND  biz_date >= '$startDate' 
             #else
                     AND  biz_date >= date_add($globalTime ,interval - (replace('$statisticsPreriod','d','') - 1) DAY)
             #end
             #if($endDate && $endDate != '')
                     AND  biz_date <= '$endDate' 
             #else 
                     AND  biz_date <= $globalTime #end #if($authShopIds && $!authShopIds != '')    -- 多个渠道
                     AND  shop_id IN ( #foreach($authShopId IN $authShopIds) $authShopId,#end - 999) 
             #end
             #if(($shopIds && $shopIds != '') |  | ($platforms && $platforms != '')) 
                 and  (
                                  1 = 0
                                  #if($shopIds && $shopIds != '')
                                      OR  shop_id IN ( #foreach($shopId IN $shopIds) $shopId, #end - 999)
                                  #end
                                  #if($platforms && $platforms != '')
                                      OR  platform IN ( #foreach($platform IN $platforms) '$platform', #end '-999')
                                  #end
                                  )
             #end
             #if($skuId && $skuId != '')    -- 商品编码
                AND  sku_id LIKE '%$skuId%'
             #end
             #if($skuName && $skuName != '')    -- 商品名称
                AND  sku_name LIKE '%$skuName%' 
             #end 
          ) temp_sku_data
GROUP BY sku_id
;

店铺自营商品销售金额多维分析SQL样例

对于第一个场景通过增加组合索引的方式可以满足，但是对于第二种场景，要枚举支持各类型的查询条件，初步预估都需要不小于10个索引，况且这里还提供了类似<、>、like等谓词，此场景下，传统的MySQL Btree索引就无法支持了。此时PolarDB IMCI给出了答案，让我们直接看表结构：

CREATE TABLE `ads_jst_erp_dataportal_shop_sku_detail` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `biz_date` varchar(15) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '业务日期（yyyy-mm-dd）',
  `co_id` int(11) DEFAULT NULL COMMENT '商家编号',
`shop_id` int(11) DEFAULT NULL COMMENT '店铺编号',
  `shop_name` text COLLATE utf8mb4_bin COMMENT '店铺名称',
  `platform` varchar(15) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '平台',
`sku_id` varchar(500) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT '商品编码',
  `sku_name` varchar(500) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '商品名称',
  `order_item_amt` decimal(38,6) DEFAULT NULL COMMENT '今日确认退款金额'
  PRIMARY KEY (`id`),
  KEY `idx_co_sku_bizdate` (`co_id`,`sku_id`,`biz_date`),
  COLUMNAR INDEX (`id`,`biz_date`,`co_id`,`shop_id`,`shop_name`,`sku_id`,`sku_name`,`platform`,`order_item_amt`)

店铺自营商品售后统计指标表

使用列存索引后SQL查询性能提升超过100倍，同时借助PolarDB Proxy节点的智能路由能力，OLAP查询可以自动路由至PolarDB IMCI节点并选择列存索引执行SQL，做到了OLTP和OLAP架构一体化的体验。

9月底，聚水潭数据中台产品正式对外售卖，通过PolarDB IMCI对MySQL 100% 兼容，帮助产品快速实现产品商业化，满足了数据中台产品的稳定性和时效性的要求，在满足产品功能快速迭代的同时，实现的功能复杂度越来越高，头部商家动辄数千万的销售订单，对营收/发货/退款等售卖情况进行分析涉及到对大量订单条目的扫描聚合关联分析等，对这些数据的快速处理很快遇到挑战：

1. 数据量巨大，达到100亿级别，普通的MySQL表索引遇到瓶颈；

2. 单个OLAP查询需要执行T级别的数据，势必会消耗大量CPU和IO资源，伴随出现了不同商家的查询干扰问题等；

过程中通过PolarDB IMCI帮助数据中台、报表架构实现了统一，和ADB系列产品形成有力组合，最终实现了PB级别实时数仓的OLTP+OLAP的一体化架构。

随着售卖客户的增加及大促的临近，PolarDB共享存储一写多读的架构再次发挥了极大的作用，垂直弹升RW，增加只读节点的操作都可以在分钟级完成。让聚水潭在双十一大促期间，沉着应付100+倍级别的流量增加面临的系统压力风险。同时，聚水潭是服务2B的业务，存在明显的波峰浪谷特性，PolarDB产品的分时弹性能力在业务低谷时将节点资源进行弹降，在业务高峰前将资源进行弹升，保障了业务查询需求，也降低了资源的持有成本，从而整体上提高了资源的使用率。

最后，引用数据中台技术架构师溪竹对于当前架构的几点总结：

1. 架构创新：Flink+PolarDB升级实时数仓新引擎，支持百万级商家全渠道数据实时分析；

2. 降本增效：统一HTAP架构，OLTP+OLAP混合负载，助力数据中台产品快速迭代；

3. 安全可靠：资源分时弹性，业务读写分离，共享存储+多读节点高效实现场景隔离。

/ End /

PolarDB IMCI助力聚水潭数据中台极致体验，实现百亿级订单实时分析

1.前言

2.数据中台的产品能力

2.1 实时大屏

2.2 发货预警

3.数据中台是如何使用PolarDB IMCI的？

3.1 PolarDB IMCI的技术特点

3.2 基于PolarDB IMCI的数仓架构

3.3 PolarDB IMCI是如何支撑百亿级的订单分析?

关系型数据库

热门文章

最新文章

相关产品

相关课程

相关电子书

相关实验场景

推荐镜像