发布于 由admin

解析 Columnar Storage（列式存储）：为什么 ClickHouse 处理 OLAP 查询的速度远超传统数据库？

各位同仁，大家好。

今天，我们来深入探讨一个在现代数据分析领域至关重要的话题：列式存储（Columnar Storage），以及它如何赋能像 ClickHouse 这样的数据库，使其在处理联机分析处理（OLAP）查询时，性能远超传统的关系型数据库。作为一名编程专家，我将从底层机制、代码实现到架构设计，为大家剖析其中的奥秘。

在当今数据爆炸的时代，企业面临着海量数据的分析挑战。传统数据库，即便经过精心调优，在面对复杂的分析查询时也常常显得力不从心。它们的响应时间可能从几秒到几分钟不等，这对于需要实时洞察的业务场景是不可接受的。ClickHouse，作为一个开源的列式数据库管理系统，正是为解决这一痛点而生。

OLAP 与 OLTP：两种截然不同的工作负载

要理解列式存储的价值，我们首先要区分两种核心的数据库工作负载：联机事务处理（OLTP）和联机分析处理（OLAP）。

OLTP (Online Transaction Processing)：
OLTP 系统主要关注事务性操作，如插入、更新、删除单条或少量记录，以及基于主键的快速查找。它的特点是并发量高、数据修改频繁、每次操作涉及的数据量小。例如，银行转账、电商订单处理、用户登录等场景。在这些场景中，我们通常需要快速访问一条记录的所有字段。

OLAP (Online Analytical Processing)：
OLAP 系统则专注于复杂的数据分析，涉及对大量数据的聚合、过滤和统计。它的特点是读取密集、涉及的记录数量庞大、查询逻辑复杂（如多表 JOIN、GROUP BY、聚合函数）、写入相对较少且通常是批量写入。例如，年度销售报告、用户行为分析、广告效果评估等。在这些场景中，我们通常只需要访问表中少量特定列的数据，但要处理这些列的全部或大部分行。

传统行式存储的困境

传统的关系型数据库，如 MySQL、PostgreSQL，普遍采用行式存储（Row-Oriented Storage）。这意味着数据库中的每一行数据都被作为一个完整的记录存储在磁盘上，相邻的行在物理上也是相邻的。

假设我们有一个 sales 表，包含 order_id, product_id, customer_id, sale_date, amount, region 等字段。在行式存储中，数据是这样组织的：

Row ID order_id product_id customer_id sale_date amount region
1 1001 P001 C101 2023-01-01 150.00 East
2 1002 P002 C102 2023-01-02 200.00 West
3 1003 P001 C101 2023-01-03 120.00 East

在磁盘上，这些数据可能被连续存储为：
[1001, P001, C101, 2023-01-01, 150.00, East], [1002, P002, C102, 2023-01-02, 200.00, West], ...

对于 OLTP 查询，例如 SELECT * FROM sales WHERE order_id = 1002;，行式存储非常高效，因为一条记录的所有字段都在一起，只需一次磁盘查找就能读取整行。

然而，当面对 OLAP 查询时，问题就出现了。考虑一个查询：SELECT SUM(amount) FROM sales WHERE region = 'East' AND sale_date BETWEEN '2023-01-01' AND '2023-01-31';。这个查询只需要 amount, region, sale_date 这三列。但在行式存储中，即使我们只关心这三列，数据库也必须读取每一行的所有列（order_id, product_id, customer_id 等），然后丢弃不需要的列。这导致了大量的I/O 放大（I/O Amplification）。磁盘带宽是宝贵的资源，读取无关数据无疑是巨大的浪费。同时，由于数据分散，CPU 缓存的利用率也大打折扣。

列式存储：为分析而生

列式存储的核心思想是：将表中的每一列数据单独存储。 也就是说，所有 order_id 存储在一起，所有 product_id 存储在一起，依此类推。

对于我们之前的 sales 表，列式存储将数据组织成：

order_id product_id customer_id sale_date amount region
1001 P001 C101 2023-01-01 150.00 East
1002 P002 C102 2023-01-02 200.00 West
1003 P001 C101 2023-01-03 120.00 East

在磁盘上，数据可能被存储为：
order_id 列: [1001, 1002, 1003, ...]
product_id 列: [P001, P002, P001, ...]
amount 列: [150.00, 200.00, 120.00, ...]
…

现在，我们再来看那个 OLAP 查询：SELECT SUM(amount) FROM sales WHERE region = 'East' AND sale_date BETWEEN '2023-01-01' AND '2023-01-31';。数据库只需读取 amount、region 和 sale_date 这三列的数据，完全避免了读取 order_id、product_id、customer_id 等无关列。这显著减少了磁盘 I/O，正是列式存储在 OLAP 场景下性能优越的根本原因。

