亿级数据秒级响应：PolarDB MySQL HTAP实时分析方案设计与压测报告

HTAP 的必然性与 PolarDB MySQL 的破局之道

在数据驱动的时代，业务对数据的实时性要求达到了前所未有的高度。传统架构中，OLTP（在线事务处理） 与 OLAP（在线分析处理） 分离的模式面临严峻挑战：

• 数据延迟高： ETL 过程导致分析数据滞后，无法反映最新业务状态。
• 架构复杂、成本高： 维护两套系统（如 MySQL + ClickHouse/Greenplum）带来开发、运维、数据同步的巨大开销。
• 资源利用率低： TP 和 AP 负载高峰时段不同，资源难以弹性共享。

HTAP（混合事务/分析处理） 应运而生，旨在使用同一份数据、同一个数据库引擎，同时高效处理高并发的事务请求和复杂的分析查询。阿里云 PolarDB MySQL 版凭借其云原生、共享存储、计算存储分离的先进架构，成为实现 HTAP 的理想平台。其核心优势在于：

• 行列混存： 在共享存储基础上，提供行存（主处理 TP）和列存（主处理 AP）两种格式，物理隔离 TP/AP 负载。
• 智能路由： 优化器自动识别查询类型，将分析查询智能路由到列存节点执行，避免影响 TP 事务性能。
• 资源隔离： TP 节点（读写节点）与 AP 节点（只读列存节点）资源独立，互不干扰。
• 实时一致： 基于 Redo Log 的秒级数据同步，确保 AP 查询的数据强一致性（通常秒级延迟）。
• 弹性扩展： 计算节点（TP/AP）可按需独立扩缩容，存储容量自动在线扩展。

本文将从实战出发，深入剖析如何基于 PolarDB MySQL 设计和实现一个支撑亿级数据秒级响应的 HTAP 方案，并通过详尽的压力测试验证其性能。

2 PolarDB MySQL HTAP 核心架构解析

(1) 共享存储（PolarStore）

• 基石： 所有计算节点（读写节点、只读节点、列存节点）访问同一份存储在 PolarStore 上的数据。
• 优势： 彻底解耦计算与存储。存储容量独立扩展（PB 级），计算节点增减不影响数据；存储层多副本保障高可用；计算节点无状态，故障恢复快。
• 数据格式：
  • 行存 (Row Store)： 默认格式，面向高并发点查、小范围扫描、事务处理优化。数据按行存储，修改高效。
  • 列存 (Column Store)： 面向海量数据分析优化。数据按列压缩存储，大幅减少 I/O 量；支持向量化执行引擎，提升 CPU 缓存利用率和 SIMD 指令效率。

(2) 计算节点角色

• 读写节点 (Primary Node)：
  • 唯一可写节点，处理所有 DML 操作和事务型读请求。
  • 负责将事务产生的 Redo Log 同步到其他节点。
  • 通常配置为行存访问模式。
• 只读节点 (Read-Only Node)：
  • 可配置为行存访问模式。
  • 接收并应用读写节点的 Redo Log，提供行存数据的只读副本，分担 TP 读负载。
  • 支持会话一致性读。
• 列存节点 (Columnar Index Node)：
  • HTAP 核心组件。
  • 可配置为列存访问模式。
  • 接收并应用读写节点的 Redo Log，但只将数据按列存格式组织和存储。
  • 专门用于执行复杂的分析型查询 (AP Load)。
  • 通常是只读的（某些场景下可支持特定写操作，非主流）。

(3) 数据同步与列存构建

• Redo Log 同步： 读写节点的事务操作生成 Redo Log，近乎实时地（毫秒级）同步到所有只读节点和列存节点。
• 列存异步构建：
  1. 列存节点持续接收并解析 Redo Log。
  2. 解析出的数据变更（INSERT/UPDATE/DELETE）被放入一个内存队列 (MemBuffer)。
  3. 后台线程定期或在特定条件下（如 MemBuffer 满、时间间隔到）将内存队列中的变更批量刷盘 (Flush)，转换为高效的列存格式（如 Delta 文件）。
  4. 多个 Delta 文件会在后台异步合并 (Merge) 成更大的、压缩率更高的 Segment 文件，优化查询性能。
• 一致性保证： 列存节点的数据是异步构建的，通常有秒级延迟（RPO）。查询时，列存节点会结合已持久化的列存数据和内存队列中的最新变更，提供会话级别或时间点一致性的读视图。

(4) 智能查询路由

