本文主要是介绍智稳双全 - AnalyticDB如何助力菜鸟运配双十一,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
#今年双十一快递有多快#、#双十一快递比外卖还快# 这些话题在今年双十一期间频繁出现在热搜榜上,“凌晨付款起床收货”成了今年双十一快递时效的新标签。作为天猫官方物流服务提供方,今年菜鸟联合14家快递公司为消费者提供了如任意门般的天猫双十一物流体验。而在这背后,正是阿里云云原生数据仓库 AnalyticDB MySQL 为菜鸟运配的运营决策提供了强有力的数据支撑,使包裹能够通过更优更快的线路到达消费者手中。
菜鸟运配双十一面临的挑战
智能运营平台作为菜鸟运配域的数据中台,一直承载着整个运配事业部几乎全部的数据洞察、分析类需求;作为运配事业部运营的眼睛,智能运营平台有将近1000个实时指标、上百张报表和几十种简报及协同场景,这些指标数据来自菜鸟6个业务域。整体业务挑战包括包裹链路长、数据源各异、实操集中发车、数据实时性要求高等。去年双十一和今年618,相继出现过慢SQL、数据导出量过大、SOP遵守率参差不齐等问题,并且大促期间会有大量的临时运营需求需要快速响应和支持,这些对数据链路的存储、抽取、计算都会是非常大的挑战,今年双十一必须要完美达成。目标如下:
1)运配数据洞察要求高并发低延迟
需要支持上百张报表和几十种简报等复杂分析场景,QPS不低于300,支持百亿毫秒级的实时分析性能。
快速支持大促期间各类数据拉取、分析、报表搭建等临时需求。
2)运配数据的时效性要求
搭建包含1000指标的秒级实时链路,和业务系统数据一致性达到99.99%,数据全链路1分钟可见。
问题5分钟发现,10分钟定位,30分钟解决,重大问题2小时内解决。
3)高吞吐的实时数据写入
支持在每秒几十万条数据高吞吐实时写入,高峰时间3倍的流量峰值。
支持各类报表的数据导出,单次可导出30万行。
4)大促稳定性保障
系统保障100%可用,0故障,0资损。
指标查询5s内响应,简报在时效内发送。
普通工单低于5个,无双高工单。
同时需要对所有指标进行TPS、QPS、RT的监控。
可进行指标或应用维度的上下线、主备切换、主备负载均衡、弹性扩缩容等操作。
为什么选择 AnalyticDB
AnalyticDB MySQL是阿里云自研的PB级云原生数据仓库,有着百亿毫秒级的分析性能、千万级的高吞吐实时写入,是阿里内部性能最好、最成熟稳定的在线数据仓库。
如下几个关键特性是我们选择AnalyticDB MySQL的主要原因:
数据更新完全实时可见
菜鸟当前数据仓库模型中,AnalyticDB MySQL需要应对每秒十几万行的更新量,业务对时效性要求非常高,写入后完全实时可见,业务上即时进行汇总报表输出。AnalyticDB MySQL基于Raft协议构建了一套分布式强一致高可靠的轻量级存储架构,可实现高吞吐实时写入+立即可见,很好的满足了业务上的时效性,对智能运营的报表汇总提供了有力保障。
高并发低延迟的复杂查询
在每秒10万行数据更新场景的基础上,智能运营平台不仅关联分析查询延时敏感(要求高性能),还要求高并发。而AnalyticDB MySQL通过优化器层面的RBO+CBO,以及分区裁剪和计算下推,计算引擎的向量执行+Codegen、存储引擎的行列存储、自适应索引能力提供了出色的查询性能,大部分查询可以在毫秒级完成;同时通过在线化的调度和云原生的弹性扩展能力,支持几百个并发的复杂查询,也符合要求。
在线查询和批处理混合负载
除了高吞吐实时写入、高并发复杂分析性能,智能运营平台还同时不定期的执行大量的数据ETL导入导出任务。在存储计算分离的架构下,AnalyticDB 同时支持在线查询和批处理。在线查询基于MPP架构,中间结果和算子状态完全使用内存(all-in-memory),计算过程完全流水线化(pipelined),查询RT小,适用于低延迟、高并发的场景 ,比如BI报表、数据分析、在线决策等。批处理模式基于DAG执行模型,stage-by-stage执行,中间结果和算子状态可以落盘,支持大吞吐量的数据计算能力,适用于数据量大或者计算资源有限的场景,比如ETL、数据仓库等。
成熟和稳定
AnalyticDB MySQL在阿里集团具有大规模的业务验证,覆盖阿里内部几乎所有BU,成熟稳定。同时AnalyticDB MySQL全面兼容MySQL协议,和现有的数据库体验一致,简单易用;此外,AnalyticDB提供了众多的运维监控指标、慢SQL日志诊断等能力,对大促的稳定性提供了有效支撑。
菜鸟运配的场景实践
菜鸟运配采用云原生数据仓库 AnalyticDB MySQL版、Lindorm、Blink等构建了包含上千指标的实时数据链路后置汇总业务技术架构,将链路上各个数据源的海量数据实时多流join形成宽表,最后通过 AnalyticDB 将千余指标开放复用,整体链路如下图所示。有力保证了菜鸟运配智稳双全的双十一运营体验。
1)将各个业务系统的消息和日志镜像到多模数据库 Lindorm(HBase)中
2)通过 Lindorm 落库后发出的 export 消息作为触发源,去 Lindorm 中取出这个主键(运单号)相关的所有数据,在 Blink 中加工成宽表后写入 AnalyticDB MySQL 中进行实时存储和分析,并提供主备切换能力
3)智能运营平台在 AnalyticDB MySQL 版中通过SQL关联查询分析,将各类指标在服务中心维护并开放出来
智稳双全的运配体验
相比去年双十一单量上涨2.5倍,TPS峰值上涨4倍以及业务指标增长一倍的情况下,智能运营平台体系面临着对数据的高实时性、高完整性、高准确性的三“高”挑战,在系统稳定性方面打了一场漂亮的胜仗,系统100%可用无延迟,数据覆盖运配全链路,真实反馈实操现状,强有力的保障了业务运营,受到运配域业务团队好评。
AnalyticDB MySQL作为链路核心,支撑了菜鸟运配平台十几万TPS高吞吐写入并且完全实时可见,复杂查询达到300 QPS,毫秒级响应,同时还兼顾不同表定期/不定期的数据导出。在数据时效性、高并发、低延时的复杂查询体验等方面提供了强力的保障,助力菜鸟实现了智稳双全的双十一运配运营体验。
未来展望
未来我们希望在现有基础上根据不同业务维度划分数据模型层,构建所有指标和数据链路,将平稳保障整个大盘,为快速迭代各项指标和快速响应业务需求打下基础。为此,菜鸟运配会持续与 AnalyticDB 保持共建,以实现更好的业务体验:
业务资源隔离
在 AnalyticDB MySQL版新推出的弹性形态下实现了资源组功能,通过新建资源组可以从现有实例划分出部分计算节点,这些计算节点资源只归属该资源组。用户可将数据库账号绑定到不同的资源组,SQL查询时根据绑定关系自动路由至对应的资源组执行,满足用户实现内部多租户隔离、混合负载的需求。资源组的创建、修改、删除等操作都可以在线实时生效,并可以通过API与用户业务系统进行深度融合,实现全自动调配。
一写多读(灾备实例)
目前业务测需要主备实例做业务分离和灾备,前端还是通过Blink双写两个AnalyticDB实例,这带来了写入的复杂性和数据一致性风险。而AnalyticDB将提供了一写多读的主备实例能力,业务侧只需写入主实例,其数据会自动实时复制到备实例,这大大简化了业务的部署和复杂性。
智能化诊断
需要做好监控和边界问题的发现机制,在出现问题时能够快速定位。期望能够充分利用AnalyticDB的监控能力,在出现问题前第一时间预警,规避问题的发生。为此,AnalyticDB将提供全方位、多维度以及准实时的实例运行状况洞察能力,通过对实例内部的各类运行日志和时序指标进行算法建模,提供出问题前准确预测、出问题时及时告警、处理问题时精准定位的能力,确保不影响用户上层业务。
原文链接
本文为阿里云原创内容,未经允许不得转载。
这篇关于智稳双全 - AnalyticDB如何助力菜鸟运配双十一的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!