列式存储的关键优势：

  1. 减少 I/O 读写： 只读取查询所需列，避免全行扫描。
  2. 更高的压缩率： 同一列的数据类型相同，且往往具有更高的相似性（例如，一个 region 列可能只有少数几个重复值，一个 sale_date 列可能是递增的日期）。这使得各种压缩算法（如 Run-Length Encoding, Delta Encoding, Dictionary Encoding）能发挥最佳效果，进一步减少存储空间和 I/O 量。
  3. 更优的 CPU 缓存利用率： 当查询读取某一列时，数据是连续存储的。这意味着一旦数据被加载到 CPU 缓存，后续操作可以持续命中缓存，减少内存访问延迟。
  4. 支持向量化执行： 由于数据按列存储，CPU 可以一次处理一整批（向量）数据，而不是逐行处理。这能够充分利用现代 CPU 的 SIMD（Single Instruction, Multiple Data）指令集，大幅提升计算效率。

ClickHouse 的列式存储实现深度剖析

ClickHouse 将列式存储的优势发挥到了极致，其高性能并非偶然，而是基于一系列精巧的设计和优化。

1. 数据存储引擎：MergeTree 家族

ClickHouse 最核心的存储引擎是 MergeTree 及其变种（如 ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree 等）。MergeTree 引擎的特点是：

  • 数据分片 (Partitions)： 数据可以按照指定的键（如日期）进行分区。每个分区的数据在物理上是独立的，有助于管理和查询。
  • 有序存储 (Ordered Storage)： 数据在每个分区内部是按照 ORDER BY 表达式指定的键进行排序的。这对于范围查询和聚合操作至关重要。
  • 稀疏索引 (Sparse Primary Index)： ClickHouse 不为每一行数据都建立索引。相反，它每隔一定行数（例如 8192 行）记录一个主键值及其在磁盘上的偏移量。这意味着索引文件非常小，可以完全加载到内存中，从而实现极快的索引查找。
  • 不可变数据块 (Immutable Parts)： 写入的数据被组织成一个个小的、独立的、不可变的“数据片段”（Parts）。这些片段会周期性地在后台进行合并（Merge），以优化存储和查询性能。合并操作会去除重复数据（如果使用 ReplacingMergeTree），或进行预聚合（如果使用 SummingMergeTree）。

让我们通过一个 CREATE TABLE 语句来感受 MergeTree 的基本结构：

CREATE TABLE sales_data
(
    event_date Date,
    timestamp DateTime,
    region String,
    product_id UInt32,
    customer_id UInt64,
    amount Decimal(18, 2),
    quantity UInt32
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)  -- 按照月份分区
ORDER BY (region, event_date, product_id) -- 数据在每个分区内按照这三列排序
PRIMARY KEY (region, event_date)          -- 稀疏主键，用于快速过滤
SETTINGS index_granularity = 8192; -- 索引粒度，每8192行一个索引项

在这个例子中：

  • PARTITION BY toYYYYMM(event_date)：数据会根据 event_date 的年份和月份进行分区。例如，2023年1月的数据会存放在一个分区，2023年2月的数据存放在另一个分区。这使得查询可以快速跳过不相关的分区。
  • ORDER BY (region, event_date, product_id)：在每个分区内部，数据会按照 region、event_date、product_id 的顺序存储。这对于 WHERE region = 'East' AND event_date BETWEEN ... 这样的范围查询非常有利，因为相关数据在磁盘上是物理相邻的。
  • PRIMARY KEY (region, event_date)：ClickHouse 会为 region 和 event_date 组合创建一个稀疏索引。当查询条件包含 region 或 event_date 时，ClickHouse 可以通过这个索引快速定位到相关的数据块，而无需扫描整个文件。

对于每一列，ClickHouse 都会创建单独的文件来存储其数据。例如，sales_data 表的 event_date 列将存储在 event_date.bin 文件中，amount 列存储在 amount.bin 文件中。此外，还会有 event_date.mrk (标记文件，记录数据块的偏移量)，以及其他辅助文件。

2. 高效的压缩技术

列式存储天然适合高压缩率，ClickHouse 在此基础上提供了多种高级压缩算法，并且允许用户为每列单独指定压缩方式。

为什么列式数据更容易压缩？

  • 同类型数据： 同一列的所有值都是相同数据类型，没有混合类型带来的开销。
  • 相似性： 许多列的数据具有高度相似性或重复性。例如，region 列可能只有几十个不同的地区名称；timestamp 列可能是递增的时间戳序列；event_type 列可能只有几个固定的枚举值。

