ClickHouse 的架构设计、安装方式以及连接工具(二)

​

Column 与 Field

Column 和 Field 是 ClickHouse 中最基础的映射单元，作为一款百分百的列式存储数据库，ClickHouse 按列存储数据，内存中的一个列就用一个 Column 对象表示。Column 对象分为接口和实现两个部分，在 IColumn 接口对象中，定义了对数据进行各种关系运算的方法，例如插入数据的 insertRangeFrom 方法和 insertFrom 方法，用于分页的 cut，以及用于数据过滤的 filter 方法等等。而这些方法的具体实现对象则根据数据类型的不同，由不同的对象实现，例如：ColumnString、ColumnArray 和 ColumnTuple 等等。在大部分场景中，ClickHouse 都会以整列的方式操作数据，但凡事也有例外，如果需要操作单个具体的值（也就是单列中的一行数据），则需要使用 Field 对象。Field 对象代表一个单值，与 Column 对象的泛化设计思路不同，Field 对象使用了聚合的设计模式。在 Field 对象内部聚合 Null、UInt64、String 和 Array 等 13 种数据类型及相应的处理逻辑，说白了就是这些值的类型虽然不同，但它们都是 Field 对象，因为这些类型的数据的处理逻辑都在 Field 对象里面。

Column 对象是数据表中的一列，Field 对象相当于一个单元格。

DataType

数据的序列化和反序列化工作由 DataType 负责，IDataType 接口定义了许多正反序列化的方法，它们成对出现，例如 serializeBinary 和 deserializeBinary、serializeTextJSON 和 deserializeTextJSON 等等，涵盖了常用的二进制、文本、JSON、XML、CSV 和 Protobuf 等多种格式类型。IDataType 也使用了泛化的设计模式，具体方法的实现逻辑由对应数据类型的实例对象来承载，例如 DataTypeString、DataTypeArray 以及 DataTypeTuple 等等。

接口内部定义相应的方法，具体的数据类负责实现。如果某个类实现了接口内部定义的所有方法，那么这个类就实现了这个接口，其实例对象就可以赋值给接口，通过接口来调用内部的方法。当然调用的方法必须是接口内部已经声明的，如果除了接口内部定义的方法之外，该类还定义了其它的方法，那么这些其它的方法就不能通过接口调用了。

那么接口设计有什么好处呢？首先最直观的一个好处就是实现了多态，因为不管是什么类，只要它实现了接口定义的方法，那么其实例对象就可以赋值给接口，即：一个接口，多种实现。

另外 DataType 虽然负责序列化相关工作，但它并不直接负责数据的读取，而是从 Column 对象或 Field 对象中读取。在 DataType 的实现类中，聚合了相应数据类型的 Column 对象和 Field 对象。例如 DataTypeString 会引用字符串类型的 ColumnString，而 DataTypeArray 则会引用数组类型的 ColumnArray，以此类推。

Block 和 Block流

ClickHouse 内部的数据操作是面向 Block 对象进行的，并且采用了流的形式，虽然 Column 对象和 Field 对象组成了数据的基本映射单元，但对应到实际操作，它们还少了一些必要的信息，比如数据的类型和列的名称。于是 ClickHouse 设计了 Block 对象，Block 对象可以看成是数据表的子集，Block 对象的本质是由数据对象、数据类型和列名称组成的三元组，即 Column、DataType、列名称字符串。Column 提供了数据的读取能力，而 DataType 知道如何正反序列化，所以 Block 对象在这些对象的基础上实现了进一步的抽象和封装，从而简化了整个使用的过程，仅通过 Block 对象就能完成一系列的数据操作。只不过在具体的实现过程中，Block 并没有直接聚合 Column 和 DataType 对象，而是通过 ColumnWithAndName 对象进行间接引用。

