让数据分析跑在内存里：最高 1.5 TB

分布式系统每多一道节点边界，就要付出网络 Shuffle、协调和运维工作的代价。单台服务器最高可达 1.5 TB 内存和 192 个核心，许多原本需要一群小机器组成集群的分析负载，用一到两台大型节点就能承载。

• ClickHouse 纵向扩展能力出色：把全部核心交给它，并为热数据片段和缓存提供足够内存。
• DuckDB 以进程内方式在单节点上运行，大内存和高速 NVMe 能直接提升其性能。
• Spark 在单台大型节点上以本地模式运行，可完全避免网络 Shuffle；在小型集群中，每台主机运行多个 Executor。

双路的 Max 192 默认将内存划分为两个 NUMA 节点，每颗 CPU 各一个。内存密集型引擎在每个进程都固定在同一路 CPU 上时表现最好：用 numactl 绑定实例、每路运行一个实例，或在引擎支持时启用其 NUMA 感知功能。单路的 Max 96 拥有 96 个核心和 1,152 GB 内存，从根本上避开了这个问题。

Max 系列服务器配备四块 7.68 TB NVMe Gen5 硬盘（原始容量 30.72 TB），Pro 64 配备四块 3.84 TB 硬盘。根据冗余由哪一层负责来选择布局：

• 在数据层复制（ClickHouse ReplicatedMergeTree、Kafka 复制、OpenSearch 副本）：在 JBOD 存储策略中单独使用每块硬盘，或者做条带化，由其他服务器上的副本来应对硬盘故障。
• 无副本的单节点：组 RAID 10，Max 系列服务器约有 15 TB 可用空间，备份存放在别处。

对数据分层。近期分区留在 NVMe 上，较旧的分区迁移到更便宜的大容量存储：ClickHouse 存储策略可以把数据片段迁移到 S3 兼容存储，而这类存储可以自建，例如在阿什本、洛杉矶、阿姆斯特丹或法兰克福的 Storage 264（原始容量 264 TB）上运行 Ceph RGW 或 SeaweedFS。

压缩会改变计算结果：列式引擎存储的数据通常比原始大小小好几倍，因此请用你自己的数据样本估算磁盘需求，而不是按源数据大小推算。

当一个节点不够用时，把集群流量放在私有 VLAN 上：同一机房内的服务器可免费共享，内网流量不计费。各引擎的实用起步配置：

• ClickHouse：在 Pro 64 或 Max 系列节点上分片，每个分片两个副本，并在三个节点上运行 ClickHouse Keeper 负责协调。Keeper 对硬件要求不高，Core 16 这样的小型服务器就足够了。
• Spark：每个 Executor 约分配 4 至 8 个核心，并配置相应的内存；Shuffle 和溢写目录放在 NVMe 上。
• Kafka：至少三个 Broker，副本因子为 3，日志存放在 NVMe 上。
• OpenSearch 或 Elasticsearch：每个 JVM 堆保持在约 30 GB 以下，以确保压缩对象指针保持启用；至少留一半内存给文件系统缓存；在大型服务器上，每台主机运行多个节点。

Max 192 配备 2 × 100 Gbps 端口，适合 Shuffle 密集型集群；Pro 64 和 Max 96 配备 2 × 25 Gbps 端口。数据分析的瓶颈往往在于数据搬运，因此要尽早测量节点之间的吞吐量。