在我负责的日志平台改造项目中，每天采集和分析来自上百台应用服务器的结构化日志数据，峰值写入吞吐量超过每秒 500,000 条日志，查询响应需要在秒级内完成。传统 ELK（Elasticsearch + Logstash + Kibana）架构在高并发写入与复杂聚合查询下响应缓慢，存储成本也不断攀升。

在对多个 OLAP 引擎评估后，A5数据最终选择基于 ClickHouse 构建自研分布式日志分析平台。在 CentOS 8 环境下，从单节点性能调优，到跨机房分布式部署及容错设计，我和团队逐步沉淀出一套系统的实践方案。本篇文章围绕这一真实项目展开，详述架构设计、配置方法、调优步骤及性能评测。

---

一、核心需求与架构设计

1.1 关键业务需求

需求项	说明
单日日志写入量	~15 亿条
峰值写入吞吐量	> 500,000 条/秒
查询响应时延	< 3 秒（Top-K、时间范围聚合）
数据保留周期	30 天活跃分析 + 365 天归档
高可用	可容忍节点或机房故障
监控与报警	实时告警写入延迟与查询错误

1.2 集群拓扑

为了满足高可用与快速查询，我们采用如下 分布式 + 复制 + 分片 结构：

• 3 个机架/机房：分别承担不同分片与副本

• 每个机架 3 节点 ClickHouse Server

  • 每个逻辑分片由 3 个副本组成

• ZooKeeper 集群（3 节点）

  • 提供分布式元数据协调：复制队列、分布式锁

拓扑示意：

          +--------------------+
          |    ZooKeeper 3PC   |
          +--------------------+

Cluster: logs_cluster
Shard1: CH1-A, CH1-B, CH1-C
Shard2: CH2-A, CH2-B, CH2-C
Shard3: CH3-A, CH3-B, CH3-C

---

二、环境与香港服务器www.a5idc.com硬件配置建议

为了充分发挥 ClickHouse 数据写入与压缩能力，以下是我们在一期部署中的真实配置。

2.1 CentOS 8 基础环境

项	配置
系统	CentOS Linux 8.6
SELinux	Disabled
Firewall	Disabled (改由统一防火墙管理)
内核参数优化	iommu=pt intel_iommu=off 无虚拟内存干扰

2.2 单节点硬件规格

资源类型	规格
CPU	Intel Xeon Gold 6248 (20C/40T) @2.5GHz
内存	256 GB DDR4 ECC
主存储	NVMe SSD 2TB × 2 (RAID 1)
日志存储	SATA SSD 4TB × 4 (RAID 10)
网络	Dual 25 Gbps IPSec/Private
ZooKeeper	3 节点专用机，每台 64GB 内存

2.3 I/O 调优建议（真实生产值）

# 优化 I/O 调度
echo noop > /sys/block/nvme0n1/queue/scheduler
echo 4096 > /sys/block/nvme0n1/queue/nr_requests

# 调整文件句柄
ulimit -n 2000000

---

三、ClickHouse 安装与初始配置

3.1 安装 YUM 源与软件

sudo rpm --import https://packages.clickhouse.com/rpm/clickhouse-signing-key.asc

cat <<EOF | sudo tee /etc/yum.repos.d/clickhouse.repo
[clickhouse]
name=ClickHouse Repository
baseurl=https://packages.clickhouse.com/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://packages.clickhouse.com/rpm/clickhouse-signing-key.asc
EOF

sudo yum install -y clickhouse-server clickhouse-client

3.2 基础配置调整（/etc/clickhouse-server/config.xml）

核心参数：

<!-- 数据目录 -->
<path>/var/lib/clickhouse/</path>
<tmp_path>/var/lib/clickhouse/tmp/</tmp_path>

<!-- 网络设置 -->
<listen_host>::</listen_host>
<tcp_port>9000</tcp_port>
<http_port>8123</http_port>

<!-- ZooKeeper 集群配置 -->
<zookeeper>
    <node index="1">
        <host>zk1.example.com</host>
        <port>2181</port>
    </node>
    <node index="2">
        <host>zk2.example.com</host>
        <port>2181</port>
    </node>
    <node index="3">
        <host>zk3.example.com</host>
        <port>2181</port>
    </node>
</zookeeper>

注意：

• 强烈建议使用独立 ZK 集群
• 主数据路径与临时路径分离，有助于避免临时写膨胀

---

四、构建分布式集群

