随着时间的推移，clickhouse 中的数据逐步增长。为了查询、存储效率的提升我们可能需要计划性删除、移动或聚合历史数据。针对此类数据生命周期管理，clickhouse 提供了简单且强大的工具——TTL，该工具作用于 DDL 子句中。这篇文章将探索 TTL 以及如何使用它来解决多种数据管理任务。 TTL 只能应用在 MergeTree 系列引擎中 一、删除数据在一些特殊的场景中，有时存储过期的数据是没有意义的，因此需要定期执行删除操作。而 clickhouse 只需要在 DDL 中配置 TTL 就可以在后台自动完成。同时对于删除操作又可以细分为删除整行或只删除指标列 1.1 删除整行1. 普通删除假设有一张event表，同时我们期望自动删除所有超过一个月的记录 123456789create table events( event String, time DateTime, value UInt64) engine = MergeTree order by (event, time) ttl time + interval ...
为了实现最佳性能，数据库需要优化其内部数据存储和处理管道的每一步。但是数据库执行的最好的工作是根本没有完成的工作！缓存是一种特别流行的技术，它通过存储早期计算的结果或远程数据来避免不必要的工作，而访问这些数据的成本往往很高。在今天的博文中，介绍一下 ClickHouse 缓存系列的最新成员——查询缓存，在 v23.1 版本中作为实验性特性。 一、缓存一致性问题在实操 clickhouse 的查询缓存前需要先了解一下缓存事务问题，查询缓存通常可以分为事务一致和事务不一致。 在事务一致缓存中，如果 SELECT 查询的结果发生更改或可能发生更改，则数据库会使缓存的查询结果无效（丢弃）。在 ClickHouse 中，更改数据的操作包括在表中插入/更新/删除或折叠合并。事务一致性缓存特别适合 OLTP 数据库，例如MySQL（在v8.0之后删除了查询缓存）和 Oracle。 在事务不一致缓存中，所有缓存条目都被分配了一个有效期，之后它们就会过期，并且基础数据在此期间仅发生很小的变化，那么查询结果中的轻微不准确是可以接受的，这种方法总体上更适合 OLAP 数据库。在一些应用场 ...
Kafka 是大数据领域非常流行的一款分布式消息中间件，是实时计算中必不可少的一环，同时一款 OLAP 系统能否对接 Kafka 也算是考量是否具备流批一体的衡量指标之一。ClickHouse 的 Kafka 表引擎能够直接与 Kafka 系统对接，进而订阅 Kafka 中的 Topic 并实时接受消息数据。 众所周知，在消息系统中存在三层语义，它们分别是： 最多一次（at most once）：可能存在丢失数据的情况 最少一次（at least once）：可能存在重复数据的情况 精准一次（exactly once）：数据不多不少，最为理想的情况 虽然 Kafka 本身能够支持上述三层语义，但一条完整的数据链路支持的语义遵循木桶原理。ClickHouse 24.8（2024 年 9 月 3 日）前还不支持 exactly once 语义，但因为 ClickHouse 有强大的 MergeTree 系列引擎且在明确的业务场景加持下(定义业务主键)具备幂等性，当幂等性 + at least once 语义也是可以实现 exactly once。而在 ClickHouse 24.8 L ...
一、背景在数据仓库的日常工作中，我们经常需要面对海量数据的存储和高效查询问题。尤其是，当业务对性能的要求越来越高、数据量持续增长时，传统的处理方式往往显得笨拙而低效。而这时候，Bitmap（位图）作为一种“看似简单却威力强大”的数据结构，逐渐展现出它的价值。简单来说，Bitmap 就像是一种用“0”和“1”记录信息的小工具。它通过位的形式将数据高效地压缩存储，同时支持快速的集合运算，比如并集、交集、补集等。这些特性使得 Bitmap 在高基数去重、行为统计、快速筛选等场景中表现得尤为出色。比如，给定一个数千万级别的用户群，使用 Bitmap 技术可以在几毫秒内完成某些复杂的查询操作，这在传统方法中可能需要数十秒甚至更长时间。 Bitmap 在数据仓库中的应用非常广泛。无论是帮助优化指标计算，还是提升查询性能，它都能够为开发者解决很多头疼的问题。例如，在广告投放场景下，我们需要实时统计某一人群的曝光次数；在用户运营中，我们可能需要高效筛选出符合特定标签的用户群。这些看似复杂的任务，通过 Bitmap，往往能以优雅的方式轻松解决。 这篇文章希望以实际案例为切入点，结合 Bitmap 的原理 ...
作为一个在工程领域摸爬滚打十年的工程师，我今晚可能在酒精的作用下，毫无顾忌地分享一些心得体会。以下是我酒后吐真言。 我在职业发展上取得的最大进步，是通过跳槽实现的。 技术栈并不是真的那么重要，因为在我所在的领域，大约有15种基本的软件工程模式是适用的。我从事的是数据领域的工作，它与网页开发或嵌入式开发不同。但所有领域都有大约10到20个核心原则，而技术栈只是试图让这些原则更容易实现，所以不必为此烦恼。 人们推崇寻找新工作是有其道理的。如果我对当前的工作感到不满意，那很可能是时候向前看了。 在我曾经工作过的公司里，我结交了一些好朋友，他们将会是我一生的挚友。我并不要求我工作过的每一个地方都必须建立这样的友谊。在那些没有与同事建立友谊的地方，我也能非常快乐地工作；同样地，即使在那些我交到了好朋友的地方，有时我也可能感到不快乐。 我学会了对上司坦诚，既保持真诚，又不至于过于直白，这样在工作中我能够保持自我。最糟糕的情况是什么？被解雇？那也无妨，我相信不久便能找到新的工作机会。 如果我一个季度内因为值班被在凌晨两点钟叫醒超过一次，那么肯定是出了严重的问题，我要么会解决它，要么就会辞职。 再倒 ...
一、如何在 mapPartitions 中释放资源mapPartitions是一种对每个分区进行操作的转换操作，于常用的map操作类似，但它处理的是整个分区而不是单个元素。mapPartitions的应用场景适合处理需要在每个分区内批量处理数据的场景，通常用于优化性能和减少计算开销。例如：减少数据库连接、网络连接等。即然涉及到资源的初始化那么必定伴随着资源的释放，这是本节讨论的重点。 以和 mysql 中数据交互为例，下面是一段伪代码 12345678910rdd.mapPartitions(iter => { // 初始化数据库连接 lazy val connection = initConnection(args) // 迭代数据 val result = iter.map(... /*处理逻辑会使用到 connection 对象*/) // 在返回结果之前需要释放资源 connection.close() // 返回处理结果 result}) 上面的代码在运行阶段之前都是没有问题的（可编译、可打包），不存在语法问题。但是在运行时会报No ...
