ClickHouse小记

1、ClickHouse简介

  ClickHouse 是俄罗斯的 Yandex 于 2016 年开源的列式存储数据库（DBMS），使用 C++
语言编写，主要用于在线分析处理查询（OLAP），能够使用 SQL 查询实时生成分析数据报
告。

官网：https://clickhouse.com/docs/zh

---

2、ClickHouse特点

2.1、列式存储

列式存储优点：

• 对于列的聚合，计数，求和等统计操作原因优于行式存储。
• 由于某一列的数据类型都是相同的，针对于数据存储更容易进行数据压缩，每一列选择更优的数据压缩算法，大大提高了数据的压缩比重。
• 由于数据压缩比更好，一方面节省了磁盘空间，另一方面对于 cache 也有了更大的发挥空间。

2.2、DBMS的功能

  几乎覆盖了标准 SQL 的大部分语法，包括 DDL 和 DML，以及配套的各种函数，用户管理及权限管理，数据的备份与恢复。

2.3、多样化引擎

  ClickHouse 和 MySQL 类似，把表级的存储引擎插件化，根据表的不同需求可以设定不同的存储引擎。目前包括合并树、日志、接口和其他四大类 20 多种引擎。

2.4、高吞吐写入能力

  ClickHouse采用类LSM Tree的结构，数据写入后定期在后台Compaction。通过类LSM tree的结构，ClickHouse 在数据导入时全部是顺序 append 写，写入后数据段不可更改，在后台compaction 时也是多个段 merge sort 后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力，即便在 HDD 上也有着优异的写入性能。
  官方公开 benchmark 测试显示能够达到 50MB-200MB/s 的写入吞吐能力，按照每行100Byte 估算，大约相当于 50W-200W 条/s 的写入速度。

2.5、数据分区与线程级并行

  ClickHouse 将数据划分为多个 partition，每个 partition 再进一步划分为多个 indexgranularity(索引粒度)，然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。在这种设计下，单条 Query 就能利用整机所有 CPU。极致的并行处理能力，极大的降低了查询延时。
  所以，ClickHouse 即使对于大量数据的查询也能够化整为零平行处理。但是有一个弊端就是对于单条查询使用多 cpu，就不利于同时并发多条查询。所以对于高 qps 的查询业务，ClickHouse 并不是强项。

2.6、性能对比

单表查询

关联查询

  结论: ClickHouse 像很多 OLAP 数据库一样，单表查询速度由于关联查询，而且 ClickHouse的两者差距更为明显。

---

3、ClickHouse安装注意事项

3.1、/etc/security/limits.conf

sudo vim /etc/security/limits.conf 末尾增加

* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

3.2、CentOS 取消 SELINUX

修改/etc/selinux/config 中的 SELINUX=disabled

SELINUX=disabled

3.3、配置非本机访问

sudo vim /etc/clickhouse-server/config.xml

::</listen_host> 的注释打开

---

4、ClickHouse数据类型

4.1、整型

固定长度的整型，包括有符号整型或无符号整型。

• Int8 - [-128 : 127]
• Int16 - [-32768 : 32767]
• Int32 - [-2147483648 : 2147483647]
• Int64 - [-9223372036854775808 : 9223372036854775807]
• UInt8 - [0 : 255]
• UInt16 - [0 : 65535]
• UInt32 - [0 : 4294967295]
• UInt64 - [0 : 18446744073709551615]

使用场景： 个数、数量、也可以存储型 id 。

4.2、浮点型

• Float32 - float
• Float64 – double

  建议尽可能以整数形式存储数据。例如，将固定精度的数字转换为整数值，如时间用毫秒为单位表示，因为浮点型进行计算时可能引起四舍五入的误差。

4.3、布尔型

  没有单独的类型来存储布尔值。可以使用 UInt8 类型，取值限制为 0 或 1。

4.4、Decimal 型

  有符号的浮点数，可在加、减和乘法运算过程中保持精度。对于除法，最低有效数字会被丢弃（不舍入）。
有三种声明： s 标识小数位

• Decimal32(s)，相当于 Decimal(9-s,s)，有效位数为 1~9
• Decimal64(s)，相当于 Decimal(18-s,s)，有效位数为 1~18
• Decimal128(s)，相当于 Decimal(38-s,s)，有效位数为 1~38

  使用场景： 一般金额字段、汇率、利率等字段为了保证小数点精度，都使用 Decimal进行存储。

4.5、字符串

• String
    字符串可以任意长度的。它可以包含任意的字节集，包含空字节。
• FixedString(N)
    固定长度 N 的字符串，N 必须是严格的正自然数。当服务端读取长度小于 N 的字符串时候，通过在字符串末尾添加空字节来达到 N 字节长度。 当服务端读取长度大于 N 的字符串时候，将返回错误消息。
    与 String 相比，极少会使用 FixedString，因为使用起来不是很方便。

  使用场景：名称、文字描述、字符型编码。 固定长度的可以保存一些定长的内容，比如一些编码，性别等但是考虑到一定的变化风险，带来收益不够明显，所以定长字符串使用意义有限。

4.6、枚举

• 包括 Enum8 和 Enum16 类型。 Enum 保存 ‘string’= integer 的对应关系。
• Enum8 用’String’= Int8 对描述。
• Enum16 用 ‘String’= Int16 对描述。

CREATE TABLE t_enum
(
    x Enum8('hello' = 1, 'world' = 2)
)
ENGINE = TinyLog;

  使用场景：对一些状态、类型的字段算是一种空间优化，也算是一种数据约束。但是实际使用中往往因为一些数据内容的变化增加一定的维护成本，甚至是数据丢失问题。所以谨慎使用。

4.7、时间类型

目前 ClickHouse 有三种时间类型

• Date 接受 年- 月- 日的字符串比如 ‘2019-12-16’
• Datetime 接受 年- 月- 日 时: 分: 秒的字符串比如 ‘2019-12-16 20:50:10’
• Datetime64 接受 年- 月- 日 时: 分: 秒. 亚秒的字符串比如‘2019-12-16 20:50:10.66

4.8、数组

• Array(T) ：由 T 类型元素组成的数组。

  T 可以是任意类型，包含数组类型。 但不推荐使用多维数组，ClickHouse 对多维数组的支持有限。

