体育云平台项目里最容易返工的不是页面，而是存储。闸机、票务、手环、摄像头、小程序五类数据源各自为政，字段对不上、时间戳不统一，上线三个月就可能推倒重来。存储架构其实只回答三个问题：数据从哪来、按什么形态存、放多久怎么删。下面按接入、选库、分层、容量、留存备份五步拆开讲。
一、多源接入：协议先定，字段后定
五类数据源的节奏完全不同，不能共用一条管道：
- 闸机与票务属低频事件、要求可靠送达，走 MQTT 的 QoS1 或设备直连 HTTP 回调，带重发与去重；
- 摄像头抓拍与手环轨迹是持续高频流，用消息队列做削峰与多订阅，下游各取所需；
- 小程序等业务请求统一收进网关，做鉴权、限流与参数校验后再落库。
三条通道最终收敛到同一套事件规范：设备编号、事件类型、毫秒级且统一时区的时间戳、业务主键。落地时先把事件字典定下来，同一时刻同一设备的重复上报按事件编号去重，时间戳一律取设备侧产生时间而非入库时间，网络抖动引起的入库延迟单独统计。字典定稿后再开工，各厂商才有共同语言，字段不统一，后面的分层全是空谈。
二、按形态选库，别拿关系库硬扛
时序数据包括闸机通行、手环心率、地磁占用，写时序库，按时间分区、按标签索引，写入吞吐高而单条体积极小；业务数据包括订单、会员、票务核销，放关系库，靠事务保证一致性；抓拍图片与视频片段放对象存储，库里只存路径、哈希与采集元数据。三类数据各归各位，查询性能与存储成本才能同时可控。写入策略也要配套：时序库按天建分区、按设备与类型打标签，保留策略设为 30 天热存、1 年降采样；关系库的通行明细按月归档，只留近 3 个月在线；对象存储开启生命周期规则，超期抓拍图自动转低频或删除，让存储自己管自己。
三、四层数仓与命名规则
按 ODS、DWD、DWS、ADS 四层组织：ODS 原样落地并按天分区，保留原始报文以便追查；DWD 做清洗与维度关联，做到一行一事；DWS 按主题轻度汇总，例如通行日汇总、客流小时汇总；ADS 面向看板与对外接口输出最终指标。命名建议带层级与日期，例如 ods_gate_event_20261004，哪一层、哪张表、哪一天，一眼可辨，回溯时不必翻文档。分层的真正收益在回溯：原始报文保留着，就能重跑清洗逻辑修复历史数据，而不必找设备厂商逐条对账。
四、容量估算：10 个闸机、日 5000 人次
先把假设写清楚再算。按单条通行事件 200 字节、人均 1.6 次刷卡计，日通行事件约 8000 条，一天约 1.6 MB，一年约 580 MB，这一块小到可以忽略。真正吃空间的是抓拍图片：按每日 5000 张、单张 80 KB 计，一天约 400 MB，一年约 146 GB；若原图按 30 天滚动覆盖，稳态占用约 12 GB，加上索引与冗余按 1.5 倍预留约 18 GB。再看手环心率，按每 5 秒一条、每条 40 字节、100 台设备计，一天约 690 万条约 275 MB，一年约 100 GB，这部分才是需要压缩与降采样的重点。再补一项常被忽略的：小程序与票务订单按每单 1 KB、日 2000 单计，一天约 2 MB，一年不到 1 GB。把五类数据摆在一起看，结论很清楚，结构化事件永远不是瓶颈，图片与高频传感器才是，容量预算应向这两块倾斜。
五、留存、备份与脱敏
存下来只是第一步，删得掉、备得住、查得到才算合格。建议按下面四条执行：
- 明确留存期限：抓拍原图 30 天滚动覆盖，人脸特征与通行记录按最短必要期限设定，到期自动归档或删除，不靠人记得；
- 执行 3-2-1 备份：三份副本、两种介质、其中一份异地，每月做一次恢复演练，只备份不演练等于没备份；
- 脱敏与分权：看板只出聚合指标，手机号与证件号入库即掩码或哈希，按角色开表，所有查询留审计日志；
- 每季度复核一次增长与容量，在磁盘告警前完成扩容与分区预建。