5月18日，腾讯云首款分布式分析型数据库TDSQL-A正式发布公有云版本。
TDSQL-A作为领先的分析型数据库，是腾讯首款分布式分析型数据库，采用全并行无共享架构，具有自研列式存储引擎，支持行列混合存储，适应于海量OLAP关联分析查询场景。它能够支持2000台物理服务器以上的集群规模，存储容量能达到单数据库实例百P级。
TDSQL-A具备强大的海量数据实时分析能力，并全面兼容PostgreSQL语法、高度兼容Oracle语法，同时具备高安全、高可用、超大规模集群支持和完整事务能力等产品特性，可为企业用户需求提供高效、低成本的数据分析解决方案。
其中，TDSQL-A完整的分布式事务处理能力，可实时保障系统多平面数据全局读一致性、可靠性；支持多级容灾以及多维度资源隔离，还提供强大的多级安全体系，提供完善的企业级管理能力，为用户提供容灾、备份、恢复、监控、安全、审计等全套解决方案。同时TDSQL-A提供弹性扩缩容能力，适用于 GB-PB 级的海量 OLAP 场景，是市场领先的企业级分析型数据库引擎产品。
TDSQL-A有这么多吸引人的特性，这些特性具体是如何保证完备、优雅地解决以上这些需求问题的呢？以下是腾讯云数据库技术总监李跃森老师对TDSQL-A产品核心架构的分享。
一、TDSQL-A场景定位

TDSQL-A是腾讯基于PostgreSQL自主研发的分布式在线关系型数据仓库，业务场景针对于在线数据分析。
TDSQL-A是植根于腾讯内部业务发展起来的分布式数据库，最早的时候我们是用TDSQL-PG来做一些大数据平台小规模的数据分析。随着业务的发展，我们发现单机的数据库逐渐不能满足业务的需要，我们就萌生了要开发分布式数据库的想法。最早我们服务了微信支付，而随着业务的发展，我们逐步自主研发了列存储，来增进TDSQL 分析型能力。
同时，随着腾讯云业务的拓展，TDSQL-A也逐步走向服务外部客户的过程中，积累了大量优秀案例实践。
二、TDSQL-A核心技术架构

TDSQL-A整体架构和PostgreSQL的整体架构相比，是既紧紧地跟随生态，同时有深度定制改造。

如上图，曲线部分是TDSQL-A数据库的内核，分为几个部分：
第一是上层的GTM事务管理器，它主要是负责全局事务的管理，协调机群的事务，同时管理集群的全体对象。右上角是协调节点，它是业务访问入口。协调节点模块是水平对等的，也就是说业务连接到任何一个协调节点上，都能够获得到一致的数据库视图。
第二是下方的数据节点。数据节点也是实际存储数据的节点，每个数据节点只会存储数据的分片，而数据节点之间加在一起会形成一个完整的数据视图。
而数据节点和协调节点之间是集群的数据交互总线。集群数据交互总线在TDSQL-PG和TDSQL-A之间是存在差异的——两者在系统内名字上来讲都叫集群交互总线，但是在这两个不同的产品形态下，其实现逻辑完全不同——在TDSQL-A里面通过基于物理网卡的数据交互汇集器，并通过完整的网络连接的复用来完成这个工作。集群交互总线的目的是把集群内部节点连接在一起，从而完成整个查询交互。
最后，左侧描述的是数据库内核的运维管控系统。数据库在运行的时候需要一个运维管控系统来支撑运营，包括运维管理、实时监控、实时告警、安全审计和数据治理等等。
2.1 TDSQL-A自研行列混合存储能力
下面介绍TDSQL-A全自研的行列混合的存储能力。

数据库的存储有两种方式，一个是按行存储、一个是按列存储：
按行存储表：每行数据存储所有列、一次磁盘IO可以访问一行中所有列、适合OLTP场景。
按列存储表：每列单独存储，多个列逻辑组成一行；一次磁盘IO只包含一列数据；方便做数据压缩；适合OLAP场景。
TDSQL-A支持按列存储和按行存储两种方式来建表，同时在列表和行表之间，用户不用感知到下层的表是通过行表还是列表来建，行表和列表之间可以进行无缝的互操作——包括相互关联、相互交换数据，完全不需要感知到底下的存储逻辑。
除了操作的便利性之外，行表和列表之间混合查询还能保持完整的事务一致性，也就是说在查询运行的同时，整个事务（ACID）的能力也得到完整的保证。
2.2 TDSQL-A列存储压缩能力
列存模块，我们介绍列存储压缩能力。
TDSQL-A的列存储压缩分为两种：
第一种是轻量式压缩。轻量式压缩方式首先感知到数据的具体内容，从而针对数据的特点来选用不同的压缩办法提高压缩比，降低业务的成本，当前我们支持RLE的压缩方式。
第二种是透明压缩。这种压缩方式是直接使用包括zstd和gzip直接进行压缩，这种压缩对数据的存储内容没有明确的要求，可以对任何的信息进行压缩。通过数据压缩，可以把数据的体积大幅度减少，一方面减少用户的使用成本，另一方面可以在大量查询分析的时候减少IO访问量，提升我们的查询效率。
2.3 TDSQL-A执行引擎：延迟物化原理

