Clickhouse第六讲-视图

本文介绍了Clickhouse中的视图功能,包括普通视图和物化视图。普通视图作为查询的简化,不存储数据,而物化视图会预先计算并存储结果。此外,还讨论了Clickhouse的update和delete操作的低效率,以及数据导入导出的多种格式支持和常用的CK连接工具。
ClickHouse 中视图分为普通视图和物化视图,两者区别如图所示

普通视图

普通视图不存储数据,它只是一层 select 查询映射,类似于表的别名或者同义词,能简化查询,对原有表的查询性能没有增强的作用,具体性能依赖视图定义的语句,当从视 图中查询时,视图只是替换了映射的查询语句。普通视图当基表删除后不可用。

创建普通视图语法:

CREATE [OR REPLACE] VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER]
AS SELECT ...
例子:
create table personinfo(id UInt8,name String,age UInt8,birthday Date) engine = Log;
#向表 personinfo 中插入如下数据:
node1 :) insert into personinfo values (1,'张三',18,'2021-06-01');
node1 :) insert into personinfo values (2,'李四',19,'2021-06-02');
node1 :) insert into personinfo values (3,'王五',20,'2021-06-03');
node1 :) insert into personinfo values (4,'马六',21,'2021-06-04');
node1 :) insert into personinfo values (5,'田七',22,'2021-06-05');
#创建视图 person_view 映射查询子句
 node1 :) create view person_view as select name,birthday from personinfo;  

物化视图

 物化视图是查询结果集的一份持久化存储,所以它与普通视图完全不同,而非常趋近于表。”查询结果集”的范围很宽泛,可以是基础表中部分数据的一份简单拷贝,也可以是多表 join 之后产生的结果或其子集,或者原始数据的聚合指标等等。
物化视图创建好之后,若源表被写入新数据则物化视图也会同步更新,POPULATE 关键 字决定了物化视图的更新策略,若有 POPULATE 则在创建视图的过程会将源表已经存在的 数据一并导入,类似于 create table ... as,若无 POPULATE 则物化视图在创建之后 没有数据,只会在创建只有同步之后写入源表的数据,clickhouse 官方并不推荐使用 populated,因为在创建物化视图的过程中同时写入的数据不能被插入物化视图。 物化视图是种特殊的数据表,创建时需要指定引擎,可以用 show tables 查看。另外,物化视图不支持 alter 操作。
产生物化视图的过程就叫做“物化”(materialization),广义地讲,物化视图是 数据库中的预计算逻辑+显式缓存,典型的空间换时间思路,所以用得好的话,它可以避免对基础表的频繁查询并复用结果,从而显著提升查询的性能。

物化视图创建语法

