A service data migration method, device, equipment and medium

Abstract

The application relates to the technical field of data processing, in particular to a business data migration method and device, equipment and medium, which are used for improving the migration efficiency of business data. The method comprises the following steps: acquiring a contract identifier from first business data; determining a first application partition identifier according to the contract identifier, the first application partition identifier being associated with a first partition; determining that the first business data is cross-partition data according to the first application partition identifier and a second application partition identifier of the first business data, the second application partition identifier being associated with a second partition; and migrating the first business data to a database corresponding to the first partition. According to the method, whether the first business data is cross-partition data can be determined according to the first application partition identifier and the second application partition identifier of the first business data, without referring to other card identifier associated data, so that cross-partition data can be quickly and accurately acquired, thereby improving the migration efficiency of business data.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data processing, in particular to a business data migration method and device, equipment and medium. BACKGROUND

[0002] When processing certain businesses, banks and other financial institutions will generate cross-partition data. For example, when changing a card in a different place, that is, when a card of a certain customer in partition A is lost and the card is changed in partition B, the generated data belongs to cross-partition data.

[0003] Currently, when migrating the inventory data in the host database to the distributed database, the inventory data cannot be directly dropped into the distributed database of the belonging partition, and the cross-partition data in the inventory data must be identified. After reformatting these data, they can be stored in the distributed database of the current belonging partition.

[0004] However, it is currently impossible to accurately and efficiently find cross-partition data, resulting in a long time consumption of data migration. SUMMARY

[0005] The embodiments of the present application provide a business data migration method, device, equipment and medium, which can improve the migration efficiency of business data.

[0006] In a first aspect, the present application provides a business data migration method, which comprises: obtaining a contract identifier from first business data; determining a first application partition identifier according to the contract identifier, the first application partition identifier being associated with a first partition; determining that the first business data is cross-partition data according to the first application partition identifier and a second application partition identifier of the first business data, the second application partition identifier being associated with a second partition; and migrating the first business data to a database corresponding to the first partition.

[0007] By using this method, whether the first business data is cross-partition data can be determined according to the first application partition identifier and the second application partition identifier of the first business data, without referring to other card identifier associated data. Only the information of the first business data itself is needed to identify whether the first business data belongs to cross-partition data. Therefore, cross-partition data can be quickly and accurately obtained, thereby improving the migration efficiency of business data.

[0008] In a possible embodiment, the method further comprises: determining a region identifier of the first partition according to the contract identifier; and determining the first application partition identifier according to the region identifier of the first partition.

[0009] According to the design, the region identifier of the first partition is determined according to the contract identifier, and then the application partition identifier of the first application partition is determined according to the region identifier of the first partition, so that the application partition identifier corresponding to the first service data can be accurately obtained.

[0010] In a possible embodiment, the method further includes: determining, according to the first application partition identifier and a third application partition identifier of second service data, that the second service data is cross-partition data, wherein the second service data includes the contract identifier, and the second service data is card data of the user.

[0011] According to the design, whether the second service data is cross-partition data can be determined according to the first application partition identifier and the third application partition identifier of the second service data, without referring to other card identifier associated data, so that the cross-partition data can be quickly and accurately obtained, thereby improving the migration efficiency of service data.

[0012] In a possible embodiment, the method further includes: migrating the second service data to a database corresponding to the first partition.

[0013] In a possible embodiment, the method further includes: obtaining a card identifier from third service data, wherein the third service data is data with an empty contract identifier; determining the fourth application partition identifier according to the card identifier, wherein the fourth application partition identifier is associated with a third partition; and determining, according to the fourth application partition identifier and a fifth application partition identifier of the third service data, that the third service data is cross-partition data.

[0014] According to the design, when the contract identifier of the third service data is empty, the fourth application partition identifier corresponding to the third service data can be determined according to the card identifier of the third service data, and then whether the third service data is cross-partition data can be determined according to the fourth application partition identifier and the fifth application partition identifier, without referring to other card identifier associated data, so that the cross-partition data can be quickly and accurately obtained, thereby improving the migration efficiency of service data.

[0015] In a possible embodiment, the method further includes: determining the region identifier of the second partition according to the card identifier; and determining the fourth application partition identifier according to the region identifier of the second partition.

[0016] In a possible embodiment, the method further includes: migrating the third service data to a database corresponding to the third partition.

[0017] In a second aspect, the present application provides a device for migrating service data, and the device includes:

[0018] The acquisition module is configured to acquire a contract identifier from the first service data; the processing module is configured to determine a first application partition identifier according to the contract identifier, the first application partition identifier being associated with a first partition; the processing module is further configured to determine, according to the first application partition identifier and a second application partition identifier of the first service data, that the first service data is cross-partition data, the second application partition identifier being associated with a second partition; and the processing module is further configured to migrate the first service data to a database corresponding to the first partition.

[0019] In a possible implementation, the processing module is specifically configured to determine a region identifier of the first partition according to the contract identifier; and determine the first application partition identifier according to the region identifier of the first partition.

[0020] In a possible implementation, the processing module is further configured to determine, according to the first application partition identifier and a third application partition identifier of second service data, that the second service data is cross-partition data, the second service data including the contract identifier, and the second service data being card data of the user.

[0021] In a possible implementation, the processing module is specifically configured to migrate the second service data to the database corresponding to the first partition.

[0022] In a possible implementation, the acquisition module is further configured to acquire a card identifier from third service data, the third service data being data with an empty contract identifier; the processing module is further configured to determine a fourth application partition identifier according to the card identifier, the fourth application partition identifier being associated with a third partition; and the processing module is further configured to determine, according to the fourth application partition identifier and a fifth application partition identifier of the third service data, that the third service data is cross-partition data.

