计算
弹性云服务器 ECS
Flexus云服务
裸金属服务器 BMS
弹性伸缩 AS
镜像服务 IMS
专属主机 DeH
函数工作流 FunctionGraph
云手机服务器 CPH
Huawei Cloud EulerOS
网络
虚拟私有云 VPC
弹性公网IP EIP
虚拟专用网络 VPN
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
VPC终端节点 VPCEP
云连接 CC
企业路由器 ER
企业交换机 ESW
全球加速 GA
安全与合规
安全技术与应用
Web应用防火墙 WAF
企业主机安全 HSS
云防火墙 CFW
安全云脑 SecMaster
DDoS防护 AAD
数据加密服务 DEW
数据库安全服务 DBSS
云堡垒机 CBH
数据安全中心 DSC
云证书管理服务 CCM
边缘安全 EdgeSec
威胁检测服务 MTD
CDN与智能边缘
内容分发网络 CDN
CloudPond云服务
智能边缘云 IEC
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
迁移中心 MGC
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
云搜索服务 CSS
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
数据治理中心 DataArts Studio
数据可视化 DLV
数据湖工厂 DLF
湖仓构建 LakeFormation
企业应用
云桌面 Workspace
应用与数据集成平台 ROMA Connect
云解析服务 DNS
专属云
专属计算集群 DCC
IoT物联网
IoT物联网
设备接入 IoTDA
智能边缘平台 IEF
用户服务
账号中心
费用中心
成本中心
资源中心
企业管理
工单管理
国际站常见问题
ICP备案
我的凭证
支持计划
客户运营能力
合作伙伴支持计划
专业服务
区块链
区块链服务 BCS
Web3节点引擎服务 NES
解决方案
SAP
高性能计算 HPC
视频
视频直播 Live
视频点播 VOD
媒体处理 MPC
实时音视频 SparkRTC
数字内容生产线 MetaStudio
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
存储容灾服务 SDRS
高性能弹性文件服务 SFS Turbo
弹性文件服务 SFS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属分布式存储服务 DSS
容器
云容器引擎 CCE
容器镜像服务 SWR
应用服务网格 ASM
华为云UCS
云容器实例 CCI
管理与监管
云监控服务 CES
统一身份认证服务 IAM
资源编排服务 RFS
云审计服务 CTS
标签管理服务 TMS
云日志服务 LTS
配置审计 Config
资源访问管理 RAM
消息通知服务 SMN
应用运维管理 AOM
应用性能管理 APM
组织 Organizations
优化顾问 OA
IAM 身份中心
云运维中心 COC
资源治理中心 RGC
应用身份管理服务 OneAccess
数据库
云数据库 RDS
文档数据库服务 DDS
数据管理服务 DAS
数据复制服务 DRS
云数据库 GeminiDB
云数据库 GaussDB
分布式数据库中间件 DDM
数据库和应用迁移 UGO
云数据库 TaurusDB
人工智能
人脸识别服务 FRS
图引擎服务 GES
图像识别 Image
内容审核 Moderation
文字识别 OCR
AI开发平台ModelArts
图像搜索 ImageSearch
对话机器人服务 CBS
华为HiLens
视频智能分析服务 VIAS
语音交互服务 SIS
应用中间件
分布式缓存服务 DCS
API网关 APIG
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
分布式消息服务RocketMQ版
多活高可用服务 MAS
事件网格 EG
企业协同
华为云会议 Meeting
云通信
消息&短信 MSGSMS
云生态
合作伙伴中心
云商店
开发者工具
SDK开发指南
API签名指南
Terraform
华为云命令行工具服务 KooCLI
其他
产品价格详情
系统权限
管理控制台
客户关联华为云合作伙伴须知
消息中心
公共问题
开发与运维
应用管理与运维平台 ServiceStage
软件开发生产线 CodeArts
需求管理 CodeArts Req
部署 CodeArts Deploy
性能测试 CodeArts PerfTest
编译构建 CodeArts Build
流水线 CodeArts Pipeline
制品仓库 CodeArts Artifact
测试计划 CodeArts TestPlan
代码检查 CodeArts Check
代码托管 CodeArts Repo
云应用引擎 CAE
开天aPaaS
云消息服务 KooMessage
云手机服务 KooPhone
云空间服务 KooDrive
本文导读

