正确设计Hologres实时数仓，性能提升10倍+

概要：天猫双11对于零售通团队来说也是全年最大的一场战役，数据响应需要更实时，但也会相应增加更多的个性化指标，业务面临的挑战也会更大。本文将会讲述阿里巴巴零售通数据平台如何优化Hologres实时数仓，达到性能提升10倍+的效果，完美支撑双11营销活动、实时数据大屏等核心场景。也希望通过此文对Hologres新用户起到一定的帮助作用，通过合理的数仓设计实现事半功倍的性能效果。

作者：
曹泰铭（潇铭） 阿里巴巴零售通事业部高级数据工程师
汪宇（旋宇） 阿里巴巴零售通事业部高级数据工程师

背景

阿里巴巴零售通团队是阿里巴巴B2B事业群针对线下零售小店（便利店/小超市）推出的一个为城市社区零售店提供订货、物流、营销、增值服务等的互联网一站式进货平台，实现互联网对线下零售业的升级，同时也为有志于线上线下零售业的创业群体提供创业平台。
整个平台的架构图如下所示，是一个流批分离且以离线为主的架构。零售通数据团队负责对离线MaxCompute数仓和实时Flink数仓的建设和维护，对内部小二和外部生态伙伴提供决策支持，数据服务和数据产品建设。

因为Hologres与MaxCompute有着极好的兼容性，并且能够对MaxCompute毫秒级加速，财年初零售通数据团队作为业务数据中台基于Hologres在业务上进行了大量的尝试，包括实时数仓公共层，冷热混合计算，查询加速等场景，因为Hologres的加入，相同的需求量，以前的架构需要2天才能完成，而现在在2小时内就能完成，大大提升了开发效率，得到了研发们的一致好评。

天猫双11对于零售通团队来说也是全年最大的一场战役，数据响应需要更实时，但也会相应增加更多的个性化指标，业务面临的挑战也会更大。基于Hologres日常在业务的优秀表现，团队也决定使用Hologres作为双11核心开发产品，应用于双11核心场景包括营销活动中心，实时数据大屏等。

在10月份对全链路进行了几次压测，Hologres在100%压测压力下CPU和内存资源在100%线上徘徊，属于压线通过。本以为能顺利通过大促考验，但在2020-11-01这天，Hologres并没有扛住业务峰值，在大量查询QPS和高并发的数据写入峰值下，RT延迟一度达到90秒，没有达到预期。
事后针对Hologres进行了整体的复盘，并在Hologres团队的支持下，通过整体结构的调整以及相关性能调优，整体性能提升了10倍+，扛住了整个双11期间的流量洪峰，为双11划下了圆满句号。

事后我们针对整个事件做了全链路复盘，发现主要问题还是出在对于Hologres的原理了解不够深入，包括技术原理、Table Group、表结构设计等，导致某些用法还不是最优，这也导致在实际业务场景中，Hologres的性能没有发挥到最大化。
我们将会通过此文讲诉阿里巴巴零售通团队如何根据业务场景合理的设计Hologres实时数仓，包括表结构、Table Group设计等，以到达更优的性能表现。也希望通过此文对Hologres新用户起到一定的帮助作用，通过合理的资源利用实现事半功倍的性能效果。

11月1日现场还原

首先我们先来还原一下11月1日的现场反馈，以更直观的方式来看看当时Hologres承受的压力和相关表现（注：监控页面为Hologres在阿里内部的监控页面，与公有云的监控页面和指标项略有不同）：

查询QPS: 每秒完成Query的数量，一般代表数据库性能和压力，23:30后的增长代表压力负荷增长（业务方开始大量关注/查询报表），00:15分的骤降代表性能降低，1点之后的降低代表业务水位下降。
查询延迟（RT）：15分左右陡升到25s，大概持续15分钟；Hologres超负荷运作，性能下降。

CPU使用率：代表正在运转的core数量。我们的实例有几百个core用于计算，但在峰值严重超负载50%+；
Woker CPU使用率：Woker的CPU负载情况，和CPU使用率基本一致，峰值超负载50%+。
这两个指标代表大量Query将会无法及时处理，在队列中等待，延迟将会较大增加，实例也有停摆的风险。

Blink写入RPS：代表每秒实时数据的写入量，0点是实时订单写入的峰值。当时有较多数据导入，对Worker产生较大的负荷，影响实例性能（比如RT，CPU使用率等），所以对部分blink写入脚本采取紧急降级操作，峰值过后1:10恢复降级，产生第二波较大的写入。

问题定位和优化手段

在Hologres团队的帮助下，经过反复的排查，发现问题主要有以下几个原因：

1）主要问题: Table Group&Shards数设置不合理，在高并发读取和写入峰值时，造成集群资源浪费和性能下降

零售通Hologres实例总计有几百core的计算资源