1. 从一份站点空气质量表说起：数据价值与适用场景
做环境数据分析、城市治理或者健康暴露评估的朋友，应该都绕不开一个基础问题：怎么拿到干净、连续、字段齐全的空气质量历史数据。公开渠道其实不少，但真正落到“能直接进模型、能追溯、能按站点和时间维度做聚合”的表，反而没那么好找。我之前接触到一份“站点空气质量表”的数据文件，把站点的逐小时监测记录、污染物浓度、空气质量指数都整理在了一张表里，拿来做历史回溯和区域对比都挺顺手。
这个表的适用人群很明确：一是做环境政策研究的学生和研究人员，需要按站点统计污染天数、季风影响周期；二是做健康影响评估的团队，要把污染浓度和就医、出行数据关联起来；三是做数据产品的开发者，需要稳定、字段规范的基础数据做接口或报表。只要你的分析对象涉及“某个城市、某片区域的空气质量演变”，这份表就能作为底表直接使用。
站点的数据看起来是“字段+数值”的普通结构，但实际落地时牵扯到的问题不少：时间字段怎么统一时区、站点编号和经纬度怎么对应、AQI（空气质量指数）计算口径是否一致、缺测值用什么标记。这些细节如果不提前摸清，后续写清洗脚本时很容易反复返工。下面我直接拆开来讲，按“字段理解 — 数据特点 — 实操流程 — 常见坑 — 场景扩展”这条主线走，每部分都会给出实际可用的思路。
2. 核心字段与表结构：为什么这样设计
拿到任何一张表，第一步都不是急着跑数，而是先读懂结构。这份站点空气质量表的字段设计，基本覆盖了环境监测的常规要素，但从数据分析的角度看，有几个字段特别容易用错，单独拿出来说。
2.1 时间字段的粒度与含义
表里必然有一个时间字段，但要注意它到底是“监测起始时间”还是“监测结束时间”。多数平台习惯把小时数据标记为该小时整点，比如“2023-05-01 14:00:00”代表14:00到15:00这一小时的平均浓度。如果你做小时级分析，直接group by这个字段没问题；但如果你要计算“某一天24小时的完整覆盖”，就要确认当天是否缺了某些小时。
日粒度数据也有讲究：有的是全天平均，有的是按“当日0点到23点”的自然日，有的则是按“当日8点到次日7点”的环保统计日（部分地区用于考核口径）。这两者算出的日均值有差异，尤其在凌晨高污染时段，偏差可能超过10%。我一般会在建表初期额外加一个字段做标记，区分自然日与统计日，避免后续自相矛盾。
2.2 站点编号与空间位置的对应关系
站点编号是这张表的主键之一，但不同数据源的站点编码规则并不统一。有的用五位数字，有的用“市代码+站点序号”，有的干脆用拼音缩写。拿到表后，建议先用站点经纬度字段做一次反向验证：把站点坐标画到图上，对照真实城市行政边界，确认站点是否分布在合理区域。
这里存在一个容易被忽略的问题：同一站点在不同时期可能移动过位置，或者因为城市改造改了代码。如果你做长时间序列分析，不做站点匹配就直接拼接，会出现“幽灵站点”——同一编号在不同年份代表的完全不是同一个地方。我的做法是先按“站点编号+经纬度+所属城市”三层做去重比对，经纬度相差超过200米的记录单独列出来人工核验。
2.3 污染物浓度与AQI的换算逻辑
站点表通常会包含两类列：一类是各污染物原始浓度，比如PM2.5、PM10、SO₂、NO₂、CO、O₃；另一类是直接计算好的AQI和首要污染物。如果你只要一个综合指标，直接用AQI列就行；但如果你要分析污染物构成、做源解析或者健康风险评估，必须用原始浓度，不能拿AQI反推。原因是AQI采用的是分段线性插值，同一AQI数值在不同污染物之间没有可比性，更无法做线性运算。
AQI计算还有一个时点问题：实时AQI通常按滑动24小时均值（PM2.5、PM10）或最大8小时均值（O₃）计算，而日报AQI则按全天数据计算。同一小时数据，如果平台是滚动更新计算的，你存下来的AQI可能是“当时的值”，事后重算会不一样。对于需要精确复现的研究，建议把原始浓度和官方AQI都保留，以官方发布为准。
2.4 缺测值与无效数据的表示
表格里的缺失值通常表现为空值、负值或者特殊数字（比如-999、9999）。这些都需要在清洗阶段统一处理。特别注意的是，有些污染物浓度低于仪器检出限时，平台会记录为“0”或“1”，但这不代表真实浓度为零。如果你要做超标统计，把这类低值直接当0处理，会导致超标天数量被低估；正确做法是设定一个检出限阈值，低于阈值的标记为“未检出”，单独归类。
3. 数据特点与站点瑕疵：录入数值不能盲目相信
表格数据看起来规整，但实际使用中，站点级空气质量数据的“现场感”很强。这里说几个我踩过的真实情况，帮助大家理解为什么“数据已整理”不等于“数据可直接用”。
3.1 站点代表性差异：城区站 vs 郊区站 vs 背景站
一张表里往往同时包含不同类型站点。城市评价站一般设在人口密集区，交通站则在主干道旁，背景站通常远离城市。同一时刻，三类站点的PM2.5浓度可能差1.5到2倍。如果你把交通站的数据当成城市平均暴露水平，结论会明显偏高。所以使用前先看站点类型字段，或者自己根据经纬度和位置特征做分类，再决定数据代表的人群范围。
另外，部分站点可能是临时增设的，为了满足某段时间的监测需求。这会导致时间序列不完整，比如某站点只有2021年以后的数据，而且后期编号变更。对于趋势分析，建议选择连续运行时间超过3年的核心站点构建长期队列，临时站点仅做横截面分析。
3.2 数据粒度切换时的聚合偏差
小时级数据聚合为日数据，常见方式有简单平均和有效小时数加权。简单平均在数据缺失时会产生偏差，例如白天数据齐全、夜间缺测，会导致日均值偏高。建议聚合时按“当日有效小时数”加权，比如要求至少16个有效小时才计算日均值，否则标记为无效。对于O₃，除了日均值，还要计算日最大8小时平均（MDA8），这是空气质量评价的一个重要指标。
聚合后需要重新检查数据分布。小时级PM2.5通常呈右偏分布，但日均值会更接近正态。如果聚合后某个站点数据仍然极度偏态，要排查是否存在特定的排放源周期性扰动，比如附近的工厂夜间排放。
3.3 空间插值与区域平均的误区
不同研究者经常用站点浓度做区域平均。需要注意：站点不是均匀分布的，城区站点多、郊区站点少，直接算术平均会偏向城区。可用的替代方案包括反距离加权、克里金插值，或者用人口权重估算真实暴露水平。但插值方法也依赖站点密度，站点太少时插值结果非常不稳定。
如果你只是做相对比较（比如“A区域比B区域污染更重”），算术平均问题不大；但如果你要做排放清单校验或者健康负担评估，就必须考虑站点分布的空间偏倚。
4. 实操：从原始表到可用分析数据集
到了这一步，才真正进入数据工程环节。基于这份站点空气质量表，我的操作流程基本固定为：了解原始结构 -> 建库落表 -> 数据体检 -> 清洗规则 -> 特征衍生 -> 输出宽表。下面按步骤详细写，附上可直接参考的代码思路。
4.1 建表与数据导入：先定规范再灌数
拿到原始表后，我习惯先建立本地数据库，将数据导入为标准化表。字段类型设计上注意几点：时间字段用DateTime类型；站点编号用字符串而非整数，避免前导零被吞；经纬度用Decimal(9,6)，保留6位小数；浓度字段用Float或Decimal，并区分原始浓度与质控后浓度。
CREATE TABLE air_quality_station ( station_id VARCHAR(32) COMMENT '站点编号', station_name VARCHAR(128) COMMENT '站点名称', city_name VARCHAR(64) COMMENT '所属城市', longitude DECIMAL(9,6) COMMENT '经度', latitude DECIMAL(9,6) COMMENT '纬度', monitor_time DATETIME COMMENT '监测时间', pm25 DECIMAL(8,1) COMMENT 'PM2.5浓度，单位ug/m3', pm10 DECIMAL(8,1) COMMENT 'PM10浓度', so2 DECIMAL(8,1) COMMENT '二氧化硫', no2 DECIMAL(8,1) COMMENT '二氧化氮', co DECIMAL(6,2) COMMENT '一氧化碳，单位mg/m3', o3 DECIMAL(8,1) COMMENT '臭氧', aqi INT COMMENT '空气质量指数', primary_pollutant VARCHAR(32) COMMENT '首要污染物', data_source VARCHAR(64) COMMENT '数据来源标记', etl_time DATETIME COMMENT '入库时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;导入完成后，第一件事是统计记录条数。假设原始文件有57万条，导入后如果少了数据，多半是编码问题或字段分隔符不一致。此时需要比对总数和去重后的（station_id, monitor_time）数量，二者必须一致，否则存在重复记录。
4.2 数据抽查与质控：分层抽，不要随机抽
“全表平均值正常”不代表每个站点都正常。我习惯按站点分层抽样，每个站点随机选3天完整数据，人工核对小时值是否连续、浓度是否在合理区间。PM2.5的合理区间是0到1000μg/m³，超过这个范围的记录大概率是仪器故障或数据传输错误，要打异常标记。
同时要检查空间上的合理性：相邻站点的同一时刻浓度差距不能太大。如果两个相距2公里的站，PM2.5在同一小时一个为20、一个为200，多半有一个站点出了问题。用“空间邻域对比”作为质控方法，比单站点阈值判断更灵敏。
4.3 清洗规则建议：分级处理，保留痕迹
我习惯把清洗规则分成三档，而不是一刀切删数据：
- 硬删除：浓度值为负、时间字段无法解析、经纬度明显出界（经度不在70到140之间，纬度不在0到55之间），这些属于录入错误，直接删除并记录数量。
- 软标记：浓度值超过上限阈值（比如PM2.5大于900），保留数据，但加一个quality_flag=“疑似异常”，后续分析可选择排除。
- 缺失填补：短时段缺失（连续小于3小时）可以用线性插值填补，但长时段缺失不建议填补，直接保持缺失。
插值操作在时间序列分析中有用，但注意：插值不等于真实观测，填补后的数据如果参与超标统计，等于人为造假。所以业务考核类场景不要插值，只有做连续特征提取或模型输入时才考虑。
4.4 特征衍生：一天的污染画像怎么构造
基于站点小时数据，可以衍生出一批有价值的特征，这一步是数据分析中比较出成果的环节。常用特征包括：
- 日最大值、最小值和极差
- 夜间均值（20:00至次日06:00）与日间均值（08:00至18:00）的差值
- PM2.5/PM10比值（判断粗颗粒物与细颗粒物的相对贡献）
- 连续污染时长（PM2.5超过75持续的小时数）
- 首要污染物出现频率
比如计算某城市全年PM2.5/PM10比值，如果比值低于0.5，说明该城市沙尘或道路扬尘影响较大；如果高于0.8，说明燃烧源贡献较高。这个比值在北方城市、南方城市之间差异明显，做对比分析时容易出亮点。
5. 常见问题与排查技巧实录
这里整理我在处理站点空气质量数据时遇到过的几类高频问题，以及对应的排查思路。这些问题在数据格式说明里通常不会写全，但在实际使用中非常容易出现。
5.1 部分站点某一时期数据全部缺失
现象：某站点2022年7月一整个月没有记录，前后月份正常。排查方向：先确认是否为站点设备维护期。很多平台在设备维护时不会产出数据，也不会标记说明。你可以看同一城市其他站点同期是否有数据，如果其他站点正常，该站点单独缺失，大概率是设备问题或站点暂时停运。
另一种可能是数据从平台导出时由于查询参数拼接错误，漏掉了某个站点的数据。这时要回溯原始归档文件，确认缺失是上游原因还是导出原因。归档文件也没有，那就只能放弃这个时段，别强行插值补满。
5.2 AQI与污染物浓度对不上
算出来的AQI和官方发布的日报AQI差异大，这通常是计算口径不同。官方日AQI基于当日0点到23点的浓度，但有些市级的评价会采用“自然日+数据审核后”的修订值。修订过程涉及人工审核，甚至会把明显异常的小时数据剔除后重算，所以原始值算出来的AQI偏高是正常的。
处理办法：以官方发布数据为准，你的分析结果不要直接引用“自己算的AQI”与官方作对比。如果你要自己算AQI，必须严格按技术规范的分段限值和插值公式计算，并输入当日数据全部参与计算，不打折扣。
5.3 相邻城市同一时刻浓度差异悬殊
监测显示两个相邻城市PM2.5浓度差了3倍，数据本身没问题，但要注意地理和气象条件。比如一个城市处于山谷下风向，另一个在上风向，静稳天气下污染物在山谷内堆积，差异确实可以拉得很大。遇到这种情况，不要急着怀疑数据错误，而是结合风场数据辅助判断。
如果你没有气象数据，可以用“多站点同步曲线”看看两个城市多个站点的变化走势是否一致。趋势一致仅数值有差异，说明是区域背景浓度差异；连趋势都不一样，那就要仔细核查站点数据链路了。
5.4 经纬度坐标全是同一个中心点
表里所有站点的经纬度相同或非常接近，这通常是因为平台出于隐私考虑做了坐标偏移，只显示城市中心点。如果分析精确的空间分布，这张表就不能满足要求。可以尝试用站点名称中的地址信息做地理编码，但精度有限。
实际项目中，我碰到过一次平台导出时把经纬度截断成两位小数，导致方圆1公里内所有站点坐标完全相同。处理方式不复杂：如果站点数量不多，逐个手动校验并修正；如果站点数量上千，那就只能放弃精度需求，改用“城市-站点类型”的粒度做分析。
6. 基于站点表还能做什么：场景扩展与价值挖掘
一张规范化的站点空气质量表，真实应用范围比很多人想得更广。下面挑几个我见过或验证过的方向，给大家一些参考。
6.1 区域污染过程复盘
选取一次重污染过程（例如持续72小时以上PM2.5高浓度事件），把多站点数据按时间对齐，画出浓度空间演变图，能清楚看到污染从哪个方向输入、在哪里堆积、何时消散。这个过程用于政策评估或公众沟通都有说服力。而且只需要站点表本身，不需要额外数据就能完成初步复盘。
6.2 健康暴露评估与人群影响估算
将站点浓度和人口分布数据叠加，可以估算某次污染过程中受影响人群数量。前提是站点空间代表性可以接受。用站点浓度作为周边区域的暴露估计会存在一定误差，但做相对比较和趋势判断是可行的。搭配疾病门诊数据，还能做短期暴露反应关联分析。
6.3 与气象数据关联：预测模型的输入
站点表与气象数据（温度、湿度、风速、风向、边界层高度）结合，可以构建统计模型做次日空气质量预测。这里强调一下：原始站点表的时间分辨率越细，模型输入特征越丰富。小时级数据可以构造“夜间逆温强度”“通风系数”等气象条件指标，预测效果比单纯用日均值好不少。
我做过一个简化版的试验：利用前一天PM2.5浓度、当天湿度以及风速，就能解释一部分第二天的浓度变化。如果再把O₃和NO₂的夜间反应特征加进去，预测精度还有提升空间。
6.4 数据服务产品化：标准报表输出
如果你在做一个面向公众或内部决策者的环境数据平台，站点空气质量表就是核心底层。经常有这种需求：生成日报、周报、月报，统计各站点达标天数、首要污染物分布、同比环比变化。字段设计合理后，这套报表完全可以用SQL定时任务自动刷新，不需要每天手工导出。
7. 最后的几点经验
站点空气质量表只是一个起点，离“有用”还差几步距离。我自己在使用过程中的体会是：数据的时间连续性和空间代表性，比字段数量更重要。一张字段再多、但关键站点长期缺测的表，分析价值会大打折扣。
实际操作中，我通常会先花一周时间做数据体检和数据质量报告，而不是急着跑分析。数据体检能避免后续两个月都在收拾数据质量问题。你可以把所有清洗规则、异常标记、处理动作记录成文档或日志，这在写论文或给客户交付时是重要的工作量证明。
最后分享一个小建议：如果你多次使用同一份数据源，建议维护一份“站点变化台账”，记录每个站点的新增、停运、搬迁和类型调整。环境监测站网是在不断变化的，这份台账能让你在跨越多年的分析中少走很多弯路。这份站点空气质量表的常规操作，就先说到这儿，有具体问题欢迎留言交流。
