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 心愿通过引入新硬件，来晋升产品竞争力，为客户提供更好的服务。