SAP BW Star Schema (InfoCube)

In vielen Blogs findet man eine Beschreibung des erweiterten Star Schemas im klassischen SAP BW – bekannt auch als InfoCube. Der InfoCube existiert bis SAP BW 7.5.

Durch die Standardisierung eines SAP BWs kann der InfoCube mit allen seinen Aspekten einfach auf Basis der Metadaten generiert werden kann.

Die Standardisierung schränkt das Star Schema ein. Allerdings gibt es trotzdem viele Optionen, um das Star Schema an den Zweck anzupassen.

  • Eine zweite Faktentabelle für komprimierte Daten. D. h. auch in der nicht-komprimierten Tabelle sind noch alle Informationen der Änderungen verfügbar. In der Administration ein klarer Vorteil.
  • Maximal gibt es 16 Dimensionen. 3 Dimensionen sind vorgegeben (Zeit, Einheiten und eine technische Dimension). Die restlichen Dimensionen können frei genutzt werden.
  • Technisch baut die Modellierung auf SIDs auf. Surrogate IDs, welche durch INT4-Werte repräsentiert werden. Dadurch können JOINs effizienter ausgeführt werden und das Kernmodel – Fakten- und Dimensionstabellen sind sehr kompakt. Die SIDs sind generisch, ist der Wert selbst nicht ein INT4-Wert.
  • Die SID verbindet das Merkmal mit den im Weiteren standardisierten Optionen. Dies sind Texte (optional zeit- oder sprachabhängig), Attribute (optional zeitabhängig) oder externe Hierarchien. (Parent-Child, optional zeitabhängig).
  • Dimensionen arbeiten auch mit einer Surrogate ID. In der Dimension stehen i. d. R. nicht die Merkmals-/Schlüsselwerte sondern die bereits erwähnten SIDs. Die Kombination der SIDs wiederum werden auf eine eindeutige Dimensions-ID gemapped. Es gibt 2 Ausnahmen von dieser Modellierung. Man kann eine Dimension mit der Eigenschaft Line-Item versehen. Dies bietet sich bei großen Dimensionen (10% der Faktentabelle) an. Die 2. Option ist, ein oder mehrere Aggregate auf Basis des InfoCubes zu generieren. Bis 13 Dimensionen ist jede Dimension dann automatisch Line-Item, was bedeutet, dass die SID anstatt der Dimensions-ID direkt als Fremdschlüssel in die Faktentabelle geschrieben wird.
  • Der sogenannte MultiProvider ermöglich im Prinzip die Nutzung mehrerer Faktentabellen zu den gleichen Dimensionen (Shared Dimension). Somit könnte man den Einsatz als Galaxy Schema bezeichnen.
  • Über Partitionierung wird eine Aufsplittung der Faktentabelle erreicht. Allerdings ist dies nur über die Zeitdimension möglich. Später wurde das sogenannte Semantisch Partitionierte Objekt (SPO) eingeführt, welches nach weiteren Merkmalen eine Aufsplittung zulässt und dabei die Verwaltung vereinfacht. Über den MultiProvider ist das gleiche, jedoch auch eine heterogene Integration in gewissem Rahmen möglich.

Ein BW InfoCube ist somit relativ einfach anzulegen und wird dann auch funktionieren. Durch eine gewisse, auf SAP und Businessdaten ausgelegte Standardisierung gibt es im Vergleich zu einer freien Modellierung eines Star Schemas Einschränkungen. Man muss die spezifischen Möglichkeiten kennen, um im BW eine gute Performance erreichen zu können.

Der InfoCube hat eine gewisse Historie und ist auf klassische Datenbanken (Oracle, MS SQL Server, SAP ASE, IBM DB2, …) mit zeilenbasierter Datenspeicherung (Row Store) ausgelegt.

Durch die physische Speicherung der Dimensionsdaten ist diese Art der Modellierung nur bedingt flexibel (vgl. z. B. Dynamic Star Schema in BW/4HANA oder Calculation View mit Star Join in HANA).

Da im klassischen BW ein Standard DSO auch Navigationsattribute (Attribute welche frei verwendet werden können) haben kann, kann dies auch als Flat Cube gesehen und genutzt werden. Im weiteren werde ich hierauf aber nicht mehr eingehen.

Eine direkte Modellierung transitiver Attribute ist im klassische Star Schema (InfoCube) nicht möglich.

S/4HANA – Q1/2020 Update

S/4HANA ist nach wie vor das Produkt der SAP, an der sie sich messen lassen muss.

