1       一句话介绍

DWS是华为基于share-nothing MPP架构自研的OLAP数据仓库。

2       基本概念

• 查询操作符：Query Operator，也称为查询迭代算子（Iterator）或查询节点（Query Tree Node）。一个查询的执行可以分解为一个或多个查询操作符，是构成一个查询执行的最基本单位。常见的查询操作符包括表扫描（Scan），表关联（Join），表聚集（Aggregation）等。
• 查询片段：每一个查询任务都可以分解成为一个或者多个查询片段。每个查询片段由一个或多个查询操作符构成，可独立在节点上运行。
• 数据流操作符：负责查询片段间的数据交互。
• 死锁：并发执行的事务争抢同一资源而无法解决的状态。
  
• Xlog：即预写式日志WAL（Write Ahead Log），是指如果要修改数据文件，必须是在这些修改操作已经记录到日志文件之后才能进行修改，即在描述这些变化的日志记录刷新到永久存储器之后。根据Xlog恢复数据的过程称为回放（replay）或redo/recovery过程，系统崩溃是或者系统启动时都会回放。
• catchup（追赶）：备机连接主机恢复数据的过程。追赶机制分为全量和增量两种。全量catchup机制，不依赖于从备，主机递归扫描本地默认表空间和自定义表空间下的所有BCM文件，然后查看状态位来确认哪些数据文件需要发送给备机。增量catchup机制依赖于从备，主机通知从备遍历其从备上暂存的数据页，将变更的数据页列表发往主机，主机直接按照从备发来的变更列表，将变更数据发往备机。DWS实例catchup分为以下两种：

• • 数据页catchup：一般出现在备机故障一段时间修复后重新连主时，从主机追赶落后数据。
  • 日志catchup：一般常见于带索引导入时主机产生过多xlog文件，备机来不及接收出现。
• 外表：用于识别数据源文件的位置、文件格式、存放位置、编码格式、数据间的分隔符等信息。是关联数据文件与数据库实表（目标表）的对象。
• Build（重建）：DN实例故障后进行重启修复，build过程中需要同步主机xlog数据，包括增量重建（incremental）、全量重建（full）以及全量轻量重建（fullcleanup）。

3       Share-nothing架构

Share-nothing架构即无共享架构，整个系统由多个互不共享CPU、内存及磁盘的节点组成。此架构下，业务数据被分散存储到不同的数据节点上，业务查询任务由协调节点统一入口，推送给数据节点执行，待所有数据节点执行完成后再由协调节点汇总反馈给业务客户端。架构示意图如下：

4       逻辑架构

DWS集群（原GaussDB A）包含管理节点、控制节点以及数据节点，其中数据节点主要部署MPPDBServer(CM)、MPPDBServer(GTM)、MPPDBServer三大模块：

• MPPDBServer(CM)：集群管理模块，即含有CMServer进程的特殊MPPDBServer模块。该模块主备部署。
• MPPDBServer(GTM)：全局事务管理模块，即含有GTM进程的特殊MPPDBServer模块。该模块主备部署。
• MPPDBServer：业务模块，每个业务模块均含有Datanode(DN)进程，CN则根据需要部署在业务模块中。该模块负责执行CM、GTM下发的任务。
  • DN进程分为主、备、从备三种。
  • CN进程多活，支撑业务连接负载均衡。
• 每种模块都含有CMAgent、Monitor进程，与CMServer构成主从结构的集群管理服务。

5       DN高可用

DN高可用架构图如下所示：

• 主备从DN之间会建立流复制通道，包含日志复制以及数据页复制。一般来讲，数据页复制流比日志复制流IO小。
• 正常情况下，主备DN强同步数据、从备不工作（从备只存放备DN故障时同步到从备的Xlog数据和数据通道复制产生的数据）。数据在主DN操作时产生日志，事务提交时将日志同步给备机，备机对接收到的Xlog进行回放，将日志转为数据；另外，列存和行存批插场景下，新增（变更）数据会直接发往备机。
• 备DN故障时，主DN将数据页发往从备DN（不做redo），保证数据仍旧写两份。备DN恢复时，会连接主DN做数据页追赶（catchup）。
• 主DN故障时，备DN自动failover升主。此时备机需要连接从备同步Xlog和数据页文件（以防此前备机因异常未同步主机数据）。如果需要同步的Xlog比较多，或者遇到某种特殊日志类型，或者数据文件比较多时，对备DN实例进行failover，过程时间就会有些长。

6       数据库连接

由于集群存在多活CN，因此建议集群安装LVS（主备部署在不同的节点上），业务应用通过LVS VIP连接集群。网络模型如下：

• 集群内节点上可直接执行gsql命令连接postgres数据库（集群安装完成后默认生成的数据库）。
• 客户端远程连接到数据库时，需要事先将客户端IP加入CN监听地址（listen_addresses）内。

7       业务流向图

• CN（协调节点）作为业务的统一入口，承担下发执行计划给DN及汇总DN执行结果的作用。因此整个SQL的执行效率取决于执行最慢的DN。
• 根据数据流输入输出关系可分为三种数据流：聚合流（Gather）将数据从多个查询片段聚合到一个。广播流（Broadcast）将数据从一个查询片段的数据向多个传输。重分布流（Redistribution）则将多个查询片段的数据，按照一定规则重组后向多个传输。

8       表查询逻辑

表t1、t2均以列c1为分布列，举例如下：

create table t1(c1 int, c2 int) distribute by hash(c1);

create table t2(c1 int, c2 int) distribute by hash(c1);

• select * from t1 where c1=1 order by c2 limit 10;

对于该sql，CN生成查询计划，给每个DN下发任务，每个DN上扫描表t1，按照c2做升序排序，返回前10条；100个DN，就会返回1000条结果给CN，CN再按照c2做升序排序，最后只返回10条给业务应用。

• select * from t1, t2 where t1.c1=t2.c1;

两个表都是按照c1列做分布列，两个表中c1列相等的数据肯定都在相同的DN上，所以按照c1列做关联时，CN生成的计划就会把这个sql语句直接发给DN上执行。

• select * from t1, t2 where t1.c1=t2.c2;

两个表都是按照c1列做分布列，而关联列t1表是c1、t2表是c2，CN生成的计划会把一个表的数据在内存中做重分布，比如把t2表按照c2做重分布，这样t1.c1和t2.c2相等的数据就会分布在相同的DN上，每个DN就可以并行做join操作。

9  锁机制

查询锁表，先判断是否存在冲突。如果无冲突，修改锁表，更新加锁信息，如果有冲突，将自己加入锁的等待队列中。锁冲突如下表所示：

10  参考

• https://blog.csdn.net/devcloud/article/details/109111666