WO2018014582A1 - 保单数据处理方法、装置、服务器和存储介质 - Google Patents

保单数据处理方法、装置、服务器和存储介质 Download PDF

Info

Publication number
WO2018014582A1
WO2018014582A1 PCT/CN2017/078356 CN2017078356W WO2018014582A1 WO 2018014582 A1 WO2018014582 A1 WO 2018014582A1 CN 2017078356 W CN2017078356 W CN 2017078356W WO 2018014582 A1 WO2018014582 A1 WO 2018014582A1
Authority
WO
WIPO (PCT)
Prior art keywords
split
task
target database
log
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2017/078356
Other languages
English (en)
French (fr)
Inventor
刘永凡
罗志权
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Publication of WO2018014582A1 publication Critical patent/WO2018014582A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance

Definitions

  • the present application relates to the field of computer technology, and in particular, to a policy data processing method, apparatus, server, and storage medium.
  • a policy data processing method, apparatus, server, and storage medium are provided.
  • a policy data processing method comprising:
  • the query is performed in the corresponding partition according to the dimension information, and the query result is obtained, and the query result is returned to the terminal, so that the terminal performs monthly node processing according to the query result.
  • a policy data processing device comprising:
  • a judging module configured to determine whether the batch processing in the plurality of source databases is completed when the synchronization time is reached
  • a synchronization module configured to: if the batch processing in the multiple source databases is completed, trigger a synchronous operation between the source database and the target database, write policy data in the multiple source databases into the target database, and obtain a policy in the target database. a data summary table corresponding to the data;
  • a splitting module configured to split the data summary table into partitions of multiple dimensions in the target database
  • a receiving module configured to receive a data query instruction sent by the terminal, where the query instruction carries dimension information
  • a query module configured to perform a query in the corresponding partition according to the dimension information, to obtain a query result
  • a sending module configured to return the query result to the terminal, so that the terminal performs monthly node processing according to the query result.
  • a server comprising a memory and a processor, the memory storing computer executable instructions, the computer executable instructions being executed by the processor, such that the processor performs the following steps:
  • the query is performed in the corresponding partition according to the dimension information, and the query result is obtained, and the query result is returned to the terminal, so that the terminal performs monthly node processing according to the query result.
  • One or more non-volatile readable storage media storing computer-executable instructions, when executed by one or more processors, cause the one or more processors to perform the following steps:
  • the query is performed in the corresponding partition according to the dimension information, and the query result is obtained, and the query result is returned to the terminal, so that the terminal performs monthly node processing according to the query result.
  • FIG. 1 is an application scenario diagram of a policy data processing method in an embodiment
  • FIG. 2 is a flow chart of a method for processing policy data in an embodiment
  • Figure 3 is a block diagram of a server in one embodiment
  • Figure 4 is a block diagram of a policy data processing apparatus in an embodiment
  • Figure 5 is a block diagram of a policy data processing apparatus in another embodiment.
  • the policy data processing method provided in the embodiment of the present application can be applied to the application scenario shown in FIG. 1 .
  • the terminal 102 and the server 104 are connected through a network.
  • Server 104 runs the job and kettle.
  • the job is configured to synchronize time. When the synchronization time is reached, the job is started and the job is used to determine whether the batch processing in the multiple source databases is completed. If it is completed, the kettle is executed to perform the synchronization operation between the source database and the target database.
  • the policy data in the source database is written into the target database, and the data summary table corresponding to the policy data is obtained in the target database.
  • the server 104 splits the data summary table into partitions of multiple dimensions in the target database.
  • the terminal 102 sends a data query instruction to the server 104, and the server 104 receives the data query instruction, performs a query in the corresponding partition according to the dimension information carried in the query instruction, obtains the query result, and returns the query result to the terminal 102.
  • the terminal 102 performs a monthly knot process based on the result of the query. This makes it possible to provide policy statistics quickly and accurately when performing policy monthly settlement processing.
  • a policy data processing method is provided. It should be understood that although the steps in the flowchart of FIG. 2 are sequentially displayed as indicated by the arrows, these steps are not necessarily in accordance with The order indicated by the arrows is performed in order. Except as explicitly stated herein, the execution of these steps is not strictly limited, and may be performed in other sequences. Moreover, at least some of the steps in FIG. 2 may include a plurality of sub-steps or stages, which are not necessarily performed at the same time, but may be executed at different times, and the order of execution thereof is not necessarily This may be performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of the other steps.
  • the method is applied to the server as an example, and specifically includes the following steps:
  • Step 202 When the synchronization time is reached, it is determined whether the batch processing in the plurality of source databases is completed; if yes, step 204 is performed; otherwise, the batch processing is completed.
  • the job and the kettle are running on the server, and the kettle is working on the kettle platform.
  • the synchronization time is the time set according to the need for the monthly settlement process of the policy. For example, 20:00 on the 1st of each month.
  • the synchronization time can be either working time or non-working time.
  • the job is configured for synchronization time.
  • the server can be a standalone server or a cluster service.
  • determining whether the batch processing in the plurality of databases is completed comprises: starting a job, using a job to obtain a log corresponding to the batch processing; using a job to check a log corresponding to the batch processing, and determining whether the batch processing is performed according to the content recorded in the log carry out.
  • Batch processing refers to policy-guaranteed settlement and policy monthly snapshot snapshot refreshing. Batch operations are performed in multiple source databases and the logs corresponding to the batch are recorded. The progress of the batch execution is recorded in the log.
  • the job is started, the log corresponding to the batch processing is acquired by the job, and the contents of the log record are checked, and the batch processing is checked according to the content of the log record. If the batch processing is not completed, wait for the preset time. For example, wait for 5 minutes, and use the job to obtain the log corresponding to the batch. The log records the execution status of the batch, and thus uses the job to check according to the contents recorded in the log. Whether the batch is complete. Loop through until the job determines that the batch in multiple source databases is complete.
  • Step 204 trigger a synchronization operation between the source database and the target database, write policy data in the plurality of source databases into the target database, and obtain a data summary table corresponding to the policy data in the target database.
  • Policy data in the source database can be stored in the form of a data table.
  • Data tables in multiple source databases can be in the same format.
  • the data sheet includes the policy number, insured and premiums.
  • Import data tables from multiple source databases into the target database using multiple threads The merchant data is processed by the merchant, and the full-scale insertion synchronization operation is performed in the target database, thereby quickly obtaining the data summary table corresponding to the policy data in the target database.
  • the synchronization operation is performed concurrently by multiple threads, which effectively improves the synchronization efficiency of policy data in multiple source databases.
  • Step 206 Split the data summary table into partitions of multiple dimensions in the target database.
  • the data master Since the amount of data in the data master is usually in the order of millions and tens of millions, the data master is too large. It takes too long to perform data query in the data summary table, which also degrades the performance of the target database, which causes the monthly knot processing to be adversely affected.
  • the data summary table is split into partitions of multiple dimensions in the target database. Partitioning refers to splitting the data master table into policy data in the data master table and storing it in multiple locations.
  • the policy data for the post-partition data master is hashed to multiple locations in the database.
  • the server obtains the dimension field in the target database, and splits the data summary table into multiple partitions according to the dimension field.
  • Dimension fields include time and organization. Among them, the time can be one day, one week or one month.
  • the institution can be the identity of the location of the institution.
  • the server can also configure partition thresholds for the amount of data for the partition. For example, the threshold is 10,000.
  • the server splits the data master into multiple partitions based on the dimension field and the partition threshold. For policy data for a dimension that is less than the threshold, a single partition can be constructed.
  • the server can also divide the partition into multiple sub-partitions. For example, the server divides the partition into sub-partitions based on the type of insurance and premiums. Partitioning can effectively reduce the burden on the target database and improve the performance of the target database.
  • Step 208 Receive a data query instruction sent by the terminal, where the query instruction carries dimension information.
  • Step 210 Perform a query in the corresponding partition according to the dimension information, obtain a query result, and return the query result to the terminal, so that the terminal performs monthly node processing according to the query result.
  • the terminal sends a data query instruction to the server, and the query instruction carries the dimension information.
  • One or more dimension fields, such as time and organization, etc., can be included in the dimension information.
  • the server receives the data query instruction, performs a query in the corresponding partition according to the dimension information, and obtains the query result.
  • the server does not need to query in the data summary table, which can effectively improve the query efficiency.
  • the server returns the query result to the terminal, and the terminal performs the policy monthly settlement process according to the query result.
  • the terminal may send a delete instruction to the server, and the server deletes the corresponding partition according to the delete instruction.
  • the server In the traditional method, if the data in the data summary table is deleted, it needs to be deleted line by line. If the deleted data is more, it takes more time.
  • the server can directly obtain the address of the partition, and delete the entire partition, and the operation is simple and fast.
  • the terminal can also export the partitions required for the policy of the monthly settlement from the target database, and does not need to export the policy data one by one in the multiple source databases, thereby further improving the work efficiency of the policy monthly settlement processing.
  • the terminal can also perform data cleaning and data compression on the exported policy data. Data cleaning refers to reviewing and verifying policy data, deleting duplicate policy data, and invalid policy data.
  • Data compression refers to the consolidation and compression of policy data of the same type of insurance.
  • the synchronization time when the synchronization time is reached, if the batch processing in the plurality of source databases has been completed; the synchronization operation of the source database and the target database is triggered. Thereby, the policy data in the plurality of source databases is written into the target database, and the data summary table corresponding to the policy data is obtained in the target database.
  • the target database Through the synchronization of multiple source databases and the target database, a large amount of policy data is written into the target database, thereby ensuring the accuracy of the policy statistics.
  • Split the data master table into partitions of multiple dimensions in the target database. After receiving the data query instruction sent by the terminal, the query can be quickly performed in the partition according to the dimension information carried in the query instruction, thereby enabling the terminal to perform the policy monthly settlement process according to the query result. Therefore, the policy statistics can be quickly and accurately provided during the policy monthly settlement process.
  • the method further includes: recording a synchronization operation log; after the estimated time period, checking the synchronization operation log by using the job, according to the content recorded in the synchronization operation log. Determine whether the synchronization operation is completed; if yes, generate a prompt message that the synchronization operation is completed, and send the prompt information to the terminal.
  • the server records the synchronization operation log while the kettle performs the synchronization operation of the plurality of source databases and the target database.
  • the execution status of the synchronization operation is recorded in the synchronization operation log.
  • the server uses the job to check the synchronization operation log to determine whether the synchronization operation is completed.
  • the estimated time is the time required to perform the synchronization operation based on the historical data and is an empirical value. For example, the estimated time can be 1 hour.
  • the job After the synchronization operation is triggered, if the job determines that the synchronization operation is not completed, the job waits for the preset time, acquires the synchronization operation log again, checks whether the synchronization operation is completed, and executes the loop until the synchronization operation is completed.
  • the server When the job determines that the synchronization operation is completed, the server generates a prompt message that the synchronization operation is completed, and sends the prompt information to the terminal. Therefore, the synchronous operation is monitored in real time, and it is convenient for the terminal to know the execution status of the synchronous operation in time.
  • the step of splitting the data summary table into the partitions of the plurality of dimensions in the target database comprises: running multiple threads in the target database to perform split task concurrently on the data summary table; and recording the split task splitting Divide the log; when multiple threads exit the target database and then perform the split task again, according to the split log, find the corresponding breakpoint task when multiple threads exit, and multiple threads continue to execute the split concurrently from the breakpoint task. Task until the data master is split into partitions of multiple dimensions.
  • the server runs multiple threads in the target database and concurrently performs the splitting task on the data summary table.
  • the server can generate split tasks based on the dimension fields. Different threads execute split tasks for different dimension fields, and the number of threads is less than the number of split tasks. Multiple threads execute the split task concurrently according to the preset logic, which can effectively improve the splitting efficiency of the data summary table.
  • the server records the split log for the data master table split process, and records the split status of the data master table by splitting the log, thereby monitoring the split process. Once an error occurs during the splitting of the data master, the server can quickly locate the location of the error by calling the split log.
  • multiple threads are run in the target database to perform a split task concurrently on the data summary table, and the corresponding split log is recorded.
  • the breakpoint task corresponding to the multiple threads at the time of exit may be searched according to the execution status of the split task, so that multiple threads continue to perform concurrent operations from the breakpoint task. This eliminates the need to perform full replenishment of the split task, and finds the breakpoint task to continue execution at the breakpoint task, effectively preventing the missed execution and mis-execution of the split task, and effectively improving the policy data. Processing efficiency.
  • the step of executing a split task on the data table concurrently by running multiple threads in the target database includes: obtaining a split task identifier in the target database, grouping the split tasks according to the split task identifier, and obtaining more Task groups; assign corresponding threads to task groups; perform split tasks concurrently on task groups through multiple threads.
  • each split task has a unique split task identifier.
  • the server obtains the split task identifier, and groups the split tasks according to the split task identifier to obtain multiple task groups.
  • the server obtains the split task identifier, and groups the split tasks according to the preset number of task groups according to the sequence of split task identifiers to obtain multiple task groups. For example, there are a total of 100 split tasks in the target database. Each split task has a corresponding split task ID. The default task group is 10. Each of the 10 tasks is grouped according to the order of the split task identification, thereby obtaining 10 task groups.
  • the split task identifier may be a task number
  • the server obtains the split task, and obtains the tasks with the same number and tails according to the task number, and divides the split tasks with the same number and tails into one task group to obtain multiple task groups.
  • the server obtains the split task, and obtains the tasks with the same number and tails according to the task number, and divides the split tasks with the same number and tails into one task group to obtain multiple task groups.
  • Each task has a corresponding task number, such as task 1, task 2, and task 100.
  • the server assigns a corresponding thread to each task group. That is to say, each thread will execute the tasks in the corresponding task group fixedly. For example, there are a total of 10 task groups, 10 tasks in each task group, 5 threads running on the server, and the server assigns thread 1 to task group 1 and task group 3, then thread 1 will execute task group 1 fixedly. 10 tasks in the task until the task in task group 1 is completed. Thread 1 executes task group 3 after executing task group 1. Multiple threads perform concurrent operations based on the corresponding task group to process the policy. Since the thread fixedly executes the task corresponding to a certain task identifier, it is easy to find an abnormality occurring during the execution of the task, and the maintenance cost is low.
  • the step of performing a split task concurrently on the task group by using multiple threads includes: multiple threads randomly acquiring the split task and performing concurrent operations; after the split task is executed, the thread randomly acquires the next split The task performs the corresponding operation.
  • the thread does not perform a split task fixedly, and the split task can be randomly acquired to execute.
  • Multiple threads can simultaneously acquire multiple split tasks and perform operations concurrently, and split the data summary table. After the thread has processed a split task, it can randomly acquire the next split task to execute. Because it does not require a thread to perform a split task, it can effectively reduce the time required to perform split tasks.
  • a server in one embodiment, as shown in FIG. 3, includes a processor coupled via a system bus, an internal memory, a non-volatile storage medium, and a network interface.
  • the non-volatile storage medium of the server stores an operating system, a source database, a target database, and computer executable instructions.
  • the policy data of the organization is stored in the source database, and the data summary table corresponding to the policy data is stored in the target database.
  • Computer executable instructions are used to perform a policy data processing method.
  • the server's processor is used to provide computing and control capabilities that support the operation of the entire server.
  • the server's network interface is used to connect to the terminal and communicate with the terminal.
  • the server can be a separate server or a clustered server.
  • FIG. 3 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the server to which the solution of the present application is applied.
  • a particular server may include more or fewer components than shown, or some components may be combined, or have different component arrangements.
  • a policy data processing apparatus including: a determining module 402, a synchronization module 404, a splitting module 406, a receiving module 408, a querying module 410, and a sending module 412, where:
  • the determining module 402 is configured to determine whether the batch processing in the plurality of source databases is completed when the synchronization time is reached.
  • the synchronization module 404 is configured to: if the batch processing in the multiple source databases is completed, trigger a synchronous operation between the source database and the target database, write policy data in the plurality of source databases into the target database, and obtain policy data in the target database. Corresponding data summary table.
  • the splitting module 406 is configured to split the data summary table into partitions of multiple dimensions in the target database.
  • the receiving module 408 is configured to receive a data query instruction sent by the terminal, where the query instruction carries dimension information.
  • the query module 410 is configured to perform a query in the corresponding partition according to the dimension information to obtain a query result.
  • the sending module 412 is configured to return the query result to the terminal, so that the terminal performs monthly node processing according to the query result.
  • the determining module 402 is further configured to start a job, use a job to obtain a log corresponding to the batch processing, use a job to check a log corresponding to the batch processing, and determine whether the batch processing is completed according to the content recorded in the log.
  • the apparatus further includes: a recording module 414, configured to record a synchronization operation log; and the determining module 402 is further configured to: after the estimated time period, use the job to check the synchronization operation log, according to the synchronization operation. The content recorded in the log is used to determine whether the synchronization operation is completed; if yes, the prompt information for completing the synchronization operation is generated; the sending module 412 is further configured to send the prompt information to the terminal.
  • a recording module 414 configured to record a synchronization operation log
  • the determining module 402 is further configured to: after the estimated time period, use the job to check the synchronization operation log, according to the synchronization operation.
  • the content recorded in the log is used to determine whether the synchronization operation is completed; if yes, the prompt information for completing the synchronization operation is generated; the sending module 412 is further configured to send the prompt information to the terminal.
  • the splitting module 406 is further configured to run multiple threads in the target database to perform a split task concurrently on the data summary table; record a split log of the split task; and when multiple threads exit from the target database When the split task is executed again, according to the split log, multiple breakpoint tasks corresponding to multiple threads are exited, and multiple threads continue to execute the split task concurrently from the breakpoint task until the data summary table is split into multiple dimensions. Partition.
  • the splitting module 406 is further configured to obtain a split task identifier in the target database, group the split tasks according to the split task identifier, and obtain multiple task groups; assign a corresponding thread to the task group; Multiple threads perform split tasks concurrently on the task group.
  • the various modules in the policy data processing apparatus described above may be implemented in whole or in part by software, hardware, and combinations thereof.
  • the receiving module 408 is configured to receive a query instruction sent by the terminal through a network interface of the server, and the sending module 412 returns the query result to the terminal through a network interface of the server.
  • the network interface may be an Ethernet card or a wireless network card.
  • the above modules may be embedded in the hardware of the base station or may be stored in the memory of the base station in a software form, so that the processor can call the corresponding operations of the above modules.
  • the processor may be a central processing unit (CPU) or a microprocessor.
  • one or more non-volatile readable storage media having computer-executable instructions that, when executed by one or more processors, cause one or more processors to execute The following steps:
  • the synchronization operation between the source database and the target database is triggered, the policy data in the plurality of source databases is written into the target database, and the data summary table corresponding to the policy data is obtained in the target database;
  • the query is performed in the corresponding partition according to the dimension information, and the query result is obtained, and the query result is returned to the terminal, so that the terminal performs monthly knot processing according to the query result.
  • determining whether the batch processing in the plurality of databases is completed includes: starting a job, acquiring a log corresponding to the batch processing by using a job; and checking a log corresponding to the batch processing by using a job, and determining whether the batch processing is performed according to the content recorded in the log carry out.
  • the one or more processors when the computer executable instructions are executed by one or more processors, the one or more processors further cause the step of: recording a synchronization operation log; after an estimated period of time, checking the synchronization operation log with a job, Determining whether the synchronization operation is completed according to the content recorded in the synchronization operation log; and if so, generating prompt information for completion of the synchronization operation, and transmitting the prompt information to the terminal.
  • splitting the data summary table into multiple dimensions in the target database includes: running multiple threads in the target database to perform split tasks concurrently on the data master table; recording split logs of split tasks And when multiple threads execute the split task after exiting from the target database, find the breakpoint tasks corresponding to the multiple threads at the exit according to the split log, and multiple threads continue to execute the split task concurrently from the breakpoint task. Until the data master is split into partitions of multiple dimensions.
  • running the multiple threads in the target database to perform the splitting task on the data table concurrently includes: obtaining the split task identifier in the target database, grouping the split tasks according to the split task identifier, and obtaining multiple tasks a group; assign a corresponding thread to the task group; and perform a split task concurrently on the task group through multiple threads.
  • the storage medium may be a magnetic disk, an optical disk, or a read-only storage memory (Read-Only) Memory, ROM), etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种保单数据处理方法，包括：当到达同步时间时，判断多个源数据库内的批处理是否完成；若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；在所述目标数据库中将所述数据总表拆分为多个维度的分区；接收终端发送的数据查询指令，所述查询指令中携带了维度信息；及根据所述维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。

