User location based weather live data service interface system

Abstract

The application provides a user position-based weather live data service interface system, which is based on a grid data block processing and fast query data storage model, adopts a micro-service application mode to design and implement a user position-based weather live data service interface, improves data service timeliness and user concurrency, and provides technical support for solving the problem that weather live data published by different applications at the same time and at the same position are inconsistent. The weather live data is provided to 54 applications of national meteorological departments, and the monthly access volume exceeds 100 million, and the high concurrency, high timeliness and high availability of the system are verified.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of meteorological service, and particularly relates to a weather real-time data service interface system based on user positions. BACKGROUND

[0002] During the period of the 13th Five-Year Plan, the meteorological observation and prediction capacity of China has been steadily improved. In 2017, the weather prediction business of the China Meteorological Administration was upgraded from the original site prediction to the intelligent grid prediction, and a series of multi-source data fusion weather real-time grid products (including air temperature, precipitation, humidity, wind, total cloud cover, visibility, etc.) have been applied in the business. However, the problem of unbalanced and insufficient supply in meteorological service is still prominent.

[0003] The public meteorological service and the meteorological service of the transportation and tourism industries have a strong demand for fine weather real-time products. The service mode based on site real-time observation data cannot meet the needs. In order to meet the needs of the public meteorological service and the meteorological service of the transportation and tourism industries for fine weather real-time products, multi-source data fusion technology and other methods are used to generate high-resolution real-time grid data (including air temperature, precipitation, humidity, wind, total cloud cover, visibility, etc.). Due to the differences in data acquisition time and fusion technology of various units, there is a problem that the real-time data of the same time and the same place published by different units is inconsistent when providing services to users. At present, more than 60,000 site data or 5KM grid data are mainly used to provide weather real-time data services to users. Due to the low resolution, there is a large difference between the data service accuracy and the actual situation.

[0004] In addition, according to the current distribution of meteorological data stations and the development status of fusion technology, the real-time service accuracy is determined to be 1KM (corresponding to the geographical coordinate system about 0.01°), and the target position latest fine weather real-time element data service is provided according to the geographical position information of the user. According to the administrative boundaries, main cities and population distribution of China, the coverage range of the weather real-time element data grid definition is 0-60° north latitude and 70-140° east longitude, the spatial resolution is 0.01°, and one grid data file is about 120MB. For non-continuous meteorological elements such as precipitation and weather phenomena based on precipitation, air temperature and other elements, the grid data is updated once every 5 minutes, and the continuous meteorological elements such as air temperature and relative humidity are updated once every hour. The existing meteorological real-time element data storage and query positioning usually use relational databases or in-memory databases, which have problems such as insufficient concurrent support capability, data storage and update delay, etc., which greatly reduces the timeliness of data service. SUMMARY

[0005] In view of the above problems, the application provides a weather live data service interface system based on user position using resources of public cloud for storage and data service provision, and proposes a block storage and query positioning method for balancing high timeliness of data storage and query, which is applied to the weather live data service interface system for position service.

[0006] The technical solution for achieving the object of the application is:

[0007] A weather live data service interface system based on user position, characterized by comprising:

[0008] A resource layer comprising cloud server ECS, table storage Tablestore, cloud database MySQL, message service Kafka, load balancing SLB, special network VPC and cloud resolution DNS, used for providing infrastructure service;

[0009] A business layer comprising weather live data storage and application service program related to weather live data, used for providing application service to user layer;

[0010] A user layer comprising third-party application, used for acquiring service published by business layer through Restful mode. Further, the weather live data is derived from site observation data and weather live grid data; the weather live grid data comprises several meteorological service elements and is stored in table type database using block storage method and is queried through block query positioning method.

[0011] The application service program is developed using SpringBoot micro service, comprising interface user registration and authentication service, weather live data service interface, data receiving service and data resolution and processing.

[0012] Further, the weather live grid data adopts binary grid data storage mode, uses big tail for byte order, and each element is taken as a grid file for data exchange.

[0013] Further, the block storage method of weather live grid data comprises the following steps:

[0014] Step 1: store meteorological service element of weather live grid data as a three-dimensional model, wherein x dimension is longitude, y is latitude, and z is meteorological service element, and x and y together constitute grid data of a certain meteorological service element;

