GLM-4.5 & Dify：零成本构建 PostAI

Sat, 10 Jan 2026 17:13:57 GMT

PostAI 是博客网站与 AI 结合的产物，为网站提供智能客服与搜索增强功能，同时对于首次访问网站的用户可以依靠 PostAI 快速了解网站主题与热门文章。因此 PostAI 的角色是：

智能客服
智能搜索
智能摘要

如果您是在主站中刷到这篇文章，任意地方鼠标右键点击「智能管家」即可体验，其它渠道可以先访问：https://blog.kpretty.tech/

一、设计思路

围绕「客服」、「搜索」和「摘要」容易想到的是 AI + 知识库，将博客与文章相关的数据定时同步到知识库。例如：dify 与扣子的知识库都提供基于 sitemap 的抓取工具，但是因为知识库依赖召回策略，当用户想要了解指定文章内容时是期望将整篇文章内容都返回给 AI，而知识库往往只能返回片段或者召回到其它片段。总体来说知识库在内容完整性与时效性不能很好的适配 PostAI 场景

知识库也可以不切分，但整体来说比较黑盒不自由。同时知识库也需要定期维护成本过高

一种轻量级的设计思路便是：假如可以提供博客元数据查询工具以及指定文章链接获取文章内容工具，当用户咨询 AI 关于博客的相关问题时首先调用元数据查询工具，让 AI 自主判断（或小小辅助一下）仅有的元数据是否可以回答用户的问题，如果不可以则再调用查询文章内容工具进行补充。它的好处如下：

实时，接口可以实时获取到最新的博客数据
轻量，无需持久化任何数据
拓展，后续可以增加工具扩展 PostAI 能力

JSON数据处理新思路：深入SparkSQL复杂类型

Tue, 06 Jan 2026 10:13:57 GMT

在实际的数据处理工作中，处理多层嵌套、结构不规则的JSON数据，是一个常见的挑战。
传统方法通常依赖一系列字符串解析函数（如get_json_object）与行展开操作（explode）。这种方式不仅导致SQL语句冗长复杂，难以维护，而且在处理深层嵌套或复杂数组时，性能开销显著，逻辑也容易出错。
面对这一问题，SparkSQL提供了一套更为优雅和高效的解决方案：复杂数据类型（Struct, Array, Map）。这些类型允许我们将完整的JSON结构直接加载为表中的一列，并在此结构之上，使用扩展的SQL语法进行精确的查询和操作。这意味着，无需预先进行繁琐的扁平化处理，我们就能直接访问嵌套字段、遍历数组元素或映射键值对，从而极大地简化了代码逻辑，并提升了处理效率。
本文不仅教会你如何解析任意复杂结构的 JSON 数据，同时还会告诉你如何封装一个 JSON 数据。

一、复杂数据类型及其配套函数

在传统的关系型数据库与SQL中，数据模型通常被约束在“第一范式”之内，即所有数据都是原子性的，表中的每一列都是不可再分的基本数据类型。然而，现实世界中的数据，尤其是来自现代应用日志、API接口和传感器数据的JSON格式，往往是多层嵌套、结构复杂的。
为了在保持SQL关系模型强大查询能力的同时，原生地处理这种半结构化数据，SparkSQL引入了三种核心的复杂数据类型：STRUCT、ARRAY和MAP。这三种类型允许我们将一个具有内部结构的数据块，作为表中的一列来处理，从而在数据建模和查询上提供了极大的灵活性。

1.1 数据类型

别再让 Excel 毁了你下班前的灵感

Wed, 03 Sep 2025 10:05:06 GMT

写给所有把数据仓库当“一次加工”，把本地电脑当“二次战场”的数据人

先来三个灵魂拷问

你上一次把 ADS 表导出 Excel 做探查，是不是卡到风扇起飞?
你上一次 vlookup 三张百万行 CSV，是不是蓝屏死机?
你上一次把 Excel 粘给老板，是不是被问“能不能换个格式，我要透视”?

如果你都点头，那恭喜你——你已经在做“二次分析”了
而二次分析，正是DuckDB在今天依旧值得被数据人放进工具箱的最大理由。

一、闲谈

1.1 什么是二次分析

维度一次加工二次分析