---

5、表引擎

  表引擎是 ClickHouse 的一大特色。可以说， 表引擎决定了如何存储表的数据。包括：

• 数据的存储方式和位置，写到哪里以及从哪里读取数据。
• 支持哪些查询以及如何支持。
• 并发数据访问。
• 索引的使用（如果存在）。
• 是否可以执行多线程请求。
• 数据复制参数。

  表引擎的使用方式就是必须显式在创建表时定义该表使用的引擎，以及引擎使用的相关参数。

  特别注意：引擎的名称大小写敏感

5.1、TinyLog

  以列文件的形式保存在磁盘上，不支持索引，没有并发控制。一般保存少量数据的小表，生产环境上作用有限。可以用于平时练习测试用。

5.2、Memory

  内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。读写操作不会相互阻塞，不支持索引。简单查询下有非常非常高的性能表现（超过 10G/s）。
  一般用到它的地方不多，除了用来测试，就是在需要非常高的性能，同时数据量又不太大（上限大概 1 亿行）的场景。

5.3、MergeTree (重点、核心)

  ClickHouse 中最强大的表引擎当属 MergeTree（合并树）引擎及该系列（*MergeTree）中的其他引擎，支持索引和分区，地位可以相当于 innodb 之于 Mysql。 而且基于 MergeTree，还衍生除了很多小弟，也是非常有特色的引擎。

create table t_order_mt(
    id UInt32,
    sku_id String,
    total_amount Decimal(16,2),
    create_time Datetime
) engine =MergeTree
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id,sku_id);

5.3.1、partition by 分区( 可选)

• 作用
    学过 hive 的应该都不陌生，分区的目的主要是降低扫描的范围，优化查询速度
• 不填
    只会使用一个分区。
• 分区目录
    MergeTree 是以列文件+索引文件+表定义文件组成的，但是如果设定了分区那么这些文件就会保存到不同的分区目录中。
• 并行
    分区后，面对涉及跨分区的查询统计，ClickHouse 会以分区为单位并行处理。
• 数据写入与分区合并
    任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区。写入后的某个时刻（大概 10-15 分后），ClickHouse 会自动执行合并操作（等不及也可以手动通过 optimize 执行），把临时分区的数据，合并到已有分区中。

optimize table xxxx final;

5.3.2、primary key 主键( 可选)

• ClickHouse 中的主键，和其他数据库不太一样， 它只提供了数据的一级索引，但是却不是唯一约束。这就意味着是可以存在相同
  primary key 的数据的。
• 主键的设定主要依据是查询语句中的 where 条件。
• 根据条件通过对主键进行某种形式的二分查找，能够定位到对应的 index granularity,避免了全表扫描。
• index granularity： 直接翻译的话就是索引粒度，指在稀疏索引中两个相邻索引对应数据的间隔。ClickHouse 中的
  MergeTree 默认是 8192。官方不建议修改这个值，除非该列存在大量重复值，比如在一个分区中几万行才有一个不同数据。

稀疏索引：

  稀疏索引的好处就是可以用很少的索引数据，定位更多的数据，代价就是只能定位到索引粒度的第一行，然后再进行进行一点扫描。

5.3.3、order by （必选）

• order by 设定了分区内的数据按照哪些字段顺序进行有序保存。
• order by 是 MergeTree 中唯一一个必填项，甚至比 primary key
  还重要，因为当用户不设置主键的情况，很多处理会依照 order by 的字段进行处理（比如去重和汇总）。
• 要求：主键必须是 order by 字段的前缀字段。
• 比如 order by 字段是 (id,sku_id) 那么主键必须是 id 或者(id,sku_id)

5.3.4、二级索引

  目前在 ClickHouse 的官网上二级索引的功能在 v20.1.2.4 之前是被标注为实验性的，在这个版本之后默认是开启的。

老版本 使用二级索引前需要增加设置

  是否允许使用实验性的二级索引（v20.1.2.4 开始，这个参数已被删除，默认开启）

set allow_experimental_data_skipping_indices=1;

create table t_order_mt2(
id UInt32,
sku_id String,
total_amount Decimal(16,2),
create_time Datetime,
INDEX a total_amount TYPE minmax GRANULARITY 5
) engine =MergeTree
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id, sku_id);

其中 GRANULARITY N 是设定二级索引对于一级索引粒度的粒度。

5.3.5、数据TTL

  TTL 即 Time To Live，MergeTree 提供了可以管理数据表或者列的生命周期的功能。

• 列级别TTL

total_amount Decimal(16,2) TTL create_time+interval 10 SECOND,

• 表级别TTL

下面的这条语句是数据会在 create_time 之后 10 秒丢失

alter table t_order_mt3 MODIFY TTL create_time + INTERVAL 10 SECOND;

  涉及判断的字段必须是 Date 或者 Datetime 类型，推荐使用分区的日期字段。

能够使用的时间周期：

• SECOND
• MINUTE
• HOUR
• DAY
• WEEK
• MONTH
• QUARTER
• YEAR

5.4、MergeTree - ReplacingMergeTree

  ReplacingMergeTree 是 MergeTree 的一个变种，它存储特性完全继承 MergeTree，只是多了一个去重的功能。 尽管 MergeTree 可以设置主键，但是 primary key 其实没有唯一约束的功能。如果你想处理掉重复的数据，可以借助这个 ReplacingMergeTree。

• 去重时机
    数据的去重只会在合并的过程中出现。合并会在未知的时间在后台进行，所以你无法预先作出计划。有一些数据可能仍未被处理。
• 去重范围
    如果表经过了分区，去重只会在分区内部进行去重，不能执行跨分区的去重。
    所以 ReplacingMergeTree 能力有限， ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现。

案例演示

create table t_order_rmt(
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2) ,
   create_time Datetime
) engine =ReplacingMergeTree(create_time)
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id, sku_id);

  ReplacingMergeTree() 填入的参数为版本字段，重复数据保留版本字段值最大的。
  如果不填版本字段，默认按照插入顺序保留最后一条。

结论：

1. 实际上是使用 order by 字段作为唯一键
2. 去重不能跨分区
3. 只有同一批插入（新版本）或合并分区时才会进行去重
4. 认定重复的数据保留，版本字段值最大的
5. 如果版本字段相同则按插入顺序保留最后一笔