有了 Block 对象的这一层封装之后，对 Block 流的设计就是水到渠成的事情了，流操作有两组顶层接口：IBlockInputStream 负责数据的读取和关键运算，IBlockOutputStream 负责将数据输出到下一环节。Block 流也是用了泛化的设计模式，对数据的各种操作都会转换成其中一种流的实现。所以 IBlockInputStream 也是一个接口，内部定义了读取数据的若干个 read 虚方法，而具体的实现逻辑则交给它的实现类来填充，IBlockOutputStream 同理。

总共有 60 多个类实现了 IBlockInputStream 接口，它们覆盖了 ClickHouse 数据摄取的方方面面。这些实现类大致可以分为三类：第一类用于处理数据定义的 DDL 操作，例如 DDLQueryStatusInputStream 等；第二类用于处理数据关系运算的相关操作，例如 LimitBlockInputStream、JoinBlockInputStream、AggregatingBlockInputStream等；第三类则是与引擎呼应，每一种引擎都拥有与之对应的 BlockInputStream 实现，例如 MergeTreeBaseSelectBlockInputStream（MergeTree 引擎）、TinyLogBlockInputStream（TinyLog 引擎）以及 KafkaBlockInputStream（Kafka 引擎）等。

IBlockOutputStream 的设计也与 IBlockInputStream 如出一辙，IBlockOutputStream 接口同样定义了若干写入数据的 write 虚方法。但它的实现类比起 IBlockInputStream 要少很多，一共只有 20 多种，这些实现类基本用于引擎的相关处理，负责将数据写入下一环节或者最终目的地，例如：MergeTreeBlockOutputStream、TinyLogBlockOutputStream 以及 StorageFileBlockOutputStream 等。

Table

在数据表的底层设计中并没有所谓的 Table 对象，它是直接使用 IStroge 接口指代数据表，表的引擎是 ClickHouse 的一个显著特征，不同的表的引擎由不同的子类实现。例如：IStorageSystemOneBlock（系统表）、StorageMergeTree（合并树引擎）和 StorageTinyLog（日志表引擎）等。IStorage 接口定义了 DDL（如 ALTER、RENAME、OPTIMIZE 和 DROP 等）、read 和 write 方法，它们分别负责数据的定义、查询与写入。在数据查询时，IStorage 负责根据 AST 查询语句的指示要求，返回指定列的原始数据。后续对数据的进一步加工、计算和过滤则会统一交由 Interpreter 解释器对象处理。对 Table 发起的一次操作通常都会经历这样的过程，接收 AST 查询语句、根据 AST 返回指定列的数据，之后再将数据交给 Interpreter 做进一步处理。

Parser 和 Interpreter

Parser 和 Interpreter 是非常重要的两组接口：Parser 分析器负责创建 AST 对象；而 Interpreter 解释器对象则负责解释 AST，并进一步创建查询的执行管道，它们与 IStorage 一起，串联起了整个数据查询的过程。

Parser 分析器可以将一条 SQL 语句以递归下降的方法解析成 AST（抽象语法树），不同的 SQL 语句会交给不同的 Parser 实现类来解析。例如，有负责解析 DDL 查询语句的 ParserRenameQuery、ParserDropQuery 和 ParserAlterQuery 解析器，还有负责解析 INSERT 语句的 ParserInsertQuery 解析器，还有负责 SELECT 语句的 ParserSelectQuery 等等。所以尽管 SQL 语句最终都会被解析成 AST，但不同的 SQL 语句会交给不同的 Parser 实现类进行解析

Interpreter 解释器的作用域就像 Service 服务器一样，起到串联整个查询过程的作用，它会根据解释器的类型，聚合它所需要的资源。首先它会解析 AST 对象，然后执行 “业务逻辑”（例如分支判断、设置参数、调用接口等）；最终返回 IBlock 对象，以线程的形式建立起一个查询执行管道。

img

Functions 与 Aggregate Functions

