Distributed Data Processing System with Dynamic Process Migration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing graph-based computation systems face inefficiencies in resource management, particularly in adapting to varying computation resources and load, leading to slow startup times and difficulties in reconfiguring data parallelism and load balancing across servers.

Innovation Solution

A distributed data processing system that manages replication and persistence of data, using a call cluster component to interface with a graph-based program specification, allowing for dynamic adaptation to changing resources and load by maintaining message counts and time intervals for replication and persistence, and implementing rollback scenarios for fault tolerance.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If traditional graph-based computation systems are used with fixed process hosting, then system stability is maintained, but adaptability to varying computation resources and load is poor

Engineering Contradiction:
Improveadaptability to varying computation resourcesVSAvoidcomplexity of resource management
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system implements dynamic process hosting where component processes can be migrated between servers based on computation load and resource availability. The orchestrator process continuously monitors system state and reassigns component processes to optimal servers, enabling the system to adapt to varying computation resources and load conditions rather than being fixed to static process hosting arrangements.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The orchestrator process employs feedback mechanisms by continuously monitoring computation load, resource availability, and process performance metrics across servers. Based on this feedback information, the orchestrator dynamically adjusts process placement and resource allocation decisions, creating a closed-loop control system that adapts to changing conditions in real-time.

Inventive Principle:
Principle #23Feedback

2Reliability

If multiple processes are initiated at startup to ensure resource availability, then system reliability is improved, but startup time increases and memory is wasted

Engineering Contradiction:
Improvesystem reliabilityVSAvoidstartup time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by pre-configuring the orchestrator process and essential core components at startup, while deferring the initiation of data-processing component processes until actually needed. The orchestrator is prepared in advance to rapidly allocate and start component processes on-demand, providing both quick startup and reliable operation without wasting memory on unnecessarily pre-started processes.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Component processes are started on-demand by the orchestrator in response to actual computation needs rather than being pre-started. This self-service approach allows the system to initialize only the minimum required components at startup, reducing startup time and memory usage, while maintaining reliability through rapid on-demand process creation when resources are required.

Inventive Principle:
Principle #25Self-service

3Productivity

If component processes are hosted on dedicated servers, then system stability is maintained, but load balancing efficiency decreases

Engineering Contradiction:
Improveload balancing efficiencyVSAvoiddifficulty in reconfiguring data parallelism
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The system transitions from static dedicated server hosting to dynamic process migration. The orchestrator can move component processes between servers based on real-time load conditions, enabling efficient load balancing. This dynamic approach also allows easy reconfiguration of data parallelism by adjusting the number and placement of component process instances without being constrained by dedicated server assignments.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

Servers are designed to host multiple types of component processes rather than being dedicated to single functions. This universal hosting capability allows the orchestrator to flexibly allocate and reallocate processes across any available server, improving load balancing efficiency and making reconfiguration of data parallelism straightforward by distributing processes across the universal server pool based on current system state.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Reliability

If data is replicated across multiple servers for fault tolerance, then system reliability is improved, but communication overhead and complexity increase

Engineering Contradiction:
Improvefault toleranceVSAvoidcomplexity of replication management
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The orchestrator process serves as an intermediary that manages data replication and consistency across servers. Rather than implementing complex peer-to-peer replication protocols between component processes, the orchestrator centralizes replication management, coordinating data synchronization and fault tolerance mechanisms, thereby reducing overall system complexity while maintaining high reliability.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3704578B1Managing a computing cluster using durability level indicators
Publication Date: 2024.12.04 AB INITIO TECHNOLOGY LLC
  • EP3704578B1 patent drawingFigure 1
  • EP3704578B1 patent drawingFigure 2
  • EP3704578B1 patent drawingFigure 3

AI summary

A method for managing data in a distributed data processing system including a number of processing nodes includes storing data units in data stores that are associated with a number of different levels of durability. The method includes maintaining indicators including a first indicator associated with a first durability level and a second indicator associated with a second durability level. The first indicator is maintained to reflect a time interval at which all sets of data units associated with the time interval are stored at the first durability level. The second indicator is maintained to reflect a timer interval at which all sets of data units associated with the time interval are stored at the second durability level. The first and second indicators are used to manage processing of the data units in the distributed data processing system.