一、引言：数据采集不是终点，是起点

很多智慧公厕项目做完设备部署、数据上云后，就认为“大功告成了”。但实际上，设备上线只是第一步，数据价值的挖掘才是真正的核心。

公厕每天产生大量数据：

• 厕位占用数据（高、中、低频使用时段）

• 环境监测数据（温湿度、氨气、硫化氢浓度）

• 能耗数据（照明、通风、除臭设备的用电量）

• 客流数据（日/周/月人流趋势）

• 设备运行状态（故障频次、设备寿命）

这些数据不只是用来“看”的。如果把它们放在一起分析，就能发现很多业务层面的洞察，帮助管理者从“凭经验”变成“靠数据”。

这篇文章分享我们桐盛在智慧公厕项目中，如何从设备数据中挖掘业务价值，以及踩过的坑。

二、数据分层：从原始数据到业务指标

在搭建数据价值体系之前，先要理清一个框架：数据是怎么一步步变成决策依据的？

我们把它分成四个层次：

层级	内容	示例	使用对象
原始数据层	设备上报的实时读数	厕位感应器状态、氨气浓度值	系统工程师
指标层	加工后的业务指标	今日占用率、周平均异味超标次数	运营主管
分析层	多维度交叉分析	客流高峰与异味超标的相关性	管理者
决策层	可执行的洞察	高峰时段增派保洁、设备联动策略调整	决策者

很多项目做到第一层就停了。但真正让系统“值钱”的，是第二到第四层。

三、具体场景：数据怎么“说话”？

场景一：厕位占用数据 → 保洁排班优化

传统做法：保洁员按固定时间表工作，不管忙不忙，都是那几个人、那几个时间段。

数据洞察：

• 通过客流计数器分析客流规律，我们发现不同公厕的客流高峰时段差异很大

• 有些公厕工作日早高峰（7:30-9:00）客流占全天的35%，但保洁员8:00才到岗

• 周末与工作日的客流曲线完全不同，但排班表是一样的

落地效果：

• 根据客流预测调整保洁排班，高峰期增配、低谷期减配

• 人力成本降低约20%，游客投诉率下降约65%

技术实现：

客流数据 → 分时段聚合 → 客流曲线建模 → 预测未来客流 → 排班建议推送

场景二：环境监测数据 → 设备联动优化

传统做法：排风系统定时开启（如8:00-22:00），不管现场异味情况如何。

数据洞察：

• 氨气浓度在客流高峰后30分钟达到峰值

• 夜间（22:00后）虽然排风还在转，但客流极少，氨气浓度基本不超标

• 不同季节的通风需求差异明显（夏季异味扩散快，冬季扩散慢）

落地效果：

• 改为按需排风（浓度超标才启动），综合节电20-30%-7

• 照明系统配合客流感应，人走灯灭，节电30-40%-1

• 每月碳排放减少约10-20%-10

技术实现：

环境传感器数据 → 阈值判断 → 联动指令下发 → 设备执行 → 效果回传验证

场景三：能耗数据 → 异常检测与预测维护

传统做法：设备坏了才修，水表电表读数靠人工抄，异常发现滞后。

数据洞察：

• 某公厕用水量连续3天异常上升，排查发现马桶水箱漏水

• 某排风扇电机电流逐渐增大（轴承磨损的前兆），提前更换避免了突发故障

• 不同季节、不同客流下的正常能耗区间差异很大

落地效果：

• 漏水等异常提前发现，维修成本降低约30%

• 设备寿命延长40-50%

• 从“等人投诉”升级为“主动预警”，投诉响应效率提升100%

技术实现：

能耗数据 → 滑动窗口计算基线 → 偏离检测 → 异常告警 → 工单自动生成

四、数据分析的技术架构

要实现以上价值，需要在系统架构中增加数据分析层：

4.1 数据流设计

设备上报 → 采集服务 → 消息队列(Kafka) → 数据清洗 → 时序数据库(InfluxDB)
                                         ↓
                                    流计算引擎(Flink)
                                         ↓
                                    实时指标 → 业务数据库(PostgreSQL)
                                         ↓
                                    可视化(ECharts) + 告警服务

4.2 关键模块代码示例

客流预测模型（简化版，Python + Prophet）：

import pandas as pd
from prophet import Prophet

# 加载历史客流数据
df = pd.read_csv('footfall_data.csv')
df.columns = ['ds', 'y']  # ds:日期时间, y:客流量

# 训练预测模型
model = Prophet()
model.fit(df)

# 预测未来7天客流
future = model.make_future_dataframe(periods=7*24, freq='H')
forecast = model.predict(future)

# 输出预测结果，用于排班调度
print(forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']].tail(24*7))

异常检测（时序数据离群值识别）：

-- InfluxQL示例：检测过去24小时内用电量异常
SELECT mean(electricity) 
FROM energy_consumption 
WHERE time >= now() - 30d 
GROUP BY device_id, time(1d)

-- 异常检测逻辑：当前值超出历史均值的±2个标准差
-- 在应用层实现阈值判断和告警触发

4.3 数据看板设计原则

看板类型	受众	核心指标
公厕大屏	公众/访客	厕位占用情况、温度、异味等级
运营看板	保洁/运维人员	待处理告警、设备状态、今日工单
管理看板	管理层	能耗趋势、投诉率、人力成本、碳排放量
决策看板	决策者	月度同比、项目ROI、节能减碳成果

五、常见问题与避坑指南

5.1 数据质量问题

问题：设备上报的数据中存在大量异常值（传感器故障、网络波动、设备重启导致的突变）。

解决方案：

• 在数据采集层增加前置校验，对明显异常的值进行标记而非直接丢弃-11

• 使用滑动窗口滤波，取中位数而非平均值作为有效值

• 保留原始数据和清洗后数据两条链路，便于回溯

5.2 数据孤岛问题

问题：客流数据、环境数据、能耗数据分别存在不同系统，做交叉分析时需要手工导出合并。

解决方案：

• 统一数据存储：所有设备数据进入同一套时序数据库

• 统一设备ID体系：所有设备在系统内有唯一标识，关联其位置、类型、归属

• 通过物模型抽象设备能力，屏蔽底层协议差异

5.3 数据量爆炸问题

问题：设备数量增加到1000+后，时序数据量快速膨胀，查询越来越慢。

解决方案：

• 设置合理的数据保留策略：原始数据保留1年，降采样数据长期存储

• 使用持续查询（Continuous Query）预聚合小时级/日级数据

• 高频查询场景使用缓存（Redis）

六、小结

智慧公厕的数据价值挖掘，本质上是回答三个问题：

1. 过去发生了什么？ → 描述性分析（看板、报表）

2. 为什么会发生？ → 诊断性分析（交叉分析、归因）

3. 未来会发生什么？ → 预测性分析（客流预测、能耗预测）

很多项目停留在第一个问题。如果能把后面两个问题也回答好，智慧公厕系统就能从“工具”升级为“参谋”，帮助管理者做出更好的决策。