ClickHouse 主要提供两类函数：普通函数和聚合函数，普通函数由 IFunction 接口定义，拥有数十种函数实现，例如 FunctionFormatDataTime、FunctionSubstring 等。除了一些常见的函数（诸如四则运算、日期转换）之外，也不乏一些非常使用的函数，例如网址提取函数、IP 地址脱敏函数等。普通函数是没有状态的，函数效果作用于每行数据之上。当然，在函数具体执行的过程中，并不会一行一行的运算，而是采用向量化执行的方式直接作用于一整列数据。

聚合函数由 IAggregateFunction 接口定义，相比无状态的普通函数，聚合函数是有状态的。以 COUNT 聚合函数为例，其 AggregateFunctionCount 的状态使用整型UInt64记录。聚合函数的状态支持序列化和反序列化，所以能够在分布式节点直接进行传输，以实现增量计算。

Cluster 与 Replication

ClickHouse 的集群由分片（Shard）组成，而每个分片又通过副本（Replica）组成，这种分层的概念，在一些流行的分布式系统中非常普遍。例如，在 Elasticsearch 中，一个索引由分片和副本组成，副本可以看做是一种特殊的分片，如果一个索引由 5 个分片组成，副本的基数是 1，那么这个索引一共会拥有 10 个分片（每 1 个分片对应 1 个副本）。

而如果你使用同样的方式来理解 ClickHouse 的分片，那么很可能会栽一个跟头，ClickHouse 的某些设计总是显得独树一帜，而集群与分片便是其中之一。这里有几个与众不同的特性：

  • 1. ClickHouse 的一个节点只能有 1 个分片，也就是说如果要实现 1 分片、1 副本，则至少需要两个服务节点
  • 2. 分片只是一个逻辑概念，其物理承载还是要由副本来承担的

我们来看一下 ClickHouse 的集群配置，这里将会在后面详细说，目前先看看有个印象即可。

1
2
3
4
5
6
7
8
<ch_cluster>
	<shard>
    	<replica>
        	<host>47.94.174.89</host>
            <port>9000</port>
        </replica>
    </shard>
</ch_cluster>

如果从字面含义上来理解的话，可以认为是自定义集群 ch_cluster 拥有一个 shard（分片）和一个replica（副本），且该副本由 47.94.174.89 服务节点承载。

但是从本质上来理解的话，1 分片、1 副本的配置在 ClickHouse 中只有 1 个物理副本，所以它的正确语义应该是 1 分片、0 副本。分片更像是逻辑层的分组，在物理存储层面则统一使用副本来代表 “分片和副本”。所以如果想真正表示 1 分片、1 副本语义的配置，应该改为 1 个分片和 2 个副本，配置可以改为如下：

1
2
3
4
5
6
7
8
9
10
11
12
<ch_cluster>
	<shard>
    	<replica>
        	<host>47.94.174.89</host>
            <port>9000</port>
        </replica>
        <replica>
        	<host>47.93.39.238</host>
            <port>9000</port>
        </replica>
    </shard>
</ch_cluster>

以上就是 ClickHouse 的架构设计，这些内容感觉有点枯燥甚至不好理解，下面就来安装 ClickHouse，进入实际操作环节。

ClickHouse 的安装以及连接工具

相较于 Hadoop 生态中的一些系统，ClickHouse 的安装显得尤为简单，因为它自成一体，在单节点的情况下不需要额外的依赖，集群的话后面会说。

ClickHouse 支持运行在主流 64 位 CPU 架构的 Linux 操作系统上，可以通过源码编译、预编译压缩包、Docker 镜像和 RPM 等多种方法进行安装。这里我们着重介绍一下离线 RPM 的安装方法，因为它最常用。

先介绍一下环境，我们使用的操作系统为 CentOS 7，是我在阿里云上的服务器，而 ClickHouse 我们选择 21.7.3.14 版本，一个非常新的版本。

1. 下载 RPM 安装包

