Clickhouse表引擎介绍

作者：俊达

1 引擎分类

ClickHouse表引擎一共分为四个系列，分别是Log、MergeTree、Integration、Special。其中包含了两种特殊的表引擎Replicated、Distributed，功能上与其他表引擎正交，根据场景组合使用。
在这里插入图片描述

2 Log系列

Log系列表引擎功能相对简单，主要用于快速写入小表（1百万行左右的表），然后全部读出的场景。
几种Log表引擎的共性是：

数据被顺序append写到磁盘上。

不支持delete、update。

不支持index。

不支持原子性写。

insert会阻塞select操作。

它们彼此之间的区别是：

TinyLog：不支持并发读取数据文件，查询性能较差；格式简单，适合用来暂存中间数据。

StripLog：支持并发读取数据文件，查询性能比TinyLog好；将所有列存储在同一个大文件中，减少了文件个数。

Log：支持并发读取数据文件，查询性能比TinyLog好；每个列会单独存储在一个独立文件中。

3 Integration系列

该系统表引擎主要用于将外部数据导入到ClickHouse中，或者在ClickHouse中直接操作外部数据源。
Kafka：将Kafka Topic中的数据直接导入到ClickHouse。

MySQL：将Mysql作为存储引擎，直接在ClickHouse中对MySQL表进行select等操作。

JDBC/ODBC：通过指定jdbc、odbc连接串读取数据源。

HDFS：直接读取HDFS上的特定格式的数据文件；

Special系列：Special系列的表引擎，大多是为了特定场景而定制的：

Memory：将数据存储在内存中，重启后会导致数据丢失。查询性能极好，适合于对于数据持久性没有要求的1亿以下的小表。在ClickHouse中，通常用来做临时表。

Buffer：为目标表设置一个内存buffer，当buffer达到了一定条件之后会flush到磁盘。

File：直接将本地文件作为数据存储。

Null：写入数据被丢弃、读取数据为空。

4 MergeTree系列

（1）MergeTree

MergeTree表引擎主要用于海量数据分析，支持数据分区、存储有序、主键索引、稀疏索引、数据TTL等。MergeTree支持所有ClickHouse SQL语法，但是有些功能与MySQL并不一致，比如在MergeTree中主键并不用于去重。

数据TTL

1、基本语法

TTL time_col + INTERVAL ${num} [SECOND|MONTH]

目前TTL可对具体指定列级别、或者表级别进行设置，但是设置后无法取消。

2、实现原理

1）TTL处理逻辑

若表定义中设置了TTL相关设置，在数据写入时，在分区目录下会额外生成一个ttl.txt文件，该文件通过json的格式记录了当前表列级别、表级别的TTL设置，以及当前分区目录下TTL指定时间字段的最小最大值。

MergeTree 以分区目录为单位，通过 ttl.txt文件记录过期时间，并将其作为后续的 判断依据 。

每当写入一批数据时，都会基于INTERVAL表达式的计算结果为这个分区生成 ttl. txt 文件 。

只有在MergeTree合并分区时，才会触发删除 TTL过期数据的逻辑。

在选择删除的分区时，会使用贪婪算法，它的算法规则是尽可能找到会最早过期 的，同时年纪又是最老的分区(合并次数更多 ， MaxBlockNum更大的分区目录) 。

如果一个分区内某一列数据因为 TTL 到期全部被删除了，那么在合并之后生成的 新分区目录中，将不会包含这个列字段的数据文件( .bin 和 .mrk)。

2）如何触发TTL

TTL默认合并频率，由参数merge_with_ttl_timeout控制

使用 optimize命令强制触发合并

-- 触发一个分区的合并
optimize TABLE table_name-- 触发所有分区的合并
optimize TABLE table_name FINAL

（2）ReplacingMergeTree

为了解决MergeTree相同主键无法去重的问题，ClickHouse提供了ReplacingMergeTree引擎，用来做去重。虽然ReplacingMergeTree提供了主键去重的能力，但是仍旧有以下限制：

在没有彻底optimize之前，可能无法达到主键去重的效果，比如部分数据已经被去重，而另外一部分数据仍旧有主键重复。

在分布式场景下，相同primary key的数据可能被sharding到不同节点上，不同shard间可能无法去重。

optimize是后台动作，无法预测具体执行时间点。

手动执行optimize在海量数据场景下要消耗大量时间，无法满足业务即时查询的需求。

ReplacingMergeTree更多被用于确保数据最终被去重，而无法保证查询过程中主键不重复。

（3）SummingMergeTree

