ClickHouse 22.3 LTS 版本发布

全新 ClickHouse 22.3 版本已发布！这是一个长期支持 (LTS) 版本——它将在 2023 年 3 月之前收到安全更新和重要的错误修复。

此版本包含来自 86 位贡献者的 1308 个新提交，其中包括 25 位新贡献者

1lann, Anish Bhanwala, Eugene Galkin, HaiBo Li, Hongbin, Jianmei Zhang, LAL2211, Lars Eidnes, Miel Donkers, NikitaEvs, Nir Peled, Robert Schulze, SiderZhang, Varinara, Xudong Zhang, Yong Wang, cwkyaoyao, heleihelei, kashwy, lincion, metahys, rfraposa, shuchaome, tangjiangling, zhangyifan27.

22.3 版本的更改主要集中在功能成熟度、安全性和可靠性方面。一些实验性功能已准备好用于生产环境

ClickHouse Keeper 是我们 ZooKeeper 的替代品。它实现了 ZooKeeper 协议和数据模型；并且可以作为 ZooKeeper（最高版本 3.5）与 ClickHouse 和其他应用程序的直接替代品。它可以作为专用组件工作，也可以嵌入到 clickhouse-server 中。

我们很自豪它通过了 Jepsen 测试和持续集成。这包括 ZooKeeper 的测试以及用于更好覆盖率的附加测试。此外，它还通过了 ClickHouse 功能和集成测试、压力测试和模糊测试。

自 22.3 版本以来，我们确保它在读取和写入方面都比 ZooKeeper 更快，同时消耗更少的内存。日志和快照的磁盘使用量也更低。磁盘上和传输中的数据都经过校验和，以防止硬件故障。请求延迟的更高百分位数更低。这要归功于 Zhang Li Star 和 Alexander Sapin 的贡献。

截至 22.3 版本，ClickHouse Keeper 已准备好用于生产环境！事实上，它已经在生产环境中使用了半年多，因此您不会是第一个生产用户。

64 位 ARM CPU 架构 (AArch64) 在云服务器应用程序以及笔记本电脑和工作站中变得越来越流行。有没有考虑过在网络设备和移动设备上使用 ClickHouse？你知道吗？ClickHouse 可以在所有这些设备上运行，并从中榨取每一丝性能。

我们于 2016 年 2 月开始将 ClickHouse 移植到 AArch64，从那时起，我们检查了 13 种不同的 CPU 型号：APM X-Gene；Cavium ThunderX 1, 2；Raspberry Pi；Pinebook；Google Pixel；Apple M1, M1 Max；华为 Taishan；AWS Graviton 1, 2, 3；Ampere Altra。ARM CPU 制造商之间存在巨大的多样性，我们很高兴为此提供支持。我们还维护了不同硬件的对比基准测试的集合。

22.3 版本在 AArch64 支持方面有两个主要里程碑

1. 持续集成，100% 功能测试通过。
2. 完全支持发布版本构建：deb、rpm、apk、tgz、single-binary 和 Docker。

这要归功于 Mikhail Shiryaev 的工作。自 22.3 版本以来，AArch64 上的 ClickHouse 已准备好用于生产环境！

ClickHouse 对 x86_64 指令集架构有更多特定优化，而对 AArch64 的特定优化只有几个，但即便如此，它在主要云提供商的 AArch64 上仍能提供更好的性价比。

某些 x86 特定的功能在 AArch64 上被禁用：对 Hyperscan 的支持、对来自 PMU 的硬件指标的支持。某些功能未包含在构建中，例如 GRPC API 支持。不建议运行混合架构集群，尽管目前尚无已知问题。

接下来期待什么？我们正在进行 PowerPC 64 little-endian 和 RISC-V 64 的开发。如果您对其他 CPU 架构感兴趣，请告知我们。

对基于 S3 的 VFS 的实验性支持已存在约两年。这是故事

• Vladimir Chebotarev 的用于数据导入和导出的 s3 函数
• Igor Mineev 和 Alexander Sapin 的磁盘、卷和存储策略
• Vladimir Chebotarev 的数据部分在磁盘之间的自动和用户触发移动
• Alexander Burmak 的虚拟文件系统接口
• Pavel Kovalenko、Grigory Pervakov 和 Anton Ivashkin 的基于 s3 的 VFS 实现
• Alexey Milovidov、Kseniia Sumarokova 和 Alexander Sapin 的异步读取
• Alexander Sapin 的完整功能测试覆盖率、正确性和可靠性

