SensorFlow 与 ClkLog：2026 年自托管埋点方案怎么选？

如果你已经用神策 SDK 埋点，又想把数据留在自有服务器，ClkLog 和 SensorFlow 都值得检查。但两者不能只按“开源、私有化、ClickHouse”几个标签判断：ClkLog 更接近带有业务分析界面的完整产品；SensorFlow 更聚焦于接收兼容 SDK 事件、写入 ClickHouse，再用 SQL 和 Superset 分析。

先给结论：希望产品与运营人员打开系统就看访问、事件和用户分析，应优先测试 ClkLog，并核对社区版与商业版功能边界。希望保留现有 SDK、把原始事件直接放进自己的 ClickHouse、由数据团队定义 SQL 指标，可以测试 SensorFlow。两者都需要真实 SDK 样本验证，不能靠功能表推断兼容率。

本文根据双方截至 2026 年 9 月的公开仓库与文档整理；没有进行并排压测、安装耗时测量或生产兼容性认证。

两条链路到底差在哪里？

ClkLog 官方仓库展示的架构为 SDK → Receiver → Kafka → Processing → ClickHouse / Doris → API 与管理后台 → 可视化。其源码部署文档明确写到，接收服务可以接收神策 SDK 采集的日志并写入 Kafka，再由处理链路导向分析存储。这意味着不能简单宣传“只有 SensorFlow 能保留神策 SDK”：ClkLog 也有相关接收路径，具体版本与格式都需要实测。

SensorFlow 仓库公开的主路径是兼容神策 SDK 流量 → Go 接收服务 → ClickHouse → Apache Superset。部署有两阶段：先安装依赖服务、演示事件和 Superset 看板，再安装许可证启动真实 SDK 接收。第一阶段能看 Demo，不等于真实接收服务可免费直接启用。

选型维度	ClkLog	SensorFlow
产品重心	自带分析后台的用户行为分析系统	ClickHouse 原始事件链路与 SQL 分析
官方展示链路	Receiver、Kafka、Processing、ClickHouse/Doris、API/前端	Go 接收、ClickHouse、Superset
神策 SDK	源码部署文档有接收神策 SDK 日志的说明	以兼容标准上报作为主要迁移场景
业务使用方式	访问、事件、用户等产品界面；高级能力看版本	SQL 定义指标，Superset 构建看板
免费/商业边界	AGPL-3.0 社区版；更多能力按版本核对	演示环境可先运行；真实接收需许可证
更需要验证的事	社区版功能是否满足业务，以及 Kafka/处理链路运维	SDK 格式兼容、许可证与 SQL/运维工作量

表格是架构和产品边界的概括，不是性能排序。两边的版本与配置都会变化，部署前应直接阅读各自当前文档。

ClkLog 的优势不能略过

ClkLog 的公开资料列出了 Web、App、小程序等多端采集以及访问统计、访客分析、事件分析等能力。官方仓库还有 Docker 部署入口和社区版 Demo。对没有专职 SQL 分析人员的团队，已有业务界面往往比“原始数据都能查”更重要。

但也要看清版本。ClkLog 的 README 把社区版列为 AGPL-3.0，并把专业版、企业版、信创版区分开来；其产品预览将留存、自定义分析和漏斗放在更高版本的示例中。不能把整套商业版界面当成免费社区版承诺，也不能因为社区版没有某个可视化功能，就说底层事件不能做该分析。最稳妥的做法是对照官方功能清单并亲自进入对应版本 Demo。

AGPL 与 Apache-2.0 的义务不同；商业闭源集成场景尤其需要技术负责人和法务根据实际代码组合核对许可证，不要把这篇文章当作法律意见。

SensorFlow 的优势也有明确边界

SensorFlow 选择更直接的 ClickHouse 数据路径，适合已经有 SQL 工作流、希望从接收端灰度迁移的团队。原始事件落入自有 ClickHouse 后，开发者可以检查事件名、用户标识、时间字段和属性类型，再写出团队认可的指标口径。快速开始说明了先看演示环境、再激活真实埋点的步骤。

代价是更多工作留给使用者：Superset 不会自动变成 ClkLog 的产品分析后台。漏斗、留存、用户分群的 SQL、看板、权限、监控、备份和升级都要有人负责。SensorFlow 也不应被说成包含可视化全埋点或对所有神策 SDK 扩展插件完全兼容。

还有一个购买边界必须提前说清：开源仓库与演示阶段可供评估；真实 SDK 埋点接收需要从 SensorFlow 获取许可证并运行激活流程。只看 README 第一屏或 Demo 图表就计划生产迁移，会漏掉这一步。

建议如何做一次公平 PoC？

先固定业务问题，例如“注册页到注册成功的七日转化”。不要一边更换接收端，一边改事件定义。

1. 列出当前 SDK 版本、事件名、用户 ID 规则、加密插件、发送模式和失败重试机制。
2. 在两套独立测试环境发送同一组非敏感的标准事件，包括匿名、登录、跨天和重复请求样本。
3. 分别确认接收 HTTP 响应、消息处理状态和最终存储记录。返回成功不等于数据已经入库。
4. 按事件名和日期对账事件数；抽查属性类型、时区、身份关联。任何差异都要追到具体样本。
5. 让实际使用者完成同一个漏斗查询：在 ClkLog 确认该能力属于所评估的版本；在 SensorFlow 用 ClickHouse SQL 和 Superset 实现，并记录维护成本。
6. 测试数据库不可用、重启、备份恢复、Token 轮换和监控告警。最后再用自己的代表性负载测吞吐与查询延迟。

如果希望比较成本，应把软件许可证、服务器、Kafka/处理链路或 SQL 看板的运维、备份与升级一并计算。没有真实报价和代表性负载，就不写“谁便宜多少”或“谁快几倍”。

哪些团队应该先看哪一个？

先看 ClkLog：需要开箱可用的运营分析界面；重视产品内的访问和用户分析；愿意接受其社区版/商业版边界与相应架构。尤其当最终使用者不写 SQL 时，产品界面是真正的优势。

先看 SensorFlow：现有神策 SDK 埋点必须尽量保留；自有 ClickHouse 是硬要求；团队有数据工程和 SQL 能力；希望先验证接收端迁移，而非采购一套完整业务分析界面。

两者都不能只凭“兼容神策 SDK”四个字直接上生产。最好让实际 SDK 发送测试事件，直到 ClickHouse 中查到正确的行、核对身份和属性，再决定灰度范围。SensorFlow 与 ClkLog 是独立项目，彼此没有关联或背书。