Data consanguinity implementation method based on logistics supply chain event collection

Abstract

The invention discloses a data consanguinity implementation method based on logistics supply chain event collection, which specifically comprises the following steps: a client sends a business SQL (Structured Query Language) needing to be analyzed according to a logistics demand, and an analyzer receives the business SQL to carry out lexical analysis and grammatical analysis; constructing a syntax tree according to the SQL syntax rule, checking whether the combination of the lexical units in the service SQL accords with the syntax rule or not, and if unsupported syntax elements are found in the lexical analysis or syntax analysis process, throwing syntax exceptions by the analyzer, generating an exception report and returning the exception report to the client; the SQL grammar conforming to the grammar rule selects a workflow type task or selects a single SQL task according to a self-defined strategy; if the workflow type task is selected, the workflow type task enters a workflow IPO analysis module, the IPO analysis module encapsulates the logic of the workflow type task into a graph object, the graph object is disassembled into different sub-SQL statements, and each sub-SQL statement is a self-defined syntax tree; and finally, returning an analysis result of the IPO analysis module to the client.

Description

Technical Field

[0001] The present invention relates to the field of data analysis, and mainly to a method for realizing data lineage based on logistics supply chain event collection. Background Art

[0002] In today's era of information explosion, logistics companies are facing the challenges of rapid data growth and complex and diverse data sources. Through lineage tracking, it is possible to accurately trace the data and products provided by each supplier and evaluate their quality and reliability.

[0003] In the actual use of data, the lineage of data should be clarified from the data perspective, that is, to find out what database and table the data is stored in, what the corresponding fields are, and the attributes of the fields; the lineage of data should be clarified from the business perspective, that is, to understand the business line to which the data belongs, the output logic of business data, the use logic of data, and the relationship between business lines. Data lineage not only helps logistics companies understand where the data comes from, but also can track the operation and flow of data, providing comprehensive data context.

[0004] By building a comprehensive and accurate full-link data lineage view, we can find out the upstream and downstream application methods of data, and do a good job of communication and information synchronization. For services that have not been called for a long time, we can promptly handle them offline to save data costs. While improving the efficiency of data problem troubleshooting, we can also better understand the flow and impact of data, so as to make more accurate decisions and optimization measures in the data governance process.

[0005] Data lineage plays a vital role in logistics data management and governance. It involves the entire life cycle of data from source, flow, processing to final application. Although data lineage has many advantages, it also faces many technical difficulties in the actual implementation process. For example, the automatic parsing and tracking of data lineage in the supply chain is a complex technical challenge, which requires parsing SQL to identify and track the relationship between tables and fields. This usually involves the operation of AST (abstract syntax tree) and the use of graph databases. Summary of the invention

[0006] In view of the above shortcomings, the present invention proposes a data lineage realization method based on logistics supply chain event collection, and the specific steps are as follows:

[0007] The logistics supply chain sends the business SQL that needs to be parsed according to the logistics demand, and the SQL syntax parser receives the business SQL for lexical analysis and syntax analysis;

[0008] Construct a syntax tree according to SQL syntax rules, check whether the combination of lexical units in the business SQL complies with the syntax rules, and if unsupported syntax elements are found during lexical analysis or syntax analysis, the SQL syntax parser will throw a syntax exception and generate an exception report and return it to the client;

[0009] The SQL syntax that conforms to the grammatical rules selects a workflow type task or a single SQL task according to a custom strategy; if the workflow type task is selected, it will enter the workflow IPO parsing module, in which the logic of the workflow type task will be encapsulated into a graph type logical object, and the graph type logical object will be disassembled into different sub-SQL statements, each of which is a custom syntax tree; finally, the parsing result of the IPO parsing module is returned to the logistics client.

[0010] Furthermore, the lexical analysis specifically includes decomposing the SQL statement into lexical units, and the lexical units include keywords, identifiers, operators and constants.

