淘菜菜 ：基于Flink和Hologres的实时数仓架构升级之路

Posted 2023-03-23 aliyunhologres

作者：旋宇，淘菜菜数据研发

前言：

阿里淘菜菜（简称TCC）主营社区团购，其在阿里至少历经6年时间，为了更好支持业务发展，淘菜菜也在不断演进其技术架构。2020年淘菜菜开始与Hologres合作，历经2次大的架构升级，从传统多组件的架构升级为现在稳定的高可用实时数仓2.0，承载上千万RPS写入、几百T数据存储和秒级查询响应。在此合作过程中，淘菜菜技术团队不断沉淀出实时数仓场景下的最佳实践、开发实践、开发规范等，基于此背景，我们将会合作推出系列文章，介绍淘菜菜基于Hologres搭建实时数仓的最佳实践，内容将会包括架构升级、场景实践、容灾实践以及最近业界比较关心的成本治理等，期望与更多的企业互通有无，在数仓建设上更加简单、方便、高效。

本期我们将会带来系列文章第一篇：淘菜菜技术架构的前世今生–技术架构升级之路。

淘菜菜业务简介

阿里淘菜菜(简称TCC)事业部的前身是盒马优选及零售通，2021年初合并成立了淘菜菜事业部，主要做社区团购，和多多买菜、美团优选业务模式一致，主营生鲜和日销品，采用次日达的配送方式为用户提供服务。2022年开始和淘宝深度合作，作为淘宝生鲜和日销品类目的补充。目前淘菜菜属于稳定发展阶段，微信、淘宝、淘特、支付宝等多渠道入口，日均用户访问量上千万，数据量约有几百T。

发展历程：从数据库到高可用实时数仓

为了支持淘菜菜丰富的业务需求，其背后的技术发展历经了最初的零售通原始数据库架构、零售通传统lambda架构、Hologres实时数仓、Hologres高可用实时数仓这4个阶段。

阶段1：16年之前原始架构- jstorm阶段

该阶段为实时数仓的初期建设，主要用于零售通团队的实时作战大屏，以及核心数据产品的报表看板等。技术方案采用的jstrom，有专门的实时团队同学支持，实时任务数10个以内，实时计算的资源在3000+CU。

阶段2：16-20年传统架构 -FlinkSQL阶段

16年之后，零售通业务开始规模化增长，因此业务场景变得更加丰富，包括实时大屏、实时营销活动分析、渠道实时分析等。这个阶段主要基于Flink SQL发展，同时离线开发同学慢慢开始加入，和实时团队同学配合进行实时需求支持。直到到19年B系研发同学开始独立支持实时数据体系的建设，这个时期实时任务数快速增长到500+。资源使用也比第一个阶段上升30%。

阶段3：20年实时数仓 - Flink+Hologres阶段

随着业务的快速发展，实时数仓的建设越来越臃肿，也开始出现一些开发和运维问题。而当时Hologres也开始在集团内大面积推广，于是我们开始考虑用一套新的方案解决老架构存在的问题。因此这个阶段开始基于Flink+Hologres进行实时架构升级。

在这个阶段，零售通和盒马优选合并成淘菜菜团队。面对日益增长的数据，技术上主要要解决的问题就是实时开发提效，追求高效率、高灵活，以此来满足淘菜菜所有小二实时&离线数据的查询需求，核心应用场景包括交易实时多维分析，物流供应链实时服务、指标中心自助分析和离线报表加速等。

我们用了一年的时间（从20年9月到21年9月）完成了架构升级，通过新架构缩短了实时处理链路，提高数据处理效率，让实时数仓变得更加高效快捷。

阶段4：21年高可用实时数仓-Flink+Hologres读写分离部署

21年架构升级完成后，在新的阶段，我们的核心目标就是提升新架构的稳定性。同时业务发展也逐渐趋于稳定，除了常规场景的支持，也开始参与双11、双12等大促节日，因此成本的治理也开始提上日程，我们期望能够用最简单的架构，最少的资源支撑所有的场景。

在高可用稳定性方面，我们使用写链路的主备链路，应用层使用Hologres多子实例共享存储的部署方式，主实例用于写，不同子实例用于不同场景的查询，这样做能够非常好的做到读写分离、资源隔离以及开发生产隔离。

在成本治理侧，我们主要采取了将闲置实时任务及时治理、Hologres表存储优化等手段，21年共计节约200w+资源。

目前新的架构在淘菜菜业务稳定运行中，在本文中我们将会介绍为什么要进行架构升级，以及架构升级后我们遇见的挑战和对应的解决方案，以帮助大家更简单高效的建设实时数仓。

淘菜菜实时数仓的典型应用场景

随着业务的发展和合并，我们总结了淘菜菜实时数仓需要支持的业务场景和背后需要的技术能力。