5.5、MergeTree - SummingMergeTree

  对于不查询明细，只关心以维度进行汇总聚合结果的场景。如果只使用普通的MergeTree的话，无论是存储空间的开销，还是查询时临时聚合的开销都比较大。
  ClickHouse 为了这种场景，提供了一种能够“预聚合”的引擎SummingMergeTree

案例演示

create table t_order_smt(
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2) ,
   create_time Datetime
) engine =SummingMergeTree(total_amount)
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id,sku_id );

结论

1. 以 SummingMergeTree（）中指定的列作为汇总数据列
2. 可以填写多列必须数字列，如果不填，以所有非维度列且为数字列的字段为汇总数据列
3. 以 order by 的列为准，作为维度列
4. 其他的列按插入顺序保留第一行
5. 不在一个分区的数据不会被聚合
6. 只有在同一批次插入(新版本)或分片合并时才会进行聚合

开发建议

  设计聚合表的话，唯一键值、流水号可以去掉，所有字段全部是维度、度量或者时间戳。

问题：

能不能直接执行以下 SQL 得到汇总值

select total_amount from XXX where province_name=’’ and create_date=’xxx’

不行，可能会包含一些还没来得及聚合的临时明细

  如果要是获取汇总值，还是需要使用 sum 进行聚合，这样效率会有一定的提高，但本身 ClickHouse 是列式存储的，效率提升有限，不会特别明显。

select sum(total_amount) from province_name=’’ and create_date=‘xxx’

5.6、其余表引擎

https://clickhouse.com/docs/zh/engines/table-engines

---

6、SQL操作

6.1、基本SQL操作

基本SQL操作参考官方文档：https://clickhouse.com/docs/zh/sql-reference

6.2、Update 和 Delete

• ClickHouse 提供了 Delete 和 Update 的能力，这类操作被称为 Mutation 查询，它可以看做 Alter的一种。
• 虽然可以实现修改和删除，但是和一般的 OLTP 数据库不一样，Mutation 语句是一种很“重”的操作，而且不支持事务。
• “重”的原因主要是每次修改或者删除都会导致放弃目标数据的原有分区，重建新分区。所以尽量做批量的变更，不要进行频繁小数据的操作。

删除操作

alter table t_order_smt delete where sku_id ='sku_001';

修改操作

alter table t_order_smt update total_amount=toDecimal32(2000.00,2) where id = 102;

  由于操作比较“重”，所以 Mutation 语句分两步执行，同步执行的部分其实只是进行新增数据新增分区和并把旧分区打上逻辑上的失效标记。直到触发分区合并的时候，才会删除旧数据释放磁盘空间，一般不会开放这样的功能给用户，由管理员完成。

6.3、查询操作

ClickHouse 基本上与标准 SQL 差别不大

• 支持子查询
• 支持 CTE(Common Table Expression 公用表表达式 with 子句)
• 支持各种 JOIN， 但是 JOIN 操作无法使用缓存，所以即使是两次相同的 JOIN 语句，ClickHouse 也会视为两条新 SQL
• 窗口函数
• 不支持自定义函数
• GROUP BY 操作增加了 with rollup\with cube\with total 用来计算小计和

案例：with rollup - 从右至左去掉维度进行小计

select id , sku_id,sum(total_amount) from t_order_mt group by
id,sku_id with rollup;

案例：with cube : 从右至左去掉维度进行小计，再从左至右去掉维度进行小计

select id , sku_id,sum(total_amount) from t_order_mt group by
id,sku_id with cube;

案例：with totals: 只计算合计

select id , sku_id,sum(total_amount) from t_order_mt group by
id,sku_id with totals;

6.4、alter操作

• 新增字段

alter table tableName add column newcolname String after col1;

• 修改字段类型

alter table tableName modify column newcolname String;

• 删除字段

alter table tableName drop column newcolname;

6.5、导出数据

clickhouse-client --query "select * from t_order_mt where
create_time='2020-06-01 12:00:00'" --format CSVWithNames>
/opt/module/data/rs1.csv

---

7、副本

  副本的目的主要是保障数据的高可用性，即使一台 ClickHouse 节点宕机，那么也可以从其他服务器获得相同的数据。

7.1、副本写入流程

7.2、副本配置步骤

1、/etc/clickhouse-server/config.d 目录下创建一个名为 metrika.xml的配置文件：注：也可以不创建外部文件，直接在 config.xml 中指定

<yandex>
    <zookeeper-servers>
        <node index="1">
            <host>hadoop地址host>
            <port>2181port>
        node>
        <node index="2">
            <host>hadoop地址host>
            <port>2181port>
        node>
        <node index="3">
            <host>hadoop地址host>
            <port>2181port>
        node>
    zookeeper-servers>
yandex>

2、/etc/clickhouse-server/config.xml 中增加

<zookeeper incl="zookeeper-servers" optional="true" />
<include_from>/etc/clickhouse-server/config.d/metrika.xmlinclude_from>

3、重启服务

4、其他说明

create table t_order_rep2 (
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2),
   create_time Datetime
) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_102')
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id,sku_id);

create table t_order_rep2 (
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2),
   create_time Datetime
) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_103')
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id,sku_id);

• 副本只能同步数据，不能同步表结构，所以我们需要在每台机器上自己手动建表

参数解释 ReplicatedMergeTree

• 第一 个参数是分片的 zk_path 一般按照： /clickhouse/table/{shard}/{table_name} 的格式写，如果只有一个分片就写 01 即可。
• 第二个参数是副本名称，相同的分片副本名称不能相同。

---

8、分片集群

• 副本虽然能够提高数据的可用性，降低丢失风险，但是每台服务器实际上必须容纳全量数据，对数据的横向扩容没有解决。
• 要解决数据水平切分的问题，需要引入分片的概念。通过分片把一份完整的数据进行切分，不同的分片分布到不同的节点上，再通过
  Distributed 表引擎把数据拼接起来一同使用。