[0011] The purpose of lexical analysis is to identify lexical units. During the identification process, an internal data structure, such as a token sequence, is generated, which can be used for subsequent grammatical analysis.

[0012] Furthermore, the exception report includes the location where the exception occurred and the error type, wherein the error type includes syntax errors and keyword errors.

[0013] Anomaly detection can improve the clarity of syntax, increase the resilience of the entire business code, and enhance readability.

[0014] Furthermore, the judgment criteria for the single SQL task is a data operation with a single syntax; the judgment criteria for the workflow type task is the presence of preset keywords or structures in the syntax and the associated statements containing more than one data processing step.

[0015] If it is neither a single SQL task nor a workflow type task, it is determined to be a non-workflow task, and the syntax is further verified, specifically including: checking each component of the syntax of the non-workflow task in turn to see if it conforms to the predefined syntax specifications; if unsupported syntax elements appear, a syntax exception is thrown, and an exception report is generated and returned to the client.

[0016] Furthermore, the graph-type logical object specifically includes organizing the tasks into a directed graph or a directed tree, which clearly shows the relationship and flow between the various steps in the workflow.

[0017] The parsing results of the IPO parsing module are divided into two modules: two logical lineages decomposed from the graph and the tree:

[0018] As table lineage results at the workflow level, graph-type logical objects represent the data flow of multi-table input and multi-table output.

[0019] The syntax tree, as a field lineage result, represents the field changes of the internal fields of a single data table from the innermost data source to the final output data result field.

[0020] According to a second aspect of the present invention, a computer program product is provided, on which one or more computer programs are stored. When the one or more computer programs are executed by a computer processor, the above method is implemented.

[0021] The above one or more technical solutions in the embodiments of the present application have at least one of the following technical effects:

[0022] 1) Supply chain transparency

[0023] Supply chain data flow tracking: In supply chain management, lineage tracking can help monitor the entire process of products from raw materials to end consumers, ensuring that data at each link is accurate and compliant.

[0024] Supplier management: Through lineage tracking, the data and products provided by each supplier can be accurately traced and their quality and reliability can be evaluated.

[0025] 2) Logistics optimization and scheduling

[0026] Transportation data monitoring: Through data lineage, enterprises can track every operation in the transportation process, including the loading and unloading of goods, transportation status and delivery, to help optimize logistics scheduling and improve transportation efficiency.

[0027] Inventory management: Lineage tracking can help understand the flow of inventory data from procurement, storage to sales, ensuring the accuracy of inventory management. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated into and constitute a part of this specification. The accompanying drawings illustrate the embodiments and are used together with the description to explain the principles of the present invention. It will be easy to recognize other embodiments and many expected advantages of the embodiments because they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale with each other. The same reference numerals refer to corresponding similar parts.

[0029] Figure 1 A flow chart of a method for implementing data lineage based on logistics supply chain event collection according to an embodiment of the present invention is shown.

[0030] Figure 2It is a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0031] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It should also be noted that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0032] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0033] Figure 1 FIG. 1 is a flow chart showing a method for realizing data lineage based on logistics supply chain event collection according to an embodiment of the present invention. Figure 1 As shown:

[0034] The logistics client sends the business SQL (which can be single or multiple SQLs) that needs to be parsed according to logistics requirements;

[0035] The SQL syntax parser parses and judges the received business SQL statements. The specific steps include: performing lexical analysis on the business SQL statements and decomposing the SQL statements into lexical units such as keywords, identifiers, operators and constants;

[0036] The main task of lexical analysis is to decompose the input SQL statement into a series of lexical units (Tokens), which can be keywords, identifiers, constants, operators, etc. The SQL syntax parser will split the SQL query into smaller parts according to the predefined lexical rules and identify them one by one.

[0037] In some specific embodiments, the composition of the lexical unit includes:

[0038] Keywords: such as SELECT, FROM, WHERE, etc.