Auch für das Thema Analytics ist S/4HANA wichtig. Durch das heben des SAP ERP-System auf HANA hat das Thema Analytik hier Stück für Stück an Bedeutung gewonnen.

Analytische Aspekte von S/4HANA sind:

  • Embedded BW – Bereits seit das SAP ERP auf SAP NetWeaver 7.0 verfügbar ist, enthält es immer auch ein SAP BW, ob dies genutzt wird oder nicht.
  • Embedded Analytics – Fiori-basierte Apps, welche Core Data Services und Embedded BW-Logik nutzen um für verschieden Anwendergruppen einfach zu handhabende Analysen und Visualisierungen zur Verfügung zu stellen.
  • Embedded Machine Learning – Die zunehmende Möglichkeit ML-Verfahren z. B. aus SAP Analytics Cloud Smart Predict in S/4HANA-Applikationen über Predictive Analytics Integrator zu integrieren
  • BPC for Finance – Die Möglichkeit, die BPC-Planungsengine zu nutzen und direkt in die ACDOCP zu schreiben.
  • Group Reporting – Konsolidierung direkt im S/4HANA mit der Möglichkeit direkt in die ACDOCU zu schreiben
  • Embedded SAP Analytics Cloud – Die direkte Integration von SAC in SAP S/4HANA Cloud

Die Bedeutung ist so groß, dass jedes Quartal die Zahlen veröffentlicht werden, wie viel Kunden nun S/4HANA lizenziert und u. U. sogar implementiert haben.

Also gab es zum Q1/2020 für S/4HANA wieder neue Zahlen. Wie immer muss man sich die Details etwas zusammensuchen und evtl. auch mal Abschätzungen machen, z. B. wie viele SAP ERP-Kunden es überhaupt gibt:

S4HANA Zahlen

Nun, in Q4 wurden 1.200 Neukunden noch groß gefeiert. Der Vergleich zeigt aber, dass Q4 immer das stärkste und Q1 immer das schwächste Quartal ist. Bisher waren in Q1 in den 2 Vorjahren 400 Neukunden zu verzeichnen. Im Q4 waren 1000+ Kunden die Regel.

Mit „nur“ 300 Kunden bei auch noch rund 45% Neukunden (135 neu / 165 Bestandskunden) ist das keine rühmliche Zahl. Selbst die Verlängerung der Wartung auf 2027 bzw. 2030 ist eher utopisch zu sehen, um bis dahin den größten Teil der Kunden auf S/4HANA zu heben. Da muss sich die SAP noch einiges einfallen lassen, denn Corona wird hier aktuell sicherlich auch keinen positiven Effekt haben.

Mit den laufenden Projekten kann man u. U. auch ein Forecasting machen. Sieht man, dass in Q2/2018 4200 Kunden ein S/4HANA (Brownfield/Greenfield) laufen hatten und hofft man, dass es nicht signifikante Projektabbrüche gab, dann sind auf Basis der Live Customer-Zahlen die Projekt im Durchschnitt mindestens 1,5 Jahre gelaufen. Wie lange diese in Q2/2018 bereits liefen, kann ich ja nicht sagen.

SAP & Machine Learning 2020

Wie sieht das aktuelle Angebot im Bereich Machine Learning der SAP aus? Wer sind die entsprechenden Zielgruppen?

Natürlich, Machine Learning wird zunehmend unter „AI“ – Artificial Intelligence vermarktet. Wie dem auch sei. Kurz drüber nachgedacht kam ich zu folgendem grobem Ergebnis:

SAP Advanced Analytics Jetzt könnte einem noch Conversational AI einfallen, was aus meiner Sicht noch relativ speziell und eher nicht unabhängig zu sehen ist. Ganz alte SAP BW-Hasen wissen evtl. auch noch, dass das BW bis Release 7.5 eine Data Mining-Workbench hatte, welche mit Release 3.5 in den Analyseprozessdesigner eingebettet war. Faszinierenderweise hatte man also schon vor langer Zeit den Gedanken, Machine Learning als Teil einer Datenpipeline auf Basis eines SAP BW zu sehen. Die Nutzung war indes überschaubar.

HANA ist aus meiner Sicht der Analytical Core, wobei SAP Data Intelligence bspw. auch Python-Bibliotheken für maschinelles Lernen zulässt.

Bin ich heute Entwickler, hab ich letztendlich verschiedene Möglichkeiten. Die SAP versucht ja alles irgendwo in einen vereinfachten Service zu packen, so dass eben kein Data Scientist notwendig ist.

