OLAP引擎—ClickHouse常规优化

OLAP引擎—ClickHouse优化

一、数据一致性问题

即便对数据一致性支持最好的 Mergetree，也只是保证最终一致性。

ReplacingMergeTree

• 该引擎和 MergeTree 的不同之处在于它会删除排序键值相同的重复项。
• 数据的去重只会在数据合并期间进行。合并会在后台一个不确定的时间进行，因此你无法预先作出计划。
• 尽管你可以调用 OPTIMIZE 语句发起计划外的合并，但请不要依靠它，因为 OPTIMIZE 语句会引发对数据的大量读写。
  因此，ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现。

在使用 ReplacingMergeTree、SummingMergeTree 这类表引擎的时候，会出现短暂数据不一致的情况。在某些对一致性非常敏感的场景，通常有以下几种解决方案。

1.1 测试表及数据的准备

-- 1、创建表
-- user_id 是数据去重更新的标识;
-- create_time 是版本号字段，每组数据中 create_time 最大的一行表示最新的数据;
-- deleted 是自定的一个标记位，比如 0 代表未删除，1 代表删除数据。

CREATE TABLE test_distinct(
     user_id UInt64,
     score String,
     deleted UInt8 DEFAULT 0,
     create_time DateTime DEFAULT toDateTime(0)
) ENGINE= ReplacingMergeTree(create_time)
  ORDER BY user_id;
  


-- 2、写入 100 万 测试数据
INSERT INTO TABLE test_distinct(user_id,score)
WITH(
 SELECT ['A','B','C','D','E','F','G']
)AS dict
SELECT number AS user_id, dict[number%7+1] FROM numbers(1000000);


-- 3、修改前 5 万 行数据，修改内容包括 name 字段和 create_time 版本号字段
INSERT INTO TABLE test_distinct(user_id,score,create_time)
WITH(
 SELECT ['AA','BB','CC','DD','EE','FF','GG']
)AS dict
SELECT number AS user_id, dict[number%7+1], now() AS create_time FROM 
numbers(50000);

-- 4、还未触发分区合并，所以还未去重
SELECT COUNT() FROM test_distinct;
┌─count()─┐
│ 1050000 │
└─────────┘

1.2 通过 FINAL去重

在查询语句后增加 FINAL 修饰符，这样在查询的过程中将会执行 Merge 的特殊逻辑（例如数据去重，预聚合等）。

注：这种方法在早期版本基本没有人使用，因为在增加 FINAL 之后，我们的查询将会变成一个单线程的执行过程，查询速度非常慢。

在 v20.5.2.7-stable 版本中，FINAL 查询支持多线程执行，并且可以通过 max_final_threads 参数控制单个查询的线程数。

SELECT COUNT() FROM test_distinct final;


┌─count()─┐
│ 1000000 │
└─────────┘

1.3 手动OPTIMIZE(不建议)

-- 在写入数据后，立刻执行 OPTIMIZE 强制触发新写入分区的合并动作。
OPTIMIZE TABLE test_distinct FINAL;

-- 语法如下
OPTIMIZE TABLE [db.]name [ON CLUSTER cluster] [PARTITION partition | 
PARTITION ID 'partition_id'] [FINAL] [DEDUPLICATE [BY expression]]


-- 再次查询，发现已经去重
centos04 :) SELECT COUNT() FROM test_distinct;

┌─count()─┐
│ 1000000 │
└─────────┘

1.4 通过group by进行去重

-- 1、利用group by进行去重
CREATE VIEW view_test_distinct AS
SELECT
 user_id ,
 argMax(score, create_time) AS score,     -- 按照 create_time 的最大值取 score 的值
 argMax(deleted, create_time) AS deleted, -- 按照 create_time 的最大值取 deleted 的值
 max(create_time) AS ctime 
FROM test_distinct 
GROUP BY user_id     -- 对利用group by进行去重
HAVING deleted = 0;  -- 筛选未删除的数据


-- 2、再次插入一条数据(重复数据)
INSERT INTO TABLE test_distinct(user_id,score,create_time) VALUES(0,'AAAA',now());


SELECT 
  *
FROM test_distinct
WHERE user_id = 0;

┌─user_id─┬─score─┬─deleted─┬─────────create_time─┐
│       0 │ AAAA  │       0 │ 2023-04-06 12:59:03 │
└─────────┴───────┴─────────┴─────────────────────┘
┌─user_id─┬─score─┬─deleted─┬─────────create_time─┐
│       0 │ AA    │       0 │ 2023-04-06 12:48:26 │
└─────────┴───────┴─────────┴─────────────────────┘

SELECT 
  *
FROM view_test_distinct
WHERE user_id = 0;

