ClickHouse系列（十）：生产架构与最佳实践总结

系列定位：规模化与总结 ------ 解决长期稳定运行的系统性问题

这是本系列的最后一篇。经过前 9 篇对 ClickHouse 各个维度的深入探讨，本篇将站在全局视角，梳理生产环境中的架构选型、运维要点，并给出一套可直接落地的 Checklist。

一、分片 / 副本 / 分布式表的代价

1.1 架构拓扑

ClickHouse 集群的基本单元是 shard（分片） 和 replica（副本）：

复制代码

┌─────────────────────────────────────┐
│           Distributed Table         │
├──────────┬──────────┬───────────────┤
│ Shard 1  │ Shard 2  │   Shard 3     │
│ ┌──────┐ │ ┌──────┐ │ ┌──────┐      │
│ │ R1-1 │ │ │ R2-1 │ │ │ R3-1 │      │
│ │ R1-2 │ │ │ R2-2 │ │ │ R3-2 │      │
│ └──────┘ │ └──────┘ │ └──────┘      │
└──────────┴──────────┴───────────────┘

1.2 分片的代价

分片并非免费午餐，它引入了以下成本：

维度	代价
查询复杂度	分布式查询需要跨节点聚合，`GROUP BY` 高基数场景下网络传输量大
数据倾斜	分片键选择不当导致热点节点
DDL 管理	需要 `ON CLUSTER` 或逐节点执行，容易不一致
JOIN 限制	跨分片 JOIN 性能极差，通常需要 `GLOBAL JOIN`
运维成本	扩缩容需要数据重分布

1.3 副本的代价

xml 复制代码

<!-- 典型的 ZooKeeper 配置 -->
<zookeeper>
    <node><host>zk1</host><port>2181</port></node>
    <node><host>zk2</host><port>2181</port></node>
    <node><host>zk3</host><port>2181</port></node>
</zookeeper>

副本依赖 ZooKeeper（或 ClickHouse Keeper）进行元数据协调。代价包括：

ZooKeeper 成为额外的运维组件和潜在瓶颈
每次 INSERT 和 Merge 都需要与 ZK 交互
ZK 节点数过多时（百万级 znode），性能急剧下降

建议：优先使用 ClickHouse Keeper 替代 ZooKeeper，它与 ClickHouse 版本同步演进，运维更简单。

1.4 分布式表的查询陷阱

sql 复制代码

-- 分布式表定义
CREATE TABLE events_dist AS events_local
ENGINE = Distributed('cluster_name', 'db', 'events_local', rand());

-- ⚠️ 这条查询会在每个分片上执行子查询，然后在发起节点聚合
SELECT uniq(user_id) FROM events_dist;

-- 结果是近似值的近似值（双重近似误差）
-- 正确做法：使用 uniqExact 或接受误差

二、ClickHouse Operator 的设计思路

在 Kubernetes 环境中，Altinity ClickHouse Operator 是最成熟的方案。

2.1 核心抽象

yaml 复制代码

apiVersion: clickhouse.altinity.com/v1
kind: ClickHouseInstallation
metadata:
  name: production
spec:
  configuration:
    clusters:
      - name: main
        layout:
          shardsCount: 3
          replicasCount: 2
    zookeeper:
      nodes:
        - host: clickhouse-keeper-0
        - host: clickhouse-keeper-1
        - host: clickhouse-keeper-2
  defaults:
    templates:
      podTemplate: clickhouse-pod
      volumeClaimTemplate: data-volume
  templates:
    podTemplates:
      - name: clickhouse-pod
        spec:
          containers:
            - name: clickhouse
              resources:
                requests:
                  memory: 32Gi
                  cpu: "8"
                limits:
                  memory: 48Gi
    volumeClaimTemplates:
      - name: data-volume
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 500Gi

2.2 Operator 解决的核心问题

问题	Operator 方案
节点扩缩容	修改 `shardsCount` / `replicasCount`，自动创建 StatefulSet
配置变更	修改 CR，Operator 滚动重启
版本升级	修改镜像版本，逐节点滚动升级
监控集成	自动暴露 Prometheus metrics 端点

三、TTL、磁盘膨胀与空间回收

3.1 TTL 的工作机制

sql 复制代码

