Die ultimative SAP HANA Architektur- und Upgrade-Analyse: Von In-Memory-Basics bis zur Cloud-Ära

Willkommen zurück im Tech-Blog! Als Senior SAP Technology Consultant werfe ich heute einen extrem detaillierten und tiefgreifenden Blick auf das Herzstück moderner SAP-Landschaften: SAP HANA (High-performance ANalytic Appliance). Wir verknüpfen heute das grundlegende historische Backup-Wissen mit den modernsten Architektur-Daten, Update-Pfaden und Code- beziehungsweise Skripting-Konzepten, um ein lückenloses Bild dieser revolutionären In-Memory-Datenbank zu zeichnen.

Historische Fakten und die technologische Evolution

Die Entwicklung von SAP HANA war ein Paradigmenwechsel, der maßgeblich von SAP-Mitbegründer Hasso Plattner sowie Teams des Hasso-Plattner-Instituts (HPI) und der Stanford University vorangetrieben wurde. Das Ziel war klar: Geschäftliche Fragestellungen in Echtzeit beantworten, ohne die Latenzen traditioneller, festplattenbasierter Datenbanken.

Die Architektur basierte in der Frühphase auf der Forschung an HYRISE (einer Main-Memory Hybrid Storage Engine, veröffentlicht im November 2010 und 2017 zu HYRISE2 weiterentwickelt). SAP integrierte und akquirierte zudem Schlüsseltechnologien wie die TREX Search Engine (für spaltenbasierte In-Memory-Suchen), P*TIME (eine 2005 erworbene In-Memory OLTP-Plattform) und MaxDB mit seiner liveCache-Engine. Das erste offizielle Release, SAP HANA 1.0, erfolgte im November 2010.

Über die Jahre folgten bahnbrechende Meilensteine:

• 2012: Einführung der SAP HANA Cloud Platform (PaaS) und SAP HANA One.

• 2013: Launch der HANA Enterprise Cloud (HEC) und von SAP HANA XS (eine integrierte, leichtgewichtige App-Server-Schicht).

• 2015: Release von SAP S/4HANA, der spezifisch für HANA geschriebenen, simplifizierten Business Suite.

• Nov 2016: Ankündigung von SAP HANA 2.0, das fortan als technologische Basis für Innovationen diente.

• 2020: Zehnjähriges Jubiläum und Launch der SAP HANA Cloud (DPaaS) auf Basis von Hyperscaler-Plattformen.

Kernarchitektur: OLTAP, Column-Store und MVCC

Die größte Innovation von SAP HANA ist die Etablierung als OLTAP-System (Online Transaction and Analytical Processing), oft auch als HTAP (Hybrid Transactional/Analytical Processing) bezeichnet. Diese Architektur eliminiert die Notwendigkeit, OLTP (Transaktionen) und OLAP (Analysen) in getrennten Systemen zu betreiben.

Row Store vs. Column Store

Die Datenhaltung erfolgt im RAM, was Datenzugriffe bis zu 10.000-mal schneller macht als auf Festplatten. Standardmäßig arbeiten Modellierungstools wie der Information Modeler ausschließlich mit Column Tables (Spaltenspeicher). Der Column-Store speichert Daten einer Spalte am selben Ort, was eine enorme vertikale Komprimierung und blitzschnelle OLAP-Abfragen ermöglicht.

Dennoch existiert der Row Store (Zeilenspeicher) weiterhin für spezifische administrative Aufgaben. Hier ist eine exakte architektonische Aufteilung der System-Schemata:

• Row Store: Schema SYS (beinhaltet Caches und administrative Tabellen der Engine) sowie Tabellen des Statistics Servers.

• Column Store: Schema _SYS_BI (Metadaten der Views und Stammdaten für MDX), Schema _SYS_BIC (generierte Tabellen für MDX) und Schema _SYS_REPO (Listen von aktiven/modifizierten Versionen der Modelle).

MVCC (Multiversion Concurrency Control) und Garbage Collection

SAP HANA verwaltet Nebenläufigkeit (Concurrency) über MVCC. Transaktionen erhalten Snapshots der Datenbank. Bei Updates werden alte Daten nicht überschrieben, sondern als obsolet markiert, während die neue Version hinzugefügt wird. Architektur-Wissen / Fehlerbehebung: Bei älteren HANA Revisionen (122.00 bis 122.04 sowie 122.07 bis 122.10) konnte es durch LOB Garbage Collection im Row Store zu Problemen kommen, die das globale MVCC Version Garbage Collection blockierten (siehe SAP Note 2413261 und 2482053). Dies führte zu einem stetigen Wachstum der HANA-Persistenz und Backups.

Multi-Tier Storage (Data Tiering)

