博客 / 工程

ClickHouse 23.2 版本发布

ClickHouse 团队

2023年3月9日 - 10 分钟阅读

23.2 Release Post.png

发布列车继续前进。我们非常激动地分享 23.2 版本中的更新。

而且，我们已经确定了 23.3 版本的发布日期，请立即注册参加 3 月 30 日上午 9:00（PST）/下午 6:00（CEST）的社区电话会议。

18 项新功能。
30 项性能优化。
43 个错误修复。

多项 SQL 语言功能和扩展的集成支持。但是，与往常一样，有一些值得关注的重点项目

PREWHERE 子句自 ClickHouse 的第一个 OSS 版本以来就已成为一项功能。此优化旨在减少查询需要读取的行数，并且在 22.2 之前的版本中使用了 2 步执行过程。当查询运行时，首先使用表的主键识别读取所需的粒度。这会识别一组粒度，每个粒度包含许多行（默认情况下为 8192 行）。但是，并非所有这些粒度内的行都将与主键上的筛选子句匹配 - 因为粒度可能包含一系列值，或者因为 WHERE 条件未使用主键。因此，为了识别正确的行并在读取 SELECT 列之前，需要进行额外的筛选。这是在使用 PREWHERE 的读取的第二阶段执行的，它允许进一步筛选 WHERE 子句中的主键列和非主键列。这需要读取粒度并使用线性扫描进行筛选。

ClickHouse 会根据内部启发式方法将列移动到 PREWHERE 阶段。用户也可以手动指定要使用的列，以防自动选择无效，方法是使用显式的 PREWHERE 子句。这些列中的每一列都将在读取的第二阶段独立筛选，并且只有那些满足所有条件的行才会在管道的后续阶段读取。

我们在下面将其可视化

single-step-prewhere(1).png

在 23.2 版本中，此 pre-where 优化已拆分为多个步骤。列按照从小到大（未压缩大小）的顺序进行筛选。从对列应用筛选器中识别的行可以用于进一步减少后续步骤中扫描的粒度。由于每个步骤都变得更加高效，因此所有步骤的总成本都会降低。我们在下面说明这一点

此行为目前需要通过设置 enable_multiple_prewhere_read_steps=1 启用。设置后，在大多数情况下，将 move_all_conditions_to_prewhere 设置为 true 是有意义的。虽然尚未默认启用，但我们建议用户在其查询中尝试此设置，并在我们的 slack 社区或作为 github 问题报告他们的发现。我们预计会看到明显的性能改进，尤其是在按大型列进行筛选时。

23.2 版本带来了对 Apache Iceberg 格式的读取支持。

Apache Iceberg 最初由 Netflix 开发，是一种高性能表格式，独立于任何特定的 SQL 引擎 - 允许任何 SQL 引擎（包括现在的 ClickHouse！）查询它。

这种表格式越来越受欢迎，并迅速成为数据湖中管理数据的行业标准。虽然 Parquet 已确立自己作为数据湖首选数据文件格式的地位，但表通常表示为位于存储桶或文件夹中的一组文件。这通常足以进行即席查询，但使得管理大型数据集变得繁琐，并且意味着 ClickHouse 等工具的表抽象充其量是松散建立的，不支持模式演变或写入一致性。对于 ClickHouse 而言，最重要的是，这种方法将依赖于文件列表操作 - 在 s3 等对象存储上可能很昂贵。数据筛选需要打开和读取所有数据，除了通过在命名方案上使用 glob 模式来限制文件的有限能力之外。

Iceberg 旨在通过以开放和可访问的方式将类似 SQL 表的功能引入数据湖中的文件来应对这些挑战。具体来说，Iceberg 提供

支持模式演变，以跟踪表随时间的变化
能够创建定义特定版本的数据快照。可以查询这些版本，允许用户在几代之间“时间旅行”。
支持快速回滚到先前版本的数据
自动对文件进行分区以协助筛选 - 从历史上看，用户需要手动执行此容易出错的任务并在更新中维护它。
查询引擎可以用来提供高级规划和筛选的元数据。

这些表功能由清单文件提供。这些清单维护底层数据文件的历史记录，其中完整描述了它们的模式、分区和文件信息。这种抽象支持不可变快照，这些快照以分层结构有效地组织，跟踪表中随时间的所有更改。

重要的是，底层文件格式不会更改，Apache Iceberg 支持 Parquet、ORC 和 Avro。

ClickHouse 目前支持通过 iceberg 表函数和 Iceberg 表引擎读取 Iceberg 格式的 v1 版本（v2 版本支持即将推出！）。下面我们为房价数据集提供这些示例，方法是计算过去 20 年英格兰最昂贵的城镇的平均价格及其最昂贵的街道。这些查询应该可以在您自己的 ClickHouse 实例上重现，此数据集是公开的。

使用表函数

SELECT
    town,
    round(avg(price)) AS avg_price,
    argMax(street, price) AS street
FROM iceberg('https://datasets-documentation.s3.eu-west-3.amazonaws.com/house_prices_iceberg/')
GROUP BY town
HAVING street != ''
ORDER BY avg(price) DESC
LIMIT 10