ClickHouse 支持的常用压缩编码包括：

  • LZ4 / ZSTD： 通用的高速压缩算法，提供良好的压缩比和解压速度。
  • Delta / DoubleDelta： 针对有序数值序列，存储相邻值之间的差值（Delta），或差值的差值（DoubleDelta），对于时间戳、ID 等递增序列效果极佳。
  • Run-Length Encoding (RLE)： 对于包含大量连续重复值的列非常有效。例如，[A, A, A, B, B, C] 可以压缩为 [ (A, 3), (B, 2), (C, 1) ]。
  • Dictionary Encoding： 对于低基数字符串列（如 region），可以将字符串映射为整数 ID，然后存储 ID 序列。
  • T64 / FPC (Floating Point Compression)： 针对浮点数进行优化。

通过 CODEC 语法，我们可以在 CREATE TABLE 时为每列指定压缩算法：

CREATE TABLE sensor_readings
(
    sensor_id UInt32 CODEC(Delta, LZ4), -- sensor_id 可能递增，先Delta编码再LZ4
    timestamp DateTime CODEC(DoubleDelta, ZSTD), -- timestamp 也是递增，DoubleDelta更优，ZSTD压缩比高
    temperature Float32 CODEC(FPC, LZ4), -- 浮点数用FPC，再LZ4
    humidity UInt8 CODEC(T64, LZ4),     -- 小整数用T64，再LZ4
    location String CODEC(ZSTD)        -- 字符串用ZSTD
)
ENGINE = MergeTree()
ORDER BY (sensor_id, timestamp);

当查询需要读取某一列时，ClickHouse 只需解压该列的数据。这种细粒度的压缩和按需解压进一步减少了 I/O 和内存开销。

3. 向量化查询执行

这是 ClickHouse 性能卓越的另一个核心秘密。传统的数据库通常采用迭代式（row-at-a-time）执行模型，即查询处理器一次处理一行数据。这在 OLTP 场景中可能足够，但在 OLAP 场景中，频繁的函数调用、条件判断和循环迭代会引入巨大的 CPU 开销。

ClickHouse 采用向量化（Vectorized）查询执行模型。它不是一次处理一行，而是一次处理一个数据块（Block）或一个向量（Vector）的数据。一个数据块通常包含几千到几万行数据，每个列的数据被组织成一个连续的数组。

考虑一个简单的聚合查询：SELECT SUM(amount) FROM sales_data WHERE region = 'East';

在传统的行式执行中（伪代码）：

long total_amount = 0;
for (Row row : table) {
    if (row.getRegion() == "East") {
        total_amount += row.getAmount();
    }
}

这里，每次循环都需要调用 getRegion()、getAmount() 等方法，进行条件判断和累加，这些都是单独的指令操作。

在 ClickHouse 的向量化执行中（概念性伪代码）：

long total_amount = 0;
Block block; // 定义一个数据块，包含多列数据
while (get_next_block(block)) { // 循环读取数据块
    // 获取当前数据块中 region 和 amount 列的指针/引用
    Column<String>& region_column = block.getColumn("region");
    Column<Decimal>& amount_column = block.getColumn("amount");

    // 创建一个掩码，用于标记哪些行符合条件
    std::vector<bool> filter_mask(block.rows());

    // 向量化过滤：一次性处理 region 列的所有值
    for (size_t i = 0; i < block.rows(); ++i) {
        filter_mask[i] = (region_column.getValue(i) == "East");
    }

    // 向量化聚合：根据掩码，一次性累加 amount 列的值
    for (size_t i = 0; i < block.rows(); ++i) {
        if (filter_mask[i]) {
            total_amount += amount_column.getValue(i);
        }
    }
}

这种处理方式带来了显著的性能提升：

  • 减少函数调用开销： 对一个数据块的所有行执行一次操作，而不是对每一行执行一次函数调用。
  • 提高 CPU 缓存命中率： 数据在内存中是连续的，CPU 可以高效地预取数据，减少缓存缺失。
  • 利用 SIMD 指令： 现代 CPU 支持 SIMD 指令（如 SSE, AVX），可以并行处理多个数据元素。ClickHouse 的向量化引擎能够将这些操作映射到 SIMD 指令，例如，一次比较或累加 4 个、8 个甚至更多整数或浮点数。这就像一次性搬运一车货，而不是一包一包地搬。

ClickHouse 的内部数据结构 Block 就是这种向量化执行的基础。它是一个由多个 IColumn 对象组成的集合，每个 IColumn 代表一列数据，并且存储着该列的实际数据。操作符（如过滤、聚合）直接作用于这些 IColumn 对象。