[0015] Step 2: integrate weather live grid data according to longitude direction, integrate each block at 1° resolution with 0.01° resolution, so that each block contains 100 points of meteorological value of a certain meteorological service element;

[0016] Step 3: store all meteorological service element data in a data table, and take the dimension of the weather live grid data as a partition key, and take the meteorological service element as a second primary key, and the two form the query primary key of the data table;

[0017] Step 4: define 70 attribute columns according to the area coverage of the weather live grid data, and each attribute column is a block;

[0018] Step 5: split the weather live grid data into a 70*400 byte array for each row of data, and store the data into the data table;

[0019] Step 6: for the site observation data, according to the latitude and longitude information of the site, the corresponding meteorological service element value is superimposed on the grid to replace the value of the corresponding grid.

[0020] Further, the block query positioning method of the weather live grid data comprises:

[0021] S1: according to the position information of the user, calculate the nearest latitude and longitude value in the 0.01° grid, and use the latitude value and the integer value of the longitude to obtain the nearest data block of the user's position corresponding to the weather live grid data point;

[0022] S2: through the query primary key, locate the data block of the row and column of the meteorological service element of the nearest weather live data of the user's position to be queried;

[0023] S3: through the decimal point value of the longitude, four bytes are taken out from the binary data block by byte displacement, and converted into specific numerical values.

[0024] Firstly, based on the real-time updated site observation data and the high-frequency updated 1KM weather live grid data, the distributed table storage is used to define the China regional weather live grid data block storage model and query positioning method, which can solve the problems of high data storage or update delay, insufficient user high-concurrency data query ability and the like, and is beneficial to improving the service timeliness of the weather live data, and provides technical support for solving the consistency problem of the weather live data obtained by different applications at the same time and at the same position.

[0025] Secondly, the application uses Aliyun as the infrastructure service, including cloud server ECS, table storage Tablestore, cloud database MySQL, message service Kafka, load balancing SLB, special network VPC, cloud resolution DNS and the like, which is beneficial to the expansion of system capacity and the operation and maintenance cost of basic resources when more users are concurrent in the future. DETAILED DESCRIPTION

[0026] Figure 1The architecture diagram of the system of the present application;

[0027] Figure 2 The schematic diagram of weather live data update frequency;

[0028] Figure 3 The weather live data processing and service flow;

[0029] Figure 4 The flowchart of data query access;

[0030] Figure 5 The flowchart of data signature authentication implementation;

[0031] Figure 6 The flowchart of data processing implementation;

[0032] Figure 7 The live data service business operation monitoring;

[0033] Figure 8 The live service interface concurrent performance test result;

[0034] Figure 9 The application effect of China Weather APP;

[0035] Figure 10 The application effect of China Weather APPlet;

[0036] Figure 11 The data service interface calling condition; DETAILED DESCRIPTION

[0037] In order to make the ordinary skilled in the art better understand the technical scheme of the present application, the technical scheme of the present application will be further described below in combination with the drawings and examples.

[0038] The present application proposes a weather live data service interface system based on user location, which is constructed by using Aliyun resources, including resource layer, business layer and user layer, as shown in the accompanying Figure 1

[0039] The resource layer is used to provide cloud server ECS, table storage Tablestore, cloud database MySQL, message service Kafka, load balancing SLB, special network VPC and cloud resolution DNS resources.

[0040] The business layer contains weather live data storage and application service program related to weather live data, which is provided with deployment and operation support by the resource layer, and is used to provide application service to the user layer.

[0041] ​The weather live data includes user information, live grid data and user behavior information and related profiles, which are stored by using table storage and cloud database;

[0042] The application service program is developed by using SpringBoot for micro service, and includes interface user registration and authentication service, weather live data service interface, data receiving service, data analysis and processing and running monitoring module.

[0043] The user layer is a third-party application, including mobile APP, applet or webpage, which is used for obtaining the service published by the business layer through the Restful mode, and developing the application and data calling of the weather live data service interface account.

[0044] The key technologies involved in the application include:

[0045] 1. Weather live data

