Universal Transformation Specification Format for Multi-Engine Coordination

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In distributed systems and cloud computing environments, the complexity of managing and provisioning resources across different execution engines with varying capabilities and configurations leads to inefficiencies, requiring separate services for each type of transformation, which is time-consuming and labor-intensive for developers.

Innovation Solution

A common transformation specification format is introduced, independent of specific execution engines, allowing for the same specification to be used across multiple engines, enabling centralized coordination, engine registration, and version management, thereby decoupling transformation specifications from engine details.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If separate services are created for each type of transformation in distributed systems, then each transformation can be handled with engine-specific logic, but developer effort increases and new transformations become time-consuming to implement

Engineering Contradiction:
Improveease of implementing new transformationsVSAvoidsystem complexity
Core Design Contradiction:
Ease of manufactureVSDevice complexity

Solution Approach 1:

The patent implements a universal transformation specification format that can be executed by multiple different execution engines. Instead of creating separate services for each transformation type, the system uses a common specification format (e.g., JSON, XML, or YAML) that describes transformations in an engine-agnostic way. This allows the same specification to be processed by various engines (MapReduce, Spark, Flink, etc.), eliminating the need to develop new services for each transformation and reducing developer effort while maintaining system flexibility.

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

Solution Approach 2:

The patent introduces an intermediary layer consisting of a transformation specification document and a coordination service that mediates between the user's transformation requirements and the underlying execution engines. The specification document serves as an intermediary representation that decouples the transformation logic from engine-specific implementations. The coordination service acts as a mediator that receives the specification, selects appropriate engines, and manages their execution, thereby simplifying the process of implementing new transformations without directly modifying engine code.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If transformation specifications are tied to specific execution engines, then engine-specific optimizations can be applied, but engine upgrades or rollbacks require modifying specifications

Engineering Contradiction:
Improvestability of transformation specificationsVSAvoidflexibility in engine management
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments the transformation system into distinct components: the transformation specification document (which contains the transformation logic in a standardized format), the coordination service (which manages execution), and the execution engines (which perform the actual processing). This segmentation allows the specification to remain stable and independent of engine changes. When engines are upgraded or rolled back, only the engine component needs to be modified, while the transformation specifications remain unchanged, ensuring reliability and ease of engine management.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The transformation specification document serves as an intermediary that decouples the transformation logic from engine-specific implementations. By using a standardized format (JSON, XML, or YAML) that is independent of any particular engine, the specification acts as a stable contract between the user's requirements and the engine's capabilities. This intermediary layer allows engines to be upgraded, replaced, or rolled back without requiring changes to the transformation specifications, thereby maintaining both stability and adaptability.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Productivity

If a common transformation specification format is used across multiple execution engines, then developer effort is reduced and engine upgrades become easier, but each engine must be capable of interpreting the common format

Engineering Contradiction:
Improvespeed of implementing transformationsVSAvoidcompatibility requirements
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent implements a universal transformation specification format that can be interpreted by multiple different execution engines. The specification uses a standardized structure (JSON, XML, or YAML) with clearly defined fields that describe the transformation logic, data sources, and targets. Each execution engine is designed to read and interpret this common format, allowing the same specification to be executed across different engines without modification. This universality dramatically reduces developer effort and enables rapid implementation of transformations while maintaining compatibility across the ecosystem.

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

Solution Approach 2:

The patent employs parameter changes by allowing the transformation specification to include engine-specific parameters or extensions while maintaining a core standardized structure. The specification can define mandatory fields that all engines must support and optional fields that provide engine-specific functionality. This approach enables engines to interpret the common format according to their capabilities, with more capable engines able to handle additional parameters or features while less capable engines can ignore them. This flexible parameter structure accelerates adoption across different engines without requiring complete compatibility for every feature.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS11347548B2Transformation specification format for multiple execution engines
Publication Date: 2022.05.31 AMAZON TECH INC
  • US11347548B2 patent drawing
  • US11347548B2 patent drawing
  • US11347548B2 patent drawing

AI summary

Methods, systems, and computer-readable media for a transformation specification format for multiple execution engines are disclosed. A transformation specification is expressed according to a transformation specification format. The transformation specification represents a polytree or graph linking one or more data producer nodes, one or more data transformation nodes, and one or more data consumer nodes. An execution engine is selected from among a plurality of available execution engines for execution of the transformation specification. The execution engine is used to acquire data from one or more data producers corresponding to the one or more data producer nodes, perform one or more transformations of the data corresponding to the one or more data transformation nodes, and output one or more results of the one or more transformations to one or more data consumers corresponding to the one or more data consumer nodes.