自托管事件分析系统的设计与实现：采集服务 + ClickHouse + Superset

分享一个开源项目的架构实践：自托管的用户行为分析系统。整体链路为 SDK 上报 → Go 采集服务 → ClickHouse → SQL/Superset 分析。Docker 安装脚本先启动演示，激活后启用真实采集。

项目地址：https://github.com/data-analyze-bi/sensorflow
许可证：Apache-2.0

一、设计目标

1. 数据完全自持：事件从采集到存储都在自己的服务器上
2. 查询透明：指标用 SQL 定义，可审查、可版本管理
3. 迁移成本低：采集协议兼容神策 SDK，已验证兼容的上报场景可减少埋点重写

二、采集服务

埋点上报是典型的高并发小请求场景。Go 实现的采集服务职责很薄：

• 接收 SDK 的事件批量上报（HTTP）
• 基础校验：SDK 上报格式、身份与时间字段
• 按时间窗口攒批，批量写入 ClickHouse

不做重业务逻辑，保持无状态，方便水平扩展。批量写入是关键——ClickHouse 不适合逐条插入，攒批后写入吞吐和压缩率都好得多。

协议兼容的设计值得一说：很多团队的埋点代码散落在各端，发版成本高。迁移前应核对 SDK 版本、加密、身份、属性类型和时间戳；兼容场景可复用已有埋点，再切换上报地址。

三、ClickHouse 表设计

事件分析的核心是漏斗和留存，本质是按用户 + 时间窗口的聚合查询。

-- 示例：同一用户在注册后 24 小时内下单的转化
SELECT countIf(level >= 2) / nullIf(countIf(level >= 1), 0) AS funnel_rate
FROM (
    SELECT distinct_id,
           windowFunnel(86400)(time, event = 'register', event = 'order') AS level
    FROM sensors.event
    WHERE time >= '2026-09-01' AND time < '2026-09-29'
      AND event IN ('register', 'order')
    GROUP BY distinct_id
)

设计要点：

• 排序键 (distinct_id, event, time)：与当前公开初始化表一致，并配合事件、时间跳数索引
• 分区：按月分区，配合 TTL 做数据生命周期管理
• 预聚合：高频的日报类指标用物化视图，避免每次全量扫描

四、分析层

Superset 作为 BI 层，可用图表呈现事件指标，权限和分享机制成熟。定制需求直接写 SQL 查 ClickHouse。

自研 BI 看板投入产出比太低，能复用就不重复造轮子。

五、部署

./install.sh
# 取得许可证后启用真实 SDK 采集
./activate.sh

安装脚本先启动 ClickHouse 与 Superset 演示；激活许可证后再启动真实采集服务。无需 K8s，单机可跑，生产环境按需拆分。

六、在线演示

Superset 看板 demo：https://superset.sensorflow.site

欢迎技术交流，Issue 和 PR 都在 GitHub 上。