[0039] Identifiers: such as table names, column names, database names, etc.

[0040] Constants: such as string constants (John), numeric constants (100), and date constants (2024-12-24).

[0041] Operators: such as =, >, <, AND, OR, etc.

[0042] Separators: such as brackets, commas, semicolons, etc.

[0043] Further syntax analysis is performed, a syntax tree is constructed according to SQL syntax rules, and whether the combination of lexical units conforms to the syntax rules is detected. If unsupported syntax elements are found during lexical analysis or lexical analysis, such as unrecognized keywords, data types that do not conform to the specifications, etc., the SQL syntax parser will throw a syntax exception and generate a detailed exception report including the location of the exception and the error type and return it to the client. The error type includes syntax error, keyword error, etc. At this point, the SQL syntax parser process ends;

[0044] The task of syntax analysis is to string together lexical units according to the syntax rules of SQL (usually a syntax tree generated by the grammar) to generate a syntax tree that complies with the SQL language specification. The SQL syntax analyzer will check whether the syntax structure complies with the expected rules.

[0045] The syntax tree is a tree structure that reflects the hierarchical relationship between the components of an SQL query, for example:

[0046] The SQL statement is:

[0047]

[0048] Converted to a syntax tree:

[0049]

[0050]

[0051] Among them, order_id is the unique identifier of the order; delivery_date is the delivery date of the order; shipments is the table that stores the transportation order data; shipment_status = 'to be shipped' is the filter condition, querying all orders with the status of "to be shipped".

[0052] Through recursive calls, each part (such as SELECT statement, FROM clause, WHERE clause, etc.) is parsed layer by layer according to the grammatical rules of SQL syntax.

[0053] When checking for abnormal content, it specifically includes checking whether the tables and columns referenced in the statement exist in the corresponding database; checking whether the data types on both sides of the operator are compatible. For example, in the statement 'WHERE age='John", the age column is an integer type, but the right value is a string, which is semantically incompatible. In this case, an abnormal error report will be issued.

[0054] In the exception report, if the referenced table or column does not exist, an "invalid identifier" or "non-existent table / column" error is thrown; if the data type does not match, a "data type error" is thrown; if the wrong type of parameter is passed to the function, a "function call error" is thrown.

[0055] The SQL grammar that passes the verification will select a workflow-type task or a single SQL task according to the custom strategy, including: a set of strategy rules are preset in the system. When the grammar contains specific keywords or structures, it will be judged as a workflow-type task, such as an associated statement containing multiple data processing steps; when the grammar is relatively simple and only involves a single data operation, it will be judged as a single SQL task; if it is a non-workflow task, it will determine whether the corresponding grammar is supported based on the grammar type. If unsupported grammar elements are found, such as unallowed function calls or data type mismatches, the system will throw a grammar exception and return detailed exception information to the client;

[0056] The specific judgment criteria of the strategy rule are as follows: if the SQL statement contains multiple JOINs or complex ON conditions, the system will judge it as a workflow task; SQL containing multi-level queries, nested subqueries or WITH statements will also be identified as a workflow task; if the SQL statement involves batch data update, deletion, and insertion operations in multiple steps, it will also be classified as a workflow task;

[0057] If an SQL statement contains only one data processing step, such as a single SELECT query, INSERT, UPDATE, or DELETE operation, and does not have complex logic or multi-table associations, multi-level subqueries, complex joins, or multiple operation steps, it is considered a single SQL task.

[0058] If the syntax itself does not contain multiple steps, the system will determine whether it complies with the legality of the SQL language. If it contains unsupported SQL functions (such as database-specific custom functions, specific data types, etc.), the system will detect and mark it as a non-workflow task.

[0059] In summary, the policy rules include three judgment rules:

[0060] Rule 1: If the SQL statement contains associations between multiple tables (such as JOIN), it is determined to be a workflow task.