[0023] In a possible implementation, the processing module is specifically configured to determine a region identifier of the second partition according to the card identifier; and determine the fourth application partition identifier according to the region identifier of the second partition.

[0024] In a possible implementation, the processing module is specifically configured to migrate the third service data to a database corresponding to the third partition.

[0025] In a third aspect, the present application provides an electronic device, comprising:

[0026] a memory configured to store program instructions;

[0027] a processor configured to invoke the program instructions stored in the memory, and perform steps included in the method according to the obtained program instructions.

[0028] Fourthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in any one of the first aspects.

[0029] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects.

[0030] The technical effects of aspects two through five and any one of their designs can be found in the technical effects of the corresponding designs in aspect one, and will not be repeated here. Attached Figure Description

[0031] Figure 1 A flowchart illustrating a business data migration method provided in an embodiment of this application;

[0032] Figure 2 A flowchart illustrating another method for migrating business data provided in this application embodiment;

[0033] Figure 3 A schematic diagram of the structure of a business data migration device provided in an embodiment of this application;

[0034] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0036] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0037] The data collection, dissemination, and use in this application all comply with relevant national laws and regulations.

[0038] Before introducing the business data migration method provided in the embodiments of this application, for ease of understanding, the technical background of the embodiments of this application will be described in detail below.

[0039] When processing certain business transactions, cross-regional data may be generated. In this application, a region can be understood as a specific area where a provincial branch, sub-branch, or multiple institutions are located. Therefore, when business data involves cross-provincial branches, it can be considered cross-regional data.

[0040] The following example uses province-level partitions to illustrate cross-partition data.

[0041] Example 1: Sub-card cross-provincial bank appointment card application business, that is, sub-card products applying for appointment cards across provinces. The primary bank management institution corresponding to the sub-card is different from the primary bank management institution of this transaction institution. As a result, the province to which the host application partition number and contract number of the sub-card belongs is different from the province to which the host application partition number of the primary card belongs, thus generating cross-provincial cross-partition data.

[0042] For example, if a customer's primary card's primary bank branch is in Province A, and according to the application partitioning rules, the provincial branch number corresponding to the primary card's application partition number is 0001, where 0001 is the logical provincial branch number of Province A. If the customer applies for a multi-media card with one account at a bank in Province B, and this multi-media card service is a sub-card service, the application partition number of the sub-card would be 0002, the same as the primary card's application partition number, where 0002 is the logical provincial branch number of Province B. Since the primary and sub-cards belong to the same customer, the application partition number of the sub-card should correspond to the same provincial branch as the primary card's application partition number. However, because the sub-card was applied for at a bank in Province B, the application partition number of the sub-card is inconsistent with that of the primary card, resulting in cross-provincial data.

[0043] Example 2: For cross-provincial card replacement services, a customer applies to replace their card at a branch other than the primary card's issuing bank. The card can be either a primary card or a secondary card. Since the card's application partition number is generated based on the transaction institution, the application partition number of the replacement card will differ from the primary card's application partition number, resulting in cross-provincial, cross-partition data generation.

[0044] For example, if a customer's primary card is managed by a branch in Province A, according to the application partitioning rules, the provincial branch number corresponding to the primary card's application partition number is 0001, where 0001 is the logical provincial branch number of Province A. If the customer applies for a new card at a bank in Province B, according to the current mechanism for generating application partition numbers, the provincial branch number corresponding to the new card's application partition number is 0002, where 0002 is the logical provincial branch number of Province B. Therefore, the application partition number of the new card is inconsistent with the provincial branch number corresponding to the original card's application partition number, thus generating cross-provincial data.

[0045] Currently, when banks and other financial institutions archive existing data, they cannot directly transfer the existing data from the mainframe database to the distributed database of the corresponding partition. They must identify cross-partition data within the existing data, reorganize this data, and then store it in the distributed database associated with the current partition. However, archiving business data to a previous partition could lead to errors in subsequent business data management.

[0046] However, currently, identifying cross-partition data requires comparing the application partition identifiers of multiple related data sets (such as primary card data and secondary card data), and cannot be determined solely based on data under the same card identifier. Therefore, the identification process for cross-partition data is highly complex, resulting in low identification efficiency. Since the efficiency of cross-partition data identification affects the efficiency of business data organization and archiving, it is imperative to improve the efficiency of cross-partition data identification.

[0047] To improve the efficiency of identifying cross-partition data, embodiments of this application provide a method, apparatus, device, and medium for migrating business data, which are used to improve the efficiency of business data migration.

[0048] The method employed in this application includes: a data processing device obtaining a contract identifier from first business data; the data processing device determining a first application partition identifier based on the contract identifier, the first application partition identifier being associated with a first partition; the data processing device determining that the first business data is cross-partition data based on the first application partition identifier and a second application partition identifier of the first business data, the second application partition identifier being associated with a second partition; and the data processing device migrating the first business data to the database corresponding to the first partition.

[0049] It is understood that the data processing device in this application can be used to determine a first application partition identifier based on the obtained contract identifier, and to determine that the first business data is cross-partition data based on the first application partition identifier and the second application partition identifier, wherein the first application partition identifier and the second application partition identifier correspond to different partitions. Using this method, the data processing device can determine whether the first business data is cross-partition data based on the first application partition identifier and the second application partition identifier of the first business data, without needing to refer to data associated with other card identifiers. Therefore, it can quickly and accurately obtain cross-partition data, thereby improving the migration efficiency of business data. Furthermore, the data processing device can be included in a computer system for executing the method shown in this application, or it can be a processing device in a computer system for executing the method shown in this application, such as a processor or processing module, etc., which is not specifically limited in this application.

[0050] Figure 1 This is a flowchart illustrating a business data migration method provided in an embodiment of the present invention. Taking a data processing device as the executing entity, the process may include the following steps:

[0051] S101, the data processing device obtains the contract identifier from the first business data.

[0052] Specifically, the first business data can be at least one piece of data from multiple contract data sets in the user's debit card contract file. The first business data includes information such as the user identifier, the card identifier used in the contract, and the contract identifier. The contract can be a record between the user and the bank regarding a specific business or account function, such as a record of the user conducting debit card transactions at the bank. The first contract can include at least one of a debit card contract, a top-level contract for a first-level sub-card, and a main contract for a second-level sub-card. Therefore, the contract identifier can be a debit card contract identifier, a top-level contract for a first-level sub-card, or a main contract for a second-level sub-card.

[0053] Card identifiers can consist of at least one of letters, numbers, and symbols. For example, a common card identifier is a card number composed of numbers. Similarly, contract identifiers can also consist of at least one of letters, numbers, and symbols, without specific limitations. For example, a common contract identifier is a contract number composed of numbers. It can be understood that the contract number may include the regional identifier (such as a provincial branch code or institution code) of the institution that signed the contract with the user. To ensure the stability of the contractual relationship between the user and the bank, and to ensure that the contract remains unchanged when the card is changed, most tables use the contract identifier as the primary key, making it easy to retrieve the contract identifier from the primary business data.

[0054] Therefore, data processing devices can determine the relationships between tables through contract identifiers. This method minimizes the number of table relationships and reduces interactions between components.

[0055] S102, the data processing device determines the first application partition identifier based on the contract identifier, wherein the first application partition identifier is associated with the first partition. It is understood that the application partition identifier in this application can consist of at least one of letters, numbers, and symbols, used to distinguish different partitions. For example, a commonly used application partition identifier is an application partition number composed of numbers. The application partition identifier can also have other names, such as a cross-partition data identification number, etc., without specific limitation.

[0056] In one or more embodiments, the data processing device may determine the first application partition identifier in the following manner:

[0057] The data processing device determines the region identifier of the first partition based on the contract identifier, and then determines the first application partition identifier based on the region identifier of the first partition. The contract identifier can be the top-level contract identifier, the main contract identifier, etc.

[0058] S103, the data processing device determines that the first business data is cross-partition data based on the first application partition identifier and the second application partition identifier of the first business data, wherein the second application partition identifier is associated with the second partition.

[0059] Specifically, the first business data also includes a second application partition identifier. The second application partition identifier is generated when the first business data is generated, based on an existing mechanism for generating application partition identifiers. For example, the second application partition identifier may be generated based on the user's card identifier or other information besides the contract identifier. It is understood that the second application partition identifier in this application can be an application partition identifier determined in an existing manner. As a possible example, the partition corresponding to the first application partition identifier determined in S102 is the partition to which the user's primary card belongs. If the partition corresponding to the first application partition identifier is different from the partition corresponding to the second application partition identifier, then the first business data is determined to be cross-partition data.

[0060] In one or more embodiments, the data processing device may further determine that the second business data is cross-partition data based on the first application partition identifier and the third application partition identifier of the second business data, wherein the second business data includes a contract identifier and the second business data is the user's card data.

[0061] Specifically, the second business data is one of several data points in the debit card file. The second business data also includes information such as card identifier, contract identifier, and third application partition identifier. The contract identifier of the second business data is the same as the contract identifier of the first business data. The third application partition identifier is generated when the second business data is generated, according to the current mechanism for generating application partition identifiers; that is, the partition corresponding to the application partition identifier is the partition where the data was generated. The third application partition identifier may be generated based on the card identifier, or based on information other than the contract identifier. It is understood that the third application partition identifier in this application can be an application partition identifier determined in an existing manner.

[0062] The following describes step S103 with reference to Embodiment 1. In this embodiment, we take the determination of multiple contract data in the debit card contract file and the debit card file as cross-partition data as an example.

[0063] The implementation process of Example 1 is as follows:

[0064] The first application partition identifier corresponding to each piece of data in the debit card contract file is determined based on the contract identifier, and a base file is determined based on the contract identifier and the first application partition identifier. The full debit card contract file is then matched with the base file based on the contract identifier, and data in the full debit card contract file whose first application partition identifier and second application partition identifier differ are selected. Data with different first and second application partition identifiers are considered cross-partition data.

[0065] Using the same method, the full download file of the debit card file is matched with the baseline file based on the contract identifier, and the data in the full download file of the debit card file that are different between the first application partition identifier and the third application partition identifier are filtered out. Among them, the data that are different between the first application partition identifier and the third application partition identifier are cross-partition data.

[0066] Using this method, data in the full download files of the debit card contract file and the debit card file can be filtered simultaneously, improving the efficiency of identifying cross-partition data and thus improving the efficiency of business data migration.

[0067] In one or more embodiments, the data processing device may further obtain a card identifier from the third business data, wherein the third business data is data with an empty contract identifier; determine a fourth application partition identifier based on the card identifier, the fourth application partition identifier being associated with the third partition; and determine that the third business data is cross-partition data based on the fourth application partition identifier and the fifth application partition identifier of the third business data.

[0068] Optionally, the data processing device can determine the region identifier of the second partition based on the card identifier, and then determine the fourth application partition identifier based on the region identifier of the third partition.

[0069] Specifically, the third business data is data in the debit card file where the contract identifier is empty, such as pre-issued card data. The third business data also includes information such as the card identifier and the fifth application partition identifier. The fifth application partition identifier is generated when the third business data is generated, according to the current mechanism for generating application partition identifiers; that is, the partition corresponding to the application partition identifier is the partition where the data was generated. The fifth application partition identifier may be generated, for example, based on information other than the card identifier. It is understood that the fifth application partition identifier in this application can be an application partition identifier determined according to existing methods.

