Speculative Data Processing for Streaming Workflows

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In streaming workflows, processing nodes face challenges with latency and data accuracy due to late or out-of-order source data, leading to inaccurate derived data being generated and propagated downstream, which can cause significant errors in network management and other critical applications.

Innovation Solution

The implementation of speculative data processing and offline correction logic, where processing nodes generate derived transactions based on available source data and regenerate them when necessary, using transaction mappings to ensure data integrity and reduce latency by propagating corrections throughout the workflow.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If the processing node delays processing source data until completeness is confirmed, then data accuracy is improved, but latency increases to unacceptable levels

Engineering Contradiction:
Improvedata accuracyVSAvoidlatency
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system performs preliminary speculative processing of source data to generate derived data before confirmation of source data completeness. This allows the processing node to act in advance, reducing latency while maintaining the ability to correct errors later through the commit/revert mechanism when source data completeness is confirmed.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements a feedback mechanism where the processing node monitors source data arrival and uses this information to determine whether to commit or revert speculative derived data. This feedback loop enables the system to balance latency and accuracy dynamically based on actual source data completeness status.

Inventive Principle:
Principle #23Feedback

2Loss of time

If the processing node processes source data immediately without waiting for completeness, then latency is reduced, but data accuracy deteriorates due to late or out-of-order data

Engineering Contradiction:
ImprovelatencyVSAvoiddata accuracy
Core Design Contradiction:
Loss of timeVSMeasurement precision

Solution Approach 1:

The processing node performs preliminary speculative processing immediately upon receiving source data, generating derived data in advance without waiting for completeness confirmation. This preliminary action reduces latency while the subsequent commit/revert mechanism ensures accuracy by validating against complete source data later.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system prepares compensatory mechanisms in advance by implementing the commit/revert framework. This cushioning allows the system to tolerate potential inaccuracies from premature processing by having the capability to revert incorrect derived data when source data completeness is confirmed, thus protecting against accuracy deterioration.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

3Productivity

If the processing node generates derived data from incomplete source data, then productivity is improved, but reliability deteriorates due to inaccurate derived data being propagated downstream

Engineering Contradiction:
Improveprocessing throughputVSAvoiddata integrity
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The processing node performs preliminary speculative processing to generate derived data from available source data without waiting for completeness, thereby maintaining high processing throughput. The commit/revert mechanism then ensures data integrity by validating these speculative results against complete source data and reverting incorrect derivations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements feedback monitoring of source data completeness status to control the commit/revert of derived data. This feedback mechanism allows the system to maintain productivity by continuously processing available data while protecting reliability by using completeness information to determine whether to commit or revert derived data results.

Inventive Principle:
Principle #23Feedback

4Reliability

If the processing node waits for source data completeness before processing, then data reliability is improved, but productivity decreases due to suspended processing

Engineering Contradiction:
Improvedata integrityVSAvoidprocessing throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The processing node performs preliminary speculative processing in advance without waiting for source data completeness confirmation, maintaining continuous processing throughput. The reliability aspect is preserved through the subsequent commit/revert mechanism that validates speculative results against complete source data, allowing the system to achieve both high productivity and data reliability.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS9438676B2Speculative data processing of streaming data
Publication Date: 2016.09.06 CISCO TECHNOLOGY INC
  • US9438676B2 patent drawing
  • US9438676B2 patent drawing
  • US9438676B2 patent drawing

AI summary

In an embodiment, a method comprises receiving a plurality of source data records from one or more source computers, wherein one or more first source data records are associated with a first source transaction and one or more second source data records are associated with a second source transaction; generating a first derived transaction comprising one or more first derived records based on the plurality of source data records; generating a first transaction mapping between the first derived transaction and the first source transaction; generating a second transaction mapping between the first derived transaction and the second source transaction; determining that the first derived transaction has ended, and in response, committing first derived transaction including the one or more first derived records to a persistent storage; receiving a first ending punctuation associated with the first source transaction, and in response, committing the first source transaction including the one or more first source data records associated with the first source transaction to the persistent storage; after committing the first derived transaction, determining that the second source transaction failed, and in response: determining that the first derived transaction should be regenerated based on the second transaction mapping, and in response, regenerating the first derived transaction.