• 当客户端发起一个查询时，首先到达读写节点（或代理层）。
• 优化器会分析查询：
  • 如果查询是简单的点查、小范围扫描或明显是事务型查询（涉及写、使用 FOR UPDATE 等），则路由到行存节点（读写节点或行存只读节点） 执行。
  • 如果查询是复杂的聚合（SUM/COUNT/AVG）、大表全表扫描、多表 JOIN 且适合列存执行，则优化器会考虑自动或手动（通过 Hint）路由到列存节点执行，利用列存的 I/O 和计算优势。
• 路由决策可基于规则、代价模型或用户指定。

3 实战：亿级数据 HTAP 方案设计与实施

场景描述： 电商订单分析系统。核心表 orders 包含数亿条记录（持续增长），需要支持：

• TP： 高并发的订单创建、状态更新、用户订单查询（按订单ID/用户ID）。
• AP： 实时分析大盘（分钟级）、商家销售报表（按天/月/年聚合）、商品热度分析、用户行为漏斗分析等复杂查询，要求秒级响应。

(1) PolarDB MySQL 集群选型与配置

• 集群规格：
  • 读写节点 (Primary)： PolarDB MySQL 通用规格 8 核 32GB * 1
  • 列存节点 (AP)： PolarDB MySQL 列存规格 16 核 64GB * 2 (部署于不同可用区)
  • 存储 (PolarStore)： 1TB (SSD PL3) - 按需自动扩展
• 版本： PolarDB MySQL 8.0.2 及以上（稳定支持列存索引）。
• 网络： 所有节点部署在同一 VPC 内，确保低延迟网络通信。

(2) 核心表设计与列存索引创建