截至 22.3 版本，我们确保在 s3 之上的最大查询性能，并对每次提交进行持续测试。对 s3 上 MergeTree 和 ReplicatedMergeTree 操作的支持已准备好用于生产环境。

尽管一些新功能尚未准备好用于生产环境：“零拷贝复制”（如果一个区域中有多个副本，则确保只有一个数据副本）和本地缓存。已针对 AWS S3 和 Minio 执行了测试。GCP 上存在已知问题。

对于以前的版本，我们使用了 Yandex Cloud 中的服务器。自 22.3 版本以来，我们已将我们的基础设施迁移到不同的位置。

持续集成和测试已移至美国 AWS 数据中心。我们还在开源中发布了所有构建和测试运行程序。构建过程已实现可重现。您可以自行运行构建，并获得与官方二进制文件字节相同且无法区分的二进制文件。构建过程是 hermetic 的，并且不依赖于操作系统发行版和环境。最终发布版本构建存储在 JFrog Artifactory 中，并在 packages.clickhouse.com 上提供。

这项工作由 Mikhail Shiryaev、Alexander Sapin 和 Alexey Milovidov 完成。

请阅读这些更改的动机。

使用 X.509 客户端证书的身份验证由 Eungenue 贡献。Heena Bansal 贡献了两个功能：一个用于禁用用户的纯文本密码或无密码的开关；过滤 MySQL、PostgreSQL 联邦查询中的传出连接。

我们认为模糊测试是构建可靠软件的绝对需要。模糊测试的主要原则是：应该有更多的模糊测试。因此，我们在 ClickHouse CI 中有许多模糊测试方法：LLVM 的 libFuzzer、基于 AST 的查询模糊器、Ad-hoc SQL 函数模糊器、线程调度顺序的随机化、时区的随机化、SQLancer（逻辑模糊器）、压力测试和 Jepsen 测试。

但这还不够。

自 22.3 版本以来，我们添加了功能测试中查询设置的随机化。因此，我们可以在不同设置的每种组合下运行测试。

我们还为向后兼容性添加了自动化测试。它尝试创建每个可能的数据库、表和字典，然后安装之前的 ClickHouse 版本并检查它是否会成功启动。这使我们能够了解新功能是否会阻止版本降级。

我们非常热衷于测试，以至于我们决定为测试添加自动化测试。每当有人贡献错误修复时，我们会自动检查它是否包含测试，并且这些测试在之前的 ClickHouse 版本上会失败。

好吧，我花了你 15 分钟的时间来讲述安全性、可靠性、合规性、透明度……但是乐趣在哪里？

在 22.3 版本中，我们有一个新的实验性功能——支持动态子列和半结构化数据！

假设您有一堆 JSON 并且想要分析它——无需在表中指定数据类型。并且您希望您的表自动适应模式更改，自动添加新列。以及具有深度嵌套的分层对象和数组的所有内容！现在这是可能的，并且它像魔法一样工作。

让我用一个使用 GitHub API 的示例来演示它。

我从 GH Explorer 获取了按星数排序的 GitHub 存储库列表。然后，我开始使用以下脚本从 GitHub API 查询最受欢迎的存储库的元数据

