#今年双十一快递有多快#、#双十一快递比外卖还快# 这些话题在今年双十一期间频繁出现在热搜榜上，“凌晨付款起床收货”成了今年双十一快递时效的新标签。作为天猫官方物流服务提供方，今年菜鸟联合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详情见：产品详情
AnalyticDB知乎公众号：云原生数据仓库
AnalyticDB开发者社区公众号：云原生数据仓库
AnalyticDB开发者钉钉群：23128105