Nunja, selbst für das für den Business Analyst vorgesehene Smart Predict habe ich hingeschrieben, dass zumindest mal ein grundlegendes Datenverständnis, also für Datenqualität, Datenstrukturen, typische Themen, die man mit der Herkunft, der Vollständigkeit, der Genauigkeit usw. der Daten hat. Man könnte hier auch von Data Literacy oder Datenkompetenz reden. Bei aller Automation, die einem eben die Auswahl des Algorithmus und das Hyperparametertuning abnimmt, gilt, was immer galt – Garbage in, Garbage out.

Learning Journey: SAP Data Warehouse Cloud

Die SAP hat für die neue Lösung „SAP Data Warehouse Cloud“ (im Weiteren DWC) eine Learning Journey erstellt. Schauen wir mal, was man damit lernen kann.

Erster Step zum Überblick sind Webinare zum Thema:

LJ1

Tatsächlich steht hier auch eine ganze Menge zur Auswahl. Neben relativ allgemeinen Webinare, die erklären sollen, warum man jetzt ein DWC benötigt, gibt es 4 interessante, etwa 1-stündige Deep Dives on demand:

 

SAP DWC – Stories

Dieser Blog ist eine Zusammenfassung des Webinars:

SAP Data Warehouse Cloud Workshop: Deep Dive into Stories

Im Rahmen der Learning Journey: SAP Data Warehouse Cloud (Tag 4).

Leider ist die Anmeldung etwas umständlich. Das gezeigte ist kein großes Geheimnis und konnte in anderen Webinaren, welche durchaus auch auf Youtube verfügbar sind, ebenfalls gesehen werden. Leider war ein umständlicher Anmelde- und Bestätigungsprozess notwendig.

In Summe geht das Webinar knapp 40 Minuten und zeigt die aktuellen Features in SAP Analytics Cloud. Leider passiert dies unabhängig von Data Warehouse Cloud. Initial wird gar ein .xlsx-File hochgeladen und dann damit gestartet.

Auf der einen Seite will man damit wohl auch klar machen, es gibt keine wesentlichen Unterschiede. Wobei durchaus die Frage kam, ob zwischen einer Live-Verbindung und dem Import der Daten unterschieden werden kann. Für mich kam zumindest nicht klar raus, ob DWC als Live-Connection gilt, auch wenn die Unterschiede zunehmend verschwimmen werden.

Vielleicht ein Hinweis, bei dem doch auch mal auf DWC eingegangen wurde. SAC unterstützt natürlich die Berechnung von Kennzahlen. Grundlegender und nachhaltiger kann dies natürlich im DWC erfolgen, da hier die Daten gemanaged und entsprechend komplexe Kalkulationen vorgenommen werden können.

Richtigerweise wird zum Ende für weitere Informationen auf http://www.sapanalytics.cloud verwiesen. Hier ist sicherlich die zentrale Anlaufstelle für alles rund um SAC.

 

 

 

SAP DWC – Modeling and Semantic Layer

Dieser Blog ist eine Zusammenfassung des Webinars:

SAP Data Warehouse Cloud Workshop: Deep Dive into Modeling and Semantic Layer

im Rahmen der Learning Journey: SAP Data Warehouse Cloud (Tag 3).

Anwendungsfälle für DWC:

  • Data Warehouse-Modernizierung durch hybride Anwendung mit S/4HANA und BW/4HANA
  • Accelerate Analytics durch Data Marts
  • Anwendungsübergreifendes Data Warehouse – also der klassische Anwendungsfall

Datenmodellierung besteht im Wesentlichen aus dem Business Catalog, welche bestehende Datenmodelle und Business Entities umfasst sowie dem Data Builder um Entity-Relationship-Modelle, Tabellen und Views zu verwalten.

Im DWC kann man zwei Layer unterscheiden:

  • Business Layer: Fachliche Ebene – entkoppelt von der Datenquelle, beschreibt Verbindungen zwischen den Elementen (Business Entities), umfasst KPIs/Dimensionen/Fakten/Hierarchien, resultiert in einem semantischen Graph, dient der Standardisierung und Wiederverwendung
  • Data Layer: Technische Ebene – Beschreibt Datenquellen und deren Versorgung mit Daten, umfasst virtuelle und lokale Tabellen, umfasst Verbindungen und Views

In der Demo wird dann ein Überblick über DWC gegeben.

  • Der Cube Builder, der z. B. aktuell noch nicht verfügbar ist.
  • Connections, bei welchen aktuell nur OData, ABAP- und HANA-Systeme verfügbar zu sein scheinen. Mehr ist aber geplant. Im Wesentlichen scheint eine Anbindung über SDI möglich zu sein.
  • Business Catalog,

