Graphanalyse & SAP HANA Graph
Stand 2026-09-03
SAP HANA Graph macht aus Fragen, die relationales SQL nicht effizient beantworten kann — Lieferantenrisiko-Kaskaden, Cross-Sell-Zentralität, Skills-Matching —, Traversierungsabfragen, die im selben HANA-Mandanten laufen, der bereits BW/4HANA oder Datasphere bedient, ohne separate Graphdatenbank und ohne ETL. In Produktionsprojekten hat das einen achtstündigen nächtlichen Batch für Lieferantenrisiko auf 4 Minuten reduziert und die Cross-Sell-Konversion von 11 % auf 38 % gehoben, indem Konten nach Netzwerk-Zentralität statt nach RFM-Segmentierung gerankt wurden. Die rare Fähigkeit ist nicht die Cypher-ähnliche MATCH-Syntax — es ist die Entscheidung, was ein Knoten und was eine Kante ist, und wann ein Problem tatsächlich graph-förmig ist und nicht nur ein schlecht geschriebener SQL-Join. Praktiker, die das glaubwürdig können, verlangen eine Tagessatz-Prämie von 15-25 % über allgemeiner HANA-Modellierung, mit aktuellen Senior-Sätzen in DACH/Frankreich von 1.100-1.450 €/Tag.
Was Sie lernen
- Erkennen Sie, wann eine Geschäftsfrage eine Graph-Traversierung statt einer relationalen Aggregation erfordert, und wählen Sie den passenden HANA-Graph-Algorithmus aus
- Entwerfen Sie Knoten- und Kantentabellenschemata aus SAP-Quelldaten und behandeln dabei zusammengesetzte Schlüssel, Richtung und Kantenvolumen-Beschränkungen
- Implementieren Sie einen HANA-Graph-Workspace, führen Sie eingebaute Algorithmen aus (PageRank, kürzester Pfad, Nachbarschaftssuche) und stellen Sie die Ergebnisse über Calculation Views für SAC bereit
- Dimensionieren Sie Graph-Workspaces hinsichtlich ihrer Speicherauswirkung auf geteilten HANA-Mandanten und definieren Sie inkrementelle Refresh-Prozeduren für die Produktionsstabilität
Wenn relationale Modelle an ihre Grenzen stoßen
Die relationale Engine von SAP HANA glänzt beim Aggregieren von Fakten entlang dimensionaler Hierarchien — Umsatz nach Region, Gewinn nach Kostenstelle, Lagerbewegungen nach Werk. Sie stößt an ihre Grenzen, sobald die Frage sich um Verbindungen statt um Attribute dreht. Wer hat wen in einem Kundenadoptionsnetzwerk beeinflusst? Welcher Lieferant sitzt auf dem kritischen Pfad eines mehrstufigen Beschaffungsgraphen? Welche Berater sind auf einem Kollaborationsgraphen drei Schritte von einem bestimmten Practice Lead entfernt? Das sind Graphprobleme, und sie relationalen Joins aufzuzwingen erzeugt entweder eine kombinatorische Explosion oder Ausführungspläne, die auf produktiven HANA-Instanzen ins Timeout laufen.
SAP HANA Graph ist die native Antwort darauf. Als Kernkomponente der Engine in HANA 2.0 SPS 01 eingeführt und schrittweise bis SPS 06 gehärtet, arbeitet es mit Graph-Workspaces — Knotentabellen (Entitäten) und Kantentabellen (Beziehungen), gespeichert als gewöhnliche HANA-Column-Store-Tabellen und abgefragt über die openCypher-kompatible GRAPH-SQL-Erweiterung. Die Graph-Engine läuft in-process mit dem Column Store, das heißt: keine Datenbewegung und kein ETL in eine separate Graphdatenbank. Diese architektonische Entscheidung ist für SAP-Analytics-Workloads ausschlaggebend: Dieselbe HANA-Instanz, die BW/4HANA-InfoProvider oder Datasphere-Remote-Tabellen hält, kann gleichzeitig Graph-Traversierungsabfragen über dieselben physischen Daten bedienen.
Was die HANA-Graph-Engine tatsächlich leistet
Die Engine stellt drei Hauptfähigkeiten bereit:
Voraussetzungen
- Praktische Erfahrung auf mittlerem Niveau in SAP-Analytics-Projekten
- Zuerst die Kernkonzepte wiederholen: C028, C087, C083
Lernergebnisse
- Arbeiten Sie ein realistisches Szenario durch: Ein französischer Luftfahrt-Tier-1-Lieferant, der S/4HANA Sourcing and Procurement betreibt, muss nahezu in Echtzeit Bescheid wissen.
- Erkennen und vermeiden Sie das Anti-Pattern: Den Workspace auf ungefilterter Transaktionshistorie aufbauen — eine fünfjährige Bestelltabelle mit 200 Millionen Zeilen scheitert beim Laden; materialisieren Sie stets eine gefilterte Version.
- Wenden Sie die Kernentscheidung des Moduls an: Graph-Traversierung vs. relationale Aggregation — modellieren Sie es als HANA-Graph-Workspace, sobald das SQL bereits fünf oder mehr Self-Joins oder ein rekursives CTE benötigt.
- Verfolgen Sie den Lernfortschritt anhand des KPI: Abfragelatenz gegenüber der relationalen Baseline.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.