技术分析：AnalyticDB 强力支撑双 11

前言

每年双十一购物狂欢节都是云原生数据仓库 AnalyticDB MySQL 版（原分析型数据库 MySQL 版）的一块试金石。今年 AnalyticDB 除了在阿里数字经济体内进入更多核心交易链路，全力支撑双十一以外，AnalyticDB 全面拥抱云原生，构建极致弹性，大幅降低成本，释放技术红利，重磅发布了诸多全新企业级特性，让用户及时拥有极高性价比的云原生数据仓库。

云原生数据仓库 AnalyticDB

云原生数据仓库 AnalyticDB 是一种支持高并发低延时查询的新一代云原生数据仓库，高度兼容 MySQL 协议以及 SQL:2003 语法标准，可以对海量数据进行即时的多维分析透视和业务探索，快速构建企业云上数据仓库，实现数据价值的在线化。

AnalyticDB 全面覆盖数据仓库场景，包括报表查询、在线分析、实时数仓、ETL 等，应用范围广。AnalyticDB 兼容 MySQL 和传统数据仓库生态，使用门槛低。

AnalyticDB 全力支撑双十一

2020 年双十一，AnalyticDB 支持了阿里数字经济体内几乎所有 BU 的业务，承载了集团的菜鸟、新零售供应链、DT 数据系列产品、数据银行、生意参谋、人群宝、达摩院店小蜜、AE 数据、盒马、天猫营销平台等 130 多个主要业务。从核心交易链路的高并发在线检索到复杂实时分析应用场景，表现非常稳定。当天各项指标再创新高，AnalyticDB 当天的写入 TPS 峰值到达 2.14 亿，通过离在线一体化架构，支持在线 ETL 及实时查询 Job 数达到 174571 个/秒，离线 ETL 导入导出任务 570267 个，处理的实时数据量达到 7.7 万亿行。

在本次双十一中，在公有云上支持聚水潭、递四方、EMS 等诸多核心业务，在专有云上支持了中国邮政集团的各类业务。AnalyticDB 数据库为这些业务方提供了数据处理 ETL、实时在线分析、核心报表、大屏和监控能力，为数十万商家和千万消费者提供稳定的离在线数据服务。

AnalyticDB 面临的挑战

双十一的一连串亮眼数据背后，AnalyticDB 也面临极大的挑战，主要体现在：

1、进入集团核心交易链路

AnalyticDB 开始正式接入集团内的核心交易链路，进入集团核心交易业务买家分析库业务，这对 AnalyticDB 的实时高并发写入、在线检索的能力提出了极高的要求。双十一总共超过 600 亿条订单记录，其中双十一 1 号 0 点和 0 点 30 分预付尾款的多波峰值达到 500 万 TPS，是日常的 100 倍。Query 95 分位 RT 在 10ms 以内。

AnalyticDB 全新研发的行存引擎首次表现亮眼，可支持千万级 QPS 在线高并发检索和分析，关键技术点包括高并发查询链路、全新的行存存储、任意列 TopN 下推、联合索引、智能索引选择等，实现了单节点 10000+QPS 并可线性扩展。在相同资源下，单表点查、聚合及 TopN 是开源 ElasticSearch 的 2-5 倍，存储空间节省 50%，写入性能是其 5-10 倍，并且保证数据的实时可见和数据高可靠。

2、进入更多生产作业环节

这一年来，AnalyticDB 深入到菜鸟仓储的核心作业环节。仓库操作人员的数据看板、数据核对、发货操作等都依赖 AnalyticDB 的高并发实时写入、实时查询和相关的数据分析能力，每秒峰值 6000 订单。ADB 作为菜鸟数仓引擎，实时监控亿级包裹在仓、揽、干、运、配每个作业节点的状态，确保每一笔订单都能按时履约，极大提升了用户体验。在 11 月 1 日的第一波流量峰值中，菜鸟仓储单实例的 TPS 40 万+，QPS 200；供应链履约单实例 TPS 峰值 160 万，1200 QPS。

菜鸟数仓数据架构图：

3、接入更多的导入任务

一些依赖数据洞察（类似 DeepInsight）的业务，他们本身也是平台方，上面每天都大量的导入任务，且这些任务需要在规定的时间内导入完成，有些甚至配置了基线要求，不仅要求所有任务在规定的时间点导入完成，还要求每个任务在规定的时间点内完成。这在原来 AnalyticDB 2.0 上（依靠跑 MapReduce 任务）是不可想象的，然而在 AnalyticDB 3.0 上可以轻松地跑完。AnalyticDB 3.0 的任务导入做到更加轻量和实时。以 11 月 8 日的导入任务为例，9074 个任务最长的只需要 921 秒，最短的 3 秒完成，平均时长 39 秒完成。

