关于云计算:ClickHouse-技术系列-ClickHouse-聚合函数和聚合状态

简介：本文翻译自 Altinity 针对 ClickHouse 的系列技术文章。面向联机剖析解决（OLAP）的开源剖析引擎 ClickHouse，因其低劣的查问性能，PB 级的数据规模，简略的架构，被国内外公司宽泛采纳。本系列技术文章，将具体开展介绍 ClickHouse。

前言

本文翻译自 Altinity 针对 ClickHouse 的系列技术文章。面向联机剖析解决（OLAP）的开源剖析引擎 ClickHouse，因其低劣的查问性能，PB 级的数据规模，简略的架构，被国内外公司宽泛采纳。

阿里云 EMR-OLAP 团队，基于开源 ClickHouse 进行了系列优化，提供了开源 OLAP 剖析引擎 ClickHouse 的云上托管服务。EMR ClickHouse 齐全兼容开源版本的产品个性，同时提供集群疾速部署、集群治理、扩容、缩容和监控告警等云上产品性能，并且在开源的根底上优化了 ClickHouse 的读写性能，晋升了 ClickHouse 与 EMR 其余组件疾速集成的能力。拜访 https://help.aliyun.com/docum… 理解详情。

译者：何源（荆杭），阿里云计算平台事业部高级产品专家

ClickHouse 聚合函数和聚合状态

ClickHouse 可能有一个独特的性能——聚合状态（除了聚合函数外）。你能够参考 和 组合子的文档。

简而言之，许多数据库应用概率数据结构，例如 HyperLogLog（简称 HLL）。它用于惟一 / 去重计算，你能够在 Spark、ElasticSearch、Flink、Postgres、BigQuery 和 Redis 等服务中看到它的成果。但通常你只能在聚合函数中利用此函数一次，例如查问每月惟一用户数——失去一个数字，这样就知足了。因为 HLL 构造没有对应的外部格局，因而无奈重用预聚合或局部聚合的数据。而在 ClickHouse 中，你能够这样做，因为 HLL 构造是统一的。

ClickHouse 的速度十分快，其基本思路是解决原始数据而不是预聚合数据。然而让咱们做个试验。例如，咱们须要为上个月的惟一用户数计算一些指标。

构想：每天预聚合，而后汇总所有后果。这就是所谓的存储空间办法——当前你能够只汇总最初 30 个测量值来计算上个月的统计数据，或者只汇总最初 7 个测量值来计算上周的统计数据。

创立咱们的预聚合表：

create table events_unique (
  date Date, 
  group_id String, 
  client_id String, 
  event_type String, 
  product_id String, 
  value AggregateFunction(uniq, String)
) ENGINE = MergeTree(date, (group_id, client_id, event_type, product_id, date), 8192);

这里将我的聚合申明为 AggregateFunction(uniq, String)。咱们关注的是一些独特的指标，这些指标是在 String 列上计算的（为了进一步优化，你可能应该应用 FixedString 或二进制数据）。

让咱们将数据插入预聚合表：

INSERT INTO events_unique 
SELECT date, group_id, client_id, event_type, product_id, uniqState(visitor_id) AS value 
  FROM events 
 GROUP BY date, group_id, client_id, event_type, product_id;

进行冒烟测试，确认其能够失常运行：

SELECT uniqMerge(value) FROM events_unique GROUP BY product_id;
当初让咱们比拟原始表和预聚合表的查问性能。原始查问：

SELECT uniq(visitor_id) AS c 
  FROM events 
 WHERE client_id =‘aaaaaaaa’AND event_type =‘click’AND product_id =‘product1’AND date >=‘2017–01–20’AND date <‘2017–02–20’;

┌──────c─┐
│ 457954 │
└────────┘
1 rows in set. Elapsed: 0.948 sec. Processed 13.22 million rows, 1.61 GB (13.93 million rows/s., 1.70 GB/s.)

预聚合表的后果：

SELECT uniqMerge(value) AS c 
  FROM events_unique 
 WHERE client_id =‘aaaaaaaa’AND event_type =‘click’AND product_id =‘product1’AND date >=‘2017–01–20’AND date <‘2017–02–20’;

┌──────c─┐
│ 457954 │
└────────┘
1 rows in set. Elapsed: 0.050 sec. Processed 39.39 thousand rows, 8.55 MB (781.22 thousand rows/s., 169.65 MB/s.)

结果表明，咱们的解决工夫缩短到 1/20。

在实践中，将物化视图与 AggregatingMergeTree 引擎联合应用，会比应用独自的表更不便。

总结

ClickHouse 可让你将聚合状态存储在数据库中，而不仅仅是存储在业务利用中，这无望带来颇具吸引力的性能优化和新用例。无关更多详细信息，请查看对于 AggregatingMergeTree 引擎的丰盛文档。

后续

您曾经理解了在 ClickHouse 中解决实时更新相干内容，本系列还包含其余内容：

• 在 ClickHouse 中解决实时更新
• 应用新的 TTL move，将数据存储在适合的中央
• 在 ClickHouse 物化视图中应用 Join
• ClickHouse 聚合函数和聚合状态（本文）
• ClickHouse 中的嵌套数据结构

原文链接
本文为阿里云原创内容，未经容许不得转载。