Distributed Tuple Graph Execution with Token-Based Stream Completion

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current programming models for cloud computing face challenges in achieving low-latency and efficient data processing due to limitations in data proximity and transfer costs in distributed computations.

Innovation Solution

A new programming model that constructs a directed acyclic graph of operators, allowing streams of values to flow between operators on different machines, with automatic location assignment and graph partitioning to minimize network traffic and optimize execution, using a method that includes sending tokens to determine stream completion and dynamic buffer growth for efficient data transfer.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If distributed computation is performed across multiple machines, then computing efficiency and scalability are improved, but data transfer costs and network latency increase

Engineering Contradiction:
Improvecomputing efficiencyVSAvoiddata transfer costs
Core Design Contradiction:
ProductivityVSLoss of energy

Solution Approach 1:

The system segments the directed acyclic graph into multiple shards that can be distributed across different machines. Each shard represents a portion of the computation that can be executed independently, allowing parallel processing while managing data transfer between segments. This segmentation enables scalable distributed computation while controlling network overhead.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system optimizes data locality by assigning operators and their associated data to specific shards based on access patterns and computation requirements. By placing frequently accessed data close to the computation that needs it, the system reduces cross-shard data transfer and minimizes network latency, thereby reducing data transfer costs while maintaining computing efficiency.

Inventive Principle:
Principle #3Local quality

2Productivity

If data is transferred between computation units in distributed systems, then processing capability is improved, but performance degrades due to network latency

Engineering Contradiction:
Improveprocessing capabilityVSAvoidperformance
Core Design Contradiction:
ProductivityVSSpeed

Solution Approach 1:

The system performs preliminary actions by pre-fetching and caching data that is likely to be needed by downstream operators before actual computation occurs. This anticipatory data loading reduces the impact of network latency during actual processing, as data is already available in local memory when needed, thereby maintaining high processing capability without performance degradation.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system ensures continuous processing by overlapping data transfer operations with computation operations. While data is being transferred between shards, other computation tasks are performed in parallel. This continuous utilization of computation units prevents idle waiting time and maintains high processing capability despite network latency constraints.

Inventive Principle:
Principle #20Continuity of useful action

3Reliability

If stream completion is tracked using token values across shards, then data accuracy is improved, but communication overhead increases

Engineering Contradiction:
Improvedata accuracyVSAvoidcommunication overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system introduces an intermediary controller that manages token value aggregation and stream completion tracking across multiple shards. Instead of requiring direct peer-to-peer communication between all shards, the controller acts as a central coordinator that collects token values, verifies data completeness, and manages the stream completion protocol. This intermediary approach maintains data accuracy while reducing the communication overhead that would result from full mesh communication between shards.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3673369B1Method of executing a tuple graph program across a network
Publication Date: 2024.07.03 GOOGLE LLC
  • EP3673369B1 patent drawingFigure 1
  • EP3673369B1 patent drawingFigure 2A~2B
  • EP3673369B1 patent drawingFigure 3

AI summary

A programming model provides a method for executing a program in a distributed architecture. One or more first shards of the distributed architecture execute one or more operations, and sending tuples to at least one second shard, the tuples being part of a stream and being based on the one or more operations. The one or more first shards send a token value to the at least one second shard when the sending of the tuples in the stream is complete. The at least one second shard determines whether a total of the token values matches a number of the one or more first shards, and takes a first action in response to determining that the total of the token values matches the number of the one or more first shards. The first action may include marking the stream as being complete and/or generating a message indicating that the stream is complete.