用于安装的 RPM 包可以从仓库 https://repo.yandex.ru/clickhouse/rpm/stable/x86_64/ 中进行下载，里面包含了所有版本的 ClickHouse。

我们需要下载以下四个安装包文件：

1
2
3
4
clickhouse-client-21.7.3.14-2.noarch.rpm
clickhouse-common-static-21.7.3.14-2.x86_64.rpm
clickhouse-common-static-dbg-21.7.3.14-2.x86_64.rpm
clickhouse-server-21.7.3.14-2.noarch.rpm

2. 关闭防火墙并检查环境依赖

首先，考虑到后续的集群部署，通常建议关闭本机的防火墙，在 CentOS 7 中关闭防火墙的方法如下：

1
2
3
4
# 关闭防火墙
systemctl stop firewalld.service
# 禁用开机启动项
systemctl disable firewalld.service

接着需要验证当前服务器的 CPU 是否支持 SSE 4.2 指令集，因为向量化执行需要用到这项特性：

1
grep -q sse4_2 /proc/cpuinfo && echo "支持 SSE 4.2 指令集" || echo "不支持 SSE 4.2 指令集"

img

如果不支持 SSE 指令集，则不能使用上面下载的 RPM 安装包，而是需要使用源码编译的方式安装，当然现在的 CPU 基本上都是支持的。

3. 安装 ClickHouse

我们将上面下载地 RPM 包上传到服务器，然后进行安装。

1
2
3
# 使用通配符，会将当前目录下所有的 rpm 包全部依次安装，非常方便
# 因为我们是安装 ClickHouse，所以该目录除了 ClickHouse 的 rpm 包之外，最好不要有其它的 rpm 包
rpm -ivh ./*.rpm

注意，在安装到 clickhouse-server 的时候会提示你设置密码：

img

因为 ClickHouse 在安装的时候会有一个默认的 default 用户，这里会提示你给 default 设置密码，因为 ClickHouse 和 MySQL、PostgreSQL 等数据库一样，也具有用户管理权限。老版本默认没有密码，新版本会让你主动设置，这里我们就不设置了，直接回车就好，这样后续在连接的时候就不需要密码了。

最后，如果想卸载 ClickHouse 也很简单，至于以下几步：

1
2
3
4
yum remove clickhouse-client clickhouse-common-static clickhouse-common-static-dbg clickhouse-server -y
rm -rf /var/lib/clickhouse
rm -rf /etc/clickhouse-*
rm -rf /var/log/clickhouse-server

目录结构

程序在安装的时候会自动构建整套目录结构，接下来分别说明它们的作用。

1) 首先是核心目录部分

/etc/clickhouse-server：服务端的配置文件目录, 包括全局配置 config.xml 和用户配置 users.xml 等。

img

/var/lib/clickhouse：默认的数据存储目录（通常会修改默认存储路径，将数据保存到大容量磁盘挂载的路径），通过 config.xml 进行修改。

/var/log/clickhouse-server：默认保存日志的目录（通常会修改默认存储路径，将日志保存到大容量磁盘挂载的路径），通过 config.xml 进行修改。

2) 接下来是配置文件部分

/etc/security/limits.d/clickhouse.conf：文件句柄数量的配置，默认值如下所示：

1
2
3
4
[root@satori ~]# cat /etc/security/limits.d/clickhouse.conf
clickhouse	soft	nofile	262144
clickhouse	hard	nofile	262144
[root@satori ~]#

该配置也可以通过 config.xml 中的 max_open_files 参数指定。

/etc/cron.d/clickhouse-server：cron 定时任务配置, 用于恢复因异常原因中断的 ClickHouse 服务进程, 其默认的配置如下所示：

1
2
3
[root@satori ~]# cat /etc/cron.d/clickhouse-server
#*/10 * * * * root ((which service > /dev/null 2>&1 && (service clickhouse-server condstart ||:)) || /etc/init.d/clickhouse-server condstart) > /dev/null 2>&1
[root@satori ~]#

