欢迎来到 ClickHouse 7月刊。盛夏终于来临(在世界的一半地区),但我们并未放慢脚步。本月刊不仅为您带来最新版本的更新、有趣的链接和即将到来的活动,还为您带来真正令人兴奋的每月查询!
顺便说一句,如果您正在我们的网站上阅读本文,您是否知道您可以每月在收件箱中收到每期新闻通讯的电子邮件? 在此注册。
如果您想继续接收这些更新,请点击此处确认您的电子邮件偏好。
ClickHouse v23.6
- 10 项新功能。
- 12 项性能优化。
- 31 个错误修复。
您可以在 YouTube 上录制的 v23.6 版本发布电话会议中详细了解所有功能,如果您有兴趣,请不要忘记注册 23.7 版本发布直播电话会议(欢迎提问与解答)。
特别欢迎所有 23.6 版本的新贡献者!ClickHouse 的受欢迎程度很大程度上归功于社区贡献者的努力。看到社区不断壮大总是令人感动。
如果您在这里看到了您的名字,请与我们联系...但我们也会在 Twitter 等平台上找到您。
Chang Chen, Dmitry Kardymon, Hongbin Ma, Julian Maicher, Thomas Panetti, YalalovSM, kevinyhzou, tpanetti, 郭小龙
对几乎排序的数据进行排序
ClickHouse 喜爱排序数据。作为列式数据库,在插入时对数据进行排序是查询性能的基础,也是用户在创建表时需要指定 ORDER BY
子句时遇到的早期概念之一。在 23.6 版本中,ClickHouse 现在将利用数据中的任何自然排序模式来提高查询性能。这在列在大多数情况下已知为单调递增,但不是排序键的一部分的情况下尤其如此。
Mongo 6.x 支持
如果说现代 Web 应用程序堆栈中几乎无处不在的数据存储,那就是 MongoDB。MongoDB 是一种面向文档的数据库,旨在存储和检索类似 JSON 的数据。虽然 ClickHouse 通过表函数对 MongoDB 提供了支持已有一段时间,但 Mongo v5.1 引入了协议更改,需要更新此集成。我们现在很高兴地宣布支持 Mongo 最新 v6 版本。
Transform 函数
数据处理中常见的问题是需要映射值 - 通常是将代码映射为有意义的内容。此任务最好在 SQL 中使用 transform 函数执行。此函数在 ClickHouse 中已支持一段时间,用于数字、日期和字符串。在 23.6 版本中,我们为此函数添加了对所有数据类型的支持。transform 函数现在可用于将列转换为其他类型。
每月查询 - windowFunnel
具有数据库经验的 ClickHouse 新用户通常会对标准 ANSI SQL 之外支持的分析函数数量感到惊讶。这些函数专门用于简化某些查询的编写并加快执行速度。
一个不太为人所知但专为许多企业提出的常见问题而设计的函数是 windowFunnel。在本月的“每月查询”中,我们将探讨如何使用此函数来解决用户行为的漏斗分析。同时,我们将借此机会更多地了解我们自己的贡献者。
windowFunnel 函数允许在滑动时间窗口中计数事件序列。更具体地说,用户可以指定预期序列和允许它们发生的时间段。该函数将反过来计算链中每个子序列发生的事件的最大数量。
此函数的名称表明其预期应用:漏斗分析。这可以简洁地描述为计算用户依次执行的多个事件。通过计算有多少唯一用户按顺序到达每个事件,可以计算出每个步骤的转化率,从而使企业主能够将问题定位到特定阶段。这是电子商务中的一个常见问题,企业旨在确定用户在完成购买所需步骤期间“流失”的方式。
虽然这可以在经典 SQL 中解决,但这是一个 ClickHouse 函数如何显着简化查询的示例。
为了举例说明,我们将使用流行的 Github Events 数据集。此数据集在我们的文档中提供,捕获了自 2011 年以来 GitHub 上的所有事件。这包括诸如用户添加存储库星标、创建分支、发布 PR 和发表评论等事件。此事件数据自然适合漏斗分析。在我们的案例中,我们很好奇地想知道,在我们用户分支 ClickHouse 存储库后,有多少百分比的用户会在 30 天内提出 PR,以及这种行为与其他流行的开源项目相比如何。
对于此查询,我们的事件序列仅包含两种事件类型:ForkEvent
,后跟 PullRequestEvent
。这些事件需要在 30 天内,在 ClickHouse 存储库上,为特定用户发生。
为了提高查询效率,我们首先识别分支了 ClickHouse 存储库的用户
SELECT DISTINCT actor_login AS logins FROM github_events
WHERE ((repo_name = 'ClickHouse/ClickHouse') OR (repo_name = 'yandex/ClickHouse')) AND (event_type = 'ForkEvent'))
windowFunnel 函数的完整参数及其使用的算法可以在我们的文档中找到。总而言之,我们需要指定允许的时间段和事件序列
windowFunnel(2592000)(created_at, event_type = 'ForkEvent', event_type = 'PullRequestEvent')
将我们的分析限制在那些分支了存储库的用户,我们的查询
WITH logins AS
(
SELECT DISTINCT actor_login AS logins
FROM github_events
WHERE (repo_name IN ['yandex/ClickHouse', 'ClickHouse/ClickHouse']) AND (event_type = 'ForkEvent')
)
SELECT
actor_login,
windowFunnel(2592000)(created_at, event_type = 'ForkEvent', event_type = 'PullRequestEvent') AS step
FROM github_events
WHERE (repo_name IN ['yandex/ClickHouse', 'ClickHouse/ClickHouse']) AND (actor_login IN (logins)) AND (event_type IN ['ForkEvent', 'PullRequestEvent'])
GROUP BY actor_login
LIMIT 10
┌─actor_login──────┬─step─┐
│ AntiTopQuark │ 1 │
│ AndreyTokmakov │ 2 │
│ aig │ 1 │
│ maks-buren630501 │ 2 │
│ qwe4815124 │ 1 │
│ amdfansheng │ 1 │
│ lenovore │ 1 │
│ calipeng │ 1 │
│ xiaohan2013 │ 1 │
│ fjteam │ 1 │
└──────────────────┴──────┘
10 rows in set. Elapsed: 0.095 sec. Processed 812.09 thousand rows, 6.30 MB (8.54 million rows/s., 66.20 MB/s.)
这将返回每个用户执行的链中的步骤数,其中 1 表示 Fork 事件,2 表示 Fork 后 30 天内提交 PR。最后,我们需要聚合这些用户,并计算到达每个步骤的用户总数
WITH logins AS
(
SELECT DISTINCT actor_login AS logins
FROM github_events
WHERE (repo_name IN ['yandex/ClickHouse', 'ClickHouse/ClickHouse']) AND (event_type = 'ForkEvent')
)
SELECT
step,
count()
FROM
(
SELECT
actor_login,
windowFunnel(2592000)(created_at, event_type = 'ForkEvent', event_type = 'PullRequestEvent') AS step
FROM github_events
WHERE (repo_name IN ['yandex/ClickHouse', 'ClickHouse/ClickHouse']) AND (actor_login IN (logins)) AND (event_type IN ['ForkEvent', 'PullRequestEvent'])
GROUP BY actor_login
)
GROUP BY step
ORDER BY step ASC
┌─step─┬─count()─┐
│ 1 │ 5234 │
│ 2 │ 1115 │
└──────┴─────────┘
2 rows in set. Elapsed: 0.108 sec. Processed 812.09 thousand rows, 6.30 MB (7.49 million rows/s., 58.03 MB/s.)
因此,大约 17% 的分支 ClickHouse 存储库的用户会在 30 天内继续创建 PR。这感觉像是一个令人鼓舞的数字,但我们很好奇想看看这与其他类似流行的项目相比如何。我们将流行定义为超过 2.5 万颗星和 5 千个分支(是的,这是一个很高的门槛),并计算所有满足条件的项目的这个比率。请注意,这里我们需要按用户和存储库分组,以避免计算用户在一个存储库上进行分支,并在 30 天内在另一个存储库上提交 PR 的情况。这在计算上相当昂贵,但仍然可以在几秒钟内完成
WITH repos AS
(
SELECT if(repo_name = 'yandex/ClickHouse', 'ClickHouse/ClickHouse', repo_name) AS repo_name
FROM github_events
WHERE event_type IN ['ForkEvent', 'WatchEvent']
GROUP BY repo_name
HAVING (countIf(event_type = 'ForkEvent') > 5000) AND (countIf(event_type = 'WatchEvent') > 25000)
)
SELECT
rowNumberInAllBlocks() AS position,
repo,
round(countIf(step = 2) / count(), 3) AS ratio
FROM
(
SELECT
repo,
windowFunnel(2592000)(created_at, event_type = 'ForkEvent', event_type = 'PullRequestEvent') AS step
FROM github_events
WHERE ((repo_name IN (repos)) OR (repo_name = 'yandex/ClickHouse')) AND (event_type IN ['ForkEvent', 'PullRequestEvent'])
GROUP BY
actor_login,
if(repo_name = 'yandex/ClickHouse', 'ClickHouse/ClickHouse', repo_name) AS repo
HAVING step > 0 //ignore users who can raise a PR without forking
)
GROUP BY repo
ORDER BY ratio DESC
LIMIT 25
┌─position─┬─repo───────────────────────────────────┬─ratio─┐
│ 0 │ firstcontributions/first-contributions │ 0.711 │
│ 1 │ tldr-pages/tldr │ 0.458 │
│ 2 │ DefinitelyTyped/DefinitelyTyped │ 0.451 │
│ 3 │ laravel/framework │ 0.373 │
│ 4 │ gatsbyjs/gatsby │ 0.298 │
│ 5 │ rust-lang/rust │ 0.275 │
│ 6 │ sequelize/sequelize │ 0.268 │
│ 7 │ symfony/symfony │ 0.26 │
│ 8 │ ansible/ansible │ 0.231 │
│ 9 │ JuliaLang/julia │ 0.215 │
│ 10 │ facebook/jest │ 0.21 │
│ 11 │ hashicorp/terraform │ 0.202 │
│ 12 │ home-assistant/home-assistant │ 0.199 │
│ 13 │ ripienaar/free-for-dev │ 0.193 │
│ 14 │ fastlane/fastlane │ 0.191 │
│ 15 │ freeCodeCamp/freeCodeCamp │ 0.19 │
│ 16 │ hwchase17/langchain │ 0.186 │
│ 17 │ neovim/neovim │ 0.185 │
│ 18 │ serverless/serverless │ 0.182 │
│ 19 │ vuejs/awesome-vue │ 0.181 │
│ 20 │ kubernetes/minikube │ 0.177 │
│ 21 │ sveltejs/svelte │ 0.176 │
│ 22 │ ClickHouse/ClickHouse │ 0.176 │
│ 23 │ go-gitea/gitea │ 0.175 │
│ 24 │ avelino/awesome-go │ 0.174 │
└──────────┴────────────────────────────────────────┴───────┘
25 rows in set. Elapsed: 2.970 sec. Processed 554.18 million rows, 1.87 GB (186.58 million rows/s., 629.18 MB/s.)
也许所有基于 Github 的指标都倾向于虚荣的练习,但我们认为这里的第 22 名还不错,并且显示了我们用户的健康参与模式。更重要的是,它使我们能够向您展示一个很棒的 ClickHouse 函数,希望它能使您的查询更简单!
有趣链接
以下是我们您可能错过的最喜欢的一些读物,包括
- Monitorama PDX 2023 - 如何在不让公司破产的情况下扩展可观测性 - David Gildeh,Netflix - 来自演讲描述:“随着需要实时收集、存储和查询的数据量呈指数级增长,每家公司都在努力控制其可观测性成本!Netflix 不得不解决这个问题,因为它迅速扩展成为一家拥有全球数亿客户的 Web 规模公司。” 请密切关注 ClickHouse 及其如何融入基础设施!!
- 在 ClickHouse 中使用时间序列数据 - 许多数据集都是随着时间推移收集的,以便分析和发现有意义的趋势。当我们收集日志或业务事件时,每个数据点通常都会分配一个时间。这篇博文基于我们看到用户需要执行的日常任务,提供了使用时间序列数据的技巧和窍门。我们涵盖了查询和常见的数据类型问题(例如处理仪表),并探讨了如何在扩展时提高性能。
- ClickHouse 和 PostgreSQL - 数据天堂中的绝配 - PostgreSQL 和 ClickHouse 代表了关于开源数据库的最佳类别,每个数据库都以其各自的优势和劣势来解决不同的用例。最近我们在 ClickHouse Cloud 中启用了 PostgreSQL(和 MySQL)集成,我们认为应该借此机会提醒用户如何将这些强大的集成与 ClickHouse 一起使用。(系列文章第 1 部分)
- 使用 ClickHouse 进行向量搜索 - 在过去一年中,大型语言模型 (LLM) 以及 ChatGPT 等产品吸引了全世界的想象力,并推动了构建在其之上的一波新功能浪潮。向量和向量搜索的概念是为推荐、问题解答、图像/视频搜索等功能提供支持的核心。如果您错过了,本系列在一个方便的系列中涵盖了向量搜索和 ClickHouse 实现的基础知识。
- 纽约聚会报告:Vantage 从 Redshift 和 Postgres 到 ClickHouse 的旅程 - 如果您错过了 Vantage 在我们最近的纽约聚会上的精彩演讲录音,您可以在我们的聚会报告中阅读所有相关内容。Vantage 分享了他们从 Redshift 和 Postgres 迁移到 ClickHouse 的原因,包括他们面临的挑战、切换的决定以及获得的收益。
即将到来的活动
在您的日历上标记以下活动
ClickHouse v23.7 版本发布网络研讨会
7月27日星期四 @ 太平洋夏令时间上午 9 点 / 欧洲中部夏令时间下午 6 点
在此注册。
波士顿聚会
7月18日星期二 @ 美东夏令时间下午 6 点
在此注册。
纽约聚会
7月19日星期三 @ 美东夏令时间下午 6 点
在此注册。
多伦多聚会
7月20日星期四 @ 美东夏令时间下午 6 点
在此注册。
新加坡聚会
7月27日星期四 @ 新加坡标准时间下午 6 点
在此注册。
ClickHouse 基础知识 - 免费培训
8月16日星期三 @ 英国夏令时间下午 1 点 / 欧洲中部夏令时间下午 2 点
在此注册。
ClickHouse Cloud 入门 - 免费培训
8月23日星期三 @ 太平洋夏令时间上午 8 点 / 美东夏令时间上午 11 点 / 欧洲中部夏令时间下午 5 点
在此注册。
感谢您的阅读,我们下个月再见。
ClickHouse 团队