ClickHouse通过SummingMergeTree来支持对主键列进行预先聚合。在后台Compaction时，会将主键相同的多行进行sum求和，然后使用一行数据取而代之，从而大幅度降低存储空间占用，提升聚合计算性能。值得注意的是：

ClickHouse只在后台Compaction时才会进行数据的预先聚合，而compaction的执行时机无法预测，所以可能存在部分数据已经被预先聚合、部分数据尚未被聚合的情况。因此，在执行聚合计算时，SQL中仍需要使用GROUP BY子句。

在预先聚合时，ClickHouse会对主键列之外的其他所有列进行预聚合。如果这些列是可聚合的（比如数值类型），则直接sum；如果不可聚合（比如String类型），则随机选择一个值。

通常建议将SummingMergeTree与MergeTree配合使用，使用MergeTree来存储具体明细，使用SummingMergeTree来存储预先聚合的结果加速查询。

-- 建表
CREATE TABLE summtt
(key UInt32,value UInt32
)
ENGINE = SummingMergeTree()
ORDER BY key-- 插入数据
INSERT INTO summtt Values(1,1),(1,2),(2,1)-- compaction前查询，仍存在多行
select * from summtt;
┌─key─┬─value─┐
│   1 │     1 │
│   1 │     2 │
│   2 │     1 │
└─────┴───────┘-- 通过GROUP BY进行聚合计算
SELECT key, sum(value) FROM summtt GROUP BY key
┌─key─┬─sum(value)─┐
│   2 │          1 │
│   1 │          3 │
└─────┴────────────┘-- 强制compaction
optimize table summtt final;-- compaction后查询，可以看到数据已经被预先聚合
select * from summtt;
┌─key─┬─value─┐
│   1 │     3 │
│   2 │     1 │
└─────┴───────┘-- compaction后，仍旧需要通过GROUP BY进行聚合计算
SELECT key, sum(value) FROM summtt GROUP BY key
┌─key─┬─sum(value)─┐
│   2 │          1 │
│   1 │          3 │
└─────┴────────────┘

（4）AggregatingMergeTree

AggregatingMergeTree也是预先聚合引擎的一种，用于提升聚合计算的性能。与SummingMergeTree的区别在于：SummingMergeTree对非主键列进行sum聚合，而AggregatingMergeTree则可以指定各种聚合函数。

AggregatingMergeTree的语法比较复杂，需要结合物化视图或ClickHouse的特殊数据类型AggregateFunction一起使用。在insert和select时，也有独特的写法和要求：写入时需要使用-State语法，查询时使用-Merge语法。

示例一：配合物化视图使用。

-- 建立明细表
CREATE TABLE visits
(UserID UInt64,CounterID UInt8,StartDate Date,Sign Int8
)
ENGINE = CollapsingMergeTree(Sign)
ORDER BY UserID;-- 对明细表建立物化视图，该物化视图对明细表进行预先聚合
-- 注意：预先聚合使用的函数分别为： sumState, uniqState。对应于写入语法<agg>-State.
CREATE MATERIALIZED VIEW visits_agg_view
ENGINE = AggregatingMergeTree() PARTITION BY toYYYYMM(StartDate) ORDER BY (CounterID, StartDate)
AS SELECTCounterID,StartDate,sumState(Sign)    AS Visits,uniqState(UserID) AS Users
FROM visits
GROUP BY CounterID, StartDate;-- 插入明细数据
INSERT INTO visits VALUES(0, 0, '2019-11-11', 1);
INSERT INTO visits VALUES(1, 1, '2019-11-12', 1);-- 对物化视图进行最终的聚合操作
-- 注意：使用的聚合函数为 sumMerge， uniqMerge。对应于查询语法<agg>-Merge.
SELECTStartDate,sumMerge(Visits) AS Visits,uniqMerge(Users) AS Users
FROM visits_agg_view
GROUP BY StartDate
ORDER BY StartDate;-- 普通函数 sum, uniq不再可以使用
-- 如下SQL会报错： Illegal type AggregateFunction(sum, Int8) of argument 
SELECTStartDate,sum(Visits),uniq(Users)
FROM visits_agg_view
GROUP BY StartDate
ORDER BY StartDate;

示例二：配合特殊数据类型AggregateFunction使用。