1、高管实时播报

场景说明：淘菜菜核心数据实时查询，并且每日需要播报到高管钉钉群里，协助管理层第一时间做出业务决策。

特点：高保障、数据低延迟、指标快速订正、问题快速排查并恢复

需要的技术能力：离线实时存储一体、列式更新、多表关联、即席复杂查询

2、物流实时作业

场景说明：供物流小二使用，结合出入库、仓库作业等实时数据协助小二日常物流订单分析、订单派送等。

特点：高稳定、持续的在线服务查询能力，长周期实时数据消费能力

需要的技术能力：高可用，可快速主备切换、高效问题排查、物化视图

3、指标中心&自助分析

场景说明：配置核心指标和常用维度的查询，自助生成多维报表，支持小二多维数据快速看数，方便小二快速做运营动作

特点：多维复杂查询、大量Distinct去重、自动生成大SQL

需要的技术能力：实时多维OLAP能力，大表关联能力

4、增长平台(实验平台&圈选平台)

场景说明：为拉新和留存提供的数据增长平台，主要是提供不同实验的多维分析，同时也能支持标签圈选的能力，从而生成人群画像，帮助业务精细化运营。

特点：多维分析、大数据量交叉(7亿多数据量表关联)

需要的技术能力：多维OLAP灵活查询

5、小二日常看数报表(数来宝)

场景说明：提供给行业、营销、用户、渠道、物流等小二日常看报表的能力，需要提供历史和实时数据的查询，同时报表能够快速交付，满足小二的个性化分析

特点：基于已有的基数数据能够快速交付，灵活查询，缩短交付周期

需要的能力：外表加速、多维OLAP

回顾：传统架构及遇到的问题

以下是20年架构升级之前的架构图：

可以看到为了支持好业务，整个架构还是比较臃肿，采用多套组件支持不同的场景，架构冗余，组件复杂，随之而来带来的问题就是：

1、数据不一致： 数据团队和技术团队实时方案不一致，从底层消息流的获取，到中间加工，再到最后的应用，分别用的自有方案，源、处理流程和逻辑不一致，经常出现数据不一致问题，需要花费较多人力去排查问题。

2、开发效率低下： 多维数据分析以及常规开发模式需要分别进行开发，导致实时任务数变多，代码调试、数据测试等都比较耗时，特别是数据测试，还需要写到对应的db中，然后进行核对，效率低下。

3、运维成本高：

• 1）任务排查耗时长：实时任务链路长，部分应用层ADS的设计达到5层，加上ODS和DWD总共达到7+以上的层次，再加上有些任务本身逻辑复杂，导致整个计算链路非常长。另外由于实时本身的State不可见，在问题排查的时候非常困难，平均一个问题定位到解决就需要半天以上，严重影响线上查询效率。
• 2）长周期回滚难：由于上游采用的TT中间件（Datahub），只能回滚3日数据，对于长周期去重指标回滚就会有问题，同时为了保证数据一致性，需要另外将离线数据加入才能进行回滚。在压测的时候，上游的数据量不够，无法达到压测预期，还需要额外造离线数据。

4、实时资源浪费： 有些实时数据并不是高频使用场景，比如大促预热期的多维实时蓄水效果监控跟踪，日常基本没查询，仅在大促前两天需要使用，日常的实时计算就会导致浪费计算资源。

20年业务合并后，数据量变得更多，业务场景更加复杂，传统架构无法再继续满足需求，因此我们迫切希望能够将现架构进行替换，以此来支撑更多的业务。恰逢当时Hologres在集团内大面积推广使用，因此我们便开始了新架构的升级之路。

第一次架构升级：传统架构替换为Flink+Hologres实时数仓1.0

面向公共层的统一数仓设计

引入Hologres后，新架构如下：

1、数据源统一

通过TT（Datahub）来统一数据源的入口。因为原架构技术、算法都自己创建数据源，比如交易，技术会用metaq、notify等各种消息队列，而数据团队通常会采用TT获取mysql Binlog。ODS源不一致，导致数据统计的时候存在一些差异，因此首先就是要进行数据源统一，保证所有整个事业部的数据源头统一。

2、存储统一：CDM/ADS层升级为Hologres

CDM和ADS层统一用Hologres替换原架构的各种组件，其中：

1）CDM设计为Hologres行存表

• 下游可以直接订阅Hologres Binlog作为输入使用
• 问题排查直接查询Hologres即可，不用再云存储到MaxCompute后解析
• 生命周期可设置多天，保存更久的数据，便于长周期指标计算和压测

2）ADS采用Hologres行存和列存结合对接应用查询