┌─town──────────────┬─avg_price─┬─street─────────┐
│ GATWICK           │  28232812 │ NORTH TERMINAL │
│ VIRGINIA WATER    │    903457 │ WEST DRIVE     │
│ CHALFONT ST GILES │    830274 │ PHEASANT HILL  │
│ COBHAM            │    720600 │ REDHILL ROAD   │
│ BEACONSFIELD      │    690689 │ AYLESBURY END  │
│ ESHER             │    638641 │ COPSEM LANE    │
│ KESTON            │    606303 │ WESTERHAM ROAD │
│ GERRARDS CROSS    │    601461 │ NARCOT LANE    │
│ ASCOT             │    559106 │ BAGSHOT ROAD   │
│ WEYBRIDGE         │    552827 │ THE HEIGHTS    │
└───────────────────┴───────────┴────────────────┘

10 rows in set. Elapsed: 18.151 sec. Processed 27.07 million rows, 1.37 GB (1.49 million rows/s., 75.50 MB/s.)

使用表引擎的等效查询

CREATE TABLE house_iceberg
ENGINE = Iceberg('https://datasets-documentation.s3.eu-west-3.amazonaws.com/house_prices_iceberg/')

SELECT
    town,
    round(avg(price)) AS avg_price,
    argMax(street, price) AS street
FROM house_iceberg
GROUP BY town
HAVING street != ''
ORDER BY avg(price) DESC
LIMIT 10

除了 v2 版本支持之外，我们还计划在未来版本中支持查询特定快照 - 目前 ClickHouse 仅查询最新快照。此外，Iceberg 提供的元数据文件包含数据文件本身的列统计信息，例如，我们计划利用的列的上限，以避免数据读取操作。

在 23.2 版本中，我们添加了对计算相关矩阵的支持。提醒一下，相关矩阵是一个表，其中包含表中所有可能值之间的相关系数。这代表了一种总结大型数据集并识别强相关或负相关的列的简单方法。这种计算被许多统计分析技术使用，从历史上看，它需要 ClickHouse 中非常复杂或多个查询。借助新的 corrMatrix 函数，此查询现在变得非常简单。

在下面的示例中，我们计算了开发人员经常密切关注的许多 github 指标的相关矩阵 - 最值得注意的是星数。我们将其限制为至少有 100 颗星的存储库。为此，我们使用了 Github Events 数据集，该数据集记录在我们测试数据集的一部分中，并在我们的演示环境 sql.clickhouse.com 中提供，供用户查询。

SELECT arrayMap(x -> round(x, 3), arrayJoin(corrMatrix(stars, issue_raised, follows, prs, forks, commit_comment_event, issues_commented))) AS correlation_matrix
FROM
(
    SELECT
        countIf(event_type = 'WatchEvent') AS stars,
        countIf(event_type = 'IssuesEvent') AS issue_raised,
        countIf(event_type = 'FollowEvent') AS follows,
        countIf(event_type = 'PullRequestEvent') AS prs,
        countIf(event_type = 'ForkEvent') AS forks,
        countIf(event_type = 'CommitCommentEvent') AS commit_comment_event,
        countIf(event_type = 'IssueCommentEvent') AS issues_commented
    FROM github_events
    GROUP BY repo_name
    HAVING stars > 100
)

┌─correlation_matrix──────────────────────┐
│ [1,0.298,0.003,0.22,0.552,0.063,0.291]  │
│ [0.298,1,0.035,0.376,0.223,0.104,0.557] │
│ [0.003,0.035,1,0.004,0.004,0.015,0.003] │
│ [0.22,0.376,0.004,1,0.277,0.151,0.685]  │
│ [0.552,0.223,0.004,0.277,1,0.057,0.262] │
│ [0.063,0.104,0.015,0.151,0.057,1,0.175] │
│ [0.291,0.557,0.003,0.685,0.262,0.175,1] │
└─────────────────────────────────────────┘

7 rows in set. Elapsed: 44.847 sec. Processed 5.72 billion rows, 51.60 GB (127.65 million rows/s., 1.15 GB/s.)

回想一下，矩阵中每个条目的值代表皮尔逊相关系数，其中 1 代表强线性关系，-1 代表负相关关系，0 代表根本没有相关性。

上面的矩阵最好使用热图进行可视化。下面我们使用 Superset。

我们将得出结论留给读者，但星星似乎与其他 repo 活动的相关性很差，除了可能的 forks 数量之外。

上个月，我们宣布了我们用于 ClickHouse 的开源 Kafka Connect Sink 的 beta 版本。为了响应我们社区的需求，我们现在可以宣布此连接器与 AWS 的托管产品 MSK 完全兼容。

在 ClickHouse，我们坚信支持我们的开源生态系统对于采用和确保用户成功至关重要。本月本着这种精神，我们宣布发布了我们用于 OSS 可视化工具 Metabase 的 ClickHouse 插件的 GA 版本。与 Metabase 团队合作，此插件现在也可在 Metabase Cloud 中使用。对于需要 ClickHouse 可视化工具的用户，我们建议用户观看我们与 Metabase 的朋友们最近举办的网络研讨会。

分享此文章