微购相册 × TDSQL-C 分析引擎：更快更实时的数据分析体验

本文将通过微购相册数据库使用案例深入讲解如何通过腾讯云数据库 TDSQL-C 的只读分析引擎加速业务分析查询效率，获得更加实时的数据分析体验。

微购相册是一家线上分享类的移动电商平台，用户通过上传产品到相册，一键分享到各大平台，通过关系流进行快速传播，促进产品销售。迄今为止，已服务超过5000万客户，在 Appstore 中曾排名 Top 30。

面对如此大体量的用户规模，其核心业务系统"相册网盘系统”的稳定性与性能体验就显得尤为重要。同时也对后端数据库的能力要求更加严苛。所以在进行数据库选型的时候，客户提出了如下主要需求：

● 百亿级数据存储与高频写入

● 强实时查询计算要求

● 混合负载

在如此大的数据量情况下既要保证高 TPS 的数据并发写入更新，还需要满足业务的实时聚合查询的低时延需求。这对传统关系型数据库是一个极大的挑战。使用高规格的资源可以满足业务高 QPS 变更的需求，但在实时的数据聚合分析类查询时就会遇到性能瓶颈。

基于此，微购相册曾考虑是否将聚合分析的查询拆分到数仓中去实现。但经过测试后发现，传统数仓虽然可以满足业务的并发聚合查询性能。但在如此高频的数据变更场景下，传统列式存储的数仓延迟非常高，无法满足业务的最高 3s 数据延迟的需求。

针对以上挑战，我们采用了如下的业务架构设计：

只读分析引擎是云原生数据库 TDSQL-C 的列存从节点，其拥有着优秀的复杂查询性能，可以有效的提升业务的查询效率。并可以实时的将数据从行存转换为列存，在超高并发数据变更场景下也能确保数据的行列一致性。

通过只读分析引擎的方案，微购云盘的容量计算业务效率有了十倍提升，单任务由之前的 10min 缩短到 1min 内。

同时只读分析引擎优异的数据变更能力，在面对 100 亿数据基础上 35 W QPS 的部分列更新时，仍能保证数据实时加载为列存，整体数据无延时。

那么只读分析引擎如何满足业务需求？其能力有哪些独到之处？

在微购业务场景中，绝大部分慢查询都是组合谓词过滤后的聚合分析。典型 SQL 样例如下（为了脱敏，这里使用 TPC-H 数据查询来做代表）：

 select
sum(l_extendedprice * l_discount)as revenue
 from
	lineitem
 where
	l_shipdate >='1994-01-01'
   and l_shipdate < date_add('1994-01-01',interval'1'year)
   and l_discount between0.06-0.01and0.06+0.01
   and l_quantity <24;

这些 SQL 有几个典型的特征：

对于这种 SQL ，想要执行效率高，首先需要快速的从存储上读取到有效的数据行中的有效列，避免对全量数据进行扫描，否则需处理大量冗余数据，I/O 和计算开销都非常大。

其次是过滤完毕之后的数据仍然具备一定的数据规模，要能够快速的对这些数据进行聚合分析。

这两个问题对传统的行存关系数据库主要有几个核心的挑战

● 谓词组合的方式非常多，并且过滤后的数据量仍具一定规模，很难为所有的谓词组合提前建立好覆盖索引；

当然需要强调的是，TDSQL-C 的只读分析引擎在微购业务中能够保障“所有的聚合分析在 200 QPS 左右还能有 3 秒以下响应”，这得益于多种技术能力的综合运用。

这些能力包括异步化处理，它能够有效地提高系统的并发性能；灵活调度机制，确保资源的高效分配和使用；以及向量化执行中SIMD技术，通过并行处理来加速数据计算。

超高并发下的更新一致性

这样所有的变更还是在内存中，并且依靠 WAL 进行持久化。

同时数据的删除和更新都会直接应用到每个 MemTable 对应的 MemTable 中，数据的局部性也会更好，增量数据和基线数据的合并基本都在一个 SSTable 中进行，写放大也会明显的下降。

通过这种原地更新和日志更新的结合，只读分析引擎在高频变更，尤其是高频更新的场景下的性能大幅提升，对于微购业务数据行列数据实时同步起到重要作用。