Sensors Data SDK → ClickHouse 完整实测

1. 准备可识别的测试事件

先生成唯一 run_id，避免把历史同名事件误认为本次结果。不要把生产 token 写进源码或终端历史。

export SF_ENDPOINT='https://your-domain.example/sensors/send/?token=REDACTED'
export SF_RUN_ID="sdk_ck_$(date +%s)"

浏览器项目使用官方 sa-sdk-javascript，仅修改 server_url：

import sensors from 'sa-sdk-javascript';

sensors.init({
  server_url: window.SF_ENDPOINT,
  is_track_single_page: true,
  use_client_time: true,
  send_type: 'beacon'
});
sensors.login('sf_engineering_user_001');
sensors.track('sf_engineering_test', {
  run_id: window.SF_RUN_ID,
  source: 'web_sdk',
  amount: 19.90
});
sensors.flush?.();

send_type: beacon 是浏览器传输选择，不保证立即可查。SDK 版本、广告拦截器、页面卸载时机都会影响发送。

2. Collector 实际做了什么

1. 从 data_list 或 data 读取 SDK 编码 payload，并限制请求大小。
2. 解码后接受事件数组或单个 type=track 对象。
3. 移除属性名的 $ 前缀并扁平化 JSON；例如 $os 存为 os。
4. 遇到新属性时按合法列名动态扩展表列。
5. 事件进入 Redis 集合，定时任务批量写 ClickHouse；Redis 写入失败时走直接入库回退。

因此生产验收要允许批处理延迟，并检查接收器日志、Redis 积压与 ClickHouse 三层，而不是只看前端 Network 面板。

3. 用 ClickHouse 证明落库

SELECT
  time, event, distinct_id, user_id,
  run_id, source, amount
FROM sensors.event
WHERE event = 'sf_engineering_test'
  AND run_id = 'sdk_ck_1726660000'
ORDER BY time DESC
LIMIT 10;

将示例值替换为本次 SF_RUN_ID。再检查重复与端到端延迟：

SELECT
  run_id,
  count() AS rows,
  uniqExact(distinct_id) AS identities,
  min(time) AS first_event_time,
  max(time) AS last_event_time
FROM sensors.event
WHERE event = 'sf_engineering_test'
  AND run_id = 'sdk_ck_1726660000'
GROUP BY run_id;

rows > 1 不一定是服务端重复：SDK 重试、页面重复初始化或同一测试多次点击都可能产生多行。当前原始事件表没有通用 event-id 去重键，业务查询应按明确规则去重。

4. 时间、schema 与身份语义

• time 来自事件时间戳并转为服务端时区；缺失或异常时间会回退到当前时间。新装脚本使用 DateTime64(3)，历史部署可能仍是 DateTime，毫秒精度需以实际 DESCRIBE TABLE 为准。
• 新装 schema 的 ds Date 从同一安全时间戳派生并按月分区；历史升级库可能保留字符串 ds，升级前要先审计字段类型。
• 分析身份优先选团队约定的稳定键。登录前后若 distinct_id 改变，需要单独的身份合并规则；不要默认 user_id 总是存在。
• 动态属性的类型由样本推断；上线前应固定事件字典，避免同一属性混用数字与字符串。

5. 验收清单与限制

• 分别验证匿名、登录、跨端、断网重试、批量发送和页面卸载。
• 验证 SDK 版本、加密插件、可视化埋点和自动采集；兼容标准上传流程不等于兼容所有插件。
• 监控 4xx/5xx、Redis 积压、动态加列失败、ClickHouse 写入延迟和磁盘空间。
• SensorFlow 与神策数据相互独立，未获其认证；迁移前保留原接收地址和回滚开关。

继续验证分析 SQL