4. 强大的查询优化器与分布式能力

ClickHouse 拥有一个相对简单的但高效的查询优化器。它主要关注以下几点：

  • 分区裁剪 (Partition Pruning)： 根据查询条件，跳过不包含所需数据的分区。
  • 索引跳过 (Index Skipping)： 利用稀疏主键和各种数据跳过索引（如 MinMax 索引、Set 索引、Bloom Filter 索引）快速定位相关数据块。
  • 谓词下推 (Predicate Pushdown)： 尽可能早地在数据读取阶段应用过滤条件，减少传输和处理的数据量。

例如，对于 sales_data 表：

SELECT SUM(amount)
FROM sales_data
WHERE event_date >= '2023-03-01' AND event_date < '2023-04-01'
  AND region = 'West';

ClickHouse 会：

  1. 根据 PARTITION BY toYYYYMM(event_date)，识别并只读取 202303 分区的数据。
  2. 在 202303 分区内部，利用 ORDER BY (region, event_date, product_id) 和 PRIMARY KEY (region, event_date) 的稀疏索引，快速定位到 region = 'West' 且 event_date 在指定范围内的物理数据块。
  3. 只读取 amount, event_date, region 这三列的数据。
  4. 对读取到的数据块进行向量化过滤和聚合。

此外，ClickHouse 生来就是为分布式环境设计的。通过 Distributed 表引擎，它可以将查询自动分发到集群中的所有分片（shards），并在各个分片上并行执行查询。最终，将各个分片的结果汇总，实现对海量数据的横向扩展分析。

5. 内存管理与缓存效率

由于列式存储将同一列的数据紧密地存储在一起，当 ClickHouse 读取一个列的数据块时，这些数据在内存中也是连续的。这极大地提高了 CPU 缓存（L1, L2, L3 Cache）的命中率。当处理器从主内存获取数据时，它通常会预取一块数据到缓存中，如果这些数据是连续的，那么后续的访问将直接命中缓存，避免了昂贵的主内存访问。

ClickHouse 也充分利用了操作系统级别的页缓存（Page Cache）。一旦数据文件被读取到操作系统的页缓存中，后续对相同数据的访问将无需再次从磁盘读取，进一步加速查询。

与传统行式数据库的对比（深入）

让我们更具体地对比 ClickHouse 与传统行式数据库在 OLAP 场景下的表现：

特性/场景 传统行式数据库 (e.g., MySQL InnoDB) ClickHouse (列式存储)
数据组织 按行存储，一行数据所有列连续存放。 按列存储，一列数据所有行连续存放。
I/O 效率 (OLAP) 低效。即使只查询少数列，也需读取整行数据，导致大量无关数据 I/O。 高效。只读取查询所需列的数据，大幅减少 I/O 量。
压缩效率 较低。行内数据类型多样，难以统一高效压缩。 极高。同列数据类型和特性一致，可使用特定算法（Delta, RLE, Dictionary Encoding）实现高压缩比。
CPU 缓存利用率 较低。查询所需数据分散在不同行，容易导致缓存失效。 极高。所需列数据连续存储，CPU 预取和缓存命中率高。
查询执行模型 逐行处理（Row-at-a-time），频繁函数调用和循环。 向量化处理（Vectorized），一次处理数据块，利用 SIMD 指令。
索引 B-Tree 索引，适用于单行快速查找。 稀疏主键索引，配合数据跳过索引，适用于范围查询和块级过滤。
写入性能 (OLAP) 批量写入可能涉及复杂事务和锁，性能瓶颈。 批量写入性能极高。数据追加到 Part，后台异步合并。
更新/删除 高效。基于主键可快速定位并修改/删除单行。 低效。数据不可变，更新/删除实际是标记删除或重写数据块（MergeTree 族通过合并实现）。不适合频繁单行修改。
事务支持 完整的 ACID 事务支持。 不支持 ACID 事务，提供最终一致性。设计目标是分析而非事务。

代码示例：数据导入与查询

为了更直观地展示 ClickHouse 的使用，我们来看几个简单的 SQL 例子。

首先，创建一个表：

CREATE TABLE website_events
(
    event_time DateTime,
    user_id UInt64,
    event_type LowCardinality(String), -- LowCardinality 是一种高效存储低基数字符串的方式
    page_url String,
    duration_ms UInt32,
    ip_address IPv4
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_time)
ORDER BY (user_id, event_time)
PRIMARY KEY (user_id);

