本文字数：10774；估计阅读时间：27 分钟
审校：庄晓东（魏庄）
本文在公众号【ClickHouseInc】首发
北半球迎来春天，也是 ClickHouse 发布新版本的时候了。
发布概要
本次ClickHouse 24.3版本包含了12个新功能🎁、18个性能优化🛷、60个bug修复🐛
新的贡献者
一如既往，我们诚挚地欢迎所有在 24.3 版本中新加入的贡献者！ClickHouse 之所以备受欢迎，很大程度上要归功于社区的努力贡献。看到社区不断壮大总是令人感到谦卑。
以下是新贡献者的名字：
johnnymatthews, AlexeyGrezz, Aliaksei Khatskevich, Aris Tritas, Artem Alperin, Blacksmith, Blargian, Brokenice0415, Charlie, Dan Wu, Daniil Ivanik, Eyal Halpern Shalev, Fille, HowePa, Jayme Bird, Joshua Hildred, Juan Madurga, Kirill Nikiforov, Lino Uruñuela, LiuYuan, Maksim Alekseev, Marina Fathouat, Mark Needham, Mathieu Rey, MochiXu, Nataly Merezhuk, Nickolaj Jepsen, Nikita Fomichev, Nikolai Fedorovskikh, Nikolay Edigaryev, Nikolay Monkov, Nikolay Yankin, Oxide Computer Company, Pablo Musa, PapaToemmsn, Peter, Pham Anh Tuan, Roman Glinskikh, Ronald Bradford, Shanfeng Pang, Shaun Struwig, Shuai li, Shubham Ranjan, Tim Liou, Waterkin, William Schoeffel, YenchangChan, Zheng Miao, avinzhang, beetelbrox, bluikko, chenwei, conicliu, danila-ermakov, divanik, edpyt, jktng, josh-hildred, mikhnenko, mochi, nemonlou, qaziqarta, rogeryk, shabroo, shuai-xu, sunny, sunny19930321, tomershafir, una, unashi, Кирилл Гарбар, 豪肥肥
默认启用的分析器
由Maksim Kita、Nikolai Kochetov、Dmitriy Novik、Vladimir Cherkasov、Igor Nikonov、Yakov Olkhovskiy 等人共同贡献
分析器是 ClickHouse 中的一种新的查询分析和优化基础设施，在过去几年中经过精心打造。它提供了更好的兼容性和功能完整性，并且可以进行复杂的查询优化。
尽管我们之前对分析器进行了实验性支持，但从 24.3 版本开始，该功能已经升级为 beta 版，并默认启用。
如果您不想使用它，仍然可以通过配置以下设置来禁用：
SET allow_experimental_analyzer = 0;在 24.4 或 24.5 版本中，我们计划将分析器升级为生产版本，并移除旧的查询分析实现。
旧的查询运行时不能很好地处理使用嵌套公共表表达式 (CTE) 和连接的查询。例如，下面的查询应该返回数字 1：
WITH example AS (
SELECT '2021-01-01' AS date, 1 AS node, 1 AS user
)
SELECT extra_data
FROM (
SELECT join1.*
FROM example
LEFT JOIN (
SELECT '2021-01-01' AS date, 1 AS extra_data
) AS join1
ON example.date = join1.date
LEFT JOIN (
SELECT '2021-01-01' AS date
) AS join2
ON example.date = join2.date);但是，如果我们在旧的查询运行时中运行它（在 24.3 版本中可以通过设置allow_experimental_analyzer = 0 来模拟），我们将得到以下错误：
Received exception:
Code: 47. DB::Exception: Missing columns: 'extra_data' while processing query: 'WITH example AS (SELECT '2021-01-01' AS date, 1 AS node, 1 AS user) SELECT extra_data FROM (SELECT join1.* FROM example LEFT JOIN (SELECT '2021-01-01' AS date, 1 AS extra_data) AS join1 ON example.date = join1.date LEFT JOIN (SELECT '2021-01-01' AS date) AS join2 ON example.date = join2.date) SETTINGS allow_experimental_analyzer = 0', required columns: 'extra_data' 'extra_data'. (UNKNOWN_IDENTIFIER)分析器还支持同一查询中的多个数组连接 (ARRAY JOIN) 子句，这在以前是不可能的。
假设我们有以下 JSON 文件，其中包含订单、产品和评论。
[
{
"order_id": 1,
"products": [
{
"product_id": 101,
"name": "Laptop",
"reviews": [
{"review_id": 1001, "rating": 5, "comment": "Excellent product!"},
{"review_id": 1002, "rating": 4, "comment": "Very good, but could be cheaper."}
]
},
{
"product_id": 102,
"name": "Smartphone",
"reviews": [
{"review_id": 2001, "rating": 5, "comment": "Best phone I've ever had."},
{"review_id": 2002, "rating": 3, "comment": "Battery life could be better."}
]
}
]
},
{
"order_id": 2,
"products": [
{
"product_id": 103,
"name": "Headphones",
"reviews": [
{"review_id": 3001, "rating": 5, "comment": "Great sound quality!"},
{"review_id": 3002, "rating": 2, "comment": "Stopped working after a month."}
]
},
{
"product_id": 104,
"name": "E-book Reader",
"reviews": [
{"review_id": 4001, "rating": 4, "comment": "Makes reading so convenient!"},
{"review_id": 4002, "rating": 5, "comment": "A must-have for book lovers."}
]
}
]
}
]我们希望对数据进行处理，以便在产品信息旁边逐行查看评论。我们可以通过以下查询实现这一目标：
SELECT
review.rating AS rating,
review.comment,
product.product_id AS id,
product.name AS name
FROM `products.json`
ARRAY JOIN products AS product
ARRAY JOIN product.reviews AS review
ORDER BY rating DESC
┌─rating─┬─review.comment───────────────────┬──id─┬─name──────────┐
1. │ 5 │ Excellent product! │ 101 │ Laptop │
2. │ 5 │ Best phone I've ever had. │ 102 │ Smartphone │
3. │ 5 │ Great sound quality! │ 103 │ Headphones │
4. │ 5 │ A must-have for book lovers. │ 104 │ E-book Reader │
5. │ 4 │ Very good, but could be cheaper. │ 101 │ Laptop │
6. │ 4 │ Makes reading so convenient! │ 104 │ E-book Reader │
7. │ 3 │ Battery life could be better. │ 102 │ Smartphone │
8. │ 2 │ Stopped working after a month. │ 103 │ Headphones │
└────────┴──────────────────────────────────┴─────┴───────────────┘现在，我们可以将元组元素视为列，这意味着我们可以传入评论元组的所有元素并格式化输出：
SELECT format('{}: {} [{}]', review.*) AS r
FROM `products.json`
ARRAY JOIN products AS product
ARRAY JOIN product.reviews AS review; ┌─r──────────────────────────────────────────┐
1. │ Excellent product!: 5 [1001] │
2. │ Very good, but could be cheaper.: 4 [1002] │
3. │ Best phone I've ever had.: 5 [2001] │
4. │ Battery life could be better.: 3 [2002] │
5. │ Great sound quality!: 5 [3001] │
6. │ Stopped working after a month.: 2 [3002] │
7. │ Makes reading so convenient!: 4 [4001] │
8. │ A must-have for book lovers.: 5 [4002] │
└────────────────────────────────────────────┘我们还可以为匿名函数创建别名：
WITH x -> round(x * 1.2, 2) AS addTax
SELECT
round(randUniform(8, 20), 2) AS amount,
addTax(amount)
FROM numbers(5)
┌─amount─┬─addTax(amount)─┐
1. │ 15.76 │ 18.91 │
2. │ 19.27 │ 23.12 │
3. │ 8.45 │ 10.14 │
4. │ 9.46 │ 11.35 │
5. │ 13.02 │ 15.62 │
└────────┴────────────────┘此外，还有许多其他改进，您可以在演示幻灯片中了解到。【https://presentations.clickhouse.com/release_24.3/】
从远程磁盘来挂载分区
由 Unalian 贡献
在 ClickHouse 中，从另一个磁盘附加表是一个早已存在的功能，但在我们看下一个功能之前，让我们快速回顾一下它的工作原理。
ClickHouse/web-tables-demo 仓库包含了英国房价数据集的数据库文件。我们可以通过运行以下命令来附加该表：
ATTACH TABLE uk_price_paid_web UUID 'cf712b4f-2ca8-435c-ac23-c4393efe52f7'
(
price UInt32,
date Date,
postcode1 LowCardinality(String),
postcode2 LowCardinality(String),
type Enum8('other' = 0, 'terraced' = 1, 'semi-detached' = 2, 'detached' = 3, 'flat' = 4),
is_new UInt8,
duration Enum8('unknown' = 0, 'freehold' = 1, 'leasehold' = 2),
addr1 String,
addr2 String,
street LowCardinality(String),
locality LowCardinality(String),
town LowCardinality(String),
district LowCardinality(String),
county LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY (postcode1, postcode2, addr1, addr2)
SETTINGS disk = disk(type = web, endpoint = 'https://raw.githubusercontent.com/ClickHouse/web-tables-demo/main/web/');UUID 需要保持原样，否则无法正确附加。当您运行附加表命令时，您不会看到错误，但是生成的查询将不会返回任何结果；
然后，我们可以运行以下查询，按年份分组查找最近 10 年的平均房价：
SELECT
toYear(date) AS year,
round(avg(price)) AS price,
bar(price, 0, 1000000, 80)
FROM uk_price_paid_web
GROUP BY year
ORDER BY year ASC;
┌─year─┬──price─┬─bar(price, 0, 1000000, 80)──────┐
1. │ 2022 │ 387415 │ ██████████████████████████████▉ │
2. │ 2021 │ 382166 │ ██████████████████████████████▌ │
3. │ 2020 │ 376855 │ ██████████████████████████████▏ │
4. │ 2019 │ 352562 │ ████████████████████████████▏ │
5. │ 2018 │ 350913 │ ████████████████████████████ │
6. │ 2017 │ 346486 │ ███████████████████████████▋ │
7. │ 2016 │ 313543 │ █████████████████████████ │
8. │ 2015 │ 297282 │ ███████████████████████▊ │
9. │ 2014 │ 280029 │ ██████████████████████▍ │
10. │ 2013 │ 256928 │ ████████████████████▌ │
└──────┴────────┴─────────────────────────────────┘
10 rows in set. Elapsed: 3.249 sec. Processed 27.40 million rows, 164.42 MB (8.43 million rows/s., 50.60 MB/s.)
Peak memory usage: 209.20 MiB.这个查询所需的时间取决于您运行它的机器的互联网带宽速度 - 数据并不存储在本地，因此在运行查询之前需要将数据拉取下来。
24.3 版本中已经更新了ATTACH PARITION命令，使您可以从不同/远程磁盘附加数据，这样就可以轻松地将数据库从 GitHub 复制到我们的机器上。让我们首先创建另一个具有相同模式的表：
CREATE TABLE uk_price_paid_local
(
price UInt32,
date Date,
postcode1 LowCardinality(String),
postcode2 LowCardinality(String),
type Enum8('other' = 0, 'terraced' = 1, 'semi-detached' = 2, 'detached' = 3, 'flat' = 4),
is_new UInt8,
duration Enum8('unknown' = 0, 'freehold' = 1, 'leasehold' = 2),
addr1 String,
addr2 String,
street LowCardinality(String),
locality LowCardinality(String),
town LowCardinality(String),
district LowCardinality(String),
county LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY (postcode1, postcode2, addr1, addr2);接着，我们可以将来自 uk_price_paid_web 的数据附加到 uk_price_paid_local 表中：
ALTER TABLE uk_price_paid_local
ATTACH PARTITION () FROM uk_price_paid_web;
0 rows in set. Elapsed: 4.669 sec.这个命令会将数据库文件从 GitHub 仓库复制到我们的机器上。这样做比执行 INSERT INTO...SELECT AS 查询要快得多，因为后者需要先将数据从 GitHub 反序列化为内存数据结构，再将其序列化回本地数据库文件。
现在，让我们运行查询，查找针对本地表的平均销售价格：
SELECT
toYear(date) AS year,
round(avg(price)) AS price,
bar(price, 0, 1000000, 80)
FROM uk_price_paid_local
GROUP BY year
ORDER BY year DESC
LIMIT 10;
┌─year─┬──price─┬─bar(price, 0, 1000000, 80)──────┐
1. │ 2022 │ 387415 │ ██████████████████████████████▉ │
2. │ 2021 │ 382166 │ ██████████████████████████████▌ │
3. │ 2020 │ 376855 │ ██████████████████████████████▏ │
4. │ 2019 │ 352562 │ ████████████████████████████▏ │
5. │ 2018 │ 350913 │ ████████████████████████████ │
6. │ 2017 │ 346486 │ ███████████████████████████▋ │
7. │ 2016 │ 313543 │ █████████████████████████ │
8. │ 2015 │ 297282 │ ███████████████████████▊ │
9. │ 2014 │ 280029 │ ██████████████████████▍ │
10. │ 2013 │ 256928 │ ████████████████████▌ │
└──────┴────────┴─────────────────────────────────┘
10 rows in set. Elapsed: 0.045 sec.速度快了很多！
S3 Express 单可用区支持
由 Nikita Taranov 贡献
在 2023 年 11 月，亚马逊宣布支持 S3 Express 单可用区存储类型，旨在提供更低的延迟和更高的每秒读取次数，但成本却高出很多（7 倍），而可用性却较低。
为了支持这种新的存储类型，AWS/S3 库进行了更新，截至 24.3 版本，ClickHouse 已支持从这些bucket读取和写入。您可以在 S3 Express 文档中了解更多信息。
让我们来看看如何在 S3 Express bucket中查询数据以及可能的性能优势。
最近我们参加了一个查询 1 万亿行数据的挑战，这些数据分布在一个 S3 bucket中的 10 万个 Parquet 文件中。我们将所有这些文件都复制到了一个 S3 Express bucket中。
接着，我们在与 S3 Express bucket相同的区域和可用区中创建了一个 EC2 实例（这一点很重要，因为 Express 是特定于 AZ 的）。我们选择了 c7gn.16xlarge 实例类型，其网络带宽为每秒 125 GB - 这应该足够满足我们的需求了。
然后，我们下载并安装了 ClickHouse，并在配置文件中添加了我们的 S3 Express bucket的条目：
<s3>
<perf-bucket-url>
<endpoint>https://super-fast-clickhouse--use1-az4--x-s3.s3express-use1-az4.us-east-1.amazonaws.com</endpoint>
<region>us-east-1</region>
</perf-bucket-url>
</s3>在查询bucket时，如果您没有指定该配置，将会收到以下错误：
Region should be explicitly specified for directory buckets现在我们已经完成设置，是时候来看看查询了。首先，我们将计算所有文件中记录的数量。由于我们正在查询 Parquet 文件，我们将能够从每个文件的 Parquet 元数据中计算结果，因此不需要下载每个文件。
让我们在普通的 S3 bucket上运行它：
SELECT count()
FROM s3('https://clickhouse-1trc.s3.amazonaws.com/1trc/measurements-*.parquet', '<key>', '<secret>') SETTINGS schema_inference_use_cache_for_s3=0;
1 row in set. Elapsed: 219.933 sec. Processed 1.00 trillion rows, 11.30 MB (4.55 billion rows/s., 51.36 KB/s.)现在我们来看看在 S3 Express 上的查询情况。S3 Express API 不支持文件路径中的通配符表达式，所以我们将返回bucket中的所有文件。这也会返回根目录，我们将通过编写 WHERE 子句来删除根目录（这是我们需要解决的一个问题）。
SELECT count()
FROM s3('https://super-fast-clickhouse--use1-az4--x-s3.s3express-use1-az4.us-east-1.amazonaws.com/1trc/*', '<key>', '<secret>', 'Parquet')
WHERE _file LIKE '%.parquet'
SETTINGS schema_inference_use_cache_for_s3 = 0
┌───────count()─┐
1. │ 1000000000000 │ -- 1.00 trillion
└───────────────┘
1 row in set. Elapsed: 29.544 sec. Processed 1.00 trillion rows, 0.00 B (33.85 billion rows/s., 0.00 B/s.)
Peak memory usage: 99.29 GiB.我们运行了这些查询几次，结果都相似。对于这个查询，我们看到查询性能几乎提高了 7 倍。
在 S3 Express 中存储数据的成本是每 GB 0.16 美元，而在普通bucket中是每 GB 0.023 美元。因此，这种 7 倍的性能提升伴随着存储成本的 7 倍增加。
现在，让我们看看如果我们运行来自 1 万亿行数据挑战的实际查询，该查询按站点分组计算最小、最大和平均测量值。这个查询需要我们下载所有 10 万个文件，ClickHouse 将会并行执行。对于这个查询来说，延迟不那么重要，所以我们不应该期望像对计数查询那样得到那么大的性能提升。
首先是普通bucket：
SELECT
station,
min(measure),
max(measure),
round(avg(measure), 2)
FROM s3('https://clickhouse-1trc.s3.amazonaws.com/1trc/measurements-*.parquet', '', '')
GROUP BY station
ORDER BY station ASC
FORMAT `Null`
0 rows in set. Elapsed: 3087.855 sec. Processed 1.00 trillion rows, 2.51 TB (323.85 million rows/s., 813.71 MB/s.)
Peak memory usage: 98.87 GiB.这个查询花了略超过 51 分钟。那么使用 S3 Express 呢？
SELECT
station,
min(measure),
max(measure),
round(avg(measure), 2)
FROM s3('https://super-fast-clickhouse--use1-az4--x-s3.s3express-use1-az4.us-east-1.amazonaws.com/1trc/*', '', '', 'Parquet')
WHERE _file LIKE '%.parquet'
GROUP BY station
ORDER BY station ASC
FORMAT `Null`
SETTINGS schema_inference_use_cache_for_s3 = 0
0 rows in set. Elapsed: 1227.979 sec. Processed 1.00 trillion rows, 2.51 TB (814.35 million rows/s., 2.05 GB/s.)
Peak memory usage: 98.90 GiB.这个查询只花了略超过 20 分钟，所以这次的性能提升大约是 2.5 倍。
总的来说，S3 Express 在等价价格增加的情况下提供了显著降低查询延迟的优势。这一点在存在许多小文件且延迟占据查询时间主导地位的情况下尤为重要。而在必须下载较大文件并且查询可以并行执行的情况下，Express 层的好处可能不那么明显。
征稿启示
面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com
联系我们
手机号：13910395701
邮箱：Tracy.Wang@clickhouse.com
满足您所有的在线分析列式数据库管理需求
![pwn--realloc [CISCN 2019东南]PWN5](https://img-blog.csdnimg.cn/direct/c63f2dba8fc7469ebc4ec33f46f57fa7.png)
