Clickhouse多磁盘存储，实现冷热数据分离

liuian 2025-07-10 16:38 87 浏览

前言

最近一直在搞监控方面的事情，随着监控数据越来越多，之前使用的influxdb感觉有点要扛不住的感觉，查询时间范围选择稍长，查询速度就变得特别慢。正好发现了clickhouse数据库，测试后觉得不错，目前监控已经全面切换至clickhouse，今天就来简单分享下clickhouse如何实现多磁盘存储，实现冷热数据分离。

Clickhouse简介

ClickHouse是一款OLAP的数据库产品，由俄罗斯yandex公司开发，专为在线数据分析而设计，能够使用SQL查询生成实时数据报告，在2016年开源。

ClickHouse足够轻量，不依赖Hadoop生态。ClickHouse有如下特点：

真正的面向列的DBMS
数据高效压缩
磁盘存储的数据
多核并行处理
在多个服务器上进行分布式处理
SQL语法支持
向量化引擎
实时数据更新
索引
适合在线查询
支持近似预估计算
支持嵌套的数据结构
支持数组作为数据类型
支持限制查询复杂性以及配额
复制数据复制和对数据完整性的支持

详情参考官方文档：
https://clickhouse.tech/docs/zh/

Clickhouse多磁盘存储策略

在Clickhouse 19.15版本之前，MergeTree 只支持单路径存储，所有的数据都会被写入config.xml配置中path指定的路径下，即使服务器挂载了多块磁盘，也无法有效利用这些存储空间。

为了解决这种问题在19.15版本开始支持MergeTree自定义存储策略的功能，支持以数据分区为最小移动单元将分区目录写入多块磁盘目录。

根据配置策略的不同，目前大致有三类存储策略：

1.默认策略（default）：MergeTree原本的存储策略，无须任何配置，所有分区会自动保存到config.xml 配置中的path指定的路径。

1.JBOD策略：这种策略适用于服务器挂载了多块磁盘，但是没有RAID的场景。JBOD （Just a Bunch Of Disks），是一种Round-robin 轮询策略，每执行一次INSERT或者Merge 所产生的新分区会轮询写入各个磁盘。这种策略的效果类似于RAID 0，可以降低单块磁盘的负载，在一定条件下能增加数据并行读写的性能。若单块磁盘发生故障，则会丢掉应用JBOD策略写入的这部分数据。

3.HOT/COLD策略：（冷热分离）这种策略适合服务器挂载了不同类型磁盘的场景。将存储磁盘分为HOT和COLD。

HOT使用SSD，注重性能；

COLD区域使用HDD这类高容量存储媒介，注重存取的经济性。

数据在写入的MergeTree之初，首先会在HOT区域创建分区目录保存数据，当分区数据大小达到阈值数据会自动移动到COLD区域。

而在每个区域的内部也支持定义多个磁盘，所以在单个区域写入的过程，也能使用JBOD策略。

Clickhouse多磁盘存储配置

Clickhouse安装也非常简单，本文不做概述，官方文档已经写得很详细了。

磁盘、卷和存储策略应当在主配置文件 config.xml 或 config.d 目录中的独立文件中的 <storage_configuration> 标签内定义。

disk配置示例：

<storage_configuration>
    <disks>
        <disk_name_1> <!-- disk name -->
            <path>/mnt/fast_ssd/clickhouse/</path>
        </disk_name_1>
        <disk_name_2>
            <path>/mnt/hdd1/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_2>
        <disk_name_3>
            <path>/mnt/hdd2/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_3>

        ...
    </disks>

    ...
</storage_configuration>

示例解释：

<disk_name_*> 必填项，必须全局唯一，表示磁盘的自定义名称

<path> 必填项，服务器将用来存储数据 (data 和 shadow 目录) 的路径, 应当以 ‘/’ 结尾

<keep_free_space_bytes> 选填项，用于指定指定磁盘的预留空间，单位字节bit

注意：磁盘的配置选项的先后顺序没有关系。

在policies 的配置中，需要引用先前定义的disks磁盘。policies 同样支持定义多个策略。

存储策略配置：

<storage_configuration>
    ...
    <policies>
        <hdd_in_order> <!-- policy name -->
            <volumes>
                <single> <!-- volume name -->
                    <disk>disk1</disk>
                    <disk>disk2</disk>
                </single>
            </volumes>
        </hdd_in_order>

        <moving_from_ssd_to_hdd>
            <volumes>
                <hot>
                    <disk>fast_ssd</disk>
                    <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
                </hot>
                <cold>
                    <disk>disk1</disk>
                </cold>
            </volumes>
            <move_factor>0.2</move_factor>
        </moving_from_ssd_to_hdd>
    </policies>
    ...
</storage_configuration>

示例解释：

<hdd_in_order>必填项，必须全局唯一，表示策略的自定义名称

<volume_name_x>必填项，必须全局唯一，表示卷的自定义名称

<disk> 必填项，用于关联<disks>配置内的磁盘，可以声明多个disk，MergeTree会按照定义的顺序选择disk

<max_data_part_size_bytes> 选填，字节为单位默认1G，表示在这个卷的单个disk磁盘中，一个数据分区的最大磁盘存储阈值，若当前分区的数据大小超过阈值，则之后的分区会写入下一个disk磁盘。

<move_factor> 选填项，默认值为0.1,；若当前卷的可用空间大小小于factor因子，并且定义多个卷，则数据会自动移动到下一个卷。

在示例中，hdd_in_order 策略实现了循环制方法。因此这个策略只定义了一个卷（single），数据片段会以循环的顺序全部存储到它的磁盘上。当有多个类似的磁盘挂载到系统上，但没有配置 RAID 时，这种策略非常有用。

如果在系统中有不同类型的磁盘可用，可以使用 moving_from_ssd_to_hdd。hot 卷由 SSD 磁盘（fast_ssd）组成，这个卷上可以存储的数据片段的最大大小为 1GB。所有大于 1GB 的数据片段都会被直接存储到 cold 卷上，cold 卷包含一个名为 disk1 的 HDD 磁盘。

同样，一旦 fast_ssd 被填充超过 80%，数据会通过后台进程向 disk1 进行转移。

创建数据表，将配置的策略应用到表即可：

CREATE TABLE table_with_non_default_policy (
    EventDate Date,
    OrderID UInt64,
    BannerID UInt64,
    SearchPhrase String
) ENGINE = MergeTree
ORDER BY (OrderID, BannerID)
PARTITION BY toYYYYMM(EventDate)
SETTINGS storage_policy = 'moving_from_ssd_to_hdd'

default 存储策略意味着只使用一个卷，这个卷只包含一个在 <path> 中定义的磁盘。表创建后，它的存储策略就不能改变了。