“事件驱动的数据采集 + 本地部署的分析系统 + 全栈可观测能力”
下面是对 PostHog 工作原理的详细拆解,从 架构层次 到 数据流转流程,并涵盖其核心模块。
🧱 架构总览
PostHog 通常由以下几个关键组件构成:
用户前端 → PostHog JS SDK / API → Ingestion Pipeline → Kafka(事件队列)
↓
PostgreSQL / ClickHouse(事件存储)
↓
后端处理服务 + 插件系统 + 分析引擎
↓
Web UI / API 输出结果
🔄 数据采集流程(事件驱动)
- 事件采集
• 前端页面通过 posthog.js
SDK 或移动端 SDK 自动采集:
• 点击事件、表单提交、页面访问、滚动等
• 或手动埋点调用 posthog.capture('event_name', properties)
• 服务端也可以通过 API 发送自定义事件(如注册成功、订单支付等)
- 数据上报
• 所有事件被统一发送到 PostHog 的 事件摄取服务(Ingestion Service)
• 摄取服务做基础清洗和格式规范后,将事件写入 Kafka 或直接传送到 ClickHouse
💾 数据存储与处理
- 事件入库
• 默认使用 ClickHouse 存储事件数据(高性能列式数据库)
• 用户信息、元数据等保存在 PostgreSQL 中
- 处理与插件
•插件系统可以在事件流转过程中执行任意逻辑:
• 增强属性(如 IP 转换为城市)
• 发送 webhook
• 写入外部系统(如 S3、BigQuery)
- 分析与建模
•后端使用 ClickHouse 的 SQL 引擎进行:
• 漏斗分析
• 路径分析
• 用户分群
• 转化率计算
• 实验组/对照组差异分析
📊 前端可视化与查询
- 展示结果
• PostHog 的 Web UI 是基于 React 构建的前端仪表盘
• 所有数据支持:
• 图表展示(折线图、饼图、漏斗图等)
• 动态筛选
• 下载导出或 API 访问
- Session Replay(会话回放)
•SDK 会自动记录用户 DOM 操作行为,存储成压缩帧数据
• 后端解码回放 DOM 和鼠标轨迹,实现完整操作还原
🧠 关键原理总结
原理 | 说明 |
---|---|
事件驱动架构 | 一切以用户事件为基本单位采集和分析 |
ClickHouse 存储引擎 | 高并发、高吞吐、支持复杂分析 |
Kafka 消息流(可选) | 提高系统解耦与扩展性 |
插件处理链 | 类似中间件机制,可拦截或增强事件流 |
自托管架构 | 用户控制所有数据,符合 GDPR/合规要求 |
Session Replay 编码 | 使用 DOM diff + 滚动轨迹压缩算法 |
🧩 模块级别图(简化)
[PostHog SDKs]
↓
[Ingestion Service] --→ [Plugin System] → [ClickHouse]
↓
[Analysis Engine]
↓
[Web UI / API]