• Distributed 表引擎本身不存储数据，有点类似于 MyCat 之于
  MySql，成为一种中间件，通过分布式逻辑表来写入、分发、路由来操作多台节点不同分片的分布式数据。

  注意：ClickHouse 的集群是表级别的，实际企业中，大部分做了高可用，但是没有用分片，避免降低查询性能以及操作集群的复杂性。

8.1、集群写入流程（3 分片 2 副本共 6 个节点）

8.2、集群读取流程（3 分片 2 副本共 6 个节点）

8.3、分片 2 副本共 6 个节点 集群 配置 （ 供参考）

  配置的位置还是在之前的/etc/clickhouse-server/config.d/metrika.xml，内容如下：
  注：也可以不创建外部文件，直接在 config.xml 的中指定

<yandex>
    <remote_servers>
        <gmall_cluster>
            
            <shard>
                
                <internal_replication>trueinternal_replication>
                
                <replica>
                    <host>hadoop101host>
                    <port>9000port>
                replica>
                
                <replica>
                    <host>hadoop102host>
                    <port>9000port>
                replica>
            shard>
            <shard>
                
                <internal_replication>trueinternal_replication>
                <replica>
                    
                    <host>hadoop103host>
                    <port>9000port>
                replica>
                <replica>
                    
                    <host>hadoop104host>
                    <port>9000port>
                replica>
            shard>
            <shard>
                
                <internal_replication>trueinternal_replication>
                <replica>
                    
                    <host>hadoop105host>
                    <port>9000port>
                replica>
                <replica>
                    
                    <host>hadoop106host>
                    <port>9000port>
                replica>
            shard>
        gmall_cluster>
    remote_servers>
yandex>

8.4、集群分片建表

create table st_order_mt_all2 on cluster gmall_cluster
(
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2),
   create_time Datetime
)engine = Distributed(gmall_cluster,default,st_order_mt,hiveHash(sku_id));

参数含义：

• Distributed（集群名称，库名，本地表名，分片键）
• 分片键必须是整型数字，所以用 hiveHash 函数转换，也可以 rand()

---

9、Explain 查看执行计划

  在 clickhouse 20.6 版本之前要查看 SQL 语句的执行计划需要设置日志级别为 trace 才能可以看到，并且只能真正执行 sql，在执行日志里面查看。在 20.6 版本引入了原生的执行计划的语法。在 20.6.3 版本成为正式版本的功能。

9.1、基本语法

EXPLAIN [AST | SYNTAX | PLAN | PIPELINE] [setting = value, ...]
SELECT ... [FORMAT ...]

• PLAN：用于查看执行计划，默认值。
  1> header 打印计划中各个步骤的 head 说明，默认关闭，默认值 0;
  2> description 打印计划中各个步骤的描述，默认开启，默认值 1；
  3> actions 打印计划中各个步骤的详细信息，默认关闭，默认值 0。
• AST ：用于查看语法树;
• SYNTAX：用于优化语法;
• PIPELINE：用于查看 PIPELINE 计划。
  1> header 打印计划中各个步骤的 head 说明，默认关闭;
  2> graph 用 DOT 图形语言描述管道图，默认关闭，需要查看相关的图形需要配合graphviz 查看；
  3> actions 如果开启了 graph，紧凑打印打，默认开启。

注： PLAN 和 PIPELINE 还可以进行额外的显示设置，如上参数所示。

9.2、案例 - 新版本

  可以再安装一个 20.6 以上版本，或者直接在官网的在线 demo，选择高版本进行测试。
  官网示例集：https://clickhouse.com/docs/zh/getting-started/example-datasets

查看 PLAIN - 简单查询

explain plan select arrayJoin([1,2,3,null,null]);

查看PLAIN - 复杂SQL

explain select database,table,count(1) cnt from system.parts where
database in ('datasets','system') group by database,table order by
database,cnt desc limit 2 by database;

查看PLAIN - 打开全部的参数的执行计划

EXPLAIN header=1, actions=1,description=1 SELECT number from
system.numbers limit 10;

AST 语法树

EXPLAIN AST SELECT number from system.numbers limit 10;

SYNTAX 语法优化

//先做一次查询
SELECT number = 1 ? 'hello' : (number = 2 ? 'world' : 'atguigu') FROM numbers(10);

//查看语法优化
EXPLAIN SYNTAX SELECT number = 1 ? 'hello' : (number = 2 ? 'world' :
'atguigu') FROM numbers(10);

//开启三元运算符优化
SET optimize_if_chain_to_multiif = 1;

//再次查看语法优化
EXPLAIN SYNTAX SELECT number = 1 ? 'hello' : (number = 2 ? 'world' :
'atguigu') FROM numbers(10);

//返回优化后的语句
SELECT multiIf(number = 1, \'hello\', number = 2, \'world\', \'xyz\')
FROM numbers(10)

查看 PIPELINE

EXPLAIN PIPELINE SELECT sum(number) FROM numbers_mt(100000) GROUP BY
number % 20;

//打开其他参数
EXPLAIN PIPELINE header=1,graph=1 SELECT sum(number) FROM
numbers_mt(10000) GROUP BY number%20;

9.3、案例 - 老版本

clickhouse-client -h 主机名 --send_logs_level=trace <<< "sql" > /dev/null

  其中，send_logs_level 参数指定日志等级为 trace，<<<将 SQL 语句重定向至 clickhouse-client 进行查询，> /dev/null 将查询结果重定向到空设备吞掉，以便观察日志。

注意：

• 通过将 ClickHouse 的服务日志，设置到 DEBUG 或者 TRACE 级别，才可以变相实现EXPLAIN 查询的作用。
• 需要真正的执行 SQL 查询，CH 才能打印计划日志，所以如果表的数据量很大，最好借助 LIMIT 子句，减小查询返回的数据量。

10、建表优化

10.1、时间字段的类型

• 建表时能用数值型或日期时间型表示的字段就不要用字符串，全 String 类型在以 Hive为中心的数仓建设中常见，但 ClickHouse环境不应受此影响。
• 虽然 ClickHouse 底层将 DateTime 存储为时间戳 Long 类型，但不建议存储 Long 类型，因为 DateTime 不需要经过函数转换处理，执行效率高、可读性好。

create table t_type2(
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2) ,
   create_time Int32
) engine =ReplacingMergeTree(create_time)
partition by toYYYYMMDD(toDate(create_time)) –-需要转换一次，否则报错
primary key (id)
order by (id, sku_id);

