共计 3155 个字符，预计需要花费 8 分钟才能阅读完成。
往年双十一快递有多快 、 双十一快递比外卖还快 这些话题在往年双十一期间频繁呈现在热搜榜上，“ 凌晨付款起床收货”成了往年双十一快递时效的新标签。作为天猫官网物流服务提供方，往年菜鸟联结 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 将提供全方位、多维度以及准实时的实例运行状况洞察能力，通过对实例外部的各类运行日志和时序指标进行算法建模，提供出问题前精确预测、出问题时及时告警、解决问题时精准定位的能力，确保不影响用户下层业务。
原文链接
本文为阿里云原创内容，未经容许不得转载。