[0061] Rule 2: If the SQL statement only involves operations such as query, update, insert, or delete on a single table, it is considered a single SQL task.

[0062] Rule 3: If the SQL statement does not contain multiple steps but complies with the legality of the SQL language, it is judged as a non-workflow task.

[0063] Workflow-type tasks enter the workflow IPO parsing module, which is specifically an input-execution-output parsing module. In this module, the workflow task logic will be encapsulated into a graph-type logical object, which can be a directed graph or a directed tree, which can clearly show the relationship and flow between each step in the workflow.

[0064] The logical objects of graph type will be decomposed into different sub-SQLs. Each sub-SQL is a custom syntax tree. For example, a workflow graph object contains three nodes: A, B, and C. Node A corresponds to the sub-SQL for input data preparation, node B corresponds to the sub-SQL for data processing, and node C corresponds to the sub-SQL for output results. In this way, the specific process of decomposing the graph object into sub-SQLs is displayed;

[0065] The above graph and tree decompose into two logical lineages:

[0066] 1) Table lineage at the workflow level (graph level), which indicates the data flow of multiple table inputs and outputs. The data in the logistics supply chain is often distributed in multiple tables, covering multiple areas such as order management, transportation management, inventory management, customer information, etc.

[0067] The lineage of the workflow level is represented by a graph, where nodes represent tables or data sets, and edges represent the flow relationship between data. The direction of each edge indicates that data flows from one table to another, and the attributes of the edge may contain information about data changes (e.g., update, delete, insert, etc.).

[0068] In the data flow, a workflow task may involve multiple data tables (or data sources). Through lineage tracing, it can be clearly shown how these data tables are related to each other through different operation steps (such as JOIN, UNION, SELECT, etc.) to finally form a result.

[0069] When multiple tables participate in data input (such as JOIN, UNION, etc.), the lineage graph needs to reflect the relationship between the input data tables. For example, in a SQL query, there may be JOIN operations of multiple tables, and the lineage graph will show how the fields of each table participate in the formation of the final result.

[0070] For example:

[0071] SELECT a.name,b.salary

[0072] FROM employees a

[0073] JOIN salaries b ON a.employee_id=b.employee_id;

[0074] The employees table and the salaries table are input tables, which are connected through the employee_id field. The lineage diagram can reflect the relationship between the two tables.

[0075] In multi-table related queries, the dependency between data tables is critical. The blood relationship helps track the impact of changes in source data on target data, especially when data is updated or modified, to ensure data integrity and consistency.

[0076] 2) Field lineage (tree level), which indicates the field changes of a single table's internal fields from the innermost data source to the final output data result field. It can help us understand how data is converted, calculated, and transmitted at the field level. Field lineage in the logistics supply chain usually refers to the change path from the original data source to the calculated result field.

[0077] Field lineage describes the change track of a field, including how the field is converted and calculated from the original field of the source data table to finally form the query result field. It helps track the changes of fields at different query stages, avoid errors in field calculations, and improve the fault tolerance of goods during the logistics delivery process.

[0078] The value of a field may depend on the values ​​of other fields. Field lineage tracking helps to clarify the dependencies between fields. Through field lineage, you can also trace back to the source of each field to ensure that each link in the data processing process meets expectations, thereby improving data quality.

[0079] The lineage of each field starts from the field of the original data table. In the data table, each field is introduced from the data source, and field lineage tracking can show the source of the field. For example, in the query:

[0080] SELECT product_id,SUM(amount)AS total_sales

[0081] FROM sales

[0082] GROUP BY product_id;

[0083] Among them, product_id is the unique identifier of the product; amount is the sales amount of the product in each sales record; SUM(amount) adds up all sales amounts of the same product (grouped by product_id) to get the total sales of the product; GROUP BY product_id means grouping by product_id, that is, one sales record for each product. The fields product_id and amount are directly imported from the sales table, and these fields constitute the source fields of the query.