[0046] The weather live data is derived from site observation data and weather live grid data, and includes many meteorological service elements, as shown in Table 1. The weather live meteorological elements mainly include the commonly used elements that the public is concerned about, such as precipitation (including rolling 1 hour, 3 hours, 6 hours, 12 hours and 24 hours cumulative precipitation), air temperature, wind speed and wind direction.

[0047] Table 1 Description of weather live meteorological service elements

[0048]

[0049]

[0050] The site observation data is observed by more than 60,000 observation stations of the meteorological department every minute, and the precipitation elements are observed and uploaded in real time. Other elements are uploaded once every 5-10 minutes at the station, and are stored in the meteorological big data cloud platform distributed database after analysis. According to the requirements of meteorological data sharing, the real-time site data is processed into site data products with a location accuracy of 0.01° in the special cloud according to the service strategy, and a file is generated every minute, which is used for exchange between the special cloud and the public cloud. The file is organized to store one element information of a station in each row, and different information is separated by English comma, including station number, observation time, longitude, latitude, meteorological element and observation value. For example, the observation value of air temperature of Beijing south suburb station (number 54511) at 12:05 on December 31, 2021 is 2.2°, which is represented as "54511, 20211231120500, 116.47, 39.81, TEM, 2.2".

[0051] The real-time weather grid data is created by fusing data from multiple sources, including ground, satellite, radar, and DEM. The spatial resolution is 0.01°, and the coverage area spans from 0°N to 60°N and from 70°E to 140°E. Each grid data file is approximately 120MB. Based on the characteristics of meteorological elements, combined with the frequency of meteorological observations, processing and computing capabilities, and public sensitivity to weather (sunny / rainy), for discontinuous meteorological elements such as precipitation and weather phenomena derived from precipitation and temperature, the grid data is updated every 5 minutes. Continuous meteorological elements such as temperature and relative humidity are updated hourly. Figure 2 As shown.

[0052] Based on the data coverage and resolution, a single weather element at one time point contains 42 million points. For user location services, the fastest way to query data is to store one record per 0.01-degree grid point. At a MySQL database ingestion rate of 100,000 records per second, it would take 420 seconds (7 minutes) to complete the data ingestion, severely impacting data real-time performance. To balance the high timeliness of data ingestion and querying, the weather real-time data service interface system of this invention utilizes a method of block storage and query positioning for weather real-time meteorological service element data. By dividing and storing meteorological service elements into blocks, the efficiency of database queries is improved, achieving good application results.

[0053] In this invention, the weather grid data is stored in a custom binary grid data storage mode during data exchange, with big-endian byte order. Each meteorological element data is exchanged as a grid file. The specific structure of the weather grid data file is shown in Table 2.

[0054] Table 2. Description of Weather Real-Time Grid Data File Structure

[0055] Segmentation Data type Data description Meteorological element Character type 16 bytes, element code in Table 1 Observation time Character type 14 bytes, format yyyymmddHHmiss Data type Integer type 0 represents integer type, 1 represents floating point type, and 2 represents double precision floating point type Data range Floating point array Array length is 4, and the first is the northernmost latitude, the second is the minimum east longitude, the third is the latitude grid interval, and the fourth is the longitude grid interval Data size Integer array Array length is 2, and the first is the column number and the second is the row number Data block Byte array Data block, stored in the longitude direction first

[0056] 2. Data Processing and Service Process

[0057] Real-time weather data is rapidly pushed to the public cloud after being generated on the private cloud. Data processing services then integrate and process the site and grid files before writing them into the database. External applications can access this data via service interfaces. The process is shown in the attached diagram. Figure 3 As shown.

[0058] 3. Meteorological element data is stored in blocks and its query location is optimized.

[0059] This invention stores and queries real-time weather grid data in blocks. In the database, the real-time weather grid data can be viewed as a three-dimensional model, where x and y represent the grid data of a certain element (where x is longitude and y is latitude), and z represents the meteorological elements in Table 1. The main focus is on aggregating and dividing x into blocks.

[0060] (1) Data block design