[0070] For example Figure 2 As shown, the data processing device can obtain the first application partition identifier or the fourth application partition identifier through the following steps:

[0071] In step S201, the data processing device determines whether the user identifier corresponding to the debit card contract identifier in the first business data has a value. If a value is found, step S202 is executed; otherwise, step S205 is executed. The debit card contract identifier is a contract identifier generated when the user applies for a primary card at the bank. Specifically, the data processing device can search for the debit card contract identifier key-value pair to determine whether the key-value pair contains a value.

[0072] S202, the data processing device acquires the user identifier from the first business data. The user identifier may be, for example, customer account information.

[0073] S203, the data processing equipment determines the corresponding area identifier and user number based on the user identifier.

[0074] Specifically, the data processing device can query the first table based on the user identifier to determine the corresponding area identifier and user number. The first table can include the correspondence between the user identifier, area identifier, and user number.

[0075] S204, the data processing device determines the first application partition identifier based on the area identifier corresponding to the user identifier and the user number.

[0076] For example, the first application partition identifier can consist of all the values ​​or symbols of the region identifier, the first three digits of the user ID, and the last two digits of the user ID.

[0077] In step S205, the data processing device determines whether the user identifier corresponding to the top-level contract identifier in the first business data has a value. If it does, step S206 is executed; otherwise, step S209 is executed. Similar to step S201, the data processing device can query the top-level contract identifier key-value pair to determine whether the value exists in the key-value pair.

[0078] Specifically, in this application, if the debit card contract identifier corresponding to the first business data is empty, it means that the debit card corresponding to the first business data is a non-primary card. If the debit card contract identifier corresponding to the first business data is empty, but the top-level contract identifier corresponding to the first business data has a value, it means that the debit card corresponding to the first business data is a first-level sub-card, wherein the top-level contract identifier corresponds to the debit card contract identifier of the primary card of the first-level sub-card;

[0079] S206, The data processing device obtains the value of the top-level contract identifier.

[0080] S207, the data processing device determines the corresponding area identifier and user number based on the top-level contract identifier.

[0081] Specifically, the data processing device can query the second table based on the top-level contract identifier to determine the corresponding region identifier and user number. The second table includes at least one top-level contract identifier, region identifier, user number, and the correspondence between the three.

[0082] S208, the data processing device determines the first application partition identifier based on the area identifier corresponding to the top-level contract identifier and the user number.

[0083] For example, the first application partition identifier can be composed of all the values ​​or symbols of the region identifier corresponding to the top-level contract identifier, the first three digits of the user number, and the last two digits of the user number.

[0084] In S209, the data processing device determines whether the user identifier corresponding to the main contract in the first business data has a value. If it has a value, it executes S210; otherwise, it executes S213. Similar to S201, the data processing device can query the main contract key-value pair to determine whether the value exists in the key-value pair.

[0085] Specifically, if the debit card contract identifier and the top-level contract identifier corresponding to the first business data are empty, but the main contract identifier corresponding to the first business data has a value, it means that the debit card corresponding to the first business data is a second-level sub-card, wherein the main contract identifier corresponds to the debit card contract identifier of the main card of the second-level sub-card;

[0086] S210, the data processing device obtains the value of the master contract identifier.

[0087] S211, the data processing device determines the corresponding area identifier and user number based on the master contract identifier.

[0088] Specifically, the data processing device can query the third table based on the master contract identifier to determine the corresponding region identifier and user number. The third table includes at least one master contract identifier, region identifier, user number, and the correspondence between the three.

[0089] S212, the data processing device determines the first application partition identifier based on the region identifier corresponding to the main contract identifier and the user number.

[0090] For example, the first application partition identifier can be composed of all the values ​​or symbols of the region identifier corresponding to the main contract identifier, the first three digits of the user number, and the last two digits of the user number.

[0091] S213, The data processing device obtains the card identifier, such as the debit card number, from the first business data.

[0092] Specifically, if the debit card contract identifier, main contract identifier, and top-level contract identifier corresponding to the first business data are all empty, it means that the debit card corresponding to the first business data is a card without a contract, that is, a card without an account, such as a pre-made card.

[0093] S214, the data processing device determines the corresponding area identifier and user number based on the card identifier.

[0094] Specifically, the data processing device can use the card identifier to query the fourth table to determine the corresponding region identifier and user number. The fourth table includes at least one card identifier, region identifier, user number, and the correspondence between the three.

[0095] S215, the data processing device determines the fourth application partition identifier based on the area identifier and user number corresponding to the card identifier.

[0096] For example, the fourth application partition identifier can consist of a region identifier, the first three digits of the user ID, and the last two digits of the user ID.

[0097] based on Figure 2 As shown in the process, the data processing device can determine the first application partition identifier based on the debit card contract identifier, the top-level contract identifier, or the master contract identifier, thus enabling data migration based on the first application partition identifier. However, in the absence of a debit card contract identifier, a top-level contract identifier, or a master contract identifier, a fourth application partition identifier can be obtained based on the card identifier. In this case, the first business data can be migrated based on the fourth application partition identifier.

[0098] For example, a data processing device can determine that third-party business data is cross-partition data in the following ways:

[0099] The data processing device obtains the card identifier from the third business data and determines the region identifier based on the card identifier. The data processing device then determines the fourth application partition identifier based on the region identifier. For example, the fourth application partition identifier can consist of the region identifier and five zeros, where the five zeros indicate that there is no user ID.

[0100] The data processing device determines that the third business data is cross-partition data because the partition corresponding to the fourth application partition identifier is inconsistent with the partition corresponding to the fifth application partition identifier.

[0101] It is understandable that in practical applications, the operation of S103 can be omitted. That is, after determining the first application partition number in S102, S104 is executed.

[0102] S104, the data processing device migrates the first business data to the database corresponding to the first partition according to the first application partition number.

