欢迎阅读 7 月 ClickHouse 新闻简报。夏季终于来临(在世界的一半地区),但我们并没有放慢脚步。本月版的新闻简报不仅为您带来了最新版本更新、有趣链接和即将举行的活动信息,还带来了一个激动人心的“本月查询”!
顺便说一句,如果您是在我们的网站上阅读这封简报,您是否知道您可以通过电子邮件接收每月的新闻简报?在此注册。
如果您希望继续接收这些更新,请点击此处确认您的电子邮件偏好设置。
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 函数
数据处理中一个常见的问题是需要映射值,通常是将代码映射到有意义的内容。使用 transform 函数在 SQL 中执行此任务是最好的方法。此函数在 ClickHouse 中已被支持一段时间,用于数字、日期和字符串。在 23.6 版本中,我们向此函数添加了对所有数据类型的支持。现在可以使用 transform 函数将列转换为其他类型。
本月查询 - windowFunnel
具有先前数据库经验的用户在初次使用 ClickHouse 时,通常会对除了标准 ANSI SQL 之外支持的分析函数数量感到惊讶。这些函数专门针对简化某些查询的编写以及加快执行速度而设计。
一个不太为人知的函数,专为许多企业提出的一个常见问题而设计,那就是 windowFunnel 函数。在本月的“本月查询”中,我们将探讨如何使用此函数来解决用户行为的漏斗分析。同时,我们将借此机会更深入地了解我们自己的贡献者。
windowFunnel 函数允许在滑动时间窗口内计算事件序列。更具体地说,用户可以指定一个预期的序列和允许发生的事件时间段。该函数将反过来计算链中每个子序列发生的事件的最大数量。
此函数的名称表明了它的预期应用:漏斗分析。简而言之,它可以描述为对用户执行的若干个连续事件进行计数。通过计算到达每个事件序列的唯一用户数量,可以计算出每个步骤的转化率,从而使企业主能够将问题定位到某个特定阶段。这是电子商务中一个常见的问题,企业希望确定用户在完成购买所需步骤时,是如何“流失”的。
虽然这可以通过在经典 SQL 中解决,但这是一个 ClickHouse 函数如何显著简化查询的示例。
为了说明目的,我们将使用流行的 Github 事件数据集。此数据集存在于我们的文档中,它捕获了自 2011 年以来在 Github 上发生的所有事件。这包括用户添加仓库星标、创建分支、发布 PR 和发表评论等事件。此事件数据自然适合进行漏斗分析。在我们的案例中,我们很好奇地想知道,在我们 fork ClickHouse 仓库的用户中,有多少人在 30 天内发布了 PR,以及这种行为与其他流行的开源项目相比如何。
对于此查询,我们的事件序列仅包含两种事件类型:ForkEvent
后跟 PullRequestEvent
。这些事件需要针对特定用户,在 ClickHouse 仓库中,在 30 天内发生。
为了提高查询效率,我们首先确定已 fork 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')
将我们的分析限制在 fork 过该仓库的用户身上,我们的查询为
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% fork 过 ClickHouse 仓库的用户会在 30 天内创建 PR。这似乎是一个令人鼓舞的数字,但我们很好奇地想知道,与其他同等流行的项目相比如何。我们将“流行”定义为拥有超过 25k 个星标和 5k 个 fork 的项目(是的,门槛很高),并计算满足此条件的所有项目的比例。请注意,我们在此需要按用户和仓库进行分组,以避免计算在 30 天内 fork 某个仓库并为另一个仓库发布 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 必须解决这个问题,因为它迅速发展成为一家拥有全球 1 亿用户的 Web 规模公司。” 注意 ClickHouse 以及它如何融入基础设施!
- 在 ClickHouse 中处理时间序列数据 - 许多数据集是随着时间的推移收集的,用于分析和发现有意义的趋势。每个数据点通常都分配有一个时间,当我们收集日志或业务事件时。这篇博文提供了处理时间序列数据的技巧和窍门,这些技巧和窍门基于我们看到用户需要执行的日常任务。我们涵盖了查询和常见的数据类型问题,例如处理指标,并探讨了随着规模的扩大如何提高性能。
- ClickHouse 和 PostgreSQL - 天作之合 - PostgreSQL 和 ClickHouse 代表了开源数据库方面的佼佼者,它们各自以各自的优势和劣势处理不同的用例。我们最近在 ClickHouse Cloud 中启用了 PostgreSQL(以及 MySQL)集成,我们认为这是一个提醒用户如何将这些强大的集成与 ClickHouse 一起使用的机会。(系列文章的第一部分)
- 使用 ClickHouse 进行向量搜索 - 在过去的一年里,大型语言模型(LLM)以及 ChatGPT 等产品吸引了全世界的想象力,并推动了建立在它们之上的新一波功能。向量和向量搜索的概念是为推荐、问答、图像/视频搜索等功能提供支持的核心。如果您错过了它,本系列将涵盖向量搜索和 ClickHouse 实现的基础知识,所有这些都汇集在一个方便的系列中。
- 纽约聚会报告:Vantage 从 Redshift 和 Postgres 迁移到 ClickHouse 的历程 - 如果你错过了 Vantage 在我们最近的纽约聚会上精彩演讲的录制,你可以在我们的聚会报告中了解所有内容。Vantage 分享了他们从 Redshift 和 Postgres 迁移到 ClickHouse 的原因,包括他们遇到的挑战、切换的决定以及获得的好处。
即将举办的活动
为以下活动做好准备
ClickHouse v23.7 版本发布网络研讨会
星期四,7 月 27 日 @ 9 AM PDT / 6 PM CEST
注册 这里.
波士顿聚会
星期二,7 月 18 日 @ 6 PM EDT
注册 这里.
纽约聚会
星期三,7 月 19 日 @ 6 PM EDT
注册 这里.
多伦多聚会
星期四,7 月 20 日 @ 6 PM EDT
注册 这里.
新加坡聚会
星期四,7 月 27 日 @ 6 PM SST
注册 这里.
ClickHouse 基础知识 - 免费培训
星期三,8 月 16 日 @ 1 PM BST / 2 PM CEST
注册 这里.
ClickHouse Cloud 入门 - 免费培训
星期三,8 月 23 日 @ 8 AM PDT / 11 AM EDT / 5 PM CEST
注册 这里.
感谢您的阅读,我们下个月再见。
ClickHouse 团队