引言：ETL + 实时数仓延时大，查询慢？MySQL 分析引擎帮你解决高频变更下的实时数据分析！
背景
在当今快速变化的市场与高速发展的业务环境中，实时数据分析已成为数据库及大数据领域的核心能力。若能先人一步从在线业务库中提取有效数据并指导运营，便可能抢占市场先机，推动业务成功。
为满足这一需求，许多企业通过ETL工具将在线数据库数据同步至数据仓库。然而，基于 ETL 工具的传统方案往往带来较高的数据延迟，难以满足实时性要求较高的业务场景。比如实时订单统计、在线报表系统等。
腾讯云数据库分析引擎基于 MySQL 主从复制机制，可实时将主库数据转换为列式存储，在显著提升查询效率的同时，可充分保障数据同步的实时性。
对比 Flinks+Doris
目前业界常采用 FlinkCDC + Doris 方案实现实时分析。本文通过模拟测试，对比分析引擎与 Doris 在高频数据变更场景下的同步延迟&查询表现。
测试环境
服务器：48C488GB 物理服务器 * 3 台
测试场景：循环执行以下操作—创建一张测试表，插入 1000 条数据、随机更新某条数据、删除 1000 条数据，并实时记录 Doris 与分析引擎的数据同步完成时间。
测试时长：9 小时
Doris 版本：3.0.5
Flink 版本：1.19.1
腾讯云数据库分析引擎： 3.2503.5.0
测试结果
根据测试结果，可得出以下结论：
● 腾讯云数据库分析引擎以从库形式直接实时同步数据，而 FlinkCDC 方案需额外维护同步链路，架构更复杂。
● 分析引擎平均延迟稳定保持在百毫秒级别，而 FlinkCDC 方案的同步延迟高达 9 秒以上。
● FlinkCDC 在同步 DDL 至 Doris 时支持有限，部分列变更场景需人工干预。比如修改列长度超出 Doris支持范围时。
同步能力对比分析
为何会有着如此显著的差异呢？主要是因为MySQL分析引擎在实现与传统 ETL+数仓的实现存在着显著的区别。
列式存储更新效率差异
线上业务中数据变更频繁，高并发场景下每秒 TPS 可达数万。然而，列存数据库在高并发更新和删除场景下的性能通常弱于行存数据库。以 Doris 为例，其主键模型表支持两种数据合并策略：
● 在 MoW 模式下，高并发更新会带来显著的写入合并开销。为降低该开销，同步层常进行数据攒批，从而导致同步延迟，这也是上述测试中 Doris 延迟较高的主要原因。
● 在 MoR 模式下，高并发写入更新易产生大量文件碎片，若合并不及时，会在查询时引发实时合并，严重影响查询性能。
那既然采用 LSM-tree的列式存储存在以上缺点。对于此，分析引擎是怎么实现的呢？
如图所示，“只读分析引擎”具备多模块存储架构。增量数据首先以行式格式写入内存中的 MemRowSet 和 MemDelta 结构中，后续按策略持久化至磁盘 BaseData，并按列存储、按主键排序。
● MemRowSet 使用 BTree 结构存储增量数据。写入新行时直接插入MemRowSet；若需更新或删除的数据仍在内存中，引擎会定位对应行并将更新记录于链表，随后在刷新时合并为列存，并生成 Undo 日志以支持 MVCC。
● 若待更新数据已持久化至磁盘，更新操作将被记入 MemDelta。MemDelta 达到一定规模后，会刷新为 Redo 文件并异步与 BaseData 合并。
由此可见，分析引擎实现实时同步的关键，在于将列存写入转换为行式写入，从而获得与传统行存数据库相当的写入效率，并通过异步合并机制避免性能损耗。
同步实现逻辑差异
在列存更新机制的对比中，分析引擎展现出比 Doris 等数仓更优的实时性。但它仍存在数据合并过程，可能在高并发时影响查询性能。为此，我们同样针对高频写入场景下的查询性能进行了测试。
测试方案
服务器：48C488GB 物理服务器 * 3 台
测试表：
CREATETABLE sbtest1 (
id INT NOT NULL AUTO_INCREMENT,
k INT NOT NULL,
c CHAR(120) NOT NULL,
pad CHAR(60) NOT NULL,
-- 10 个额外 int 字段
i1 INT DEFAULT 0,
i2 INT DEFAULT 0,
i3 INT DEFAULT 0,
i4 INT DEFAULT 0,
i5 INT DEFAULT 0,
i6 INT DEFAULT 0,
i7 INT DEFAULT 0,
i8 INT DEFAULT 0,
i9 INT DEFAULT 0,
i10 INT DEFAULT 0,
-- 10 个额外 string 字段
s1 VARCHAR(100) DEFAULT'',
s2 VARCHAR(100) DEFAULT'',
s3 VARCHAR(100) DEFAULT'',
s4 VARCHAR(100) DEFAULT'',
s5 VARCHAR(100) DEFAULT'',
s6 VARCHAR(100) DEFAULT'',
s7 VARCHAR(100) DEFAULT'',
s8 VARCHAR(100) DEFAULT'',
s9 VARCHAR(100) DEFAULT'',
s10 VARCHAR(100) DEFAULT'',
PRIMARY KEY (id),
KEY k_1 (k)
);
测试方法：sysbench工具内置的oltp_update_non_index脚本，1亿行数据，10表 100并发。
测试 SQL：SELECT SUM(i1) FROM test.sbtest1 WHERE id < 2000000;
如下图所示，横轴为写入 QPS，纵轴为查询时延。可以明显看到，分析引擎在高写入 QPS 下仍能将查询延迟保持在 10–100 ms 内，而 Doris 的查询延迟则随 QPS 增加而显著上升。
究其原因，传统 LSM-Tree 存储引擎在执行 Update 时通常采用 MoR 或 Delete-Insert 方式，易在高频更新场景下产生大量文件重叠，加重后台合并负担，导致性能下降。
分析引擎通过引入 Delta-Store 功能，对部分列更新时避免产生过多重叠文件，从而缓解上述问题。因此，传统 ETL + 数仓方案通常需引入数据攒批以规避高频写入对查询的影响，这也是 FlinkCDC 同步至 Doris 延迟较高的根本原因。
分析引擎凭借其存储架构优势，在高并发写入中仍能保持稳定的查询消耗，无需过多攒批，进一步保障数据同步的实时性。
此外，在同步实现层面，分析引擎也与传统 ETL 工具有显著区别：
● 分析引擎基于 MySQL 主从同步原理，实时解析主实例 Binlog 并消费应用到列存节点，无需频繁攒批。
● 引擎在内存中直接应用 Binlog，无需写入磁盘 Relay 日志，极大减少 IO 消耗，提升同步效率。
DDL 兼容能力差异
业务迭代常伴随表结构变更（DDL）。在 ETL + 数仓的方案中，DDL 操作往往带来同步延迟与运维负担。尽管多数数仓已增强 DDL 支持，仍存在诸多局限：
● 使用 FlinkCDC 同步 MySQL 数据时，通常需手动在 Doris 中执行 Schema Change。
● 实现自动同步需编写 DataStream API 程序或依赖 Light Schema Change 功能。
● Doris 对部分MySQL数据类型（如 TEXT, ENUM, TIMESTAMP, YEAR 等）支持有限，主库变更这些类型时需人工处理。
● 主键变更可能导致同步异常，需人工介入修复。
● 不支持列名、聚合类型、Nullable 属性、默认值及列注释的修改。如中文表名或同时增加列与删除列的 DDL。
以上仅为部分常见限制，实际应用中还存在更多影响同步的 DDL 场景。
相对的，腾讯云数据库分析引擎则全面兼容 MySQL，支持所有常用字段类型、隐式转换与 DDL 语法。兼容 PT变更、Gh-ost变更等多种无锁变更场景。作为MySQL的列式从库，其可与主节点完全保持一致，无需用户干预，显著降低运维成本。
结论
腾讯云数据库 MySQL/TDSQL-C MySQL 的“只读分析引擎”能够高效地将实时数据转换为列式存储，为分析与报表等场景提供支持。相比传统 ETL 同步方案，其同步效率显著提升，用户无需关注 ETL 链路的运维与搭建成本，可大幅简化架构、降低成本。该引擎为交互式业务慢查询治理与实时报表提供了一条高效、稳定的落地路径。