[0103] The first business data can be existing data stored in the organization's database. Therefore, the data processing device can migrate the first business data from the existing data to the database corresponding to the first partition. Alternatively, the first business data can be migrated from the database corresponding to the second partition (when the first business data contains a second application partition identifier) ​​or the third partition (when the first business data contains a third application partition identifier) ​​to the data block corresponding to the first partition. It is understood that the database can be in the form of tables, etc. Furthermore, the database can adopt a centralized or distributed storage method, without specific limitations.

[0104] Optionally, before migrating the first business data to the database corresponding to the first partition, the data processing device can replace the second application partition identifier of the first business data with the first application partition identifier. Therefore, the first application partition identifier can be used as the unique application partition identifier for the first business data, avoiding confusion during data archiving.

[0105] In one or more embodiments, the data processing device can migrate the second business data to the database corresponding to the first partition. Optionally, before migrating the second business data to the database corresponding to the first partition, the data processing device can replace the third application partition identifier of the second business data with the first application partition identifier. Therefore, the first application partition identifier can be used as the unique application partition identifier of the second business data, avoiding confusion when archiving data.

[0106] Based on this embodiment, replacing the third application partition identifier with the first application partition identifier can avoid secondary data processing and improve data migration efficiency.

[0107] In one or more embodiments, assuming that the fourth application partition identifier and the fifth application partition identifier of the aforementioned third business data are different, the data processing device can migrate the third business data to the database corresponding to the third partition. Optionally, before migrating the third business data to the database corresponding to the third partition, the data processing device can also replace the fifth application partition identifier of the third business data with the fourth application partition identifier. Therefore, the fourth application partition identifier can be used as the unique application partition identifier of the third business data, avoiding confusion when archiving data.

[0108] In one or more embodiments, the data processing device may also read the table containing cross-partition data based on the card identifier and contract identifier of the cross-partition data, and then store the data in the table containing cross-partition data into the database of the corresponding partition based on the application partition identifier corresponding to the contract identifier.

[0109] Because the business data to be migrated is quite large, migrating all the data at once cannot guarantee stability and efficiency. Therefore, this application adopts a data migration method combining full-scale and incremental modes. Specifically, the data processing equipment can use full-scale mode to process the data and filter out cross-partition data one week before the specified migration date. On the specified migration date, the data processing equipment uses incremental mode to process the newly added data and filter out cross-partition data. Here, full-scale mode refers to the method for filtering cross-partition data provided by this invention. Incremental mode is irrelevant to this invention and will not be described in detail.

[0110] The existing data stored in this application also includes tables other than debit card contract files and debit card files. To ensure the complete migration of all business data to be migrated, this application performs additional processing on these other tables. Specifically, the debit card contract files contain user contract data, such as the first business data. The debit card files contain user card data, such as the second business data. Other tables refer to data tables that cannot be processed using the methods described above.

[0111] For example, other tables include: the processing method for the personal debit card BIN usage table (TBCRBIN0) is as follows: Based on the card BIN, TBCRBIN0 is matched with the personal debit card number generation rule table (TBCRCGR0). The bank card type code and city code usage level code corresponding to the card BIN in TBCRBIN0 are obtained; data in TBCRBIN0 whose city code usage level is not 03-virtual city code are filtered out, and the city code + bank card type is used as the key to match the personal debit card city code mapping table (…). Data from TBDCUCD0 with the institution number belonging to a lower-level provincial bank is matched to obtain data file A corresponding to the card BIN + city code parameter of the provincial bank's sub-database. Data from TBCRBIN0 with city codes whose usage level is not 03-virtual city code is then matched with the card BINs in the virtual city code table for personal debit cards (TBCRPVC0). Data with the institution number belonging to a lower-level provincial bank in TBCRPVC0 is then selected to obtain data file B corresponding to the card BIN + city code parameter of the provincial bank's sub-database. Files A and B together represent the card BIN parameter data used in a specific lower-level provincial bank's sub-database. The personal debit card overseas card BIN sequence number table (TBCRBIX0) is used to match the card BIN and city code as keys with TBCRBIN0 to obtain the corresponding data.

[0112] The processing methods for the private debit card external medium and contract relationship (TBCRMRR0) and the private debit card external medium (TBCRMRD0) are as follows: Obtain the corresponding application partition number based on the debit card contract number in TBCRMRR0; deduplicate the provincial branch database data corresponding to the application partition number based on the mobile payment device code (SEID) to obtain file A; match TBCRMRR0 with file A using SEID to obtain cross-provincial branch data. Similarly, match TBCRMRD0 with file A using SEID to obtain cross-provincial branch data.

[0113] The processing methods for private debit card reservation card applications (TBCRPLY0) and TBCRPLY1 are as follows: Using the debit card contract number in the partition file TBCRPLY0, the database table TBASCCC0 generated from the downstream transfer baseline file is read to obtain the provincial branch database corresponding to the contract number. The processed file is then re-filtered according to the distributed application partition number to identify the corresponding provincial branch. Each provincial branch corresponds to an independent downstream transfer data database file, where the downstream transfer baseline file includes the data to be migrated from the current provincial branch and the data from other provincial branches within the same province. The database table order is reorganized, and a redundant distributed data table TBCRPLY1 is constructed using multi-entity identifier, customer number, and reservation card application number as index keys.

[0114] The processing method for private debit cards awaiting activation (TBCRACR0) is as follows: the entire bank downloads the TBCRACR0 file of debit cards awaiting activation; the debit card number in TBCRACR0 is matched with the card number base file of the next branch to obtain the provincial branch database corresponding to the card number; the provincial branch has a corresponding independent data database file for the next branch.

