Virtual Transformation Flows for Cloud Data Lake Integration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Managing large volumes of data in an in-memory database is challenging due to scalability and cost issues, while hyperscalers offer better scalability and cost-effectiveness, but integrating data storage across these systems is complex and requires a unified, seamless solution.

Innovation Solution

A data warehousing environment that supports storage in either an in-memory database or a Lakehouse architecture, leveraging hyperscalers, with mechanisms for schema enforcement and evolution, and utilizing open data formats like Apache Parquet and Delta Lake for efficient data management and processing, along with tools like SAP HANA Cloud and Apache Spark for advanced analytics and machine learning.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If data is stored in an in-memory database, then data access speed is improved, but scalability and cost-effectiveness deteriorate

Engineering Contradiction:
Improvedata access speedVSAvoidscalability
Core Design Contradiction:
SpeedVSAdaptability or versatility

Solution Approach 1:

The patent segments data storage into two distinct layers: hot data stored in an in-memory database for fast access, and cold data stored in cloud-based object storage for scalability. This segmentation allows the system to optimize for both speed and scalability simultaneously by placing different data types in appropriate storage media.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a data lake as an intermediary layer between the in-memory database and cloud storage. This data lake buffer facilitates seamless data movement and management, enabling the system to maintain fast access to frequently used data while scaling storage capacity in the cloud without direct coupling between the memory and cloud layers.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Speed

If data is stored in an in-memory database, then data access speed is improved, but cost-effectiveness deteriorates

Engineering Contradiction:
Improvedata access speedVSAvoidstorage cost
Core Design Contradiction:
SpeedVSQuantity of substance

Solution Approach 1:

The patent segments storage resources into expensive in-memory storage for critical fast-access data and inexpensive cloud object storage for bulk data. This segmentation enables the organization to pay premium prices only for the minimal data that requires high-speed access, while storing the majority of data in cost-effective cloud storage.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies local quality by providing different storage characteristics to different portions of data based on their access patterns. Frequently accessed data receives the high-speed in-memory treatment, while less frequently accessed data is stored in economical cloud storage, optimizing the overall cost-performance ratio.

Inventive Principle:
Principle #3Local quality

3Adaptability or versatility

If data is stored in hyperscaler cloud storage, then scalability is improved, but integration complexity increases

Engineering Contradiction:
ImprovescalabilityVSAvoidintegration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a data lake and integration layer as intermediaries between the in-memory database and hyperscaler cloud storage. This intermediary layer abstracts the complexity of cloud storage integration, providing standardized interfaces and data movement mechanisms that simplify the integration process while maintaining full scalability benefits.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates a universal data lake architecture that can work with multiple hyperscaler providers and different data formats. This universal layer handles various cloud storage APIs and protocols, reducing integration complexity by providing a single standardized interface regardless of the underlying cloud provider.

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

4Adaptability or versatility

If data is transformed across different storage systems, then data usability is improved, but transformation complexity increases

Engineering Contradiction:
Improvedata usabilityVSAvoidtransformation complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a transformation layer within the data lake architecture that serves as an intermediary between source data systems and target analytics systems. This transformation layer handles data format conversions, schema enforcement, and data quality operations in a centralized manner, reducing the complexity that would otherwise be distributed across multiple point-to-point integration scenarios.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent employs parameter changes by allowing flexible configuration of transformation rules, data formats, and quality standards through metadata and configuration files rather than hard-coded transformations. This enables the system to adapt to different data sources and targets by changing parameters rather than restructuring the entire transformation architecture.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP4711946A1Data transformation in cloud-based data warehousing environment
Publication Date: 2026.03.18 SAP SE
  • EP4711946A1 patent drawingFigure 1
  • EP4711946A1 patent drawingFigure 2
  • EP4711946A1 patent drawingFigure 3

AI summary

A solution for transforming and managing data in a data lake environment is disclosed. A definition of a transformation flow is received via a graphical user interface. The transformation flow specifies operations to transform source data into target data stored in a first format object storage. A virtual procedure corresponding to the transformation flow is generated and stored in an in-memory cloud database. Then the virtual procedure is executed, causing retrieval of metadata from the first format object storage and triggering a transformation job on a computing cluster. The transformation job reads the source data from the first format object storage, applies one or more transformations specified in the definition of the transformation flow, and writes results to target data in the first format object storage.