[0084] In SQL queries, fields may undergo calculations, transformations, or aggregations. For example, in SUM(amount), the amount field is aggregated to form the total_sales field, which constitutes a field evolution process. In the field lineage tree, total_sales will depend on the amount field.

[0085] The final output field is the combination or calculation result of the original fields. For example, after multiple JOIN, WHERE, GROUP BY and other operations, the final result field is generated. The field lineage tree can clearly show this process.

[0086] Field lineage tracking allows you to accurately understand the source of each field and ensure data accuracy. This helps developers identify problem fields and potential errors in data flows, especially in complex queries and data transformations.

[0087] Field lineage can also help developers clearly see the process of field evolution. In logistics:

[0088] Order management and sales tracking: The sales table contains the amount of each sale, which can be summarized by product_id to get the total sales of each product. This is very important for supply chain management because it can help predict which products have high demand, thus affecting inventory and transportation plans.

[0089] Inventory management: Once we have calculated the total sales for each product, we can combine this information with the inventory quantity in the inventory table to evaluate the inventory turnover of the product. If a product has high sales but low inventory, it may be necessary to increase procurement or readjust the logistics and transportation plan.

[0090] Supply chain decision support: By analyzing the sales of each product, management can make more targeted purchasing, production, transportation and inventory management decisions. For example, if a product has high sales, the supply chain management team may strengthen the inventory and transportation arrangements for that product.

[0091] Workflow lineage and field lineage complement each other in the data processing process. They focus on data flow and field changes respectively, but the ultimate goal is to achieve complete data tracking and traceability. Workflow-level lineage helps developers and data analysts understand the flow of data across tables and clarify the dependencies between different tables. It is suitable for scenarios such as multi-table query, data integration, and data pipelines. Field-level lineage helps track the evolution of a single field from source data to output results. It is suitable for scenarios such as field-level data quality monitoring, field transformation, and aggregate analysis.

[0092] Through the combination of these two lines of kinship, users can comprehensively track the flow and changes of data at both high-level (cross-table) and fine-grained (field level) dimensions, thereby providing more sophisticated monitoring, debugging, optimization and data quality assurance.

[0093] Finally, the parsing result is returned to the client and the process ends.

[0094] In summary, the present invention realizes the comprehensive realization of the flow direction and processing process of single or multiple data under different big data components. By using the implementation method of the present invention, the lineage of the workflow is not connected to any metadata for metadata verification. When actually operating a single SQL or a group of SQL groups with a source end and a target end, the lineage of the workflow can determine the data flow direction of the table or field by disassembling the syntax, and then parse out the corresponding data lineage. Without the metadata verification step, the timeliness of pure syntax analysis of data lineage will be faster and lighter.

[0095] Reference below Figure 2 , which shows a schematic diagram of the structure of a computer system 200 suitable for implementing an electronic device of an embodiment of the present application. Figure 2 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0096] like Figure 2 As shown, the computer system 200 includes a central processing unit (CPU) 201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 202 or a program loaded from a storage part 208 into a random access memory (RAM) 203. In the RAM 203, various programs and data required for the operation of the system 200 are also stored. The CPU 201, the ROM 202, and the RAM 203 are connected to each other via a bus 204. An input / output (I / O) interface 205 is also connected to the bus 204.

[0097] The following components are connected to the I / O interface 205: an input section 206 including a keyboard, a mouse, etc.; an output section 207 including a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 208 including a hard disk, etc.; and a communication section 209 including a network interface card such as a LAN card, a modem, etc. The communication section 209 performs communication processing via a network such as the Internet. A drive 210 is also connected to the I / O interface 205 as needed. A removable medium 211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 210 as needed, so that a computer program read therefrom is installed into the storage section 208 as needed.

[0098] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 209, and / or installed from the removable medium 211. When the computer program is executed by the central processing unit (CPU) 201, the above functions defined in the method of the present application are executed. It should be noted that the computer-readable storage medium of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection with one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wireline, optical cable, RF, etc., or any suitable combination of the foregoing.