[0115] The processing method for ATM special withdrawals using private debit cards (TBCRADR0) is as follows: TBCRADR0 is completely removed from the database across the entire bank; the customer account in TBCRADR0 is matched with the current account baseline file of the downstream branch to obtain the corresponding provincial branch database for special withdrawal table data; the provincial branch corresponds to an independent downstream database file.

[0116] The processing methods for the comprehensive private debit card contract (TBCRCSI0), comprehensive private debit card contract index 1 (TBCRCSI1), and comprehensive private debit card contract index 2 (TBCRCSI2) are as follows: TBCRCSI0 is downloaded to the entire bank; TBCRCSI0 itself can obtain the corresponding distributed application partition number by matching the key-value contract number with the downstream benchmark file, thus distinguishing the corresponding provincial branch database; TBCRCSI0 is the agreed transfer contract table, which, in addition to the primary key contract number (card number), also includes the transfer-in and transfer-out accounts for wealth management. These two accounts can be queried according to the corresponding index key value, so index information tables TBCRCSI1 and TBCRCSI2 need to be created in the distributed database to achieve this; since the transfer-in and transfer-out accounts for wealth management can be card numbers, contract numbers, or customer accounts, the corresponding provincial branch database is obtained by reading the database tables TBASBCC0 and TBASCCC0 generated by the downstream benchmark file, and the index key value is reorganized; thus, the independent downstream data database file corresponding to each table and each provincial branch is obtained.

[0117] The processing method for student benefit subscription information (TBCRSIG0) and TBCRSIG1 for private debit cards is as follows: TBCRSIG0 is downloaded to the entire bank; the customer account in TBCRSIG0 is matched with the baseline file of the current account of the downstream branch to obtain the provincial branch's database corresponding to the student benefit subscription data; each provincial branch has an independent downstream database file. In actual transactions, the student benefit subscription information of a customer can be queried through the customer number index, so a redundant index table TBCRSIG1 is created in the distributed database, and the data is distributed to the corresponding data cluster according to the first three digits of the customer number.

[0118] The method provided in this application can be used to migrate data from a host database to a distributed database. Since the storage methods of distributed databases and host databases are different, and the amount of bank data to be migrated is huge, this application also provides a bank-wide routing index table to accurately identify the database corresponding to the bank data to be migrated, thereby improving the migration efficiency and accuracy of bank data.

[0119] Specifically, obtain all card numbers and contract data corresponding to the provincial branches in the distributed database, and load the full data into the routing index database according to the routing index rules. The contract data includes data from the provincial branches in the distributed database as well as corresponding cross-provincial branch data.

[0120] For example, indexing rules can take the following form:

[0121] Card Number: Debit Card Number + APD0101 + 7-digit basket number (0 + 3-digit logical provincial branch number + first 3 digits of customer number) + 2-digit scattered module number (last 2 digits of distributed application partition number) + 2-digit free trade zone symbol + 7-digit account category (DC00002) + public-private symbol (1-private) + 32-digit matching account number + 23-digit contract number + 1-digit quasi-credit card limit symbol.

[0122] Contract Number: Debit Card Contract Number + APD0102 + 7-digit basket number (0 + 3-digit logical provincial bank number + the first 3 digits of the customer number) + 2-digit random number (the last 2 digits of the distributed application partition number).

[0123] Mobile payment device code (SEID): Device media type + SEID code + APD0105 + 7-digit basket number (0 + 3-digit logical provincial bank number + 000).