在存储层之上，是数据库的执行引擎。执行引擎模块中，大规模的查询分析场景下的数据交换以及IO、网络开销是非常大的关注点，因为其对系统性能以及整体扩展性都有很大影响。
TDSQL-A在调研了业界的技术趋势和技术的发展方向之后，在引擎里引入了延迟物化。相对于延迟物化，就是一般常见的提前物化。提前物化指的就是查询执行器再去执行扫描的时候——这里简单理解这些查询里面包括Scan、Join、Project等。
这里举一个例子，一个场景中有两张表——tbl_a和tbl_b，两张表上都有f1和f2两列，分布列都是f1。按照tbl_a的f1列与tbl_b的非分布列f2来进行关联——此时左边是提前物化的计算方法， Project需要返回tbl_b的f1，进行Join关联的时候需要tbl_b的f2，所以在对tbl_b进行Scan的时候，就会把tbl_b的f1和f2都物化出来。所谓的物化，是把两个列在文件里面读出来，在内存里形成一个虚拟的记录元组，然后往上传输。实际上可以看一下，在最上层往里面投数据的时候，只投影了tbl_b的f1。在这个过程中，如果中间Join关联的过滤比例很高，比如说只有1%是满足要求的，这里面有很多tbl_b的f1列数据是没有必要传输进来的。

可见，提前物化造成对网络带宽的浪费：
JOIN的选择率等于0.01
TBL_B中有20亿条记录
JOIN有20亿 * (1 – 0.01) * sizeof(TBL_B .f1) = 7.4GB的无效数据传输。
这个现象是在OLAP场景下常见的开销，因为OLAP做各种复杂查询时很多是宽表，而且查询时大多数时候只会访问宽表里面极少数列，这个时候如果遇到了比较典型的选择率很低、投影率很少的情况，开销就变得不能忽视。
TDSQL-A延迟物化技术就是针对刚才的问题提出的优化方案。TDSQL-A延迟物化查询计划会在下层进行Scan的时候，针对Join中不需要的目标列只往上层传递物理元组的位置信息到上层节点。只有等上层节点完成Join关联后，才会去把满足条件的记录的位置信息记录下来，在投影阶段再到下层拉取需要的数据信息，进而透到外面。

通过测试证明，这种方式可以大幅度地节省CPU的计算开销和网络IO、磁盘IO的开销。

延迟物化对性能提升的效果：当测试的场景是20节点、20台节点、1TB的数据，选择率是10%，投影率是60%，两表进行Join。可以明显地发现，时间消耗相比是提前物化的五分之一，网络带宽的占用只有提前物化的一半。假设把表Join个数从两个变成三个，消耗的时间则是其30%，网络占用比接近40%——也就是说节省了60%的网络占用。
因此，测试结果证明这对于IO和网络开销有非常明显的节省。而通过这两个开销的节省，可以进一步影响到性能的提升。

此外我们专门做了一个复杂Join的测试：选择率是1%、投影率是100%；两表的Join，横坐标是100GB到1TB。从上面两表的Join可以看出，表越大到1TB的时候，相比开源的GP有5.2倍性能的提升；假设把两张表变成三张表，则有18倍性能提升。可见，随着查询变得复杂、表变得越大，在延迟物化的场景下对性能的提升越明显。
2.4TDSQL-A全新设计的异步执行器解耦控制和数据交互
最初我们目标是让TDSQL—A支持数千台服务器集群规模。支撑数千台服务器的规模，存在一些必须要去跨越的障碍，其中一个障碍就是网络连接数过多。

为了解决上连接数过高的问题，TDSQL-A全新设计了异步执行器。TDSQL-A的执行器是全新自研设计的执行器，主要有两个特点：第一个是异步执行；第二个是控制逻辑和数据传输逻辑分离。

