Erstellung und Verwendung von Autoencodern mit der SAP PAL

Datensätze, die im Machine Learning (ML) verwendet werden sollen, sind in der Praxis meist unverarbeitet und immens groß. Die meisten ML-Algorithmen benötigen die Eingangsdaten in einer spezifischen Form, die durch Datenvorverarbeitung bereitgestellt wird. Selbst dann ist das vorliegende Datenmodell meist jedoch sehr komplex.

Ein weiteres Problem bei Datensätzen kann die fehlende Balance zwischen Klassen sein. Bei einem Klassifizierungsvorhaben wird dem jeweiligen ML-Algorithmus ein Datensatz zugeführt, der neben regulären Attributen und einem Index auch ein Klassenattribut besitzt. So zum Beispiel bei einer Kundenabwanderungsanalyse. Hier sind alle Tupel mit einem Wert versehen, ob der jeweilige Kunde abgesprungen ist oder nicht, das Klassenattribut. Ist der Datensatz für die Kundenabwanderungsanalyse nun aber nicht balanciert und springen z.B. nur 20% der Kunden ab, kann das mit dem verwendeten ML-Algorithmus zu Ungenauigkeiten im resultierenden Modell führen. Um gleichzeitig den Problemen der hohen Komplexität von Datensätzen und der fehlenden Balance entgegenzuwirken, können mithilfe der SAP Predictive Analysis Library (PAL) Autoencoder erstellt werden.

