ClickHouse 和 Apache Superset 可以组成一套透明的用户行为分析基础设施：前者保存事件明细并执行聚合查询，后者连接数据库、管理数据集并制作图表与仪表盘。两者之间的指标逻辑由 SQL 明确定义，适合具备数据建模与运维能力的团队。
ClickHouse + Superset 如何用于用户行为分析？
事件接收服务把页面、App 或服务端行为写入 ClickHouse；数据团队使用 SQL 清洗、聚合并定义指标；Apache Superset 将查询封装为数据集、图表和仪表盘。该方案的核心优势是原始事件和指标逻辑可检查，限制是团队需要自行负责模型、权限、性能与运维。
四个组件分别负责什么？
| 组件 | 职责 | 不应该承担 |
|---|---|---|
| SDK / 业务服务 | 记录事件、身份、属性与发生时间 | 直接连接数据库 |
| 接收服务 | 鉴权、解析、校验、限流、错误记录 | 把所有业务逻辑写进采集层 |
| ClickHouse | 存储明细、执行过滤与聚合查询 | 替代事件治理和业务定义 |
| Superset | SQL 探索、数据集、图表、仪表盘与权限 | 自动理解所有产品分析语义 |
为什么选择 ClickHouse 存储事件？
ClickHouse 官方将其定位为面向在线分析处理的列式数据库。事件数据通常具有持续写入、按时间和维度过滤、对大量记录聚合等特点，与列式分析场景匹配。
但“适合分析”不等于无需设计。分区、排序键、基数、物化视图、数据保留和查询并发都会影响实际表现。任何容量或性能结论都应由团队使用真实事件大小、峰值写入和查询模式压测验证。
Superset 能做哪些用户行为分析？
Superset 官方提供数据库连接、SQL Lab、数据集、图表和仪表盘等能力。只要 ClickHouse 中的数据模型和 SQL 定义清晰，就可以制作事件趋势、独立用户、注册转化、活跃度和留存等看板。
| 分析问题 | 基础数据 | 适合的展示 |
|---|---|---|
| 每天发生多少关键事件？ | 事件名、发生日期 | 时间序列 |
| 有多少独立用户触发事件？ | 用户标识、事件名 | 指标卡与趋势 |
| 注册流程在哪一步流失？ | 用户、步骤事件、时间 | 漏斗或分步转化表 |
| 不同渠道带来什么用户？ | 来源属性、身份、事件 | 分组柱状图或透视表 |
| 用户是否持续回来？ | 首次行为与回访日期 | 留存矩阵 |
从测试事件开始的实施流程
1. 定义最小事件模型
至少包含稳定事件名、匿名或登录用户标识、属性、客户端发生时间、服务端接收时间和环境字段。测试与生产必须可以明确区分。
2. 建立隔离环境
先部署测试 ClickHouse、Redis、接收服务和 Superset。使用独立账号与密钥，禁止把演示密码或默认配置直接用于生产。
3. 发送可识别事件
发送 integration_test，附加平台、环境、测试用户和版本。这样可以快速在日志、数据库与 BI 中定位同一条链路。
4. 运行最小校验 SQL
SELECT
event,
count() AS event_count
FROM sensors.event
WHERE environment = 'test'
GROUP BY event
ORDER BY event_count DESC;表名和字段仅为 SensorFlow 示例，必须以实际版本为准。生产查询需要结合分区、排序键、时间范围和权限进行设计。
5. 在 Superset 建立数据集
先使用 SQL Lab 验证查询，再保存为数据集。指标名称、过滤条件、时区与去重规则应写入说明，避免同一个“活跃用户”在不同看板中出现不同定义。
6. 从最小看板扩展
第一版只放事件量、独立用户、注册、登录和关键转化。确认数据稳定后，再加入留存、路径和业务维度，避免一次性构建大量无人使用的报表。
上线前检查表
| 类别 | 必须验证 |
|---|---|
| 数据 | 身份关联、属性类型、时区、迟到事件、重复与非法事件 |
| 性能 | 峰值写入、典型查询、并发、保留周期与磁盘增长 |
| 可靠性 | 接收重试、错误记录、服务重启、备份与恢复演练 |
| 安全 | TLS、数据库网络隔离、最小权限、密钥管理和审计 |
| 治理 | 事件字典、负责人、变更流程、测试环境隔离 |
| BI | 指标定义、过滤器、时区、缓存和看板权限 |
哪些团队适合这套方案？
数据工程团队
需要访问事件明细、用 SQL 构建指标并与其他业务表关联时，透明数据库比封闭报表更灵活。
重视数据驻留的组织
自托管让团队控制存储位置、访问权限与保留策略，但同时承担安全、合规、备份和升级责任。
已有 BI 工作流的公司
如果团队已经用 Superset 或其他 SQL BI，事件数据进入 ClickHouse 后可以复用现有权限、指标和看板流程。
什么时候不适合？
如果主要用户不会 SQL，且需要开箱即用的会话回放、无代码漏斗、实验、Feature Flags 或运营自动化，完整产品分析平台通常更省时间。ClickHouse + Superset 提供基础设施与 BI，不会自动补齐所有产品分析工作流。
如果只需要页面访问、来源和基础网站报表，也可以优先评估更轻量的网站分析工具，避免承担不必要的数据平台运维。
与 SensorFlow 的关系
SensorFlow 把这套架构封装为一条可部署的事件链路：兼容事件上报进入 Go 服务，写入 ClickHouse，再通过 Superset 查询和展示。它适合把“能否接收、数据是否正确、SQL 如何验证”放在首位的工程团队。
已有神策 SDK 的项目可以参考神策 SDK 到 ClickHouse 迁移指南；仍在比较工具时，可查看SensorFlow、PostHog 与 Matomo 对比。
官方资料
- ClickHouse 官方文档：数据库、引擎、SQL 与运维依据。
- Apache Superset 官方文档：数据库连接、SQL Lab、图表与仪表盘。
- Redis 官方文档：队列与缓存组件配置依据。
- Go 官方文档：接收服务工具链。
- SensorFlow GitHub 仓库：开源部署实现。
- SensorFlow 部署文档：站内安装与验证步骤。
常见问题
ClickHouse 为什么适合存储埋点事件？
它是面向在线分析的列式数据库，适合大量事件的过滤与聚合。实际效果取决于模型、数据量、查询和运维，必须压测。
Superset 能直接做漏斗和留存吗？
可以基于 SQL 数据集制作对应结果和图表，但模型逻辑通常需要团队自行定义，不等同于专用产品分析平台的一键功能。
Redis 是必需的吗？
取决于具体接收架构。SensorFlow 使用它支撑接收流程；其他实现可以选择不同队列或缓冲组件，不能一概而论。
可以让 SDK 直接写 ClickHouse 吗？
不建议。接收服务应负责鉴权、协议解析、校验、限流和错误处理，数据库不应直接暴露给客户端。
如何保证看板指标一致？
统一事件字典与 SQL 定义，明确身份、时区、去重和过滤规则，并为数据集与指标指定负责人和变更流程。