关于大数据:淘菜菜-一基于Flink和Hologres的实时数仓架构升级之路

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

前言：

阿里淘菜菜（简称TCC）主营社区团购，其在阿里至多历经6年工夫，为了更好反对业务倒退，淘菜菜也在一直演进其技术架构。2020年淘菜菜开始与Hologres单干，历经2次大的架构降级，从传统多组件的架构降级为当初稳固的高可用实时数仓2.0，承载上千万RPS写入、几百T数据存储和秒级查问响应。在此单干过程中，淘菜菜技术团队一直积淀出实时数仓场景下的最佳实际、开发实际、开发标准等，基于此背景，咱们将会单干推出系列文章，介绍淘菜菜基于Hologres搭建实时数仓的最佳实际，内容将会包含架构降级、场景实际、容灾实际以及最近业界比较关心的老本治理等，冀望与更多的企业互通有无，在数仓建设上更加简略、不便、高效。

本期咱们将会带来系列文章第一篇：淘菜菜技术架构的前世今生&＃8211;技术架构降级之路。

淘菜菜业务简介

阿里淘菜菜(简称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年实时数仓 &＃8211; 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表辨认，长生命周期治理，其余存储异样辨认
• 动静扩缩容，实现老本和稳定性的衡量