Description

保单数据处理方法、装置、服务器和存储介质
本申请要求于 2016 年 07 月 22 日提交中国专利局，申请号为 2016105852562 ，发明名称为'保单数据处理方法和装置'的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
【技术领域】
本申请涉及计算机技术领域，特别是涉及一种保单数据处理方法、装置、服务器和存储介质。
【背景技术】
随着社会的发展，保险已经深入到人们的生活。保险的类型也是越来越多。每个类型的保险对数据准确性的要求都非常高，因此在后台处理的计算逻辑都会很复杂。对于需要进行月结处理的保单来说，由于保单数量较多，月结处理中处理的数据量非常庞大。统计保单数据会耗费较多时间。在进行月结处理时如何快速准确的提供保单统计数据成为目前需要解决的一个技术问题。
【发明内容】
根据本申请的各种实施例，提供一种保单数据处理方法、装置、服务器和存储介质。
一种保单数据处理方法，包括：
当到达同步时间时，判断多个源数据库内的批处理是否完成；
若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
在所述目标数据库中将所述数据总表拆分为多个维度的分区；
接收终端发送的数据查询指令，所述查询指令中携带了维度信息；及
根据所述维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
一种保单数据处理装置，包括：
判断模块，用于当到达同步时间时，判断多个源数据库内的批处理是否完成；
同步模块，用于若多个源数据库内的批处理完成，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
拆分模块，用于在所述目标数据库中将所述数据总表拆分为多个维度的分区；
接收模块，用于接收终端发送的数据查询指令，所述查询指令中携带了维度信息；
查询模块，用于根据所述维度信息在对应的分区中进行查询，得到查询结果；及
发送模块，用于并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
一种服务器，包括存储器和处理器，所述存储器中储存有计算机可执行指令，所述计算机可执行指令被所述处理器执行时时，使得所述处理器执行以下步骤：
当到达同步时间时，判断多个源数据库内的批处理是否完成；
若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
在所述目标数据库中将所述数据总表拆分为多个维度的分区；
接收终端发送的数据查询指令，所述查询指令中携带了维度信息；及
根据所述维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
一个或多个存储有计算机可执行指令的非易失性可读存储介质，所述计算机可执行指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
当到达同步时间时，判断多个源数据库内的批处理是否完成；
若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
在所述目标数据库中将所述数据总表拆分为多个维度的分区；
接收终端发送的数据查询指令，所述查询指令中携带了维度信息；及
根据所述维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
【附图说明】
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他实施例的附图。
图1为一个实施例中保单数据处理方法的应用场景图；
图2为一个实施例中保单数据处理方法的流程图；
图3为一个实施例中服务器的框图；
图4为一个实施例中保单数据处理装置的框图；
图5为另一个实施例中保单数据处理装置的框图。
【具体实施方式】
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本申请实施例中提供的保单数据处理方法可以应用于如图1所示的应用场景中。终端102与服务器104通过网络连接。服务器104运行了job和kettle。job被配置同步时间，当到达同步时间是，启动job并且利用job判断多个源数据库内的批处理是否完成，若已完成，则触发kettle执行源数据库与目标数据库的同步操作，通过kettle将多个源数据库中的保单数据写入目标数据库中，在目标数据库中得到保单数据对应的数据总表。服务器104在目标数据库中将数据总表拆分为多个维度的分区。终端102向服务器104发送数据查询指令，服务器104接收数据查询指令，根据查询指令中携带的维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端102。终端102根据查询结果进行月结处理。由此实现了在进行保单月结处理时快速准确的提供保单统计数据。
在一个实施例中，如图2所示，提供了一种保单数据处理方法，应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。以该方法应用于服务器为例进行说明，具体包括以下步骤：
步骤202，当到达同步时间时，判断多个源数据库内的批处理是否完成；若是，则执行步骤204，否则，等待批处理完成。
服务器上运行了job和kettle，其中，kettle依托kettle平台进行工作。同步时间是根据保单进行月结处理的需要来设定的时间。例如，每个月1号的20:00。同步时间可以是工作时间，也可以是非工作时间。job被配置了同步时间。
服务器上部署了多个数据库，包括源数据库和目标数据库。其中，源数据库中存储机构的保单数据。源数据库可以与机构的数量相同，每个机构都配置了对应的源数据库。服务器可以是独立服务器，也可以是集群服务。
在其中一个实施例中，判断多个数据库内的批处理是否完成包括：启动job，利用job获取批处理对应的日志；利用job检查批处理对应的日志，根据日志中记录的内容判断批处理是否完成。
批处理是指保单保全结算和保单月结快照刷新等。在多个源数据库中进行批处理操作，并记录批处理对应的日志。日志中记录了批处理执行的进度状况。当到达同步时间时，启动job，利用job获取批处理对应的日志，并查看日志记录的内容，根据日志记录的内容来检查批处理是否完成。如果批处理未完成，则等待预设时间，例如，等待5分钟，再次利用job获取批处理对应的日志，日志中记录了批处理的执行状况，由此利用job根据日志中记录的内容来检查批处理是否完成。循环执行，直至job确定多个源数据库中的批处理完成。
步骤204，触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在目标数据库中得到保单数据对应的数据总表。
源数据库中的保单数据可以以数据表的形式进行存储。多个源数据库中的数据表可以采用相同的格式。数据表中包括保单号、被保险人和保费等。当job确定多个源数据库中的批处理完成时，触发kettle执行多个源数据库与目标数据库的同步操作。具体的，利用kettle删除目标数据库中已经存在的数据，新建转换，获取源数据库中需要同步的数据表，在开始节点后依次设置多个节点。节点数量可以与源数据库的数量相同。对每个节点配置对应的线程，每个线程负责执行一个源数据库的文件输出至目标数据库。利用多个线程将多个源数据库中的数据表导入目标数据库中。对保单数据采用merger处理，在目标数据库中进行全量插入同步操作，由此在目标数据库中快速得到保单数据对应的数据总表。通过多个线程并发执行同步操作，有效提高了多个源数据库中保单数据的同步效率。
通过增加job检查源数据库中批处理的执行状况，在源数据库中的批处理完成时，由job触发kettle执行源数据库与目标数据之间的同步操作。从而有效降低了同步操作与kettle平台之间的耦合度，提高了海量保单数据的同步效率。
步骤206，在目标数据库中将数据总表拆分为多个维度的分区。
由于数据总表中的数据量通常是百万级以及千万级，数据总表过于庞大。在数据总表中进行数据查询的耗时过长，也使得目标数据库的性能下降，导致月结处理受到不利影响。
为了便于月结处理，在目标数据库中将数据总表拆分为多个维度的分区。分区是指将数据总表拆分为数据总表中的保单数据还分在多个位置存放。分区后数据总表的保单数据散列到数据库中的多个位置。
服务器在目标数据库中获取维度字段，根据维度字段将数据总表拆分为多个分区。维度字段包括时间和机构等。其中，时间可以是一天、一周或一个月等。机构可以是机构所在地的标识。服务器还可以为分区的数据量配置分区阈值。例如，阈值为1万条。服务器在根据维度字段和分区阈值将数据总表拆分为多个分区。对于不足阈值的某个维度的保单数据，可以单独构成一个分区。进一步的，服务器还可以将分区划分为多个子分区。例如，服务器根据险种和保费等对分区划分为子分区。通过分区可以有效减少目标数据库的负担，提高目标数据库的性能。
步骤208，接收终端发送的数据查询指令，查询指令中携带了维度信息。
步骤210，根据维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据查询结果进行月结处理。
终端向服务器发送数据查询指令，查询指令中携带了维度信息。维度信息中可以包括一个或多个维度字段，例如，时间和机构等。服务器接收数据查询指令，根据维度信息在对应的分区中进行查询，得到查询结果。服务器不需要在数据总表中进行查询，能够有效提高查询效率。服务器将查询结果返回至终端，终端根据查询结果进行保单月结处理。
对于保单月结处理中不需要的分区，终端可以向服务器发送删除指令，服务器根据删除指令将相应的分区删掉。传统的方式中，如果是删除数据总表中的数据，需要逐行删除，如果删除的数据较多，则会耗费较多时间。本实施例中，服务器可以直接获取分区的地址，将相应的分区整个删掉，操作简单快捷。
进一步的，终端还可以将保单月结处理所需的分区一并从目标数据库中导出，不需要在多个源数据库中逐个导出保单数据，进一步提高了保单月结处理的工作效率。终端对导出的保单数据还可以进行数据清洗和数据压缩。数据清洗时指对保单数据进行审核和校验，删除重复的保单数据以及无效的保单数据等。数据压缩是指将同险种的保单数据进行合并压缩处理。
本实施例中，当到达同步时间时，如果多个源数据库内的批处理已完成；则触发源数据库与目标数据库的同步操作。由此将多个源数据库中的保单数据写入至目标数据库中，在目标数据库中得到保单数据对应的数据总表。通过多个源数据库与目标数据库的同步操作将海量的保单数据写入目标数据库中，由此确保了保单统计数据的准确性。通过在目标数据库中将数据总表拆分为多个维度的分区。在接收到终端发送的数据查询指令，能够根据查询指令中携带的维度信息快速在分区中进行查询，由此能够使得终端根据查询结果进行保单月结处理。从而在进行保单月结处理时能够快速准确的提供保单统计数据。
在一个实施例中，在触发源数据库与目标数据库的同步操作的步骤之后，还包括：记录同步操作日志；经过估计时间段后，利用job检查同步操作日志，根据同步操作日志中记录的内容来判断同步操作是否完成；若是，则生成同步操作完成的提示信息，并将提示信息发送至终端。
本实施例中，在kettle执行多个源数据库与目标数据库同步操作的同时，服务器记录同步操作日志。同步操作日志中记录了同步操作的执行状况。经过预估时间后，服务器利用job检查同步操作日志，以判断同步操作是否完成。估计时间是指根据历史数据估计出的执行同步操作所需的时间，是一个经验值。例如，估计时间可以是1个小时。
在触发同步操作后，经过预估时间，如果job判定同步操作未完成，则等待预设时间，再次获取同步操作日志，检查同步操作是否完成，循环执行，直至同步操作完成。当job判定同步操作完成，则服务器生成同步操作完成的提示信息，并将提示信息发送至终端。由此对同步操作进行实时监控，并且为终端及时了解同步操作执行状况提供了方便。
在一个实施例中，在目标数据库中将数据总表拆分为多个维度的分区的步骤包括：在目标数据库中运行多个线程对数据总表并发执行拆分任务；记录拆分任务的拆分日志；当多个线程从目标数据库中退出后再次执行拆分任务时，根据拆分日志查找多个线程在退出时对应的断点任务，多个线程从断点任务开始继续并发执行拆分任务，直至将数据总表拆分为多个维度的分区。
本实施例中，由于数据总表的保单数据过于庞大，服务器在目标数据库中运行多个线程并发执行对数据总表的拆分任务。服务器可以根据维度字段来生成拆分任务。不同线程执行不同维度字段的拆分任务，线程数量少于拆分任务的数量。多个线程按照预设的逻辑并发执行拆分任务，能够有效提高数据总表的拆分效率。
服务器对数据总表拆分过程记录拆分日志，通过拆分日志记录数据总表的拆分的状况，由此对拆分过程进行监控。一旦在数据总表的拆分过程中出错，服务器可以通过调用拆分日志快速定位到出错的位置。
当多个线程在某个时刻从目标数据库中退出时，可能还没有对所有的拆分任务执行完毕。需要再一次运行线程对尚未执行的拆分任务继续进行并发操作。具体的，当多个线程再次运行时，根据拆分日志中记录的任务的执行状况查找出多个线程从目标数据库中退出时对应的断点任务。从断点任务开始，多个线程再次继续执行并发操作，按照预设的逻辑对保单进行处理。
本实施例中，在目标数据库中运行多个线程对数据总表并发执行拆分任务，并且记录相应的拆分日志。当多个线程在目标数据库中退出后再次运行执行拆分任务时，不需要对所有的拆分任务重新执行。可以根据拆分任务的执行状况查找多个线程在退出时对应的断点任务，使得多个线程从断点任务开始继续执行并发操作。由此省去了对拆分任务进行全量补执行的时间，而且通过查找断点任务，在断点任务开始继续执行，有效防止拆分任务的漏执行和误执行等，有效提高了保单数据的处理效率。
在一个实施例中，在目标数据库中运行多个线程对数据表并发执行拆分任务的步骤包括：在目标数据库中获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组；对任务组分配对应的线程；通过多个线程对任务组并发执行拆分任务。
本实施例中，每个拆分任务都具有唯一的拆分任务标识。服务器获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组。
在一个实施例中，服务器获取拆分任务标识，根据预设的任务组数量按照拆分任务标识的顺序对拆分任务进行分组，得到多个任务组。例如，目标数据库中的拆分任务总共有100个。每个拆分任务都具有对应的拆分任务标识。预设的任务组为10个。根据拆分任务标识的顺序将每10个任务分为一组，由此得到10个任务组。
在一个实施例中，拆分任务标识可以是任务编号，服务器获取拆分任务，根据任务编号获取编号尾数相同的任务，将编号尾数相同的拆分任务分为一个任务组，得到多个任务组。例如，数据库中的任务总共有100个。每个任务都具有对应的任务编号，如任务1、任务2……任务100。将任务编号尾数相同的任务分为一组。如，将任务1、任务11、任务21……任务91分为一组，由此得到10个任务组。
服务器对每个任务组分配对应的线程。也就是说，每个线程会固定执行对应的任务组中的任务。例如，总共有10个任务组，每个任务组中有10个任务，服务器上运行了5个线程，服务器将线程1分配给任务组1和任务组3，则线程1将固定执行任务组1中的10个任务，直至任务组1中的任务执行完毕。线程1在执行完任务组1之后，再去执行任务组3。多个线程根据对应的任务组执行并发操作，对保单进行处理。由于线程固定执行某个任务标识对应的任务，因此容易发现任务执行过程中出现的异常，维护成本较低。
在一个实施例中，通过多个线程对任务组并发执行拆分任务的步骤包括：多个线程随机获取拆分任务，执行并发操作；在拆分任务执行完之后，线程随机获取下一个拆分任务进行对应操作。
本实施例中，线程不会固定执行某个拆分任务，可以随机获取拆分任务来执行。多个线程可以同时获取多个拆分任务并发执行操作，对数据总表进行拆分处理。在线程处理完一个拆分任务后，可以自行随机获取下一个拆分任务来执行。由于不需要线程固定执行某个拆分任务，因此能够有效缩短执行拆分任务的耗时。
在一个实施例中，如图3所示，提供了一种服务器，包括通过系统总线连接的处理器、内存储器、非易失性存储介质和网络接口。其中，该服务器的非易失性存储介质中存储有操作系统、源数据库、目标数据库和计算机可执行指令。源数据库中存储了机构的保单数据，目标数据库中存储了保单数据对应的数据总表。计算机可执行指令用于执行一种保单数据处理方法。服务器的处理器用于提供计算和控制能力，支撑整个服务器的运行。该服务器的网络接口用于连接终端，与终端进行通信。该服务器可以单独的服务器，也可以是集群服务器。本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定。具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，如图4所示，提供了一种保单数据处理装置，包括：判断模块402、同步模块404、拆分模块406、接收模块408、查询模块410和发送模块412，其中：
判断模块402，用于当到达同步时间时，判断多个源数据库内的批处理是否完成。
同步模块404，用于若多个源数据库内的批处理完成，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在目标数据库中得到保单数据对应的数据总表。
拆分模块406，用于在目标数据库中将数据总表拆分为多个维度的分区。
接收模块408，用于接收终端发送的数据查询指令，查询指令中携带了维度信息。
查询模块410，用于根据维度信息在对应的分区中进行查询，得到查询结果。
发送模块412，用于并将查询结果返回至终端，以使得终端根据查询结果进行月结处理。
在一个实施例中，判断模块402还用于启动job，利用job获取批处理对应的日志；利用job检查批处理对应的日志，根据日志中记录的内容判断批处理是否完成。
在一个实施例中，如图5所示，该装置还包括：记录模块414，用于记录同步操作日志；判断模块402还用于经过估计时间段后，利用job检查同步操作日志，根据同步操作日志中记录的内容来判断同步操作是否完成；若是，则生成同步操作完成的提示信息；发送模块412还用于将提示信息发送至终端。
在一个实施例中，拆分模块406还用于在目标数据库中运行多个线程对数据总表并发执行拆分任务；记录拆分任务的拆分日志；当多个线程从目标数据库中退出后再次执行拆分任务时，根据拆分日志查找多个线程在退出时对应的断点任务，多个线程从断点任务开始继续并发执行拆分任务，直至将数据总表拆分为多个维度的分区。
在一个实施例中，拆分模块406还用于在目标数据库中获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组；对任务组分配对应的线程；通过多个线程对任务组并发执行拆分任务。
上述保单数据处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。例如，在硬件实现上，上述接收模块408用于通过服务器的网络接口接收终端发送的查询指令，发送模块412通过服务器的网络接口将查询结果返回至终端。其中，网络接口可以是以太网卡或无线网卡等。上述各模块可以硬件形式内嵌于或独立于基站的处理器中，也可以以软件形式存储于基站的存储器中，以便于处理器调用执行以上各个模块对应的操作。其中，处理器可以为中央处理单元（CPU）或微处理器等。
在一个实施例中，提供了一个或多个存储有计算机可执行指令的非易失性可读存储介质，计算机可执行指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
当到达同步时间时，判断多个源数据库内的批处理是否完成；
若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在目标数据库中得到保单数据对应的数据总表；
在目标数据库中将数据总表拆分为多个维度的分区；
接收终端发送的数据查询指令，查询指令中携带了维度信息；及
根据维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据查询结果进行月结处理。
在一个实施例中，判断多个数据库内的批处理是否完成包括：启动job，利用job获取批处理对应的日志；及利用job检查批处理对应的日志，根据日志中记录的内容判断批处理是否完成。
在一个实施例中，计算机可执行指令被一个或多个处理器执行时，还使得一个或多个处理器执行以下步骤：记录同步操作日志；经过估计时间段后，利用job检查同步操作日志，根据同步操作日志中记录的内容来判断同步操作是否完成；及若是，则生成同步操作完成的提示信息，并将提示信息发送至终端。
在一个实施例中，在目标数据库中将数据总表拆分为多个维度的分区包括：在目标数据库中运行多个线程对数据总表并发执行拆分任务；记录拆分任务的拆分日志；及当多个线程从目标数据库中退出后再次执行拆分任务时，根据拆分日志查找多个线程在退出时对应的断点任务，多个线程从断点任务开始继续并发执行拆分任务，直至将数据总表拆分为多个维度的分区。
在一个实施例中，在目标数据库中运行多个线程对数据表并发执行拆分任务包括：在目标数据库中获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组；对任务组分配对应的线程；及通过多个线程对任务组并发执行拆分任务。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory，ROM）等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种保单数据处理方法，包括：
    当到达同步时间时，判断多个源数据库内的批处理是否完成；
    若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
    在所述目标数据库中将所述数据总表拆分为多个维度的分区；
    接收终端发送的数据查询指令，所述查询指令中携带了维度信息；及
    根据所述维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
  2. 根据权利要求1所述的方法，其特征在于，所述判断多个数据库内的批处理是否完成包括：
    启动job，利用job获取批处理对应的日志；及
    利用job检查批处理对应的日志，根据日志中记录的内容判断批处理是否完成。
  3. 根据权利要求1所述的方法，其特征在于，在所述触发源数据库与目标数据库的同步操作之后，所述方法还包括：
    记录同步操作日志；及
    经过估计时间段后，利用job检查所述同步操作日志，根据所述同步操作日志中记录的内容来判断同步操作是否完成；
    若是，则生成同步操作完成的提示信息，并将所述提示信息发送至终端。
  4. 根据权利要求1所述的方法，其特征在于，所述在所述目标数据库中将所述数据总表拆分为多个维度的分区包括：
    在目标数据库中运行多个线程对所述数据总表并发执行拆分任务；
    记录拆分任务的拆分日志；及
    当多个线程从所述目标数据库中退出后再次执行拆分任务时，根据所述拆分日志查找多个线程在退出时对应的断点任务，多个线程从断点任务开始继续并发执行拆分任务，直至将所述数据总表拆分为多个维度的分区。
  5. 根据权利要求4所述的方法，其特征在于，所述在目标数据库中运行多个线程对所述数据表并发执行拆分任务包括：
    在所述目标数据库中获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组；
    对任务组分配对应的线程；及
    通过多个线程对任务组并发执行拆分任务。
  6. 一种保单数据处理装置，包括：
    判断模块，用于当到达同步时间时，判断多个源数据库内的批处理是否完成；
    同步模块，用于若多个源数据库内的批处理完成，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
    拆分模块，用于在所述目标数据库中将所述数据总表拆分为多个维度的分区；
    接收模块，用于接收终端发送的数据查询指令，所述查询指令中携带了维度信息；
    查询模块，用于根据所述维度信息在对应的分区中进行查询，得到查询结果；及
    发送模块，用于并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
  7. 根据权利要求6所述的装置，其特征在于，所述判断模块还用于启动job，利用job获取批处理对应的日志；利用job检查批处理对应的日志，根据日志中记录的内容判断批处理是否完成。
  8. 根据权利要求6所述的装置，其特征在于，还包括：
    记录模块，用于记录同步操作日志；
    所述判断模块还用于经过估计时间段后，利用job检查所述同步操作日志，根据所述同步操作日志中记录的内容来判断同步操作是否完成；若是，则生成同步操作完成的提示信息；及
    所述发送模块还用于将所述提示信息发送至终端。
  9. 根据权利要求6所述的装置，其特征在于，所述拆分模块还用于在目标数据库中运行多个线程对所述数据总表并发执行拆分任务；记录拆分任务的拆分日志；当多个线程从所述目标数据库中退出后再次执行拆分任务时，根据所述拆分日志查找多个线程在退出时对应的断点任务，多个线程从断点任务开始继续并发执行拆分任务，直至将所述数据总表拆分为多个维度的分区。
  10. 根据权利要求9所述的装置，其特征在于，所述拆分模块还用于在所述目标数据库中获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组；对任务组分配对应的线程；通过多个线程对任务组并发执行拆分任务。
  11. 一种服务器，包括存储器和处理器，所述存储器中储存有计算机可执行指令，所述计算机可执行指令被所述处理器执行时时，使得所述处理器执行以下步骤：
    当到达同步时间时，判断多个源数据库内的批处理是否完成；
    若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
    在所述目标数据库中将所述数据总表拆分为多个维度的分区；
    接收终端发送的数据查询指令，所述查询指令中携带了维度信息；及
    根据所述维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
  12. 根据权利要求11所述的服务器，其特征在于，所述判断多个数据库内的批处理是否完成包括：
    启动job，利用job获取批处理对应的日志；及
    利用job检查批处理对应的日志，根据日志中记录的内容判断批处理是否完成。
  13. 根据权利要求11所述的服务器，其特征在于，在所述触发源数据库与目标数据库的同步操作之后，还使得所述处理器执行以下步骤：
    记录同步操作日志；
    经过估计时间段后，利用job检查所述同步操作日志，根据所述同步操作日志中记录的内容来判断同步操作是否完成；及
    若是，则生成同步操作完成的提示信息，并将所述提示信息发送至终端。
  14. 根据权利要求11所述的服务器，其特征在于，所述在所述目标数据库中将所述数据总表拆分为多个维度的分区包括：
    在目标数据库中运行多个线程对所述数据总表并发执行拆分任务；
    记录拆分任务的拆分日志；及
    当多个线程从所述目标数据库中退出后再次执行拆分任务时，根据所述拆分日志查找多个线程在退出时对应的断点任务，多个线程从断点任务开始继续并发执行拆分任务，直至将所述数据总表拆分为多个维度的分区。
  15. 根据权利要求14所述的服务器，其特征在于，所述在目标数据库中运行多个线程对所述数据表并发执行拆分任务包括：
    在所述目标数据库中获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组；
    对任务组分配对应的线程；及
    通过多个线程对任务组并发执行拆分任务。
  16. 一个或多个存储有计算机可执行指令的非易失性可读存储介质，所述计算机可执行指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    当到达同步时间时，判断多个源数据库内的批处理是否完成；
    若是，则触发源数据库与目标数据库的同步操作，将多个源数据库中的保单数据写入目标数据库中，在所述目标数据库中得到保单数据对应的数据总表；
    在所述目标数据库中将所述数据总表拆分为多个维度的分区；
    接收终端发送的数据查询指令，所述查询指令中携带了维度信息；及
    根据所述维度信息在对应的分区中进行查询，得到查询结果，并将查询结果返回至终端，以使得终端根据所述查询结果进行月结处理。
  17. 根据权利要求16所述的非易失性可读存储介质，其特征在于，所述判断多个数据库内的批处理是否完成包括：
    启动job，利用job获取批处理对应的日志；及
    利用job检查批处理对应的日志，根据日志中记录的内容判断批处理是否完成。
  18. 根据权利要求16所述的非易失性可读存储介质，其特征在于，所述
    计算机可执行指令被一个或多个处理器执行时，还使得所述一个或多个处理器执行以下步骤：
    记录同步操作日志；
    经过估计时间段后，利用job检查所述同步操作日志，根据所述同步操作日志中记录的内容来判断同步操作是否完成；及
    若是，则生成同步操作完成的提示信息，并将所述提示信息发送至终端。
  19. 根据权利要求16所述的非易失性可读存储介质，其特征在于，所述在所述目标数据库中将所述数据总表拆分为多个维度的分区包括：
    在目标数据库中运行多个线程对所述数据总表并发执行拆分任务；
    记录拆分任务的拆分日志；及
    当多个线程从所述目标数据库中退出后再次执行拆分任务时，根据所述拆分日志查找多个线程在退出时对应的断点任务，多个线程从断点任务开始继续并发执行拆分任务，直至将所述数据总表拆分为多个维度的分区。
  20. 根据权利要求19所述的非易失性可读存储介质，其特征在于，所述在目标数据库中运行多个线程对所述数据表并发执行拆分任务包括：
    在所述目标数据库中获取拆分任务标识，根据拆分任务标识对拆分任务进行分组，得到多个任务组；
    对任务组分配对应的线程；及
    通过多个线程对任务组并发执行拆分任务。