展开导读

ClickHouse SQL调优

更新时间:2024-12-11 GMT+08:00

规则

  1. 合理使用数据表的分区字段和索引字段。

    MergeTree引擎,数据是以分区目录的形式进行组织存储的,在进行的数据查询时,使用分区可以有效跳过无用的数据文件,减少数据的读取。

    MergeTree引擎会根据索引字段进行数据排序,并且根据index_granularity的配置生成稀疏索引。根据索引字段查询,能快速过滤数据,减少数据的读取,大大提升查询性能。

  2. 不要用select *,只查询需要的字段,减少机器负载,提升查询性能。

    OLAP分析场景,一张大宽表通常能有几百上千列,选择其中少数的几列做维度列、指标列计算。匹配这种场景下,ClickHouse的数据也是按照列存储的。如果使用select *,会大大加重系统的压力。

  3. 通过limit限制查询返回的数据量,节省计算资源、减少网络开销。

    如果返回的数据量过大,客户端有可能出现内存溢出等服务异常。

    对于前端使用ClickHouse的场景,如果要查询的数据量比较大,建议每次可适当地进行分页查询返回数据,以减少查询数据量对网络带宽和计算资源的占用。

    【不做limit限制】

    耗时:1.124

    【做limit限制】

    耗时:0.002

  4. join查询时小表在右。

    两表JOIN时,会将右表数据加载到内存中,再根据右表数据遍历左表做匹配,将小表放在右边,减少匹配查询的次数。根据使用的情况,大表join小表的性能比小表join大表的性能有数量级的提升。

    【大表在左小表在右】

    SELECT count(a.id)
    FROM
    (
    SELECT id
    FROM mytable
    WHERE id < 100000000
    ) AS a
    INNER JOIN
    (
    SELECT id
    FROM mytable
    WHERE id < 1000000
    ) AS b ON a.id = b.id;
    耗时:0.145 sec。

    【大表在右小表在左】

    SELECT count(a.id)
    FROM
    (
    SELECT id
    FROM mytable
    WHERE id < 1000000
    ) AS a
    INNER JOIN
    (
    SELECT id
    FROM mytable
    WHERE id < 100000000
    ) AS b ON a.id = b.id;
    耗时:0.996 sec。
  5. ClickHouse不支持limit下推,SQL生成时需要优化,以免SQL性能受影响。

    【错误示例】

    select did from (select did from tableA) limit 10;

    【正确示例】

    select did from (select did from tableA limit 10);
  6. 基于大宽表做数据分析,尽量不要使用大表join大表的操作。

    ClickHouse分布式join的性能较差,建议在模型侧将数据聚合成大宽表再导入ClickHouse。

    【两表join查询】

    SELECT
    col1,
    col2
    FROM
    (
    SELECT
    t1.col1 AS col1,
    t2.col2 AS col2
    FROM
    (
    SELECT
    did,
    col1
    FROM table1
    WHERE cc_pt_d = '2020-03-30'
    ) AS t1
    LEFT JOIN
    (
    SELECT
    did AS did_v2,
    col2
    FROM table2
    WHERE pt_d = '2020-03-30'
    ) AS t2 ON t2.did_v2 = t1.did
    ) AS t
    GROUP BY
    col1,
    col2
    LIMIT 10;
    耗时: 40秒。

    【大宽表查询】

    SELECT
    col1,
    col2
    FROM
    table1
    GROUP BY
    col1,
    col2
    LIMIT 10;
    耗时: 8秒。

