营销网站的例子,meetsh网站建设,江苏省建设职业中心网站,闵行 网站建设公司摘要#xff1a; 气象数据是一类典型的大数据#xff0c;具有数据量大、时效性高、数据种类丰富等特点#xff0c;每天产生的数据量常在几十TB到上百TB的规模#xff0c;且在爆发性增长。如何存储和高效的查询这些气象数据越来越成为一个难题#xff0c;本文针对气象领域中…摘要 气象数据是一类典型的大数据具有数据量大、时效性高、数据种类丰富等特点每天产生的数据量常在几十TB到上百TB的规模且在爆发性增长。如何存储和高效的查询这些气象数据越来越成为一个难题本文针对气象领域中海量模式数据的存储和查询问题分别介绍了传统方案和采用表格存储(TableStore)的方案并对方案优缺点进行了一些总结。
前言
气象数据是一类典型的大数据具有数据量大、时效性高、数据种类丰富等特点。气象数据中大量的数据是时空数据记录了时间和空间范围内各个点的各个物理量的观测量或者模拟量每天产生的数据量常在几十TB到上百TB的规模且在爆发性增长。如何存储和高效的查询这些气象数据越来越成为一个难题。
传统的方案常常采用关系型数据库加文件系统的方式实现这类气象数据的存储和实时查询这种方案在可扩展性、可维护性和性能上都有一些缺陷随着数据规模的增大缺点越来越明显。最近几年学界和业界开始不约而同的转向利用分布式NoSQL存储来解决海量气象数据的存储和实时查询问题相比之前的方案可以支撑更大规模的数据量并提供更好的查询性能并且在稳定性、可管理性等方面也得到了显著的提升。
另一方面利用云计算的资源来解决气象大数据的解析、存储、查询与分析也成为一种趋势和方向。云上有着丰富的产品服务和弹性的计算资源可以在云上完成一整套的气象数据处理工作流利用云上的分布式存储进行气象数据的存储和实时查询利用大数据计算服务进行气象数据的分析和加工利用各种应用服务搭建气象平台与应用。
因此今天越来越多的气象领域科研人员以及海洋、地震等等领域的科研人员开始了解云计算了解分布式存储并思考如何基于这些服务进行海量气象数据的存储和查询方案设计。本文会基于表格存储(TableStore, 原OTS)在气象领域的解决方案的探索介绍如何使用表格存储解决海量气象数据的存储和实时查询难题。
气象数据的特点和查询方式
这一章会介绍一下气象数据(主要是模式数据)的特点以及几种查询方式并由此引出为了实现海量气象数据的存储和实时查询我们需要解决哪些问题。
模式数据
气象数据中非常重要的一部分数据是模式数据用于数值模式预报。模式数据是由高性能计算机根据地面、高空、卫星等传感器上的实时观测数据通过物理方程计算得出的产生模式数据的系统是一套庞大的计算系统一般各个发达国家的气象机构都会有自己的一套模式系统。
模式系统每天会计算几次每次生成几百个物理量在未来一段时间(比如240小时)的不同海拔高度下的一系列经纬度网格预报数据网格上的每个点代表这个高度这个经纬度上未来某时刻某个物理量的预报数值。
模式数据具有多维特点
模式数据具有明显的多维特点以模式系统每次产生的数据为例包含以下五个维度
物理量或者称为要素温度、湿度、风向、风速等等。 预报时效未来3小时、6小时、9小时、72小时等等。 高度。 经度。 纬度。 当我们固定某一要素某一预报时效那么高度、经度、纬度就构成一个三维网格数据如下图所示(图片来自互联网)。每个格点代表了一个三维空间上的点上面的数值为该点在某一预报时效(比如未来三小时)下某一物理量(比如温度)的预报值。
假设一个三维格点空间包含10个不同高度的平面每个平面为一个2880 x 570的格点每个格点保存一个4字节数据那么这三维的数据量为2880 x 570 x 4 x 10, 大约64MB。这仅仅是某个模式系统对某个物理量某一时效下的一次预报可见模式数据的总量是非常大的。模式数据的查询方式
预报员会通过页面的形式浏览各种模式数据并进行数值模式预报。这个页面需要提供多种模式数据的查询方式比如
查询一个经纬度平面的格点数据比如未来三小时全球地面温度的格点数据或者未来三小时浙江省地面温度数据。 查询某个格点的时间序列数据比如阿里云公司所在地未来3小时、未来6小时、一直到未来72小时的温度。 查询不同物理量的数据比如查询某一预报时效、某一高度、某一点的全部物理量的预报数据。 查询不同模式系统产生的数据比如同时查询欧洲中心的某一模式数据和中国气象机构产生的对应数据等。 查询方式不限于以上几种本文重点分析前两种较为典型的查询方式即“查询一个经纬度平面的格点数据”和“查询某个格点的时间序列数据”。
方案要解决哪些问题
首先是存储方面的问题。海量的气象数据必须采用多台服务器进行存储问题在于如何选择或者构建一个分布式存储系统来保障数据可靠性、可管理性和系统可维护性。
然后是查询的问题。预报员在进行气象预报时需要快速的浏览大量的气象数据才能高效准确的进行气象预报。因此各种查询操作的延迟要很低必须在毫秒级。上面提到数据是分布在多台机器之中的为了实现毫秒级的延迟必须满足以下两点
能够根据查询条件高效的定位到要查询的数据。 定位到数据之后需要高效的筛选出本次查询所需的数据。比如查询某个点的时间序列数据需要只筛选出该点的数据。 下面我们来看传统方式和分布式NoSQL方式分别如何解决该问题。
传统的气象数据存储查询方案
由于多维气象数据具有数据量大的特点所以传统的存储方式是文件系统而非数据库。在文件系统中每个维度作为一个目录形成一个树形的目录结构数据文件作为树的叶子节点如下图所示。
image.png | center | 698x611 上图只是一个示意图实际存储时数据的层次关系和目录结构设计会因地而异不同的研究机构会采用不同的目录结构设计。一个需要考虑的问题是一个数据文件需要控制在多大即一个数据文件要保存多少维度信息的数据。如果每个文件都很小文件系统中就会有大量的小文件导致定位文件的延迟增加维护这些小文件的负担也较大。如果每个文件都较大那么就要避免在查询时读取整个文件导致延迟很高。 下面我们来看这种方案分别如何解决存储和查询问题。对于存储这种方案会人为的将不同类型的数据划分到不同的服务器上实现数据的分布式保存每台机器的目录结构都如上图所示。为了维护某种类型的数据对应哪台机器常采用关系型数据库进行记录或者使用配置文件的方式。
对于数据的查询这种方案常会先从关系型数据库中获取要查询的数据文件所在的机器和文件系统路径然后访问对应机器上的agent进行查询。这个agent会访问本地文件系统读取数据文件并筛选和处理出用户所需的数据。这个agent是必不可少的其作用是在本地先对数据进行一遍筛选和处理以减少传输的网络流量。
这里我们可以举一个例子假设我们要获取某个点在某一高度的未来72小时的时间序列数据预报时效间隔3小时那么其实只是获取24个数值。问题在于这24个数值涉及的数据文件可能很大可能达到几百MB的级别因为其中的冗余数据太多了其他的经纬度格点其他高度的数据我们都是不关心的。本地agent在读取数据时如果数据采用特定的文件格式比如NetCDF可以只读取一个大文件中的一部分起到优化效果。
image.png | center | 743x558 这种模式的缺点也很明显
人为的将不同类型的数据存储在不同机器上需要解决数据可靠性和可用性的问题带来很大的维护负担。 数据种类和存储节点的对应关系是确定好的在新增或者删减数据时需要人为进行调整可扩展性较差。 为了优化查询性能必须开发一个agent程序启动在存储节点上。这个程序负责从数据文件中筛选出符合条件的一小部分数据假设数据文件采用NetCDF格式存储本地agent可以只读取文件中的一部分内容减少读盘的延迟。这种定制化的方案带来了一些开发维护成本同时这个agent也难以集成到现有的成熟的分布式存储系统中即这是一种基于本地文件系统和NetCDF文件格式的特定优化。 使用表格存储进行气象数据存储和查询的方案
表格存储(TableStore)是一款云上的分布式NoSQL数据存储服务支持高并发的数据读写和PB级别的数据存储能力提供毫秒级的读取性能。通过上面对传统方案的分析我们对海量气象数据的存储和查询已经有了一定认识那么表格存储如何解决其中的问题呢
首先表格存储是一种分布式NoSQL存储服务数据本身会分散到不同的机器上单集群可以支撑10PB的数据规模这就解决了存储的问题。
其次表格存储支持快速的单行查询和范围查询从数据模型上可以认为是一个巨大的SortedMap。即使表中拥有几百亿、几万亿行数据单行数据的定位速度并不会下降这就解决了文件系统在大量小文件时定位慢的问题。
从查询的角度来看越高效准确的定位到数据读取以及返回的冗余数据越少查询效率越高。那么我们可以把表格存储中一行或者一列的数据大小控制在一个恰当的粒度以此来满足各种查询方式的需求。实践中已经验证这种方式可以带来非常优秀的性能。下面具体来看存储方案的设计。
存储方案设计
表格存储的数据模型如下图所示每行数据分为主键和属性列通过主键来标示一行数据。 image.png | center | 701x362 下文中的方案重点来讲主键列和属性列如何设计并且如何实现两种典型的查询方式 即“查询一个经纬度平面的格点数据”和“查询某个格点的时间序列数据”。
方案一
对于气象中的某种模式数据Data我们暂且用下面的方式表示
Data F(物理量、起报时间、高度、预报时效、经度、纬度)
我们可以把前四个维度作为主键(PrimaryKey简称PK)后两个维度的数据作为属性列保存表示为
Row(物理量、起报时间、高度、预报时效) F(经度、维度)
PK (物理量、起报时间、高度、预报时效) Data F(经度、维度) 二维的经纬度格点数据(我们采用binary格式存储在属性列中) Meta 一些其他的辅助信息比如数据是否压缩等等。
那么 Row(PK) (Data, Meta, 其他属性列) Table SortedMap(Rows) 如下图所示。 这种方式下对于查询“一个经纬度平面的格点数据”, 那么只需要把物理量、起报时间、高度、预报时效这些信息拼成主键然后通过表格存储的GetRow接口读取一行数据即可如果一次要获取多个经纬度平面的数据可以通过BatchGetRow接口一次读取多行数据。读取完成后客户端需要解析出属性列中存储的二进制数据因为气象数据的压缩率较高这种方式下推荐对数据进行压缩。
设计这种方案时很重要的考虑因素是一行存储多大粒度的数据。这里一行只存储一个经纬度平面的数据以2880 x 570的float数据为例为例数据量为2880 x 570 x 46.3MB数据压缩后数据量更小。这个粒度对于存储和查询都较为合适而且气象中大部分查询请求也是读取一个平面。
但是这种方案有一个缺点对于“查询某个格点的时间序列数据”必须先读取出一个完整的经纬度格点数据然后筛选出所需的一个格点。因为获取的冗余数据太多所以对这个查询场景不能提供很好的性能。由此我们引出方案二。
方案二
为了满足“查询某个格点的时间序列数据”的需求我们想到通过对数据再切分来减小数据的粒度缩小冗余数据的查询和返回。为了缩小数据的粒度我们把一行中的一个经纬度平面再切分为100个方格存储在100个属性列中。下图是一个切分的例子我们把一个481 x 641的平面切分成很多49 x 65的方格每个方格的数据保存为一列列名为Data_x_y, x, y是这个方格的左上角坐标。
此时 Row(PK) (Data_x1_y1, Data_x2_y2, Data_x3_y3, … , Meta)
image.png | center | 704x373
切分示意图如下这种方式下对于“查询某个格点的时间序列数据”我们先根据切分方式算出这个格点落在哪个属性列中然后设置只读取该属性列然后使用BatchGetRow接口批量读取不同预报时效的数据即可获取并筛选出“这个格点的时间序列数据”。相比方案一这里读取的数据量缩小了100倍性能得到了巨大的提升。 如果读取的不是某个格点而是读取一部分区域的数据。那么可以先算出这个区域涉及哪些小方格只读取这些小方格的数据也可以大量的减少冗余数据的读取。
如果需要读取整个平面方案一和方案二都可以满足。方案一的好处在于数据放在一起可以获得较好的压缩率因此业务上可以考虑综合使用方案一和方案二还是只使用方案二。
方案优缺点
采用表格存储的方案之后新的查询方式如下图所示
image.png | center | 700x421 这种方案的优点可以总结一下
高可靠和高可用保障可维护性和可扩展性强。采用成熟的分布式NoSQL系统相比人为的管理多台服务器的文件系统可靠性和可用性有巨大提升。可扩展性强针对不同类型的模式数据都可以方便的纳入这一系统中来。 弹性的存储和计算资源。使用公共云上的表格存储服务只需要按量付费大大的节约了成本并且可以应对短期的容量或访问高峰。 性能优异架构简单。实际测试中上述方案的性能远优于传统方案。同时传统方案需要在服务端启动一个agent来优化读取性能在表格存储的方案中已经不再需要开发类似的agent架构更加简单分层清晰。 这种方案的缺点在于气象系统的开发工程师需要对分布式NoSQL较为了解特别是在进行方案二的实现时需要对数据进行切分有一些开发上的复杂度。
作者亦征