可以看到默认情况，每隔 10 秒就会使用 condstart 尝试启动一次 ClickHouse 服务，如果 ClickHouse 服务正在运行，则跳过；如果没有运行，则启动。

3) 最后是在 /usr/bin 目录下的启动文件

ClickHouse 相关的启动文件都位于 /usr/bin 目录下。

img

可执行文件数量还是蛮多的，其中四个最常用。

  • clickhouse: 主程序的可执行文件
  • clickhouse-client: 一个指向 ClickHouse 可执行文件的软连接, 供客户端连接使用
  • clickhouse-server: 一个指向 ClickHouse 可执行文件的软连接, 供服务端启动使用
  • clickhouse-compressor: 内置提供的压缩工具, 可用于数据的正压反解

启动命令

ClickHouse 给我们提供了非常优雅的启动方式。

  • 启动 ClickHouse：clickhouse start
  • 关闭 ClickHouse：clickhouse stop
  • 重启 ClickHouse：clickhouse restart

注意：在安装 ClickHouse 的时候，系统会自动创建一个名为 clickhouse 的用户，启动脚本会基于此用户来启动服务。因此我们需要将 clickhouse 用户具备相关目录的权限，如果不赋权限，ClickHouse 可能会启动失败。

1
2
3
chown clickhouse.clickhouse /var/log/clickhouse-server/ -R 
chown clickhouse.clickhouse /var/lib/clickhouse/ -R 
# 如果后续你修改了配置文件，改变了 ClickHouse 的数据存储目录，那么也要记得赋给它相应的权限

另外，上面通过 clickhouse start 启动的时候我们没有指定配置文件，没错，通过这种方式启动的话，会自动加载 /etc/clickhouse-server/config.xml。

但如果我们想手动指定配置文件的话，那么需要使用 clickhouse-server。

1
clickhouse-server --config-file /etc/clickhouse-server/config.xml --daemon

–config-file 负责指定配置文件，这样即使将配置文件放在了别的地方也没有关系，因为我们可以显式地指定它的位置；–daemon 表示后台启动，因为默认是前台启动的。

但是注意：使用 clickhouse-server 启动的话，不能使用 root，需要切换到 clickhouse 用户，所以我们应该这么做。

1
sudo -u clickhouse clickhouse-server --config-file /etc/clickhouse-server/config.xml --daemon

注意：sudo -u 后面的 clickhouse 指的是名为 clickhouse 的用户，clickhouse start 里面的 clickhouse 指的是 /usr/bin 里面的可执行文件。这里由于我们配置文件就在默认路径下，所以也可以直接使用 clickhouse start 启动，默认加载 /etc/clickhouse-server/config.xml、并且后台启动。至于关闭的话，直接 clickhouse stop 即可。

客户端的访问接口

ClickHouse 服务端的底层访问接口支持 TCP 和 HTTP 两种方式，其中 TCP 拥有更好的性能，其默认监听 9000 端口，主要用于集群间的内部通信及 clickhouse-client 客户端进行连接；而 HTTP 协议则拥有更好的兼容性，可以通过 REST 服务的形式被广泛用于编程语言的客户端，其默认监听 8123 端口。

下面我们来介绍几种连接方式。

使用客户端 clickhouse-client 连接服务端

通过 clickhouse start 将服务启动之后，我们就可以通过客户端进行连接了，通过 clickhouse-client，默认会连接到本机的 9000 端口，并使用 default 用户，如果想单独指定的话可使用如下方式：

1
clickhouse-client --host 地址 --port 端口 --user 用户 --password 密码

这里我们的服务端默认也是监听 9000 端口，并且 default 用户还没有密码，所以直接输入 clickhouse-client 即可连接上。

img