[0124] Automated Teller Machine (ATM) withdrawal code: ATM withdrawal code + APD0123 + 7-digit basket number (0 + 3-digit logical provincial bank code + the first 3 digits of the customer's number).

[0125] Reservation card application number: Reservation card application number + APD0124 + 7-digit basket number (0 + 3-digit logical provincial branch number + the first 3 digits of the customer number).

[0126] Pre-made card application number: application date + serial number (expanded) + APD0125++7-digit basket number (0+3-digit logical provincial bank number+000).

[0127] In addition, since the data of each provincial branch is stored in the corresponding distributed database, in order to avoid data isolation and the generation of the same card number, the uniqueness of the card number cannot be guaranteed. Therefore, this application also provides a number selection parameter table TBCRPSN0 number conversion method.

[0128] The specific implementation is as follows:

[0129] Obtain card number data file A from all debit card files across the entire bank; filter all TBDUCD0 data, and obtain the bank card type + issuing city code by institution code; filter non-virtual city code card BINs in TBCRCGR0, and obtain the Cartesian product of card BIN and city code corresponding to the card type according to the card number generation rule by matching the bank card type with the data filtered by TBDUCD0; split this file into 3 parts: 5-digit card BIN city code, 6-digit card BIN city code, and 8-digit card BIN city code; match file A with the 3 card BIN city code data respectively, according to the matching rule: data that cannot be matched by the current bank and data that cannot be matched by other banks. Integrate the valid data to obtain the bank-wide card selection parameter file.

[0130] Understandably, this parameter file compiles data on all non-bank card BINs that can generate card numbers and selectable card numbers, effectively avoiding the problem of generating the same card number due to data isolation and ensuring the uniqueness of card numbers.

[0131] This application also includes code conversion of the bank data to be migrated.

[0132] For example, converting code values ​​supported by the host database to code values ​​supported by the distributed database. The following methods can be used for code conversion:

[0133] The distributed database uses 8-bit (UTF-8) encoding, while the host database uses E-code. Because their code values ​​differ, encoding conversion is necessary before data migration. Furthermore, due to previous improper assignments or incorrect manual input, garbled characters may occur. Therefore, the encoding conversion program needs specific handling based on the actual situation before use. For example, TBCRCHG0 is an incident file where some transactions were sent in UTF-8 encoding, causing the UTF-8 encoding to be converted back into garbled characters during the encoding conversion process. Therefore, before encoding conversion, it is necessary to identify the fixed assignments of specific transactions through big data retrieval and then perform specific processing on the encoding conversion program to avoid this problem.

[0134] Furthermore, since some sensitive information appears as invisible characters generated according to certain rules in the host database, but should be recognizable characters in the distributed database, this application also employs BASE64 encoding conversion to transcode sensitive information, converting invisible characters into recognizable characters. For example, sensitive information such as ciphertext values ​​stored on two tracks, CVV security index numbers, ciphertext values ​​stored on CVV2, CVV2 security index numbers, debit card PIN OFFSET values, ciphertext values ​​stored on three tracks using CVV, equivalent ciphertext information stored on two tracks, and equivalent CVV security index numbers stored on two tracks can be transcoded using BASE64 encoding conversion. Specific conversion methods can be found in the processing rules in Table 1.

[0135]

[0136]

[0137] Table 1

[0138] In this application, after the data code value conversion is completed, the data can also be uploaded to a distributed database via a pre-set script. For example, the corresponding database table file can be transmitted from the host to the open server via a serial port, and then the file can be loaded into the database via a script.

[0139] After data migration is completed, this application can also perform data verification to ensure the accuracy of the migrated bank data. The specific implementation method is as follows: Data verification can be divided into intra-component verification, inter-component verification, and incremental verification. Intra-component verification can be performed in the following ways:

[0140] The component internal check is divided into two parts: the testing phase and the digital transformation exercise phase.

[0141] During the testing phase, a random sample of data from each table was manually reviewed. The key points of this manual review included: verifying the accuracy of partition number conversion, field encoding, and the encoding of sensitive fields.

[0142] During the data conversion exercise phase, data volume comparison was used to ensure a complete match between the downstream data volume and the distributed upstream data volume. Statistics were compiled using tasks and script tools. The statistical dimensions included downstream data, cross-provincial filtered data, converted data, and upstream data.

[0143] Inter-component checks can be performed in the following ways: Inter-component checks mainly check whether the dependencies are correct and whether the data files provided by the components are correct.

[0144] Incremental verification can be conducted in the following ways: Incremental verification can be divided into a testing phase and a data transfer exercise phase. In the testing phase, customer number changes are tested to ensure that the operations and procedures meet the requirements. In the data transfer exercise phase, a new full-volume comparison mode is used to ensure that the data generated by the new full-volume comparison is consistent with the one-time full-volume comparison. Specifically, the implementation is as follows: merge the first full-volume download file and the second incremental download file, sort them by timestamp to remove duplicates (file 1); add a second full-volume download file (file 2); perform a full-field match between file 1 and file 2, and identify the differences between file 1 and file 2.

[0145] This method avoids discrepancies arising from multiple data conversions, identifies redundant data, and ensures data consistency, thereby guaranteeing the accuracy of the migrated bank data.

[0146] After completing data migration and data verification, this application can also delete data generated during data conversion on the host machine to prevent transactions from re-identifying existing data. Specifically, the data cleanup principles are as follows: parameter tables are not cleaned; a data synchronization mechanism is used to ensure consistency between the distributed and host systems for data cleanup; 24-hour tables do not require cleanup; tables that can identify provincial branch partitions will be cleaned by partition, and cross-provincial branch data will be deleted row by row using DELETE BY KEY; special cases: TBCRSIG0 and TBCRPLY0, as well as customer dimension tables TBCRCNT0\TBCRCIL0\TBCRCUQ0, will not be deleted on the host machine because customer dimension information will not be shifted down due to branch switching; the two systems will use a data synchronization mechanism to achieve data unification.

[0147] Based on the above content and the same concept, this application provides a business data migration apparatus. For example... Figure 3 As shown, the device includes an acquisition module 301 and a processing module 302.

[0148] The acquisition module 301 is used to obtain the contract identifier from the first business data;

[0149] Processing module 302 is used to determine a first application partition identifier based on the contract identifier, wherein the first application partition identifier is associated with a first partition;

[0150] Processing module 302 is further configured to determine that the first business data is cross-partition data based on the first application partition identifier and the second application partition identifier of the first business data, wherein the second application partition identifier is associated with the second partition; and to migrate the first business data to the database corresponding to the first partition.

[0151] In one possible embodiment, the processing module 302 is specifically configured to determine the region identifier of the first partition based on the contract identifier; and to determine the first application partition identifier based on the region identifier of the first partition.

[0152] In one possible embodiment, the processing module 302 is further configured to determine, based on the first application partition identifier and the third application partition identifier of the second business data, that the second business data includes the contract identifier and that the second business data is the user's card data; and to migrate the second business data to the database corresponding to the first partition.

[0153] In one possible embodiment, the acquisition module 301 is further configured to acquire a card identifier from the third business data, wherein the third business data is data with an empty contract identifier; the processing module 302 is further configured to determine the fourth application partition identifier based on the card identifier, wherein the fourth application partition identifier is associated with the third partition; the processing module 302 is further configured to determine that the third business data is cross-partition data based on the fourth application partition identifier and the fifth application partition identifier of the third business data.

[0154] In one possible embodiment, the processing module 302 is specifically configured to determine the region identifier of the second partition based on the card identifier; determine the fourth application partition identifier based on the region identifier of the second partition; and migrate the third service data to the database corresponding to the third partition.

[0155] Figure 4 A schematic diagram of an electronic device structure provided in an embodiment of this application is shown.

[0156] The electronic device in this embodiment may include a processor 401. The processor 401 is the control center of the device, and can connect to various parts of the device via various interfaces and lines, executing instructions stored in the memory 403 and accessing data stored in the memory 403. Optionally, the processor 401 may include one or more processing units. The processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401. In some embodiments, the processor 401 and the memory 403 may be implemented on the same chip; in some embodiments, they may be implemented separately on independent chips.

[0157] Processor 401 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The methods and steps disclosed in the embodiments of this application can be directly executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0158] In this embodiment of the application, the memory 403 stores instructions that can be executed by at least one processor 401. By executing the instructions stored in the memory 403, the at least one processor 401 can perform the method steps disclosed in this embodiment of the application.