建议

  1. 明确数据查询的范围,增加条件过滤和查询的数据周期过滤,缩小数据查询范围。

    【示例】

    SELECT uniqCombined(did) from pp.scene_model where pt_d < ‘2020-11-10’ and pt_d > ‘2020-11-03’;
  2. 在分组、join等操前做数据过滤,减少计算的数据量。

    【效果对比】

  3. 用PREWHERE替代WHERE,优先过滤数据,加速查询。

    PREWHERE相对于WHERE在执行时的区别:首先只读取PREWHERE表达式所指定的列,根据条件做数据过滤,再根据过滤后的数据读取其他列。这通常会减少磁盘读取数据的压力。

    PREWHERE只支持*MergeTree系列的表。系统配置optimize_move_to_prewhere默认开启,将WHERE转成PREWHERE,可以根据自己的业务场景调整这个配置。

    查询语句中同时有PREWHERE和WHERE,在这种情况下,PREWHERE先于WHERE执行。

  4. 合理配置最大并发数。

    Clickhouse快是因为采用了并行处理机制,即使一个查询,默认也会用服务器一半的CPU去执行,所以ClickHouse对高并发查询的场景支持的不够。

    官方默认的最大并发数是100,可以根据实际场景调整并发配置,实际使用中并发数配置的是150,建议不超过200。

  5. 部署负载均衡组件,查询基于负载均衡组件进行,避免单点查询压力太大影响性能。

    ClickHouse支持连接集群中的任意节点查询,如果查询集中到一台节点,可能会导致该节点的压力过大并且可靠性不高。建议使用ClickHouseBalancer或者其他负载均衡服务,均衡查询负载,提升可靠性。

  6. 用近似去重(uniqCombined、uniq)替代精确去重。

    ClickHouse提供多种近似去重算法,通过count_distinct_implementation配置,支持将countDistinct语法转成所配置的近似算法。查询性能有数量级的提升。

    近似算法的误差一般在1%以内。在数据准确度要求不高,比如趋势分析等,建议使用近似去重提升用户体验。

    【使用精确去重查询】

    耗时:1.280秒。

    【使用近似查询】

    耗时:0.061秒。

  7. 对于字符串类型的字段做复杂计算,建议先编码成整数类型,以提升计算性能。

    【字符编码前,32字节的String类型字段did】

    CREATE TABLE default.Test_String ON Cluster default_cluster
    (
      `EventDate` DateTime,
      `did`       String,
      `UserID`    UInt32,
      `ver`       UInt16
    )
    ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/default/Test_String', '{replica}')
    PARTITION BY toYYYYMM(EventDate) 
    ORDER BY (EventDate, intHash32(UserID)) 
    SETTINGS index_granularity = 8192;
    select count(distinct did) from dws_wallet_xxx_mlb_ds;
    执行耗时:142秒。

    【字符编码后,将32位长String转码成int类型】

    CREATE TABLE default.Test_Int ON Cluster default_cluster
    (
      `EventDate` DateTime,
      `did`       UInt32,
      `UserID`    UInt32,
      `ver`       UInt16
    )
    ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/default/Test_Int', '{replica}')
    PARTITION BY toYYYYMM(EventDate) 
    ORDER BY (EventDate, intHash32(UserID)) 
    SETTINGS index_granularity = 8192;
    select count(distinct did_int) from dws_wallesst_xxx_mlb_ds;
    执行耗时:34秒。
  8. 高基数(大于10W)字段(int类型),使用bitmap做精确去重。

    【countDistinct做精确去重】

    select count(distinct did_int) from dws_wallet_xxx_mlb_ds;
    执行耗时:34秒。

    【countDistinct做精确去重】

    select groupBitmapMergeState(arrayReduce('groupBitmapState', [toUInt64(did)])) as user1 from t_r_309;
    执行耗时:8秒。
  9. 使用物化视图加速查询。

    对于查询方式比较固定的场景,建议使用物化视图,提前做好数据聚合,相对于查询明细表,性能有数量级的提升。

    【物化视图创建】

    明细表、物化视图创建参见 【建议】 物化视图创建参考。

    【明细表插入数据】

    INSERT INTO counter SELECT
    toDateTime('2019-01-01 00:00:00') + toInt64(number / 10) AS when,
    (number % 10) + 1 AS device,
    ((device * 3) + (number / 10000)) + ((rand() % 53) * 0.1) AS value
    FROM system.numbers
    LIMIT 100000000;

    【查询明细表】

    【查询物化视图】

    【效果对比】

    使用物化视图后,遍历的数据量从1亿下降到2000,耗时从0.211秒下降到0.002秒,性能提升100倍。

  10. 使用bitmap做跨表预估计算。

    【场景】

    用户画像,用户数预估:计算t_r_309和t_r_308 join后,did字段的基数。

    【表join示例】

    SELECT countDistinct(a.did)
    FROM
    (
    SELECT DISTINCT did
    FROM t_r_309
    ) AS a
    INNER JOIN
    (
    SELECT DISTINCT did
    FROM t_r_308
    ) AS b ON a.did = b.did;

    【bitmap实现示例】

    SELECT bitmapAndCardinality(user1, user2)
    FROM
    (
    SELECT
    1 AS join_id,
    groupBitmapMergeState(arrayReduce('groupBitmapState', [toUInt32(did)])) AS user1
    FROM t_r_309
    ) AS a
    INNER JOIN
    (
    SELECT
    1 AS join_id,
    groupBitmapMergeState(arrayReduce('groupBitmapState', [toUInt32(did)])) AS user2
    FROM t_r_308
    ) AS b ON a.join_id = b.join_id;

    【效果对比】

    多张表join后计算,随着join数越多,时延越大,基本在几十秒以上。使用bitmap计算预估,耗时在3秒以内。

  11. 使用GLOBAL JOIN/IN替换普通的JOIN。

    ClickHouse基于分布式表的查询会转换成所有分片的本地表的操作,再汇总结果。实际使用中,join和global join的执行逻辑差别很大,建议使用global join做分布式表查询。

    【场景说明】

    1. 查询的集群有N个分片(shard)
    2. A_all是分布式表,对应的本地表是A_local
    3. B_all是分布式表,对应的本地表是B_local
    【分布式表直接join示例】
    SELECT * FROM A_all AS t1 JOIN B_all AS t2 ON t1.id = t2.id;

    执行逻辑如下:

    1. 在发起查询的节点,将查询分发到所有分片,转成A_all Join B_local。
    2. 在收到a中每个请求的分片,再将请求分发到所有分片,转成A_local Join B_local。
    3. 可以看到,分布式表的join操作,存在查询放大的问题。
    【分布式表global join示例】
    SELECT * FROM A_all AS t1 GLOBAL JOIN B_all AS t2 ON t1.id = t2.id;

    执行逻辑如下:

    1. 在查询发起的节点,查询B_all的所有数据到本地的缓存表T中,并将T分发到所有节点。
    2. 查询发起的节点,将本地缓存表T分发到所有分片。
    3. 每个分片执行A_local join T。
    4. 在收到a中每个请求的分片,再将请求分发到所有分片,转成A_local Join B_local。

    【效果对比】

    可以看到,使用GLOBAL关键字后,查询的放大减少了很多。不过,由于需要将右表汇总再分发到所有机器,如果右表的数据量很大,需要考虑机器的内存,避免内存溢出。

  12. 数据压缩算法的选择,建议使用默认的lz4压缩算法。

    ClickHouse提供了两种数据压缩方式供选择:LZ4和ZSTD。

    默认的LZ4压缩方式,会提供更快的执行效率,但是同时,要付出较多的磁盘容量占用的代价。

  13. ReplacingMergeTree表引擎数据查询,需要先做数据去重合并提升性能。

    如果使用去重引擎进行数据查询,且使用argMax函数和final关键字,会导致整个查询性能较差,需要提前对重复数据做合并去重optimize操作,查询时候直接查询不需要使用argMax函数和final关键字,提升查询性能。

我们使用cookie来确保您的高速浏览体验。继续浏览本站,即表示您同意我们使用cookie。 详情

文档反馈

文档反馈

意见反馈

0/500

标记内容

同时提交标记内容