数据导入： ClickHouse 支持多种导入方式，例如 CSV、TSV、JSON Each Row 等。

-- 假设我们有一个 CSV 文件 event_data.csv
-- event_time,user_id,event_type,page_url,duration_ms,ip_address
-- 2023-10-26 10:00:00,1001,click,/home,150,192.168.1.1
-- 2023-10-26 10:00:15,1002,view,/product/123,5000,192.168.1.2
-- ...
INSERT INTO website_events FROM INFILE 'event_data.csv' FORMAT CSV;

-- 或者直接插入多行数据
INSERT INTO website_events (event_time, user_id, event_type, page_url, duration_ms, ip_address) VALUES
('2023-10-26 10:00:00', 1001, 'click', '/home', 150, '192.168.1.1'),
('2023-10-26 10:00:15', 1002, 'view', '/product/123', 5000, '192.168.1.2'),
('2023-10-26 10:00:30', 1001, 'scroll', '/home', 3000, '192.168.1.1');

OLAP 查询示例：

  1. 统计每天不同事件类型的发生次数：

    SELECT
    toDate(event_time) AS event_day,
    event_type,
    count() AS total_events
FROM website_events
WHERE event_time >= '2023-10-01 00:00:00' AND event_time < '2023-11-01 00:00:00'
GROUP BY event_day, event_type
ORDER BY event_day, total_events DESC;

    这个查询只会读取 event_time 和 event_type 两列，以及执行 count() 聚合。由于 event_time 是 PARTITION BY 和 ORDER BY 的一部分，ClickHouse 可以高效地进行分区裁剪和索引定位。event_type 使用 LowCardinality 编码，进一步加速过滤和分组。

  2. 找出访问时长最长的用户及其平均访问时长：

    SELECT
    user_id,
    avg(duration_ms) AS avg_duration,
    sum(duration_ms) AS total_duration
FROM website_events
WHERE event_time >= '2023-10-01 00:00:00'
GROUP BY user_id
ORDER BY total_duration DESC
LIMIT 10;

    此查询主要关注 user_id 和 duration_ms 两列。user_id 是 ORDER BY 和 PRIMARY KEY 的一部分，有助于快速分组。

  3. 使用物化视图预聚合数据：
    对于频繁执行的聚合查询，我们可以创建物化视图来预计算结果，进一步提升查询速度。

    CREATE MATERIALIZED VIEW mv_daily_event_summary
ENGINE = SummingMergeTree(total_events) -- SummingMergeTree 会在合并时对 total_events 列进行求和
PARTITION BY toYYYYMM(event_day)
ORDER BY (event_day, event_type)
AS SELECT
    toDate(event_time) AS event_day,
    event_type,
    count() AS total_events
FROM website_events
GROUP BY event_day, event_type;

    一旦创建，每次有新数据写入 website_events 表时，mv_daily_event_summary 视图也会自动更新。当我们查询 mv_daily_event_summary 时，实际上是在查询已经预聚合好的结果，速度会快得多。

    SELECT event_day, event_type, total_events
FROM mv_daily_event_summary
WHERE event_day = '2023-10-26';

适用场景与局限性

ClickHouse 的最佳适用场景：

  • OLAP 查询： 对海量数据进行实时或近实时分析，如日志分析、用户行为分析、BI 报表、广告分析、IoT 数据分析等。
  • 高吞吐量写入： 能够以每秒数十万到数百万行的速度接收数据。
  • 大数据量存储： 能够高效存储 PB 级数据，并提供快速查询。
  • 明细数据分析： 能够直接查询原始明细数据，而不仅仅是预聚合数据。

ClickHouse 的局限性（不适合的场景）：

  • OLTP 工作负载： 不支持复杂的事务（如多语句事务、回滚），不适合频繁的单行更新和删除。
  • 低并发单行查询： 虽然可以处理，但其设计并非为高并发、低延迟的单行查询优化（如 SELECT * FROM table WHERE id = X）。
  • 强一致性要求： 提供的是最终一致性，不适合需要严格 ACID 事务的场景。
  • 复杂 JOIN： 虽然支持 JOIN，但通常推荐在大宽表中进行分析，或者通过物化视图预处理 JOIN 结果。

结语

列式存储并非 ClickHouse 独有，但 ClickHouse 凭借其在列式存储基础上的极致优化，包括 MergeTree 引擎的精心设计、丰富的压缩算法、革命性的向量化查询执行、以及对分布式架构的原生支持，使其在 OLAP 领域脱颖而出，成为处理大规模分析查询的利器。理解这些底层机制，能够帮助我们更好地利用 ClickHouse，并为数据驱动的决策提供强大支撑。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注