┌─user_id─┬─score─┬─deleted─┬───────────────ctime─┐
│       0 │ AAAA  │       0 │ 2023-04-06 12:59:03 │
└─────────┴───────┴─────────┴─────────────────────┘


-- 3、再次插入一条标记为删除的数据
INSERT INTO TABLE test_distinct(user_id,score,deleted,create_time) 
VALUES(0,'AAAA',1,now());


SELECT 
  *
FROM test_distinct
WHERE user_id = 0;
┌─user_id─┬─score─┬─deleted─┬─────────create_time─┐
│       0 │ AAAA  │       0 │ 2023-04-06 12:59:03 │
└─────────┴───────┴─────────┴─────────────────────┘
┌─user_id─┬─score─┬─deleted─┬─────────create_time─┐
│       0 │ AAAA  │       1 │ 2023-04-06 13:02:22 │
└─────────┴───────┴─────────┴─────────────────────┘
┌─user_id─┬─score─┬─deleted─┬─────────create_time─┐
│       0 │ AA    │       0 │ 2023-04-06 12:48:26 │
└─────────┴───────┴─────────┴─────────────────────┘



SELECT 
  *
FROM view_test_distinct
WHERE user_id = 0;
-- 这行数据并没有被真正的删除，而是被过滤掉了。在一些合适的场景下，可以结合 表级别的 TTL 最终将物理数据删除。

二、查看执行计划

-- 语法如下
EXPLAIN [AST | SYNTAX | PLAN | PIPELINE] [setting = value, ...] 
SELECT ... [FORMAT ...]

➢ PLAN：用于查看执行计划，默认值。

​ ◼ header 打印计划中各个步骤的 head 说明，默认关闭，默认值 0;

​ ◼ description 打印计划中各个步骤的描述，默认开启，默认值 1；

​ ◼ actions 打印计划中各个步骤的详细信息，默认关闭，默认值 0。

➢ AST ：用于查看语法树;

➢ SYNTAX：用于优化语法;

➢ PIPELINE：用于查看 PIPELINE 计划。

​ ◼ header 打印计划中各个步骤的 head 说明，默认关闭;

​ ◼ graph 用 DOT 图形语言描述管道图，默认关闭，需要查看相关的图形需要配合graphviz 查看；

​ ◼ actions 如果开启了 graph，紧凑打印打，默认开启。

三、建表优化

3.1 字段类型

3.1.1 时间字段的类型

建表时能用数值型或日期时间型表示的字段就不要用字符串。

虽然 ClickHouse 底层将 DateTime 存储为时间戳 Long 类型，但不建议存储 Long 类型，因为 DateTime 不需要经过函数转换处理，执行效率高、可读性好。

create table t_a(
     id UInt32,
     sku_id String,
     total_amount Decimal(16,2) ,
     create_time Int32 
) engine =ReplacingMergeTree(create_time)
 partition by toYYYYMMDD(toDate(create_time)) --需要转换一次，否则报错
 primary key (id)
 order by (id, sku_id);

3.1.2 空值存储类型

官方已经指出 Nullable 类型几乎总是会拖累性能，因为存储 Nullable 列时需要创建一个额外的文件来存储 NULL 的标记，并且 Nullable 列无法被索引。

因此除非极特殊情况，应直接使用字段默认值表示空，或者自行指定一个在业务中无意义的值。

3.2 分区和索引

• 一般选择按天分区。
• 1亿条数据一般选择30个左右的分区。
• 必须指定索引列，ClickHouse 中的索引列即排序列，通过 order by 指定。索引：order by(a,b,c) 从左到右优先索引，高频查询的字段放在前面。
• 基数特别大的不适合做索引列。
  • 基数大的列：该列的数据去重后和数据记录数越接近基数越大。
  • 为什么基数大不适合做索引：基数过大，查找时越需要依次遍历，则失去了索引意义。

……
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID)) -- UserID基数特别大的不适合做索引列，利用intHash32()解决
……

3.3 表参数

• Index_granularity是用来控制索引粒度的，默认是8192，如非必须不建议调整。
• 如果表中不是必须保留全量历史数据，建议制定TTL（生存时间值）可以免去手动处理过期历史数据的麻烦，TTL也可以通过Alter table随时修改。

3.4 写入和删除优化

• 尽量不要执行单条或小批量删除和插入操作，这样会产生小分区文件，给后台Merge任务带来巨大压力；
• 不要一次写入太多分区，或数据写入太快：
  • 数据写入太快会导致Merge速度跟不上而报错，一般建议每秒钟发起2-3次写入操作，每次操作写入2w-5w条数据。

3.5 常见配置项

3.5.1 CPU配置

