基于TableStore的海量气象格点数据解决方案实战

前言

气象数据是一类典型的大数据，具有数据量大、时效性高、数据种类丰富等特点。气象数据中大量的数据是时空数据，记录了时间和空间范围内各个点的各个物理量的观测量或者模拟量，每天产生的数据量常在几十TB到上百TB的规模，且在爆发性增长。如何存储和高效的查询这些气象数据越来越成为一个难题。

传统的方案常常采用关系型数据库加文件系统的方式实现这类气象数据的存储和实时查询，这种方案在可扩展性、可维护性和性能上都有一些缺陷，随着数据规模的增大，缺点越来越明显。最近几年，业界开始越来越多的基于分布式NoSQL来解决这一问题，比如基于TableStore来实现气象格点数据的存储和查询。TableStore是一款阿里自研的分布式NoSQL服务，可以提供超大规模的存储容量，支撑超大规模的并发访问和低延迟的性能，可以很好的解决气象数据的规模和查询性能问题。

我们之前也写过相关的解决方案文章《基于云上分布式NoSQL的海量气象数据存储和查询方案》，也有一些客户基于这个方案进行了开发。出于减少客户开发难度，提供通用的实现的想法，我们最近开发了一个TableStore-Grid的Library，基于这个Library用户可以非常方便的实现气象格点数据的存储、查询和管理。本文作为一个实战文章，主要讲解这一解决方案的设计以及使用方式。

背景

格点数据的特点

格点数据具有明显的多维特点，以模式系统每次产生的数据为例，一般包含以下五个维度：

1. 物理量，或者称为要素：温度、湿度、风向、风速等等。
2. 预报时效：未来3小时、6小时、9小时、72小时等等。
3. 高度。
4. 经度。
5. 纬度。

当我们固定某一要素某一预报时效，那么高度、经度、纬度就构成一个三维网格数据，如下图所示(图片来自互联网)。每个格点代表了一个三维空间上的点，上面的数值为该点在某一预报时效(比如未来三小时)下，某一物理量(比如温度)的预报值。

假设一个三维格点空间包含10个不同高度的平面，每个平面为一个2880 x 570的格点，每个格点保存一个4字节数据，那么这三维的数据量为2880 x 570 x 4 x 10, 大约64MB。这仅仅是某个模式系统对某个物理量某一时效下的一次预报，可见模式数据的总量是非常大的。

格点数据的查询方式

预报员会通过页面的形式浏览各种模式数据(格点数据)，并进行数值模式预报。这个页面需要提供多种模式数据的查询方式，比如：

1. 查询一个经纬度平面的格点数据：比如未来三小时全球地面温度的格点数据，或者未来三小时浙江省地面温度数据。
2. 查询某个格点的时间序列数据：比如阿里云公司所在地未来3小时、未来6小时、一直到未来72小时的温度。
3. 查询不同物理量的数据：比如查询某一预报时效、某一高度、某一点的全部物理量的预报数据。
4. 查询不同模式系统产生的数据：比如同时查询欧洲中心的某一模式数据和中国气象机构产生的对应数据等。

上面提到，一个格点数据集一般是一个五维结构，各种查询方式实际上就是对这个五维数据进行切分，比如查询某个平面，每个剖面，某个点序列，某个三维、四维子空间等等。而我们的方案设计要保证在各种查询条件的查询性能，这是数据查询方面的主要技术难点。

基于TableStore的方案设计

标准化格点数据模型

首先，我们定义一个规整的五维网格数据为一个GridDataSet，表示一个格点数据集，按照维度顺序，其五维分别为：

1. variable：变量，比如各种物理量。
2. time：时间维度。
3. z