CREATE TABLE events (
    event_date Date,
    event_time DateTime,
    data String
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY event_time
TTL event_date + INTERVAL 90 DAY DELETE,
    event_date + INTERVAL 30 DAY TO VOLUME 'cold';

TTL 规则在 Merge 时执行，而非实时删除。这意味着：

数据不会在过期瞬间消失
需要等待后台 Merge 触发
可以手动触发：OPTIMIZE TABLE events FINAL

3.2 磁盘膨胀的常见原因

原因	表现	解决方案
小 part 堆积	`system.parts` 中 active part 数量过多	检查写入频率，合并小批次
Mutation 残留	旧 part 未被清理	`KILL MUTATION` + 等待 Merge
TTL 未触发	过期数据仍占用空间	`OPTIMIZE TABLE ... FINAL`
宽表 + 低压缩率	磁盘占用远超预期	检查编码，使用 `CODEC(ZSTD)`

3.3 空间回收操作

sql 复制代码

-- 查看各表的磁盘占用
SELECT
    database,
    table,
    formatReadableSize(sum(bytes_on_disk)) AS disk_size,
    sum(rows) AS total_rows,
    count() AS part_count
FROM system.parts
WHERE active
GROUP BY database, table
ORDER BY sum(bytes_on_disk) DESC;

-- 强制合并以触发 TTL 清理（谨慎使用，消耗大量 IO）
OPTIMIZE TABLE events FINAL;

-- 删除特定分区（立即释放空间）
ALTER TABLE events DROP PARTITION '202301';

四、Trace / Metrics / Logs 的统一建模思路

ClickHouse 非常适合作为可观测性数据的存储后端。以下是一套统一建模方案：

4.1 Logs 表

sql 复制代码

CREATE TABLE logs (
    timestamp DateTime64(3),
    trace_id String,
    span_id String,
    severity LowCardinality(String),
    service LowCardinality(String),
    message String,
    attributes Map(String, String)
) ENGINE = MergeTree()
PARTITION BY toDate(timestamp)
ORDER BY (service, severity, timestamp)
TTL toDate(timestamp) + INTERVAL 30 DAY;

4.2 Metrics 表

sql 复制代码

CREATE TABLE metrics (
    timestamp DateTime,
    metric_name LowCardinality(String),
    service LowCardinality(String),
    value Float64,
    tags Map(String, String)
) ENGINE = MergeTree()
PARTITION BY toDate(timestamp)
ORDER BY (metric_name, service, timestamp)
TTL toDate(timestamp) + INTERVAL 90 DAY;

4.3 Traces 表

sql 复制代码

CREATE TABLE traces (
    trace_id String,
    span_id String,
    parent_span_id String,
    service LowCardinality(String),
    operation LowCardinality(String),
    start_time DateTime64(6),
    duration_us UInt64,
    status_code UInt8,
    attributes Map(String, String)
) ENGINE = MergeTree()
PARTITION BY toDate(start_time)
ORDER BY (service, start_time, trace_id)
TTL toDate(start_time) + INTERVAL 14 DAY;

4.4 关联查询

三张表通过 trace_id 关联，实现从 Trace 到 Log 的下钻：

sql 复制代码

-- 找到慢请求对应的日志
SELECT l.timestamp, l.severity, l.message
FROM logs l
WHERE l.trace_id IN (
    SELECT trace_id FROM traces
    WHERE duration_us > 5000000  -- > 5s
      AND start_time > now() - INTERVAL 1 HOUR
)
ORDER BY l.timestamp;

五、生产级 Checklist

5.1 表设计

检查项	要求
主键（ORDER BY）	按查询频率从高到低排列，低基数列在前
分区键	使用时间字段，粒度不宜过细（推荐月/天）
数据类型	枚举值用 `LowCardinality(String)`，时间用 `DateTime` 而非 `String`
编码	时间列用 `DoubleDelta`，整数用 `Delta`，通用用 `ZSTD(1)`
TTL	必须设置，防止数据无限增长

5.2 写入

检查项	要求
批次大小	每批 10,000 ~ 100,000 行，避免逐行 INSERT
写入频率	每秒不超过 1 次 INSERT（同一张表）
异步写入	生产环境使用 `Buffer` 表或 Kafka 引擎缓冲
去重	ReplicatedMergeTree 自带 block 级去重，利用 `insert_deduplicate`

5.3 Kafka 集成

检查项	要求
消费架构	Kafka 引擎表 → 物化视图 → 目标 MergeTree 表
错误处理	设置 `kafka_skip_broken_messages` 避免卡死
监控	监控 `system.kafka_consumers` 的 lag
分区对齐	Kafka partition 数量与 ClickHouse 消费线程数匹配

5.4 聚合

检查项	要求
预聚合	高频查询使用 `AggregatingMergeTree` + 物化视图
近似算法	UV 统计用 `uniqHLL12`，分位数用 `quantileTDigest`
溢出保护	设置 `max_bytes_before_external_group_by`

5.5 查询

检查项	要求
内存限制	`max_memory_usage` 必须设置
超时	`max_execution_time` 设置合理上限
并发控制	`max_concurrent_queries_for_user` 防止单用户打满
LIMIT	所有面向用户的查询必须带 LIMIT
JOIN	避免大表 JOIN，优先用 `IN` 或字典表

5.6 运维

检查项	要求
监控	Prometheus + Grafana，关注 `MemoryTracking`、`Query`、`Merge` 指标
备份	使用 `clickhouse-backup` 工具，定期备份到 S3
升级	先升级测试环境，逐节点滚动升级，保持副本可用
日志清理	`system.query_log` 设置 TTL，避免系统表膨胀
ZooKeeper	监控 znode 数量，定期清理过期的 block hash

sql 复制代码

-- 为系统表设置 TTL（推荐）
ALTER TABLE system.query_log MODIFY TTL event_date + INTERVAL 14 DAY;
ALTER TABLE system.trace_log MODIFY TTL event_date + INTERVAL 7 DAY;
ALTER TABLE system.metric_log MODIFY TTL event_date + INTERVAL 7 DAY;

系列总结

回顾整个系列的 10 篇文章，我们从 ClickHouse 的核心理念出发，逐步深入到生产实践。ClickHouse 是一个极其强大但也需要深入理解的系统。希望这个系列能帮助你在生产环境中用好它，构建高性能、高可靠的实时分析平台。