-- 建立明细表
CREATE TABLE detail_table
(   CounterID UInt8,StartDate Date,UserID UInt64
) ENGINE = MergeTree() 
PARTITION BY toYYYYMM(StartDate) 
ORDER BY (CounterID, StartDate);-- 插入明细数据
INSERT INTO detail_table VALUES(0, '2019-11-11', 1);
INSERT INTO detail_table VALUES(1, '2019-11-12', 1);-- 建立预先聚合表，
-- 注意：其中UserID一列的类型为：AggregateFunction(uniq, UInt64)
CREATE TABLE agg_table
(   CounterID UInt8,StartDate Date,UserID AggregateFunction(uniq, UInt64)
) ENGINE = AggregatingMergeTree() 
PARTITION BY toYYYYMM(StartDate) 
ORDER BY (CounterID, StartDate);-- 从明细表中读取数据，插入聚合表。
-- 注意：子查询中使用的聚合函数为 uniqState， 对应于写入语法<agg>-State
INSERT INTO agg_table
select CounterID, StartDate, uniqState(UserID)
from detail_table
group by CounterID, StartDate-- 不能使用普通insert语句向AggregatingMergeTree中插入数据。
-- 本SQL会报错：Cannot convert UInt64 to AggregateFunction(uniq, UInt64)
INSERT INTO agg_table VALUES(1, '2019-11-12', 1);-- 从聚合表中查询。
-- 注意：select中使用的聚合函数为uniqMerge，对应于查询语法<agg>-Merge
SELECT uniqMerge(UserID) AS state 
FROM agg_table 
GROUP BY CounterID, StartDate;

（5）CollapsingMergeTree

ClickHouse实现了CollapsingMergeTree来消除ReplacingMergeTree的功能限制。该引擎要求在建表语句中指定一个标记列Sign，后台Compaction时会将主键相同、Sign相反的行进行折叠，也即删除。

CollapsingMergeTree将行按照Sign的值分为两类：Sign=1的行称之为状态行，Sign=-1的行称之为取消行。

每次需要新增状态时，写入一行状态行；需要删除状态时，则写入一行取消行。

在后台Compaction时，状态行与取消行会自动做折叠（删除）处理。而尚未进行Compaction的数据，状态行与取消行同时存在。

因此为了能够达到主键折叠（删除）的目的，需要业务层进行适当改造：

执行删除操作需要写入取消行，而取消行中需要包含与原始状态行主键一样的数据（Sign列除外）。所以在应用层需要记录原始状态行的值，或者在执行删除操作前先查询数据库获取原始状态行。

由于后台Compaction时机无法预测，在发起查询时，状态行和取消行可能尚未被折叠；另外，ClickHouse无法保证primary

key相同的行落在同一个节点上，不在同一节点上的数据无法折叠。因此在进行count()、sum(col)等聚合计算时，可能会存在数据冗余的情况。为了获得正确结果，业务层需要改写SQL，将count()、sum(col)分别改写为sum(Sign)、sum(col Sign)。

CollapsingMergeTree虽然解决了主键相同的数据即时删除的问题，但是状态持续变化且多线程并行写入情况下，状态行与取消行位置可能乱序，导致无法正常折叠。

-- 建表
CREATE TABLE UAct
(UserID UInt64,PageViews UInt8,Duration UInt8,Sign Int8
)
ENGINE = CollapsingMergeTree(Sign)
ORDER BY UserID;-- 插入状态行，注意sign一列的值为1
INSERT INTO UAct VALUES (4324182021466249494, 5, 146, 1);-- 插入一行取消行，用于抵消上述状态行。注意sign一列的值为-1，其余值与状态行一致；
-- 并且插入一行主键相同的新状态行，用来将PageViews从5更新至6，将Duration从146更新为185.
INSERT INTO UAct VALUES (4324182021466249494, 5, 146, -1), (4324182021466249494, 6, 185, 1);-- 查询数据：可以看到未Compaction之前，状态行与取消行共存。
SELECT * FROM UAct;
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │         5 │      146 │   -1 │
│ 4324182021466249494 │         6 │      185 │    1 │
└─────────────────────┴───────────┴──────────┴──────┘
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │         5 │      146 │    1 │
└─────────────────────┴───────────┴──────────┴──────┘-- 为了获取正确的sum值，需要改写SQL： 
-- sum(PageViews) => sum(PageViews * Sign)、 
-- sum(Duration) => sum(Duration * Sign)
SELECTUserID,sum(PageViews * Sign) AS PageViews,sum(Duration * Sign) AS Duration
FROM UAct
GROUP BY UserID
HAVING sum(Sign) > 0;
┌──────────────UserID─┬─PageViews─┬─Duration─┐
│ 4324182021466249494 │         6 │      185 │
└─────────────────────┴───────────┴──────────┘-- 强制后台Compaction
optimize table UAct final;-- 再次查询，可以看到状态行、取消行已经被折叠，只剩下最新的一行状态行。
select * from UAct;
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │         6 │      185 │    1 │
└─────────────────────┴───────────┴──────────┴──────┘

