您知道 ClickHouse 是世界上查询 JSON 文件最快的工具吗?这里 是证明!
此外,您是否曾经想过 ClickHouse 二进制文件作为图片会是什么样子?我们也想过。它很大,很漂亮——而且是灰色的?这里 看一看。
本月,请继续阅读关于 ClickHouse Cloud 简化定价、即将举办的完整“巡回日历”、ClickHouse 22.10 中的新功能、一些现代数据集炼金术以及您定期阅读的轻量级材料。
顺便说一下,如果您是在我们的网站上阅读本文,您是否知道您可以将每个月的新闻稿作为电子邮件接收至您的收件箱?这里 注册。
ClickHouse Cloud - 简化定价
好消息,我们简化了 ClickHouse Cloud 服务的定价。现在我们只收取两项费用:计算和存储。访问定价页面 了解详情。在接下来的几天内,即 2022 年 11 月 15 日之前,我们还提供额外 500 美元的积分。
10 月 27 日,我们播出了正式的发布网络研讨会。我们讨论了我们构建 ClickHouse Cloud 的原因和方式,演示了演示并回答了您的问题。这里观看录制内容。
巡回日历(又名“即将举行的活动”)
接下来的几周将充满 ClickHouse 活动。我们希望在虚拟或亲自参加活动时,能够与许多人见面。看看您可以在哪里找到其他 ClickHouse 用户(以及我们)。
ClickHouse v22.11 发布网络研讨会
- 时间?太平洋标准时间 11 月 17 日星期四上午 9 点 / 中欧时间下午 6 点
- 如何参加?这里 注册。
ClickHouse Cloud 入门研讨会
- 内容?从我们的团队那里了解如何开始使用 ClickHouse Cloud。我们将讨论架构、数据建模、视图、数据摄取和性能调优,并在最后安排时间进行问答。
- 时间?太平洋标准时间 11 月 10 日星期四上午 10 点 (AMER)
聚会我们将举办一系列聚会,由 ClickHouse 用户和专家进行演讲。准备您的好奇心和问题。也带上一些同事和朋友!
斯德哥尔摩聚会
- 时间?12 月 1 日星期四下午 6 点(这里 注册)
- 演讲者:RELEX、ClickHouse
柏林聚会
- 时间?12 月 5 日星期一晚上 6 点(这里 注册)
- 演讲者:德意志银行、BENOCS、ClickHouse
纽约市聚会
- 时间?12 月 6 日星期二晚上 6 点(这里 注册)
- 演讲者:彭博社、迪士尼、Prequel、Rokt、ClickHouse
特拉维夫聚会
- 时间?1 月 16 日星期一晚上 6 点(这里 注册)
- 演讲者:待定
ClickHouse v22.10
在上个月,ClickHouse 收到了第 100,000 次提交!您可以使用 git log
查找它,但首先,让我们看看 10 月份版本中的新功能。
- 备份到 S3 ClickHouse 现在可以将您的数据备份到 S3 存储桶。您可以备份(和还原)单个表和字典,或备份整个数据库。支持完整备份和增量备份。
- 重置设置 您现在可以使用
SET setting_name = DEFAULT
将设置重置为其默认值。 - 始终合并旧分区 您可以使用
min_age_to_force_merge_seconds
指定在特定时间后将合并分区。这样,您可以确保在设定时间后,数据将位于最少的磁盘文件数量中,从而提高查询性能。它在使用FINAL
修饰符 以及do_not_merge_across_partitions_select_final
时也很有用,因为 ClickHouse 无需在查询时合并这些文件。 - 太多分区 我们放宽了太多分区的检查。默认情况下,如果分区中的活动分区数量超过 300(可使用
parts_to_throw_insert
配置),ClickHouse 将抛出异常。有了此更改,如果平均分区大小大于 10 GiB,则不会抛出错误,从而允许非常大的分区(100+ TB)。它可以使用新设置max_avg_part_size_for_too_many_parts
(默认值:10 GiB)进行配置。 - 随机数据 为了帮助您生成比均匀分布更逼真的随机数据,现在有 11 个新的
rand*
函数。例如,randNormal
和randExponential
。
以及一项预览功能
- Kafka Connect Sink 我们已经开始开发 ClickHouse 的官方 Kafka Connect Sink。它将支持完全一次语义,无需任何第三方依赖项。您可以在这里 找到当前的源代码。如果您将 ClickHouse 与 Kafka 一起使用,请尝试一下并给我们一些反馈!
看看发布网络研讨会幻灯片 和 录制内容,除非您想停留在长期支持 (LTS) 版本上,否则请升级。
本月查询:混淆的净化效果
有用的数据集就像大钻石:很难找到,但非常有价值。当您拥有了一些数据集时,通常会将它们锁定在安全的空间中——保险库或数据库中。不幸的是,最好的数据集通常包含有关客户的敏感信息、专有数据或商业机密。因此,它们只存在于生产数据库中,即使是用于内部开发和测试目的,也必须使用其他数据,通常是合成生成的测试数据。
但是,合成数据通常有缺陷。它通常不能准确地反映真实数据的实际情况。维度基数、数值范围和分布以及空值比例等特征通常会与实际数据有很大差异。对于开发和测试扫描大量数据以得出结果的查询来说,这是一个主要问题——这正是 ClickHouse 擅长的。
例如,对于包含 GROUP BY dimension
的查询,dimension
的基数是数百还是数十亿,内存使用量和性能之间存在很大差异。GROUP BY
将使用一个哈希映射进行计算,每个不同值对应一个键。几百个键值对可以轻松地放入内存中,查询速度将非常快——而对于数十亿个值,哈希映射必须卸载到磁盘,导致查询速度变慢,甚至查询可能会失败。
那么,我们如何使用在特征(例如列中值的基数)上接近实际数据的但不是实际数据的数据进行开发和测试?
一个答案是混淆。ClickHouse 实际上附带了一个内置的混淆器,无论是 clickhouse-obfuscator
(在 Linux 上)还是 clickhouse obfuscator
(在 Mac 上)。文档在 这里。
ClickHouse 混淆器将读取数据集作为输入,并生成一个在特征上非常相似但不会包含相同实际值的输出数据集。让我们看看它如何使用 英国房价支付 数据集。
首先,看一下一些高级特征
SELECT count(), avg(price), max(price) FROM uk_price_paid ┌──count()─┬──────avg(price)─┬─max(price)─┐ │ 26763022 │ 208231.24594106 │ 932540400 │ └──────────┴─────────────────┴────────────┘
正如我们所看到的,该数据集中房地产交易的总数为 2670 万,平均价格约为 208,000 英镑,历史上最高价格为 9.32 亿英镑。让我们混淆一下。
clickhouse obfuscator --structure "price Int64, date UInt16, postcode1 String, postcode2 String, type String, is_new UInt8, duration String, addr1 String, addr2 String, street String, locality String, town String, district String, county String, category String" --input-format Parquet --output-format Parquet --seed "${RANDOM}${RANDOM}${RANDOM}${RANDOM}" < uk_price_paid.parquet > obfuscated.parquet
注意我们如何将一个 Parquet 文件转换为另一个 - 混淆器适用于非 ClickHouse 数据!让我们检查一下混淆数据集的相同特征
SELECT count(), avg(price), max(price) FROM file('obfuscated.parquet') ┌──count()─┬─────────avg(price)─┬─max(price)─┐ │ 26763022 │ 223585.90603467726 │ 994963827 │ └──────────┴────────────────────┴────────────┘
行数相同 - 但平均价格和最高价格略有变化。即使价格分布也保持大致相同。例如,低于 100 万英镑的价格分布
SELECT band, q1.count AS real, q2.count AS obfuscated FROM (SELECT floor(price, -5) band, count() count FROM file('uk_price_paid.parquet') GROUP BY band) q1 LEFT JOIN (SELECT floor(price, -5) band, count() count FROM file('obfuscated.parquet') GROUP BY band) q2 USING band WHERE band < 1e6 ORDER BY band ┌───band─┬────real─┬─obfuscated─┐ │ 0 │ 8728237 │ 8803178 │ │ 100000 │ 9277684 │ 7936176 │ │ 200000 │ 4422328 │ 5148196 │ │ 300000 │ 1944389 │ 1906225 │ │ 400000 │ 975584 │ 1493438 │ │ 500000 │ 465029 │ 361164 │ │ 600000 │ 291360 │ 221633 │ │ 700000 │ 178879 │ 249621 │ │ 800000 │ 117307 │ 113644 │ │ 900000 │ 77406 │ 166402 │ └────────┴─────────┴────────────┘
值得注意的是,混淆器不会加密或哈希数据 - 所以并非所有信息都丢失(出于目的,以保留特征)。因此,自动将混淆数据集与任何人共享并不安全。但这应该在很大程度上使共享更容易,对于内部使用(例如,用于应用程序的开发和测试)尤其有用。
尽情使用 ClickHouse 混淆器 - 也许你可以释放一个或两个有用的数据集。
阅读角
我们一直在读什么
- 快 100 倍:从 Elasticsearch 到 ClickHouse 的 GraphQL Hive 迁移 The Guild 测试了 InfluxDB、TimescaleDB 和 ClickHouse 来替换他们现有的 Elasticsearch 设置。不出所料(至少对我们来说),ClickHouse 成为明显的赢家 - 查询时间为 100 毫秒,而 TimescaleDB 为 3 秒,InfluxDB 为 5 秒。通过从 Elasticsearch 切换到 ClickHouse,The Guild 现在可以摄取数十亿事件,而不仅仅是数百万事件。
-
ClickHouse 的“七宗罪” 以及如何避免它们 如果你使用 ClickHouse,那么这篇博文适合你。就在万圣节前夕,我们写了 13 个 ClickHouse 用户遇到的常见问题 - 以及如何避免它们。读一读,你可能遇到过其中一些(也许还有一些你即将遇到的)。
-
世界上最快的 JSON 查询工具 - ClickHouse 挑战了 Spark SQL 等通用工具 - 以及 OctoSQL 和 SPyQL 等专门工具 - 并最终胜出。
-
使用 Fluent Bit 将 Kubernetes 日志发送到 ClickHouse 和 使用 Fluent Bit 将 Nginx 日志发送到 ClickHouse 一个关于使用 Fluent Bit 日志处理器和转发器将日志摄取到 ClickHouse 的两部分系列。你应该尝试将日志放入 ClickHouse - 磁盘上的数据大小可能会更小,并且仪表板比你现在拥有的要快得多!
-
使用 ClickHouse 可视化数据 - 第 3 部分 - Metabase - 我们关于使用不同用户界面在 ClickHouse 中可视化数据的系列的第 3 部分。第 3 部分涵盖了 Metabase,而第 1 部分涵盖了 Grafana,第 2 部分涵盖了 Superset。
-
使用 IN 查询和反规范化优化星型模式查询 - 这里有一些关于结合来自多个表的数据的加速 ClickHouse 查询的技巧。例如,使用
IN
而不是JOIN
将查询时间从 19 秒减少到 130 毫秒。 -
深入:ClickHouse 与 PostgreSQL - 与许多其他公司一样,Posthog 最初使用 PostgreSQL,后来迁移到 ClickHouse。在这里,他们详细介绍了他们的想法以及他们取得的收益。此外,还有很多可爱的刺猬。
感谢您的阅读,我们下个月再见。
ClickHouse 团队