配置	描述
background_pool_size	后台线程池的大小，merge线程就是在该线程池中执行，该线程池不仅仅是给merge线程使用的，默认值16，允许的前提下建议改成CPU个数的2倍（一核可以虚拟化成两线程）
background_schedule_pool_size	执行后台任务的线程数，默认128，建议改成CPU个数的2倍（线程数）
background_distributed_schedule_pool_size	设置为分布式发送执行后台任务的线程数，默认16，建议改成CPU个数的2倍（线程数）
max_concurrent_queries	最大并发处理请求数（包含select、insert等），默认值100，推荐150（不够再加）~300，默认单位为个/每秒
max_threads	设置单个查询所能使用的最大CPU个数，默认是CPU核数

3.5.2 内存配置

配置	描述
max_memory_usage	此参数在users.xml中，表示单词Query占用内存最大值，该值可以设置的比较大，这样可以提升集群查询的上限。保留一点给OS，比如128G内存的机器，设置为100G。
max_bytes_before_external_group_by	一般按照max_memory_usage的一半设置内存，当group使用内存超过阈值后会刷新到磁盘进行。因为Click house聚合分为两个阶段：查询并建立中间数据、合并中间数据，结合上一项，建议50GB。
max_bytes_before_external_sort	当 order by已使用max＿bytes＿before＿external＿sort内存就进行溢写磁盘（基于磁盘排序），如果不设置该值，那么当内存不够时直接抛错，设置了该值 order by可以正常完成，但是速度相对存内存来说肯定要慢点（实测慢的非常多，无法接受）。
max_table_size_to_drop	此参数在 config.xml 中，应用于需要删除表或分区的情况，默认是50GB，意思是如果删除50GB以上的分区表会失败。建议修改为0，这样不管多大的分区表都可以删除。

四、查询优化

4.1 单表查询优化

4.1.1 prewhere替代where

prewhere 和where 语句的作用相同，用来过滤数据。不同之处在于 prewhere 只支持MergeTree 族系列引擎的表，首先会读取指定的列数据，来判断数据过滤，等待数据过滤之后再读取 select 声明的列字段来补全其余属性。

当查询列明显多于筛选列时使用prewhere可十倍提升查询性能，Prewhere会自动优化执行过滤阶段的数据读取方式，降低io操作。
​ 在某些场合下，prewhere 语句比 where 语句处理的数据量更少性能更高。

4.1.2 列裁剪与分区裁剪

• 列裁剪：其实就是避免使用select * ，筛选出需要的字段
• 分区裁剪：避免使用select * ，在where中使用partition by字段，选择分区

4.1.3 order by 结合where、limit

千万以上的数据集进行order by查询时需要搭配where条件和limit语句一起使用。

4.1.4 避免构建虚拟列

如非必须，不要在结果集上构建虚拟列，虚拟列非常消耗资源浪费性能，可以考虑在前端进行处理，或者在表中构造实际字段进行额外存储。

• 虚拟列：原表中不存在的列，计算出来的列，如：

select
	a,
	b,
	a+b  -- 虚拟列,虚拟列非常消耗资源，浪费性能。
from
	table

4.1.5 uniqCombined替代distinct

• uniqCombined：近似去重，但是精度不会很低，差别很小

性能可提升10倍以上，uniqCombined底层采用类似HyperLogLog算法实现。

不建议对千万以上的对准确度没有要求的数据进行精确去重，使用近似去重。

-- 反例：
select count(distinct rand()) from hits_v1;

-- 正例：
SELECT uniqCombined(rand()) from datasets.hits_v1

4.2 多表关联

clickhouse 的JOIN：

• 原理：右表加载到内存，再匹配；
• 非要使用，如何使用：
  • 能过滤先过滤，特别是右表；
  • 右表放小表；
  • 特殊场景可以考虑使用字典表；
  • 可以替换的话，利用IN替换JOIN

-- 建表的时候，想要复制表结构：
create table XXX as select * from XXXX where 1 = 0; -- 条件不成立，数据永远不会写进来

4.2.1 Join原理

A join B，将B表全部加载到内存中，A表中的数据会逐条匹配内存中的B表。

4.2.2 用IN代替JOIN

• 当多表联查时，查询的数据仅从其中一张表出时，可以考虑从IN操作而不是JOIN

select table_a.* from table_a where table_a.count_id in (select count_id from table_b);

4.2.3 大小表JOIN

多表 join 时要满足小表在右的原则，右表关联时被加载到内存中与左表进行比较， Click House 中无论是 Left join 、 Right join 还是 Inner join 永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。

4.2.4 注意谓词下推

• 尽量在join之前进行过滤

ClickHouse 在join查询时不会主动发起谓词下推的操作，需要每个子查询提前完成过滤操作，需要注意的是，是否执行谓词下推，对性能影响差别很大

4.2.5 分布式表使用GLOBAL