10.2、空值存储类型

  官方已经指出 Nullable 类型几乎总是会拖累性能，因为存储 Nullable 列时需要创建一个额外的文件来存储 NULL 的标记，并且 Nullable 列无法被索引。因此除非极特殊情况，应直接使用字段默认值表示空，或者自行指定一个在业务中无意义的值（例如用-1 表示没有商品ID）。

CREATE TABLE t_null(x Int8, y Nullable(Int8)) ENGINE TinyLog;
INSERT INTO t_null VALUES (1, NULL), (2, 3);
SELECT x + y FROM t_null;

查看存储的文件：

10.3、分区和索引

• 分区粒度根据业务特点决定，不宜过粗或过细。一般选择 按天分区，也可以指定为 Tuple()，以单表一亿数据为例，分区大小控制在 10-30 个为最佳。
• 必须指定索引列，ClickHouse 中的索引列即排序列，通过 order by 指定，一般在查询条件中经常被用来充当筛选条件的属性被纳入进来；可以是单一维度，也可以是组合维度的索引；通常需要满足高级列在前、查询频率大的在前原则；还有基数特别大的不适合做索引列，如用户表的 userid 字段；通常 筛选后的数据满足在百万以内为最佳。
• 比如官方案例的表：

……
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
……

……
PARTITION BY toYYYYMM(StartDate)
ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID)
……

10.4、表参数

• Index_granularity 是用来控制索引粒度的，默认是 8192，如非必须不建议调整。
• 如果表中不是必须保留全量历史数据，建议指定 TTL（生存时间值），可以免去手动过期历史数据的麻烦，TTL 也可以通过 alter table 语句随时修改。

10.5、写入和删除优化

• 尽量不要执行单条或小批量删除和插入操作，这样会产生小分区文件，给后台Merge 任务带来巨大压力
• 不要一次写入太多分区，或数据写入太快，数据写入太快会导致 Merge 速度跟不上而报错，一般建议每秒钟发起 2-3 次写入操作，每次操作写入 2w~5w 条数据（依服务器性能而定）
• 写入过快报错，报错信息：

1. Code: 252, e.displayText() = DB::Exception: Too many parts(304).
Merges are processing significantly slower than inserts
2. Code: 241, e.displayText() = DB::Exception: Memory limit (for query)
exceeded:would use 9.37 GiB (attempt to allocate chunk of 301989888
bytes), maximum: 9.31 Gi

处理方式：
“ Too many parts 处理 ” ：使用 WAL 预写日志，提高写入性能。
in_memory_parts_enable_wal 默认为 true
在服务器内存充裕的情况下增加内存配额，一般通过 max_memory_usage 来实现
在服务器内存不充裕的情况下，建议将超出部分内容分配到系统硬盘上，但会降低执行速度，一般通过 max_bytes_before_external_group_by、max_bytes_before_external_sort 参数来实现。

---

11、常见配置

11.1、配置项

config.xml 或 users.xml 中， 基本上都在 users.xml

11.2、CPU 资源

11.3、内存资源

11.4、存储

  ClickHouse 不支持设置多数据目录，为了提升数据 io 性能，可以挂载虚拟券组，一个券组绑定多块物理磁盘提升读写性能，多数据查询场景 SSD 会比普通机械硬盘快 2-3 倍。

---

12、ClickHouse语法优化

12.1、COUNT优化

• 在调用 count 函数时，如果使用的是 count() 或者 count(*)，且没有 where 条件，则会直接使用system.tables 的 total_row
• 如果 count 具体的列字段，则不会使用此项优化

12.2、消除子查询重复字段

下面语句子查询中有两个重复的 id 字段，会被去重:

EXPLAIN SYNTAX 
SELECT a.UserID, b.VisitID, a.URL, b.UserID
FROM hits_v1 AS a
LEFT JOIN (
SELECT UserID, UserID as HaHa, VisitID
FROM visits_v1) AS b
USING (UserID)
limit 3;
//返回优化语句：
SELECT UserID, VisitID, URL, b.UserID
FROM hits_v1 AS a
ALL LEFT JOIN
(
SELECT UserID, VisitID
FROM visits_v1
) AS b USING (UserID)
LIMIT 3

12.3、谓词下推

• 当 group by 有 having 子句，但是没有 with cube、with rollup 或者 with totals 修饰的时候，having 过滤会下推到 where 提前过滤。例如下面的查询，HAVING name 变成了 WHERE name，在 group by 之前过滤

12.4、聚合计算外推

• 聚合函数内的计算，会外推，例如：

EXPLAIN SYNTAX
SELECT sum(UserID * 2) FROM visits_v1
//返回优化后的语句
SELECT sum(UserID) * 2 FROM visits_v1

12.5、聚合函数消除

• 如果对聚合键，也就是 group by key 使用 min、max、any 聚合函数，则将函数消除，例如：

EXPLAIN SYNTAX
SELECT
sum(UserID * 2),
max(VisitID),
max(UserID)
FROM visits_v1
GROUP BY UserID

//返回优化后的语句
SELECT
sum(UserID) * 2,
max(VisitID),
UserID
FROM visits_v1
GROUP BY UserID

12.6、删除重复的 order by key

• 例如下面的语句，重复的聚合键 id 字段会被去重:

EXPLAIN SYNTAX
SELECT *
FROM visits_v1
ORDER BY
UserID ASC,
UserID ASC,
VisitID ASC,
VisitID ASC
//返回优化后的语句：

select
……
FROM visits_v1
ORDER BY
UserID ASC,
VisitID ASC

12.7、删除重复的 limit by key

• 例如下面的语句，重复声明的 name 字段会被去重：

EXPLAIN SYNTAX
SELECT *
FROM visits_v1
LIMIT 3 BY
VisitID,
VisitID
LIMIT 10

//返回优化后的语句：
select
……
FROM visits_v1
LIMIT 3 BY VisitID
LIMIT 10

12.8、删除重复的 USING Key

• 例如下面的语句，重复的关联键 id 字段会被去重：

