Autonomous Data Pipeline Comparator for Production Validation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multi-tenant cloud environments, it is challenging to certify that new data pipelines correctly extract and transform data, especially when transitioning from monolithic to microservices architecture, as test environments may not surface actual issues or regressions, and testing against live data is necessary but difficult due to data volume and legal compliance concerns.

Innovation Solution

Deploying an autonomous intelligent data pipeline comparator that compares outputs of old and new data pipelines within a production environment, using production data to validate the new pipeline and detect data quality issues, including domain object model customizations, allowing for real-time validation and reporting of anomalies.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If test environments are used to validate new data pipelines, then development safety is improved, but data quality issues and regressions are not detected

Engineering Contradiction:
Improvedevelopment safetyVSAvoiddata quality detection
Core Design Contradiction:
ReliabilityVSMeasurement precision

Solution Approach 1:

The system performs preliminary comparison of data pipeline outputs by capturing and storing reference data from the old pipeline before the new pipeline is fully deployed. This preliminary action enables subsequent validation of the new pipeline against the stored reference data, allowing detection of data quality issues that would not be visible in isolated test environments.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary validation layer that sits between the new data pipeline and the production data warehouse. This intermediary component captures output data from both the old and new pipelines, performs automated comparison, and validates data quality metrics without requiring direct access to live production data, thus resolving the contradiction between safety and detection precision.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Device complexity

If the old data pipeline is decommissioned, then system simplicity is improved, but confidence in the new pipeline cannot be established

Engineering Contradiction:
Improvepipeline architectureVSAvoidconfidence in new pipeline
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

Before decommissioning the old pipeline, the system performs preliminary validation by comparing a subset of data pipeline outputs from the new pipeline against stored reference data from the old pipeline. This preliminary action establishes confidence metrics that enable safe decommissioning of the old pipeline while maintaining system simplicity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements partial validation by comparing only critical data fields and metrics rather than entire data sets. This partial action approach provides sufficient confidence for pipeline decommissioning while minimizing the complexity and overhead of the validation process, enabling the old pipeline to be decommissioned safely.

Inventive Principle:
Principle #16Partial or excessive action

3Reliability

If the new data pipeline is tested against live data, then data quality confidence is improved, but data volume and legal compliance issues arise

Engineering Contradiction:
Improvedata quality confidenceVSAvoiddata volume and compliance burden
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The system extracts and captures only the necessary output data from the data pipeline for comparison purposes, rather than processing entire live data sets. This extraction approach enables validation against live data while minimizing data volume and legal compliance burdens by taking out only the critical fields needed for validation.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent creates copies of reference data from the old pipeline and stores them in a validation data store. These copies enable comparison and validation of the new pipeline without requiring access to actual live production data, thus maintaining data quality confidence while avoiding data volume and compliance issues.

Inventive Principle:
Principle #26Copying

4Adaptability or versatility

If manual validation processes are used, then customization handling is improved, but time consumption and resource usage increase

Engineering Contradiction:
Improvecustomization handlingVSAvoidvalidation time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system implements self-service automated validation that compares data pipeline outputs without requiring manual intervention. The automated process handles customized domain object models by using configurable comparison rules that adapt to different data structures, eliminating time-consuming manual validation while maintaining adaptability to customizations.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent enables parameter changes in the validation process by allowing configurable comparison rules, thresholds, and data field selections. These parameter changes allow the system to adapt to customized domain object models and different validation requirements automatically, reducing time consumption while maintaining versatility.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS11379419B2Autonomous intelligent data pipeline comparator
Publication Date: 2022.07.05 SAP SE
  • US11379419B2 patent drawing
  • US11379419B2 patent drawing
  • US11379419B2 patent drawing

AI summary

Briefly, embodiments of a system, method, and article for transmitting, from a first application, a query for a domain entity associated with a second application. A transformation microservice may receive change data indicating modifications to the domain entity associated with the second application. The second application may execute the query on data for the domain entity associated with the first application and may generate a first output file with query results. The transformation microservice may execute the query on the change data for the domain entity associated with the second application and generating a second output file with query results. The first output file and the second output file may be sent to a comparison microservice. The comparison microservice may determine whether there are differences between the query results of the first output file and the second output file.