具体来说，系统在查询优化阶段的时候会生成统一的执行计划、统一执行需要的资源，这是TDSQL-A的控制逻辑。同时系统把整个网络通信进行了抽象，抽象成下面蓝色的Router——Router主要是负责机群内部的数据查收。不同的进程之间，比如两层Join或者三层Join，不同层级的进程之间是完全异步执行的，并通过推送数据的方式来完成数据交互。假设有N个节点，有M层join，则一共有M×N个进程。

在对执行器进行异步化和控制数据分层的基础上，TDSQL-A又对数据交互逻辑进行完整实现，这就是数据交互总线（Forward Node）。它主要是负责节点间的数据交互。可以认为它是我们集群的逻辑网卡。

FN通过共享内存和CN、DN进行数据交互——当然也存在本地的逻辑交互，假设数据需要从本地内部进行交互，可以不走网络而直接在内存里面完成交互，进一步提升性能。
启用了FN之后，假设有N个节点，M×Join不管有多复杂，连接个数都是只有（N-1）×S——这个“S”是一个正整数，这意味着每台服务器和其他服务器建N个连接，一般来说会乘2，这样就可以把整个集群内部的网络连接完全抽象和简化。服务器与服务器之间建立的连接个数变成近似于和集群规模相关的一个很小的数值：假设我们有2000台服务器，这个值也只会在4000左右。
现在很多业务场景下业务都会要求读多写少——非常复杂的查询的读多写少，比如最多有五六张20亿条的表进行关联，同时有数十个、甚至更多并发发生。这种情况将对数据库的计算资源带来极大的挑战。一般而言，在不具备这个技术之前，一般做法是每当计算资源不足，就多建一个新的数据库集群来保存完整的数据，在新建副本上通过扩容的方式实现冗余数据的重新查询。这种方式存在很大的问题——建一个新的数据库，数据一致性是非常大的挑战。扩容的时候规模变得很大，同时每新建一个数据库集群，就需要容灾、备份等所有的资源都同时扩展，这导致的结果是数据库整体的开销更大、成本更高。
针对这个问题，TDSQL-A设计推出了多平面方案。
2.5 TDSQL-A的多平面能力提供一致的读扩展性

所谓的多平面：一个平面对应一个完整的数据副本，完整的数据副本可以提供完整的一致性读扩展服务——读扩展可以是单条的查询，也可以是复杂的OLAP的关联查询，通过这种方式TDSQL-A可以提供成本低廉的读扩展服务。
在TDSQL-A整个架构体系当中，多平面技术可在数据库集群内部保证各个平面之间数据一致性，同时也能保证各个平面在读取时数据事务的一致性。
2.6 TDSQL-A如何做到高性能计算—全并行能力

对数据库来说最关键的一点的无疑是高性能计算。以下介绍TDSQL-A在高速并行计算方面的工作。
在海量数据的实时分析场景下，我们一定要充分去发挥、充分压榨资源才能达到最好的效果。这个方式，在TDSQL-A里面叫全并行能力。
TDSQL-A全并行分为三个层级：
第一层节点级并行。所谓节点级的并行是，系统拿到一个查询之后，会把查询分发给各个不同的DN，通过DN之间分片区的查询来完成节点级并行；
第二是执行器拿到分配后把算子并行化，即尽量使用允许更多CPU资源来完成查询工作，通过多CPU方式提升查询的效率；
第三层是指令层面，包括对于CPU的特殊指令、SMD指令等，通过简单的算术运算或者求值，以及通过指定值的优化和并行来提升查询效率。
总结而言，全并行计算是系统榨干硬件潜力的必经之路，是做复杂查询、实时在线查询的必经之路。

除了高性能计算，随着行业对OLAP技术深入研究，近年来向量化也越来越受到关注。在TDSQL-A系统，也实现了向量化能力：数据量越大，列存储场景下向量化结果越明显，最好的结果是列存储向量化运行时间会达到列存储非向量化的二分之一、行存储时间的八分之一左右。向量化也是在列存储引擎里实现实时在线分析的必经之路之一。
三、结语

当前，是TDSQL-A的新起点，未来TDSQL-A整体规划分两部分：一方面是陆续将目前基于PG10的版本，merge到PG11、PG12、PG13等更高版本，持续地跟进社区版本丰富的特性来提升用户的体验，为客户创造更多价值。另一方面，TDSQL-A希望通过引入新硬件，来提升产品竞争力，为客户提供更好的服务。