多线程并发写入下导致数据混乱的示例

-- 建表
CREATE TABLE UAct_order
(UserID UInt64,PageViews UInt8,Duration UInt8,Sign Int8
)
ENGINE = CollapsingMergeTree(Sign)
ORDER BY UserID;-- 先插入取消行
INSERT INTO UAct_order VALUES (4324182021466249495, 5, 146, -1);
-- 后插入状态行
INSERT INTO UAct_order VALUES (4324182021466249495, 5, 146, 1);-- 强制Compaction
optimize table UAct_order final;-- 可以看到即便Compaction之后也无法进行主键折叠: 2行数据仍旧都存在。
select * from UAct_order;
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249495 │         5 │      146 │   -1 │
│ 4324182021466249495 │         5 │      146 │    1 │
└─────────────────────┴───────────┴──────────┴──────┘

（6）VersionedCollapsingMergeTree

为了解决CollapsingMergeTree乱序写入情况下无法正常折叠问题，VersionedCollapsingMergeTree表引擎在建表语句中新增了一列Version，用于在乱序情况下记录状态行与取消行的对应关系。主键相同，且Version相同、Sign相反的行，在Compaction时会被删除。与CollapsingMergeTree类似， 为了获得正确结果，业务层需要改写SQL，将count()、sum(col)分别改写为sum(Sign)、sum(col * Sign)。

-- 建表
CREATE TABLE UAct_version
(UserID UInt64,PageViews UInt8,Duration UInt8,Sign Int8,Version UInt8
)
ENGINE = VersionedCollapsingMergeTree(Sign, Version)
ORDER BY UserID;-- 先插入一行取消行，注意Signz=-1, Version=1
INSERT INTO UAct_version VALUES (4324182021466249494, 5, 146, -1, 1);-- 后插入一行状态行，注意Sign=1, Version=1；及一行新的状态行注意Sign=1, Version=2，将PageViews从5更新至6，将Duration从146更新为185。
INSERT INTO UAct_version VALUES (4324182021466249494, 5, 146, 1, 1),(4324182021466249494, 6, 185, 1, 2);-- 查询可以看到未compaction情况下，所有行都可见。
SELECT * FROM UAct_version;
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │         5 │      146 │   -1 │
│ 4324182021466249494 │         6 │      185 │    1 │
└─────────────────────┴───────────┴──────────┴──────┘
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │         5 │      146 │    1 │
└─────────────────────┴───────────┴──────────┴──────┘-- 为了获取正确的sum值，需要改写SQL： 
-- sum(PageViews) => sum(PageViews * Sign)、 
-- sum(Duration) => sum(Duration * Sign)
SELECTUserID,sum(PageViews * Sign) AS PageViews,sum(Duration * Sign) AS Duration
FROM UAct_version
GROUP BY UserID
HAVING sum(Sign) > 0;
┌──────────────UserID─┬─PageViews─┬─Duration─┐
│ 4324182021466249494 │         6 │      185 │
└─────────────────────┴───────────┴──────────┘-- 强制后台Compaction
optimize table UAct_version final;-- 再次查询，可以看到即便取消行与状态行位置乱序，仍旧可以被正确折叠。
select * from UAct_version;
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┬─Version─┐
│ 4324182021466249494 │         6 │      185 │    1 │       2 │
└─────────────────────┴───────────┴──────────┴──────┴─────────┘

更多技术信息请查看云掣官网https://yunche.pro/?t=yrgw

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/521626.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

快看！提高效率，还得看工作流表单引擎

快看！提高效率，还得看工作流表单引擎

经常有客户会问我们&#xff1a;究竟用什么样的工具才能打破信息孤岛&#xff0c;让大家互联联络起来&#xff1f;其实&#xff0c;说到这&#xff0c;有不少人会联想到低代码技术平台。不错&#xff0c;在快节奏的发展社会中&#xff0c;高效率的办公目的已经是大家的追求和发…
阅读更多...
最长上升子序列c++

最长上升子序列c++

题目 输入样例&#xff1a; 7 3 1 2 1 8 5 6输出样例&#xff1a; 4 思路 题目求最大长度&#xff0c;考虑使用DP来做。我们从状态表示和状态计算两方面进行分析。 假设用a数组来存序列&#xff0c;f数组来存以f[i]结尾的最长上升子序列。 1. 状态表示&#xff1a; 这一步…
阅读更多...
UI学习 一

