Clickhouse之system log tables 运维

过年期间Clickhouse的服务器一直因为磁盘空间问题在告警，开年第一天先来排查个小问题。

查看CK表的大小

我们先来看看CK各张表的磁盘大小，在CK中库的大小和表的大小都可以通过查询system.parts这张表获得，system.parts表是 MergeTree 表分区的相关信息的系统表， 具体SQL如下

SELECT
    concat(database, '.', table) AS table,
    formatReadableSize(sum(bytes)) AS size,
    sum(bytes) AS bytes_size,
    sum(rows) AS rows,
    max(modification_time) AS latest_modification,
    any(engine) AS engine
FROM system.parts
GROUP BY
    database,
    table
ORDER BY bytes_size DESC

百度出来的sql，大多数是使用的是data_compressed_bytes和data_uncompressed_bytes，更准确一点的应该是使用bytes或者bytes_on_disk 字段， 我们来看看这几个字段的定义以及我们查询到的数据就一目了然了：

• bytes_on_disk  – 数据总大小（以字节为单位）。

• bytes  – bytes_on_disk的别名。

• data_compressed_bytes  – 数据分区中压缩数据的总大小。不包括所有辅助文件（例如，带有标记的文件）。

• data_uncompressed_bytes  – 数据分区中未压缩数据的总大小。不包括所有辅助文件（例如，带有标记的文件）。这里其实是指数据压缩前的大小。

再看看我们查询到的实际的结果对比，其实 bytes_on_disk 还是比 data_compressed_bytes  结果稍微大一点。

table───────────────────┬────────size─┬─bytes_on_disk─┬─compressed─┬─uncompressed─┐
│ trace_log               │ 28725460521 │ 26.75 GiB     │ 26.72 GiB  │ 262.59 GiB   │
│ query_thread_log        │ 19884489567 │ 18.52 GiB     │ 18.49 GiB  │ 146.65 GiB   │
│ part_log                │ 17956173407 │ 16.72 GiB     │ 16.70 GiB  │ 82.89 GiB    │
│ query_log               │ 17369094330 │ 16.18 GiB     │ 16.13 GiB  │ 146.34 GiB   │

system log tables

一排查才发现其实我们的业务表并不大，是query_log, query_thread_log等这些系统表占用的磁盘空间太大，query_log, query_thread_log 这些都属于系统自动记录查询日志相关信息的表，metric_log, query_log, query_thread_log, trace_log, part_log, crash_log and text_log 默认采用MergeTree 引擎并将其数据存储在文件系统中， 默认情况下Clickhouse并不会自动清理这些数据。这些表基本都是分区表并基于event_date按月进行分区。有二种方式来配置TTL自动清理这些系统日志表，我们先来看看CK官方文档提到的直接修改系统配置文件/etc/clickhouse-server/config.xml进行配置，看了下默认配置，其实这些表的库名，表名分区等信息都已经配置好了，只需要添加下<ttl>event_date + INTERVAL 30 DAY DELETE</ttl> 这段ttl配置就好， 官方文档示例如下：

<clickhouse>
    <query_log>
        <database>system</database>
        <table>query_log</table>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <ttl>event_date + INTERVAL 30 DAY DELETE</ttl>
        <!--
        <engine>ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_time) SETTINGS index_granularity = 1024</engine>
        -->
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    </query_log>
</clickhouse>

测试了一下，配置好了之后，直接重启CK服务使配置生效，多余的分区会被直接自动干掉了，并不需要手动再去清理原有的过期数据。

第二种方式是网上查到的，直接以SQL语句的方式来设置ttl：

ALTER TABLE query_log MODIFY TTL event_date + toIntervalDay(30);

‍

小结

Clickhouse 是实时数仓和OLAP的主流技术栈之一，我们从去年开始试用CK，其性能确实很强大，但个人感觉现阶段对运维并不太友好，各种坑不少，优秀开源工具缺乏，文档相比ES和CDH比较拉胯，我们对于CK的运维能力还需要继续爬坡。