CREATE MATERIALIZED VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER] [TO[db.]name] [ENGINE = engine] [POPULATE] AS SELECT ...
#在库newdb中创建物化视图
create materialized view t_view engine=Log as select * from personinfo;
show tables;
insert into personinfo values(1,'张三',18,'2021-06-01');
insert into personinfo values(2,'李四,18,'2021-06-01');
insert into personinfo values(3,'王五',18,'2021-06-01');
insert into personinfo values(4,'马六',18,'2021-06-01');
创建无话视图
create materialized view t_view2 engine=Log as  select count(name) as cnt from personinfo
当 创 建 好 物 化 视 图 t_view1 时 , 可 以 进 入 到/var/lib/clickhouse/data/newdb 目录下看到%2Einner%2Et_view1 目录,当物化视图中同步基表数据时,目录中有对应的列文件和元数据记录文件,与普通创建表一样,
有目录结构。物化视图可能存在的 bug(待验证):clickhouse 物化视图 根据 tab1 表的 a,b 分
组 对 c 列 sum 操作, 得到的物化视图数据可能不是期望的结果,物化视图中 a,b 两列
的记录可能 a1,b1/a1,b2 两条数据。可能只显示 a1,b1。

update更新

由于clickhouse针对的是OLAP业务分析,update操作在clickhouse中不会经常使用,这种更新效率低:

alter table dbname table update column1 = expr1 [,....] where filter_expr

#创建表 t_update,使用 MergeTree 引擎

create table t_update (id UInt8,name String,age UInt8) engine = MergeTree() order by id ;

insert into t_update values (1,'张三',18),(2,'李四',19)

alter table t_update update age = 22 where name = '张三'

delete

ClickHouse 针对的是 OLAP 业务分析,Delete 操作与 Update 操作一样在 ClickHouse 中不会经常使用。这种删除效率低下

alter table db. table on cluster cluster delete where filter_expr

#创建表 t_delete,使用 MergeTree 引擎

create table t_delete (id UInt8,name String,age UInt8) engine = MergeTree() order by id ;

insert into t_update values (1,'张三',18),(2,'李四',19)

alter table t_delete delete where name = '张三';

向表中导入到处数据

ClickHouse 中 支 持 多 种 数 据 格 式 数 据 导 入 和 导 出 , 支 持 格 式 有 ORC,Parquet,Avro,Protobuf,xml,json,csv 等

#创建表 t_csv ,执行引擎为 MergeTree
create table t_csv (id UInt8,name String,age UInt8) engine = MergeTree order by id;
#导入数据,在 ClickHouse-client 中执行导入数据命令
clickhouse-client --format_csv_delimiter="," --query="INSERT INTO newdb.t_csv FORMAT CSV" < /root/csvdata
#进入 ClickHouse 客户端查看表 t_csv 中的数据

导出数据

#导出数据,在 ClickHouse-client 中执行命令,将数据导入到 result 文件中
clickhouse-client --format_csv_delimiter="|" --query="select * from newdb.t_csv FORMAT CSV" > /root/result

CK的连接工具

DBeaver和tabix
<think>我们面对的问题是ClickHouse在向物化视图`gaia.ads_invest_automatic_rules_campagin_rt_v5_local_mv`推送数据时出现ZooKeeper会话过期的错误(错误码225)。根据引用[1]和[2],这个错误通常是由于与ZooKeeper的连接丢失导致的。 根本原因分析: 1. ClickHouse重度依赖ZooKeeper(ZK)来管理分布式表的元数据、数据块分配和插入同步等操作。 2. 当ZK服务由于网络问题、资源不足(如CPU或磁盘I/O瓶颈)或ZK服务本身的问题(如日志同步慢)导致无法及时响应时,ClickHouse与ZK的会话可能会超时(默认会话超时时间为30秒),从而引发此错误。 解决方案: 1. 检查ZK集群状态: 确保ZK集群健康,没有节点宕机,且所有节点状态正常(通过`echo stat | nc <zk_host> <zk_port>`检查)。 2. 监控ZK性能: 检查ZK服务器的资源使用情况(CPU、内存、磁盘I/O)和网络延迟,确保没有资源瓶颈。 3. 调整ClickHouse的ZK会话超时设置: 在ClickHouse的配置文件中(通常为`config.xml`),可以增加会话超时时间(注意:设置过长可能导致故障检测缓慢): ```xml <zookeeper> <session_timeout_ms>30000</session_timeout_ms> <!-- 默认30秒,可适当增大,如60000 --> </zookeeper> ``` 4. 优化ZK的配置: 在ZK的配置文件`zoo.cfg`中,适当调整`tickTime`和`maxSessionTimeout`(确保`maxSessionTimeout`大于ClickHouse中设置的会话超时时间)。 5. 检查网络连接: 确保ClickHouse服务器与ZK服务器之间的网络稳定,没有丢包或高延迟。 6. 减少对ZK的负载: - 避免在ZK中存储大量数据(ClickHouse的每个插入操作都会在ZK中创建节点,因此插入频率过高可能导致ZK压力大); - 考虑使用ReplicatedMergeTree引擎的表减少插入频率(合并写入); - 检查是否有其他应用程序过度使用同一个ZK集群,必要时分离集群。 7. 查看ClickHouse日志: 在ClickHouse的日志(通常位于`/var/log/clickhouse-server/`)中搜索相关错误,获取更多上下文信息。 针对物化视图插入的特定建议: 1. 物化视图的数据插入同样会涉及到ZK操作(如果底层表是Replicated表)。因此,确保物化视图依赖的表结构正确,且ZK配置正确(引用[3]提到,缺少ZK配置会导致错误139)。 2. 如果插入数据量很大,可能会导致ZK上临时节点过多,从而增加ZK的压力。可以尝试: - 增加每次插入的批次大小,减少插入次数; - 调整表引擎的参数,如`max_partitions_per_insert_block`(防止一次插入产生过多分区)和`parts_to_delay_insert`(延迟插入以等待合并)等,参考引用[4]中提到的“Too many parts”错误的相关优化。 如果问题仍然存在,请收集以下信息以便进一步排查: - ClickHouse和ZK的版本。 - 错误发生时的ClickHouse日志片段。 - ZK集群的状态(使用`zkCli.sh`检查)。 注意:修改配置后需要重启ClickHouse服务。 相关问题: 1. 如何监控ClickHouse对ZooKeeper的使用情况? 2. 如何优化ClickHouse的物化视图写入性能? 3. ZooKeeper在ClickHouse分布式架构中扮演什么角色? </think>### ClickHouse报错 "ZooKeeper session has been expired" 解决方案 针对向视图 `gaia.ads_invest_automatic_rules_campagin_rt_v5_local_mv` 推送数据时出现的 `DB::Exception: ZooKeeper session has been expired`(错误码 225),结合引用内容分析,解决方案如下: #### 核心问题原因 1. **ZooKeeper 连接丢失** ClickHouse 重度依赖 ZooKeeper 管理分布式元数据、数据块分配和同步操作[^2]。当 ZooKeeper 会话过期时,会导致数据推送失败。 2. **可能触发场景** - ZooKeeper 服务响应超时(日志同步阻塞等) - 网络波动导致心跳检测失败 - ZooKeeper 服务端资源过载(CPU/内存) - ClickHouse 配置缺失(如引用[3]的配置错误) --- ### 具体解决步骤 #### 第一步:检查 ZooKeeper 服务状态 1. **验证 ZooKeeper 健康** ```bash echo stat | nc <ZK主机> 2181 # 检查响应时间和连接状态 ``` 输出应包含 `Zookeeper version: ... Mode: leader/follower` 2. **排查资源瓶颈** - 检查 ZooKeeper 节点的 CPU/内存/磁盘 I/O - 查看 ZooKeeper 日志(通常位于 `/var/log/zookeeper/`),搜索 `WARN` 或 `ERROR` #### 第二步:优化 ClickHouse 配置 1. **增加会话超时时间** 修改 ClickHouse 配置文件 `config.xml`: ```xml <zookeeper> <session_timeout_ms>60000</session_timeout_ms> <!-- 默认30秒,建议增至60秒 --> </zookeeper> ``` 2. **添加重试机制** 在表引擎配置中添加 ZooKeeper 重试策略(针对物化视图依赖的基础表): ```sql CREATE TABLE ... ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table', '{replica}') SETTINGS zookeeper_retry_interval_ms = 1000, -- 重试间隔 zookeeper_retry_interval_cap_ms = 30000; ``` #### 第三步:调整写入策略 1. **减少 ZooKeeper 负载** 批量写入代替高频单条插入,降低 ZooKeeper 压力: ```sql INSERT INTO ... VALUES (batch1), (batch2), ... -- 合并插入批次 ``` 2. **控制分区数量** 避免产生过多数据块(解决引用[4]的 "Too many parts" 问题): ```sql ALTER TABLE ... MODIFY SETTING max_partitions_per_insert_block = 50; ``` #### 第四步:验证视图配置 1. **检查物化视图的 ZooKeeper 依赖** 确认视图依赖的底层表已正确配置 ZooKeeper(避免引用[3]错误): ```sql SELECT engine, zookeeper_path FROM system.tables WHERE name = 'ads_invest_automatic_rules_campagin_rt_v5_local_mv'; ``` 2. **重建会话连接** 重启 ClickHouse 服务强制重建 ZooKeeper 连接: ```bash systemctl restart clickhouse-server ``` --- ### 预防措施 1. **监控 ZooKeeper 指标** - 关注 `znode_count`(节点数量)和 `avg_latency`(响应延迟) - 设置告警规则:会话超时 > 50ms 或 连接数 > 80% 上限 2. **增强集群可靠性** - ZooKeeper 集群至少部署 3 节点(避免单点故障) - 使用专用网络通信,减少网络抖动影响 3. **升级版本** 旧版本存在已知稳定性问题(如引用中的 19.14.6.12),建议升级到 LTS 版本(如 22.3+)。 > **关键提示**:若问题持续发生,需检查 ZooKeeper GC 停顿时间(通过 `jstat -gc <ZK_PID>`),超过 500ms 的停顿会直接导致会话超时。 --- ### 相关问题 1. 如何监控 ClickHouse 与 ZooKeeper 的交互延迟? 2. ClickHouse 分布式表写入时出现 "Too many parts" 错误如何解决?[^4] 3. ZooKeeper 集群性能优化的常用手段有哪些? 4. ClickHouse 物化视图同步失败的其他常见原因是什么?
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值