位置数仓/Hadoop/Spark 本地电脑

产出

dwd/dws/ads

CoalescingMergeTree：列级合并，一行成景

Wed, 27 Aug 2025 09:10:06 GMT

CoalescingMergeTree 引擎通过追加写的方式，为 ClickHouse 带来了真正的列级更新能力。作为 MergeTree 家族的新成员，它能够在后台合并时，把稀疏的局部记录逐步聚合成完整行，非常适合以下场景：

需要高效保留每个实体的最完整版本
可接受后台合并时才落盘整合的延迟
只想填补缺失字段，而非像 ReplacingMergeTree 那样整行覆盖

CoalescingMergeTree 首发于 25.6 版本，25.7.2.54 已具备完整更新能力。详情查看issue #84116

一、实现原理

1.1 八股文版

与其它 MergeTree 引擎一样，需要先通过 ORDER BY 声明排序键（主键）。CoalescingMergeTree 会把相同排序键的多条记录做合并，规则：每列保留最新的非 NULL 值，最终在磁盘上得到一行“完整”数据。

其中 1- 4 为数据 insert 过程，对于同一个 vin 每次插入局部数据

初始化 vin

可刷新物化视图

Mon, 07 Jul 2025 08:45:06 GMT

可刷新物化视图 (refreshable materialized view) 是 ClickHouse 一种新的物化视图解决方案，并在24.10版本中标记为生产可用。主要用于解决增量物化视图不适用的场景。

一、增量物化视图

增量物化视图是 ClickHouse 中常见的物化视图。下面我们来介绍它的更新时机以及不适用的场景，以引出可刷新物化视图推出的背景。

1.更新时机

从本质上说，增量物化视图是主表insert事件的触发器。当主表有数据插入时，会将本次插入的数据应用物化视图的建表 SQL，并写入物化视图或其 to 表（后面全部用 to 表解释）。

上述是单表增量物化视图更新时机极其数据扭转。

对于多表 join 的增量物化视图，其更新时机略有区别。也正是因为其独特的机制，导致增量物化视图无法应用于所有多表场景。下面构建一个多表 join 的增量物化视图场景：