4.1 定义集群拓扑（users.xml）

<remote_servers>
    <logs_cluster>
        <shard>
            <replica>
                <host>ch1-a.example.com</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>ch1-b.example.com</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>ch1-c.example.com</host>
                <port>9000</port>
            </replica>
        </shard>
        <shard>
            <replica>...</replica>
            <replica>...</replica>
            <replica>...</replica>
        </shard>
        <shard>
            ...
        </shard>
    </logs_cluster>
</remote_servers>

4.2 创建基础表结构（MergeTree + Distributed）

本地物理表

CREATE TABLE logs_local
(
    event_date Date,
    event_time DateTime,
    host String,
    service String,
    level String,
    message String,
    INDEX idx_event_time (event_time) TYPE minmax GRANULARITY 3
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/logs_local', '{replica}')
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_time, host, service);

分布式逻辑表

CREATE TABLE logs_dist
(
    event_date Date,
    event_time DateTime,
    host String,
    service String,
    level String,
    message String
)
ENGINE = Distributed(logs_cluster, default, logs_local, event_time);

---

五、写入与查询性能调优

5.1 写入优化

批量写入建议

使用大小合适的批次写入（例如 10,000 行/批），可降低网络开销与 MergeTree 的碎片化。

# 示例 Python 批量插入
from clickhouse_driver import Client

client = Client('logs-proxy.example.com')
batch = []
for record in stream_log():
    batch.append(record)
    if len(batch) >= 10000:
        client.execute('INSERT INTO logs_dist VALUES', batch)
        batch.clear()

压缩配置（config.xml）

将压缩策略调整为 LZ4 或 ZSTD，可在写入性能与存储消耗之间获得平衡。

<compression>
    <method>zstd</method>
</compression>

---

5.2 查询优化

最佳排序键设计

ORDER BY 中放置高基数字段可提升分区剪裁效率，例如：

ORDER BY (event_date, event_time, service)

SQL 示例：Top 10 服务的错误率

SELECT service,
       countIf(level='ERROR') AS errors,
       count() AS total,
       round(errors/total, 4) AS error_rate
FROM logs_dist
WHERE event_time BETWEEN now() - INTERVAL 1 HOUR AND now()
GROUP BY service
ORDER BY error_rate DESC
LIMIT 10;

---

六、性能基准与评测

在完整流水线部署后，我们使用自制基准工具对比不同配置的性能。下面是 写入与查询吞吐量对比：

配置方案	平均写入 TPS	查询（TopK）延迟 95%
默认 MergeTree	150,000	7.2s
调整分区/键 + Replica	380,000	3.4s
NVMe + 多线程应用写入	520,000	2.8s

评测说明：

• 每组测试采样 30 分钟日志流
• 查询延迟为 95% 百分位响应

---

七、监控与告警

7.1 系统监控

• CPU / Memory / Disk I/O：使用 Prometheus + Node Exporter
• ClickHouse 监控：clickhouse_exporter

7.2 关键监控指标

指标	告警阈值
Write Pending Tasks	> 1000
Query Time (95%)	> 5 秒
Merge Queue	> 500 次
ClickHouse OOM	频发

7.3 PromQL 示例

查询 ClickHouse CPU 使用：

avg by (instance) (rate(process_cpu_seconds_total{job="clickhouse"}[1m]))

---

八、常见问题与优化建议

8.1 内存与线程配置

在 users.xml 中：

<max_threads>40</max_threads>
<max_memory_usage>150000000000</max_memory_usage>
<table_function_remote_max_connections>15</table_function_remote_max_connections>

建议：

• max_threads 不宜与 CPU 线程数一致，上限控制在 70% 以内
• 为写入和查询分别设限，以防资源抢占

8.2 网络与延迟优化

• 私有网络优先，避免跨机房直连
• TCP KeepAlive 与窗口调优：

sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864

---

九、总结

A5数据通过合理的硬件选型、分布式架构设计、ZooKeeper 协调、精细的 MergeTree 表设计、写入与查询路径调优，以及完善的监控告警体系，我们在 CentOS 8 上构建了一个 高性能、稳定、可扩展的 ClickHouse 分布式日志分析平台。在实践中，该平台已经成功支撑千万级别日志写入与秒级聚合查询，显著提升了实时日志分析能力。

如果你正在规划 ClickHouse 在生产环境的部署与优化，不妨沿用本文的架构设计、调优方法与评测指标，结合自身业务特点继续深入调整。