Da RAM teuer ist, nutzt HANA Mechanismen für dynamisches Tiering:

• Hot Data: Im In-Memory.

• Warm Data / Cold Data: Ausgelagert auf Festplatten oder Data Lakes über Native Storage Extension (NSE).

Datenmodellierung: Die Evolution der Views

Die Aufbereitung der operativen Daten für den Endnutzer geschah traditionell im SAP In-Memory Computing Studio und später über moderne Web-IDEs. Das alte Basiswissen der HANA-Modellierung umfasst drei Haupt-Views:

1. Attribute Views: Agieren als Dimensionen oder Stammdaten-Tabellen. Bei Tabellen-Joins können hier Join-Typen wie leftOuter, rightOuter, fullOuter und textTable mit Kardinalitäten von 1:1, N:1 und 1:N definiert werden.

2. Analytic Views: Repräsentieren Cubes in einem Star Schema. Sie speichern keine Daten selbst, greifen aber auf den Column Store zu. Hier werden mindestens ein Attribut und ein Measure (Kennzahl) vorausgesetzt; zudem können Restricted und Calculated Measures implementiert werden.

3. Calculation Views: Diese entsprechen logisch den Virtual Providern mit Services-Konzept im SAP BW. Sie können grafisch (mit Union, Join, Projection-Knoten) oder skriptbasiert via SQLScript erstellt werden.

Mit SAP HANA 2.0 verschob sich die Entwicklung stark zur SAP Web IDE for SAP HANA und Core Data Services (CDS), um erweiterte Datenmodelle inkl. Syntax-Prüfung zu bauen.

Erweiterte Analysemöglichkeiten (Advanced Analytics)

SAP HANA bietet massive Parallelverarbeitung für rechenintensive Logik direkt in der Datenbank:

• SQLScript: Vermeidet Datenkopien an den Application Server durch Push-Down der Applikationslogik. Version 2 unterstützt Stored Procedures für verbesserte Kontrollflüsse.

• BFL (Business Function Library): In C++ geschrieben und in der HANA Calculation Engine ausgeführt. Sie bietet finanz- und betriebswirtschaftliche Algorithmen wie Abschreibungen (Asset Depreciation) und Moving Averages.

• PAL (Predictive Analytics Library): Beinhaltet native Algorithmen für statistische Berechnungen wie Clustering, Klassifizierung und Time-Series-Analyse.

• R-Integration: Offene Programmiersprache für statistisches Computing, nutzbar innerhalb von Stored Procedures (über 3000+ Pakete).

• Graph Engine: Verarbeitet die Cypher Query Language und nutzt den Graph Viewer. Strukturen liegen direkt im Column Store. Integrierte Algorithmen sind u.a. Pattern Matching, Single Shortest Path und Neighborhood Search.

• Spatial Processing: Native SQL-Erweiterungen für räumliche Datentypen (OGC-zertifiziert, integrierbar mit ESRI ArcGIS).

• Text Analytics: "Fuzzy" Search mit Fehlertoleranz und Entitätsextraktion (Voice of the Customer, Public Sector).

Application Development: Von XS Classic zu XSA

Anfänglich nutzte SAP die SAP HANA extended application services (XS Engine), um OData- und REST-Services mit HTML5/JavaScript bereitzustellen. Der moderne Nachfolger ist die XS Advanced Engine (XSA). XSA basiert auf einer Cloud Foundry Architektur und unterstützt "Bring Your Own Language". Native Laufzeitumgebungen für Node.js und JavaEE sind integriert, ebenso wie SAP HANA XS Javascript (XSJS) für abwärtskompatiblen serverseitigen Code.

Detaillierte Release-Strategie und komplexe Upgrade-Pfade

Einer der kritischsten Bereiche für SAP-Basiskonsultanten sind die Wartungs- und Upgrade-Pfade.

• HANA 1.0 SPS12: Das End of Maintenance für HANA 1.0 SPS12 wurde auf Mai 2021 festgelegt. Es folgten keine neuen SPS für HANA 1.0.

• HANA 2.0: Folgt der Strategie von 1 SPS pro Jahr. Die Maintenance-Dauer für ein neues SPS (ab SPS02) beträgt 2 Jahre, während das letzte SPS von HANA 2.0 einen Support-Zeitraum von 5 Jahren hat.

Die harten Fakten: Architektur-Limits beim Upgrade

Upgrades erfordern, dass Fixes der Quell-Revision in der Ziel-Revision enthalten sind. Ausnahmen und Inkompatibilitäten bestehen jedoch dokumentiert über die SPS-Grenzen hinweg:

• Die HANA 1 Revisionen 75-79, 86-89, 98-99 und 103-109 wurden komplett übersprungen.