3-1.png

3-2.png

4、接入更多高吞吐的写入业务

类似数据银行之类的业务，每天会有大量的数据导入，导入的数据量巨大，对 AnalyticDB 的写入吞吐量要求极高，双十一前后数据银行的 AnalyticDB TPS 峰值写到近 1000 万，写入流量达到 1.3GB/s。数据银行利用 AnalyticDB 实现人群画像、自定义分析、触发式计算、实时引擎和离线加速。单库存储了 6PB+的数据，中间使用了大量的复杂 SQL 的交并差、group by、count、distinct、多张万亿级别的大表的 join 操作。

4.png

5、在线离线混合负载

基于在线分析和离线 ETL 混合负载的能力，AnalyticDB 支持了 AE 中台的多个双十一业务：商家端业务实现 100 QPS 的基于明细事件的商家端人群预估，将复杂的画像从平均 10 秒钟降低到平均 3 秒内。相比于传统将商家的事件加工为物化的标签，通过明细事件的分表过滤能力大幅度降低了基于事件的新人群的上线时间，从原先需要数据开发一周的工作量，降低到半天的数据配置。基于 AnalyticsDB 实现了 AE 用户洞察人群的实时聚类，从原先离线的 20 分钟离线聚类提升为分钟级别的在线聚类，并实现了权益分包算法的准实时化，从原先离线的 20 分钟分包，提升为在线的分钟级分包。后续 AE、Lazada 的在线人群缩放，精排都能够基于在线的 AnalyticDB 算法实现算法的在线化，帮助国际化提升人群、商品运营的整体效率。

AnalyticDB 最新关键技术

过去一年，AnalyticDB 完美承载起阿里数字经济体业务和阿里云公有云+专有云业务，其背后，AnalyticDB 技术架构全面拥抱云原生，AnalyticDB 完成了重大架构升级，在公有云上也同步发布了新版弹性模式，让用户拥有极高性价比、极致弹性的新一代数据仓库。以下将对新版弹性模式的关键技术点一一道来。

5.png

计算存储分离

AnalyticDB 预留模式的产品形态是采用 Shared-Nothing 架构，具备良好的扩展性和并发性。后端采用计算与存储耦合的方式，两者共享相同的资源。存储容量和计算能力均与节点数有关。用户可以通过扩容、缩容节点数来调整自己的资源需求，但是没法自由搭配计算与存储资源配比，来满足不同的业务负载需求。此外，节点数的调整往往面临大量的数据迁移，会花费比较长的时间，对当前系统的运行负载也有一定的影响。另外，计算、存储不能灵活配比，也导致性价比成为一个问题。

全面拥抱云平台的弹性能力，AnalyticDB 主推新弹性模式的产品形态，后端采用了计算存储分离的新架构，提供统一的服务化 Serverless 存储层，计算层可以独立弹性扩展，同时兼具了预留模式的性能。通过计算与存储的解耦，用户可以较为灵活地单独对计算资源、存储容量进行扩缩，更加合理控制总成本。针对计算资源的扩缩，不再需要数据的搬迁，具备更极致的弹性体验。

数据冷热分层

数据存储的高性价比是云上数据仓库的核心竞争力之一，AnalyticDB 具备数据冷热分离这一企业级特性。AnalyticDB 可以按表粒度、表的二级分区粒度独立选择冷、热存储介质，比如指定用户表数据全部存储在 SSD，或指定表数据全部存储在 HDD，或指定这个表的一部分分区数据存储在 SSD，另一部分分区数据存储在 HDD，完全可以按业务需求自由指定，并且冷热策略可以任意转换。同时，热数据和冷数据的空间使用是 Serverless 按量计费的。未来 AnalyticDB 将实现智能冷热分区，即自动根据用户业务访问模型，提前对冷数据进行预热。

冷热存储定义

冷热分离的第一步是确定冷热的粒度和边界。AnalyticDB 冷热分离技术延用了现有的二级分区机制，即以分区为冷热存储的基本单位。热分区存储在节点 SSD 盘上，获得最好的性能，冷分区存储在 OSS 上，以达到最低的存储成本。

7.png

用户可以定义全热表（所有分区在 SSD），全冷表（所有分区在 OSS），以及混合表（部分分区在 SSD，部分在 OSS）来灵活使用，达到性能与成本的平衡。如下是一个游戏日志表的实例，采用混合分区策略，最新 7 天的数据存储在热区，7 天前的数据存储在冷区。

