clickhouse count和uniqCombined

于 2024-06-27 09:41:02 发布
阅读量441 收藏
点赞数 2
文章标签： clickhouse
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_37962554/article/details/139683172
版权
ELI_He999
关注
大数据ClickHouse进阶（二十二）：ClickHouse优化
Lansonli（蓝深李）的博客
11-01 1615
在Hive中对于日期数据我们经常使用String类型存储，但是在ClickHouse中建表时针对日期类型数据存储建议使用日期类型存储，不使用String类型存储，因为在使用到日期时日期类型可以直接处理，String类型的日期数据还需要使用函数进行处理，执行效率低。
ClickHouse SQL语法
Daniel462038751的专栏
10-20 2467
Clickhouse常用SQL语法介绍
clickhouse uniqCombined
weixin_43824233的博客
04-01 1876
mysql中的 count（distinct column） 与ck中uniq相比 消耗内存要少几倍。 计算精度高出几倍。 通常具有略低的性能。 在某些情况下, uniqCombined 可以表现得比 uniq 好，例如，使用通过网络传输大量聚合状态的分布式查询。 ps: 由于它对非 String 类型使用32位哈希，对于基数显著大于UINT_MAX ，结果将有非常高的误差(误差将在几百亿不同值之后迅速提高), 因此这种情况，你应该使用 uniqCombined64 ...
ClickHouse--17--聚合函数总结
时光里的博客
04-11 2519
不支持分布式表。
Clickhouse学习系列——一条SQL完成gourp by分组与不分组数值计算
killer1989的博客
08-08 2842
笔者在近一两年接触了Clickhouse数据库，在项目中也进行了一些实践，但一直都没有一些技术文章的沉淀，近期打算做个系列，通过一些具体的场景将Clickhouse的用法进行沉淀和分享，供大家参考。
7.ClickHouse系列之查询优化
算法小生
10-21 1472
prewhere和where语句的作用相同，用来过滤数据。不同之处在于prewhere只支持*MergeTree族系列引擎的表，首先会读取指定的列数据，来判断数据过滤，等待数据过滤之后在读取select声明的列字段来补全其余属性。如下表而言，当发布日期大于10月1日，会在物化视图的存储表.inner_id.xxxx中插入数据，而当清空基础表house时，.inner_id.xxxx中的数据并不会丢失。列裁剪即指定所需要的列，而非全量*，分区裁剪就是只读取需要的分区，在过滤条件中指定。
ClickHouse高级 操作使用 第八章
小坏说后端
11-08 955
CK的 join ： 1 、原理：右表加载到内存、再去匹配 2 、为什么 join 不行、因为 1 3 、非要使用、怎么比较好：能过滤先过滤，特别是右表右表放小表特殊场景可以考虑使用字典表可以替换的话、尽量不要用 join ，比如用 in 实现。
ClickHouse宝典
探索大数据世界 - 深入解析数据存储、分布式计算与人工智能
01-01 2310
ClickHouse-实操宝典
ClickHouse使用分析
InfiniteCreator
03-12 947
每个列字段都独立存储，有一个对应的.bin文件，按列独立存储的好处可以更好的数据压缩，还能缩小数据的扫描范围数据经过压缩按照order by（类似主键）的顺序排列，按照压缩数据块的形式写入.bin文件中，每个压缩块的大小控制在64KB-1MB，虽然数据被压缩后能够有效减少数据大小，降低存储空间并加速数据传输效率，但数据的压缩和解压动作，其本身也会带来额外的性能损耗，所以要控制被压缩数据的大小，在性能损耗和压缩率之间寻求一种平衡，而且通过数据块读取，可以不用读取整个.bin文件，缩小数据读取范围。
ClickHouse 聚合函数
热门推荐
thinker
03-18 2万+
ClickHouse 聚合函数 本贴最后更新于783天前，其中的信息可能已经水流花落 背景 ClickHouse 中内置许多标准 SQL 外的函数。 这里记录一下其中聚合函数的学习笔记。 聚合函数 常用函数 count 返回记录条数。 如 SELECT count() FROM table 注：如果求COUNT(DISTINCT x)，则使用uniq函数 ...
ClickHouse
dwjlyl
01-09 2674
CK函数，架构
【Clickhouse】Clickhouse 精确去重计数性能测试
九师兄
12-13 1443
主要原理：将32bit的Integer划分为高16位和低16位(两个short int)，两者之间是Key-Value的关系。高16位存到short[] keys，通过高16位（ Key）找到所对应Container，然后把剩余的低16位（ Value）放入该Container中， RoaringBitmap有三类Container：丼个栗子：丼个栗子：“双11” 就要到了，需要发放10万张家电类优惠券迚行促销：用户画像场景1—预估人数用户画像场景2—人群圈选画像。
ClickHouse系列（13）—— ClickHouse SQL 查询优化
shangjg3的博客
11-20 1015
1单表查询1.1Prewhere替代wherePrewhere和where语句的作用相同用来过滤数据。不同之处在于prewhere只支持 *MergeTree 族系列引擎的表，首先会读取指定的列数据，来判断数据过滤，等待数据过滤之后再读取select 声明的列字段来补全其余属性。当查询列明显多于筛选列时使用Prewhere可十倍提升查询性能，Prewhere会自动优化执行过滤阶段的数据读取方式，降低io操作。在某些场合下，prewhere语句比where语句处理的数据量更少性能更高。
ClickHouse-查询优化
qq_38304392的博客
04-26 2027
一、单表查询【使用的频率高】 1.prewhere代表where Prewhere 和 where 语句的作用相同，用来过滤数据。不同之处在于 prewhere 只支持*MergeTree 族系列引擎的表，首先会读取指定的列数据，来判断数据过滤，等待数据过滤之后再读取 select 声明的列字段来补全其余属性。 当查询列明显多于筛选列时使用 Prewhere 可十倍提升查询性能，Prewher...
ClickHouse 特性及存储原理
qianshanding0708的博客
08-12 3283
更多内容关注微信公众号：fullstack888背景目前业务中有大量实时分析需求，随着数据量的增加，基于行存储的 OLTP 数据库已经不能满足性能的需求，我们对 ClickHouse 进行...
clickhouse普通函数，聚合函数使用总结
dair6的博客
02-11 8659
## 一.创建clickhouse表 ### 1.建表 CREATE TABLE ck_test ( `id` String COMMENT 'id', `int_1` UInt32 COMMENT '整型列1', `int_2` UInt32 COMMENT '整型列2', `str_1` String COMMENT '字符串列1', `str_2` String COMMENT '字符串列2' ) ENGINE = MergeTree ORDER BY id...
【ClickHouse】优化
qq_41466440的博客
12-23 2282
clickhouse优化
clickhouse聚合函数之groupBitmap
鸭梨的博客
01-17 1万+
用途 官方点就是计算基数,直白点就是统计不重复的个数 参数为Uint类型,就是不是负数的整数 返回值为Uint64类型 案例 测试数据 UserID 1 1 2 3 SELECT groupBitmap(UserID) as num FROM t; 结果 num 3 再举个例子,比如我们有用户id uid, string类型,相要统计其个数,则 SELECT groupBitmap(toUInt64(uid)) as num from usertable; +----+ |num | +----+
Clickhouse 去重
最新发布
03-04
<think>好的，我现在需要向用户介绍ClickHouse的去重功能。首先，我得回忆一下自己对ClickHouse的了解，尤其是关于数据去重的部分。ClickHouse是一个列式数据库，主要用于OLAP场景，处理大数据量和高性能查询。去重在数据处理中是一个常见需求，所以用户可能想知道ClickHouse如何处理这个问题。 首先，我应该想到ClickHouse本身的设计原则。它通常不保证数据的唯一性，因为作为分析型数据库，它更注重写入速度和查询性能，而不是实时去重。不过，用户可能有去重的需求，所以需要介绍不同的方法。 接下来，我需要考虑用户可能提到的去重方法。比如，使用ReplacingMergeTree引擎，这是ClickHouse中专门用来处理重复数据的一种表引擎。ReplacingMergeTree通过指定一个版本列，在后台合并时删除重复项。但需要注意的是，合并的时间不确定，查询时可能仍有重复数据，所以可能需要使用FINAL关键字或者OPTIMIZE命令，但这会影响性能。 另外，还有使用GROUP BY子句在查询时去重。这种方法在查询时对数据进行分组，但数据量大时可能效率不高，特别是如果没有合适的索引的话。 还有使用DISTINCT关键字，但同样在大数据量下性能可能不佳。 可能还需要提到CollapsingMergeTree和VersionedCollapsingMergeTree，这两种引擎用于处理行级变更，可能在某些去重场景中有用，但主要针对数据更新。 此外，外部去重工具，比如在数据导入前使用ETL工具进行去重，或者在应用层处理，这也是一个常见的方法。 然后，需要考虑用户的实际应用场景。比如，用户是否需要实时去重，还是可以接受最终一致性。ReplacingMergeTree适合最终一致性的场景，而查询时去重则适用于实时性要求不高的情况。 可能还需要提到一些最佳实践，比如如何选择版本列，避免使用低基数字段作为版本列，合理设计主键以优化去重效率等。 最后，要总结各种方法的优缺点，帮助用户根据具体需求选择合适的方式。比如，写入性能、查询性能、数据一致性要求、存储成本等因素的权衡。 现在需要把这些思路组织成结构化的回答，分点说明，确保用户能清晰理解不同的去重方法及其适用场景。同时，注意使用中文，避免技术术语过于晦涩，必要时举例说明。比如，ReplacingMergeTree的建表语句示例，GROUP BY的使用示例等。 需要检查是否有遗漏的方法，比如使用UNIQUE约束吗？不过ClickHouse本身不支持UNIQUE约束，所以这点需要明确说明。此外，可能还要提到物化视图，结合ReplacingMergeTree使用，自动处理去重后的数据。 还要注意强调ReplacingMergeTree的合并过程是后台进行的，不能保证立即去重，因此查询时可能需要额外处理，比如使用FINAL或者子查询，或者接受可能存在重复数据的情况。 总结时，可以给出选择建议：如果数据量小，查询去重即可；需要高效去重且接受最终一致，用ReplacingMergeTree；需要严格唯一性，可能需要应用层或ETL预处理。 最后检查是否有错误，比如ReplacingMergeTree的合并机制是否正确，DISTINCT和GROUP BY的区别等，确保信息准确。</think>ClickHouse作为OLAP列式数据库，其去重处理需要结合特定引擎和查询方式实现。以下是主要去重方案及适用场景： ### 一、ReplacingMergeTree引擎（最终一致性） 建表语法示例： ```sql CREATE TABLE test_table ( id Int32, name String, version UInt64 ) ENGINE = ReplacingMergeTree(version) ORDER BY (id, name) ``` 特性： - 根据`ORDER BY`键去重（此处为id+name组合） - 通过`version`列保留最新版本（最大值） - 后台自动合并分区，但**合并时机不可控** - 查询时可能需要： ```sql -- 强制合并（生产环境慎用） OPTIMIZE TABLE test_table FINAL; -- 查询最新状态 SELECT * FROM test_table FINAL; -- 保证结果的子查询方式 SELECT * FROM ( SELECT *, row_number() OVER(PARTITION BY id, name ORDER BY version DESC) as rn FROM test_table ) WHERE rn = 1 ``` ### 二、实时查询去重 1. **GROUP BY聚合** ```sql SELECT id, name, max(version) FROM test_table GROUP BY id, name ``` *适用场景*：中小数据量即时分析 2. **DISTINCT去重** ```sql SELECT DISTINCT id, name FROM test_table ``` *限制*：仅返回去重后的维度列，无法获取最新完整记录 ### 三、高级方案 1. **数据预处理** - ETL流程中使用`GROUP BY`预聚合 - Kafka+MaterializedView实现流式去重 2. **外部字典** ```sql CREATE DICTIONARY unique_users (id UInt64, name String) PRIMARY KEY id SOURCE(...) LIFETIME(...) LAYOUT(...) ``` *适用场景*：高频查询的维度表 ### 四、方案对比 | 方案 | 去重时机 | 存储开销 | 查询性能 | 数据一致性 | |---------------------|------------|----------|----------|--------------| | ReplacingMergeTree | 后台合并 | 低 | 高 | 最终一致 | | GROUP BY查询 | 实时 | 无 | 中 | 精确 | | 预处理ETL | 写入前 | 低 | 高 | 精确 | | 外部字典 | 加载时 | 高 | 极高 | 依赖刷新策略 | ### 五、实践建议 1. **时序数据场景**：使用`ReplacingMergeTree`+时间版本列，保留最新状态 2. **精确去重分析**： ```sql SELECT countDistinct(device_id) FROM logs -- 精确计算 SELECT uniqExact(device_id) FROM logs -- 更优性能 ``` 3. **海量数据近似去重**： ```sql SELECT uniq(device_id) FROM logs -- 误差<1% SELECT uniqCombined(device_id) FROM logs -- 误差<0.6% ``` > 特殊场景提示：当需要全局唯一约束时（如用户ID），建议在应用层或使用Kafka等消息队列实现幂等写入，而非依赖数据库层约束。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值