-- 数据源表 1
create table tbl1(  


辛普森悖论的量化根因
Sat, 28 Jun 2025 14:57:45 GMT
辛普森悖论（simpson’s paradox），是概率和统计中的一种现象，其中趋势出现在几组数据中，但当这些组被合并后趋势消失或反转。这个结果在社会科学和医学科学统计中经常遇到，当频率数据被不恰当地给出因果解释时尤其成问题。当干扰变量和因果关系在统计建模中得到适当处理时，这个悖论就可以得到解决。 辛普森悖论已被用来说明统计误用可能产生的误导性结果。

关于辛普森悖论的论述推荐知乎上两篇高赞回复

关于辛普森悖论的深度解析
真实的谎言——辛普森悖论面面观

而本文的主题是当博主在工作中遇到辛普森悖论时如何去量化根因(打脸业务我的数据没有出问题)


基于 metabase + clickhouse 的流量分析
Sun, 08 Jun 2025 06:41:17 GMT
一、背景
博客的访问统计是基于51la实现，其只会统计“真人”的访问记录会过滤掉绝大部分的全站流量，因此如果想要分析全站的流量是否存在异常则需要更底层的实现。博客的基础架构是 nginx + hexo 的静态博客页面，因此全站流量分析的思路是：

采集 nginx 的访问日志
同步到分析性数据库
搭建实时报表

结合博主的技术栈，设计出如下架构

二、框架解析
本节解释为什么要选择 vector + clickhouse + metabase
2.1 vector
vector 是一个轻量级、超快用于构建可观测数据管道的工具，这里用作日志采集的 ETL工具。相较于 flume 或 filebeat + logstash 有以下优点

使用 rust 编写，无 gc 运行效率极高且部署简单无需额外的环境（flume 或 ELK 都需要 jre）
vector 支持 44 种 source、15 种 transform 和 59 种 sink

同时要考虑实际情况，博主公网服务器的配置仅为 2c4g，vector


TTL——管理 clickhouse 数据的生命周期
Fri, 30 May 2025 10:45:06 GMT
随着时间的推移，clickhouse 中的数据逐步增长。为了查询、存储效率的提升我们可能需要计划性删除、移动或聚合历史数据。针对此类数据生命周期管理，clickhouse 提供了简单且强大的工具——TTL，该工具作用于 DDL 子句中。这篇文章将探索 TTL 以及如何使用它来解决多种数据管理任务。

TTL 只能应用在 MergeTree 系列引擎中

一、删除数据
在一些特殊的场景中，有时存储过期的数据是没有意义的，因此需要定期执行删除操作。而 clickhouse 只需要在 DDL 中配置 TTL 就可以在后台自动完成。同时对于删除操作又可以细分为删除整行或只删除指标列
1.1 删除整行
1. 普通删除
假设有一张event表，同时我们期望自动删除所有超过一个月的记录
create table events
(
    event String,
    time  DateTime,
    

ClickHouse 查询缓存
Fri, 30 May 2025 10:29:11 GMT
为了实现最佳性能，数据库需要优化其内部数据存储和处理管道的每一步。但是数据库执行的最好的工作是根本没有完成的工作！缓存是一种特别流行的技术，它通过存储早期计算的结果或远程数据来避免不必要的工作，而访问这些数据的成本往往很高。在今天的博文中，介绍一下 ClickHouse 缓存系列的最新成员——查询缓存，在 v23.1 版本中作为实验性特性。
一、缓存一致性问题
在实操 clickhouse 的查询缓存前需要先了解一下缓存事务问题，查询缓存通常可以分为事务一致和事务不一致。
在事务一致缓存中，如果 SELECT 查询的结果发生更改或可能发生更改，则数据库会使缓存的查询结果无效（丢弃）。在 ClickHouse 中，更改数据的操作包括在表中插入/更新/删除或折叠合并。事务一致性缓存特别适合 OLTP 数据库，例如MySQL（在v8.0之后删除了查询缓存）和 Oracle。
在事务不一致缓存中，所有缓存条目都被分配了一个有效期，之后它们就会过期，并且基础数据在此期间仅发生很小的变化，那么查询结果中的轻微不准确是可以接受的，这种方法总体上更适合 OLAP 数据库。在一些应用场景中数据的变化假如很慢，数据库就只需要计算一次报告（由第一个 SELECT 查询表示）。可以直接从查询缓存提供进一步的查询。

事务上不一致的缓存通常是由与数据库交互的客户端工具或代理包提供的

二、查询缓存实操
2.1 前期准备
这里使用 clickhouse 官方提供的 Anonymized Web Analytics Data，

Clickhouse 的 Kafka 表引擎
Sat, 01 Mar 2025 03:50:29 GMT
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 LST 版本中官方引入新的 Kafka 引擎这为直接实现 exactly once 语义提供了可能。
We also have a new experimental Kafka engine. 
This version makes it possible to have exactly-once processing of messages from Kafka.


本文则从零开始讲述 ClickHouse 如何与 Kafka 进行深度融合，如何在生产中优雅地使用 Kafka 表引擎同时介绍新的 Kafka 表引擎是如何实现 exactly once


SparkSQL优化的行列转换
Sat, 08 Feb 2025 06:41:17 GMT
行列转换是数据处理与分析中的关键操作，它能够将数据的结构从行转为列，或从列转为行。这种转换不仅简化了复杂的数据展示，还提升了数据分析的效率。在业务场景中，行列转换常用于报表生成、数据透视和多维度数据分析，通过更直观的方式呈现数据，帮助管理者快速获取关键信息。此外，它还能有效减少数据冗余，优化查询性能，满足灵活多变的业务需求。无论是在财务报表、销售分析，还是市场趋势分析中，行列转换都是不可或缺的工具。
本文会基于 SparkSQL 3.5.x 给出常用的行列转换方式，但本文的重点是介绍pivot和unpivot子句在行列转换场景的应用，其中细节、优雅程度交由开发者自己选择
一、数据准备
以下是城市各年GDP 数据的表结构和测试数据，用于后续演示行列转换
create table city_gdp
(
    city string comment '城市名',
    year int comment '年份',
    gdp  double comment 

Bitmap 在数仓中的应用
Sun, 15 Dec 2024 08:03:59 GMT
一、背景
在数据仓库的日常工作中，我们经常需要面对海量数据的存储和高效查询问题。尤其是，当业务对性能的要求越来越高、数据量持续增长时，传统的处理方式往往显得笨拙而低效。而这时候，Bitmap（位图）作为一种“看似简单却威力强大”的数据结构，逐渐展现出它的价值。简单来说，Bitmap 就像是一种用“0”和“1”记录信息的小工具。它通过位的形式将数据高效地压缩存储，同时支持快速的集合运算，比如并集、交集、补集等。这些特性使得 Bitmap 在高基数去重、行为统计、快速筛选等场景中表现得尤为出色。比如，给定一个数千万级别的用户群，使用 Bitmap 技术可以在几毫秒内完成某些复杂的查询操作，这在传统方法中可能需要数十秒甚至更长时间。 Bitmap 在数据仓库中的应用非常广泛。无论是帮助优化指标计算，还是提升查询性能，它都能够为开发者解决很多头疼的问题。例如，在广告投放场景下，我们需要实时统计某一人群的曝光次数；在用户运营中，我们可能需要高效筛选出符合特定标签的用户群。这些看似复杂的任务，通过 Bitmap，往往能以优雅的方式轻松解决。 这篇文章希望以实际案例为切入点，结合 Bitmap 的原理，聊一聊它在数据仓库中的应用场景和实现方式，帮助大家更好地理解和使用这一实用工具。
二、Bitmap 原理
2.1 基础构成
Bitmap 是一个连续的位数组，数组的每个位置对应一个无符号整数。例如需要存储 1、2、4、5 元素，只需要将这个数组的第 1、2、4、5 位设置为 1 其余位保持为 0 即可，即为011011


醉意下的真实——十年软件工程师的深夜独白
Fri, 15 Nov 2024 10:57:45 GMT
作为一个在工程领域摸爬滚打十年的工程师，我今晚可能在酒精的作用下，毫无顾忌地分享一些心得体会。以下是我酒后吐真言。

我在职业发展上取得的最大进步，是通过跳槽实现的。
技术栈并不是真的那么重要，因为在我所在的领域，大约有15种基本的软件工程模式是适用的。我从事的是数据领域的工作，它与网页开发或嵌入式开发不同。但所有领域都有大约10到20个核心原则，而技术栈只是试图让这些原则更容易实现，所以不必为此烦恼。
人们推崇寻找新工作是有其道理的。如果我对当前的工作感到不满意，那很可能是时候向前看了。
在我曾经工作过的公司里，我结交了一些好朋友，他们将会是我一生的挚友。我并不要求我工作过的每一个地方都必须建立这样的友谊。在那些没有与同事建立友谊的地方，我也能非常快乐地工作；同样地，即使在那些我交到了好朋友的地方，有时我也可能感到不快乐。
我学会了对上司坦诚，既保持真诚，又不至于过于直白，这样在工作中我能够保持自我。最糟糕的情况是什么？被解雇？那也无妨，我相信不久便能找到新的工作机会。
如果我一个季度内因为值班被在凌晨两点钟叫醒超过一次，那么肯定是出了严重的问题，我要么会解决它，要么就会辞职。
再倒一杯。
一个优秀的管理者与一个杰出的工程师之间，有许多共通的品质。
当我刚开始的时候，我对技术和编程以及计算机科学非常着迷。我现在已经不再那么狂热了。
好的代码是初级工程师能够理解的。伟大的代码是计算机科学专业的大一新生都能理解的。而最好的代码是根本不需要写代码。
作为工程师，编写文档的能力常被低估。真的，如果有人能教我如何编写出色的文档，我非常愿意为此付费参加培训课程。如果能保证我能够写出高质量的文档，我愿意支付高达1000美元的费用。
与上述相关的，写出优秀的变更提案也是一个非常重要的技能。
几乎所有的技术“圣战”（比如Vim与Emacs，Mac与Linux等）其实都是无关紧要的……但有一个例外，详情见下文。
随着年龄的增长，我越来越欣赏动态语言了。该死，我说出来了。来打我啊。
如果我发现自己认为我是团队


ClickHouse 多种删除操作
Wed, 09 Oct 2024 04:45:06 GMT
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
) engine 

三年 Sparker 都不一定知道的算子内幕
Tue, 17 Sep 2024 08:03:59 GMT
一、如何在 mapPartitions 中释放资源
mapPartitions是一种对每个分区进行操作的转换操作，于常用的map操作类似，但它处理的是整个分区而不是单个元素。mapPartitions的应用场景适合处理需要在每个分区内批量处理数据的场景，通常用于优化性能和减少计算开销。例如：减少数据库连接、网络连接等。即然涉及到资源的初始化那么必定伴随着资源的释放，这是本节讨论的重点。
以和 mysql 中数据交互为例，下面是一段伪代码
rdd.mapPartitions(iter => {
  // 初始化数据库连接
  lazy val connection = initConnection(args)
  // 迭代数据
  val result = iter.map(... /*处理逻辑会使用到 connection 对象*/)
  //


因精度丢失导致的 join 数据异常
Mon, 19 Aug 2024 00:45:06 GMT
一、问题复现
不知你是否遇到过 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


ClickHouse 查询缓存
Mon, 01 Apr 2024 04:45:06 GMT
为了实现最佳性能，数据库需要优化其内部数据存储和处理管道的每一步。但是数据库执行的最好的工作是根本没有完成的工作！缓存是一种特别流行的技术，它通过存储早期计算的结果或远程数据来避免不必要的工作，而访问这些数据的成本往往很高。在今天的博文中，介绍一下 ClickHouse 缓存系列的最新成员——查询缓存，在v23.1版本中作为实验性特性。
一、缓存一致性问题
在实操 clickhouse 的查询缓存前需要先了解一下缓存事务问题，查询缓存通常可以分为事务一致和事务不一致。
在事务一致缓存中，如果 SELECT 查询的结果发生更改或可能发生更改，则数据库会使缓存的查询结果无效（丢弃）。在 ClickHouse 中，更改数据的操作包括在表中插入/更新/删除或折叠合并。事务一致性缓存特别适合 OLTP 数据库，例如 MySQL（在v8.0之后删除了查询缓存）和 Oracle。
在事务不一致缓存中，所有缓存条目都被分配了一个有效期，之后它们就会过期，并且基础数据在此期间仅发生很小的变化，那么查询结果中的轻微不准确是可以接受的，这种方法总体上更适合 OLAP 数据库。在一些应用场景中数据的变化假如很慢，数据库就只需要计算一次报告（由第一个 SELECT 查询表示）。可以直接从查询缓存提供进一步的查询。

事务上不一致的缓存通常是由与数据库交互的客户端工具或代理包提供的

二、查询缓存实操
2.1 前期准备
这里使用 clickhouse 官方提供的 Anonymized Web Analytics Data，

开源大数据驿站

GLM-4.5 & Dify：零成本构建 PostAI

一、设计思路

JSON数据处理新思路：深入SparkSQL复杂类型

一、复杂数据类型及其配套函数

1.1 数据类型

别再让 Excel 毁了你下班前的灵感

一、闲谈

1.1 什么是二次分析

CoalescingMergeTree：列级合并，一行成景

一、实现原理

1.1 八股文版

可刷新物化视图

一、增量物化视图

1.更新时机

辛普森悖论的量化根因

基于 metabase + clickhouse 的流量分析

一、背景

二、框架解析

2.1 vector

TTL——管理 clickhouse 数据的生命周期

一、删除数据

1.1 删除整行

1. 普通删除

ClickHouse 查询缓存

一、缓存一致性问题

二、查询缓存实操

2.1 前期准备

Clickhouse 的 Kafka 表引擎

SparkSQL优化的行列转换

一、数据准备

Bitmap 在数仓中的应用

一、背景

二、Bitmap 原理

2.1 基础构成

醉意下的真实——十年软件工程师的深夜独白

ClickHouse 多种删除操作

一、mutation

1.1 实操

三年 Sparker 都不一定知道的算子内幕

一、如何在 mapPartitions 中释放资源

因精度丢失导致的 join 数据异常

一、问题复现

ClickHouse 查询缓存

一、缓存一致性问题

二、查询缓存实操

2.1 前期准备