1901-2020年降水数据集处理实战：从数据清洗到高效存储的技术方案

1次阅读

共计 2313 个字符，预计需要花费 6 分钟才能阅读完成。

气象数据是气候研究和灾害预警的重要基础，但处理 1901-2020 年这样的长时序降水数据集面临巨大挑战：数据量常达亿级记录，且包含复杂的时空维度（经纬度 + 时间戳）。传统方法往往遭遇格式混乱、查询缓慢等问题。本文将分享一套经过实战检验的技术方案。

处理气象数据时，存储格式直接影响后续分析效率。我们对比三种常见方案：

CSV 文件：
优点：通用性强，可直接用文本编辑器查看
缺点：无索引支持，全表扫描效率极低（实测 1 亿行数据查询耗时 >300 秒）
HDF5 格式：
优点：支持分块压缩，适合单机科学计算
缺点：缺乏并发写入能力，时空查询需自行实现
PostgreSQL+PostGIS：
优点：内置空间索引（R 树 /GIST），支持标准 SQL 查询
实战表现：相同查询条件响应时间 <2 秒

原始数据常见问题包括缺失值、单位不统一等。以下是典型处理流程：

import pandas as pd

# 读取原始 CSV（示例为 CRU TS 数据集）df = pd.read_csv('precipitation_1901-2020.csv', 
                parse_dates=['time'],
                na_values=[-9999])

# 单位转换：mm/month → cm/year
df['precip_cm'] = df['precip_mm'] * 12 / 10

# 填充缺失值（使用前后 5 天的移动平均）df['precip_cm'] = df['precip_cm'].fillna(df['precip_cm'].rolling(10, min_periods=1).mean())

# 输出清洗后数据
df.to_csv('cleaned_data.csv', index=False)

PostgreSQL 表设计需要特别注意空间字段和索引：

-- 创建包含地理字段的扩展
CREATE EXTENSION postgis;

-- 主表结构（时间范围分区）CREATE TABLE precipitation (
    record_id BIGSERIAL,
    obs_time TIMESTAMPTZ NOT NULL,
    location GEOGRAPHY(POINT, 4326),
    value_cm NUMERIC(6,2),
    PRIMARY KEY (record_id, obs_time)
) PARTITION BY RANGE (obs_time);

-- 空间索引加速区域查询
CREATE INDEX idx_precip_geo ON precipitation USING GIST (location);

-- 按年代创建分区表（示例：1950 年代）CREATE TABLE precip_1950 PARTITION OF precipitation
    FOR VALUES FROM ('1950-01-01') TO ('1960-01-01');

使用 Dask 可显著提升大数据加载效率：

import dask.dataframe as dd
from dask.distributed import Client

# 启动本地集群（4 工作进程）client = Client(n_workers=4)

# 创建 Dask DataFrame
ddf = dd.read_csv('cleaned_data/*.csv', 
                 parse_dates=['time'])

# 定义入库函数
def load_to_db(partition):
    engine = create_engine('postgresql://user:pass@localhost/db')
    partition.to_sql('precipitation', engine, if_exists='append')
    return len(partition)

# 并行执行（每分区 100 万行）ddf.map_partitions(load_to_db, meta=('count', int))

测试环境：AWS r5.2xlarge（8vCPU/64GB RAM），PostgreSQL 14+PostGIS 3.2

优化措施	查询场景	平均耗时（秒）
无索引	某省 10 年数据筛选	58.7
空间索引	同上	1.2
无分区	全国 1 年数据统计	22.4
按年代分区	同上	3.8

错误做法：直接使用 LOCALTIMESTAMP 会导致时区混乱
正确方案：始终存储为 UTC，应用层按需转换

-- 错误示例（隐式时区转换）INSERT INTO precipitation VALUES 
    ('2020-01-01 00:00:00'::TIMESTAMP, ...);

-- 正确做法（显式声明时区）INSERT INTO precipitation VALUES 
    ('2020-01-01 00:00:00+00'::TIMESTAMPTZ, ...);

当处理单文件超 10GB 时：