[0061] The table-type database (representative products include Cassandra, Ali Ots, etc.) is selected as the medium for storing weather live meteorological element data. The data storage table mainly consists of a primary key (the first is a partition key) and an attribute column. Each data has a life cycle.

[0062] In order to improve the timeliness of data storage or updating, facilitate data query positioning and data aggregation, the weather live meteorological service elements are integrated by data block in the longitude direction. The data is integrated by 1° block, and the resolution is 0.01°. That is, each block contains 100 points of a certain element corresponding to the meteorological value. In the database table, in order to facilitate multi-element combined query, all elements are stored in one data table. The latitude is used as the primary key partition column, and the records are hashed partitioned by latitude to multiple data storage nodes. The meteorological elements (temperature, precipitation, humidity, wind, total cloud cover, visibility, etc.) are used as the second primary key, which is of character type. The attribute is the block data identifier. One block is one attribute column. According to the area coverage range (longitude 70-140 degrees, China regional boundary) of the weather live grid data, 70 attribute columns are defined. The attribute column data is stored in binary value (one float occupies 4 bytes, and 100 values are 400 bytes). See Table 3 for an example of block data table storage design.

[0063] Table 3 Design of Meteorological Element Data Block Data Table

[0064]

[0065] (2) Block data writing design

[0066] Based on the above data block design, the weather live grid data is split into a 70*400 byte array for each row of data according to the block method. Then, combined with the block table structure, a data insertion SQL is formed to write data into the above data table. In the data writing program, multi-threading concurrency technology can be used to divide the data file into N parts according to the latitude direction. Each thread is responsible for one part. The grid file is read and written row by row according to the writing method of each row.

[0067] (3) Block data query positioning design

[0068] During data query access, the system first calculates the nearest latitude and longitude values ​​in the 0.01° grid based on the user's location information. Using the latitude and longitude integer values, it obtains the nearest data point block (100 points) in the weather data grid corresponding to the user's location. Then, using the longitude decimal value, it extracts the corresponding four bytes from the binary data block using byte shifting and converts them into a specific numerical value, which is the weather data service value for the user's location. For example, to retrieve the weather phenomenon for user location point A (71.5932, 0.0342) with longitude 71.5932° and latitude 0.0342°, the nearest location in the 0.01° grid is calculated to be B (71.59, 0.03). Then, by querying the primary key, it locates the row containing the data at latitude 0.03°, finds the data block in the attribute column lon71 containing longitude 71.59°, and then uses byte shifting to find the specific numerical value corresponding to 0.59° from the binary data block, as shown in the attached diagram. Figure 4 As shown.

[0069] (4) Site observation data update design

[0070] When updating data, based on the latitude and longitude information of the station observation data, first locate and find the value of the corresponding data block (100 values), then replace the value of the corresponding location point, and finally update the corresponding value of the data block in the data table as a whole;

[0071] 4. Spring Boot Microservice Architecture

[0072] The concept of microservices was first proposed in 2014 by Martin Fowler and James Lewis. It defines microservices as small services comprised of a single application, each with its own process and lightweight handling. Microservice architecture is a technology for deploying applications and services in the cloud. It involves fine-grainedly decomposing complex, bloated monolithic applications into services, with each service packaged and deployed independently. Adopting a microservice architecture simplifies deployment, management, and service delivery. [9] .

[0073] Spring Boot, built upon Spring 4.0, inherits the excellent features of the original Spring framework and simplifies the entire process of building and developing Spring applications. Two crucial strategies within the Spring Boot framework are "out-of-the-box" and "convention over configuration." These free developers from complex configuration and dependency management tasks, allowing them to focus more on business logic. Furthermore, the software design paradigm of adding information to the structure reduces significant XML configuration and automates code compilation, testing, and packaging.

[0074] In this system, the concept of microservices is used for user authentication, service interface, user registration, and other modules. SpringBoot is used for development to handle system function upgrades and optimization on demand and service dynamic expansion in high concurrency.

[0075] 5. Data service security authentication design