• 简化代码层次，明细数据或者轻度汇总数据直接写入Hologres，然后前端调用时实时计算，保障用的时候才消耗资源，避免日常无人看的时候的计算资源浪费
• 对于高并发点查场景采用行存模式，保障在线服务的高并发查询
• 对于保障等级不同的应用进行实例隔离，如营销活动分析等应用独立申请实例。

3、计算升级

1）实时计算升级

不同的实时任务进行单独分隔，相互计算不受影响，分别更新同一个表的不同字段。

• 运维独立，高效开发和运维；单个延迟不会影响其他数据
• 前端调用简单，只需要从一个表中就可以获取所有数据

2）流批一体，计算统一、存储统一

• 实时计算完成后，直接通过同步任务写入MaxCompute上使用，不用再离线重复计算。
• 离线、实时数据相同代码在Flink引擎上采用流和批的方式分别执行，当实时数据出现问题时，可以用离线数据直接覆盖holo的历史分区。保障了口径一致、存储一致、服务一致。

4、应用服务统一升级为Hologres

1）OLAP多维分析报表快速搭建

基于Hologres列存实时宽表，用FBI快速搭建多维的数据报表。比如：将交易明细直接存储到Hologres中，对应行业、品牌、区域、商家、商品等各种维度的随意交叉可以实现快速的开发上线。

2）指标中心&自助分析平台初步搭建

与技术合作建立指标中心，通过可视化的配置化方式进行指标的开发，保障指标口径的一致性，且支持业务自主选择需要看的指标和维度。

遇到的挑战及应对方案

挑战1：Hologres随意使用带来的性能瓶颈

Hologres初期预算只有400cu，无脑使用产生性能瓶颈，在双11前的B系压测中就出现Hologres CPU使用率直接持续到100%，从而导致Hologres宕机的情况；另外Hologres的使用也没有几年，业务对于大促保障还不太熟悉。

应对方案如下：

• 首先遇到瓶颈的时候，通过文档及Hologres技术同学的调研，考虑实际数据存储量、关联条件、写入QPS/并发等，考虑对数据的分布Table Group和Shard count进行优化。
• 其次，考虑数据表本身优化方案，对多级索引进行优化，调整合适的表结构。
• 最后，分布和表结构本身做到极致优化的时候，考虑到还是可能存在复杂SQL高并发的时候，会对整个数据库造成压力，对于重要的数据应用就进行实例隔离。

挑战2：ETL逻辑后置带来的指标口径一致性问题

以往传统架构基本是先通过Flink计算好各个粒度指标之后，写入到对应的MySQL/HBase等数据库中，然后配置数据服务查询。而现在通过Flink计算的都是明细或者轻度汇总的数据，不会算出最终的指标，有一些逻辑片段后置到前端编写，在应用调用的时候实时计算，那么逻辑大量数据写到汇总层后，如何管理这些指标口径，保证指标计算逻辑的一致性呢？

应对方案如下：

1）数据监控

通过配置数据比对，对比相同指标不同地方展示的差异值，然后进行巡检和预警。监控平台有：业界数据对比工具进行数据比对和监控。

2）与技术合作共建指标中心

基础明细和轻度汇总数据灌入指标中心库中，然后配置指标和粒度，在展示的时候直接计算。通过界面进行指标口径的管理，保障同一个指标只用配置一次，然后在不同粒度进行使用即可。

3）逻辑下沉

针对高频使用、多场景使用、性能较差的逻辑进行下沉，还是进行预处理，然后写入holo；保障共性指标计算逻辑的一致性。

方案优点

升级后的架构带来的好处是：

1、架构统一: 统一了整个BU的实时架构，能够覆盖到所有的实时计算场景。

2、开发效率高：所见及所得的开发模式。SQL写好直接可以用，省去开发、调试、发布、运行等较多实时开发环节的步骤。

3、层次少，运维高效：

• ADS层可以大量直接从明细进行olap分析，减少ads多层计算的依赖，避免中间表的处理。
• 可无限回滚：hologres作为中间件可以存储较长生命周期的数据，cdm层可以存储更久的数据，应用使用的时候可以回滚更久的数据。

4、灵活扩展性强：OLAP查询、点式查询等都可以支持。

5、实时离线数据能较好的结合：

• 既支持实时数据存储，又支持离线数据存储，同时还能实时更新或者离线更新，无需再中转数据，统一存储。
• 离线更新历史分区，实时更新当日分区，保障数据全部实时化且可以回滚。

第二次架构升级：Flink+Hologres高可用实时数仓2.0

在新的架构上线后，随着业务的发展及应用大量使用，我们又遇到了新的问题：

企业级稳定性和成本治理需求

问题1：基于Hologres的实时架构稳定性风险增加

1）不规范