• 查询放大：两张分布式表进行JOIN的时候，两张表的N各节点互相发起查询，变成N*N次

两张分布式表上的IN和JOIN之前必须加上GLOBAL关键字，右表只会在接收查询请求的那个节点查询一次，并将其分发到其他节点上。如果不加GLOBAL关键字的话，每个节点都会单独发起一次对右表的查询，而右表又是分布式表，就导致右表一共会被查询N²次（N是该分布式表的分片数量），这就是查询放大，会带来很大开销。

4.2.6 使用字典表

• 可以是自己创建的表，也可以是外部文件。

将一些需要关联分析的业务创建成字典表进行join操作，前提是字典表不宜太大，因为字典表会常驻内存。

4.2.7 提前过滤

通过增加逻辑过滤可以减少数据扫描，达到提高执行速度、降低内存消耗的目的。

五、物化视图

5.1 简介

• 视图：保存的是SQL的操作逻辑。
• 物化视图：不仅保存SQL的操作逻辑，还保存操作过后的结果，结果根据相应的引擎存到磁盘或内存中。

​ ClickHouse 的物化视图是一种查询结果的持久化，它确实是给我们带来了查询效率的提升。用户查起来跟表没有区别，它就是一张表，它也像是一张时刻在预计算的表，创建的过程它是用了一个特殊引擎，加上后来 as select，就是 create一个table as select的写法。

​ "查询结果集"的范围很宽泛，可以是基础表中部分数据的一份简单拷贝，也可以是多表join之后产生的结果或其子集，或者原始数据的聚合指标等等。所以，物化视图不会随着基础表的变化而变化，所以它也称为快照（snapshot）。

优点：查询速度快，要是把物化视图这些规则全部写好，它比原数据查询快了很多，总的行数少了，因为都预计算好了。

缺点：它的本质是一个流式数据的使用场景，是累加式的技术，所以如果要用历史数据做去重、去核这样的分析，在物化视图里面是不太好用的。在某些场景的使用也是有限的。而且如果一张表加了好多物化视图，在写这张表的时候，就会消耗很多机器的资源，比如数据带宽占满、存储一下子增加了很多。

5.2 基本语法

创建时会创建一个隐藏的目标表来保存视图数据。也可以TO表明，保存到一张显式的表。没有加TO表名，表名默认就是.inner.物化视图名。

CREATE MATERIALIZED VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER] [TO[db.]name] [ENGINE = engine] [POPULATE] AS SELECT ...

• [POPULATE]：添加之后，在创建视图时会遍历历史数据，会增加服务器负载，如果要历史数据，使用INSERT INTO写入数据。
• 在创建没有TO [db].[table]的物化视图时，您必须指定ENGINE- 用于存储数据的表引擎。
• 使用TO [db].[table]创建物化视图时，不得使用POPULATE.
• 物化视图的实现方式如下：向 中指定的表中插入数据时，插入的SELECT部分数据通过该SELECT查询进行转换，并将结果插入到视图中。
• 查询语句可以包含下面的子句：DISTINCT , GROUP BY , ORDER BY , LIMIT……

5.3 案例详解

-- 1、创建测试数据
create table test_a_test(
	user_id UInt64,
	score String,
	deleted UInt8 DEFAULT 0,
	create_time Date
) ENGINE = MergeTree()
partition by toYYYYMM(create_time)
order by (create_time,intHash32(user_id))
sample by intHash32(user_id)
SETTINGS index_granularity = 8192;


insert into
	test_a_test
select
	*
FROM
	test_a
limit 10000;

-- 2、创建物化视图
create materialized view test_mview
engine = SummingMergeTree
partition by toYYYYMM(create_time)
order by (create_time,intHash32(user_id))
as
SELECT
	user_id,
	create_time,
	count(score),
	sum(deleted)
from
	test_a_test ta
WHERE
	create_time >= toDate(0)
group by user_id,create_time ;

show tables;
>>>结果
.inner_id.5bfba660-812e-49ec-885f-3fa63e16f2f4 -- 默认存储数据的表格
test_a_test
test_mview

-- 3、插入数据
SELECT * from test_mview; -- 第一次查询结果为空

insert  into
	test_a_test
select
	*
FROM
	test_a
limit 10;

SELECT * from test_mview;  -- 插入后在查询有10条新增数据

select * from `.inner_id.068a0cde-c260-4fee-b902-c7f74cc4f194`; -- 自动创建的表中也有数据

-- 4、导入历史数据（重点！！！）
insert into
	test_mview
-- 将物化视图的逻辑再写一遍
SELECT
	user_id,
	create_time,
	count(score),
	sum(deleted)
from
	test_a_test ta
WHERE
	create_time >= toDate(0)
group by user_id,create_time