[0076] To solve the problems of account information leakage and API request malicious attacks when the system live data interface service is used, the asymmetric encryption method is used for signature authentication to strengthen user data transmission security and improve the ability of weather live data service interface to resist attacks. AccessKeyId (AK for short) is used to identify users, and SecretAccessKey (SK for short) is a key used by users to encrypt authentication strings and by the server to verify authentication strings. The AK / SK signature authentication mechanism is as follows: after the backend service receives the user's request, it will use the SK corresponding to the AK to generate an authentication string (sign) using the same authentication mechanism as the application side, and compare it with the authentication string included in the user's request. If the authentication strings are the same, the system considers that the user has the right to perform related operations; if the authentication strings are different, the system returns an error code. The implementation process is as follows Figure 5 .

[0077] In the live service interface, the AK / SK signature authentication parameter signature consists of request identity, timestamp, and random number, and the signature method has three parts. The request identity is the unique user ID (AK) and the key (SK) created by the user when applying for a user account; the timestamp is the millisecond value of the time when the user submits the request relative to the reference time, and the timestamp is set to 15 minutes, if the request exceeds this time range, it will be rejected, the random number is a random string generated by the user when submitting the request, to prevent identity forgery and malicious attacks; the signature method uses the authentication string of the business request parameters, request identity ID, and timestamp and random number, and performs MD5 encryption to generate a signature value.

[0078] In addition, to enhance service security, user IP white list, request flow control, and other authentication security designs are added on the server side, and the HTTPS protocol is used for data transmission.

[0079] 6. Apache Camel rule engine technology

[0080] Apache Camel is a very powerful rule-based routing and mediation engine providing an Enterprise Integration Patterns (EIP) implementation based on a simple and easy to use API allowing you to configure routing and mediation rules using a very simple and easy to use API.

[0081] Apache Camel provides a set of message interaction model for application integration scenarios, and accesses third-party systems through components, and currently provides more than 300 components to access HTTP, File, JMS, TCP, WebSocket and other transmission protocols. Apache Camel provides message routing, message conversion and other domain-specific languages according to the characteristics of enterprise application integration patterns (EIP), greatly reducing the development difficulty of integrated applications. Compared with the traditional enterprise integration service bus (ESB), the core library of Apache Camel is very small, and can be easily integrated with other systems. Camel is composed of an endpoint, a route, an enterprise integration pattern (EIP) and a running context (Camel Context). The route contains at least three elements, an input source, a processor and an output target.

[0082] The application uses the Apache Camel framework as a data processing integration framework, obtains data on cloud messages through file protocol from the weather live data file processed and produced in the private cloud, and writes the data into the table storage of the Ali cloud for subsequent application, so that the rule engine technology is used to reduce the coupling between services and improve the processing timeliness.

[0083] 7. Specific function implementation

[0084] (1) Data processing and storage

[0085] Data processing mainly implements the analysis, processing and data storage of the site data files and live grid files pushed by the proprietary cloud to the Ali cloud. The data processing uses the Apache Camel integration framework, and uses the file protocol to customize two RouteBuilder classes, as shown in Table 5. Among them, SurfProcessRouteBuilder is used to configure the parsing of files from the site data file directory / data / SURF to write to the database, and GridProcessRouteBuilder is used to configure the parsing of grid files from the directory / data / GRID to write to the database. The processed files are placed in the / data / Trush directory, which is cleared after 3 days according to the business management regulations. The processing function is started by the start() method of CamelContext, and the customized RouteBuilder is added to the route by the addRoutes function.

[0086] Table 5 Customized live data processing RouteBul ider class description

[0087]

[0088] When processing site data files, read all sites in the file, group and sort the longitude value according to the integer value, and facilitate batch grid point replacement operations. When processing grid files, use a multi-threaded batch submission mode, divide the grid data into 10 equal parts according to the latitude direction, and each thread processes a block of data to improve data storage efficiency. The processing flow is shown in FIG. 2. Figure 6

[0089] (2) Location-based service interface

[0090] According to business needs, two application scenarios of the interface are provided: an application scenario of obtaining data according to a location "point" and an application scenario of obtaining data according to a "trajectory line". According to the latitude and longitude information of the point or line, the temperature, relative humidity, wind speed, wind direction, weather phenomenon, visibility, total cloud cover, sea surface temperature and precipitation and other meteorological element data are obtained. The line is composed of multiple points, and in the interface implementation, the key points on the line are listed once to provide services.