create table event(id bigint auto_incrementdt datetime,event varchar,goods varchar,package int...) distribute by hash(id)partition by value(date_format(dt, '%Y%m%d')) lifecycle 365storage_policy = 'MIXED' hot_partition_count = 7;

冷热数据自动迁移

AnalyticDB 数据写入时，数据会首先进入热空间 SSD 上，当热存储数据积累到一定程度或者用户指定的冷表策略时会自动调度后台的 Build 任务，把数据迁移到冷存储空间。对于用户来说，写入和查询完全是透明的。

8.png

之所以这样设计是借鉴了写读优化存储的设计理念，为了实现高效任意维组合分析能力，AnalyticDB 默认是自适应全索引，即每个列上都有列级索引，这保证了 AnalyticDB 的查询性能做到开箱即用，但这会对写入性能带来较大挑战。因此 AnalyticDB 采用类 LSM 架构，把存储分为实时和历史两部分，实时部分采用行存混存的块级粗糙索引，历史部分采用全索引以保证极快的查询性能，并且通过后台数据构建任务（Build）实现实时到历史分区的转换。冷热分区自动迁移的机制是：

• 数据积累到一定程度，内部自动调度 Build 任务，对实时数据建立快照，进行数据整理，构造出新的历史分区（Partition），并根据冷热策略将这些历史分区（Partition）分别写入热区和冷区。

• 在 Build 调度的同时，根据冷热策略的滑动窗口，自动把历史分区从热区迁移到冷区。下图中，定义的热分区个数为 3，在 11 月 4 日，热分区为 11-04、11-03 日、11-02 日共 3 个，在 11 月 5 日，写入了新的 11-05 的数据，根据滑动窗口，最新的热分区为 11-05、11-04、11-03 三个，因此在 Build 时，会触发热分区到冷分区的迁移，11-02 分区自动迁移到冷区。

冷数据查询加速

冷区降低了存储成本，但增加了数据访问的开销。虽然 AnalyticDB 已经做了分区裁剪、计算下推等优化，仍避免不了需要对历史分区做随机和吞吐扫描。为了加速对冷分区的查询性能，AnalyticDB 在存储节点开辟了一部分 SSD 空间作为 Cache。利用这块 SSD Cache，AnalyticDB 做了如下优化：

• 不同粒度的 SSD Cache Entry，确保可以同时兼顾索引的随机查找和吞吐型数据扫描。

• 元信息预热，每次 Build 结束，会自动生成冷分区的元信息，加速访问

• 无锁化的冷热访问队列，避免经常访问的数据被频繁换入换出。

冷热存储使用

1、全热表：适用于整张表全部数据都被频繁访问，并且对访问性能要求比较高。DDL 如下：

