In-Memory Model Conversion for SAP HANA Migration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing models from non-in-memory data processing systems are not compatible with in-memory data processing systems, leading to the need for rewriting or re-creating models when migrating to in-memory systems, which is costly and time-consuming, especially for customers upgrading to SAP HANA from SAP BW.
Innovation Solution
An automatic process that converts models from non-in-memory data processing systems to in-memory data processing systems by interpreting the analytical settings of the source models and creating corresponding models in the in-memory system, eliminating the need for separate modeling and data replication, and enabling direct access to analytical data for reporting and custom applications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If models are manually rewritten or re-created when migrating to in-memory systems, then compatibility with the new system is achieved, but the effort and cost increase significantly
Solution Approach 1:
The system automatically copies and transforms metadata from source models in the data warehouse system to create target models in the in-memory system. This copying approach preserves the original model structure while adapting it to the new system, eliminating manual rewriting efforts
Solution Approach 2:
The conversion process automatically adjusts model parameters and metadata to be compatible with the in-memory system. This includes transforming data types, adjusting model structures, and modifying access patterns to match the columnar storage architecture, all through automated parameter transformation
2Speed
If data is stored in columnar format in in-memory systems, then query performance improves, but existing row-based models become incompatible
Solution Approach 1:
The system automatically transforms row-based model parameters to columnar-compatible parameters. This includes converting data access patterns from row-oriented to column-oriented queries, adjusting join operations, and modifying aggregation logic to leverage the columnar storage architecture for improved performance
Solution Approach 2:
Instead of converting data from columnar to row format, the system inverts the approach by transforming models to work with columnar data. This maintains the performance benefits of columnar storage while making existing models compatible through automated model transformation
3Productivity
If ETL processes are performed periodically, then transactional performance is maintained, but analytical data becomes outdated
Solution Approach 1:
The system merges OLTP and OLAP workloads into a single in-memory platform. This integration allows both transactional and analytical operations to access the same data simultaneously without requiring periodic ETL processes, eliminating data staleness while maintaining transactional performance through memory-speed access
Data Source
Figure 1
Figure 2
AI summary
A system and method of outputting data from an in-memory database. The method includes converting a first data model (which is unable to be used by the in-memory database) into a second data model (which is), and outputting data according to the second data model. In this manner, a user does not have to rewrite the first data model in order to access the in-memory database.