我们看到连接成功，并且也查询成功了，我们需要注意一下图中 show databases 前面的提示内容，很明显它就是我们刚才设置的 FQDN。至此，单节点 ClickHouse 的安装就算完毕了，至于集群的搭建我们后面会说。

插句题外话，如果我们想要更新 ClickHouse，那么直接下载新版的 ClickHouse RPM 包即可，然后进行更新：

1
rpm -Uvh ./*.rpm

升级的时候，原有的配置均会保留。

然后我们再来聊一下 clickhouse-client，我们上面通过输入 clickhouse-client 进入命令行、然后再执行 SQL 的方式叫做 “交互式执行”，一般用于调试、运维、开发和测试等场景。

通过交互式执行的 SQL 语句，相关查询结果会统一记录到 ~/.clickhouse-client-history 文件中，可以作为审计之用。

img

但除了交互式执行之外，还有非交互式执行。非交互式执行主要用于批处理场景，诸如对数据的导入和导出操作，在执行脚本命令时，需要追加 –query 参数指定执行的 SQL 语句。举个栗子：

1
cat xxx.csv | clickhouse-client --query "INSERT INTO some_table FORMAT CSV"

在导入数据时，它可以接收操作系统的 stdin 标准输入作为写入的数据。所以 cat 命令读取的文件流，将会作为 INSERT 查询的数据输入，而在数据导出时，则可以输出流重定向到文件：

1
clickhouse-client --query "SELECT * FROM some_table" >> xxx.csv

默认情况下，clickhouse-client 一次只能运行一条 SQL 语句，如果需要执行多次查询，则需要在循环中重复执行，这显然不是一种高效的方式。此时可以追加 –multiquery 参数，它可以支持一次运行多条SQL查询，多条查询之间使用分号分隔，比如：

img

多条 SQL 的查询结果集会依次按照顺序返回。

以上就是 clickhouse-client 的两种运行方式，由于提供了非交互式执行的功能，所以 ClickHouse 的客户端比其它数据库的客户端要强大一些。下面整理一下 clickhouse-client 常用的相关参数：

  • --host/-h: 指定连接的服务端的地址, 默认是 localhost，如果服务端的地址不是 localhost, 则需要依靠此参数进行指定, 例如 clickhouse-client -h xx.xx.xx.xx
  • --port: 服务端的 TCP 端口, 默认是 9000，如果服务端监听的不是 9000, 则需要此参数指定
  • --user/-u: 登录的用户名, 默认是 default。如果使用非 default 的用户名登录, 则需要使用此参数指定
  • --password: 登录的密码, 默认值为空。如果在用户定义中未设置密码, 则无需填写（比如默认的 default 用户，我们没有设置密码）
  • --database/-d: 登录之后所在的数据库, 默认为 default
  • --query/-q: 只能在非交互式查询时使用, 用于执行指定的 SQL 语句
  • --multiquery/-n: 在非交互式执行时, 允许一次运行多条 SQL 语句, 多条语句之间用分号隔开
  • --time/-t: 在非交互式执行时, 会打印每条 SQL 的执行时间

更多参数可以通过 clickhouse-client –help 查看，数量多到恐怖。

Python 连接 ClickHouse 服务端

首先 ClickHouse 支持使用 JDBC 连接，但我本身不是 JAVA 方向的，所以这里只介绍使用 Python 连接 ClickHouse 的方式。

Python 连接 ClickHouse 的话需要安装一个第三方库，直接 pip install clickhouse-driver 即可。

注意：我们说 HTTP 协议使用的是 8123 端口，但是 Python 这个包比较特殊，它和 clickhouse-client 一样，使用的也是 TCP 协议，也就是说端口需要指定为 9000。

img

使用 Python 是可以连接的，但是注意：我们这里是在服务器上使用 Python 连接的，如果需要在其它机器上连接的话，那么就不能使用 localhost 了。

1
2
3
4
5
from clickhouse_driver import Client

# 需要指定具体的 ip
client = Client(host="47.94.174.89", port=9000)
print(client.execute("show databases"))

不过此时仍无法在其它节点上访问，因为我们还需要修改一下服务端的配置，vim /etc/clickhouse-server/config.xml：

img

listen_host 这个标签默认是被注释掉的，也就是只监听来自本机的请求。这里我们将注释打开，或者不管注释，直接手动增加一条。

1
2
<!-- 改成 0.0.0.0，这样即可接收来自其它机器上的请求 -->
<listen_host>0.0.0.0</listen_host>

此时 Python 即可在其它节点上访问了，注意：服务器的 9000 端口是要对外开放的，这里我阿里云服务器的 9000、8123 端口都已经对外了。

img

此外我们还可以通过 sqlalchemy 去连接，但是默认情况下 sqlalchemy 找不到对应的 dialect，我们需要再安装一个模块：pip install sqlalchemy_clickhouse，安装之后就可以使用了。

但是有一点需要注意：使用 sqlalchemy_clickhouse 的话，那么连接的端口就不能是 9000 了，而是 8123。更准确的说，需要使用 HTTP 端口。

img

以上就是 Python 连接 ClickHouse 的两种方式，还是挺容易的。

DataGrip 连接 ClickHouse 服务端

DataGrip 是 JetBrains 公司开发的一个 IDE，专门负责连接数据库，其中也包含了对 ClickHouse 的支持。

img

点击之后下载相应的驱动，然后输入相关信息即可。

img

我们看到连接成功，里面还显示了 ClickHouse 支持的内置函数。然后我们执行 SQL 语句测试一下：

img

内置的实用工具

我们说 /usr/bin 下面包含了很多关于 ClickHouse 的启动文件，除了之前介绍的四个，这里再介绍两个，分别是 clickhouse-local 和 clickhouse-benchmark。

clickhouse-local

clickhouse-local 可以独立运行大部分的 SQL 查询，不需要依赖任何 ClickHouse 服务端程序，它可以理解为 ClickHouse 服务的单机版内核，是一个轻量级的应用程序。clickhouse-local 只能够使用 File 引擎（或者称之为表引擎），关于引擎后面会展开。它的数据与同机运行的 ClickHouse 服务之间也是完全隔离的，互相并不能访问。

clickhouse-local 是非交互式的，每次执行都需要指定数据来源，例如通过 stdin 标准输入，以 echo 打印作为数据来源：

img

也可以借助操作系统的命令，实现对系统用户内存用量的查询。

img

clickhouse-local 的参数用法可以通过 –help 查看，但是个人觉得不是很常用。

clickhouse-benchmark

clickhouse-benchmark 是基准测试的小工具，它可以自动运行 SQL 查询，并生成对应的运行指标报告，例如执行下面的语句启动测试：

1
echo "SELECT * FROM table" | clickhouse-benchmark -i 5

执行之后，按照指定参数的查询会被执行 5 次。执行完毕之后，会显示包含 QPS、RPS 等指标信息的报告，还会列出各百分位的查询执行时间。

如果想测试多条 SQL，此时就需要将 SQL 写在文件中，然后通过 clickhouse-benchmark -i 5 < 文件路径，将里面的 SQL 按照顺序依次执行。

这里我就不使用具体的数据测试了，有兴趣可以自己尝试一下。

clickhouse-benchmark 的一些核心参数可以通过 –help 查看。

以上我们介绍了基于离线 RPM 包安装 ClickHouse 的整个过程，当然也可以使用其它方式安装，比如：在线安装、或者使用 docker 等等。事实上，这种离线安装的方式也不麻烦，相反个人觉得还很简单。然后还介绍了访问 ClickHouse 的两个接口，TCP 接口和 HTTP 接口，以及如何使用 Python 去访问。那么就来学习 ClickHouse 的具体语法了，首先会从数据定义开始。

​ 本文来源： (https://www.cnblogs.com/traditional/p/15218595.html)