[0159] Memory 403, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 403 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 403 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 403 may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0160] In this embodiment of the application, the device may further include a communication interface 402, through which the electronic device can transmit data.

[0161] Optional, can be made by Figure 4 The processor 401 (or processor 401 and communication interface 402) shown implements... Figure 3The processing module 302 and / or the acquisition module 301 shown mean that the actions of the processing module 302 and / or the acquisition module 301 can be executed by the processor 401 (or the processor 401 and the communication interface 402).

[0162] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium that can store instructions, which, when executed on a computer, cause the computer to perform the operation steps provided in the above-described method embodiments. This computer-readable storage medium may be... Figure 4 The memory 403 shown.

[0163] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0164] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0165] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0166] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxesFigure 1 The steps of the function specified in one or more boxes.

[0167] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method of migrating service data, characterized by, The method comprises: obtaining a contract identifier from first service data; determining a first application partition identifier according to the contract identifier, the first application partition identifier being associated with a first partition; determining that the first service data is cross-partition data according to the first application partition identifier and a second application partition identifier of the first service data, the second application partition identifier being associated with a second partition; the second application partition identifier being an application partition identifier generated according to an existing mechanism for generating application partition identifiers when the first service data is generated, and the application partition identifier corresponding partition being a partition where the service data is generated; migrating the first service data to a database corresponding to the first partition; the determining of the first application partition identifier according to the contract identifier comprises: determining a region identifier of the first partition according to the contract identifier; determining the first application partition identifier according to the region identifier of the first partition, the first application partition identifier corresponding partition being a partition where a main card of a user belongs; the determining of the first service data as cross-partition data according to the first application partition identifier and the second application partition identifier of the first service data comprises: if the first application partition identifier corresponding partition and the second application partition identifier corresponding partition are different, determining that the first service data is cross-partition data.

2. The method of claim 1, wherein, The first service data is contract data of a user, and the method further comprises: determining that second service data is cross-partition data according to the first application partition identifier and a third application partition identifier of the second service data, the second service data comprising the contract identifier, and the second service data being card data of the user.

3. The method of claim 2, wherein, The method comprises: migrating the second service data to a database corresponding to the first partition.

4. The method of claim 1, wherein, The method further comprises: obtaining a card identifier from third service data, the third service data being data with an empty contract identifier; determining a fourth application partition identifier according to the card identifier, the fourth application partition identifier being associated with a third partition; determining that the third service data is cross-partition data according to the fourth application partition identifier and a fifth application partition identifier of the third service data.

5. The method of claim 4, wherein, The determining of the fourth application partition identifier according to the card identifier comprises: determining a region identifier of the second partition according to the card identifier; determining the fourth application partition identifier according to the region identifier of the second partition.

6. The method of claim 4, wherein, The method comprises: migrating the third service data to a database corresponding to the third partition.

7. An apparatus for migrating service data, characterized by comprising: The apparatus comprises: an obtaining module configured to obtain a contract identifier from first service data; The processing module is configured to determine a first application partition identifier according to the contract identifier, the first application partition identifier being associated with a first partition; determine, according to the first application partition identifier and a second application partition identifier of the first service data, that the first service data is cross-partition data, the second application partition identifier being associated with a second partition; and migrate the first service data to a database corresponding to the first partition; wherein the second application partition identifier is an application partition identifier generated according to an existing mechanism for generating an application partition identifier when the first service data is generated. When determining the first application partition identifier according to the contract identifier, the processing module is specifically configured to: determine a region identifier of the first partition according to the contract identifier; determine the first application partition identifier according to the region identifier of the first partition, the first application partition identifier corresponding to a partition to which a main card of the user belongs. When determining, according to the first application partition identifier and a second application partition identifier of the first service data, that the first service data is cross-partition data, the processing module is specifically configured to: if the partition corresponding to the first application partition identifier is different from the partition corresponding to the second application partition identifier, determine that the first service data is cross-partition data.

8. The apparatus of claim 7, wherein, The processing module is further configured to: determine, according to the first application partition identifier and a third application partition identifier of second service data, that the second service data is cross-partition data, the second service data including the contract identifier, and the second service data being card data of the user.

9. The apparatus of claim 8, wherein, The processing module is specifically configured to: migrate the second service data to the database corresponding to the first partition.

10. The apparatus of claim 7, wherein: the obtaining module is further configured to obtain a card identifier from third service data, the third service data being data with an empty contract identifier; the processing module is further configured to determine a fourth application partition identifier according to the card identifier, the fourth application partition identifier being associated with a third partition; the processing module is further configured to determine, according to the fourth application partition identifier and a fifth application partition identifier of the third service data, that the third service data is cross-partition data.

11. The apparatus of claim 10, wherein, The processing module is specifically configured to: determine a region identifier of the second partition according to the card identifier; determine the fourth application partition identifier according to the region identifier of the second partition.

12. The apparatus of claim 10, wherein, The processing module is specifically configured to: migrate the third service data to a database corresponding to the third partition.

13. An electronic device, comprising: comprises: a memory configured to store program instructions; a processor configured to invoke the program instructions stored in the memory and perform steps included in the method of any one of claims 1-6 according to the obtained program instructions.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program comprising program instructions, the program instructions causing the computer to execute the method of any one of claims 1-6 when executed by the computer.

15. A computer program product, characterised in that, The computer program product comprises computer program code which, when run on a computer, causes the computer to perform the method according to any one of claims 1-6.

Images