TDSQL- A 产品定位

TDSQL- A 是腾讯基于 PostgreSQL 自主研发的分布式超大规模在线关系型数据仓库，业务场景针对于在线高性能数据分析。

TDSQL- A 有四个次要特点：

无共享 MPP 能实现无共享的存储，还能够实现线性的扩大；

在存储层面，通过自研列存储技术，可能做到行列混合存储；

在数据库规模方面，实现了超大规模集群的反对；

为了让客户有更好的体验，TDSQL- A 还有超高速的计算能力，可能疾速解决业务以及申请。

TDSQL- A 倒退历程

TDSQL- A 是在腾讯业务倒退过程中孵化进去的产品。最早的时候咱们是用单机 PG 来做一些大数据平台小规模的数据分析以及后果缓存。但随着腾讯业务的扩张，咱们发现单机的数据库曾经无奈撑持相干业务的数据量及申请量，就萌发了开发分布式数据库的想法。在 2013 年咱们启动了第一个版本的开发。

开发实现后的 TDSQL-PG(原 TBase V2），最早用来撑持外部商户零碎。随着业务的倒退，咱们在 V2 的根底上减少了列存储和分布式异步执行器、向量化等 OLAP 高级能力，在融入了腾讯云的几个次要平台后，逐步对外提供服务。TDSQL- A 最近一次闪亮亮相，是为去年第七次全国人口普查提供技术撑持。作为在线数据分析引擎，TDSQL- A 很好地撑持了国家人口普查的执行，起到了加好的成果。

TDSQL- A 技术架构

在对 TDSQL- A 产品进行研发和架构设计的时候，咱们次要面临四个方面的挑战：

一是随着 5G 和 loT 时代的到来，数据出现爆炸式的增长。单个数据库集群外面须要解决的数据的容量很容易就达到 10PB 级别的大小。这对传统的数据仓库及数据库来说，是一个十分有挑战的数据规模。

二是随着数据量的增大，咱们须要解决的数据库业务以及各种类型的终端越来越多，对数据库的并发要求比之前更高了。咱们最多的时候甚至须要解决数千个 OLAP 的并发。

三是随着业务零碎的倒退，查问会变得异样简单，须要波及到近十张大表的数据关联，这对数据存储和数据仓库查问优化都提出了很高的要求。

四是客户和业务对于延时的要求。客户心愿咱们越来越快地把后果解决实现，这样能力更好地去实现本人的商业价值和业务指标。

TDSQL- A 产品的架构设计就是围绕这四个问题的解决开展的。

1. TDSQL- A 实时数据仓库如何解决反对超大规模集群

对实时数据仓库来说，第一个要解决的问题就是如何去反对超大规模的集群。传统认知认为，分布式数据库集群的解决能力会随结点增多而变强。但实际上却并非如此。

下图就是咱们进行分布式查问的时候须要建设的网络连接，或者说咱们须要进行网络通信的管道。从图中咱们能够看到，在两表进行 JOIN 查问时，咱们少则须要两个网络连接，多则须要八个网络连接。随着 SQL 复杂度的晋升和并发的减少，零碎须要建设的网络数量则会越来越多，数据仓库的解决能力不肯定会晋升。

由此咱们能够得出一个论断，即限度分布式数据库扩展性的外围问题之一，就是服务器连接数过高。那 TDSQL- A 是如何解决这个问题的呢？

全新设计的异步执行器解耦管制和数据交互
首先在执行逻辑方面，咱们设计了全新的执行器，来解耦 SQL 执行的的管制逻辑和执行逻辑。

在查问优化阶段咱们通过剖析物理查问打算，对执行打算进行分片，由 CN 在各个节点创立执行过程。每个过程负责执行一个打算分片，这些过程不关注网络通信，互相独立执行。

假如 N 个节点，M 层 join，则会产生 M * N 个过程。

这种设计一方面拆散了 SQL 执行的管制逻辑和执行逻辑；另外一方面，也将网络连接从具体执行逻辑形象了进去，变成了一组接口，SQL 执行引擎只须要关注本人的执行逻辑，对于底层的通信逻辑则不必专门去编写代码。而且，这些过程之间互相独立，没有互相的依赖关系，没有锁和进程同步，执行效率大大晋升。

集中数据交互总线解决集群网络瓶颈
在通信逻辑方面，咱们进一步引入 Forward Node（FN）来进行节点间数据交互。每台物理机一个 FN 节点。FN 与 CN/DN 通过共享内存进行数据交互，本机数据交互还能够不走网络层，从而提供更高的性能。假如 N 个节点，M 层 Join，且不论查问多简单，只有 S *(N-1)个网络连接数。这对于服务器来说是并不算是一个很高的负载。

咱们来小结一下 TDSQL- A 是如何实现超大规模数据集群反对的。

咱们对整个数据库的执行逻辑进行了分流，把数据库分为了控制流和数据流。所谓的控制流由管制节点，CN 节点实现，它去实现执行机构的生成，执行机构的下发以及使用资源的初始化。在执行的过程中管制立体就不会再参加执行的过程，执行过程齐全由执行平台来实现，执行平台次要负责执行过程中数据的交互以及整个执行过程的达成。

在执行过程中，数据流由转发立体实现，即 FN 节点。每个服务器下面就会部署一个 FN 过程，不同的物理服务器之间的 FN 过程相互连接在一起会组成一个转发立体。FN 跟每台服务器之间通过上面的共享内存和下面的 CN 或 DN 进行通信，FN 外部实现数据的替换和路由转发。

2. TDSQL- A 自研行列混合存储能力晋升 OLAP 效率

上面介绍 TDSQL- A 全自研的行列混合的存储能力。数据库的存储有两种形式，一个是按行存储、一个是按列存储：

按行存储表：每行数据存储所有列、一次磁盘 IO 能够拜访一行中所有列、适宜 OLTP 场景。

按列存储表：每列独自存储，多个列逻辑组成一行；一次磁盘 IO 只蕴含一列数据；不便做数据压缩；适宜 OLAP 场景。

TDSQL- A 反对按列存储和按行存储两种形式来建表，同时在列表和行表之间，用户不必感知到上层的表是通过行表还是列表来建，行表和列表之间能够进行无缝的互操作——包含互相关联、相互交换数据，齐全不须要感知到底下的存储逻辑。

除了操作的便利性之外，行表和列表之间混合查问还能放弃残缺的事务一致性，也就是说在查问运行的同时，整个事务（ACID）的能力也失去残缺的保障。

3. TDSQL- A 列存储压缩能力升高业务老本

作为 OLAP 场景下的产品来说，压缩是一项十分重要的能力，这里介绍 TDSQL- A 的列存储压缩能力。

目前咱们反对两种压缩形式：

一是轻量级压缩。这是可能感知到数据内容的一种压缩形式。它能够针对用户数据的特点提供适合的压缩形式来升高用户的老本，在有法则时达到数百倍的压缩比。咱们能够针对非凡的数据，比方反复率比拟高的或者是有法则、有程序的数据进行轻量级压缩。

二是通明压缩。通明压缩次要是用 zstd 和 gzip 压缩算法来提供压缩能力，能够帮用户进一步去压缩老本，晋升解决效率。

4. 提早物化原理

在分布式场景下，特地是超大规模分布式场景下，网络 IO 和 CPU 其实是十分重要的资源。如果在计算时，网络 IO 达到了瓶颈，或者 CPU 达到了瓶颈，都会从整体上影响集群的扩展性和集群的解决能力。

目前用数据库或数据仓库进行查问时，很多应用的都是提前物化。所谓的提前物化是绝对于查问来说的。其在数据库外面会分解成几步：第一步须要从上面最底层的表外面把数据查问进去，再进行关联，join 实现之后再进行投影，传给下层要应用的一些列。

能够看到，在进行 join 时咱们其实只关联了表 b 的 f2 这一列，然而投影时却投影了表 b 的 f1 这一列。这时对之前的数据库进行提前物化时，在传递数据给 join 时，咱们就会把表 b 的 f1 和 f2 都吐出来。因为咱们计算发现下层 project 须要 f1 这一列，然而 join 这里须要 f2 这一列，所以它就会把下层须要的所有列全副在这里算进去。但实际上如果在这个中央关联时过滤的比例很高的话，比如说当初有 1% 的满足率，其实大部分的 f1 是没有意义的，因为最终在这里通过 join 会被摈弃掉。在超大规模的分布式场景下，如果表外面有 20 亿条记录，选择率是 0.01 的话，这个时候就会有 7.4GB 的有效数据传输。对于非常依赖网络流传的分布式数据库来说，7.4 个 GB 曾经是十分可观的开销了。

因而咱们引入了另外一种物化算法，即提早物化。提早物化能够简略了解为不见兔子不撒鹰。所谓的不见兔子不撒鹰，就是在投影的时候只拉去满足条件的那些数据，缩小两头这 7.4 个 GB 的传输。这就要咱们在进行 Scan 时，只看下层 join 节点须要的一些列，把它传递到下层节点去，join 实现之后把满足条件的那些列的地位信息传递给下层的 project 节点。依据咱们的测试，随着表变得越来越简单，随着查问变得越来越简单，表变得越来越大，咱们优化的成果也越来越显著。

5. TDSQL- A 全并行能力、向量化计算能力

除了下面的提早物化外，咱们还引入了零碎的全并行能力。全并行能力对数据库的 OLAP 场景数据库来讲是一个必经之路。MPP 架构让咱们具备了多节点并行的架构劣势，同时咱们还通过优化做到了节点外部的多过程过程间的进行，并在外部应用了 CPU 的非凡指令做到指令级并行，因而 TDSQL- A 能够做到三级并行，顺次是：节点级并行，过程级并行以及指令级并行。这种全并行的能力可能进一步晋升咱们整体的解决效率。

向量化计算能力在 OLAP 上也是一个必须探讨的课题。TDSQL- A 也进行了一些新的尝试，并实现了向量化计算能力：数据量越大，列存非向量化和列存向量化成果越显著，在最好的状况下，列存向量化运行工夫是列村非向量化的 1 /2，列存向量化运行工夫是行村的 1 /8。列存储的向量化执行可能达到行存储执行 1 / 8 左右。向量化计算能力对整个 OLAP 性能的晋升是非常明显的。

6. TDSQL- A 的多立体能力提供统一的读扩展性

在整体架构上，TDSQL- A 也提供了比拟好的一致性的读扩大能力。

一致性的读扩大能力是追随业务场景的催生的技术个性。有一些客户反映过这种的状况，就是在数据库 CPU，内存曾经用满的状况下，还有更多的业务申请要加进来。为了满足这种读的扩展性须要，咱们就研发出了可能提供读取能力的多立体个性，简略了解就是在读写立体的根底上，通过外部复制的形式来创立出一个只读立体，去解决只读的申请。相比之前新建数据库集群的形式，这种做法在升高了业务老本和零碎复杂度的同时，也帮忙客户解决了很多事实的问题。

7. TDSQL- A 整体技术架构小结

TDSQL- A 整体的技术架构能够总结成六点：

通过集中式的网络架构、网络交融通信技术以及前面在执行级层面引入的能力，能够进一步去拓展分布式 MPP 数据仓库的存储规模的下限，达到数千台的规模；

通过向量化技术，底层整个执行级的逻辑优化，做到极速 OLAP 的响应；

在存储层面通过多种高效的数据压缩形式，提供极高的压缩比，帮忙业务去节俭经营老本；

在接口层面残缺兼容了 SQL2003，同时对 ORALE 语法兼容性达到 95%，包含存储过程、触发器等一系列内容；

反对行列混合存储及行列混合操作的能力；

借助特有能力去拜访内部数据源，包含分布式对象存储，HDFS 存储等，可能实现存储与计算拆散。

TDSQL- A 后续布局

TDSQL- A 的后续布局分为两局部：

一方面是陆续将目前基于 PG10 的版本，merge 到 PG11、PG12、PG13 等更高版本，继续地跟进社区版本丰盛的个性，来晋升用户的体验，为客户发明更多价值。

另一方面，随着硬件技术的一直倒退，包含 GPU、FGA 以及 APE 这些新硬件的倒退，给咱们发明了为客户发明更高价值可能性，TDSQL- A 也心愿通过引入新硬件，来晋升产品竞争力，为客户提供更好的服务。