1. 问题定义
客流统计系统在短周期运行时，数据通常比较稳定。
当运行周期扩展到季度或年度后，容易出现：
统计量持续增长
高峰值异常放大
入口数据差异扩大
重复率上升
多数情况不是识别模型失效，而是：
数据一致性失效
长期沉淀的数据如果无法保持统一统计规则，趋势分析会逐渐失真。
2. 客流系统的数据结构
客流统计属于典型的：
Event Stream System
系统持续接收边缘设备产生的检测事件。
原始数据结构：
{
"device_id":"gate_01",
"track_id":"T98431",
"timestamp":1748323012,
"direction":"in",
"feature_vector":"xxxx",
"confidence":0.96
}
其中：
字段说明
device_id设备编号
track_id单设备轨迹ID
timestamp时间戳
direction进/出方向
feature_vectorReID特征
confidence检测置信度
如果直接累计：
SELECT COUNT(*)
FROM traffic_event
WHERE direction='in';
长期统计结果会被放大。
原因来自重复事件。
3. 重复计数来源
3.1 时间重复
入口区域停留会产生连续触发。
例如：
09:01:02 enter
09:01:07 re-enter
09:01:11 re-enter
检测系统会产生多个事件。
实际只属于：
一次访问
处理方式：
WINDOW = 300
if now-last_seen < WINDOW:
ignore()
即：
5分钟窗口内不重复计数
窗口长度一般：
60s ~ 300s
根据场景调整。
3.2 空间重复
多入口场景：
Gate_A
Gate_B
Gate_C
同一用户跨入口移动时：
A记录一次
B记录一次
最终：
1 person → n records
解决方式：
Cross-camera ReID
依赖：
时间关联
轨迹关联
特征向量匹配
统一：
visitor_id
而不是：
track_id
因为：
track_id 只在单设备有效
4. 数据链路设计
长期沉淀的数据系统一般拆成四层。
Layer 1：Edge Detection
边缘设备执行：
人体检测
轨迹跟踪
方向判断
ReID特征提取
输出：
Detection Event
Layer 2：Message Queue
事件进入消息系统：
Kafka / RabbitMQ
作用：
解耦
削峰
异步处理
数据格式统一：
traffic_event
Layer 3：Stream Processing
流处理执行：
时间窗口去重
跨设备合并
员工过滤
异常值清洗
典型方案：
Flink
Spark Streaming
输出：
visitor_session
Layer 4：Analytics Storage
数据分层存储：
Raw Table
原始事件：
traffic_event
Session Table
访问会话：
visitor_session
Aggregate Table
聚合统计：
daily_traffic_stats
减少：
全量扫描成本
5. Session 化设计
长期分析不建议直接使用 Event。
推荐：
Event → Session → Visitor
Session 数据：
{
"visitor_id":"V10021",
"enter_time":"09:01",
"leave_time":"09:18",
"duration":1020,
"source_gate":"gate_02"
}
支持：
停留时长分析
回访分析
路径分析
热区分析
相比 Event：
噪声更少
稳定性更高
6. 技术指标
长期运行时建议关注：
指标建议值
检测准确率≥95%
去重准确率≥90%
ReID匹配率≥85%
数据延迟<3s
消息丢失率<0.1%
时间同步误差<100ms
否则：
长期趋势容易漂移
7. 规则版本化
模型升级会影响历史数据。
例如：
检测算法升级
ReID模型更新
设备更换
建议保留：
model_version
rule_version
避免：
历史统计口径变化
造成：
同比失效
8. 总结
长期客流数据不是：
持续存储事件
而是：
持续维护一致性
核心环节：
时间去重
跨设备归并
Session 化
规则版本化
缺少任一环节，长期统计结果都会出现偏移。
