硬件与操作系统选型：打好地基才能盖高楼
各位同学，咱们直接进入正题。做金融级ClickHouse集群，硬件和操作系统选型就是地基。地基没打好，后面再怎么优化也白搭。我见过太多团队，上来就买最贵的服务器，结果跑起来各种瓶颈。说白了，钱要花在刀刃上。
核心原则：ClickHouse是CPU密集型和IO密集型应用。它吃CPU、吃内存、吃磁盘吞吐，但对网络延迟没那么敏感（相比OLTP数据库）。
服务器硬件推荐
CPU：核多才是王道
ClickHouse的并行处理能力非常强。它能充分利用多核CPU。我个人习惯，单机至少32核起步，64核是主流配置。金融场景下，我建议直接上64核以上。
为什么会这样？因为ClickHouse的每个查询都会尽量打满所有CPU核心。你想想看，一个聚合查询，如果只有8核，那它只能同时处理8个数据块。但如果是64核，那就是64个数据块并行处理。差距是几何级的。
我在项目中遇到过，某券商用48核服务器跑实时风控查询，高峰期CPU直接飙到95%。后来换成64核，同样的查询，CPU只用了60%。嗯，这里要注意，别只看主频。ClickHouse更吃核心数，而不是单核频率。高频当然好，但性价比不高。
| 场景 | 推荐CPU | 核心数 | 备注 |
|---|---|---|---|
| 开发测试 | Intel Xeon Silver | 16-32核 | 够用就行 |
| 生产环境 | Intel Xeon Gold | 32-64核 | 主流选择 |
| 金融核心 | Intel Xeon Platinum / AMD EPYC | 64-128核 | 高并发必备 |
小技巧：AMD EPYC的性价比很高，核心数多，内存通道也多。我最近几个金融项目都用的EPYC，表现很稳。
内存：越大越好，但别浪费
ClickHouse的内存消耗主要来自三块：数据缓存、查询中间结果、以及MergeTree的合并操作。我建议至少256GB起步，512GB是标配。金融场景下，1TB也不嫌多。
你可能会问，为什么需要这么大？因为ClickHouse的查询速度，很大程度上取决于数据是否在内存中。如果内存不够，数据就要从磁盘读，那速度就掉下来了。说白了，内存就是ClickHouse的加速器。
我曾经帮一家银行做性能调优，他们128GB内存，跑一个月的交易数据，查询要3秒。后来加到512GB，同样的查询，0.3秒就出结果了。嗯，这就是内存的威力。
注意：内存频率也很重要。尽量选DDR4 3200MHz或DDR5 4800MHz以上的。低频内存会拖慢CPU的吞吐。
磁盘：NVMe SSD是唯一选择
这个没什么好说的。金融级ClickHouse，磁盘必须用NVMe SSD。SATA SSD？别想了，IOPS差一个数量级。HDD？那是给归档数据用的。
ClickHouse的写入是顺序写，读取是随机读。NVMe SSD的随机读性能，是SATA SSD的5-10倍。你想想看，如果查询要扫描大量数据，磁盘就是最大的瓶颈。
我建议至少2块NVMe SSD做RAID 0。为什么不做RAID 1？因为ClickHouse本身有副本机制，数据安全由副本保证，不需要磁盘层做冗余。RAID 0能最大化吞吐。
| 磁盘类型 | 随机读IOPS | 顺序写MB/s | 推荐场景 |
|---|---|---|---|
| NVMe SSD | 500K-1M | 3000-7000 | 生产环境 |
| SATA SSD | 50K-100K | 500-600 | 开发测试 |
| HDD | 100-200 | 150-250 | 冷数据归档 |
网络：万兆起步，25G是主流
ClickHouse的节点间通信，主要是数据复制和分布式查询。虽然不像OLTP那么敏感，但也不能太差。我建议至少万兆（10GbE），25GbE是主流配置。
为什么？因为数据复制时，如果网络带宽不够，就会拖慢写入速度。我记得有个项目，客户用千兆网络，3个节点做复制，写入速度死活上不去。后来换成万兆，问题立刻解决。
金融场景下，我建议用25GbE或100GbE。特别是做多活部署时，网络延迟和带宽都很关键。
操作系统优化
硬件选好了，操作系统也得调优。默认配置是给通用场景用的，跑ClickHouse必须改。
内核参数
这里我列几个最关键的参数。你直接照着改就行。
# /etc/sysctl.conf 添加以下内容
# 最大文件句柄数，ClickHouse会打开大量文件
fs.file-max = 1000000
# 网络优化
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# 虚拟内存，减少swap使用
vm.swappiness = 1
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
# 大页内存，减少TLB miss
vm.nr_hugepages = 1024为什么要调这些？我一个个说。
- fs.file-max：ClickHouse每个分区都会打开文件，数据量大时，文件句柄数轻松破万。默认1024？根本不够用。
- net.core.somaxconn：高并发连接时，这个值决定了连接队列长度。太小会导致连接被拒绝。
- vm.swappiness：设为1，意思是尽量别用swap。ClickHouse用swap，性能直接崩。我见过有人没改这个，内存一紧张，查询慢了几十倍。
- vm.nr_hugepages：大页内存能提升内存访问效率。ClickHouse的MergeTree引擎很吃这个。
注意：改完参数后，记得执行 sysctl -p 生效。另外，大页内存需要系统预留，别设太大，否则其他进程可能申请不到内存。
文件系统：XFS是首选
ClickHouse官方推荐XFS。为什么？因为XFS对大文件、高并发IO的支持更好。ext4也能用，但性能不如XFS。
我建议挂载时加上这些参数：
# /etc/fstab 示例
/dev/nvme0n1 /data xfs defaults,noatime,nodiratime,allocsize=1m 0 0- noatime/nodiratime：关闭文件访问时间更新，减少IO开销。
- allocsize=1m：预分配1MB的块大小，减少文件碎片。
我曾经帮一个客户排查性能问题，发现他们的文件系统是ext4，而且没加noatime。每次查询都要更新atime，白白浪费了大量IO。改成XFS后，性能提升了15%。
NUMA绑定：别让CPU跨节点访问内存
NUMA架构下，CPU访问本地内存比远程内存快得多。如果不做绑定，ClickHouse的进程可能会被调度到跨NUMA节点的CPU上，导致内存访问延迟增加。
我建议用 numactl 绑定：
# 启动ClickHouse时绑定到NUMA节点0
numactl --cpunodebind=0 --membind=0 clickhouse-server --config-file=/etc/clickhouse-server/config.xml或者，更简单的做法，在BIOS里关闭NUMA（但我不推荐，因为会损失性能）。
嗯，这里要注意。如果服务器有多个NUMA节点，最好把ClickHouse绑定到一个节点上。如果数据量特别大，也可以考虑每个节点跑一个ClickHouse实例，分别绑定不同的NUMA节点。
我的经验：金融场景下，我一般用2个NUMA节点，每个节点跑一个ClickHouse实例。这样既能充分利用硬件，又能避免跨节点访问。
网络拓扑规划
网络拓扑这块，说白了就是怎么把服务器连起来。金融级部署，我建议用Spine-Leaf架构。
为什么？因为传统三层架构（接入-汇聚-核心）有带宽瓶颈。Spine-Leaf架构下，任何两台服务器之间的跳数都是固定的，延迟可控，带宽也能线性扩展。
具体规划时，我建议：
- Spine交换机：2台做冗余，用25GbE或100GbE上行。
- Leaf交换机：每台连接8-16台服务器，用10GbE或25GbE。
- 服务器：每台服务器双网卡绑定，分别连接到两台不同的Leaf交换机，实现高可用。
我记得有个项目，客户用了单台核心交换机，结果交换机故障，整个集群挂了3小时。后来改成Spine-Leaf架构，再也没出过类似问题。
总结一下：硬件选型，CPU核多、内存大、磁盘快、网络宽。操作系统调优，改内核参数、用XFS、绑NUMA。网络拓扑，Spine-Leaf架构最稳。这些做好了，ClickHouse集群才能跑得又快又稳。
好了，这一章就到这里。内容不少，但都是实战经验。你照着做，至少能避开80%的坑。