SensorFlow Docker 部署：从埋点接入到第一张看板

部署 SensorFlow，建议先看见合成 Demo，再接入一条真实测试事件，最后制作自己的业务看板。这三个阶段分别验证环境、采集链路和指标含义，不能靠一个容器 healthy 状态一起验收。

SensorFlow 的开源部署和合成演示不要求商业许可证；真实 Sensors Data SDK 接收需激活许可证。当前环境还使用 Redis，不能把 Go、ClickHouse、Superset 这条主路径误写成完整容器清单。

本文由 SensorFlow 项目维护方整理，AI辅助修订；依据公开版本 2ff2275。本轮核对了脚本与配置、执行了隔离合成表查询，没有重新运行完整 Docker 安装，也没有虚构 SDK 接收实测。

一、安装前确认三个条件

准备可运行 Docker Engine 或 Docker Desktop 的主机，以及 Docker Compose v2。还要确认磁盘持久化、镜像网络、端口占用和现有 Redis/ClickHouse 的接入方式；不要从"能启动"推导某个CPU/内存组合支持多少生产流量。

部署 README给出的入口不是占位仓库，而是：

bash 复制代码

git clone https://github.com/data-analyze-bi/sensorFlow.git
cd sensorFlow
./install.sh

脚本与部署配置说明应一起阅读。重用已有服务时必须提供匹配的连接参数，不能把本地回环端口、容器服务名和公网地址混为一谈。

安装器负责基础环境和 demo_* 合成事件，并建立数据集与演示看板。按安装输出的服务器IP地址和管理员登录进入 Superset；只向需要的访问者开放管理端口，不公开数据库端口。

这一阶段可以验证看板可加载、查询有结果以及磁盘卷可持续保存。图上的人数、购买与金额都是演示数据，不是客户效果，也不证明真实 SDK 已经接通。

Compose 源码把 Redis、ClickHouse、ingestion 和可选 Caddy 放在不同 profile 下。只在根目录执行一条没有正确环境的 compose 命令，不等于完整执行安装流程。

从运营网站取得适用于当前环境的许可证，按安装文档放好文件后，在仓库目录运行：

bash 复制代码

./activate.sh

激活流程最后启动 ingestion，保留已有基础服务和演示数据。当前公开激活说明与脚本是版本依据，不要把许可证文件或验证材料放进公开文章/仓库。

SDK 的目的地形式是 https://你的接收域名/sensors/send/?token=YOUR_TOKEN。把实际域名、TLS、反向代理和安装环境的 Token 配好；示例字符串不能当作可直接访问的地址。生产 Token 也不要贴进截图或工单公开区。

按各端 SDK 文档加载官方 SDK，在测试环境发送唯一命名的 integration_test。记录预期次数、发生时间和测试标识，先确认请求目的地，再查询存储，不靠HTTP200代替入库验收。

在有权限的 ClickHouse SQL 客户端执行：

sql 复制代码

SELECT time, event, distinct_id, anonymous_id, user_id
FROM sensors.event
WHERE event = 'integration_test'
ORDER BY time DESC
LIMIT 10;

这是当前初始化表的字段，不是通用的 events 表。查询最近十条只是第一步，还需要按真实表中测试属性隔离本次旅程，避免把其他人的测试结果误认为自己的成功。

建议先回答"测试窗口内某个业务成功事件发生几次、涉及哪些测试账号"。先检查明细与边界，再给图表添加时间筛选、事件筛选和环境说明；不要把点击购买按钮直接当成支付成功。

漏斗还需要用户范围、步骤顺序和转化窗口；留存还需要群体入口、后续观察窗口及尚未成熟的日期处理。存在几张图不是这些分析已经正确的证明。

从演示数据切换到真实数据源时，明确排除 demo_* 与内部测试事件。保留指标定义、SQL和一组预期样本，让产品、运营和研发可以复核同一结果。

确认备份与恢复、磁盘余量、凭据、TLS、接收错误和端到端可查延迟。Superset 元数据与配置也要持久化；安装包未额外带 MySQL 容器，不等于看板没有元数据需要备份。

当前事件表采用月分区，默认TTL一年，不是所有业务都该使用的最终保留策略。扩容也要同时评估 Redis、写入任务、ClickHouse 和管理面，不能只把 Go 实例数加大就承诺容量增长。