Superset中ClickHouse SELECT查询未显示在system.processes表的问题

问题背景 #

ClickHouse的system.processes表用于存储当前所有运行中的查询信息，支持终止耗时过长的查询。该表在DBeaver和Superset SQLLab中均可正常访问，但Superset SQLLab中执行的SELECT查询不会出现在system.processes表中，仅增、删、改类查询能被正常监控到，需要实现对Superset发起的所有类型查询的监控。

复现步骤 #

1. 将ClickHouse数据库连接至Superset。
2. 在DBeaver中创建大数据量表并填充数据：

   create table eso.t2(v String) ENGINE = MergeTree() order by v;
   insert into eso.t2(v) values(generateUUIDv4());
   insert into eso.t2(v) SELECT v from eso.t2; -- 重复执行20+次，使表数据量达100万+行
   

3. 在Superset/SQLLab中设置UI LIMIT为100万+，执行长耗时SELECT查询：

   SELECT v, generateUUIDv4() as uid from eso.t2 limit 500000;
   

4. 在DBeaver中查询运行中的进程：

   SELECT query, * FROM system.processes where query not like '%processes%';
   

5. 实际结果：无返回结果；预期结果：返回步骤3中的查询进程信息。

成功案例：在Superset中执行insert into eso.t2(v) SELECT v from eso.t2，可在system.processes表中正常看到该查询进程。

可能原因及解决方案 #

原因1：SELECT查询执行过快，进程已完成 #

如果ClickHouse端的SELECT查询执行速度较快，在切换到DBeaver查询system.processes之前，进程已经结束，因此无法捕获。

验证与解决方法：
修改SELECT查询，添加耗时操作延长执行时间，比如：

SELECT v, generateUUIDv4(), sleep(0.001) from eso.t2 limit 500000;

执行该查询后立即去DBeaver查询system.processes，此时应该能看到对应的进程。

原因2：Superset客户端拉取结果模式导致进程提前结束 #

Superset默认可能会一次性拉取所有查询结果到客户端内存，导致ClickHouse端的进程在结果返回完成后立即终止，无法被持续监控。

解决方案：
在Superset的ClickHouse连接配置中调整参数：

• 若使用SQLAlchemy驱动，添加连接参数stream_results=True，开启流式结果返回
• 切换使用ClickHouse的Native协议（端口9000）而非HTTP协议（端口8123），Native协议对长查询的进程跟踪更稳定。

原因3：Superset查询逻辑的特殊优化 #

Superset的SQLLab可能对SELECT查询做了客户端侧的limit处理、结果缓存等优化，导致实际发送到ClickHouse的查询与输入不一致，或查询被提前终止。

解决方案：

• 查看Superset的查询日志，确认实际发送到ClickHouse的SQL语句
• 查看ClickHouse的system.query_log表验证查询执行记录：

  SELECT query, event_time FROM system.query_log WHERE query LIKE '%eso.t2%' AND type = 'QueryFinish' ORDER BY event_time DESC LIMIT 10;
  

  如果query_log中有记录但system.processes无实时进程，说明进程已执行完成，需要通过延长查询时间或调整拉取模式实现监控。

内容的提问来源于stack exchange，提问作者Konstantin Berlinskii