UI学习 一

教程&#xff1a;Accessibility – Material Design 3 需要科学上网&#xff0c;否则图片显示不出来。设计教程没有图片说明&#xff0c;不容易理解。 优化UI方向 清晰可见的元素足够的对比度和尺寸重要性的明确等级一眼就能辨别的关键信息 传达某一事物的相对重要性 将重…
阅读更多...
【python爬虫】免费爬取网易云音乐完整教程（附带源码）

【python爬虫】免费爬取网易云音乐完整教程（附带源码）

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯，先赞后看哦~🎈🎈 所属专栏：爬虫实战，零基础、进阶教学 景天的主页：景天科技苑 文章目录 网易云逆向网易云逆向 https://music.163.com/ 下载云音乐 胡广生等，可以选择自己喜欢的歌曲 首先，我们可以先根据…
阅读更多...
3月8日

3月8日

英语 output n. 产量&#xff1b;输出量 outstanding a. 优秀的&#xff1b;杰出的 oval n. & adj. 椭圆&#xff1b;椭圆形的 overcome v. 克服&#xff1b;解决 overhead a. 在头顶上&#xff1b;架空的 overlook v. 忽略&#xff1b;不予理会 overweight a. 太胖的&…
阅读更多...
Python实现极限学习机回归模型(ELMRegressor算法)项目实战

Python实现极限学习机回归模型(ELMRegressor算法)项目实战

说明&#xff1a;这是一个机器学习实战项目&#xff08;附带数据代码文档视频讲解&#xff09;&#xff0c;如需数据代码文档视频讲解可以直接到文章最后获取。 1.项目背景 极限学习机回归模型&#xff08;ELMRegressor&#xff09;是基于极限学习机&#xff08;Extreme Learn…
阅读更多...
常见数据类型

常见数据类型

目录 数据类型 字符串 char nchar varchar varchar2 nvarchar 数字 number integer binary_float binary_double float 日期 date timestamp 大文本数据 大对象数据 Oracle从入门到总裁:https://blog.csdn.net/weixin_67859959/article/details/135209645 数…
阅读更多...
Python实现贝叶斯优化器(Bayes_opt)优化极限学习机分类模型(ELMClassifier算法)项目实战

Python实现贝叶斯优化器(Bayes_opt)优化极限学习机分类模型(ELMClassifier算法)项目实战

说明&#xff1a;这是一个机器学习实战项目&#xff08;附带数据代码文档视频讲解&#xff09;&#xff0c;如需数据代码文档视频讲解可以直接到文章最后获取。 1.项目背景 贝叶斯优化&#xff08;Bayesian Optimization&#xff09;是一种全局优化方法&#xff0c;特别适用于…
阅读更多...
Redis 配置文件详解

Redis 配置文件详解

Units 单位 配置大小单位&#xff0c;开头定义了一些基本的度量单位&#xff0c;只支持bytes&#xff0c;不支持bit&#xff0c;大小写不敏感。 # Redis configuration file example. # # Note that in order to read the configuration file, Redis must be # started with …
阅读更多...
ABAP 内表排序总结

ABAP 内表排序总结

目录 ABAP 内表排序总结需求的场景二分法查找SAP 二分法查找SAP SORT排序 ABAP 内表排序总结 ABAP 内表排序SORT总结&#xff1a; 在创建完内表之后&#xff0c;最好使用sort去排序一下使用read读取内表&#xff0c;如果没有排序的话&#xff0c;可能会读取失败read内表只能读…
阅读更多...
devops-Maven【部署及配置】

devops-Maven【部署及配置】

1、准备maven工具包&#xff0c;Maven官网下载Maven的安装包 Maven – Download Apache Maven Index of /maven (apache.org) 选择后缀是.bin.tar.gz的文件下载&#xff0c;此处下载的版本是3.9.6。 2、安装maven的目录下&#xff0c;建一个Maven路径&#xff0c;然后把压缩…
阅读更多...
ABAP 因去重和汇总导致金额数值错误

ABAP 因去重和汇总导致金额数值错误

在去重之前&#xff0c;就有两条重复的&#xff0c;一旦进行分组汇总&#xff0c;金额就会翻倍&#xff0c;之后又进行去重&#xff0c;也是没有用的&#xff0c;错误数据是2588.6&#xff0c;是1294.3的两倍&#xff0c;现在试试先去重&#xff0c;再去计算数据 就是因为去重…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023