OpenSAP: The Internet of Things with SAP

Ein aktuell interessanter, wenn auch nur 1-wöchiger Kurs von OpenSAP ist „The Internet of Things with SAP„. Im Kontext Analytics beschäftigt mich das Thema IoT schon länger. SAP hat dort eine gewisse Entwicklung hinter sich. Auch ist die Strategie bisher nicht ganz klar.

Auf der einen Seite gibt es den PCo – Plant Connectivity, welcher seine Heimat eher im Bereich Industrie 4.0 hat. Auf der anderen Seite findet sich in Cloud Foundry (SAP Cloud Platform) eine IoT Platform, welche die bisherige in Neo mittlerweile komplett abgelöst hat.

Welche aktuellen Erkenntnisse bringt uns dieser OpenSAP-Kurs?

Was ist IoT?

“The Internet of Things (IoT) is the network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment.”

– Source: Gartner

Eine mögliche, vorgestellte Definition. SAP gibt hier erstmal keine eigene Definition.

Das IoT kann in 3 wesentliche Bausteine aufgeteilt werden:

  • Sensoren – Ein kleines Gerät, welches die Information aus der Umgebung liefert und als digitales Signal zur Edge oder Cloud übermittelt. Mögliche Messwerte sind u. a.:
    • Geräusche
    • Position (GPS)
    • Feuchtigkeit
    • Bewegung
    • Temperatur
    • usw.
  • Edge – Ein Gerät zur Verarbeitung von Daten am Rande eines Netzwerks zwischen Sensoren und Cloud/Rechenzentrum. Die Verarbeitung und Analyse nahe am Sensor kann die Entscheidung auf Basis der Daten beschleunigen. Eingesetzte Geräte sind u. a.:
    • IoT Gateways von einschlägigen Herstellern (z. B. Intel, Dell, Cisco)
    • Remote Server
    • Industrie PCs
    • Raspberry Pi
    • usw.
  • Cloud – Ein Rechenzentrum bzw. Rechenzentrumsverband welcher Speicher für die Daten und Verarbeitungskapazitäten zur Verfügung stellt.

SAP sieht IoT als wichtigen Baustein für das Intelligent Enterprise. Dies besteht aus dem klassischen Teil eines Systems, welches die Unternehmensprozess managed (z. B. SAP ERP/Intelligent Suite – O-Data) sowie Möglichkeiten die Interaktion mit Kunden und Mitarbeitern zu messen und zu verstehen (z. B. Qualtrics – X-Data) und warum etwas passiert. Um in einer „Experience Economy) zu gewinnen, müssen lt. SAP beide Seiten über Intelligence (Analytics, Intelligent Technologies, Database & Data Management und Application Integration & Development -> Business Technology Platform) verbunden werden. Teil der „Intelligent Technologies“ ist IoT cloud & edge.

3 Beispiele für die Relevanz von IoT:

  • Erhöhung der Produktivität durch die Wahrnehmung der aktuellen Situation (Nachschubsteuerung)
  • Verbindung von Prozessen für eine verbesserte Kundenerfahrung (z. B. Predictive Maintenance)
  • Geschäftsinnovationen für neue Geschäftsmodelle und Einkommensströme (z. B. Optimierung bei erneuerbaren Energien)

 

SAP Leonardo IoT in der Cloud bietet 4 Innovatonspfade:

  • Embed – Einbetten von IoT in SAP-Anwendungen (S/4HANA, C/HANA, …)
  • Extend – Entwickler die Möglichkeit geben, bestehende SAP-Prozesse durch vorher nicht verbundene IoT-Geräte wie Maschinen oder Produkte zu erweitern
  • Evolve – Im Kontext von SAP-Systemen neue Geschäftsmodelle ermöglichen
  • Edge-Enabled – Eine durch die Cloud ermöglichte Verarbeitung durch Edge-Geräte

Services von SAP Leonardo IoT:

  • Enablement of the Digital Twin
  • Data ingestion und Big Data storage
  • Analytic Services & Aggregation Management
  • Event Services
  • Actions, Integration & Descision Support Services
  • Streaming Rules & Roles on Persisted Data

SAP Edge Services – Die Services können mit 3 D’s beschrieben werden:

  • Distributed
  • Diverse
  • Dynamic Communication Channel

