ClickHouse 特性 | 一文读懂 ClickHouse V22.8 新版本重要特性-技术圈

1.背景介绍

各位 ClickHouse 圈友们！ClickHouse 又双叒叕发布新版本了。

大家都知道ClickHouse的发版节奏非常快，从官网发布记录来看，2022年依旧保持了一个月一个大版本的节奏，详情可以参阅ClickHouse 2022 Changelog(https://clickhouse.com/docs/en/whats-new/changelog/)。除了主版本之外，小版本就更多了，可见 ClickHouse 社区非常的活跃，内核迭代效率非常高。在此也呼吁国内的开发者小伙伴们多多参与到 ClickHouse 社区建设活动中。

今天给大家重点介绍 ClickHouse 社区最新版本的 LTS 版本 - V22.8 LTS 。LTS 全称是Long Term Support 长期支持版。LTS 版本是社区官方推荐的内核功能稳定，可以用于生产环境，且会长期进行稳维护升级的版本系列，也是被社区用户最广泛使用的版本，阿里云也于近期正式提供了全托管的企业级 ClickHouse V22.8 版本，大家可以到阿里云官网搜索体验。

闲言少叙，咱们一起来揭开 V22.8 版本的面纱，看看有哪些值得关注的重要特性发布。

2.特性介绍

日期&时间类型扩展

扩展 Date32 和 DateTime64 类型，将日期支持范围从之前版本的 1925年-2283年，扩展到支持 1900年-2299 年。需要注意的是，此特性变更不兼容之前的版本，尤其是对于超出日期边界值的转化逻辑。在之前的版本中1899-01-01会被强制转换为1925-01-01，而新的版本中则会转换为 1900-01-01。

日期类型精度转化为可设置精度参数，最大为 8 位，也就是达到微秒级精度，可覆盖所有日期支持范围内的时间值。假如设置了 9 位的时间精度参数，则精度进一步增加，但是需要注意最大时间范围仅仅支持到 2262-04-11 23:47:16 UTC。

对日期类型的扩展，将增加对实际业务的支持力度，尤其是对于有实际日期时间类型依赖的业务，例如会员生日的存储分析支持。

轻量 Delete 及语法支持

V22.8 LTS 对于 MergeTree 引擎表，支持标准的 DELETE FROM SQL 语法，同时实现了“轻量” Delete 逻辑。在之前的版本中，ClickHouse 的 DELETE 操作是 Mutation 类操作，所有的 DELETE 事件是通过单独文件进行记录存储，然后基于内核调度不定时的异步执行完成；执行过程也比较重，需要定位到相应的记录位置，进行物理删除。新版本中 Delete 基于 ClickHouse 的列更新机制，在数据分区中增加了系统虚拟列“_row_exists ”，通过 update_row_exists=0 where predicate 来标记列处于“已删除状态”，实现更加轻量，因此性能提升明显。语法差异如下：

旧版本 Delete 语法

ALTER TABLE [db.]table [ON CLUSTER cluster] DELETE WHERE filter_expr

新版本 Delete 语法

DELETE FROM [db.]table [WHERE expr]

举例如下：

DELETE FROM hits WHERE Title LIKE '%hello%' ;

所以轻量的 DELETE 也可以说是社区用户广泛期待的能力，从开发者的角度来看，标准 SQL 语法的支持，相比较之前的 Mutation 类操作方式，增强了开发的便利性。从官方的测试性能结果来看，在单表1亿记录总量，110个part规模下，轻量 Delete 的性能较之前版本提升了近40倍左右，性能提升明显。

但是需要注意的是，虽然有了标准 Delete From SQL 语法的支持以及轻量实现，但当前的 Delete 实现默认仍然是异步执行。所以 Delete 操作的结果并不是实时反馈在查询结果上的，并不能等同于在线处理类数据库的实时删除效果，也不能将 ClikHouse 应用于 TP 类型的在线业务类场景。官网强调 “this new feature does not make ClickHouse an HTAP DBMS”。

文件数据分布式并行写入

在 ClickHouse 早期的版本里支持了 S3 表函数，用于支持从 S3 进行数据导入操作，但是数据写入过程是串行的，面向集群中单台 ClickHouse Server 进行写入，典型场景写入效率通常是每秒百万行记录。

V22.8 版本中新增支持 S3 数据的分布式并行写入模式。当ClickHouse目标表是多副本 Replicated 或者是 Distributed 分布式表时，写入过程将跨集群多 Server 并行写入，写入效率提升 100 倍左右，可以达到十亿行记录每秒，理论性能提升近 1000 倍。

S3数据写入 ClickHouse 使用实例：

INSERT INTO distributed SELECT * FROM s3Cluster(....)

阿里云 ClickHouse 服务兼容社区的标准行为，支持 S3 导入的同时，增强扩展了对于阿里云 OSS 的支持，支持 OSS 的表函数模式，从 OSS 进行数据的导入。同样，阿里云 OSS 也支持并行导入 ClickHouse 的模式，语法示例如下。

insert into oss_test_tbl_distributed select * from oss('<oss-endpoint>', '<access-key-id>', '<access-key-secret>', '<oss-file-path>', '<file-format-name>', '<column-definitions>');

3.其他版本合并特性

除了以上在V22.8版本上首次发布的能力之外，在上一个 LTS 版本 - V22.3 LTS 版本里发布的一些重要能力，也演进到 V22.8 LTS 版本中，在此一起介绍。

JSON类型和动态子列支持

老版本 String 方式 JSON 读写

在之前的版本中，ClickHouse支持以String类型来存储JSON对象，因为JSON对象是文本格式，需要通过特殊的String解析函数来解析复杂的JSON 结构，从而获得 JSON 对象内部字段信息。这种 String 类型存储方式，内部多个字段混合存储，针对内部特定属性的查询会带有额外的字段扫描消耗，因此查询效率非常低。同时使用起来也比较麻烦，如果 JSON 数据存在多层嵌套，那么查询 JSON 数据就需要一层层去进行解析和类型转换，才能被业务使用。示例如下：

CREATE TABLE games (data String)ENGINE = MergeTree ORDER BY tuple();
SELECT JSONExtractString(data, 'teams', 1, 'name')FROM games;

新版本独立 JSON 对象类型和动态子列

新版本中推出了独立 JSON 对象类型，DDL 操作时 JSON 对象只需要指定 JSON 类型即可。同时引擎针对每个写入的 JSON 对象值进行动态的类型匹配，每个 JSON 属性按照独立列进行存储，当新写入的 JSON 对象值和之前的类型不匹配时，引擎会动态修改列类型来兼容所有的数据类型，对于新增 JSON 属性也会动态增加新的列进行数据的存储。

DROP TABLE IF EXISTS github_JSON;
SET allow_experimental_object_type=1;
CREATE table github_JSON(event JSON) ENGINE = MergeTree ORDER BY tuple(

动态子列的支持，大幅提高了非结构化数据的分析效率和扩展性支持。

对于常见的从对象存储如 OSS 导入数据到 ClickHouse 的场景，在前序版本中如果要实现 JSON 对象子列的独立存储和高效分析，那么就必须预先在 ClickHouse 端建立结构化的目标表，目标表的各个字段需要进行明确的类型定义，才能将半结构化的 JSON 数据写入到 ClickHouse 中。同时如果 JSON 对象结构变更，那么需要同时修改目标表的表结构，才能适配写入。

而新版本中由于有了动态子列，开发者完全不需要关心 JSON 的嵌套层次和内部数据类型，只需要在目标表中创建 JSON 数据类型字段，直接将半结构化的数据批量导入到 ClickHouse 目标表中即可。同时，即使在业务变更 JSON 对象属性增加的情况下，也无需要修改目标表的结构，内核会动态增加子列，并进行数据存储，扩展灵活度大幅提升。

INSERT INTO github_JSON SELECT * FROM OSS('oss-endpoint', JSONAsObject, 'event JSON');

当进行数据读取时，不需要按照 String 进行字符串的解析和类型的转换，直接基于 JSON 对象进行属性的嵌套读取就可以。由于有了实际独立的动态子列的存储的支持，大大提升了 JSON 类型数据的存储和查询效率。从社区官方的披露测试结果来看，基于 JSON 对象存储的查询性能对比老版本 String 类型存储格式下，整体查询效率提升了近 40 倍左右。

SELECT event.type, event.repo, event.actor FROM github_JSON LIMIT 1;

JSON 对象和动态子列的支持，是笔者认为近期 ClickHouse 社区发布的最具业务价值的特性之一。尤其在当前非常火热的业务日志分析，自动驾驶，工业物联网等行业，非常多的基于 Metric 写入分析的场景，Metric 采集规模非常大，数据结构和字段变化大，想要灵活的进行结构调整，支持任意维度的数据分析，借助于 ClickHouse JSON 类型和动态子列就可以很好的支持此类业务。

引擎级远程文件缓存

当 ClickHouse 从本地磁盘文件系统读取数据时，如阿里云上 ECS 本地盘或者云盘，数据被 OS 缓存在 page cache 中，因此热查询会非常快。

但是，如果ClickHouse正在从远程文件系统读取，例如从 OSS 进行数据读取，则操作系统不会感知到这些读取，且无法使用page cache。因此， ClickHouse 内核层面实现了自己的引擎级别的 page cache。从 22.3 版本开始，ClickHouse 具有远程文件系统的缓存，缓存同时使用本地磁盘和 RAM，极大地提高了性能。

在阿里云 ClickHouse 的云原生版本中，我们已经基于对象存储 OSS 实现了基于多 shard 共享存储的存算分离架构。通过应用引擎的缓存能力，保证了云原生版本的查询性能。

性能及其他

除了以上的重要的特性发布之外，V22.8 LTS 保持了社区一贯的持续性能优化提升，带来数十项的性能优化。以及其他一些成熟特性如：

Projection 的支持，相比较物化视图增强了和源表数据一致性的保证。同时基于“空间换效率”的逻辑，创建基于不同排序索引维度的物理表，数十倍地提高了非排序键数据的查询效率。
UDF (UserDefinedFunction) 的支持，支持按照 SQL 模式和脚本执行模式的用户自定义函数，增加了用户自主进行数据清洗和处理的能力。

4.总结

关注更多特性细节的小伙伴，可以到 ClickHouse 官网查看。总结来看ClickHouse仍然保持初心，通过轻量 Delete，JSON 数据类型及动态子列，引擎缓存，以及物化视图和 Projection 的支持，在 OLAP 场景实时分析性能方面持续奔跑，一骑绝尘。

同时也可以看到在云原生数据库成为主流演进趋势下，社区已经开始进行云原生的布局演进，从使用远程文件系统进行存储来支撑计算分离的落地就是很好的例证，相信后续会持续在云原生，Serverless 方面加快迭代。

阿里云 ClickHouse V22.8 全托管版本已经全域商业化，也是国内首个提供 V22.8 全托管版本的产品服务，同时我们也在云原生方面积极探索，现在已经推出了正式商业化的 ClickHouse 云原生版本，欢迎各位 ClickHouser 学习体验。

/ End /

推荐阅读