[0091] The core of the location service interface is to quickly obtain weather live element information from the table storage according to the location point requested by the user. Since the live grid data uses an equal latitude and longitude organization method, each grid point is spaced 0.01°, and when data is obtained, the user's location point is first located to the corresponding grid point according to the nearest neighbor method processing method, and then the data value is quickly queried from the database.

[0092] ​The position service interface is published in a RESTful style, and the longitude and latitude information of the current position obtained by using the mobile phone positioning function is used as one of the request parameters of the service interface. According to the standard of the weather data service interface, the request parameter design of the weather live data service interface based on user position is shown in Table 6. The data return result is encapsulated in a json format, which includes the calling state information and the weather live data group. The calling state includes the service return code, running time, search element information and unit, and the weather live data includes the longitude and latitude information, data update time, weather element corresponding value, etc.

[0093] Table 6 Weather live data position service interface parameters

[0094]

[0095]

[0096] (3) User authentication and behavior record

[0097] In order to improve the quality of data service, the weather live data needs to be authenticated before it can be obtained, and the information of each request of the user is recorded for subsequent analysis and system improvement.

[0098] The user authentication information includes user account, password, running server IP, and unit and contact information. After receiving the user request, the service parses the request parameters and service source IP, loads the user permission configuration information, verifies the user account and client IP address, and if the matching is successful, the authentication signature value of the request is compared, and after the verification is passed, the data can be accessed.

[0099] The behavior log mainly records the user's request account, initiation time, service execution time, weather live element obtained by the user and returned result state, etc. For each received request, the result state after processing is placed in the Kafka message queue, and a special thread integrates the information in the queue and writes the result into the MySQL database.

[0100] (4) System running monitoring

[0101] Since the weather live data service involves many aspects, including data processing in the special cloud, data processing, storage and service interface on the Ali cloud, in order to facilitate system operation and fault point troubleshooting, the running monitoring is integrated based on the meteorological business comprehensive monitoring system, including resource monitoring, application service monitoring, data flow monitoring, etc. on the Ali cloud. The running monitoring interface is shown in the attached Figure 7 .

[0102] Embodiment

[0103] In order to further verify the effect of the system, based on the Aliyun resources for development, and in the Aliyun deployment and running the system.

[0104] 1, operating environment

[0105] Use 5 cloud server ECS (configuration: 8C, 16GB memory, local disk 60GB), in which the weather live data service interface deployment (including user registration service, user authentication service) in 3 ECS, data processing program deployment using 2 ECS, form high availability. Other middleware rental cloud resource service, such as using load balancing SLB product for application load, using cloud resolution DNS method to provide user domain name access, etc.

[0106] According to the online business demand peak value needs to support 200000 times per second access, according to the TPS (transactions per second) = concurrent number / average response time formula, before online using Jmeter tool for system performance test, to evaluate the amount of resources to meet business needs, client and server for gigabit network environment, test results show that 3 ECS can meet the business needs.

[0107] 2, concurrent and high availability test

[0108] In the live data update and warehousing, a single live grid data file (contains 4200 million points), using 10 threads concurrent warehousing average time in 4 seconds, a single site data real-time update average time in 0.015 seconds.

[0109] Weather live data service interface concurrent performance test mainly simulates user based on geographic location to obtain common weather elements, using Jmeter tool to make test script, script user geographic location for China region random point. TPS formula shows that high time efficiency and high concurrency are mutually limited, when testing need to find the optimal time efficiency of service interface.

[0110] Test results show that a single node in 1000 concurrent can respond to the number of transactions to reach the peak of 71,000 per second, the average response time is 14 milliseconds. Increase to 3 nodes, concurrent to 3000 can respond to the number of transactions to reach the peak of 214,000 per second, the average response time is 14 milliseconds. In addition, with the increase of the number of nodes, the number of supported access quantity presents quasi linear growth, subsequent business access quantity increase can be expanded by increasing the service interface node. Concurrent transaction response test results as shown in Figure 8 .

