行列转换是数据处理与分析中的关键操作，它能够将数据的结构从行转为列，或从列转为行。这种转换不仅简化了复杂的数据展示，还提升了数据分析的效率。在业务场景中，行列转换常用于报表生成、数据透视和多维度数据分析，通过更直观的方式呈现数据，帮助管理者快速获取关键信息。此外，它还能有效减少数据冗余，优化查询性能，满足灵活多变的业务需求。无论是在财务报表、销售分析，还是市场趋势分析中，行列转换都是不可或缺的工具。 本文会基于 SparkSQL 3.5.x 给出常用的行列转换方式，但本文的重点是介绍pivot和unpivot子句在行列转换场景的应用，其中细节、优雅程度交由开发者自己选择 一、数据准备以下是城市各年GDP 数据的表结构和测试数据，用于后续演示行列转换 create table city_gdp( city string comment '城市名', year int comment '年份', gdp double comment '单位：亿') comment '城市 gdp' s ...
一、背景在数据仓库的日常工作中，我们经常需要面对海量数据的存储和高效查询问题。尤其是，当业务对性能的要求越来越高、数据量持续增长时，传统的处理方式往往显得笨拙而低效。而这时候，Bitmap（位图）作为一种“看似简单却威力强大”的数据结构，逐渐展现出它的价值。简单来说，Bitmap 就像是一种用“0”和“1”记录信息的小工具。它通过位的形式将数据高效地压缩存储，同时支持快速的集合运算，比如并集、交集、补集等。这些特性使得 Bitmap 在高基数去重、行为统计、快速筛选等场景中表现得尤为出色。比如，给定一个数千万级别的用户群，使用 Bitmap 技术可以在几毫秒内完成某些复杂的查询操作，这在传统方法中可能需要数十秒甚至更长时间。 Bitmap 在数据仓库中的应用非常广泛。无论是帮助优化指标计算，还是提升查询性能，它都能够为开发者解决很多头疼的问题。例如，在广告投放场景下，我们需要实时统计某一人群的曝光次数；在用户运营中，我们可能需要高效筛选出符合特定标签的用户群。这些看似复杂的任务，通过 Bitmap，往往能以优雅的方式轻松解决。 这篇文章希望以实际案例为切入点，结合 Bitmap 的原理 ...
作为一个在工程领域摸爬滚打十年的工程师，我今晚可能在酒精的作用下，毫无顾忌地分享一些心得体会。以下是我酒后吐真言。 我在职业发展上取得的最大进步，是通过跳槽实现的。 技术栈并不是真的那么重要，因为在我所在的领域，大约有15种基本的软件工程模式是适用的。我从事的是数据领域的工作，它与网页开发或嵌入式开发不同。但所有领域都有大约10到20个核心原则，而技术栈只是试图让这些原则更容易实现，所以不必为此烦恼。 人们推崇寻找新工作是有其道理的。如果我对当前的工作感到不满意，那很可能是时候向前看了。 在我曾经工作过的公司里，我结交了一些好朋友，他们将会是我一生的挚友。我并不要求我工作过的每一个地方都必须建立这样的友谊。在那些没有与同事建立友谊的地方，我也能非常快乐地工作；同样地，即使在那些我交到了好朋友的地方，有时我也可能感到不快乐。 我学会了对上司坦诚，既保持真诚，又不至于过于直白，这样在工作中我能够保持自我。最糟糕的情况是什么？被解雇？那也无妨，我相信不久便能找到新的工作机会。 如果我一个季度内因为值班被在凌晨两点钟叫醒超过一次，那么肯定是出了严重的问题，我要么会解决它，要么就会辞职。 再倒 ...
OLAP 数据库设计的宗旨在于分析适合一次插入多次查询的业务场景，市面上成熟的 AP 数据库在更新和删除操作上支持的均不是很好，当然 clickhouse 也不例外。但是不友好不代表不支持，本文主要介绍在 clickhouse 中如何实现数据的删除，以及最新版本中 clickhouse 所做的一些技术突破。 一、mutation刚接触 clickhouse 的小伙伴或许对 mutation 就很熟悉了，mutation 查询可以看成 alter 语句的变种。虽然 mutation 能够最终实现修改和删除的需求，但不能完全用通常意义的 delete 和 update 来理解，我们需要清醒的认识到它的不同： mutation 是一个很重的操作，适合批量数据操作 不支持事务、一旦操作立刻生效无法回滚 mutation 为异步操作 1.1 实操创建一张表用于测试 mutation 操作 create table mutations_operate( UserId UInt64, Score UInt64, CreateTime DateTime) eng ...
一、如何在 mapPartitions 中释放资源mapPartitions是一种对每个分区进行操作的转换操作，于常用的map操作类似，但它处理的是整个分区而不是单个元素。mapPartitions的应用场景适合处理需要在每个分区内批量处理数据的场景，通常用于优化性能和减少计算开销。例如：减少数据库连接、网络连接等。即然涉及到资源的初始化那么必定伴随着资源的释放，这是本节讨论的重点。 以和 mysql 中数据交互为例，下面是一段伪代码 rdd.mapPartitions(iter => { // 初始化数据库连接 lazy val connection = initConnection(args) // 迭代数据 val result = iter.map(... /*处理逻辑会使用到 connection 对象*/) // 在返回结果之前需要释放资源 connection.close() // 返回处理结果 result}) 上面的代码在运行阶段之前都是没有问题的（可编译、可打包），不存在语法问题。但是在运行时会报No operations ...
一、问题复现不知你是否遇到过 join 结果明显不匹配的情况，例如on t1.join_key = t2.join_key中两个join_key明显不相等，但 join 的结果却将其匹配在一起。今日博主在通过用户 id 关联获取用户信息时发现一个用户 id 可以在用户维表中匹配出若干条（用户维表不存在数据重复），如下： -- 业务表create table tmp_hz_perm.tmp_20240520_1( id string) stored as parquet;-- 用户维度表create table tmp_hz_perm.tmp_20240520_2( id bigint, name string) stored as parquet; 插入若干条数据 insert into tmp_hz_perm.tmp_20240520_1values ('4268348961309240666');insert into tmp_hz_perm.tmp_20240520_2values (4268348961309240666, ' ...
为了实现最佳性能，数据库需要优化其内部数据存储和处理管道的每一步。但是数据库执行的最好的工作是根本没有完成的工作！缓存是一种特别流行的技术，它通过存储早期计算的结果或远程数据来避免不必要的工作，而访问这些数据的成本往往很高。在今天的博文中，介绍一下 ClickHouse 缓存系列的最新成员——查询缓存，在v23.1版本中作为实验性特性。 一、缓存一致性问题在实操 clickhouse 的查询缓存前需要先了解一下缓存事务问题，查询缓存通常可以分为事务一致和事务不一致。在事务一致缓存中，如果 SELECT 查询的结果发生更改或可能发生更改，则数据库会使缓存的查询结果无效（丢弃）。在 ClickHouse 中，更改数据的操作包括在表中插入/更新/删除或折叠合并。事务一致性缓存特别适合 OLTP 数据库，例如 MySQL（在v8.0之后删除了查询缓存）和 Oracle。在事务不一致缓存中，所有缓存条目都被分配了一个有效期，之后它们就会过期，并且基础数据在此期间仅发生很小的变化，那么查询结果中的轻微不准确是可以接受的，这种方法总体上更适合 OLAP 数据库。在一些应用场景中数 ...