PCT/CN2017/078356 2016-07-22 2017-03-28 保单数据处理方法、装置、服务器和存储介质 Ceased WO2018014582A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610585256.2 2016-07-22
CN201610585256.2A CN106980636B (zh) 2016-07-22 2016-07-22 保单数据处理方法和装置

Publications (1)

Publication Number Publication Date
WO2018014582A1 true WO2018014582A1 (zh) 2018-01-25

Family

ID=59340373

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/078356 Ceased WO2018014582A1 (zh) 2016-07-22 2017-03-28 保单数据处理方法、装置、服务器和存储介质

Country Status (2)

Country Link
CN (1) CN106980636B (zh)
WO (1) WO2018014582A1 (zh)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109064295A (zh) * 2018-09-05 2018-12-21 中国平安财产保险股份有限公司 投保报价的计算方法、装置、计算机设备和存储介质
CN109213768A (zh) * 2018-09-25 2019-01-15 中国平安人寿保险股份有限公司 电子装置、基于多个临时数据表的数据查询方法及存储介质
CN109583829A (zh) * 2018-10-19 2019-04-05 中国平安人寿保险股份有限公司 基于新产品开发的月结信息处理方法、电子装置及可读存储介质
CN110134512A (zh) * 2019-04-15 2019-08-16 平安科技（深圳）有限公司 集群服务器执行任务的方法、装置、设备及存储介质
CN110308980A (zh) * 2019-06-27 2019-10-08 深圳前海微众银行股份有限公司 数据的批量处理方法、装置、设备及存储介质
CN110489275A (zh) * 2019-07-23 2019-11-22 中国平安财产保险股份有限公司 一种单据信息的处理方法及相关设备
CN110599354A (zh) * 2019-08-15 2019-12-20 中国平安财产保险股份有限公司 线上对账方法、系统、计算机设备和计算机可读存储介质
CN110825953A (zh) * 2019-11-12 2020-02-21 上海德启信息科技有限公司 数据查询方法、装置和设备
CN110895488A (zh) * 2018-09-12 2020-03-20 北京奇虎科技有限公司 任务调度方法及装置
CN111443999A (zh) * 2020-02-17 2020-07-24 深圳壹账通智能科技有限公司 数据并行处理方法、执行器、计算机设备和存储介质
CN111475554A (zh) * 2020-04-30 2020-07-31 上海东普信息科技有限公司 基于快递状态的数据展示方法、装置、设备及存储介质
CN112306949A (zh) * 2019-07-31 2021-02-02 中科寒武纪科技股份有限公司 数据处理方法及装置以及相关产品
CN112581295A (zh) * 2020-12-15 2021-03-30 平安养老保险股份有限公司 基于字段拆分的产品数据处理方法、装置、设备和介质
CN113628056A (zh) * 2021-08-10 2021-11-09 合众人寿保险股份有限公司 数据的处理方法、装置、服务器及计算机存储介质
CN116107713A (zh) * 2023-01-17 2023-05-12 江铃汽车股份有限公司 一种批处理任务执行方法、系统、存储介质及设备

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107391758B (zh) * 2017-08-24 2020-08-04 阿里巴巴集团控股有限公司 数据库切换方法、装置及设备
CN107798417B (zh) * 2017-09-25 2019-06-14 平安科技（深圳）有限公司 基于关联交易数据处理的优化方法、装置和计算机设备
CN108509478B (zh) * 2017-11-23 2021-04-27 平安科技（深圳）有限公司 规则引擎文件的拆分调用方法、电子装置及存储介质
CN108629699B (zh) * 2018-05-15 2023-04-18 中国平安人寿保险股份有限公司 数据上传方法、数据上传设备、存储介质及装置
CN110196880B (zh) * 2018-06-08 2023-05-12 腾讯科技（深圳）有限公司 异构数据库数据同步方法和装置、存储介质及电子装置
CN111078510B (zh) * 2018-10-18 2023-05-16 北京国双科技有限公司 一种任务处理进度的记录方法及装置
CN109801174B (zh) * 2018-12-26 2023-11-17 平安科技（深圳）有限公司 理赔数据处理方法、装置、设备及计算机可读存储介质
CN110659328B (zh) * 2019-08-30 2022-04-29 中国人民财产保险股份有限公司 数据查询方法、装置、设备及计算机可读存储介质
CN110928947A (zh) * 2019-10-16 2020-03-27 中国平安财产保险股份有限公司 基于kettle的数据同步方法、装置及相关设备
CN110851533A (zh) * 2019-11-13 2020-02-28 泰康保险集团股份有限公司 跨异构数据库的数据同步方法、装置、介质及电子设备
CN111126935B (zh) * 2019-11-19 2023-07-21 泰康保险集团股份有限公司 保全数据的处理方法、装置、电子设备和存储介质
CN111309742A (zh) * 2020-01-20 2020-06-19 深圳壹账通智能科技有限公司 数据同步方法、装置、计算机设备及存储介质
CN112100219B (zh) * 2020-09-22 2024-01-30 平安养老保险股份有限公司 基于数据库查询处理的报表生成方法、装置、设备和介质
CN113986951A (zh) * 2021-10-29 2022-01-28 重庆富民银行股份有限公司 一种通用etl代码的生成系统及方法
CN116756141A (zh) * 2023-05-31 2023-09-15 中国人民财产保险股份有限公司 理赔环节数据的查询方法及装置、存储介质、终端

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104111957A (zh) * 2013-04-22 2014-10-22 阿里巴巴集团控股有限公司 一种分布式事务同步的方法及系统
US20150019488A1 (en) * 2013-07-09 2015-01-15 Oracle International Corporation Automated database migration architecture
CN105138615A (zh) * 2015-08-10 2015-12-09 北京思特奇信息技术股份有限公司 一种构建大数据分布式日志的方法和系统
CN105320676A (zh) * 2014-07-04 2016-02-10 中国移动通信集团黑龙江有限公司 一种客户数据查询服务方法及装置
CN105760485A (zh) * 2016-02-17 2016-07-13 上海携程商务有限公司 财务数据抽取方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104111957A (zh) * 2013-04-22 2014-10-22 阿里巴巴集团控股有限公司 一种分布式事务同步的方法及系统
US20150019488A1 (en) * 2013-07-09 2015-01-15 Oracle International Corporation Automated database migration architecture
CN105320676A (zh) * 2014-07-04 2016-02-10 中国移动通信集团黑龙江有限公司 一种客户数据查询服务方法及装置
CN105138615A (zh) * 2015-08-10 2015-12-09 北京思特奇信息技术股份有限公司 一种构建大数据分布式日志的方法和系统
CN105760485A (zh) * 2016-02-17 2016-07-13 上海携程商务有限公司 财务数据抽取方法及系统

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109064295A (zh) * 2018-09-05 2018-12-21 中国平安财产保险股份有限公司 投保报价的计算方法、装置、计算机设备和存储介质
CN110895488B (zh) * 2018-09-12 2023-10-20 三六零科技集团有限公司 任务调度方法及装置
CN110895488A (zh) * 2018-09-12 2020-03-20 北京奇虎科技有限公司 任务调度方法及装置
CN109213768A (zh) * 2018-09-25 2019-01-15 中国平安人寿保险股份有限公司 电子装置、基于多个临时数据表的数据查询方法及存储介质
CN109583829A (zh) * 2018-10-19 2019-04-05 中国平安人寿保险股份有限公司 基于新产品开发的月结信息处理方法、电子装置及可读存储介质
CN109583829B (zh) * 2018-10-19 2024-03-15 中国平安人寿保险股份有限公司 基于新产品开发的月结信息处理方法、电子装置及可读存储介质
CN110134512A (zh) * 2019-04-15 2019-08-16 平安科技（深圳）有限公司 集群服务器执行任务的方法、装置、设备及存储介质
CN110134512B (zh) * 2019-04-15 2024-02-13 平安科技（深圳）有限公司 集群服务器执行任务的方法、装置、设备及存储介质
CN110308980A (zh) * 2019-06-27 2019-10-08 深圳前海微众银行股份有限公司 数据的批量处理方法、装置、设备及存储介质
CN110489275A (zh) * 2019-07-23 2019-11-22 中国平安财产保险股份有限公司 一种单据信息的处理方法及相关设备
CN110489275B (zh) * 2019-07-23 2023-06-02 中国平安财产保险股份有限公司 一种单据信息的处理方法及相关设备
CN112306949B (zh) * 2019-07-31 2022-11-01 中科寒武纪科技股份有限公司 数据处理方法及装置以及相关产品
CN112306949A (zh) * 2019-07-31 2021-02-02 中科寒武纪科技股份有限公司 数据处理方法及装置以及相关产品
CN110599354A (zh) * 2019-08-15 2019-12-20 中国平安财产保险股份有限公司 线上对账方法、系统、计算机设备和计算机可读存储介质
CN110599354B (zh) * 2019-08-15 2023-11-21 中国平安财产保险股份有限公司 线上对账方法、系统、计算机设备和计算机可读存储介质
CN110825953A (zh) * 2019-11-12 2020-02-21 上海德启信息科技有限公司 数据查询方法、装置和设备
CN110825953B (zh) * 2019-11-12 2024-03-22 上海德启信息科技有限公司 数据查询方法、装置和设备
CN111443999A (zh) * 2020-02-17 2020-07-24 深圳壹账通智能科技有限公司 数据并行处理方法、执行器、计算机设备和存储介质
CN111475554A (zh) * 2020-04-30 2020-07-31 上海东普信息科技有限公司 基于快递状态的数据展示方法、装置、设备及存储介质
CN111475554B (zh) * 2020-04-30 2024-03-01 上海东普信息科技有限公司 基于快递状态的数据展示方法、装置、设备及存储介质
CN112581295A (zh) * 2020-12-15 2021-03-30 平安养老保险股份有限公司 基于字段拆分的产品数据处理方法、装置、设备和介质
CN112581295B (zh) * 2020-12-15 2023-09-26 平安养老保险股份有限公司 基于字段拆分的产品数据处理方法、装置、设备和介质
CN113628056A (zh) * 2021-08-10 2021-11-09 合众人寿保险股份有限公司 数据的处理方法、装置、服务器及计算机存储介质
CN116107713A (zh) * 2023-01-17 2023-05-12 江铃汽车股份有限公司 一种批处理任务执行方法、系统、存储介质及设备

