时间过得真快,转眼间就到了 2023 年,并且已经是今年的第二份新闻快讯了!本月的阅读清单整理起来特别困难,因为内容实在太多了。如果您没有关注 博客 或者我们的社交媒体,您应该关注一下。未来几周将会有很多精彩活动,包括网络研讨会、线下活动以及…当然…即将发布的 23.2 版本。
如果您想继续接收这些更新,请 点击此处 确认您的电子邮件偏好设置。
即将举行的活动
请将以下活动标记在您的日历上
ClickHouse v23.02 版本发布网络研讨会
时间? 2 月 23 日星期四,太平洋标准时间上午 9 点 / 中欧时间下午 6 点
如何加入? 在 此处 注册。
ClickHouse 会议 - 阿姆斯特丹
时间? 3 月 9 日星期四,中欧时间下午 6 点
如何加入? 在 此处 注册。
ClickHouse 会议 - 旧金山
时间? 3 月 14 日星期二,太平洋标准时间下午 6 点
如何加入? 在 此处 注册。
ClickHouse 会议 - 奥斯汀
时间? 3 月 16 日星期四,中欧时间下午 6 点
如何加入? 在 此处 注册。
即将举行的免费培训
ClickHouse Cloud 入门
时间? 2 月 28 日星期二,太平洋标准时间上午 8 点
如何加入? 在 此处 注册。
ClickHouse 研讨会
时间? 2023 年 3 月 8 日和 9 日,太平洋标准时间上午 8 点
如何加入? 在 此处 注册。
ClickHouse v23.1
与往常一样,1 月份的版本并没有让我们失望。新的一年有一个良好的开端,发布了许多重要功能。请查看 博客文章。
- 倒排全文索引 - 在此版本中,我们在 ClickHouse 中添加了对倒排索引的实验性支持,作为数据跳过索引。虽然这不会使 ClickHouse 成为一个功能齐全的搜索引擎,但它为改进基于标记的特定查询的性能引入了一些有趣的可能性。
- 参数化视图 - 任何编写大量 SQL 代码的人都会很快学会欣赏视图。它们允许用户抽象掉复杂的查询,并以表格语法公开它们。到目前为止,用户只能创建静态视图。随着 ClickHouse 23.1 版本的发布,我们可以创建基于查询时传递的参数的动态视图。
- 查询结果缓存 - 为了实现最佳性能,分析型数据库会优化其内部数据存储和处理管道的每一步。但数据库执行的最佳工作是根本不执行任何工作!在 23.1 版本中,我们在 ClickHouse 缓存家族中添加了一个新成员:查询结果缓存!
建议您花一些时间观看 直播演示的录制视频,除非您想继续使用 长期支持 (LTS) 版本,否则请进行升级。
本月查询 - “从旧环境中形成新环境”
可能难以置信,但有时可能拥有如此多的数据,以至于在所需的响应时间内进行查询不切实际…即使使用 ClickHouse 也是如此。那么,当您克服了查询响应时间(在您有时间眨眼的时间内)的冲击之后,还有哪些选择呢!??! 好吧,这时我们就会求助于 ClickHouse 工具箱,并拿出 SAMPLE BY。
通常我们不需要精确的答案,尤其是在您的源数据不精确且近似答案足够的情况下。在 PB 甚至 TB 规模下,一些企业可以接受一些不精确性,以换取显着降低成本。或者,严格的延迟要求可能比完全准确性更重要。这就是 SAMPLE BY 的精神。
以 Wikistat 数据集为例。它为我们提供了从 2015 年 5 月到 2022 年 4 月每个小时维基百科上每个页面的行,以及访问次数。这是一个相当大的数据集,大约有 4250 亿行,未压缩状态下为 15 TB。对于那些有空闲时间的人,您可以按照 此处 的说明下载并将它加载到 ClickHouse 中。
假设我们想计算自 2015 年以来每个月的平均页面点击次数。这需要对整个表进行扫描才能计算答案。在一台 60 核机器上,没有任何调整,ClickHouse 在 5 分钟内(受 I/O 限制)运行此查询。
SELECT month, avg(hits) FROM wikistat GROUP BY toStartOfMonth(time) AS month ORDER BY month ASC ┌──────month─┬──────────avg(hits)─┐ │ 2015-05-01 │ 3.617108988953329 │ │ 2015-06-01 │ 3.4978754072915894 │ │ 2015-07-01 │ 3.3329051255889595 │ │ 2015-08-01 │ 3.3877185707856237 │ │ 2015-09-01 │ 3.4814217901734508 │ … │ 2022-11-01 │ 3.5633514296196567 │ │ 2022-12-01 │ 3.5317530490738696 │ │ 2023-01-01 │ 3.5829006605488463 │ │ 2023-02-01 │ 3.4581641236938476 │ └────────────┴────────────────────┘ 94 rows in set. Elapsed: 278.166 sec. Processed 425.11 billion rows, 5.10 TB (1.53 billion rows/s., 18.34 GB/s.)
即使我们可以通过一些调整来加快速度,也不可能实现足够的性能提升,以使此查询在不到一分钟内完成(没有投影,例如 ORDER BY (cityHash64(path), time)
)。但是假设我们对这些值的近似值感到满意。我们可以尝试通过将查询限制在前 100 万行来进行简单的手动采样。
SELECT month, avg(hits) FROM ( SELECT time, hits FROM wikistat LIMIT 1000000 ) GROUP BY toStartOfMonth(time) AS month ORDER BY month ASC ┌──────month─┬──────────avg(hits)─┐ │ 2015-05-01 │ 2.359986873769416 │ │ 2015-06-01 │ 2.292891439278604 │ │ 2015-07-01 │ 2.3796534376746785 │ │ 2015-08-01 │ 2.229300091491308 │ ... │ 2022-01-01 │ 2.395112662646779 │ │ 2022-02-01 │ 2.5044186449488826 │ │ 2022-03-01 │ 2.168976377952756 │ │ 2022-04-01 │ 2.182795698924731 │ └────────────┴────────────────────┘ 84 rows in set. Elapsed: 0.290 sec. Processed 4.91 million rows, 58.87 MB (16.91 million rows/s., 202.88 MB/s.)
从 300 秒到 0.2 秒,速度提高了很多,但结果显然不精确 - 您的经理不太可能接受这种精度,无论成本和延迟节省多少!这可以归因于此处缺乏随机性,即我们只是使用前 100 万行。
为了解决这个问题,ClickHouse 提供了本机随机采样。这允许用户仅对数据的随机部分(样本)执行查询。这要求我们在创建表时定义采样键,该键 ideally 应该是主鍵的前缀,以实现最佳性能。
CREATE TABLE default.wikistat_sampled ( `time` DateTime CODEC(Delta(4), ZSTD(3)), `project` LowCardinality(String), `subproject` LowCardinality(String), `path` String CODEC(ZSTD(3)), `hits` UInt64 CODEC(ZSTD(3)) ) ENGINE = MergeTree ORDER BY (cityHash64(path), time) SAMPLE BY cityHash64(path)
这里有几个关键点
- SAMPLE BY 表达式必须是主键的一部分,并且必须返回一个整数 - 因此我们使用 cityHash64 函数。确保它不是一个递增的数字,并且在空间中随机分布,以便进行随机采样 - 提示:使用哈希函数对自动递增的整数进行随机化。
- 如果它的数据类型是均匀分布在域中的。在本例中,path 事实上并不完美,因为它没有完全满足此属性,但对于我们的示例来说已经足够了。更好地分布的值会导致更好的采样和更精确的估计。
- 如果需要最佳采样性能,如本例所示,SAMPLE BY 列应为主鍵中的第一个元素。如果您需要优化 Path 的匹配,可以将它放在第二位,或者只使用
cityHash64(path)=cityHash64(“value”)
。无论您如何包含它,都要确保低基数列排在前面,以允许 使用通用排除算法。
现在我们可以进行查询,只使用一小部分数据 - 将样本表示为 绝对行数 或 从 0 到 1 的比率。下面,我们使用 0.01 的值利用 1% 的数据。
SELECT month, avg(hits) FROM wikistat_sampled SAMPLE 0.01 GROUP BY toStartOfMonth(time) AS month ORDER BY month ASC ┌──────month─┬──────────avg(hits)─┐ │ 2015-05-01 │ 3.2243997815421004 │ │ 2015-06-01 │ 3.1547988082990828 │ │ 2015-07-01 │ 2.9813449766968887 │ │ 2015-08-01 │ 3.0210786179578397 │ │ 2015-09-01 │ 3.1277045971550463 │ │ 2022-11-01 │ 3.4243634422663884 │ │ 2022-12-01 │ 3.415336905631455 │ │ 2023-01-01 │ 3.4066985347564027 │ │ 2023-02-01 │ 3.254118466286919 │ └────────────┴────────────────────┘ 94 rows in set. Elapsed: 6.272 sec. Processed 4.26 billion rows, 179.40 GB (679.64 million rows/s., 28.60 GB/s.)
请注意,结果的准确性是合理的,并且性能得到了显著提升。此采样完全是确定性的,并且对于相同值的表格而言,在各表格之间保持一致。最后需要注意的是,以上方法适用于平均值,但对于其他计算(例如求和),我们需要考虑到我们在任何计算中都只使用了一个样本。请考虑上面的查询,但计算每月点击次数。
SELECT month, sum(hits) FROM wikistat GROUP BY toStartOfMonth(time) AS month ORDER BY month ASC ┌──────month─┬───sum(hits)─┐ │ 2015-05-01 │ 18505958911 │ │ 2015-06-01 │ 16325574540 │ │ 2015-07-01 │ 15541045668 │ │ 2015-08-01 │ 15763416762 │ │ 2022-10-01 │ 16041055714 │ │ 2022-11-01 │ 16195366347 │ │ 2022-12-01 │ 15383779088 │ │ 2023-01-01 │ 16631174276 │ │ 2023-02-01 │ 5061601075 │ └────────────┴─────────────┘ 94 rows in set. Elapsed: 289.147 sec. Processed 425.11 billion rows, 5.10 TB (1.47 billion rows/s., 17.64 GB/s.)
SELECT month, sum(hits) * 100 FROM wikistat_sampled SAMPLE 1 / 100 GROUP BY toStartOfMonth(time) AS month ORDER BY month ASC ┌──────month─┬─multiply(sum(hits), 100)─┐ │ 2015-05-01 │ 16546351200 │ │ 2015-06-01 │ 14769222800 │ │ 2015-07-01 │ 13938421600 │ │ 2015-08-01 │ 14087318900 │ │ 2022-10-01 │ 15483441000 │ │ 2022-11-01 │ 15595982500 │ │ 2022-12-01 │ 14908441500 │ │ 2023-01-01 │ 15842792600 │ │ 2023-02-01 │ 4772219400 │ └────────────┴──────────────────────────┘ 94 rows in set. Elapsed: 6.184 sec. Processed 4.26 billion rows, 179.40 GB (689.32 million rows/s., 29.01 GB/s.)
阅读列表
以下是我们上个月最喜欢的几篇文章。
- ClickHouse 23.1 版本发布 - 新年快乐!同时,ClickHouse 也迎来了新的版本。我们很高兴推出 23.x 系列的第一个版本,即 23.1 版本。
- ClickHouse 查询缓存介绍 - 查询缓存基于这样一个理念:在某些情况下,可以缓存昂贵的
SELECT
查询的结果,以便在后续执行相同查询时可以直接从缓存中获取结果。 - 在 ClickHouse 中使用聚合组合器 - 组合器允许扩展和混合聚合以应对各种数据结构。此功能使我们能够调整查询而不是表格来回答最复杂的问题。
- 使用 ClickHouse 分析 AWS 流日志 - 调试安全组问题,监控入站和出站流量,检查跨可用区流量,所有这些都是为了降低云支出。AWS VPC 流日志允许您捕获有关进出 VPC 中网络接口的 IP 流量的信息。
- 在 ClickHouse 中引入倒排索引 - 在经过长时间的开发后,ClickHouse v23.1 发布了备受期待的功能 - 实验性地支持倒排索引。非常感谢 IBM 在过去六个月中开发并贡献了倒排索引代码。
- ClickHouse 和 dbt - 来自社区的礼物 - 作为一家致力于开源理念的公司,我们不仅要接受社区的请求,还要接受新功能和新集成。在本文中,我们将探讨 dbt、它与 ClickHouse 相结合带来的潜在价值,以及支持更高级功能不断发展的小故事。
- 使用 TTL 管理 ClickHouse 中的数据生命周期 - 如果您在 ClickHouse 中分析的数据随着时间的推移而增长,您可能需要计划按计划移动、删除或汇总较旧的数据。ClickHouse 拥有一个简单但功能强大的数据生命周期管理工具,可以使用 DDL 语句的
TTL
子句进行配置。 - ClickHouse 中的数据格式介绍 - 新接触 ClickHouse 的用户通常会对支持的数据格式数量感到惊讶,但有时需要帮助确定加载数据的最佳和最简单方法。本文简要概述了 ClickHouse 对不同格式的广泛支持以及如何加载本地文件。
- ClickHouse Fiddle — ClickHouse 的 SQL Playground - 有时我们想在线运行 SQL 查询以验证它们,与他人共享它们,或者只是因为我们懒得在本地安装数据库。在线 SQL Playground 可以帮助我们实现这一点。
- 在 ClickHouse 中使用物化视图 - 在现实世界中,数据不仅需要存储,还需要进行处理。在本文中,我们将探讨物化视图及其如何在 ClickHouse 中用于加速查询以及数据转换、过滤和路由任务。
感谢您的阅读,我们下个月再见。
ClickHouse 团队