Bei einem Autoencoder handelt es sich um ein künstlich neuronales Netzwerk (KNN). Wie in Abbildung 1 gezeigt, besteht ein Autoencoder aus fünf elementaren Bestandteilen. Die Originaldaten, den Encoder, die reduzierten Daten, den Decoder und die rückentwickelten Originaldaten. Anders als bei herkömmlichen KNNs ist das Ziel nicht die letzte Schicht des Netzwerks, sondern die mittlere Schicht. Bei dem Training des Autoencoders werden die Originaldaten, sowohl als Eingabe der ersten Schicht, als auch als Ziel für die letzte Schicht verwendet. In den verbleibenden Schichten werden die Daten reduziert, komprimiert und anschließend wieder bestmöglich zurückgebildet. In der mittleren Schicht des KNNs liegt also eine reduzierte Form der Originaldaten mit weniger Dimensionen vor. In der Regel werden Autoencoder für Anomalie-Analysen und Noise-Reduction (Filterung von Störwerten/-elementen) verwendet. (https://towardsdatascience.com/auto-encoder-what-is-it-and-what-is-it-used-for-part-1-3e5c6f017726)

Abbildung 1: Bestandteile eines Autoencoders

In dem von uns bearbeiteten Szenario wurde ein Datensatz zur Kundenabwanderungsanalyse verwendet. Zusammen mit dem Index und dem Klassenattribut hat der Datensatz 21 Attribute, wie Geschlecht, Dauer des Kundenverhältnisses, monatliche Kosten, etc. Bevor der Datensatz durch die SAP PAL verarbeitet wurde, wurden die Attributausprägungen skaliert. So wurden alle Attribute zwischen 0,3 und 0,7 skaliert, außer das Klassenattribut, welches zwischen 0 und 1 skaliert wurde, um einen Fokus auf dieses Attribut zu legen. Daraufhin wurde mit der SAP PAL ein KNN auf Basis des Datensatzes erstellt. Für die Erstellung eines solchen Netzwerkes sind lediglich die Eingabedaten, eine Parameter-Tabelle und eine leere Tabelle für das resultierende Modell notwendig. Das KNN wird dann von der SAP PAL im json-Format in der Modell-Tabelle gespeichert, aufgeteilt auf mehrere Zeilen mit je 5000 Zeichen. Anschließend wurde die Modell-Tabelle exportiert und mit einfach Mitteln in Python zerlegt, um als separate Modell-Tabellen für den Encoder und den Decoder zurück in die HANA-Datenbank importiert werden zu können. Dieser Schritt kann nach Bedarf jedoch auch mithilfe von SQL ohne Export im System selbst durchgeführt werden. Durch Verwendung der PREDICT-Prozedur der SAP PAL konnten die beiden Modelle verwendet werden. Auf diese Weise konnte das 19-dimensionale Datenmodell (21 abzüglich Index und Klassenattribut) zu einem zwei-dimensionalen Datensatz mithilfe des Encoders umgewandelt werden.

Abbildung 2 zeigt den verwendeten Datensatz in codierter Form. Zusätzlich wird auch ein Nutzen des Autoencoders dargestellt. Aus dem Datensatz wurde ein zufälliges Tupel ausgewählt und eine Merkmalsausprägung auf 13 (was weit über dem skalierten Maximum 0,7 liegt) gesetzt, was ganz klar einen Ausreißer, eine Anomalie, darstellt. Mithilfe der PREDICT-Prozedur konnten die zwei-dimensionalen Ausprägungen für dieses Tupel berechnet werden. Es sticht deutlich unter den restlichen Datenpunkten heraus.

Ein weiterer Nutzen des Autoencoders wird ebenfalls in Abbildung 2 deutlich. Den verwendeten Datensatz um mehr Tupel zu erweitern, ist in der zwei-dimensionalen Darstellung kein Problem. Werden Tupel der Klasse der abwandernden Kunden benötigt, können diese einfach in dem korrespondierenden Cluster hinzugefügt werden. Das ist in diesem Fall besonders einfach, weil bei der vorangegangenen Skalierung ein Fokus auf das Klassenattribut gelegt wurde und die Tupel auf diese Weise automatisch vom KNN stark danach sortiert wurden. Wurden neue Tupel nach Belieben hinzugefügt, können die Tupel mit dem Decoder wieder zurück in die ursprünglichen Dimensionen übersetzt werden.

Abbildung 2: Darstellung des codierten Datensatzes

Fazit

Autoencoder lassen sich zu verschiedenen Zwecken einsetzen und sind mit der SAP PAL problemlos zu erstellen. Die Aufteilung des von der SAP PAL erstellten Modells in Encoder und Decoder kann je nach Umsetzung aufwendig sein, kann jedoch durch geeignete SQL-Prozeduren als ein Einmal-Aufwand abgewickelt werden. Bei der Anomalie-Analyse ist besonders herauszustellen, wie visuell die Analyse betrieben werden kann, da eine zwei-dimensionale Darstellung von codierten Daten leicht umzusetzen ist. In dem von uns praktisch umgesetzten Szenario konnte der verwendete Datensatz in zwei-dimensionaler Form um Tupel einer bestimmten Klasse (abspringende Kunden) ergänzt werden. Nach der Umwandlung mit dem Decoder hatte der erweiterte Datensatz daraufhin deutlich verbesserte Ergebnisse bei dem verwendeten ML-Algorithmus zur Kundenabwanderungsanalyse hervorgebracht. Die hinzugefügten Tupel, haben außerdem den bereits existierenden Tupeln stark geähnelt, wodurch der Datensatz durch generierte Tupel nicht zu stark verfälscht wurde.

Ansprechpartner

Oliver Ossenbrink

Geschäftsführung Vertrieb und HR

Data Products Setup

I’ll start with Data Products setup. If you’re new to the concept, this recent video is a great starting point, but here’s a short summary. A data product is a well-described, easily discoverable, and consumable collection of data sets.

Creating a Data Product in Datasphere

Note that in this article I create Data Products in the Data Sharing Cockpit in Datasphere. This functionality is expected to move into the Data Product Studio, but that had not taken place at the time writing.

Before creating a Data Product in Datasphere, I need to set up a Data Provider profile, collecting descriptive metadata like contact and address details, industry, regional coverage, and importantly define Data Product Visibility. Enabling Formations allows me to share the Data Product with systems across your BDC Formation – Databricks, in this case.

With the Data Provider set up, I can go ahead and create a Data Product. As with the Data Provider, I’ll need to add metadata about the product and define its artifacts – the datasets it contains. Only datasets from a space of SAP HANA Data Lake Files type can be selected. Since this Data Product is visible across the Formation, it is available free of charge.

For this demo, the artifact is a local table containing ten years of Ice Cream sales data. Since this is a File type space, importing a CSV file directly to create a local table isn’t an option (see documentation).

I used a Replication Flow to perform an initial load from a BW aDSO table into a local table.

Once Data Product is created and listed, it becomes available in the Catalog & Marketplace, from where it can be shared with Databricks by selecting the appropriate connection details.

Jump into Databricks

To use the shared object In Databricks, I need to mount it to the Catalog – either by creating a new Catalog or using an existing one.

Databricks appends a version number to the end of the schema – ‘:v1’ – to maintain versioning in case of any future changes to the Data Product.

Once the share is mounted, the schema is created automatically, and the Sales actual data table becomes available within it. From there, I can access the shared table directly in a Notebook.

Creating a Data Product in Databricks

To create a Data Product in Databricks, I first need to create a Share – which I can either do via the Delta Sharing settings in the Catalog:

Or directly out of the table which is going to become a part of the Share:

Since a single Share can contain multiple tables, I have the option to either add the table to an existing Share, or create a new one:

To publish the Share as a Data Product, I run a Python script where I define the target table for the forecast and describe the Share in CSN notation, setting the Primary Keys. Primary Keys are required for installing Data Products in Datasphere.

Jump back into Datasphere

Once the Databricks Data Product is available in Datasphere, I install it into a Space configured as a HANA Database space – since my intention is to build a view on top of the table and use it for planning in SAC.

There are two installation options: as a Remote table for live data access, or as a Replication Flow, in which case the data is physically copied into the object store in Datasphere.

Since I want live access, I install it as a Remote Table:

and build a Graphical view of type Fact on top:

Forecast calculation

With my Data Products set up and Sales actual data are available in Databricks, I create a Notebook to calculate the Sales Forecast.

The approach combines Sales and Weather data to train a Linear Regression model. I import the Weather data *https://zenodo.org/records/4770937 from an external server directly into Databricks, select the relevant features from the weather dataset, and combine them with the Sales actual data:

* Klein Tank, A.M.G. and Coauthors, 2002. Daily dataset of 20th-century surface
air temperature and precipitation series for the European Climate Assessment.
Int. J. of Climatol., 22, 1441-1453.
Data and metadata available at http://www.ecad.eu

Using the “sklearn” library, I build and train a Linear regression model:

Once trained, the model predicts the Sales forecast for Rome in June 2026 based on the weather forecast, and I save the results to my Catalog table:

Seamless planning data model

Seamless planning concept is built around physically storing planning data and public dimensions directly in Datasphere, keeping them alongside the actual data.

Since the QRC4 2025 SAC release, it has also been possible to use live versions and bring reference data into planning models without replication.

In this scenario, I build a seamless planning model on top of the Graphical view I created over the Remote table. This lets me use the forecast generated in Databricks as a reference for the final SAC Forecast version.

The model setup follows these steps:

Create a new model:

Start with data:

Select Datasphere as the data storage:

From there, I define the model structure and can review the data in the preview.

For a deeper dive into Seamless Planning, I recommend this biX blog.

Process Flow automation

Multi-action triggers Datasphere task chain

The final step is automating the entire forecast generation by using SAC Multi-actions and a Task-Chain in Datasphere – so that my user can trigger the calculation with a single button click from an SAC Story.

The model setup follows these steps:

Create a new model:

Triggering Task Chains from Multi-actions is a recent release. This blog post walks through how to set it up.

For details on how to trigger a Databricks Notebook from Datasphere, I recommend referring to this blog.

With everything in place, I create a Story, add my Seamless planning Model, and attach the Multi-action:

Running the Multi-action triggers the Task Chain, which in turn triggers the Databricks Notebook.

I can monitor the execution details in Datasphere:

and in Databricks:

Once the calculation completes, the updated forecast appears in the Story:

The end-to-end calculation took 2 minutes 45 seconds in total. The Task Chain in Datasphere is triggered almost instantly by the Multi-action, the Databricks Notebook execution itself took 1 minute 29 seconds, with the remaining time spent on Serverless Cluster startup.

From here, I can copy the calculated forecast into a new private version:

adjust the numbers as needed, and publish it as a new public version to Datasphere:

Conclusion

With SAP Business Data Cloud, it is possible to build a forecasting workflow that feels seamless to the end user — even though it spans multiple systems under the hood.

Companies using BW as the main Data Warehouse and Databricks for ML calculations or Data Science tasks can benefit from using the platform, as the data no longer needs to be physically copied out of BW.

What this scenario demonstrates is that once wrapped as a Data Product, BW sales data can be shared with Databricks via the Delta Share protocol. Databricks, in turn, can then create its own Data Products on top of the calculation results and share them back with Datasphere as a Remote Table.

A Seamless Planning model in SAC sits on top of that Remote Table, giving planners live access to the generated forecast. A single Multi-action in an SAC Story ties it all together, triggering a Datasphere Task Chain that kicks off the Databricks Notebook — completing the full cycle in under three minutes.

As SAP Business Data Cloud continues to mature, scenarios like this one are becoming achievable – leaving the complexity in the architecture and not in the workflow.