[0111] When providing services to the outside, the domain name is used for access, and load balancing is used to route the three nodes providing services. The fault detection function is configured, and when the node fails, the abnormal node is automatically removed, and the request is transferred to the normal node. During testing, the process of the weather live data service interface of any one of the three nodes was randomly stopped. The results show that users can normally obtain weather live data, and the system has high availability.

[0112] 3. Data service situation

[0113] After the system goes online, users apply for use through the China Meteorological Data Network. As of the end of 2021, the system has provided weather live data services for 54 meteorological business units nationwide (including APPs and mini-programs) developed applications (including APPs and mini-programs). Among them, there are 8 national-level, 12 provincial-level, and 34 city-county-level applications, realizing the unity of weather live data at the same location and the same time for different applications. In terms of timeliness, the data delay is within 2 minutes when there is an observation station within a 1KM range, and the data delay is within 5 minutes in areas without observation stations. For example, after China Meteorology and China Weather access the weather live data service interface, users in the courtyard of the China Meteorological Administration (within a 1KM range of an observation station) obtain live data with a delay of 2 minutes (data at 16:17 is updated at 16:15), and the commonly used meteorological elements (temperature, humidity, wind, etc.) remain unified. The APPs and mini-programs developed using the interface system are shown in Figure 9 and Figure 10 With the growth of users, the access volume supported by the system presents a linear growth every month. In August 2021, the monthly access volume exceeded 50 million, and in December 2021, the monthly access volume exceeded 100 million. The interface call situation is shown in Figure 11 .

[0114] The contents not described in detail in the specification belong to the prior art known to those skilled in the art. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions recorded in the foregoing embodiments or make equivalent replacements to some technical features, and any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A user location based weather live data service interface system characterized by, The system comprises: a resource layer including cloud servers ECS, table storage Tablestore, cloud databases MySQL, message services Kafka, load balancing SLB, private networks VPC, and cloud resolution DNS, for providing infrastructure services; a business layer including weather live data storage and application service programs related to weather live data, for providing application services to the user layer; a user layer including third-party applications, for obtaining services published by the business layer through a Restful mode; wherein the weather live data is derived from site observation data and weather live grid data; the weather live grid data includes a plurality of meteorological service elements and is stored in a table-type database by using a block storage method and is queried by using a block query positioning method; the application service programs are developed by using SpringBoot to implement microservices, including interface user registration and authentication services, weather live data service interfaces, data receiving services, and data analysis and processing; the block storage method of the weather live grid data comprises the following steps: Step 1: defining the meteorological service elements of the weather live grid data as a three-dimensional model, wherein the x dimension is longitude, the y dimension is latitude, and the z dimension is a meteorological service element, and the x and y dimensions together constitute the grid data of a certain meteorological service element; Step 2: integrating the weather live grid data according to the longitude direction, with a resolution of 0.01 degrees, and integrating by 1°, so that each block contains 100 points of a meteorological value corresponding to a certain meteorological service element; Step 3: storing all meteorological service element data in a data table, and taking the dimensions of the weather live grid data as the partition key and the meteorological service elements as the second primary key, which together constitute the query primary key of the data table; Step 4: defining 70 attribute columns according to the area coverage of the weather live grid data, and each attribute column is a block; Step 5: splitting the weather live grid data into a 70*400 byte array for each row of data, and storing the data into the data table; Step 6: for the site observation data, the corresponding meteorological service element value is superimposed on the grid according to the site longitude and latitude information, replacing the corresponding grid value.

2. A user location based weather live data service interface system as claimed in claim 1, wherein, The weather live grid data adopts a binary grid data storage mode, and the byte order uses a large tail, and each element is taken as a grid file for data exchange.

3. A user location based weather live data service interface system as claimed in claim 2, wherein, The block query positioning method of the weather live grid data comprises: S1: calculating the nearest longitude and latitude values of a user in a 0.01° grid according to the user's location information, and obtaining the nearest data point block of the weather live grid corresponding to the user's location by using the latitude value and the integer value of the longitude; S2: positioning the data block of the meteorological service element of the nearest weather live data of the user's location to be queried by querying the primary key to the row and column of the data block; S3: taking the four bytes corresponding to the decimal point value of the longitude from the binary data block by using byte displacement, and converting them into specific numerical values.

Images