[0099] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0100] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0101] The modules involved in the embodiments of the present application may be implemented by software or by hardware.

[0102] As another aspect, the present application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiment; or it may exist alone and not be assembled into the electronic device. The above computer-readable storage medium carries one or more programs. When the above one or more programs are executed by the electronic device, the electronic device: the logistics client sends the business SQL to be parsed according to the logistics demand, and the parser receives the business SQL for lexical analysis and syntax analysis; builds a syntax tree according to the SQL syntax rules, checks whether the combination of lexical units in the business SQL conforms to the syntax rules, and if unsupported syntax elements are found during the lexical analysis or syntax analysis process, the parser throws a syntax exception and generates an exception report and returns it to the client; the SQL syntax that conforms to the syntax rules selects a workflow type task or a single SQL task according to a custom strategy; if a workflow type task is selected, it will enter the workflow IPO parsing module, and the IPO parsing module encapsulates the logic of the workflow type task into a graph type logic object, and the graph type logic object is disassembled into different sub-SQL statements, each sub-SQL statement is a custom syntax tree; finally, the parsing result of the IPO parsing module is returned to the client.

[0103] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above invention concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.

Claims

1. A data lineage realization method based on logistics supply chain event collection, characterized in that: include: The logistics client sends the business SQL to be parsed according to the logistics demand, and the SQL syntax parser receives the business SQL for lexical analysis and syntax analysis; Construct a syntax tree according to SQL syntax rules, check whether the combination of lexical units in the syntax tree conforms to the syntax rules, and if unsupported syntax elements are found during lexical analysis or syntax analysis, the SQL syntax parser will throw a syntax exception and generate an exception report and return it to the client; The SQL syntax that conforms to the grammatical rules selects a workflow type task or a single SQL task according to a custom strategy; if the workflow type task is selected, it will enter the workflow IPO parsing module, in which the logic of the workflow type task will be encapsulated into a graph type logical object, and the graph type logical object will be disassembled into different sub-SQL statements, each of which is a custom syntax tree; finally, the parsing result of the IPO parsing module is returned to the logistics client.

2. The data lineage implementation method according to claim 1, characterized in that: The lexical analysis specifically includes decomposing the SQL statement into lexical units, and the lexical units include keywords, identifiers, operators and constants.

3. The data lineage implementation method according to claim 1, characterized in that: The exception report includes the location where the exception occurs and the error type, wherein the error type includes a syntax error and a keyword error.

4. The data lineage implementation method according to claim 1, characterized in that: The judgment criteria for the single SQL task is a data operation with a single syntax; the judgment criteria for the workflow type task is the presence of preset keywords or structures in the syntax and the associated statements containing more than one data processing step.

5. The data lineage implementation method according to claim 1 or 4, characterized in that: If it is neither a single SQL task nor a workflow type task, it is determined to be a non-workflow task, and the syntax is further verified, specifically including: checking each component of the syntax of the non-workflow task in turn to see if it conforms to the predefined syntax specifications; if unsupported syntax elements appear, a syntax exception is thrown, and an exception report is generated and returned to the client.

6. The data lineage implementation method according to claim 1, characterized in that: The graph-type logical object specifically includes organizing the tasks into a directed graph or a directed tree.

7. The data lineage implementation method according to claim 1 or 6, characterized in that: The logical object of the graph type is a table lineage result at the workflow level, indicating the data flow direction of multi-table input and multi-table output.

8. The data lineage implementation method according to claim 1, characterized in that: The syntax tree, as a field lineage result, represents field changes of fields within a single data table from the innermost data source to the final output data result field.

9. A computer program product, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

10. A computing system, characterized in that: The method comprises a processor and a memory, wherein the processor is configured to execute the method according to any one of claims 1 to 8.

Images