• 实时场景增长迅速，大量应用堆积到Hologres库中，实例配置不合理（计算资源配置，存储资源配置等）
• 不规范建表（分布键不均匀、异常开启binlog、TG不合理等）
• 不同场景应用调用相互影响（点查、OLAP复杂查询在同一集群上），性能瓶颈时常导致机器异常，甚至所有应用暂时不可用情况 。

2）SLA场景持续服务能力缺乏

• 实例挂掉后，因为数据量太对，实例资源大，重启恢复太慢导致数据不持续可用，特别是物流场景需要全天持续服务的在线场景

问题2：资源浪费严重

• 多份Hologres实例，同一份数据，多份存储，开发投入增加，存储成本增加
• Hologres表数据生命周期默认100年，60%以上的表不设置有效的生命周期或者设置不合理
• 开启列存Hologres Binlog，或者Binlog的生命周期设置太长（大于90天），导致存储增加

应对方案

1、升级为高可用实时数仓2.0架构

为了提升稳定性，我们将实时数仓1.0升级为高可用版实时数仓2.0，采用同城容灾、主备链路、多子实例等措施对架构升级，从而实现不同保障SLA应用隔离，新的架构如下：

其中，

1）公共层采用主备链路

• 上海region的TT作为主链路。张北region作为备链路，主要开放最近3日的数据订阅。
• Hologres行存实例作为第二条备链路，为下游提供长周期的Binlog日志订阅。

2）应用层采用Hologres主从实例（1主3从）和同城容灾

• 由于上游TT、Flink等主要资源都在上海，因此Hologres主实例选用上海集群。主实例只用于实时或者离线写入
• 3个从实例分别用于不用业务的查询，比如报表查询，指标查询和在线服务，从实例和主实例共享存储，数据只需要存储一份即可
• 建立同城灾备实例，构建完整的主备链路。

同时为了提升稳定性，我们还采取了以下措施：

1）事前规范： 制定严格的开发规范和发布红线，防止出现资源乱用、滥用的情况。

2）事中快恢： 设置指标告警，确保3分钟通过告警项发现问题 ，5分钟介入进行排查，10分钟内定位不到问题就启动应急预案，确保30分钟内回复

3）事后改善： 梳理业务查询场景，设置合适的表结构，防止出现慢SQL影响业务使用的情况。同时定期复盘问题，及时治理问题

2、成本治理

Hologres表治理

• 通过query日志 hologres.query_log查看SQL执行明细中的表访问情况，最近180天无访问的表进行清理。
• 设置合适表数据和分区表生命周期，防止出现过期表或者数据占用大量存储的情况
• 分析型实例列存表异常开启Binlog，导致存储资源消耗，重新制定Binlog开启原则以及Binlog生命周期设置合理的数值，降低存储。

方案优点

在实时数仓1.0的基础上，实时数仓2.0真正做到了写的主备快速切换，和应用层的读写分离，以及同城容灾，真正做到了高可用同，非常高效的提升了系统的稳定性，能更加专注于业务开发。

新一代实时数仓架构提效降本

1、高效支持业务看数

开发和运维提效，能够更加快速的支持业务数据的查看、分析及迭代。

• 支持各类量级数据： 支持10亿+的大数据量，并能够提供稳定的查看，不在需要额外加速或者分库分表。
• 支持各种类型场景： 行存支持点查，列存支持olap，也可以行列共存；binlog能力可以提供下游消费；物化视图等各种能力可以满足大量的场景，支持不同场景的应用。
• 快速交付： 稳定性加强，更多场景可直接视图模式或者FBI数据集的方式搭建应用，数据服务/可视化的效率大大提升。常规应用直接外表就可以提供数据服务。

2、持续化数据服务能力

实时&Hologres月均异常次数从月均5次下降到月均1次以下，实例重启恢复从50min+减少到20min恢复，核心数据应用可保障99%持续可用。

• 支持业务目标持续跟进和决策
• 物流依据实时数据持续作业

3、成本投入降低几百万

• 通过持续的Hologres无用表、长周期表治理，实例日存储节省260T，21年成本降低几百万元

未来展望

1、更加稳定

• 加强Hologres使用规范管控和监控治理，探索shard多副本等多种稳定性保障方案，提升风险评估，保障高稳定性
• 容灾方案完善，保障更加稳定
• 实例&表视角的风险评估、事前预警及事中恢复机制加强

2、更加高效

• 探索Hologres物化视图、schemaless、行列共存等多种方案，期望能够快速支持覆盖100%小二端OLAP类应用场景。

3、更加低成本

结合新财年预算情况对成本进行管理和治理，保障稳定的同时减少浪费。

• holo存储计算治理
• 无效holo表识别，长生命周期治理，其他存储异常识别
• 动态扩缩容，实现成本和稳定性的权衡