ClickHouse V22.8 新特性介绍

背景介绍

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

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

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

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

特性介绍

日期&时间类型扩展

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

日期类型数据精度最大为 8 位，也就是达到微秒级精度。如果使用 9 位的时间精度，则最大支持到 2262-04-11 23:47:16   UTC。

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

轻量 Delete 及语法支持

22.8 新版本对于  MergeTree 引擎表，新增支持了标准的  DELETE FROM SQL 语法，同时实现了“轻量” Delete 逻辑 。 在之前的版本中，ClickHouse 的 DELETE 操作属于 Mutation 类操作，所有的 DELETE 事件是通过单独进行文件进行记录存储，然后基于内核调度不定时的异步执行；另外Delete 需要定位到相应的记录，进行实际的物理删除，执行过程也比较重。所以轻量的 DELETE 也可以说是社区用户广泛期待的能力。

旧版本 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%' ;

从开发者的角度来看，标准 SQL 语法的支持，相比较之前的 Mutation 类操作方式，增强了开发的便利性。从官方的测试性能结果来看，在单表 1 亿记录总量，110 个 Part 规模下， 轻量 Delete 的性能较之前版本提升了近 40 倍左右，性能提升明显。

但是需要注意的是，虽然有了标准 Delete From  SQL 语法的支持以及轻量实现，但当前的 Delete 默认仍然是异步执行；其部基于 ClickHouse 的列更新机制，在数据分区中增加了系统虚拟列“_row_exists ”，通过 update _row_exists = 0 where predicate   来标记列处于“已删除状态”。所以 Delete 操作的结果并不是实时反馈在查询结果上的。官网强调 “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 服务兼容社区的标准行为，同时增强扩展了对于阿里云 OSS 的支持，支持 OSS 的表函数模式，从 OSS 进行数据的导入。同时，阿里云 OSS 也是兼容 S3 的，因此社区新版本的并行写入模式，在阿里云 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>');

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

JSON类型和动态子列支持

• 老版本的 JSON 格式数据读写方式

在 22.3  之前的版本中，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 实现了基于多计算节点共享存储的存算分离架构。 通过应用引擎的缓存能力，保证了云原生版本的查询性能。

性能优化及其他

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

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

总结

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

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

国内提供全托管 ClickHouse 服务的厂商，也在云原生方面积极探索，阿里云现在已经推出了正式商业化的 ClickHouse 云原生版本，大家可以体验使用。