cut -f1 repos.tsv | while read repo; do 
    [ -f "${repo/\//@}.json" ] && continue; 
    echo $repo; 
    while true; 
        do curl -sS -u 'alexey-milovidov:***' "https://api.github.com/repos/${repo}" > ${repo/\//@}.json; 
        grep -F 'API rate limit exceeded for user' ${repo/\//@}.json && sleep 60 || break; 
    done;
done

（有时我有一种写 shell 脚本的负罪感乐趣）

数据包含详细信息，例如主要存储库语言、实际星数、fork 和订阅者。响应 JSON 对象也具有高度冗余。

我可以将所有这些加载到 ClickHouse 中，而无需关心数据类型和嵌套级别

SET allow_experimental_object_type = 1;
CREATE TABLE repositories (data JSON) ENGINE = MergeTree;
INSERT INTO repositories FROM INFILE '*.json' FORMAT JSONAsObject;

然后计算一些有趣的东西

SELECT
    1 + rowNumberInAllBlocks() AS n,
    *
FROM
(
    SELECT DISTINCT
        data.full_name,
        data.stargazers_count,
        data.license.name
    FROM repositories
    WHERE data.language = 'C++'
    ORDER BY data.stargazers_count DESC
)
LIMIT 20

Query id: 175ccd7e-d689-493b-b0bc-57a584f09590

┌──n─┬─data.full_name────────────────────────┬─data.stargazers_count─┬─data.license.name───────────────────────┐
│  1 │ tensorflow/tensorflow                 │                164038 │ Apache License 2.0                      │
│  2 │ electron/electron                     │                101133 │ MIT License                             │
│  3 │ microsoft/terminal                    │                 82110 │ MIT License                             │
│  4 │ opencv/opencv                         │                 60681 │ Other                                   │
│  5 │ apple/swift                           │                 59164 │ Apache License 2.0                      │
│  6 │ pytorch/pytorch                       │                 55051 │ Other                                   │
│  7 │ protocolbuffers/protobuf              │                 53704 │ Other                                   │
│  8 │ x64dbg/x64dbg                         │                 38319 │ GNU General Public License v3.0         │
│  9 │ BVLC/caffe                            │                 32370 │ Other                                   │
│ 10 │ nlohmann/json                         │                 29284 │ MIT License                             │
│ 11 │ google/leveldb                        │                 28826 │ BSD 3-Clause "New" or "Revised" License │
│ 12 │ topjohnwu/Magisk                      │                 24989 │ GNU General Public License v3.0         │
│ 13 │ microsoft/calculator                  │                 24045 │ MIT License                             │
│ 14 │ CMU-Perceptual-Computing-Lab/openpose │                 23777 │ Other                                   │
│ 15 │ huihut/interview                      │                 23490 │ Other                                   │
│ 16 │ cmderdev/cmder                        │                 23453 │ MIT License                             │
│ 17 │ ClickHouse/ClickHouse                 │                 22957 │ Apache License 2.0                      │
│ 18 │ facebook/rocksdb                      │                 22198 │ Other                                   │
│ 19 │ mongodb/mongo                         │                 21409 │ Other                                   │
│ 20 │ apache/incubator-mxnet                │                 19938 │ Apache License 2.0                      │
└────┴───────────────────────────────────────┴───────────────────────┴─────────────────────────────────────────┘

因此，ClickHouse 是 GitHub 上第 17 个最受欢迎的 C++ 存储库。不错。

让我解释一下动态子列是如何工作的

有一种新的 JSON 数据类型。您也可以将其写为 Object('JSON')。此数据类型可以解析任意 JSON，并且它包含动态子列。您可以在同一张表中同时拥有常规类型和 JSON 类型。动态子列在插入时创建，并像常规列一样以面向列的格式存储，因此查询这些子列与查询常规列一样高效。数据类型是自动推断的，可以在后台合并期间转换，因此您可以在不同的 INSERT 中使用不同的模式。查询使用自然语法，例如 data.license.name[1]，而不是 JSONExtractString(data, 'license', 'name', 1) 或 JSON_QUERY(data, '$.license.name[1]')。

此功能由 Anton Popov 实现。它在 22.3 版本中可用于预览。我们很乐意听取您的反馈。

ClickHouse 中有很多性能优化，每个新版本 ClickHouse 都会变得更快。

Maksim Kita 通过排序优化（如果排序键由多个数字列表示），将插入到 MergeTree 表中的性能提高了两倍。

如果您有在 WHERE IN 中包含大量列表的 SELECT 查询，则这些查询在 ClickHouse 22.3 中将快 3 倍。

SELECT * FROM table
WHERE key IN (111, 222, ... a megabyte of something)

当 ClickHouse 从本地文件系统读取数据时，数据会被操作系统缓存在页面缓存中。在具有多通道内存的服务器上，从页面缓存读取多个线程的典型性能约为 50 GB/秒，因此热查询非常快。

但是，如果 ClickHouse 从远程文件系统读取数据，则操作系统看不到这些读取操作，也无法使用页面缓存。因此，我们需要在 ClickHouse 中使用我们自己的页面缓存。自 22.3 版本以来，ClickHouse 具有远程文件系统的缓存，由 Ksenia Sumarokova 实现。此功能可用于预览。

它在性能方面带来了巨大的改进。缓存是混合的——它同时使用本地磁盘和 RAM。

阅读 22.3 版本的完整更新日志并关注路线图。