EXPLAIN SYNTAX
SELECT
a.UserID,
a.UserID,
b.VisitID,
a.URL,
b.UserID
FROM hits_v1 AS a
LEFT JOIN visits_v1 AS b USING (UserID, UserID)

//返回优化后的语句：
SELECT
UserID,
UserID,
VisitID,
URL,
b.UserID
FROM hits_v1 AS a
ALL LEFT JOIN visits_v1 AS b USING (UserID)

12.9、标量替换

• 如果子查询只返回一行数据，在被引用的时候用标量替换，例如下面语句中的total_disk_usage 字段：

EXPLAIN SYNTAX
WITH
(
SELECT sum(bytes)
FROM system.parts
WHERE active
) AS total_disk_usage
SELECT
(sum(bytes) / total_disk_usage) * 100 AS table_disk_usage,
table
FROM system.parts
GROUP BY table
ORDER BY table_disk_usage DESC
LIMIT 10;

//返回优化后的语句：
WITH CAST(0, \'UInt64\') AS total_disk_usage
SELECT
(sum(bytes) / total_disk_usage) * 100 AS table_disk_usage,
table
FROM system.parts
GROUP BY table
ORDER BY table_disk_usage DESC
LIMIT 10

12.10、三元运算优化

• 如果开启了 optimize_if_chain_to_multiif 参数，三元运算符会被替换成 multiIf 函数，例如：

EXPLAIN SYNTAX
SELECT number = 1 ? 'hello' : (number = 2 ? 'world' : 'atguigu')
FROM numbers(10)
settings optimize_if_chain_to_multiif = 1;
//返回优化后的语句：
SELECT multiIf(number = 1, \'hello\', number = 2, \'world\', \'atguigu\')
FROM numbers(10)
SETTINGS optimize_if_chain_to_multiif = 1

13、查询优化

13.1、单表优化 - Prewhere 替代 where

• Prewhere 和 where 语句的作用相同，用来过滤数据。不同之处在于 prewhere 只支持*MergeTree 族系列引擎的表，首先会读取指定的列数据，来判断数据过滤，等待数据过滤之后再读取 select 声明的列字段来补全其余属性。
• 当查询列明显多于筛选列时使用 Prewhere 可十倍提升查询能，Prewhere 会自动优化执行过滤阶段的数据读取方式，降低 io 操作。
• 在某些场合下，prewhere 语句比 where 语句处理的数据量更少性能更高。

  默认情况， where 会自动优化成 prewhere，但是某些场景即使开启优化，也不会自动转换成 prewhere，需要手动指定 prewhere：

1. 使用常量表达式
2. 使用默认值为 alias 类型的字段
3. 包含了 arrayJOIN，globalIn，globalNotIn 或者 indexHint 的查询
4. select 查询的列字段和 where 的谓词相同
5. 使用了主键字段

13.2、单表优化 - 数据采样

• 通过采样运算可极大提升数据分析的性能

SELECT Title,count(*) AS PageViews
FROM hits_v1
SAMPLE 0.1 #代表采样 10%的数据,也可以是具体的条数
WHERE CounterID =57
GROUP BY Title
ORDER BY PageViews DESC LIMIT 1000

采样修饰符只有在 MergeTree engine 表中才有效，且在创建表时需要指定采样策略。

13.3、单表优化 - 列裁剪 与分区裁剪

• 数据量太大时应避免使用 select * 操作，查询的性能会与查询的字段大小和数量成线性表换，字段越少，消耗的 io 资源越少，性能就会越高。

反例：
select * from datasets.hits_v1;
正例：
select WatchID,
JavaEnable,
Title,
GoodEvent,
EventTime,
EventDate,
CounterID,
ClientIP,
ClientIP6,
RegionID,
UserID
from datasets.hits_v1;

• 分区裁剪就是只读取需要的分区，在过滤条件中指定。

select WatchID,
JavaEnable,
Title,
GoodEvent,
EventTime,
EventDate,
CounterID,
ClientIP,
ClientIP6,
RegionID,
UserID
from datasets.hits_v1
where EventDate='2014-03-23';

13.4、单表优化 - orderby 结合 where 、limit

• 千万以上数据集进行 order by 查询时需要搭配 where 条件和 limit 语句一起使用。

#正例：
SELECT UserID,Age
FROM hits_v1
WHERE CounterID=57
ORDER BY Age DESC LIMIT 1000
#反例：
SELECT UserID,Age
FROM hits_v1
ORDER BY Age DESC

13.5、单表优化 - 避免构建虚拟列

• 如非必须，不要在结果集上构建虚拟列，虚拟列非常消耗资源浪费性能，可以考虑在前端进行处理，或者在表中构造实际字段进行额外存储。

反例：
SELECT Income,Age,Income/Age as IncRate FROM datasets.hits_v1;
正例：
拿到 Income 和 Age 后，考虑在前端进行处理，或者在表中构造实际字段进行额外存储
SELECT Income,Age FROM datasets.hits_v1;

13.6、单表优化 - uniqCombined 替代 distinct

• 性能可提升 10 倍以上，uniqCombined 底层采用类似 HyperLogLog 算法实现，能接收 2%左右的数据误差，可直接使用这种去重方式提升查询性能。Count(distinct )会使用 uniqExact精确去重。
• 不建议在千万级不同数据上执行 distinct 去重查询，改为近似去重 uniqCombined

反例：
select count(distinct rand()) from hits_v1;
正例：
SELECT uniqCombined(rand()) from datasets.hits_v1

13.7、单表优化 - 使用物化视图

13.8、单表优化 - 注意事项

• 查询熔断
  为了避免因个别慢查询引起的服务雪崩的问题，除了可以为单个查询设置超时以外，还可以配置周期熔断，在一个查询周期内，如果用户频繁进行慢查询操作超出规定阈值后将无法继续进行查询操作
• 关闭虚拟内存
  物理内存和虚拟内存的数据交换，会导致查询变慢，资源允许的情况下关闭虚拟内存。
• 配置 join_use_nulls
  为每一个账户添加 join_use_nulls 配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准 SQL 中的 Null 值。
• 批量写入时先排序
  批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致 ClickHouse 无法及时对新导入的数据进行合并，从而影响查询性能。
• 关注 CPU
  cpu 一般在 50%左右会出现查询波动，达到 70%会出现大范围的查询超时，cpu 是最关键的指标，要非常关注。

13.9、多表关联 - 用 IN 代替 JOIN

• 当多表联查时，查询的数据仅从其中一张表出时，可考虑用 IN 操作而不是 JOIN

insert into hits_v2
select a.* from hits_v1 a where a. CounterID in (select CounterID from
visits_v1);
#反例：使用 join
insert into table hits_v2
select a.* from hits_v1 a left join visits_v1 b on a. CounterID=b.
CounterID;

13.10、多表关联 - 大小表 JOIN

• 多表 join 时要满足小表在右的原则，右表关联时被加载到内存中与左表进行比较，ClickHouse 中无论是 Left join 、Right join 还是 Inner join 永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。

13.11、多表关联 - 注意谓词下推（版本差异）

• ClickHouse 在 join 查询时不会主动发起谓词下推的操作，需要每个子查询提前完成过滤操作，需要注意的是，是否执行谓词下推，对性能影响差别很大（新版本中已经不存在此问题，但是需要注意谓词的位置的不同依然有性能的差异）

13.12、多表关联 - 分布式表使用 GLOBAL

• 两张分布式表上的 IN 和 JOIN 之前必须加上 GLOBAL 关键字，右表只会在接收查询请求的那个节点查询一次，并将其分发到其他节点上。如果不加 GLOBAL 关键字的话，每个节点都会单独发起一次对右表的查询，而右表又是分布式表，就导致右表一共会被查询 N²次（N是该分布式表的分片数量），这就是查询放大，会带来很大开销。

13.13、多表关联 - 使用字典表

• 将一些需要关联分析的业务创建成字典表进行 join 操作，前提是字典表不宜太大，因为字典表会常驻内存

13.14、提前过滤

• 通过增加逻辑过滤可以减少数据扫描，达到提高执行速度及降低内存消耗的目的

---

14、数据一致性

  查询 CK 手册发现，即便对数据一致性支持最好的 Mergetree，也只是保证 最终一致性

  我们在使用 ReplacingMergeTree、SummingMergeTree 这类表引擎的时候，会出现短暂
数据不一致的情况。

在某些对一致性非常敏感的场景，通常有以下几种解决方案。

14.1、手动 OPTIMIZE

  在写入数据后，立刻执行 OPTIMIZE 强制触发新写入分区的合并动作。

OPTIMIZE TABLE test_a FINAL;
语法：OPTIMIZE TABLE [db.]name [ON CLUSTER cluster] [PARTITION partition |
PARTITION ID 'partition_id'] [FINAL] [DEDUPLICATE [BY expression]]

14.2、通过 Group by 去重

SELECT
user_id ,
argMax(score, create_time) AS score,
argMax(deleted, create_time) AS deleted,
max(create_time) AS ctime
FROM test_a
GROUP BY user_id
HAVING deleted = 0;

函数说明：

• argMax(field1，field2):按照 field2 的最大值取 field1 的值。

  当我们更新数据时，会写入一行新的数据，例如上面语句中，通过查询最大的
create_time 得到修改后的 score 字段值。

14.3、通过FINAL查询

• 在查询语句后增加 FINAL 修饰符，这样在查询的过程中将会执行 Merge 的特殊逻辑（例如数据去重，预聚合等）。
• 但是这种方法在早期版本基本没有人使用，因为在增加 FINAL 之后，我们的查询将会变成一个单线程的执行过程，查询速度非常慢。
• 在 v20.5.2.7-stable 版本中，FINAL 查询支持多线程执行，并且可以通过 max_final_threads参数控制单个查询的线程数。但是目前读取 part 部分的动作依然是串行的。
• FINAL 查询最终的性能和很多因素相关，列字段的大小、分区的数量等等都会影响到最终的查询时间，所以还要结合实际场景取舍。

普通查询：
select * from visits_v1 WHERE StartDate = '2014-03-17' limit 100 settings
max_threads = 2;

FINAL查询：
select * from visits_v1 final WHERE StartDate = '2014-03-17' limit 100
settings max_final_threads = 2;

---

15、物化视图

• ClickHouse 的物化视图是一种查询结果的持久化，它确实是给我们带来了查询效率的提升。用户查起来跟表没有区别，它就是一张表，它也像是一张时刻在预计算的表，创建的过程它是用了一个特殊引擎，加上后来 as select，就是 create 一个 table as select 的写法。
• “查询结果集”的范围很宽泛，可以是基础表中部分数据的一份简单拷贝，也可以是多表 join 之后产生的结果或其子集，或者原始数据的聚合指标等等。所以，物化视图不会随着基础表的变化而变化，所以它也称为快照（snapshot）

15.1、物化视图与普通视图的区别

  普通视图不保存数据，保存的仅仅是查询语句，查询的时候还是从原表读取数据，可以
将普通视图理解为是个子查询。 物化视图则是把查询的结果根据相应的引擎存入到了磁盘
或内存中，对数据重新进行了组织，你可以理解物化视图是完全的一张新表。

15.2、优缺点

• 优点：查询速度 快，要是把物化视图这些规则全部写好，它比原数据查询快了很多，总的行数少了，因为都预计算好了。
• 缺点：它的本质是一个流式数据的使用场景，是累加式的技术，所以要用历史数据做去重、去核这样的分析，在物化视图里面是不太好用的。在某些场景的使用也是有限的。而且如果一张表加了好多物化视图，在写这张表的时候，就会消耗很多机器的资源，比如数据带宽占满、存储一下子增加了很多。

15.3、物化视图限制

1. 必须指定物化视图的 engine 用于数据存储
2. TO [db].[table]语法的时候，不得使用 POPULATE。
3. 查询语句(select）可以包含下面的子句： DISTINCT, GROUP BY, ORDER BY, LIMIT…
4. 物化视图的 alter 操作有些限制，操作起来不大方便。
5. 若物化视图的定义使用了 TO [db.]name 子语句，则可以将目标表的视图 卸载DETACH 再装载 ATTACH

---

16、MaterializeMySQL 引擎

• MySQL 的用户群体很大，为了能够增强数据的实时性，很多解决方案会利用 binlog 将数据写入到 ClickHouse。为了能够监听 binlog 事件，我们需要用到类似 canal 这样的第三方中间件，这无疑增加了系统的复杂度。
• ClickHouse 20.8.2.3 版本新增加了 MaterializeMySQL 的 database 引擎，该 database 能映 射 到 MySQL 中 的 某 个 database ， 并 自 动 在 ClickHouse 中 创 建 对 应 的ReplacingMergeTree。ClickHouse 服务做为 MySQL 副本，读取 Binlog 并执行 DDL 和 DML 请求，实现了基于 MySQL Binlog 机制的业务数据库实时同步功能。

16.1、特点

1. MaterializeMySQL 同时支持 全量和 增量同步，在 database 创建之初会全量同步MySQL 中的表和数据，之后则会通过 binlog 进行增量同步。
2. MaterializeMySQL database 为其所创建的每张 ReplacingMergeTree 自动增加了_sign 和 _version 字段

  其中， _version 用作 ReplacingMergeTree 的 ver 版本参数，每当监听到 insert、update
和 delete 事件时，在 databse 内全局自增。而 _sign 则用于标记是否被删除，取值 1 或者 -1。

目前 MaterializeMySQL 支持如下几种 binlog 事件：

1. MYSQL_WRITE_ROWS_EVENT: _sign = 1，_version ++
2. MYSQL_DELETE_ROWS_EVENT: _sign = -1，_version ++
3. MYSQL_UPDATE_ROWS_EVENT: 新数据 _sign = 1
4. MYSQL_QUERY_EVENT: 支持 CREATE TABLE 、DROP TABLE 、RENAME TABLE 等。

16.2、使用细则

DDL 查询

• MySQL DDL 查询被转换成相应的 ClickHouse DDL 查询（ALTER, CREATE, DROP, RENAME）。如果 ClickHouse 不能解析某些 DDL 查询，该查询将被忽略。

数据复制

MaterializeMySQL 不支持直接插入、删除和更新查询，而是将 DDL 语句进行相应转换：

• MySQL INSERT 查询被转换为 INSERT with _sign=1。
• MySQL DELETE 查询被转换为 INSERT with _sign=-1。
• MySQL UPDATE 查询被转换成 INSERT with _sign=1 和 INSERT with _sign=-1。

SELECT 查询

• 如果在 SELECT 查询中没有指定_version，则使用 FINAL 修饰符，返回_version 的最大值对应的数据，即最新版本的数据。
• 如果在 SELECT 查询中没有指定_sign，则默认使用 WHERE _sign=1，即返回未删除状（_sign=1)的数据。

索引转换

• ClickHouse 数据库表会自动将 MySQL 主键和索引子句转换为 ORDER BY 元组。
• ClickHouse 只有一个物理顺序，由 ORDER BY 子句决定。如果需要创建新的物理顺序，请使用物化视图。

---

17、常见问题排查

17.1、分布式 DDL 某数据节点的副本不执行

问题：

  使用分布式 ddl 执行命令 create table on cluster xxxx 某个节点上没有创建
表，但是 client 返回正常，查看日志有如下报错。

 xxx.xxx: Retrying createReplica(), because some other replicas
were created at the same time

解决办法：

  重启该不执行的节点。

17.2、数据副本表和数据不一致

问题

  由于某个数据节点副本异常，导致两数据副本表不一致，某个数据副本缺少表，需要将两个数据副本调整一致。

解决办法

• 在缺少表的数据副本节点上创建缺少的表，创建为本地表，表结构可以在其他数据副本通过 show crete table xxxx 获取。
• 表结构创建后，clickhouse 会自动从其他副本同步该表数据，验证数据量是否一致即可。

17.3、副本节点全量恢复

问题

• 某个数据副本异常无法启动，需要重新搭建副本。

解决办法

• 清空异常副本节点的 metadata 和 data 目录。
• 从另一个正常副本将 metadata 目录拷贝过来（这一步之后可以启动数据库，但是只有表结构没有数据）。
• 执行 sudo -u clickhouse touch /data/clickhouse/flags/force_restore_data 启动数据库

17.4、数据副本启动缺少 zk 表

问题

• 某个数据副本表在 zk 上丢失数据，或者不存在，但是 metadata 元数据里存在，导致启动异常，报错：

Can’t get data for node /clickhouse/tables/01-
02/xxxxx/xxxxxxx/replicas/xxx/metadata: node doesn’t exist (No node):
Cannot attach table xxxxxxx

解决办法

• metadata 中移除该表的结构文件，如果多个表报错都移除
• mv metadata/xxxxxx/xxxxxxxx.sql /tmp/
• 启动数据库
• 手工创建缺少的表，表结构从其他节点 show create table 获取。
• 创建后会自动同步数据，验证数据是否一致

17.5、ZK table replicas 数据未删除，导致重建表报错

问题

• 重建表过程中，先使用 drop table xxx on cluster xxx ,各节点在 clickhouse 上table 已物理删除，但是 zk 里面针对某个 clickhouse 节点的 table meta 信息未被删除（低概率事件），因 zk 里仍存在该表的 meta 信息，导致再次创建该表 create table xxx on cluster, 该节点无法创建表(其他节点创建表成功)，报错：

Replica /clickhouse/tables/01-03/xxxxxx/xxx/replicas/xxx already exists..

解决办法

• 从其他数据副本 cp 该 table 的 metadata sql 过来.
• 重启节点

17.6、Clickhouse 节点意外关闭

问题

• 模拟其中一个节点意外宕机，在大量 insert 数据的情况下，关闭某个节点。

现象

• 数据写入不受影响、数据查询不受影响、建表 DDL 执行到异常节点会卡住，报错：

Code: 159. DB::Exception: Received from localhost:9000. DB::Exception:
Watching task /clickhouse/task_queue/ddl/query-0000565925 is executing
longer than distributed_ddl_task_timeout (=180) seconds. There are 1
unfinished hosts (0 of them are currently active), they are going to
execute the query in background.

解决办法

• 启动异常节点，期间其他副本写入数据会自动同步过来，其他副本的
  建表 DDL 也会同步

17.7、其他问题

https://help.aliyun.com/document_detail/162815.html?spm=a2c4g.11186623.6.652.312e79bd17U8IO

---