• MDC (Multitenant Database Containers): Bei einem Upgrade eines HANA 1 MDC-Systems muss der Systemserver separate Metadatenbereiche haben, was erst ab Maintenance-Revision 122.04 der Fall ist. Ein vorheriges Upgrade auf das letzte HANA 1.0 SPS12 ist hier zwingend erforderlich.

• Überspringen von OS-Restriktionen: Manche HANA Revisionen (wie 122.35) unterstützen RHEL 7, aber kein RHEL 8, während HANA 2.0 Rev 60 RHEL 8, aber kein RHEL 7 unterstützt. Hier muss über "Intermediate Jumps" migriert werden, z.B. über Revision 54 (unterstützt RHEL 7 & 8), um dann auf OS-Ebene RHEL 8 zu aktualisieren und anschließend auf Rev 60 zu springen (gemäß Note 2407244).

• Beispiel aus der Upgradematrix: Von HANA 1.0 Revision 102.05 darf nicht direkt auf HANA 1.0 SPS11 (110, 111, 112) aktualisiert werden, da die Quell-Revision zu diesem Zeitpunkt bereits mehr Fixes enthielt als diese alten SPS11-Revisionen. Der zulässige Pfad wäre hier mindestens Revision 112.02 oder HANA 1.0 SPS12 (Revision ≥ 120).

Integration in die SAP-Landschaft: NetWeaver, Fiori und S/4HANA

SAP HANA ist die exklusive Basis für SAP S/4HANA.

• Naming-Convention: S/4HANA Versionen wurden bis 2020 als YYMM bezeichnet (z.B. 1909 für September 2019) und für On-Premise ab Oktober 2020 auf das YYYY-Format (z.B. S/4HANA 2020) umgestellt.

• NetWeaver AS ABAP: Aktuellste Stack-Schichten umfassen Versionen wie AS ABAP 7.54 (SAP_BASIS Component). Das Vorgängersystem ECC endete bei EHP 618 als letztem großen Release (gekennzeichnet durch die "1", z.B. HANA-optimiert), identifizierbar über die SAP_APPL Komponente.

• SAP Fiori & UI5: Die Benutzeroberflächen haben sich drastisch gewandelt – von BlueCrystal (2015) über Belize / Belize Deep (Fiori 2.0 in 2016) hin zu Fiori 3 mit den Themes Quartz Light/Dark. Bei SAPUI5 (prüfbar via sap.ui.version in Browser DevTools) wechselte die Auslieferung über die SAP Business Technology Platform (BTP) von Quartals- auf Monats-Rhythmus, wobei jede zwölfte Version eine Long-Term Maintenance Version wird.

Editionen, High Availability & Security

Für Cloud- und On-Premise-Szenarien existiert SAP HANA in verschiedenen Lizenzmodellen (Runtime vs. Full Use) sowie Editionen:

• Base Edition: Kernfunktionen der Datenbank.

• Platform Edition: Base + Spatial, Predictive, R, Text, Graph.

• Enterprise Edition: Platform + Rule Frameworks + Data Loading Komponenten.

• Express Edition: Kostenlos für produktive Zwecke bis zu 32 GB RAM, erweiterbar auf 128 GB RAM.

In HANA 2.0 wurde das Management massiv durch das SAP HANA Cockpit vereinfacht. Im Bereich High Availability (HA) / Disaster Recovery (DR) unterstützt HANA 2.0 den Active/Active-Read Enabled Mode, um leselastige Abfragen (z.B. Analytics) vom Primärsystem auf das Sekundärsystem (Replication Node) zu verlagern. Sicherheitstechnisch punktet HANA mit umfassender Data-at-Rest-Verschlüsselung für Data und Redo-Logs sowie automatischer Rollenzuweisung über existierende LDAP-Gruppen.

Fazit

SAP HANA hat sich von einer anfänglichen In-Memory-Forschungsvision zu einer hochkomplexen Multi-Model-Transaktions- und Entwicklungsplattform entwickelt. Die Kombination aus HTAP-Architektur, Column Store Performance und fortschrittlichen In-Database-Berechnungen (SQLScript, PAL, Graph, Spatial) hat die traditionelle Lücke zwischen OLTP und OLAP für immer geschlossen. Für Architekten und Administratoren bedeutet dies einerseits ungeahnte Performance (3,5 Milliarden Scans pro Sekunde pro Core), andererseits aber auch eine hohe Verantwortung bei der Einhaltung exakter Upgrade-Pfade, System-Architektur-Regeln und OS-Abhängigkeiten. Die Ablösung von HANA 1.0 durch HANA 2.0 und die aktuelle Verlagerung in die HANA Cloud beweisen: Die In-Memory-Revolution war erst der Anfang einer vollständig datengetriebenen Unternehmensrealität.