SensorFlow 技术架构解析：Go + ClickHouse 的开源埋点管道

SensorFlow 的架构不能只看 Go → ClickHouse → Superset 三个名字。要判断是否适合运行真实埋点，还要看请求如何鉴权、载荷如何处理、Redis何时确认、事件何时落库以及失败由哪一层恢复。

当前主路径使用神策官方 SDK、Go 接收、Redis缓存、ClickHouse与Superset，真实接收依赖商业许可证激活。主架构图是理解方向的简图，不是无状态、零依赖或数据绝不丢失的保证。

本文由 SensorFlow 项目维护方整理，AI辅助修订；对照公开版本 2ff2275 阅读源码，没有把静态分析写成容量压测。

一、请求入口与许可边界

路由文件把事件接收组织在 /sensors/send/。当前控制器检查配置的接收 Token，再读取 data_list 或 data，调用外部许可证处理载荷后解析事件。

这意味着网络可达、Token匹配、许可证有效、协议可解析是不同验收项。不能用一条裸JSON的概念模型，承诺任何SDK都可以直接发送成功。

部署README也区分合成Demo与激活后的真实接收，公开代码的许可不能自动覆盖单独交付的商业组件。

二、Redis不是被省略的小细节

事件经过字段处理后，控制器用Redis记录事件名与序列化事件集合。写入任务从集合分批取出记录，随后写进sensors.event；失败有回填路径，控制器也包含Redis失败后的数据库写入分支。

因此“Go直写且没有缓存”不符合这个版本的实际代码。Redis集合的成员去重，也不能推广成按业务事件ID的全链路幂等保证；一批写入和多次请求之间仍需专门验收。

从取出到写入存在跨系统操作。源码中的失败处理说明作者考虑了错误路径，但不能单凭它证明进程在任意时刻中断都能恢复；应对缓存取出、数据库写失败和中断重启分别设计故障样本。

三、存储结构决定查询前提

初始化SQL定义事件表sensors.event，time为DateTime64(3)，按toYYYYMM(ds)月分区，默认保留一年。实际环境若做过迁移，应查询自己的表定义，不以文中版本代替现场结构。

ORDER BY中的标识、事件名和时间是排序安排，不是业务唯一约束。分区和TTL也不是越细越好，应结合写入、查询范围和保留政策评估。

四、分析层与元数据仍然需要维护

Superset负责数据集、SQL和图表展示，事件定义、漏斗顺序、留存观察窗仍由团队确定。这里没有“SQL自动等于完整产品分析引擎”的推论，也没有存储成本或查询速度的竞品倍数结果。

Compose配置保留superset_home卷。即使没有单独MySQL容器，Superset的元数据、配置和权限仍需要备份，不能把“没有额外MySQL服务”写成“不存在元数据存储”。

五、扩容先画出共享状态

多个Go实例不代表所有瓶颈都消失。要同时评估许可证交付约束、Redis共享状态、定时写入任务、ClickHouse连接与存储，以及实例间调度行为；未测试前不把它称为只扩一层的无状态系统。

上线前至少观察接收错误、处理错误、缓存积压、数据库写失败、磁盘与端到端可查延迟。按SDK端分别看异常，防止总体平均掩盖单端故障；这些是建议的验收与监控项，不是宣称项目已内置全部监控面板。

SensorFlow的架构价值在于路径可以检查、数据与计算可由团队掌握。要把它用好，需要把每一层的成功、失败、恢复和责任写清，而不是用“组件更少”替代工程证据。