• 行存表结构 (DDL)：

  CREATE TABLE `orders` (
  `order_id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '订单ID',
  `user_id` BIGINT UNSIGNED NOT NULL COMMENT '用户ID',
  `product_id` BIGINT UNSIGNED NOT NULL COMMENT '商品ID',
  `merchant_id` BIGINT UNSIGNED NOT NULL COMMENT '商家ID',
  `order_amount` DECIMAL(10, 2) NOT NULL COMMENT '订单金额',
  `order_status` TINYINT NOT NULL COMMENT '订单状态(1:待支付,2:已支付,3:已发货,4:已完成,5:已取消)',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`order_id`), -- 主键索引 (行存)
  KEY `idx_user_id` (`user_id`), -- 二级索引 (行存)
  KEY `idx_merchant_create` (`merchant_id`, `create_time`), -- 二级索引 (行存)
  KEY `idx_product_id` (`product_id`) -- 二级索引 (行存)
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
  PARTITION BY RANGE COLUMNS (`create_time`) (
  PARTITION p202301 VALUES LESS THAN ('2023-02-01'),
  PARTITION p202302 VALUES LESS THAN ('2023-03-01'),
  ...
  PARTITION p202405 VALUES LESS THAN ('2024-06-01')
  );
  

• 创建列存索引 (关键步骤)：

  -- 为目标表创建列存索引（CCI）
  ALTER TABLE `orders`
  ADD CLUSTERED COLUMNAR INDEX `orders_cci`
  COMMENT '订单表列存主索引'
  PARTITION BY RANGE COLUMNS (`create_time`) (
  PARTITION p202301 VALUES LESS THAN ('2023-02-01'),
  PARTITION p202302 VALUES LESS THAN ('2023-03-01'),
  ...
  PARTITION p202405 VALUES LESS THAN ('2024-06-01')
  );
  

• 列存索引特性与设计考量：

  • CLUSTERED COLUMNAR INDEX (CCI) 是物理存储结构，不是逻辑索引。数据按列压缩存储。
  • 创建 CCI 是在线、异步操作，不影响原行存表的读写。后台线程负责构建初始列存数据。
  • 分区对齐： CCI 的分区策略（PARTITION BY ...）必须与行存表完全一致。这是保证分区修剪（Partition Pruning）在 TP 和 AP 端都能正确工作的关键。
  • 选择合适的分区键： create_time 是典型的时间维度，常用于 AP 查询的时间范围过滤。按时间分区能有效利用分区修剪，减少 AP 查询扫描的数据量。
  • 列存索引包含所有列： CCI 默认包含表的所有列。无需像传统列存数据库那样显式选择 Projection。
  • DDL 同步： 对行存表执行 ALTER TABLE（如加列、改列类型）时，PolarDB MySQL 会自动同步到关联的 CCI，保持元数据一致。

(3) 数据初始化与实时同步验证

• 历史数据导入： 使用 mysqldump (逻辑导出) 或 Percona XtraBackup (物理备份) 结合 LOAD DATA 或 ALTER TABLE ... IMPORT TABLESPACE 将亿级历史订单数据导入行存表 orders。
• 列存索引构建监控：
  ```sql
  -- 查看 CCI 构建进度
  SELECT FROM INFORMATION_SCHEMA.INNODB_CCI_INDEXES
  WHERE TABLE_NAME = 'orders';
  SELECT FROM INFORMATION_SCHEMA.INNODB_CCI_INDEX_BUILD_PROGRESS
  WHERE TABLE_NAME = 'orders';

-- 查看 CCI 状态
SHOW CREATE TABLE orders; -- 输出中会包含 CCI 定义

*   **实时数据写入验证：**
    1.  在读写节点持续写入新订单。
    2.  在列存节点执行查询，检查最新写入的数据是否可见（注意秒级延迟）：

```sql
-- 在列存节点执行
SELECT MAX(order_id), MAX(create_time) FROM orders FORCE INDEX(orders_cci);
-- 对比读写节点上的最大值，观察延迟

(4) AP 查询优化技巧

• 强制使用列存索引： 虽然优化器通常能自动选择，但在复杂场景或需要明确指定时，可使用 FORCE INDEX(orders_cci) Hint。
• 利用分区修剪： 确保 AP 查询条件包含分区键 create_time 的范围。
• 聚合下推： 列存引擎擅长在存储层执行 SUM, COUNT, AVG, MIN, MAX 等聚合操作，减少数据传输量。
• 谓词下推： 将 WHERE 条件中的过滤操作尽可能下推到存储层执行，减少需解压和处理的行数。
• 避免列存不友好的操作： 如 SELECT * (尽量指定需要的列)，频繁更新的列（列存更新成本较高），大量点查（行存更优）。
• 列存统计信息： 确保 ANALYZE TABLE 定期执行，更新列存索引的统计信息，帮助优化器生成更优的 AP 执行计划。

示例 AP 查询 1：实时大盘 - 今日成交额、订单数

SELECT
    DATE(create_time) AS order_date,
    COUNT(order_id) AS total_orders,
    SUM(order_amount) AS total_amount
FROM orders FORCE INDEX(orders_cci) -- 强制使用CCI
WHERE
    create_time >= CURDATE() -- 利用分区修剪，只扫描今天的分区
    AND order_status IN (2, 3, 4) -- 已支付、已发货、已完成
GROUP BY order_date;

示例 AP 查询 2：商家月度销售 Top10

SELECT
    merchant_id,
    COUNT(order_id) AS order_count,
    SUM(order_amount) AS total_amount
FROM orders FORCE INDEX(orders_cci)
WHERE
    create_time BETWEEN '2024-05-01 00:00:00' AND '2024-05-31 23:59:59' -- 分区修剪
    AND order_status = 4 -- 已完成
GROUP BY merchant_id
ORDER BY total_amount DESC
LIMIT 10;

4 压力测试：亿级数据下的性能验证

测试目标： 量化评估 PolarDB MySQL HTAP 方案在亿级 orders 表（约 3 亿行，300GB+ 行存空间，80GB+ 列存空间）下，TP 负载与 AP 负载混合时的性能表现，验证“秒级响应”目标。

(1) 测试环境

• 数据库集群： 同第 3 节配置（读写节点 8C32G 1， 列存节点 16C64G 2）。
• 压测客户端：
  • TP 负载生成： Sysbench (v1.0.20) 部署在 2 台 8C16G ECS 上。
  • AP 负载生成： 自定义 Python 脚本模拟复杂分析查询，部署在 1 台 16C32G ECS 上。
• 网络： 所有 ECS 与 PolarDB 集群同 Region 同 VPC。

(2) 测试场景设计

(3) 关键性能指标 (KPI)

• TP 指标：
  • TPS (Transactions Per Second)： Sysbench OLTP 测试报告的事务数/秒。
  • QPS (Queries Per Second)： Sysbench OLTP 测试报告的查询数/秒。
  • Latency (ms)： TP 操作的平均、P95、P99 延迟。
• AP 指标：
  • Query Latency (ms)： 单个 AP 查询的执行时间 (平均、P95、P99)。
  • AP QPS： 所有 AP 查询成功的请求数/秒 (衡量 AP 并发吞吐能力)。
• 资源指标： (通过 PolarDB 控制台/PolarDB 性能洞察/Prometheus 监控)
  • CPU Utilization (读写节点、列存节点)
  • Memory Utilization (读写节点、列存节点)
  • IOPS (存储层读/写)
  • Network Traffic (内网入/出流量)

(4) 压测结果与分析

• 场景 S1：纯 TP 基准性能

*   **结论：** PolarDB 读写节点处理高并发 TP 负载能力优秀，在 256 并发下 P99 延迟仍控制在 50ms 以内，满足核心交易系统要求。

• 场景 S2：纯 AP 基准性能

• 结论：

  *   针对**亿级数据**，利用分区修剪将数据量**缩减到百万/千万级别**的分析查询，平均响应时间在 **300ms - 1.5s** 之间，达到“秒级响应”目标。扫描数据量更大的复杂 JOIN 查询在 5s 左右。
  *   2 个 16C64G 列存节点可提供约 **15 QPS** 的稳定 AP 并发吞吐能力。提升 AP 节点规格或数量可线性扩展 AP 吞吐。
  

• 场景 S3 & S4：TP + AP 混合负载性能

关键结论：

    *   **资源隔离效果显著：** 在持续高 TP 压力下（128/256 并发），引入 AP 负载（10/20 并发）**对 TP 事务性能 (TPS/QPS) 的影响极小 (< 0.5%)，TP 延迟的增加也非常有限 (< 5%)**。这充分证明了 PolarDB HTAP 架构中 TP 节点与 AP 节点（列存节点）资源隔离的有效性。
    *   **AP 性能稳定：** AP 查询的平均延迟在混合负载下仅有轻微上升（~5%），AP QPS 接近纯 AP 场景水平。列存节点的 CPU 利用率显著升高，成为 AP 性能的主要瓶颈，也说明资源主要被 AP 负载消耗。
    *   **无资源争抢：** TP 负载（读写节点）的 CPU、IO 监控显示，在混合负载下与纯 TP 负载时几乎无差异，进一步证实资源隔离。

• 场景 S5：突发 AP 流量应对
  • 现象： 在 TP 128 并发稳定运行期间，突然注入 50 个并发的相同 AP 查询 (Q1: 单日大盘聚合)。
  • 结果：
    • TP 性能： TPS 瞬时下降约 2% (21500 -> 21080)，持续约 15 秒后恢复到基准水平。TP P99 延迟瞬时升高至 25ms (+35%)，随后回落。
    • AP 性能： 前 5 秒内完成的 AP 查询平均延迟升至 850ms，后续完成的查询延迟逐渐回落到 350ms 左右。整体 AP QPS 在突发期间约为 12。
    • 资源： 列存节点 CPU 瞬间飙升至 95%+，持续约 10 秒后因部分查询完成而开始回落。
  • 分析： 突发高 AP 并发主要冲击列存节点资源。由于列存节点资源充足（CPU 未持续 100%），系统能快速消化突发请求。对 TP 的影响非常短暂且轻微。可通过列存节点自动弹性扩容（PolarDB 支持） 或 AP 查询队列管理 进一步优化突发体验。

(5) 核心结论汇总表

5 关键优化点与最佳实践总结

基于实战和压测，提炼以下优化关键点：

(1) 合理规划分区

• 必要性： 分区修剪是亿级数据 AP 查询秒级响应的首要前提！必须为行存表和 CCI 定义相同的、高效的分区策略。
• 分区键选择： 优先选择 AP 查询中最常用的过滤条件列（如时间 create_time、租户 tenant_id）。确保查询条件能有效触发分区修剪。
• 分区粒度： 根据数据量和查询模式确定。例如，按天分区可能产生数千分区，管理开销增大；按月分区可能扫描数据量过大。通常按天/周/月分区是常见选择。确保单个分区内的数据量在可高效扫描的范围内（如百万~千万级）。
• 定期管理： 实现分区自动增删（如每天添加新分区，删除过期分区）。

(2) 精细化列存索引 (CCI) 管理

• 创建时机： 对于大表，在业务低峰期创建 CCI。监控构建进度 (INFORMATION_SCHEMA.INNODB_CCI_INDEX_BUILD_PROGRESS)。
• 维护： PolarDB 自动维护 CCI 的数据同步和后台合并。关注 INFORMATION_SCHEMA.INNODB_CCI_INDEXES 状态 (STATUS 应为 AVAILABLE)。
• DDL 兼容性： 大部分 DDL 能自动同步到 CCI。但涉及分区键修改或存储格式变更的复杂 DDL 需谨慎测试。建议先在测试环境验证。

(3) 查询优化与 Hint 使用

• 强制路由： 对明确要走列存的 AP 查询，使用 FORCE INDEX(cci_index_name) 确保路由正确，避免优化器误判。
• 投影优化： 在 AP 查询中严格避免 SELECT *。只选择分析需要的列，减少列存引擎解压和传输的数据量。
• 谓词优化： 将过滤条件 (WHERE) 尽量写在分区键和常用过滤列上，利用分区修剪和列存谓词下推。
• 聚合下推： 确保聚合函数 (SUM/COUNT/AVG/MIN/MAX) 能被列存引擎识别并下推执行。

(4) 资源规划与监控

• AP 节点规格： AP 查询延迟和吞吐主要受列存节点 CPU 和内存限制。根据压测结果（如 S2 中 AP QPS 与 CPU 利用率关系）规划资源。纵向扩展 (Scale Up) 提升单节点性能，横向扩展 (Scale Out) 增加列存节点数量提升并发能力。
• 监控重点：
  • 列存节点： CPU Utilization, Memory Utilization, PolarDB_CCI_Scan_Rows (扫描行数), PolarDB_CCI_Query_Duration (查询耗时)。
  • 读写节点： 常规 TP 指标 (QPS/TPS/Latency), CPU, IO。在混合负载下特别关注是否因 AP 产生异常波动（理论上应极小）。
  • 存储层 (PolarStore)： IOPS, Latency, Storage Space。列存扫描会消耗读 IOPS。
• 利用 PolarDB 性能洞察 (Performance Insights)： 快速定位慢查询（区分 TP/AP），分析资源消耗 Top SQL。

(5) 一致性级别理解

• 默认： 列存节点上的查询通常是会话一致性，即在一个会话内连续查询能保证单调一致性，但可能读到比读写节点稍旧的数据（秒级延迟）。
• 强一致性读： 若业务严格要求 AP 查询读到最新已提交数据，可在查询中使用 SET innodb_cci_read_consistency = STRONG。但这会导致查询回退到读写节点的行存执行，牺牲 AP 性能！慎用，仅用于关键一致性校验场景。

PolarDB MySQL HTAP 方案成功解决了传统架构在实时数据分析上的痛点，实现了“一份数据，两种负载，秒级分析”。其价值在于：

1. 简化架构，降低成本： 告别复杂的 ETL 和异构系统维护，降低开发运维复杂度和总体拥有成本 (TCO)。
2. 加速决策，提升体验： 分钟级甚至秒级获取业务洞察，赋能实时运营、风控、推荐等场景，提升用户体验和商业效率。
3. 资源解耦，弹性高效： TP/AP 资源独立扩展，按需付费，提高资源利用率。

适用场景：

• 需要实时分析交易/日志/事件数据的场景（电商、金融、IoT、游戏、监控）。
• 传统 MySQL OLTP 系统需要增强实时分析能力，避免数据同步延迟和复杂度。
• 报表、BI 系统需要更快的刷新速度（从小时/分钟级提升到秒级）。

• 列存更新代价： 虽然 Redo 同步高效，但对高频更新的列，列存后台合并可能成为瓶颈。未来版本可能优化列存的更新效率。
• 更复杂的 AP 支持： 对比专用 OLAP 引擎（如 ClickHouse, StarRocks），在极其复杂的多表 JOIN、窗口函数、超高并发 AP 场景下，性能和功能仍有提升空间。PolarDB 正在持续增强其列存执行引擎。
• HTAP 生态整合： 与主流 BI 工具 (Tableau, QuickBI)、数据科学平台 (Python, Spark) 的深度整合体验可以进一步加强。
• Serverless HTAP： 结合 PolarDB Serverless 的能力，实现 TP 和 AP 资源的完全按需、秒级弹性，将是未来重要方向。

结论：

通过严谨的方案设计（行列混存、智能路由、分区对齐）、细致的优化（查询优化、资源规划）和充分的压测验证，PolarDB MySQL 的 HTAP 能力已能成熟支撑亿级数据量下的核心交易系统实时分析需求。它在保持 MySQL 生态兼容性和强大 OLTP 能力的同时，显著提升了实时分析性能，有效降低了架构复杂度，是企业构建下一代实时数据平台的重要选择。随着阿里云持续投入研发，PolarDB HTAP 的能力边界和应用场景必将进一步拓展。