SensorFlow 采集层技术解析：事件模型、传输与 ID 打通

理解 SensorFlow 采集层，需要区分事件表达、网络载荷、服务端存储和身份计算。四个字段看起来一致，并不说明不同 SDK 的传输协议完全通用；表里有两个身份字段，也不代表完整身份图已经建好。

本文由 SensorFlow 项目维护方整理，AI辅助修订，依据公开版本 2ff2275 做源码阅读。示例是合成教学数据，不是实际 SDK 请求、客户身份或生产准确性测试。

一、事件模型表达什么

下面用事件名、标识、毫秒时刻和属性说明一条保存行为：

{
  "event": "DocumentSaved",
  "distinct_id": "synthetic-account-a",
  "time": 1792029600000,
  "properties": {"document_id": "synthetic-doc-a", "entry_point": "toolbar"}
}

这份 JSON 可解析，但不能直接当作生产接收接口的请求体。当前控制器检查 Token，读取 data_list/data，经过许可证处理后才解析事件；真实 SDK 还涉及编码、压缩及版本差异。

在SDK文档中，客户端应配置 /sensors/send/?token=YOUR_TOKEN。保留事件调用是迁移目标，不是绕过真实协议和许可证的理由。

二、批量、缓存和重试分别属于哪一层

客户端是否批量发送、如何持久缓存、什么时候重试，应按所选 SDK 版本和配置验收。不能把 IndexedDB、SQLite 或指数退避写成所有端已经统一验证的机制。

服务端也有自己的缓存：当前控制器处理字段后把事件序列化，写进 Redis 集合；定时任务分批取出记录写入 sensors.event，失败路径包含回填处理。客户端缓存与 Redis 不是同一个东西，也不提供相同故障保证。

因此要分别测试断网、超时重传、Redis失败、写入失败和进程中断，记录哪一层确认了成功。HTTP响应、缓存成功和数据库可查是不同里程碑。

三、为什么不能承诺“按三个字段去重”

Redis 集合可以合并相同集合成员，但这里的成员是序列化记录。它不是按 event、distinct_id、time 定义的完整业务幂等系统，更不能由此推出所有重试不会重复计数。

同一个账号在相同时刻完成两次合法动作，也可能在业务上都需要保留。支付、回调或订单统计应先定义稳定业务键，再验证重复、冲突和补偿，不应靠粗略时间桶直接删事件。

当前事件表初始化使用 MergeTree。排序键不是关系数据库式唯一约束，查询时仍要结合业务事件定义判断何为重复。

四、ID 打通先问“哪些事实被保留”

distinct_id、anonymous_id、user_id 可以帮助检查匿名和登录相关记录，但字段存在不代表已经实现全部身份合并策略。当前用户属性处理也不能直接包装成与成熟平台等价的身份图服务。

先准备共用设备切换两个账号、同账号多设备、退出后匿名访问和重复登录等合成旅程。对每个行为写明原始标识、业务账号、关联发生时刻及报表期望，再核对实际存储与查询。

历史身份映射是否可导出、是否能授权迁移、在新链路如何重建，必须单独分析。不要承诺“一张映射表完整搬过来就自动打通”，也不要把所有匿名记录强行归给最后登录的账号。

五、沿代码审查，不用架构口号替代验收

可以先阅读部署README确定 Demo 与商业许可证接收的边界，再依次查看路由、控制器、Redis任务与表结构。源码能帮助定位责任层，但不能自动证明所有异常路径已经可靠恢复。

SensorFlow 的采集层适合用具体事件和查询来验证。事件语义、传输、身份和指标分别签收，才能判断“已有埋点可以复用到什么程度”，而不是用“协议通用”一句话跳过这些工作。