Das Angebot umfasst die folgenden Services:

  • Police Service – Deployment und Lifecycle Management aus der Cloud
  • Essential Business Functions Services – Erweiterung bestehender Anwendungen wie SAP ERP, SAP C/4HANA und SAP Asset Intelligence Network
  • Streaming Services – Analyse von IoT-Datenströmen in Realtime basierend auf Geschäftslogiken
  • Persistence Service – Speichern der IoT-Daten im IoT-Gateway
  • Custom Edge Services – z. B. Predictive Analytics

 

Aktuelle Themen, welche Industrie 4.0 weiter treiben:

  • 5G Mobilfunk-Standard
  • Edge Processing
  • Die 4. industrielle Revolution

 

SAP Analytix Fazit

IoT liefert grundsätzlich eine große Menge an Daten, welche in produktiven nach Big-Data-Prinzipien gemanaged werden müssen. Der Fokus des Kurses hier liegt ganz klar auf dem SAP Cloud Platform-basierten Leonardo IoT-Angebot.

Für die Analytics Services wird aus meiner Sicht konsequent SAP Analytics Cloud als Frontend über Live-Verbindung genutzt. Für die intelligente Automatisierung spielt im Weiteren Machine Learning eine wichtige Rolle.

Auch wenn IoT im eher klassischen Kontext über ein gewisses Monitoring hinaus kaum eine Rolle spielt, bringen neuere Disziplinen wie Big Data und Data Science in diesem Umfeld enormen Mehrwert. Das Thema IoT und Industrie 4.0 erfreuen sich zunehmender Beliebtheit und die Relevanz und Nutzung bei den Unternehmen wird deutlich zunehmen.

HPI – BD19/20 – Benchmarking und Measurement

Als Teil der Lecture Series des HPI hier Teil 4 der Big Data-Vorlesung mit „Benchmarking und Measurement„.

Zuletzt – Teil 4: HPI BD19/20 – Big Data Stack

Warum überhaupt messen?

  • Verfügbarkeit von Webseiten gewährleisten
  • Interaktive Datenanalyse skalierbar machen
  • Realtime-Analytics

 

Überlegungen

  •  Systemperformance muss regelmäßig geprüft werden.
  • Niemals nur einer Messmethode glauben
  • Back-of-the-envelope calculations -> Überschlagsrechnung
    • Grobe erste Berechnung, ob es passt oder nicht
    • Bsp. Berechnung der Performance der Einzelkomponenten (L1/L2-Cache, Hauptspeicher, Festplatte, …)

Im weiteren zeigt die Vorlesung viele Möglichkeiten, statistisch mit Messwerten zu arbeiten um verschiedene Aspekte sinnvoll zu testen und validieren zu können.

 

SAP Analytix-Fazit

Nun, im BI-Umfeld wie überall im Bereich Analytics spielt Performance eine wichtige Rolle und umfasst oft viele Stufen und Optionen.

Im klassischen SAP BW on Any DB dürfte dies z. B. jeder BI-Administrator/-Berater kennen. Lesen auf ein flaches Schema wird tendenziell nicht empfohlen, außer man benötigt wirklich die Detailebene und liest jeden einzelnen Datensatz. Für alles was aggregierte Daten berechnet, macht das Star Schema (InfoCube) mehr Sinn. Darauf aufbauend gibt es klassisch die Aggregate, welche nochmals über mehrere Merkmale verdichtet, eine Teilmenge der Daten auf der Datenbank bereitstellt. In der Pre-HANA Ära gab es dann auch noch den BWA, der die Daten im deutlich schnelleren Hauptspeicher vorgehalten hat. Im optimalen Fall wurden die Daten auch schonmal geladen und liegen im noch schnelleren Cache. All dies kann man designen und bereitstellen um Performance hoch zu halten.

HANA bringt das Thema natürlich nochmal auf ein neues Level. Die Daten sind permanent in Memory, spaltenbasiert quasi schon aggregiert und liefern mit optimierter Hardware auch die entsprechende Performance.

Die Cloud kann und wird evtl. zukünftig hier noch flexiblere Optionen ermöglichen, da hier Ressourcen flexibel zugeschaltet oder wieder zurückgefahren werden können.

Natürlich weiß auch jeder, der sich mit Performancemessungen beschäftigt hat, dass das beschriebene allein evt. noch nicht immer auch beim Anwender ankommt. Die richtige Systemparametrisierung, das Netzwerk und das Frontend selbst bzw. der Rechner auf dem dieses läuft, geben ihr übriges dazu.

In einem SAP BW-System haben Statistiken auch einen lange Historie und können ad-hoc oder im Langzeitvergleich flexibel ausgewertet werden.

 

Nächste Lecture: Benchmarks