Cassandra气象数据建模方案及聚合时序数据存储最佳实践问询

针对你提到的气象服务应用场景，结合明确的「按城市查询指定时间粒度聚合数据」的访问模式，具体建模方案如下：

分区键选型合理性判断 #

你提到的邮政编码/geohash作为分区键的思路是可行的，可根据实际查询粒度做优化：

• 如果核心查询粒度是城市，优先采用 「城市唯一编码 + 时间粒度标识」 作为组合分区键，完全贴合你的查询场景：比如查询上海的日度数据时，直接用SH001+DAY就能定位到对应分区的全量数据，不需要跨分区扫描，查询效率最高。
• 如果需要支持比城市更小的区域查询（比如区县、街区级），再补充geohash前缀作为分区键的一部分，注意控制geohash长度，避免出现分区过碎或者单个分区数据量过大的倾斜问题。使用邮政编码作为分区键时要注意适配不同国家的邮编规则，避免超大城市同一个邮编覆盖区域数据量远超普通区域的倾斜情况。

日/周/月级聚合数据是否要拆分独立列族 #

非常建议拆分独立列族（对应部分时序存储的独立表概念），核心原因有三点：

1. 你的访问模式每次只会查询单一时间粒度的数据，拆分后查询不需要过滤其他粒度的冗余数据，延迟会明显降低。
2. 不同粒度的聚合数据生命周期通常不同：比如日度数据可能只需要存3年，周度存10年，月度要永久留存，拆分后可以单独设置TTL过期规则，不需要做复杂的字段级过期逻辑，大幅降低存储成本。
3. 写入逻辑更简单清晰：日度聚合任务跑完直接写日度列族，周度任务写周度列族，不会出现写入冲突，后续调整不同粒度的聚合策略也不会互相影响。

参考表结构设计（以宽表型时序存储/Cassandra为例） #

// 日度气象聚合列族
CREATE TABLE weather_agg_day (
    city_code text,
    stat_date date,
    avg_temperature float,
    max_temperature float,
    min_temperature float,
    avg_humidity float,
    total_precipitation float,
    -- 其他自定义聚合指标
    PRIMARY KEY ((city_code), stat_date)
);

周度、月度列族仅需要修改列族名，将stat_date替换为stat_week（格式示例：2024W28）、stat_month（格式示例：202407）即可。

注：将时间字段设为聚类键后，同一个城市的所有聚合数据会按时间排序，查询连续时间范围的聚合数据时性能会提升数倍。

额外优化建议 #

• 单个城市的日度数据存10年也才3600多条，不存在分区过大的问题，不需要额外做分区拆分。
• 如果你的业务指标经常新增，可以采用窄表设计，将指标名作为聚类键的一部分，不需要每次新增指标都修改表结构。

内容的提问来源于stack exchange，提问作者Dipen