PostAI 是博客网站与 AI 结合的产物，为网站提供智能客服与搜索增强功能，同时对于首次访问网站的用户可以依靠 PostAI 快速了解网站主题与热门文章。因此 PostAI 的角色是： 智能客服 智能搜索 智能摘要 如果您是在主站中刷到这篇文章，任意地方鼠标右键点击「智能管家」即可体验，其它渠道可以先访问：https://blog.kpretty.tech/ 一、设计思路围绕「客服」、「搜索」和「摘要」容易想到的是 AI + 知识库，将博客与文章相关的数据定时同步到知识库。例如：dify 与扣子的知识库都提供基于 sitemap 的抓取工具，但是因为知识库依赖召回策略，当用户想要了解指定文章内容时是期望将整篇文章内容都返回给 AI，而知识库往往只能返回片段或者召回到其它片段。总体来说知识库在内容完整性与时效性不能很好的适配 PostAI 场景 知识库也可以不切分，但整体来说比较黑盒不自由。同时知识库也需要定期维护成本过高 一种轻量级的设计思路便是：假如可以提供博客元数据查询工具以及指定文章链接获取文章内容工具，当用户咨询 AI 关于博客的相关问题时首先调用元数据查询工 ...
在实际的数据处理工作中，处理多层嵌套、结构不规则的JSON数据，是一个常见的挑战。传统方法通常依赖一系列字符串解析函数（如get_json_object）与行展开操作（explode）。这种方式不仅导致SQL语句冗长复杂，难以维护，而且在处理深层嵌套或复杂数组时，性能开销显著，逻辑也容易出错。面对这一问题，SparkSQL提供了一套更为优雅和高效的解决方案：复杂数据类型（Struct, Array, Map）。这些类型允许我们将完整的JSON结构直接加载为表中的一列，并在此结构之上，使用扩展的SQL语法进行精确的查询和操作。这意味着，无需预先进行繁琐的扁平化处理，我们就能直接访问嵌套字段、遍历数组元素或映射键值对，从而极大地简化了代码逻辑，并提升了处理效率。本文不仅教会你如何解析任意复杂结构的 JSON 数据，同时还会告诉你如何封装一个 JSON 数据。 一、复杂数据类型及其配套函数在传统的关系型数据库与SQL中，数据模型通常被约束在“第一范式”之内，即所有数据都是原子性的，表中的每一列都是不可再分的基本数据类型。然而，现实世界中的数据，尤其是来自现代应用日志、API接口和传感器数据的 ...
写给所有把数据仓库当“一次加工”，把本地电脑当“二次战场”的数据人 先来三个灵魂拷问 你上一次把 ADS 表导出 Excel 做探查，是不是卡到风扇起飞? 你上一次 vlookup 三张百万行 CSV，是不是蓝屏死机? 你上一次把 Excel 粘给老板，是不是被问“能不能换个格式，我要透视”? 如果你都点头，那恭喜你——你已经在做“二次分析”了而二次分析，正是DuckDB在今天依旧值得被数据人放进工具箱的最大理由。 一、闲谈1.1 什么是二次分析 维度 一次加工 二次分析 位置 数仓/Hadoop/Spark 本地电脑 产出 dwd/dws/ads 表 业务问题的答案 工具 hive/spark/flink等 excel/python/r 量级 TB级 GB及以下 目标 口径对齐与沉淀 灵活探查与试错 一句话总结：数仓把数据做对，DuckDB把数据做活 1.2 为什么能赢 Excel 维度 Excel 2021 DuckDB 1.3 单文件上限 1,048,5 ...
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 的电池电量和防火墙信息 更新 GPS 数据（本质上是插入追加操作） 更新速度和温度数据 更新电池电量其中的 5 - 6 ...
可刷新物化视图 (refreshable materialized view) 是 ClickHouse 一种新的物化视图解决方案，并在24.10版本中标记为生产可用。主要用于解决增量物化视图不适用的场景。 一、增量物化视图增量物化视图是 ClickHouse 中常见的物化视图。下面我们来介绍它的更新时机以及不适用的场景，以引出可刷新物化视图推出的背景。 1.更新时机从本质上说，增量物化视图是主表insert事件的触发器。当主表有数据插入时，会将本次插入的数据应用物化视图的建表 SQL，并写入物化视图或其 to 表（后面全部用 to 表解释）。上述是单表增量物化视图更新时机极其数据扭转。 对于多表 join 的增量物化视图，其更新时机略有区别。也正是因为其独特的机制，导致增量物化视图无法应用于所有多表场景。下面构建一个多表 join 的增量物化视图场景： -- 数据源表 1create table tbl1( id Int8 )engine = MergeTree order by id; -- 数据源 2create table tbl2( id Int8 ...
辛普森悖论（simpson’s paradox），是概率和统计中的一种现象，其中趋势出现在几组数据中，但当这些组被合并后趋势消失或反转。这个结果在社会科学和医学科学统计中经常遇到，当频率数据被不恰当地给出因果解释时尤其成问题。当干扰变量和因果关系在统计建模中得到适当处理时，这个悖论就可以得到解决。 辛普森悖论已被用来说明统计误用可能产生的误导性结果。 关于辛普森悖论的论述推荐知乎上两篇高赞回复 关于辛普森悖论的深度解析 真实的谎言——辛普森悖论面面观 而本文的主题是当博主在工作中遇到辛普森悖论时如何去量化根因(打脸业务我的数据没有出问题) 一、背景在ToC产品领域，用户粘性体现了用户反复与产品交互的倾向，粘性越高的产品对用户而言越重要，更能吸引用户定期使用并提升忠诚度。粘性的计算通常与日活跃用户数（DAU）和月活跃用户数（MAU）密切相关。博主所在的国内知名软件数据团队，曾遇到这样的业务反馈：首页的粘性指标呈现持续增长态势，然而深入查看各子页面的粘性却无一例外地出现下降。这不禁引发疑问，数据是否出现了问题？ 在自行检查计算逻辑无误后，又从底层数据表对指标进行了复核，进一步确认数据 ...
一、背景博客的访问统计是基于51la实现，其只会统计“真人”的访问记录会过滤掉绝大部分的全站流量，因此如果想要分析全站的流量是否存在异常则需要更底层的实现。博客的基础架构是 nginx + hexo 的静态博客页面，因此全站流量分析的思路是： 采集 nginx 的访问日志 同步到分析性数据库 搭建实时报表 结合博主的技术栈，设计出如下架构 二、框架解析本节解释为什么要选择 vector + clickhouse + metabase 2.1 vectorvector 是一个轻量级、超快用于构建可观测数据管道的工具，这里用作日志采集的 ETL工具。相较于 flume 或 filebeat + logstash 有以下优点 使用 rust 编写，无 gc 运行效率极高且部署简单无需额外的环境（flume 或 ELK 都需要 jre） vector 支持 44 种 source、15 种 transform 和 59 种 sink 同时要考虑实际情况，博主公网服务器的配置仅为 2c4g，vector 是一个性价比极高的选择 2.2 clickhouse市面上流量的 AP 数据库大概 ...
随着时间的推移，clickhouse 中的数据逐步增长。为了查询、存储效率的提升我们可能需要计划性删除、移动或聚合历史数据。针对此类数据生命周期管理，clickhouse 提供了简单且强大的工具——TTL，该工具作用于 DDL 子句中。这篇文章将探索 TTL 以及如何使用它来解决多种数据管理任务。 TTL 只能应用在 MergeTree 系列引擎中 一、删除数据在一些特殊的场景中，有时存储过期的数据是没有意义的，因此需要定期执行删除操作。而 clickhouse 只需要在 DDL 中配置 TTL 就可以在后台自动完成。同时对于删除操作又可以细分为删除整行或只删除指标列 1.1 删除整行1. 普通删除假设有一张event表，同时我们期望自动删除所有超过一个月的记录 create table events( event String, time DateTime, value UInt64) engine = MergeTree order by (event, time) ttl time + interval 1 month; ...
为了实现最佳性能，数据库需要优化其内部数据存储和处理管道的每一步。但是数据库执行的最好的工作是根本没有完成的工作！缓存是一种特别流行的技术，它通过存储早期计算的结果或远程数据来避免不必要的工作，而访问这些数据的成本往往很高。在今天的博文中，介绍一下 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 ...
