标签：hits max 高级 SELECT number ClickHouse 数据 clickhouse
1、 Explain 查看执行计划
在 clickhouse 20.6 版本之前要查看 SQL 语句的执行计划需要设置日志级别为 trace 才能可以看到， 并且只能真正执行 sql，在执行日志里面查看。 在 20.6 版本引入了原生的执行计划的语法。在 20.6.3 版本成为正式版本的功能。
1.1 基本语法
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，紧凑打印打，默认开启。
注： PLAN 和 PIPELINE 还可以进行额外的显示设置，如上参数所示。
1.2 案例实操
新版本使用 EXPLAIN
可以再安装一个 20.6 以上版本，或者直接在官网的在线 demo，选择高版本进行测试。
官网在线测试链接：
ClickHouse Playground
https://play.clickhouse.com/?file=welcome
1） 查看 PLAIN
简单查询
explain plan select arrayJoin([1,2,3,null,null]);复杂 SQL 的执行计划
explain select database,table,count(1) cnt from system.parts where database in ('datasets','system') group by database,table order by database,cnt desc limit 2 by database;打开全部的参数的执行计划
EXPLAIN header=1, actions=1,description=1 SELECT number from system.numbers limit 10;2） AST 语法树
EXPLAIN AST SELECT number from system.numbers limit 10;3） SYNTAX 语法优化
//先做一次查询
SELECT number = 1 ? 'hello' : (number = 2 ? 'world' : 'atguigu') FROM numbers(10);//查看语法优化
EXPLAIN SYNTAX SELECT number = 1 ? 'hello' : (number = 2 ? 'world' : 'tlzs') FROM numbers(10);//开启三元运算符优化
SET optimize_if_chain_to_multiif = 1;//再次查看语法优化
EXPLAIN SYNTAX SELECT number = 1 ? 'hello' : (number = 2 ? 'world' :'tlzs') FROM numbers(10);//返回优化后的语句
SELECT multiIf(number = 1, 'hello', number = 2, 'world', 'tlzs') FROM numbers(10);4）查看 PIPELINE
EXPLAIN PIPELINE SELECT sum(number) FROM numbers_mt(100000) GROUP BY number % 20;//打开其他参数
EXPLAIN PIPELINE header=1,graph=1 SELECT sum(number) FROM numbers_mt(10000) GROUP BY number%20;2、 建表优化
2.1 数据类型
2.1.1 时间字段的类型
建表时能用数值型或日期时间型表示的字段就不要用字符串，全 String 类型在以 Hive为中心的数仓建设中常见，但 ClickHouse 环境不应受此影响。
虽然 ClickHouse 底层将 DateTime 存储为时间戳 Long 类型，但不建议存储 Long 类型，因为DateTime 不需要经过函数转换处理，执行效率高、可读性好。
create table t_type(
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);create table t_type(
id UInt32,
sku_id String,
total_amount Decimal(16,2) ,
create_time DateTime
) engine =ReplacingMergeTree(create_time)
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id, sku_id);
2.1.2 空值存储类型
官方已经指出 Nullable 类型几乎总是会拖累性能，因为存储 Nullable 列时需要创建一个额外的文件来存储 NULL 的标记，并且 Nullable 列无法被索引。因此除非极特殊情况，应直接使用字段默认值表示空，或者自行指定一个在业务中无意义的值（例如用-1 表示没有商品ID）。
CREATE TABLE t_null(x Int8, y Nullable(Int8)) ENGINE TinyLog;INSERT INTO t_null VALUES (1, NULL), (2, 3); SELECT x + y FROM t_null;查看存储的文件： （没有权限就用 root 用户）
官网说明：
2.2 分区和索引
分区粒度根据业务特点决定，不宜过粗或过细。一般选择按天分区，也可以指定为 Tuple()，以单表一亿数据为例，分区大小控制在 10-30 个为最佳。
必须指定索引列， ClickHouse 中的索引列即排序列，通过 order by 指定，一般在查询条件中经常被用来充当筛选条件的属性被纳入进来；可以是单一维度，也可以是组合维度的索引；通常需要满足高级列在前、查询频率大的在前原则；还有基数特别大的不适合做索引列，
如用户表的 userid 字段；通常筛选后的数据满足在百万以内为最佳。
比如官方案例的 hits_v1 表：
……
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
……visits_v1 表：
……
PARTITION BY toYYYYMM(StartDate)
ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID)
……2.3 表参数
Index_granularity 是用来控制索引粒度的， 默认是 8192， 如非必须不建议调整。
如果表中不是必须保留全量历史数据，建议指定 TTL（生存时间值），可以免去手动过期历史数据的麻烦， TTL 也可以通过 alter table 语句随时修改。（参考基础文档 4.4.5 数据 TTL）
2.4 写入和删除优化
（ 1） 尽量不要执行单条或小批量删除和插入操作，这样会产生小分区文件，给后台Merge 任务带来巨大压力
（2） 不要一次写入太多分区，或数据写入太快，数据写入太快会导致 Merge 速度跟不上而报错，一般建议每秒钟发起 2-3 次写入操作，每次操作写入 2w~5w 条数据（依服务器性能而定）
写入过快报错， 报错信息：
1. Code: 252, e.displayText() = DB::Exception: Too many parts(304).Merges are processing significantly slower than inserts
2. Code: 241, e.displayText() = DB::Exception: Memory limit (for query)exceeded:would use 9.37 GiB (attempt to allocate chunk of 301989888 bytes), maximum: 9.31 GiB
处理方式：
“ Too many parts 处理 ” ：使用 WAL 预写日志，提高写入性能。
in_memory_parts_enable_wal 默认为 true
在服务器内存充裕的情况下增加内存配额，一般通过 max_memory_usage 来实现在服务器内存不充裕的情况下，建议将超出部分内容分配到系统硬盘上，但会降低执行速度，一般通过 max_bytes_before_external_group_by、 max_bytes_before_external_sort 参数来实现。
2.5 常见配置
配置项主要在 config.xml 或 users.xml 中， 基本上都在 users.xml 里
➢ config.xml 的配置项
服务器设置 | ClickHouse文档服务器配置 builtin_dictionaries_reload_interval 重新加载内置字典的间隔时间（以秒为单位）。 ClickHouse每x秒重新加载内置字典。 这使得编辑字典 “on the fly”，而无需重新启动服务器。https://clickhouse.com/docs/zh/operations/server-configuration-parameters/settings/➢ users.xml 的配置项
2.5.1 CPU 资源
| 配置 | 描述 |
| background_pool_size | 后台线程池的大小， merge 线程就是在该线程池中执行，该线程池不仅仅是给 merge 线程用的，默认值 16，允许的前提下建议改成 cpu 个数的 2 倍（线程数） 。 |
| background_schedule_pool_size | 执行后台任务（ 复制表、 Kafka 流、DNS 缓存更新） 的线程数。 默认 128， 建议改成 cpu 个数的 2 倍（线程数）。 |
| background_distributed_schedule_ pool_size | 设置为分布式发送执行后台任务的线程数，默认 16， 建议改成 cpu个数的 2 倍（线程数） 。 |
| max_concurrent_queries | 最大并发处理的请求数(包含select,insert 等)，默认值 100，推荐 150(不够再加)~300。 |
| max_threads | 设置单个查询所能使用的最大 cpu 个数，默认是 cpu 核数 |
2.5.2 内存资源
| 配置 | 描述 |
| max_memory_usage | 此参数在 users.xml 中,表示单次 Query 占用内存最大值，该值可以设置的比较大，这样可以提升集群查询的上限。 保留一点给 OS，比如 128G 内存的机器，设置为 100GB。 |
| max_bytes_before_external_group_ by | 一般按照 max_memory_usage 的一半设置内存，当 group 使用内存超过阈值后会刷新到磁盘进行。因为 clickhouse 聚合分两个阶段：查询并及建立中间数据、合并中间数据， 结合上一项，建议 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，这样不管多大的分区表都可以删除。 |
2.5.3 存储
ClickHouse 不支持设置多数据目录，为了提升数据 io 性能，可以挂载虚拟券组，一个券组绑定多块物理磁盘提升读写性能，多数据查询场景 SSD 会比普通机械硬盘快 2-3 倍。
3、 ClickHouse 语法优化规则
ClickHouse 的 SQL 优化规则是基于 RBO(Rule Based Optimization)，下面是一些优化规则
3.1 准备测试用表
1） 上传官方的数据集
Anonymized Yandex.Metrica Data
数据集由两个表组成，包含关于Yandex.Metrica的hits(hits_v1)和visit(visits_v1)的匿名数据。你可以阅读更多关于Yandex的信息。在ClickHouse历史的Metrica部分。
数据集由两个表组成，他们中的任何一个都可以下载作为一个压缩tsv.xz的文件或准备的分区。除此之外,一个扩展版的hits表包含1亿行TSV在https://datasets.clickhouse.tech/hits/tsv/hits_100m_obfuscated_v1.tsv.xz，准备分区在https://datasets.clickhouse.tech/hits/partitions/hits_100m_obfuscated_v1.tar.xz。
从准备好的分区获取表
下载和导入hits表:
curl -O https://datasets.clickhouse.tech/hits/partitions/hits_v1.tar
tar xvf hits_v1.tar -C /var/lib/clickhouse # path to ClickHouse data directory
下载和导入visits表:
curl -O https://datasets.clickhouse.tech/visits/partitions/visits_v1.tar
tar xvf visits_v1.tar -C /var/lib/clickhouse # path to ClickHouse data directory
//修改所属用户
chown -R clickhouse:clickhouse /var/lib/clickhouse/data/datasets
chown -R clickhouse:clickhouse /var/lib/clickhouse/metadata/datasets2） 重启 clickhouse-server
clickhouse restart3） 执行查询
标签：hits,max,高级,SELECT,number,ClickHouse,数据,clickhouse 来源： https://blog.csdn.net/wtl1992/article/details/120409673
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。