ClickHouse 单机搭建记录

最近需要 OLAP 场景验证，先搭建 ClickHouse 单机环境测试，整体部署难度不高，最容易踩坑的是端口冲突问题。使用一份卡口过车数据集在多款引擎上执行相同查询做对比，记录实操过程与使用感受。

一、下载和安装

安装包从官方 RPM 源获取：https://packages.clickhouse.com/rpm/stable/ 本次选用 23.2.1 版本，三个 RPM 包按顺序安装：

复制代码

rpm -ivh clickhouse-common-static-23.2.1.2537.x86_64.rpm
rpm -ivh clickhouse-server-23.2.1.2537.x86_64.rpm
rpm -ivh clickhouse-client-23.2.1.2537.x86_64.rpm

说明：common-static 是核心依赖，必须优先安装；server 和 client 安装顺序无要求。

二、修改配置文件

配置文件路径：/etc/clickhouse-server/config.xml，修改两处核心配置：

复制代码

<!-- 默认9000端口容易和HDFS NameNode冲突，修改为9001 -->
<tcp_port>9001</tcp_port>

<!-- 默认仅本地访问，放开监听允许外部连接 -->
<listen_host>0.0.0.0</listen_host>

避坑提示：服务器部署了 Hadoop 时，9000 端口大概率被占用，启动前执行 netstat -tlnp | grep 9000 检查端口占用。

三、服务启动

复制代码

systemctl start clickhouse-server

日常调试常用命令：

复制代码

systemctl restart clickhouse-server
systemctl status clickhouse-server

启动报错排查：日志默认存放路径 /var/log/clickhouse-server/，服务异常优先查看日志。

四、客户端连接与基础测试

端口改为9001，连接时手动指定端口，-m 开启多行模式，适合执行长建表语句：

复制代码

clickhouse-client --port 9001 -m

基础建库建表插入测试SQL：

复制代码

CREATE DATABASE IF NOT EXISTS helloworld;

CREATE TABLE helloworld.my_first_table
(
    user_id UInt32,
    message String,
    timestamp DateTime,
    metric Float32
)
ENGINE = MergeTree()
PRIMARY KEY (user_id, timestamp);

INSERT INTO helloworld.my_first_table (user_id, message, timestamp, metric) VALUES
    (101, 'Hello, ClickHouse!',                                 now(),       -1.0    ),
    (102, 'Insert a lot of rows per batch',                     yesterday(), 1.41421 ),
    (102, 'Sort your data based on your commonly-used queries', today(),     2.718   ),
    (101, 'Granules are the smallest chunks of data read',      now() + 5,   3.14159 );

关键点：ClickHouse 建表必须指定引擎；MergeTree 为核心引擎，ORDER BY（老版本 PRIMARY KEY）决定磁盘数据排序，直接决定查询时的数据裁剪能力。

五、多引擎对比测试

测试数据集：卡口过车数据

字段	说明
plate_number	车牌号
gateway_id	卡口编号
city	卡口所在城市
car_brand	车辆品牌
road_id	道路编号
speed	车辆速度
travel_direction	行驶方向

测试查询类型：车牌点查 、按车辆品牌分组聚合统计

MySQL

标准建表语句，使用 LOAD DATA LOCAL INFILE 导入数据。

无索引按车牌查询：全表扫描，大数据量性能差；
plate_number 建立索引：点查速度提升明显；
给 car_brand 单独建索引：group by 聚合提升有限。

小结：B+树索引擅长等值、范围点查，对分组聚合支持弱。适合小表、实时点查场景，不适合大规模分析。

Hive

常规建表方式，ROW FORMAT DELIMITED + STORED AS TEXTFILE，表 LOCATION 指向 HDFS 数据目录。 SQL 语法兼容 MySQL，但底层依赖 MapReduce/Tez，查询延迟达到分钟级。适合离线大批量分析，无法支撑实时查询。

ClickHouse

测试表建表语句：

复制代码

create table gateway_records(
    plate_number String comment '车牌号',
    gateway_id  String comment '卡口编号',
    city String comment '卡口所在城市',
    car_brand String comment '车辆品牌',
    road_id String comment '道路编号',
    speed Float32 comment '车辆速度',
    travel_direction String comment '车辆行驶方向'
)ENGINE = MergeTree()
order by(gateway_id);

CSV 数据导入命令：

复制代码

clickhouse-client --port 9001 --password 123456 --format_csv_delimiter="," --query="INSERT INTO gateway_records FORMAT CSV" < gateway_records.txt

点查、分组聚合性能优势显著。底层数据存储目录 /var/lib/clickhouse，数据按分区、part 组织，列式存储 + MergeTree 有序数据块是高性能核心。

Doris

建表需要指定分桶策略：

复制代码

DISTRIBUTED BY HASH(city) BUCKETS 6
PROPERTIES ("replication_num" = "1");

导入方式使用 LOAD DATA LOCAL INFILE。查询体验和 ClickHouse 相近，面向分析场景设计；索引对点查优化明显，聚合提速主要依靠列存与向量化执行，而非索引。适合分布式 OLAP 场景。

六、总结感受

相同数据集、相同SQL在四款引擎表现差异，贴合各自产品定位：

MySQL：优先小表、实时点查场景，索引依赖强，不适合分析；
Hive：离线批处理，吞吐高，查询延迟高；
ClickHouse：单表聚合分析能力突出，MergeTree 排序键是核心，单机上手简单；
Doris：OLAP 定位和 ClickHouse 接近，原生分布式，需要设计分桶。

ClickHouse 单机部署门槛低，改好端口即可快速验证；短板是复杂多表 Join 场景表现一般，后续再做相关测试。本次搭建主要踩坑点集中在端口冲突，记录留存备查。