create table t1( id int, dt datetime) distribute by hash(id) partition by value(date_format('%Y%m',dt) lifecycle 12 storage_policy = 'HOT';

2、全冷表：适用于整张表全部数据都不频繁访问，并且对性能访问要求不高。DDL 如下：

create table t2( id int, dt datetime) distribute by hash(id) partition by value(date_format('%Y%m',dt) lifecycle 12 storage_policy = 'COLD';

3、冷热混合表：适用于数据冷热有明显时间窗口，比如，最近一个月数据是频繁访问且对性能有较高要求，而之前的数据是冷数据，只是偶尔访问。针对这种场景，DDL 如下：

create table t3( id int, dt datetime) distribute by hash(id) partition by value(date_format('%Y%m',dt) lifecycle 12 storage_policy = 'MIXED' hot_partition_count=1;

整张表按照月做二级分区，总共保存 12 个月，最近一个月的数据保存在 SSD 上，一个月以前的数据保存在 HDD 上。通过这样设置，性能和成本达到良好的平衡。

*在离线一体化

*

AnalyticDB 使用一套引擎，同时支持了面向低延迟的在线分析，和面向高吞吐的复杂 ETL。

10.png

混合计算负载

在存储计算分离的架构下，AnalyticDB 的计算能力也得到了极大的释放，可以支持非常丰富和强大的混合计算负载能力，在经典的在线（online）/交互式（interactive）查询执行模式之外，也支持了离线/批处理(batch)查询执行模式，同时可以通过集成开源的计算引擎（比如 Spark）来支持迭代计算和机器学习等复杂计算能力。

在线分析（Online/Interactive）

在线查询基于 MPP 架构，中间结果和算子状态完全使用内存（all-in-memory），计算过程完全流水线化（pipelined），查询 RT 小，适用于低延迟、高并发的场景 ，比如 BI 报表、数据分析、在线决策等。

批处理（Batch）

批处理模式基于 DAG 执行模型，整个 DAG 可以切分为若干个 stage 进行，stage-by-stage 执行，中间结果和算子状态可以落盘，支持大吞吐量的数据计算能力，也可以在较少的计算资源场景下执行，具备更低的计算成本，适用于数据量大或者计算资源有限的场景，比如 ETL、数据仓库等。

复杂计算（Iterative/ML 等）

AnalyticDB 提供了开放和可扩展的计算架构，通过集成和兼容开源生态的计算引擎（目前为 Spark）为用户提供复杂计算能力。用户可以基于 Spark 的编程接口（DataFrame/SparkSQL/RDD/DStream）来编写更加复杂的计算逻辑，满足业务越来越智能化和实时化的数据应用场景，比如迭代计算，机器学习等。

资源组（池）多租户

AnalyticDB 新版弹性模式下，支持了资源组功能，即对计算资源进行弹性划分，不同资源组之间的计算资源在物理上完全隔离。通过 AnalyticDB 账号绑定到不同的资源组，SQL 查询根据绑定关系自动路由至对应的资源组执行命令，用户可以选择为不同的资源组设置不同的查询执行模式，从而满足用户实现实例内部多租户、混合负载的需求。

11.png

资源组相关命令

-- 创建资源组CREATE RESOURCE GROUP group_name    [QUERY_TYPE = {interactive, batch}] -- 指定资源组查询执行模式    [NODE_NUM = N] -- 资源组节点个数    -- 绑定资源组ALTER RESOURCE GROUP BATCH_RG ADD_USER=batch_user
-- 调整资源组大小ALTER RESOURCE GROUP BATCH_RG NODE_NUM=10
-- 删除资源组DROP RESOURCE GROUP BATCH_RG

资源组可以支持不同的查询执行模式：

1. interactive：采用 all-in-memory、pipelined 的方式执行，适用于延迟要求高的在线分析

2. batch：采用 Stage by stage 执行模型，中间结果、算子状态可以落盘，适用于高吞吐，延迟要求低的查询，具备更低的计算成本

分时弹性

一般情况下，业务具备非常明显的波峰波谷，低峰期资源往往处于闲置阶段。AnalyticDB 分时弹性功能可以让这类用户定制弹性计划（每天定时、每周定时），在业务高峰期来临之前自动进行扩容满足业务流量。定时的弹性计划即满足了业务流量高峰的需求，又降低了 AnalyticDB 使用成本。结合资源组功能，用户甚至可以让某个资源组在低峰期时 0 节点，成本极低。

12.png

智能优化

查询优化是影响数据仓库系统性能的关键因素，如何生成更优的执行计划、以何种方式分区、如何配置索引、何时更新统计信息等等问题经常对数据开发人员造成困扰。AnalyticDB 一直深耕于智能优化技术，通过实时监控运行的查询，动态调整执行计划和其依赖的统计信息，自动提高查询性能；内置智能算法，可以依据系统的实时运行状态，动态调整引擎参数以适应当前的查询负载。

智能调整

智能调整是一个连续的监控和分析过程，通过不断的分析当前工作负载的特征，来识别潜在的优化并加以调整，并根据调整后实际的性能收益，来决策是否回滚或进一步的分析。

13.png

**动态执行计划调优**

查询计划经常会由于统计信息、代价模型等原因导致性能回退。AnalyticDB 充分利用了运行中与运行后的执行信息，进行执行计划的事中和事后调整。并通过对历史的执行计划和对应的运行指标进行机器学习，调整执行计划的代价预估算法，使其更加贴合当前的数据特征和工作负载，随着不断的学习和调整，达到自动优化的目标，让用户觉得越用越好用。

14.png

动态管理物化视图

物化视图(Materialized view)是数仓领域核心特性之一，可以帮助用户加速分析，简化数据清洗流程(ETL: Extract, Load, Transform)，应用场景十分广泛。比如：大屏类业务加速，配合 BI 工具使用，或者是缓存一些公共中间结果集用以加速慢查询。AnalyticDB 从 3.0 版本开始逐步支持物化视图，可以高效的维护物化视图，并提供全自动的更新机制。

15.png

结语

AnalyticDB 定位为新一代的云原生数据仓库，在一个系统中实现在离线一体化，成功赋能双十一诸多业务，抗住极端业务负载，也进一步提升业务上数据价值挖掘的实时性。随着平台的业务演进和技术演进，AnalyticDB 也在不断构建企业级数仓的能力，近期 AnalyticDB 已释放新版弹性的核心能力，极致弹性和高性价比，真正让用户所购即所得。