Also Published As

Publication number Publication date
CN106980636A (zh) 2017-07-25
CN106980636B (zh) 2020-04-03

Similar Documents

Publication Publication Date Title
WO2018014582A1 (zh) 保单数据处理方法、装置、服务器和存储介质
WO2018161478A1 (zh) 多区块链的分片处理方法、装置、服务器和存储介质
WO2018177107A1 (zh) 数据迁移方法、迁移服务器及存储介质
WO2017177769A1 (zh) Ogg 版本部署方法、系统、服务器和存储介质
US11726984B2 (en) Data redistribution method and apparatus, and database cluster
WO2018233037A1 (zh) 数据库集成测试方法、装置、服务器及存储介质
CN112182104A (zh) 一种数据同步方法、装置、设备及存储介质
WO2021003985A1 (zh) 区块链数据归档存储方法、装置、计算机设备和存储介质
WO2020238066A1 (zh) 一种软件的压力测试方法、装置、存储介质和服务器
WO2019134226A1 (zh) 一种日志收集方法、装置、终端设备及存储介质
WO2018014580A1 (zh) 数据接口测试方法、装置、服务器和存储介质
WO2018161479A1 (zh) 区块链集群处理系统、方法、计算机设备和存储介质
US20220245132A1 (en) Transaction monitoring method, apparatus and system for distributed database, and storage medium
WO2013044502A1 (zh) 数据管理的方法及装置
WO2017181430A1 (zh) 分布式系统的数据库复制方法及装置
CN113806301B (zh) 数据同步方法、装置、服务器及存储介质
CN114500289B (zh) 控制平面恢复方法、装置、控制节点及存储介质
WO2017157111A1 (zh) 防止内存数据丢失的的方法、装置和系统
CN113704790A (zh) 一种异常日志信息汇总方法及计算机设备
CN106899654A (zh) 一种序列值生成方法、装置及系统
CN114996210B (zh) 数据处理方法、装置、计算机设备和存储介质
CN109284339A (zh) 一种数据库数据实时同步的方法和装置
CN113934792A (zh) 分布式数据库的处理方法、装置、网络设备和存储介质
CN111026767A (zh) 区块链的数据存储方法、装置及硬件设备
WO2014029111A1 (zh) 一种用户行为处理系统及方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17830224

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 16.05.2019)

122 Ep: pct application non-entry in european phase

Ref document number: 17830224

Country of ref document: EP

Kind code of ref document: A1