Sie sind auf Seite 1von 609
SAP PRESS ist eine gemeinschaftlich e Initiative von SAP SE und der Rheinwerk Verlag GmbH.

SAP PRESS ist eine gemeinschaftliche Initiative von SAP SE und der Rheinwerk Verlag GmbH. Ziel ist es, Anwendern qualifiziertes SAP-Wissen zur Verfügung zu stellen. SAP PRESS vereint das fachliche Know-how der SAP und die verlegerische Kompetenz von Rheinwerk. Die Bücher bieten Expertenwissen zu technischen wie auch zu betriebswirtschaftlichen SAP-Themen.

Matthias Merz, Torben Hügens, Steve Blum SAP BW auf SAP HANA

489 Seiten, 2014, geb.

ISBN 978-3-8362-2965-4

Thorsten Schneider, Eric Westenberger, Hermann Gahm ABAP-Entwicklung für SAP HANA

602 Seiten, 2013, geb.

ISBN 978-3-8362-1996-9

Michael Mattern, Ray Croft

Business Cases mit SAP HANA

591 Seiten, 2014, geb.

ISBN 978-3-8362-2673-8

Heilig, John, Kessler, Knötzele, Thaler-Mieslinger SAP NetWeaver BW und SAP BusinessObjects

866 Seiten, 2. Auflage 2013, gebunden

ISBN 978-3-8362-2048-4

Aktuelle Angaben zum gesamten SAP PRESS-Programm finden Sie unter www.sap-press.de .

Bjarne Berg, Penny Silvia

Einführung in SAP HANA ®

Bjarne Berg, Penny Silvia Einführung in SAP HANA ®

Liebe Leserin, lieber Leser,

vielen Dank, dass Sie sich für ein Buch von SAP PRESS entschieden haben.

Haben Sie auch schon von SAP HANA gehört, wissen aber noch nicht so recht, worum es dabei geht und was die Vor- und Nachteile sind? Vielleicht überle- gen Sie aber schon, ob ein Umstieg auf SAP HANA in Ihrem Unternehmen sinnvoll ist? Scheuen Sie sich vielleicht noch vor den vielen unbekannten Auf- gaben und Kosten, die dabei auf Sie zukommen?

Unsere Autoren Bjarne Berg und Penny Silvia machen Ihnen den Einstieg in SAP HANA leicht. Lernen Sie die Grundlagen von SAP HANA und In-Memory- Computing kennen, und finden Sie heraus, was sich hinter Big Data verbirgt und wofür Sie eine SAP HANA Appliance einsetzen können. Die Neuauflage bringt Sie auf den neuesten Stand in Sachen SAP HANA Cloud Platform, SAP River und SAP HANA XS. So können Sie mit Ihrem HANA-Projekt schnell durchstarten!

Wir freuen uns stets über Lob, aber auch über kritische Anmerkungen, die uns helfen, unsere Bücher zu verbessern. Scheuen Sie nicht, mich zu kontaktieren; Ihre Fragen und Anmerkungen sind jederzeit willkommen.

Ihre Kerstin Billen

Lektorat SAP PRESS

Rheinwerk Verlag

Rheinwerkallee 4

53227 Bonn

kerstin.billen@rheinwerk-verlag.de

www.sap-press.de

Hinweise zur Benutzung

Dieses E-Book ist urheberrechtlich geschützt. Mit dem Erwerb des E-Books haben Sie sich verpflichtet, die Urheberrechte anzuerkennen und einzuhal- ten. Sie sind berechtigt, dieses E-Book für persönliche Zwecke zu nutzen. Sie dürfen es auch ausdrucken und kopieren, aber auch dies nur für den persön- lichen Gebrauch. Die Weitergabe einer elektronischen oder gedruckten Kopie an Dritte ist dagegen nicht erlaubt, weder ganz noch in Teilen. Und auch nicht eine Veröffentlichung im Internet oder in einem Firmennetzwerk.

Die ausführlichen und rechtlich verbindlichen Nutzungsbedingungen lesen Sie im Abschnitt Rechtliche Hinweise.

Dieses E-Book-Exemplar ist mit einem digitalen Wasserzeichen versehen, einem Vermerk, der kenntlich macht, welche Person dieses Exemplar nutzen darf:

Impressum

Dieses E-Book ist ein Verlagsprodukt, an dem viele mitgewirkt haben, insbesondere:

Lektorat Kerstin Billen

Lektorat der Originalausgabe Kelly Grace Weaver

Korrektorat Friederike Daenecke

Herstellung E-Book Melanie Zinsler

Covergestaltung Silke Braun

Coverfotos iStockphoto.com: 3451372 © mevans; iStockphoto.com: 18132624 © Jeja

Satz E-Book SatzPro, Krefeld

Wir hoffen sehr, dass Ihnen dieses Buch gefallen hat. Bitte teilen Sie uns doch Ihre Meinung mit und lesen Sie weiter auf den Serviceseiten.

Bibliografische Information der Deutschen Nationalbibliothek:

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN 978-3-8362-3459-7 (Buch)

ISBN 978-3-8362-3460-3 (E-Book)

2. Auflage 2015

© Rheinwerk Verlag GmbH, Bonn 2015

Inhalt

Vorwort zur 2. Auflage

17

Einführung

19

Danksagung

21

TEIL I

Was, warum und wann?

1 In-Memory-Computing, Big Data und SAP HANA

25

1.1 Einführung in das In-Memory-Computing und Big Data

26

1.1.1 In-Memory-Computing und Analysen

26

1.1.2 Big Data

31

1.2 SAP HANA – Einführung

35

1.2.1 SAP HANA als In-Memory-Computing-Lösung

36

1.2.2 SAP HANA und Big Data als Wegbereiter für Big-Data-Lösungen

39

1.2.3 Spaltenbasierte Speicherung versus zeilenbasierte Speicherung

43

1.2.4 Die Möglichkeiten von SAP HANA

50

1.2.5 SAP HANA – Akzeptanzkriterien

53

1.3 Einführung in die Implementierungsoptionen

55

1.3.1 Data Warehouse für Analysen

55

1.3.2 SAP BW auf SAP HANA

56

1.3.3 SAP Business Suite auf SAP HANA

56

1.4 Zusammenfassung

58

2 SAP-HANA-On-Premise-Implementierungsoptionen

59

2.1 SAP HANA als Data Warehouse für Analysen

59

2.1.1 Technische Voraussetzungen

63

2.1.2 Erforderliche Qualifikationen

66

2.1.3 Schritte der Projektplanung

71

2.2 SAP BW auf SAP HANA

73

2.2.1 Technische Voraussetzungen

81

2.2.2 Erforderliche Qualifikationen

84

2.2.3 Schritte der Projektplanung

87

2.3 SAP Business Suite auf SAP HANA

90

2.3.1 Technische Voraussetzungen

94

2.3.2 Erforderliche Qualifikationen

95

Inhalt

2.3.3

Schritte der Projektplanung

98

2.4 Auswählen einer SAP-HANA-Implementierungsoption

101

2.4.1 Auswahlmöglichkeit: SAP HANA als Data Warehouse für Analysen

103

2.4.2 Auswahlmöglichkeit: SAP BW auf SAP HANA

104

2.4.3 Auswahlmöglichkeit: SAP Business Suite auf SAP HANA

105

2.5 Zusammenfassung

106

3 SAP HANA in der Cloud

111

3.1 Cloud – Grundlagen

111

3.2 SAP HANA Cloud Platform und SAP HANA Enterprise Cloud

113

3.2.1 SAP HANA Cloud Platform

113

3.2.2 SAP HANA Enterprise Cloud

115

3.2.3 SAP HANA Cloud Platform im Vergleich zu SAP HANA Enterprise Cloud

116

3.3 Auswählen von SAP HANA in der Cloud

117

3.3.1 SAP HANA als Data Warehouse für Analysen

120

3.3.2 SAP BW auf SAP HANA

121

3.3.3 SAP Business Suite auf SAP HANA

122

3.4 Zusammenfassung

123

4 Erweiterte Anwendungen für SAP HANA

125

4.1 SAP HANA Live

125

4.2 SAP Predictive Analysis für SAP HANA

128

4.3 SAP Business Planning and Consolidation für SAP HANA

133

4.4 SAP-Simple-Suite-Lösungen

136

4.5 Zusammenfassung

137

5 SAP HANA und Ihre Geschäftsstrategie

139

5.1 Transformationsmöglichkeiten identifizieren

141

5.2 Ihre Bedürfnisse erkennen

145

5.2.1 Unternehmensbedürfnisse

145

5.2.2 Datenbedarf

147

5.3 Mit bestehenden Lösungen arbeiten: SAP HANA versus SAP BWA

151

5.3.1

Ersetzt SAP HANA meine bestehende BWA-Lösung?

151

Inhalt

5.3.2 Vor- und Nachteile des BWA

154

5.3.3 Vor- und Nachteile von SAP HANA

156

5.3.4 Ergebnis

158

5.4 Schreiben eines Business Case, Budgetierung und Personalbesetzung für SAP HANA

160

5.4.1 Schreiben eines Business Case

161

5.4.2 Budgetierung für eine SAP-HANA- Implementierung

166

5.4.3 Personalbesetzung einer SAP-HANA- Implementierung

169

5.4.4 Gestalten einer Roadmap

171

5.5 Häufig gestellte Fragen zu SAP HANA

174

5.5.1 Ist SAP HANA eine Datenbank, eine Hardware oder eine Lösung?

174

5.5.2 Welcher Kundentyp zieht SAP-HANA-Lösungen in Erwägung?

174

5.5.3 Was sind die Problemstellungen, die den Bedarf an SAP HANA aufzeigen?

175

5.5.4 Was ist das Unterscheidungsmerkmal für SAP mit SAP HANA?

175

5.5.5 Ist SAP HANA sofort betriebsbereit?

176

5.5.6 Funktionieren Nicht-SAP-Business-Intelligence- Werkzeuge auf SAP HANA?

176

5.5.7 Was muss ein Kunde alles kaufen, um SAP HANA anwenden zu können?

177

5.5.8 Was kostet SAP HANA?

177

5.5.9 Ersetzt SAP HANA die BWA-Lösung für Kunden?

178

5.5.10 Kann SAP HANA als Cloud-Lösung eingesetzt werden?

179

5.5.11 Ist SAP HANA eine weitere »Modeerscheinung« wie mySAP, die nicht von langer Lebensdauer sein wird?

179

5.6 Zusammenfassung

179

TEIL II

Wie wird SAP HANA eingesetzt?

6 Planung einer SAP-HANA-Implementierung

183

6.1

Von der Implementierung unabhängige Überlegungen

183

6.1.1

SAP-HANA-Editionen

183

Inhalt

6.1.2

Hardwarespezifikationen und -optionen

189

6.2 SAP HANA als Data Warehouse

196

6.2.1 Datenmodellierung

196

6.2.2 Sizing

198

6.3 SAP Business Suite auf SAP HANA

204

6.3.1 Vollständige Neuinstallation

206

6.3.2 In-Place-Migration

208

6.3.3 Kopieren, upgraden und migrieren

212

6.3.4 Sizing

212

6.4 SAP Business Warehouse auf SAP HANA

218

6.4.1 Sizing

219

6.4.2 Vorbereiten einer Migration

227

6.4.3 Durchführen der Migration

232

6.4.4 Optimieren einer Migration

236

6.4.5 Neue Funktionen in SAP BW 7.4

244

6.5 Zusammenfassung

246

7 SAP HANA und SAP Business Intelligence

249

7.1 Die Werkzeuge im Überblick

249

7.1.1 SAP BusinessObjects Dashboards

249

7.1.2 SAP BusinessObjects Web Intelligence

251

7.1.3 SAP BusinessObjects Explorer

252

7.1.4 SAP BusinessObjects Analysis

257

7.1.5 SAP BusinessObjects Design Studio

259

7.1.6 SAP Crystal Reports

260

7.1.7 SAP Lumira

262

7.2 SAP-BusinessObjects-BI-Werkzeuge mit SAP HANA verbinden

265

7.2.1 Universen mit Open und Java Database Connectivity (ODBC/JDBC)

266

7.2.2 Herstellen einer Verbindung zu Excel mit Open Database Objects und MDX

274

7.2.3 Erstellen einer Microsoft-Query-Abfrage für SAP HANA

277

7.2.4 BICS-Verbindungen

279

7.2.5 Verbindungsoptionen im Überblick

279

7.3 Zusammenfassung

280

Inhalt

8 Entwicklerwerkzeuge für SAP HANA

281

8.1 UI Development Toolkit für HTML5 (SAPUI5)

281

8.1.1

Die Bibliotheken des UI Development Toolkit

für HTML5

284

8.1.2 Grundlagen

285

8.1.3 Erste Schritte

288

8.2 SAP HANA Extended Application Services (XS)

292

8.3 SAP HANA Live

296

8.4 SAP HANA Cloud Platform

298

8.4.1 Erste Schritte

299

8.4.2 Datenbankschemata und der SAP HANA Cloud Catalog

302

8.4.3 Die Rollen in der SAP HANA Cloud Platform festlegen

304

8.5 SAP River

305

8.5.1 Erstellen einer SAP-River-Anwendung

305

8.5.2 Hinzufügen von Aktionen in SAP River

307

8.5.3 Erstellen von Sichten in SAP River

308

8.5.4 Verwenden des SAP River Editors

309

8.5.5 Hinzufügen von Daten in SAP River

310

8.6 Zusammenfassung

312

9 Datenmodellierung mit dem Information Composer

313

9.1 Einführung in die Bedienung des Information Composers

315

9.1.1 Funktionsweise

316

9.1.2 Beispielszenario

318

9.2 Hochladen von Daten auf SAP HANA

321

9.2.1 Datenquelle angeben und Daten laden

321

9.2.2 Datenbereinigung

325

9.2.3 Klassifizieren von Datenspalten

329

9.2.4 Sichern der Daten

331

9.3 Erstellen von Informationssichten

332

9.3.1 Datenquellen angeben

332

9.3.2 Daten zusammenführen

336

9.4 Anzeigen hochgeladener Daten und erstellter

Informationssichten

343

9.4.1 Der Bildbereich »My Data«

343

9.4.2 Der Bildbereich »My Information Views«

345

9.5 Zusammenfassung

346

Inhalt

10 Datenmodellierung mit SAP HANA Studio

347

10.1 SAP HANA Studio – Überblick und Terminologie

348

10.2 Erste Schritte mit dem SAP HANA Information Modeler

353

10.2.1 Hinzufügen eines Systems

355

10.2.2 Öffnen von Perspektiven

357

10.2.3 Verwenden von Quick Launch

358

10.2.4 Anlegen eines Pakets

359

10.2.5 Beispielszenario

360

10.3 Anlegen von Attributsichten

362

10.3.1 Anlegen einer Attributsicht

362

10.3.2 Erstellen von Drilldown-Funktionen in einer Attributsicht

371

10.3.3 Überprüfen, Speichern und Aktivieren von Attributsichten

371

10.3.4 Anlegen der Zeitattributsicht

373

10.4 Anlegen von Analysesichten

374

10.4.1 Anlegen einer Analysesicht

374

10.4.2 Hinzufügen von Sichten und Tabellen

375

10.4.3 Auswählen verfügbarer Felder für eine Analysesicht

377

10.4.4 Hinzufügen eines Sprachenfilters zur Analysesicht

378

10.4.5 Hinzufügen einer Berechnung zu einer Analysesicht

378

10.4.6 Anzeigen einer Datenvorschau in einer Analysesicht

380

10.4.7 Kopieren einer Analysesicht

381

10.5 Anlegen von Berechnungssichten über die grafische Methode

382

10.6 SQL und SQLScript

393

10.6.1 Verwenden von SQL

393

10.6.2 Verwenden von SQLScript

400

10.7 Zusammenfassung

405

11 Erweiterte Konzepte in SAP HANA Studio

409

11.1 Data-Mart-Virtualisierung

409

11.2 Abgeleitete Attributsichten

411

11.3 Berechnete Attribute

417

11.4 Eingeschränkte und berechnete Kennzahlen

420

11.5 Filter und Variablen

426

11.5.1 Filter

426

11.5.2 Variablen und Eingabeparameter

436

Inhalt

11.6 Währungsumrechnung

440

11.6.1 Verwenden eines Eingabeparameters zum Festlegen der Zielwährung

443

11.6.2 Verknüpfen von Kennzahlen mit Währungen ohne Verwendung der Umrechnung

445

11.7 Hierarchien

446

11.7.1 Anlegen einer abgeflachten Hierarchie

446

11.7.2 Anlegen einer Eltern-Kind-Hierarchie

451

11.8 Personalisierung von SAP HANA Studio

453

11.8.1 Modellvalidierung

453

11.8.2 Versionierung

455

11.8.3 Modellreferenzen prüfen

455

11.8.4 Customizing von Perspektiven

457

11.9 Zusammenfassung

458

12 Datenbereitstellung

461

12.1 Auswählen einer Methode für die Datenbereitstellung

462

12.1.1 Strategische Überlegungen

465

12.1.2 Technische Überlegungen

472

12.2 Triggerbasierte Datenreplikation: SAP Landscape Transformation (SLT)

475

12.2.1 Installation

476

12.2.2 Funktionsweise von SLT

477

12.2.3 Konfiguration von SLT

480

12.2.4 Administration von SLT (Start, Replicate, Stop, Suspend, Resume)

481

12.2.5 Erweiterte Funktionen

483

12.2.6 Einrichten einer neuen Replikationskonfiguration in SAP HANA

488

12.2.7 Hinzufügen von Tabellen zu einer vorhandenen Replikationskonfiguration

495

12.3 ETL-basierte Datenreplikation: SAP Data Services

500

12.3.1 Voraussetzungen für die Konfiguration

502

12.3.2 SAP HANA für den Empfang von Daten über SAP Data Services vorbereiten

503

12.3.3 Daten laden

506

12.4 Transaktionsprotokollbasierte Datenreplikation:

SAP (Sybase) Replication Server und Load Controller

526

12.4.1

Installation

528

Inhalt

12.4.2

Ausführen der Replikation mit SAP/Sybase Replication Server

530

12.5 Direct Extractor Connection

530

12.5.1 Die DXC-Technologie

531

12.5.2 Wichtige Überlegungen zum Einsatz von DXC

534

12.5.3 SAP HANA für DXC vorbereiten

538

12.5.4 Das Quellsystem für DXC vorbereiten

539

12.5.5 Mit DHX Daten in SAP HANA laden

540

12.6 Zusammenfassung

541

13 Administration von SAP HANA

543

13.1 Die Administration Console von SAP HANA verwenden

544

13.1.1 Hinzufügen von Systemen

545

13.1.2 Exportieren und Importieren von Systemen

548

13.1.3 Anzeigen von Details zur Systeminstallation

548

13.1.4 Administration Editor und Diagnosemodus

551

13.1.5 Ändern des Speicherorts für Dateien

551

13.1.6 Ändern von Konfigurationen

551

13.1.7 Anpassen der Administration Console

552

13.2 Überwachen von Systemen

554

13.2.1 Überwachen der Datenträgerverwendung

556

13.2.2 Überwachen der Performance

557

13.2.3 Überwachen mithilfe von Alerts

558

13.2.4 Konfigurieren von Alerts

559

13.2.5 Überwachen von Services und verteilten Systemen

560

13.2.6 Exportieren und Importieren von Tabellendaten

562

13.2.7 Überwachen der Speichernutzung

563

13.2.8 Große Tabellen durch Partitionierung verwalten

564

13.2.9 Lastausgleich durch Verschieben von Dateien und Partitionen

567

13.2.10Beheben von Disk Full Events

568

13.2.11Unterstützung für nicht reagierende Systeme

568

13.3 Aktualisierung

569

13.3.1 Aktualisieren der SAP HANA Appliance

569

13.3.2 Aktualisieren von SAP HANA Studio

570

13.4 Sicherheit

572

13.4.1 Systemberechtigungen

572

13.4.2 Sicherheit bei der Authentifizierung

573

13.4.3 Sicherheit von Berechtigungen

574

Inhalt

 

13.4.4

Eine Kennwortrichtlinie definieren

579

13.5 Lizenzschlüssel

580

13.5.1 Temporäre Lizenzschlüssel

581

13.5.2 Permanente Lizenzschlüssel

582

13.6 Sicherung und Hochverfügbarkeit

583

13.6.1 Sicherung

583

13.6.2 Hochverfügbarkeit

585

13.6.3 Mehrere Datenbanken und Komponenten auf derselben Hardware

586

13.7 SAP Solution Manager und SAP HANA

588

13.8 DBA Cockpit für SAP HANA

590

13.9 Zusammenfassung

593

A

Die Autoren

595

Index

597

Vorwort 2 zur 2. Auflage

Sie halten die neue Auflage von Einführung in SAP HANA in Ihren Händen. Wie Sie sehen, machten der beeindruckende Erfolg der 1. Auflage und die schnellen Änderungen im Umfeld von SAP HANA eine Aktualisierung dieses Buches erforderlich.

Unmengen von Daten stehen uns in bislang einmaligen Größenordnungen zur Verfügung. Wenn wir diese Daten schnell bzw. in Echtzeit analysieren könnten, wären wir in der Lage, die Geschäftsstrategien in einem globalisier- ten Wirtschaftssystem zu ändern. Dies gilt sowohl für große internationale Konzerne als auch für mittelständische und kleine Unternehmen, da der Wunsch nach Wachstum bei allen Beteiligten gleichermaßen vorhanden ist. Um in Echtzeit neue Erkenntnisse aus diesen riesigen Datenmengen gewin- nen zu können, benötigen wir neue Methoden zur Verarbeitung solcher Daten. Glücklicherweise ist dies mittlerweile möglich – da die In-Memory- Technologie und die Funktionen der zugrunde liegenden Hardwareinfra- struktur verfügbar und erschwinglich sind.

Mit der Einführung von SAP HANA als Plattform sind wir dieser Vision einer gemeinsamen Datengrundlage ein Stück nähergekommen, denn SAP HANA ist eine Basis für die Ausführung analytischer und transaktionaler Prozesse in hoher Geschwindigkeit. Die bahnbrechende In-Memory-Technologie von SAP HANA erfordert von den Kunden eine klare Identifizierung der relevan- ten Geschäftsszenarien und die Bestimmung der Business Cases, mit denen Unternehmen mindestens eines der folgenden Ziele (bzw. idealerweise alle drei) erreichen können:

Kann das Unternehmen mehr Umsatz und folglich mehr Gewinn erzielen?

Kann das Unternehmen eine höhere Kundenzufriedenheit erreichen?

Können interne Prozesse so signifikant verändert werden, dass die Kosten gesenkt werden?

Die Einsatzbereiche von SAP HANA können sehr stark variieren. Ein Finanz- unternehmen beispielsweise wird völlig andere Anforderungen haben als ein Automobilzulieferer oder ein Einzelhändler. Trotz dieser Unterschiede sind dies dennoch die wichtigsten Fragen, die sich ein Unternehmen bei der Implementierung von SAP HANA stellen sollte.

Vorwort zur 2. Auflage

Die Entscheidung für SAP HANA wird für gewöhnlich aus der unternehme- rischen Perspektive getroffen. Aus Sicht der IT stellt die Situation oftmals eine große Herausforderung dar: Unabhängig davon, ob SAP HANA als eine integrierte Lösung mit einem Paket aus Hardware und Software (einer »App- liance«) bereitgestellt oder als maßgeschneiderte Lösung umgesetzt wird, handelt es sich neben den ITIL-Prozessen immer noch um ein Gerät im Rechenzentrum, das ihre volle Aufmerksamkeit erfordert – ähnlich wie eine Infrastruktur, in der klassische SAP-Anwendungen betrieben werden. Aufga- ben wie die Installation neuer Systeme, Überwachung des laufenden Sys- tems, Upgrades und Patches, Sicherungen und Wiederherstellung, Aufrecht- erhaltung einer hohen Verfügbarkeit, Sicherstellung der Skalierbarkeit, Überwachung der Sicherheit und Gewährleistung der Business Continuity ändern sich niemals. Diese Anforderungen müssen alle voll entwickelt und rechenzentrumstauglich sein, bevor Unternehmen SAP HANA für geschäfts- kritische Daten nutzen können – insbesondere wenn nicht nur analytische, sondern auch transaktionale Daten in SAP HANA gespeichert werden.

Die 2. Auflage dieses Buchs gewährt Ihnen Einblicke in die Optionen zur Bereitstellung von SAP HANA, bietet Informationen über erweiterte Anwen- dungen für SAP HANA und gibt Empfehlungen rund um die IT-Verwaltung der SAP-HANA-Infrastruktur im Rechenzentrum. Zudem beinhaltet dieses Buch Anleitungen für Administrationsaufgaben, Beschreibungen zur Ent- wicklung neuer Anwendungen, die auf SAP HANA basieren, sowie Informa- tionen über neue Liefermodelle, z.B. Hostlösungen für SAP-HANA-Land- schaften. Kurzum, dieses Buch bietet Ihnen alles für den Einstieg in SAP HANA.

Irene Hopf Consulting Architect Global Lead for SAP HANA Solutions bei IBM

Einführung

SAP HANA entwickelt sich mit jedem Release weiter – und wir freuen uns, dass sich dieses Buch parallel dazu weiterentwickeln kann. Willkommen zur 2. Auflage von Einführung in SAP HANA. Sie erhalten hier neue Informatio- nen über SAP HANA in der Cloud, zur Entwicklung nativer Anwendungen mithilfe der SAP HANA Cloud Platform und zu SAP River.

Wenn Sie dieses Buch zum ersten Mal nutzen, finden Sie hier einen kurzen Fahrplan: Teil I richtet sich an all jene, die die Grundlagen von SAP HANA verstehen lernen möchten. In Kapitel 1 erhalten Sie eine Einführung in das Thema mit allgemeinen Erläuterungen zu Big Data und In-Memory Compu- ting, und Sie erfahren, wie diese beiden Aspekte in SAP HANA aufeinander- treffen. Kapitel 2 geht weiter ins Detail und beschreibt die drei Hauptoptio- nen für die Implementierung von SAP HANA vor Ort. Für alle Leser der vorherigen Auflage: Kapitel 3 ist brandneu und präsentiert Ihnen die Mög- lichkeiten von SAP HANA in der Cloud, einschließlich der SAP HANA Cloud Platform und der SAP HANA Enterprise Cloud. In Kapitel 4 stellen wir Ihnen einige der erweiterten Anwendungen vor, die von SAP HANA unter- stützt werden. Hierzu gehört auch eine kurze Einführung in die SAP Simple Suite. In Kapitel 5 erfahren Sie schließlich, wie Sie eine Geschäftsstrategie mit SAP HANA entwerfen.

Teil II ist der technischen Seite gewidmet. In Kapitel 6 erläutern wir die ers- ten Schritte zur Planung einer SAP-HANA-Implementierung und liefern aus- führliche Informationen zu allen drei Arten der On-Premise-Versionen. In Kapitel 7 stellen wir Ihnen SAP HANA und die SAP-Business-Intelligence- Werkzeuge einschließlich SAP Lumira vor. Kapitel 8 ist ein weiteres brand- neues Kapitel. Hier werden die Möglichkeiten zur Entwicklung von Anwen- dungen als Ergänzung zu SAP HANA vorgestellt, einschließlich neuer Tech- nologien wie SAP HANA Cloud Platform und SAP River. In Kapitel 9, Kapitel 10 und Kapitel 11 tauchen Sie in die Feinheiten von SAP HANA ein:

Schritt-für-Schritt-Anleitungen und zahlreiche Screenshots zum Arbeiten mit dem Information Composer und SAP HANA Studio veranschaulichen Ihnen die Zusammenhänge detailliert und leicht nachvollziehbar. Die ausführli- chen Erläuterungen werden in Kapitel 12 mit Informationen zur Datenbe- reitstellung für SAP Data Services, SAP Landscape Transformation und SAP

Einführung

(Sybase) Replication Server fortgesetzt. Abschließend wird das Buch in Kapi- tel 13 mit der Administration von SAP HANA abgerundet.

Unser Ziel mit diesem Buch war und ist es, Ihnen Informationen zur erstma- ligen Umsetzung von SAP HANA an die Hand zu geben und Sie auf die näch- sten Schritte vorzubereiten. Wir vertrauen darauf, dass diese neueste Aus- gabe diese Tradition fortsetzt.

Dr. Bjarne Berg Associate Professor, SAP University Alliance, Lenoir Rhyne University Vice President of Information Technology, ComeritLabs

Penny Silvia IBM Global Business Services SAP Center of Competency, Global Analytics und SAP HANA Leader

Danksagung

Wir möchten Filip Lemmens von ComeritLabs für seine wertvollen Beiträge zu Kapitel 11 und Kapitel 12 danken. Ebenso danken wir Tag Robertson von IBM Labs in Research Triangle Park, North Carolina, für die Bereitstellung eines leistungsstarken SAP-HANA-Hardwaresystems, das wir beim Schreiben dieses Buchs eingesetzt haben. Des Weiteren gilt unser Dank Irene Hopf für die Unterstützung von IBM bei der Erstellung dieses Buchs sowie Brandon Harwood, Nick Le und Rob Frye von ComeritLabs in North Carolina für ihre rasche Unterstützung und Tests der SAP-Lösungen. Außerdem danken wir Rich Travis von IBM für seine Erkenntnisse und Unterstützung hinsichtlich der SAP-HANA-Hardware sowie Dale Young, Gagan Reen und Guillermo Vazquez für ihre Erkenntnisse, Beiträge und unaufhörliche Motivation und Unterstützung. Und schließlich bedanken wir uns bei Vijay Vijayasankar für die Beantwortung all unserer Fragen und E-Mails.

TEIL I Was, warum und wann?

Kapitel 1

In diesem Kapitel erfahren Sie mehr über den Zusammenhang zwischen In-Memory-Computing, Big Data und SAP HANA.

1 In-Memory-Computing, Big Data und SAP HANA

SAP HANA wurde in der Geschäftswelt zunächst als Datenbank eingesetzt. Es wurde als In-Memory-Datenbank positioniert und vertrieben, mit der die Geschwindigkeit bestehender (und neuer) SAP-Lösungen drastisch erhöht werden konnte. Ja, SAP HANA ist – im Kern – eine Datenbank. Es ist aber weit mehr als eine Datenbank. Es ist eine Entwicklungsplattform. Es ist eine Technologielandschaft. Es ist eine Möglichkeit, das Geschäft und das Unter- nehmen umzuwandeln.

SAP HANA hat sich seit seiner Einführung stark weiterentwickelt. Mittler- weile ist es der Eckpfeiler für die Zukunft der Technologie- und Entwick- lungsplattform von SAP. SAP erwirbt neue Werkzeuge und entwickelt beste- hende Werkzeuge weiter, wobei SAP HANA bei allen als grundlegende Plattform vorausgesetzt wird. Daher werden neue Werkzeuge und Funktio- nen für SAP HANA optimiert. Vergleichbar mit SAP Solution Manager wird SAP HANA ein immer stärker integrierter Bestandteil des SAP-Funktions- angebots.

In diesem Sinne positioniert SAP die Appliance SAP HANA weiterhin als eine Basistechnologie zur Unterstützung stark optimierter Geschäftspro- zesse und Analysen sowie als Grundlage für die Funktionen, die in einer SAP-basierten Umgebung bisher nicht möglich gewesen waren. Unterneh- men, die eine SAP-HANA-basierte Plattform nutzen, haben das Potenzial – die Fähigkeit –, Anwendungen und Lösungen aufzubauen, um bisher scheinbar unlösbare Herausforderungen zu meistern. Fluggesellschaften und Frachtunternehmen setzen SAP-HANA-fähige Lösungen zur Routen- optimierung und Verbesserung der Wirtschaftlichkeit ein. Einzelhändler nutzen SAP-HANA-basierte Lösungen zur Identifizierung von Betrugsfällen und zu Preisabsprachen mit den Lieferanten – und das alles in Echtzeit. Wenn Sie nun diese scheinbar unüberwindbaren Technologiehindernisse

1

In-Memory-Computing, Big Data und SAP HANA

meistern können, können Sie tatsächlich eine Veränderung und Optimie- rung Ihrer Geschäftsprozesse bewirken.

In diesem Kapitel beginnen wir mit den Grundlagen von SAP HANA, indem wir die Konzepte In-Memory-Computing und Big Data erläutern, die für SAP HANA von großer Bedeutung sind. Anschließend stellen wir Ihnen SAP HANA selbst vor und zeigen Ihnen, wie die beiden Konzepte darin zusam- mengeführt werden. Schließlich erhalten Sie als Vorbereitung auf die nach- folgenden Kapitel eine kurze Übersicht über die Implementierungsmöglich- keiten von SAP HANA.

Die Informationen in diesem Kapitel werden so präsentiert, dass auch Leser, die nicht technisch versiert sind, die Zusammenhänge verstehen können. Auf diese Weise hoffen wir, Unsicherheiten im Zusammenhang mit In- Memory-Computing und Big Data im Allgemeinen und SAP HANA im Besonderen weitgehend ausräumen zu können.

1.1 Einführung in das In-Memory-Computing und Big Data

Um das wahre Potenzial von SAP HANA zu erkennen, müssen Sie jedoch erst das Konzept von SAP HANA als Technologie verstehen – als eine In- Memory-Datenbank. In-Memory-Computing und Big Data sind Begriffe, die derzeit und insbesondere im Zusammenhang mit SAP HANA häufig verwen- det werden. Bevor wir SAP HANA als Lösung genauer beschreiben, ist das richtige Verständnis dieser beiden Begriffe wichtig. Aus diesem Grund wer- den diese im folgenden Abschnitt näher erläutert.

1.1.1 In-Memory-Computing und Analysen

In einem dynamischen und anspruchsvollen Umfeld wie dem heutigen sind führende Unternehmen immer häufiger gefordert, Entscheidungen in Echt- zeit zu treffen. Diese Erwartungshaltung setzt IT-Abteilungen und deren Ver- antwortliche immer stärker unter Druck, neue und schnellere Möglichkeiten zu finden, den Entscheidungsträgern aktuelle Informationen und Erkennt- nisse bereitstellen zu können. Einfach nur darauf zu warten, dass Daten ein komplexes Datenmodell und Data Warehouse durchlaufen, bis sie schließ- lich in ihren Berichten auftauchen, reicht den Entscheidungsträgern schon längst nicht mehr aus. Selbst wenn der Bericht in zehn Sekunden erstellt ist, konnte es früher acht bis zehn Tage dauern, bis die Daten ins System gelang-

Einführung in das In-Memory-Computing und Big Data

1.1

ten! Business-Anwender fordern aber volle Transparenz darüber, was jetzt geschieht, und möchten nahezu in Echtzeit darauf reagieren können. Sie müssen in der Lage sein, auf aktuelle Geschehnisse und Marktveränderun- gen direkt reagieren zu können – und nicht erst zwei Wochen später.

Stellen Sie sich folgendes Szenario vor: Ein Einzelhändler beobachtet das Echtzeitverhalten eines Kunden im Laden oder auf einer Webseite. Er zieht historische Daten über das Kundenverhalten aus dem Kundenbindungssys- tem hinzu, kombiniert diese Informationen mit den »Gefällt mir«-Angaben bei Facebook oder anderen sozialen Netzwerken und sendet dann Gut- scheine oder Coupons direkt auf das Mobiltelefon des Kunden – für Pro- dukte, die er sich gerade im Regal oder auf dem Bildschirm ansieht. Die Ver- wirklichung dieses Szenarios ist ein lange gehegter Traum. Um ihn zu verwirklichen, müssen nicht nur Ereignisse in Echtzeit analysiert werden, sondern auch riesige Datenmengen. Mithilfe von In-Memory-Computing könnte dies bald Wirklichkeit werden: Indem Daten von einer Festplatte in den Hauptspeicher verschoben werden, können sie im Handumdrehen bereitgestellt werden. Die Leistung wird hierdurch erheblich gesteigert und das Szenario ermöglicht.

Die Idee, Datenbanken im Hauptspeicher auszuführen, ist nicht neu – es ist eine der Grundlagen des Business-Intelligence-Produkts (BI) QlikView aus dem Jahr 1997. Da seitdem die In-Memory-Technologie weiterentwickelt wurde und die Preise für Hauptspeicher stark gesunken sind, ist das In- Memory-Computing inzwischen für viele Unternehmen eine realistische Option. Diese Entwicklung hat die Türen für andere Softwareunternehmen, z.B. SAP, geöffnet, die die Situation nutzen möchten, um neue und schnel- lere Lösungen für ihre Kunden zu schaffen.

In-Memory-Computing basiert darauf, dass riesige Datenmengen im Haupt- speicher verarbeitet und Analyse- und Transaktionsergebnisse direkt bereit- gestellt werden. SAP bezeichnet dies als Massive Parallel Processing (MPP). Idealerweise werden die zu verarbeitenden Daten in Echtzeit oder Beinahe- Echtzeit generiert. Um dieses Leistungsniveau zu erreichen, folgt das In- Memory-Computing einem simplen Grundsatz: Der Datenzugriff wird beschleunigt, und Datenbewegungen werden minimiert. Der Hauptspeicher (RAM) ist der schnellste Speichertyp, der eine große Datenmenge aufneh- men kann. (Auf CPU-Verzeichnisse und CPU-Zwischenspeicher kann zwar noch schneller zugegriffen werden, jedoch findet hier nur eigentliche Verar- beitung der Daten statt.) Auf Daten im Hauptspeicher (RAM) kann 100.000- mal schneller zugegriffen werden als auf Daten auf einer Festplatte. Durch

1

In-Memory-Computing, Big Data und SAP HANA

die Nutzung der In-Memory-Funktion kann so die Leistung erheblich verbes- sert werden, da die Daten schneller für die Berichts- und Analyselösungen oder andere Anwendungen zur Verfügung gestellt werden.

Wenngleich das Thema In-Memory-Computing noch viel ausführlicher beschrieben werden könnte (es wurden zahlreiche Bücher hierzu verfasst!), möchten wir uns an dieser Stelle auf diese einfache Ausführung beschrän- ken. Allerdings möchten wir noch eine Frage klären, die oftmals im Zusam- menhang mit In-Memory-Computing gestellt wird: Was geschieht mit den Daten bei einem Stromausfall?

Vergleichen Sie diese Situation mit einem Microsoft-Word-Dokument, für das Sie noch nicht auf Speichern geklickt haben. Geht Ihre Arbeit verloren, wenn Ihr Computer abstürzt, bevor Sie auf Speichern klicken und das Doku- ment auf der Festplatte ablegen? Schließlich befindet sich das Dokument im Hauptspeicher des Computers und nicht auf der Festplatte, bis Sie auf Spei- chern klicken. Wenn Sie noch nicht auf Speichern geklickt haben und der Computer abstürzt, erhalten Sie daher möglicherweise eine Wiederherstel- lungsdatei. Es ist aber auch möglich, dass Sie das Dokument ganz neu erstel- len müssen. Dieses Problem tritt glücklicherweise bei In-Memory-Datenban- ken nicht auf. Wie aber handhaben In-Memory-Lösungen dieses Thema?

Dies führt uns zum AKID-Prinzip (Atomarität, Konsistenz, Isoliertheit und Dauerhaftigkeit; engl. ACID), das die gewünschten Eigenschaften der Verar- beitung von Daten in einer Datenbank beschreibt:

Eine Transaktion muss atomar sein, d.h., wenn ein Teil einer Transaktion fehlschlägt, schlägt die gesamte Transaktion fehl und der Status der Daten- bank bleibt unverändert.

Die Konsistenz (engl. consistency) einer Datenbank muss gewährleistet wer- den. Mit anderen Worten, es werden nur gültige Daten in der Datenbank abgelegt. Wenn aus irgendeinem Grund eine Transaktion ausgeführt wird, die die Konsistenzregeln der Datenbank verletzt, wird die gesamte Trans- aktion rückgängig gemacht, und die Datenbank wird in einem Status wie- derhergestellt, der den Regeln entspricht. Wenn allerdings eine Trans- aktion erfolgreich ausgeführt wird, wird die Datenbank von einem konsistenten Status in einen anderen Status versetzt, der ebenfalls mit den Regeln konsistent ist.

Eine Transaktion muss isoliert werden, damit keine Störungen zwischen Transaktionen auftreten können.

Einführung in das In-Memory-Computing und Big Data

1.1

Schließlich muss eine Transaktion dauerhaft sein, d.h., wenn eine Trans- aktion an die Datenbank übergeben wurde, verbleibt sie auch dort.

Die ersten drei Anforderungen stellen für die In-Memory-Technologie kein Hindernis dar. Die Dauerhaftigkeit jedoch kann nicht gewährleistet werden, wenn die Daten nur im Hauptspeicher abgelegt werden, da der Hauptspei- cher flüchtig ist, was bedeutet, dass Inhalte bei einem Stromausfall verloren gehen. Um persistente Daten zu erhalten, müssen diese in einem nichtflüch- tigen Speicher, also z.B. auf Festplatten, abgelegt werden. Um dies näher erläutern zu können, müssen wir uns nun ein wenig mit den technischen Details beschäftigen.

Das Medium, das von der Datenbank zum Speichern verwendet wird (in die- sem Fall der Hauptspeicher), ist in Seiten unterteilt. Werden Daten durch eine Transaktion geändert, werden die entsprechenden Seiten markiert und regelmäßig in den nichtflüchtigen Speicher geschrieben (eine Festplatte mit unabhängiger Stromversorgung). Zusätzlich werden im Datenbankprotokoll sämtliche Änderungen festgehalten, die von den Transaktionen vorgenom- men werden. Durch jede ausgeführte Transaktion wird ein Protokolleintrag erzeugt, der in den nichtflüchtigen Speicher geschrieben wird. So wird sichergestellt, dass alle Transaktionen dauerhaft sind.

In-Memory-Datenbanken können geänderte Seiten an Savepoints (siehe Abbildung 1.1) speichern, die in regelmäßigen Abständen (bei SAP HANA standardmäßig im 5-Minuten-Takt) asynchron in den persistenten Speicher geschrieben werden. Dieses Protokoll wird synchron geschrieben. Anders ausgedrückt: Damit die zuvor beschriebene Anforderung der Dauerhaftigkeit erfüllt wird und die In-Memory-Datenbanken den AKID-Test bestehen, wird eine Transaktion erst dann zurückgeführt, wenn der entsprechende Proto- kolleintrag in den persistenten Speicher geschrieben wurde.

Daten-Savepoint Protokolleintrag in persistenten Speicher (ausgeführte Transaktion) Stromausfall in persistenten
Daten-Savepoint
Protokolleintrag in
persistenten Speicher
(ausgeführte
Transaktion)
Stromausfall
in persistenten
Speicher

Zeit

Abbildung 1.1 Savepoints und Protokolle

1

In-Memory-Computing, Big Data und SAP HANA

Nach einem Stromausfall kann die Datenbank neu gestartet werden, und die Datenbankseiten werden über die Savepoints wiederhergestellt. Die Daten- bankprotokolle werden eingesetzt, um die Änderungen wiederherzustellen, die nicht in den Savepoints erfasst wurden. So wird sichergestellt, dass die Datenbank im Hauptspeicher mit genau dem Status wiederhergestellt wird, den sie vor dem Stromausfall hatte.

Wenn Sie also Ihre Stromrechnung nicht bezahlt haben und der Strom für Ihre In-Memory-Datenbankhardware abgestellt wird, müssen Sie nicht in Panik geraten. Vielmehr können Sie darauf vertrauen, dass Ihre SAP-HANA- Implementierung die wichtigste operative Anforderung erfüllt: Disaster Recovery – die Fähigkeit eines Systems, sich nach einem Katastrophenfall, wie einem Strom- oder Systemausfall mit erforderlichem Systemstopp, selbst wiederherzustellen. Disaster Recovery ist mit Abstand der wichtigste Aspekt für Kunden, bevor diese SAP HANA akzeptieren und übernehmen. Wenn Sie in Ihrem Unternehmen ein Pilotprogramm zur Einführung von SAP HANA durchführen möchten, sollten Sie daher auf diesen Aspekt großen Wert legen, um das Vertrauen des operativen Teams zu gewinnen. Unternehmen möchten die Kontrolle über ihr SAP-HANA-Testsystem haben (da ein Test im Produktivsystem für sie nicht infrage kommt) und im wahrsten Sinne des Wortes den Stecker ziehen können. So können sie selbst überprüfen, welche Sicherungssysteme aktiviert werden, wie lange das System ausfällt und wel- che operativen Auswirkungen insgesamt zu erwarten sind.

Disaster Recovery ist ein entscheidender Faktor, wenn Sie SAP HANA für Ihre Transaktionssysteme einsetzen möchten. Gerade für Kunden, die darü- ber nachdenken, die Suite auf SAP HANA zu verwenden, ist Disaster Reco- very ein äußerst wichtiger Aspekt. Denn wenn Sie SAP Business Warehouse (BW) auf SAP HANA nutzen und ein Systemausfall stattfindet, können Sie die Lösung erneut laden, und der Bericht wird mit einer leichten Verzögerung erstellt – alles in allem ist dies also kein Weltuntergang. Wenn Sie allerdings Ihre Kundenauftragsabwicklung über SAP HANA verwalten und das System ausfällt, können keine Buchungen, Abrechnungen oder Versandaufträge vor- genommen werden, was Sie vor ein weitaus größeres Problem stellt.

Hinweis

Möglicherweise sind Sie nicht mit den unterschiedlichen, für SAP HANA verfügba- ren Optionen – SAP Business Suite auf SAP HANA, SAP BW auf SAP HANA usw. – vertraut. Diese werden in Abschnitt 1.3, »Einführung in die Implementierungsop- tionen«, vorgestellt und in Kapitel 2, »SAP-HANA-On-Premise-Implementierungs- optionen«, genauer erläutert.

Einführung in das In-Memory-Computing und Big Data

1.1

Um dieses Problem zu entschärfen, müssen Sie dafür sorgen, dass es gar nicht erst zum Problem wird. Definieren Sie daher in Zusammenarbeit mit den technischen und operativen Support-Teams aussagekräftige Erfolgskrite- rien für Ihre Pilotprogramme. So überzeugen Sie alle davon, dass geschäfts- kritische Transaktionssysteme auf eine SAP-HANA-Plattform übertragen werden können.

1.1.2 Big Data

In-Memory-Computing ist vor allem deshalb ein so großes Thema, weil sich die Art und Weise verändert, wie wir mit Informationen umgehen. Der Bedarf an Daten und Visualisierung für Unternehmen ändert sich fortlaufend und gewinnt in Zukunft immer mehr an Wert. Dabei verlieren Trendanaly- sen bzw. die historische Berichterstellung an Bedeutung, während die Daten- visualisierung und Reaktionsfähigkeit an Bedeutung zunehmen (siehe Abbil- dung 1.2).

Vor zwei Jahren

Heute

Historische Trendanalyse und Prognose

Datenvisualisierung

Historische Trendanalyse und Prognose Datenvisualisierung Standardisiertes Reporting Simulationen und

Standardisiertes Reporting

Simulationen und Szenarienentwicklung

Datenvisualisierung

Geschäftsprozessanalyse

Geschäftsprozessanalyse

Regressionsanalyse, diskrete Entscheidungs- modelle und mathematische Optimierung

Simulationen und Szenarienentwicklung

Historische Trendanalyse und Prognose

Clustering und Segmentierung

Clustering und Segmentierung

Regressionsanalyse, diskrete Entscheidungs- modelle und mathematische Optimierung

Standardisiertes Reporting

Legende:

erhöhter oder nachhaltiger Wert

verminderter Wert

Abbildung 1.2 Entwicklung des Informationsbedarfs

Die Zeiten ändern sich zusehends, und folglich sind Unternehmen auf der Suche nach Alternativen für ihre Daten, Informationen und Analyseanforde- rungen. Welche Anforderungen stellen die Benutzer, die noch nicht mit den aktuell verfügbaren und verwendeten Werkzeugen und Technologien abge- deckt werden? Die Antworten der IT-Mitarbeiter auf diese Frage fallen natürlich unterschiedlich aus. Wenn Sie aber die Benutzer der Systeme – aus der Geschäftsperspektive – fragen, erhalten Sie möglicherweise diese Ant-

1

In-Memory-Computing, Big Data und SAP HANA

wort: »Wir haben von riesigen Datenmengen gehört, die einsatzbereit in den ERP-Systemen bereitstehen, auf die wir aber nicht zugreifen können.« Wenn Sie nach den Gründen hierfür fragen, erhalten Sie vermutlich die folgenden Antworten:

»Der Abruf ist zu kompliziert.«

»Der Ladevorgang in das Data Warehouse dauert zu lange.«

»Mir wurde gesagt, dass ein Data Warehouse für aggregierte Daten ver- wendet wird.«

»Wir haben nicht ausreichend Platz im Data Warehouse.«

»Die Berichte können nicht so viele Daten verarbeiten.«

»Ich weiß nicht, was ich abrufen soll, und die Systeme geben nicht einfach ›alles‹ aus.«

Sie werden merken, dass die Anforderungen Ihrer Benutzer und des Unter- nehmens an Informationen und deren Verfügbarkeit zunehmen, je mehr diese mit den technologischen Möglichkeiten vertraut sind (siehe Abbil- dung 1.3).

Prognose und Steuerung des Marktverhaltens Personalplanung und -zuteilung zur Bedarfsdeckung Wert auf positive
Prognose und Steuerung des Marktverhaltens
Personalplanung und -zuteilung zur Bedarfsdeckung
Wert auf positive Kundenerfahrungen legen
Risikomanagement
Priorisierung der Produktforschung und -entwicklung
Konzentration auf Kundenservice
Strategie- und Geschäftsentwicklung
Historische Trendberichterstellung
Monitoring-Tag – Betrieb und Produktion
Finanzmanagement und Analyse der Tabellenk.
Progression der

Läufer (21 %)

Besitzt die meiste Erfahrung und arbeitet sehr erfolgreich mit Analysewerkzeugen

Strebt nach gezielter Umsatzsteigerung

Will unbedingt noch mehr mit Analysewerkzeugen erreichen

Schnellgeher (46 %)

Strebt nach Umsatzsteigerung bei gleichzeitiger Kosteneffizienz

Will Fähigkeiten zur Informations- und Wissensweitergabe erweitern

Geher (33 %)

Verwendet Analysewerkzeuge zwecks Kostensenkung

Verwendet Analysewerkzeuge nur, wenn wirklich notwendig

Fähigkeiten

Abbildung 1.3 Steigender Bedarf an Analyselösungen

Einführung in das In-Memory-Computing und Big Data

1.1

Um den steigenden Anforderungen gerecht zu werden und entsprechende Lösungen anbieten zu können, werden Sie schon bald enorme Datenmengen benötigen. Dieses Phänomen wird auch als Big Data bezeichnet. Der Begriff Big Data wird im Analysesektor mit unterschiedlicher Bedeutung verwendet. Im Wesentlichen bezieht er sich nicht nur auf die enormen – fast unvorstell- bar großen – Datenmengen, die heute verfügbar sind, sondern auch darauf, dass sich diese Daten fortlaufend ändern. Benutzer generieren täglich Daten mit Billionen von Bytes. Mehr als 95 % der weltweit verfügbaren Daten wur- den allein in den letzten fünf Jahren erzeugt, und eine Verlangsamung dieses Trends ist nicht in Sicht. Webseiten, soziale Medien, Kurznachrichten, Insta- gram, Fotos – die zur Verfügung stehenden Informationen sind schier unendlich. Es ist aber eine große Herausforderung für Sie, diese zu nutzen, ihren Sinn zu verstehen und sie zu Geld machen zu können.

Die Probleme, mit denen Unternehmen heute konfrontiert sind, betreffen weit mehr als nur Kundenaufträge und Finanzbuchungen. Unternehmen versuchen, Erkenntnisse über das Verhalten ihrer Kunden zu gewinnen, um im Wettbewerb mithalten zu können. Sie bemühen sich, das Verhalten der Konsumenten zu steuern. Sie möchten erfahren, was die Kunden wirklich über ihre Produkte denken: Was schreiben die Kunden in sozialen Netz- werken darüber? In welchen Läden sehen sie sich um und in welchen kau- fen sie ein?

Unternehmen sind daher auf der Suche nach einem einzigen Statistikwerk- zeug, das riesige, in Repositorys gespeicherte, Datenmengen (Big Data) durchkämmt, um neue Zusammenhänge, Muster, Beziehungen und Trends aufzudecken, indem es auf statistische und mathematische Techniken zurückgreift und Hunderte Variablen und Millionen von Beobachtungen ein- bezieht. Wertvolle Marktforschungsinformationen zu den gewünschten Pro- dukten sollen auf diese Weise innerhalb von Minuten statt erst in Tagen ver- fügbar sein, sodass Kosten und Zeitaufwand drastisch gesenkt werden können.

Außerdem möchten Unternehmen in der Lage sein, komplexe Prognosemo- delle intuitiv zu gestalten und so anhand vergangener und aktueller Ereig- nisse (Vertriebsdaten, soziale Netzwerke usw.) und anderer beeinflussender Variablen mögliche künftige Ereignisse vorherzusagen.

Auch wenn Big Data also auf den ersten Blick ein Problem anderer Abteilun- gen zu sein scheint – oder ein Problem der Größen- und Umfangsverwaltung von Informationen –, ist es tatsächlich die Grundlage für jedes Unterneh-

1

In-Memory-Computing, Big Data und SAP HANA

men, um das ultimative Ziel zu erreichen: Verhalten vorherzusagen und zu steuern, um die gewünschten Ziele zu erreichen.

Informationen und deren Analyse stehen bei der neuen Form der Erkennt- nisgewinnung im Fokus. Allerdings bekommen Unternehmen oftmals nicht die Informationen, die sie benötigen, oder sie vertrauen den Informa- tionen nicht, die sie bekommen. Betrachten Sie in diesem Zusammenhang Folgendes:

Führungskräfte treffen oft Entscheidungen aufgrund von Informationen, denen sie nicht vertrauen, oder ohne jede Informationsgrundlage.

Führungskräfte sagen, dass sie keinen Zugriff auf Informationen haben, die für ihre Aufgaben erforderlich sind.

Ein Großteil der CIOs nennen »Business Intelligence und Analysen« als Teil ihrer visionären Pläne zur Steigerung der Wettbewerbsfähigkeit.

CEOs sagen, dass sie Informationen schneller erfassen und verstehen müs- sen, um rasche Geschäftsentscheidungen treffen zu können.

Für Sie als Benutzer bedeutet dies, dass Sie alle Daten, die für Entscheidun- gen gebraucht werden, zu Analysezwecken in Repositorys integrieren müs- sen. Für Sie als IT-Mitarbeiter bedeutet dies, dass Sie Strategien zur Integra- tion und Speicherung großer Datenmengen sowie zur bedarfsorientierten Bereitstellung dieser Daten für die Benutzer entwickeln müssen. Ihre Vorge- hensweise muss sich ändern, da die bisherige Form der Erfassung, Samm- lung und Speicherung von Daten nicht mehr ausreichend ist. Sowohl struk- turierte als auch unstrukturierte Daten werden mit astronomischer Geschwindigkeit wachsen, und Sie müssen beide Datentypen berücksichti- gen. Dies ist eine einmalige Gelegenheit zur Erstellung und Bereitstellung von Berichts- und Analyselösungen, die diese riesigen Mengen an Daten in einer vertrauenswürdigen und sicheren Umgebung zusammenbringen und dem Unternehmen zugänglich machen.

Big Data stellt Sie vor fünf große Herausforderungen:

Datenmenge Wie können riesige Mengen sich rasch ändernder Daten aus unterschied- lichen Quellsystemen in einer heterogenen Umgebung bewältigt werden?

Datenumfang Wie wird der Umfang, die Tiefe und die Bedeutung von Daten ermittelt, die bei der Bereinigung, Konvertierung und Migration berücksichtigt wer- den sollen?

SAP HANA – Einführung

1.2

360-Grad-Ansicht Wie kann mithilfe der derzeit verfügbaren Informationen eine 360-Grad- Ansicht der Kunden erstellt werden, und wie können detaillierte Informa- tionen über die Kunden (z.B. personenbezogene Informationen, Hobbys, Ansprachemöglichkeiten und Kaufinteressen) sinnvoll genutzt werden?

Datenintegrität Wie werden die gewünschten Datenintegritätsstufen über mehrere Teams und Geschäftsprozesse hinweg ermittelt? Bedeutet Datenintegrität für das Unternehmen lediglich, dass die Daten vollständig sein müssen (Informa- tionen in allen Pflichtfeldern) oder dass die in diesen Feldern enthaltenen Informationen sowohl korrekt als auch logisch sein müssen?

Governance-Prozess Wie werden Vorgehensweisen über Personengruppen, Prozesse und Tech- nologien hinweg ermittelt, um die gewünschte Governance sicherzustel- len? Wer legt die Regeln fest? Wird eine zusätzliche Administrationsstufe hinzugefügt? Wird ein Golden Client für die Daten verwendet?

Jede dieser Fragen ist schwierig zu beantworten, da Sie in Echtzeit enorme Mengen an sich schnell ändernden Daten aus unzähligen Quellen in unter- schiedlichsten Formen zusammenführen und diese Daten anschließend ver- walten, sammeln und Ihrem Unternehmen zur Erkenntnisgewinnung zur Verfügung stellen möchten – ohne vorher zu wissen, welche Erkenntnisse überhaupt gewonnen werden sollen.

Sie haben gelernt, dass leistungsstarke Recheneinheiten benötigt werden, um mit riesigen Datenmengen (Big Data) umgehen zu können, und dass das In-Memory-Computing das nötige Potenzial dazu mitbringt. Genau an die- sem Punkt kommt SAP HANA ins Spiel.

1.2 SAP HANA – Einführung

In diesem Abschnitt stellen wir Ihnen SAP HANA als eine In-Memory- Lösung und als Wegbereiter für Big-Data-Lösungen vor. Anschließend erläu- tern wir einen der technischen Hauptgründe, weshalb SAP HANA riesige Datenmengen verwalten kann: die spaltenbasierte Speicherung. Abschlie- ßend erfahren Sie, welche Möglichkeiten dadurch für die Unternehmen ent- stehen und weshalb sich Unternehmen für SAP HANA entscheiden.

1

In-Memory-Computing, Big Data und SAP HANA

1.2.1 SAP HANA als In-Memory-Computing-Lösung

SAP arbeitet bereits seit einigen Jahren daran, das Potenzial von In-Memory- Computing für die konzerneigenen Lösungen zu nutzen. Eine der bisher bekanntesten Lösungen in diesem Bereich ist die Such- und Klassifizierungs- maschine namens TREX. Als eigenständige Suchmaschine ist TREX ein wich- tiger Bestandteil unterschiedlicher SAP-Softwarelösungen, z.B. von SAP Enterprise Search. TREX speichert Daten nicht wie herkömmliche oder klas- sische Datenbanken, sondern als flache Dateien in einem Dateisystem. Obwohl TREX das Potenzial von In-Memory-Computing noch nicht voll aus- nutzt, war es dennoch der erste Vorstoß von SAP in diese Richtung.

Der nächste Schritt in Richtung In-Memory-Computing war die Entwicklung von SAP liveCache. Die SAP-liveCache-Technologie lässt sich als eine hybride Hauptspeicherdatenbank beschreiben. Sie basiert auf MaxDB, einer relatio- nalen SAP-Datenbank, in der In-Memory-Datenspeicher mit spezifischen objektorientierten Datenbanktechnologien zur Unterstützung von Anwen- dungsfunktionen kombiniert wurden. Dieses liveCache-Datenbanksystem kann sehr große Mengen an Informationen schnell verarbeiten. Es beschleu- nigt komplexe, datenintensive und zeitaufwendige Funktionen verschiede- ner SAP-Anwendungen erheblich, insbesondere innerhalb von SAP Supply Chain Management (SCM) und SAP Advanced Planner and Optimizer (APO).

Diese ersten Erfahrungen und Erfolge mit der In-Memory-Technologie nutzte SAP, um die Bedienbarkeit und Reaktionsfähigkeit der SAP-Lösungen und Anwendungen zu verbessern. Der nächste Schritt bestand in einer App- liance-basierten Lösung, die gezielt auf die Verbesserung der Berichts- und Analyseoptionen der SAP-BW-Installationsbasis ausgerichtet war, dem 2006 von SAP eingeführten SAP BW Accelerator (BWA). Der BWA basiert auf der TREX-Technologie und ist eine Erweiterung dieser bestehenden (und bewährten) Technologie. Er unterstützt die Abfrage großer Mengen an BW- Daten zu Analysezwecken. Mithilfe einer Kombination aus Hardware und Software werden gekennzeichnete Daten in den BWA verschoben und dort anders als in der SAP-BW-Hauptdatenbank organisiert und indiziert. Anschließend werden die Daten zur Auswertung über die Query Engine in die SAP-BW-Berichterstellungswerkzeuge integriert.

Der BWA dient ausschließlich zur Beschleunigung der in SAP BW geschrie- benen Abfragen und Berichte. Kurz gesagt, nachdem Sie einen BWA, der besondere Hardware, eine physische Installation und eine Verbindung zum SAP-BW-System benötigt, angeschlossen haben, kennzeichnen Sie die Info-

SAP HANA – Einführung

1.2

Provider, die über diesen BWA »beschleunigt« werden sollen. Bei Abfragen, die Daten aus diesen InfoProvidern benötigen, sucht die Query Engine zuerst im BWA nach den Daten. Wenn die Daten nicht im BWA gefunden werden, greift die Query Engine zum Abruf der Daten auf die herkömmliche (und langsamere) Datenbank zurück. Sind die Daten jedoch im BWA verfüg- bar, werden diese beinahe umgehend der Query Engine zur Verfügung gestellt. Wenn die Daten dagegen aus der herkömmlichen Datenbank abge- rufen werden müssen, kann dies eine Weile dauern.

Hinweis

Weitere Informationen über den BWA finden Sie in Abschnitt 5.3, »Mit bestehen- den Lösungen arbeiten: SAP HANA versus SAP BWA«.

Der nächste Schritt in diesem evolutionären Prozess ist die SAP-HANA-Da- tenbank, eine vollständige In-Memory-Lösung, die aufgrund der Fortschritte der Hardwaretechnologie, Reduzierung der Speicherkosten und Erweiterung der Kapazität möglich ist. SAP hat SAP HANA optimiert, um Vorteile aus die- sen technologischen Fortschritten zu ziehen, und stellt Ihnen diese Option für Ihre Informations- und Datenanforderungen zur Verfügung.

SAP HANA ist ein flexibles, von Datenquellen unabhängiges Werkzeug, d.h., die Herkunft der Daten ist für diese Lösung nebensächlich. Mit diesem Werkzeug können Sie enorme Mengen an Daten in Echtzeit speichern und bearbeiten, ohne äußerst komplexe physische Datenmodelle aggregieren oder erstellen zu müssen. Die SAP-HANA-In-Memory-Datenbanklösung ist eine Kombination aus Hardware und Software, die zeilen-, spalten- und objektbasierte Datenbanktechnologien miteinander kombiniert und so die Funktionen der parallelen Verarbeitung nutzt.

Obwohl die Hardware- und Speicheroptionen von heute die Speicherung rie- siger Datenmengen ermöglichen, müssen Sie trotzdem überlegen, wie Sie die Gesamtgröße der Datenbank komprimieren können – selbst wenn es sich um eine In-Memory-Datenbank handelt. Diese Komprimierung ist neben dem attraktiven Preis einer der wichtigsten Erfolgsfaktoren von SAP HANA. Die verschiedenen Preismodelle für SAP HANA reichen von einer auf Daten- volumen basierten Lizenzgebühr bis hin zu einer Flatrate-Lizenz, mit der Sie SAP HANA uneingeschränkt nutzen können. Wenn Sie über eine SAP- HANA-Version auf Datenvolumenbasis nachdenken, sollten Sie Ihre Kom- pressionsmöglichkeiten sorgfältig prüfen.

1

In-Memory-Computing, Big Data und SAP HANA

In der In-Memory-Computing-Engine (IMCE) von SAP HANA verwalten viele verschiedene Komponenten den Datenzugriff und die Datenspeiche- rung (siehe Abbildung 1.4). Der Plattenspeicher ist üblicherweise ein Datei- system, das die Datensicherung und Protokollierung von Aktivitäten ermög- licht und in der Persistenzschicht verwaltet wird. Außerdem gibt es eine relationale Engine, in der die zeilen- und spaltenbasierte Speicherung ver- waltet wird. Ob Ihre Implementierung einen zeilen- oder spaltenbasierten Speicher verwenden wird, ist sowohl von dem Inhalt, den Sie implementie- ren werden, als auch von dem System abhängig, das Sie auf SAP HANA ver- wenden möchten (d.h. entweder SAP BW oder SAP Business Suite). Alle Sys- teme werden eine Kombination aus zeilen- und spaltenbasierten Speichern verwenden. Wenn Sie jedoch Ihren eigenen Datensatz mithilfe von Werk- zeugen wie z.B. SAP Data Services (ETL-basierte Replikation) erstellen, ste- hen Ihnen beide Optionen als Implementierungsmethode zur Verfügung.

Metadaten- Autorisierungs- Transaktions- manager Manager Manager Plattenspeicher Persistenz- schicht SQLScript
Metadaten-
Autorisierungs-
Transaktions-
manager
Manager
Manager
Plattenspeicher
Persistenz-
schicht
SQLScript
SQL-Parser
Relationale Engine
Daten-
Seiten-
volumen
verwaltung
Zeilenspeicher
Spaltenspeicher
Kalkulations-
MDX
Log-
Engine
Logger
Volumes
Load
Replication Server
Controller

Session

Manager

Abbildung 1.4 Die In-Memory-Computing-Engine von SAP HANA

Es stehen verschiedene Werkzeuge zum Verschieben von Daten innerhalb von SAP HANA zur Verfügung. Sie können beispielsweise durch den Einsatz des Sybase Replication Servers und Load Controllers (LC) eine logbasierte Replikation durchführen oder auch die triggerbasierte Datenreplikation der SAP Landscape Transformation (SLT) bzw. SAP Data Services für die her- kömmlich terminierte Datenbewegung einsetzen. Wir werden in Kapitel 12, »Datenbereitstellung«, näher auf jede einzelne dieser Optionen eingehen.

Für den Zugriff auf Daten in Frontend-Werkzeugen bietet SAP HANA einen Support für SQLScript und Multidimensional Expressions (MDX) sowie einen SQL-Parser. Zusätzlich steht eine äußerst schnelle Kalkulations-Engine für In-Memory-Kalkulationen zur Verfügung. In Kapitel 7 werden die Optio- nen für den Zugriff auf das SAP-HANA-System über Business-Intelligence- und Berichtswerkzeuge erläutert.

SAP HANA – Einführung

1.2

Intern verwaltet SAP HANA zudem die Sicherheit, Transaktionen und Meta- daten (das sind Daten über die Daten) in drei IMCE-Komponenten, die mit dem Session Manager zusammenarbeiten. Dieser wiederum überwacht, wer auf das System zugreift und wie die Ergebnismenge und Dialoge verwaltet werden. Im Allgemeinen handelt es sich bei der IMCE um eine komplexe, interne SAP-HANA-Komponente, die als Bundle zusammen mit anderen Anwendungen einfach gestaltet ist, um Installationen und Verwaltung zu erleichtern.

1.2.2 SAP HANA und Big Data als Wegbereiter für Big-Data-Lösungen

Big Data ist kein Phänomen, das sich mit der Zeit erledigen wird. Glückli- cherweise werden mit SAP HANA nicht nur Daten verarbeitet, sondern Sie können auch Anwendungen und Prozesse aufbauen bzw. optimieren, um diese Daten auf völlig neue Art und Weise für sich zu nutzen.

In Abschnitt 1.1.2 wurden die mit Big Data einhergehenden Probleme vor- gestellt. Betrachten wir nun, wie Sie mit einer SAP-HANA-fähigen Lösung diese Probleme effektiv angehen können:

Datenmenge Das gesamte SAP-HANA-Umfeld basiert auf der Fähigkeit, MPP (Massive Parallel Processing) durchführen zu können. SAP-HANA-Systeme (mit bis zu 100 TB) stehen in Versuchsumgebungen zur Verfügung, um zu demonstrieren, dass SAP HANA diese Unmengen an Daten verarbeiten kann. Zur Erinnerung: In SAP HANA werden alle Daten im Hauptspeicher und nicht auf Festplatten abgelegt – wir sprechen hier also von riesigen Mengen.

Datenumfang In SAP HANA können umfangreiche Datenmengen gespeichert werden, sodass jegliche Arten von Informationen abgerufen werden können. Aller- dings müssen Sie hierzu festlegen, welche Informationen aus der beinahe grenzenlosen Fülle an Optionen in SAP HANA integriert und wie diese In- formationen verwendet werden sollen. SAP HANA kann riesige Mengen an Daten speichern, was aber nicht unbedingt bedeutet, dass Sie solche großen Mengen an Informationen im System bereitstellen sollten, wenn diese nicht für Ihre Anforderungen relevant oder anwendbar sind.

1

In-Memory-Computing, Big Data und SAP HANA

360-Grad-Ansicht Die 360-Grad-Ansicht der Kunden – die vollständigste und umfangreichste Sicht auf die Kunden – ist einer der wichtigsten Aspekte für Unternehmen, damit sie deren Kaufverhalten und -motivation verstehen können und Werbeaktionen effektiv und sinnvoll einsetzen. Bisher war eine Analyse dieser großen Datenmengen nahezu unmöglich. Mit SAP HANA eröffnen sich jedoch neue Möglichkeiten.

Datenintegrität Wenn Sie den Führungskräften Ihres Unternehmens SAP HANA als Option präsentieren, um Erkenntnisse und Transparenz über die großen Datenmengen zu erhalten und Entscheidungen über Geschäftsaktivitäten in Echtzeit treffen zu können, sollten Ihre Daten unbedingt vertrauens- würdig sein. Unabhängig davon, ob die Ergebnisse gut oder schlecht sind, Datenintegrität bedeutet, dass die Ergebnisse wiederholbar und die Daten nachvollziehbar sind. Mit SAP HANA können Sie enorme Datenmengen in eine einzige Umgebung laden und auf diese Weise eine Reihe von Daten- migrationen, Transformationen und Extrahierungen über mehrere Umge- bungen hinweg (potenziell) eliminieren, sodass Sie den Daten noch stär- ker vertrauen können.

Data Governance Bevor Sie sicherstellen können, dass Daten und Systeme vertrauenswürdig bleiben, müssen Sie zunächst dafür sorgen, dass vertrauenswürdige Daten vorhanden sind. Dieser Prozess gilt für Daten und das System insgesamt, und er gewährleistet, dass es eine übergreifende Governance der wichtigs- ten Systempunkte, Maßnahmen und Messgrößen gibt, auf die die Füh- rungskräfte vertrauen. SAP HANA befasst sich nicht direkt mit Govern- ance, da Governance ein Prozess und Thema im Geschäftsablauf ist. Da Sie Daten und Informationen jedoch (nahezu) umgehend sichtbar machen können, kann SAP HANA Probleme schnell identifizieren.

SAP HANA eignet sich hervorragend für Big-Data-Probleme – oder besser ge- sagt für die Analysen, die riesige Datenmengen benötigen. Abbildung 1.5 zeigt einige Beispiele dafür, wie SAP HANA Analysen aus großen Datenmen- gen bereitstellen kann. Den ersten Anwendern von SAP HANA standen Ver- kaufsinformationen, Rezepte, Banktransaktionen, Kreditkartenaktivitäten, GPS-Tags und Messgrößen von Tausenden von Lkws oder Zügen zur Ver- fügung.

SAP HANA – Einführung

1.2

F&E

 

Kommerziell

 

Clinical

 
Clinical     Marketing  
 

Marketing

Clinical     Marketing  
 
   

Performance

 

Effectiveness

Dashboards

Management

 

Clinical Trial

 

Sample

Field

Scorecards

Management

System

Clinical

CRM

Effectiveness

 

Dashboards

     

Electronic

 

Contract

Reporting and

Analysis

Data Capture

Analytics

Sales Reporting

 

Contracts

Expense

 

and Analytics

Planning and

Management

   

Manufacturing

 

Forecasting

 

Finance

Capital
Capital
HR
HR
Projects
Projects
Strategic Finance
Strategic
Finance
Contracts
Contracts
Rebates
Rebates
ERP
ERP
Finance Capital HR Projects Strategic Finance Contracts Rebates ERP Powered by SAP HANA

Powered by SAP HANA

Abbildung 1.5 Beispiele dafür, was SAP HANA für Big Data bereitstellen kann

Hierbei handelt es sich um Dateneingaben aus zusammengeführten SAP- und Nicht-SAP-Systemen. Einige praktische Einsatzbereiche, die riesige Datenmengen (Big Data) aus zahlreichen Quellen benötigen, sind folgende:

Bewertung des Verkaufserfolgs Ein Lebensmittelhersteller möchte den Erfolg von Präsentationen im Ge- schäft und in Werbeflyern zu verschiedenen Verkaufsaktionen in Echtzeit bewerten, um die Lager schnellstmöglich wieder auffüllen zu können. Hierzu müssen folgende Daten und Informationen gesammelt werden:

Verkaufsdaten aus dem Supermarkt; historische Verkaufsinformationen zum Vergleich verschiedener Verkaufszeiträume, um zu ermitteln, ob der Verkauf während der Präsentationen und Flyeraktion über dem Standard- wert liegt; Bestell- und Lieferinformationen zum besseren Verständnis des Kaufverhaltens; aktuelle Bestellungen und deren voraussichtliche Liefer- termine sowie Logistikinformationen, um zu ermitteln, wie schnell die La- ger durch den Lebensmittelhersteller wieder aufgefüllt werden können. Zusätzlich könnte das Unternehmen noch die Wetterinformationen hinzu- fügen und so feststellen, ob das Wetter die Verkäufe beeinflusst (z.B. hohe Temperaturen in der Aktionsregion, Ausgabe von Proben und Coupons

1

In-Memory-Computing, Big Data und SAP HANA

für Eis) und wie sich diese Außenfaktoren auf die Verkaufsbemühungen auswirken.

Bewertung der Leistung Der Erfolg eines Transportunternehmens hängt von den zurückgelegten Kilometern und pünktlichen Lieferungen ab. Um die tägliche Leistung bewerten zu können, sammelt das Unternehmen für eine Echtzeitanalyse im 5-Minuten-Takt 40 Messwerte für alle 15.000 Container. Diese Analyse soll dem Unternehmen anzeigen, wie es Plan- und Sollwerte erfüllt und welche Routen angepasst werden müssen. Hierzu werden Vertragsinfor- mationen benötigt, um die Anforderungen bezüglich Lieferrouten und -daten sowie Strafen bei ausbleibenden oder verspäteten Lieferungen zu definieren. Zudem benötigt das Unternehmen Verkehrsinformationen, Wetterberichte, Benzinpreise und die 600.000 Messwerte, die alle fünf Minuten ermittelt werden. All dies muss in einer Analyse gesammelt und präsentiert werden, die alle fünf Minuten aktualisiert wird, damit die Füh- rungsebene erforderliche Änderungen festlegen kann. Es könnten hierbei auch Informationen zu Service- und Reparaturanlagen entlang der Routen integriert werden, um zeitnah auf Reifenpannen oder Motorprobleme rea- gieren zu können.

Dies sind zwei sehr unterschiedliche Beispiele für Analyseanforderungen, für die riesige Datenmengen erforderlich sind und für die der Einsatz von SAP HANA von Vorteil wäre. SAP HANA könnte diese Analyseanwendungen mithilfe von MPP und In-Memory-Funktionen aufbauen und so enorme Mengen an Daten aus mehreren Systemen in mehrere benutzerdefinierte BI- Anwendungen integrieren. Diese können dann für Echtzeitentscheidungen genutzt werden, die zeitnah umgesetzt werden können.

SAP HANA und Hadoop

Ein wichtiges Thema im Zusammenhang mit Big Data ist Hadoop. Je mehr die Kun- den mit SAP HANA vertraut werden, desto wichtiger wird auch das Thema Hadoop. Mithilfe von Hadoop werden große Mengen strukturierter und unstruk- turierter Daten eingebunden und konsolidiert, die anschließend nahtlos über SAP IQ, SAP Data Services oder R-Abfragen in SAP HANA zur Erstellung von Analyse- szenarien integriert werden. Zahlreiche Unternehmen verfügen bereits über Hadoop-Strategien oder -Lösungen und stellen sich die Frage, ob SAP HANA diese Strategien ergänzt oder diesen eher entgegenwirkt.

Hadoop wurde entwickelt, um der Anforderung nach Verarbeitung sehr großer Mengen sich ständig verändernder Daten wie z.B. Webdaten gerecht zu werden. Ganz einfach ausgedrückt ist Hadoop eine Integrationstechnologie für Big Data,

SAP HANA – Einführung

1.2

die diese Daten über Cluster verteilt. Die Daten werden anschließend zur Weiter- verarbeitung in Anwendungen weitergegeben. Im Oktober 2012 kündigte SAP mit der Bekanntgabe neuer Big-Data-Lösungen und -Partner für Hadoop die Integra- tion von Hadoop in die Data-Warehousing-Echtzeitfamilie an. Bei diesen Partner- schaften arbeitet SAP (HANA, SAP IQ, Data Integrator und BI) mit Hadoop, Clou- dera, Hitachi Data Systems, HP und IBM zusammen.

Durch die Bündelung von Geschwindigkeit, Skalierbarkeit, Flexibilität und Erschwinglichkeit möchte SAP seine Kunden in die Lage versetzen, Hadoop benut- zerdefiniert in bestehende BI- und Data-Warehousing-Umgebungen zu integrie- ren. Mithilfe von SAP Data Integrator können Unternehmen Daten aus Hadoop Distributed File Systems (HDFS) bzw. Hive-Datenbanken lesen und die relevanten Daten schnell in SAP HANA oder SAP IQ laden. So wird sichergestellt, dass SAP- BusinessObjects-BI-Anwender ihre bestehenden Berichts- und Analysewerkzeuge weiterhin nutzen können. Außerdem können Kunden ihre Abfragen über SAP-IQ- und Hadoop-Umgebungen hinweg bündeln oder alternativ MapReduce -Jobs in einer SAP-IQ-MPP-Umgebung über die integrierten Funktionen ausführen. Zudem können SAP-BusinessObjects-BI-Anwender Hive-Umgebungen abfragen, sodass Geschäftsanalysten Hadoop-Umgebungen direkt untersuchen können. Kurz gesagt: SAP ist auf der Suche nach einer koexistierenden Strategie für Hadoop.

1.2.3 Spaltenbasierte Speicherung versus zeilenbasierte Speicherung

In den letzten 30 Jahren wurden zahlreiche Algorithmen zum Aufbau von Indizes verwendet. B-Baum-Indizes dienen beispielsweise zur Strukturierung von Daten, damit deren Sortierung erhalten bleibt, und ermöglichen zudem Suchen, sequenzielle Zugriffe, Einfügungen und Löschungen. B-Baum-Indi- zes basierten ursprünglich auf physischen Tabellen mit bis zu sieben Knoten, wodurch diese einen großen Umfang erreichten und oft unbalanciert waren. In einem unbalancierten B-Baum-Index besitzt ein Knoten mehr Mitglieder als die anderen Knoten. Stellen Sie sich dies wie ein Telefonbuch vor. Zunächst gibt es in jedem Abschnitt eine ähnliche Anzahl an Einträgen, z.B. jeweils 500 Nachnamen mit dem Anfangsbuchstaben »J« bzw. »K«. In einem Index mit einem Knoten schlagen Sie die erste Seite des Telefonbuchs auf und sehen, dass die Namen mit »J« ab Seite 89 aufgelistet werden. Ab dieser Seite können Sie Ihre Suche nach »Jensen« beginnen. In einem statischen Telefonbuch wäre die Suche nach »Jensen« ebenso einfach wie die Suche nach »Koswalski«. Aber was passiert, wenn weitere 1.500 Koswalskis in Ihre Stadt ziehen? Nun gibt es 500 Einträge für »J« und 2.000 für »K«, und die Suche nach Jensen ist schneller als die nach Koswalski. Mit anderen Worten:

Der Index ist nun unbalanciert.

1

In-Memory-Computing, Big Data und SAP HANA

Natürlich können Sie dieses Problem lösen, indem Sie einen zweiten Knoten zum Index hinzufügen, damit diejenigen Koswalskis, deren Vornamen mit »A« bzw. »B« beginnen, auf unterschiedlichen Seiten aufgeführt werden. So werden fortlaufend Indexseiten zum Telefonbuch hinzugefügt. Auf diese Art und Weise wurde die erste Generation der Indizes geführt. (Tatsächlich sind sie etwas mathematischer, aber für das grundsätzliche Verständnis ist unsere Ausführung ausreichend.)

In den 1990er-Jahren wurden relationale Datenbankmanagementsysteme (RDBMS) weiterentwickelt, und es kamen neue Indizierungsmethoden hinzu. Bei der ersten neuen Methode wurden Zeiger anstelle von physischen Tabellen für Indizes erstellt. Diese konnten einfacher modifiziert und balan- ciert werden. Einige Anbieter wie z.B. Oracle erzeugten sogar Indizes, die sich selbst automatisch balancierten. Vor ungefähr 20 Jahren erfanden Wis- senschaftler neuere Bitmap-Indizes, die sich gänzlich von den B-Baum-Indi- zes unterschieden. Diese waren kleiner und folglich wesentlich schneller. In den letzten zehn Jahren wurden viele weitere Indexmethoden entwickelt:

Star-Joins, Hash, Ngram, invertiert, Opt/Eval und viele mehr. Sie unterschei- den sich darin, wie neue Sätze eingefügt bzw. wie Indizes zusammengeführt wurden. Ebenso variierten sie bei Komprimierungsmöglichkeiten, Fehlerto- leranz und der Gesamtgeschwindigkeit beim Datenabruf. Die stetig zuneh- mende Größe des Internets und die Millionen von Benutzern, die elektroni- sche Informationen suchen, treiben die Forschung und die Entwicklung in diesem Bereich weiter voran.

Aber in welchem Zusammenhang steht all dies mit SAP HANA? Eines der Merkmale, das SAP HANA von anderen Datenbanken unterscheidet, ist die Art und Weise, wie Daten indiziert werden: spaltenbasierte Organisation im Gegensatz zu zeilenbasierter Organisation. In relationalen Datenbanken wer- den Daten in Tabellen organisiert, die Datensätze enthalten. Der Unterschied zwischen zeilen- und spaltenbasierter Speicherung ist nun die Methode, mit der die Tabelle gespeichert wird (siehe Abbildung 1.6). Die Bezeichnungen deuten bereits an, dass Tabellen bei der zeilenbasierten Speicherung in einer Folge von Zeilen und bei der spaltenbasierten Speicherung in einer Folge von Spalten gespeichert werden.

Wie aus Tabelle 1.1 hervorgeht, haben beide Speicherungsmodelle Vor- und Nachteile.

SAP HANA – Einführung

1.2

zeilenbasiert Row ID Datum/Zeit Material Kundenname Menge 1 845 2 3 1 2 851 5
zeilenbasiert
Row ID
Datum/Zeit
Material
Kundenname
Menge
1 845
2 3
1
2
851
5 2
2
3
872
4
4 1
4
878
1
5 2
5
888
2 3
3
6
895
3
4 1
7
901
4
1 1

spaltenbasiert

Row ID Datum/Zeit Material Kundenname Menge 1 845 2 3 1 2 851 5 2
Row ID
Datum/Zeit
Material
Kundenname
Menge
1
845
2
3
1
2
851
5
2
2
3
872
4
4
1
4
878
1
5
2
5
888
2
3
3
6
895
3
4
1
7
901
4
1
1

Abbildung 1.6 Zeilenbasierte Speicherung im Vergleich zu spaltenbasierter Speicherung

 

Zeilenbasierte Speicherung

Spaltenbasierte Speicherung

Vorteile

Daten werden zusammenhän- gend gespeichert und können einfach eingefügt bzw. aktuali- siert werden.

Nur die relevanten Spalten werden beim Auswahlprozess gelesen, und jede Spalte kann als Index oder Schlüssel zum Datenabruf dienen.

Nachteile

Bei der Auswahl müssen alle Daten gelesen werden.

Datenaktualisierungen sind bei der spaltenbasierten Speicherung nicht so effizient wie bei der zeilenbasier- ten Speicherung.

Tabelle 1.1

Vor- und Nachteile der zeilen- bzw. spaltenbasierten Speicherung

Einer der Nachteile der zeilenbasierten Speicherung ist, dass alle Daten gele- sen werden müssen, unabhängig davon, welche Zeilen tatsächlich betroffen sind. Wenn Ihre Abfrage beispielsweise nicht nach dem Kundennamen fragt, wird dieses Feld dennoch beim Ausführen der Abfrage vom System gelesen.

1

In-Memory-Computing, Big Data und SAP HANA

Beachten Sie dabei, dass die Zeilendaten in einer SAP-BW-Datenbank, die scheinbar in einer einzigen Zeile enthalten sind, in Wirklichkeit auf mehrere Tabellen verteilt sind. Die Stammdaten sind im Allgemeinen von der Fakten- tabelle getrennt, sodass die Daten gemäß der Abfrage aufgebaut werden müssen und der gesamte Prozess langsamer wird. Durch Einsatz der spalten- basierten Speicherung wird dieses Problem in SAP HANA gelöst, und es wer- den nur die relevanten Spalten während des Auswahlprozesses gelesen.

Allerdings hat die spaltenbasierte Speicherung auch einen Nachteil. Bei der Aktualisierung eines Felds in einem zeilenbasierten Format (z.B. wenn ein Kunde einen blauen statt eines silbernen Pkw bestellt) wird vom System die Zeile ermittelt, und die Informationen werden aktualisiert. Bei einem spal- tenbasierten Format jedoch muss vom System zuerst die richtige Spalte und dann die richtige Zeile zur Aktualisierung gefunden werden. Der Schreibpro- zess ist daher weniger effizient.

Auch wenn diese Ineffizienz nur geringe Auswirkungen hat, möchten wir erläutern, wie SAP dieses Problem gelöst hat: In SAP HANA findet während der Updates keine Aktualisierung statt. Stattdessen fügt SAP HANA während des Updates die neue Zeile mit Informationen ein. Mit anderen Worten: Da der Schreibprozess zur Aktualisierung der Informationen in spaltenbasierten Datenbanken etwas langsamer ist, hat SAP diesen Prozess geändert. Es wird nicht aktualisiert, sondern eingefügt. Zudem sind für gewöhnlich nicht alle Spalten einer Zeile zur Verarbeitung erforderlich, insbesondere bei Analyse- abfragen. Normalerweise wird nicht jede einzelne Information bei jeder Reporting-Anforderung abgefragt (wenngleich einige Benutzer sämtliche Informationen zur Verfügung haben möchten und diese erst danach ausfil- tern). Durch den Einsatz dieser Spaltenstruktur für Daten und die Datenbank wird das Scannen unnötiger Daten beim Ausführen einer Abfrage reduziert oder sogar ganz eliminiert, wodurch der spaltenbasierte Prozess wesentlich schneller und effizienter ist als der herkömmliche zeilenbasierte Zugriff.

Die Grundidee der spaltenbasierten Indizes ist, dass sich Daten in den Tabel- len wiederholen und in Mustern vorkommen, die Sie durch die Indexerstel- lung und den Komprimierungsprozess reduzieren können. Betrachten Sie hierzu ein vereinfachtes Beispiel.

In Abbildung 1.7 gibt es einen Eintrag für Jane Hansen mit der Kundenklasse Gold, die in North Carolina (NC) lebt, 1959 geboren wurde und ein Einkom- men von $ 71.927 hat. Natürlich ist hier eine Datenkomprimierung möglich, aber der Datensatz lässt sich bei einer Indizierung nach Zeilen kaum noch reduzieren.

SAP HANA – Einführung

1.2

SAP HANA – Einführung 1.2 Abbildung 1.7 Datensatz nach Zeilen Wenn Sie aber diese Daten aus

Abbildung 1.7 Datensatz nach Zeilen

Wenn Sie aber diese Daten aus der Spaltenperspektive betrachten, erkennen Sie eine gewisse Datenredundanz (siehe Abbildung 1.8).

betrachten, erkennen Sie eine gewisse Datenredundanz (siehe Abbildung 1.8 ). Abbildung 1.8 Datensatz nach Spalten 47

Abbildung 1.8 Datensatz nach Spalten

1

In-Memory-Computing, Big Data und SAP HANA

Neben der Standardkomprimierung können Sie nun die Datenredundanz in den Spalten bereinigen. Beispielsweise gibt es in den Daten nur drei Werte für die Kundenklasse (Silver, Gold und Platinum) und zudem le- diglich sieben Bundesstaaten. Dies ermöglicht eine viel bessere Datenre- duzierung in den Indizes sowie Performancevorteile beim Zugriff auf die Daten.

Spaltenbasierte Speicher haben also die Vorteile einer hohen Komprimie- rungsrate, besserer Scanoperationen (einfachere Suche) und einer In-Cache- Client-Verarbeitung der Aggregation (einfachere Gruppierung und Aggrega- tion). Dadurch, dass der spaltenbasierte Index auch die Row ID enthält, kön- nen die Werte im Index weiterhin den anderen Feldern im Datensatz zuge- ordnet werden; SAP HANA bleibt also sozusagen »Besitzer« der Werte im Index.

Hinweis

Zum leichteren Verständnis vereinfachen diese Beispiele die internen SAP-HANA- Algorithmen für Indizes und Komprimierung sehr stark; in Wahrheit sind diese sehr komplex. Bei der Dictionary-Komprimierung beispielsweise werden von SAP HANA bitcodierte log 2 (N DICT )-Bits verwendet, und bei der Value-ID-Sequenzie- rung kommen in SAP HANA Präfixcodierung, Lauflängencodierung, Clustercodie- rung, Sparse-Codierung und indirekte Codierung zum Einsatz. Dies ist allerdings nur für Informatiker interessant.

Das Grundprinzip ist einfach: Spaltenbasierte Indizes werden oft aufgrund ihrer kleineren und schnelleren Indizes bevorzugt. Wichtig zu beachten ist hierbei, dass die SAP-HANA-Scanoperationen in einigen Fällen so schnell sind, dass die Indizes gar nicht benötigt werden und der Zugriff auf die Spal- tendaten direkt in den In-Memory-Scans möglich ist. In SAP HANA gibt es außerdem eine Text-Engine zur Indizierung von Text, die zudem Funktionen zur Fuzzy- und Phrasensuche beinhaltet.

Hinweis

Falls Sie an den internen Komprimierungsprozessen und Algorithmen von SAP HANA interessiert sind, verweisen wir Sie auf die detaillierten wissenschaftlichen Arbeiten zu diesem Thema von Hannes Rauhe von SAP Europa.

SAP HANA – Einführung

1.2

Tabelle 1.2 enthält eine Zusammenfassung der grundlegenden Unterschiede zwischen zeilen- und spaltenbasierten Speicherung.

Zeilenbasierter Speicher

Spaltenbasierter Speicher

Es handelt sich um eine relationale

 

Maschine zum Speichern von Daten im Rohformat.

Es handelt sich um einen reinen In- Memory-Speicher.

Er verfügt (in Zukunft) über einen In-Memory-Objektspeicher für liveCache-Funktionalität.

Die Lese- und Schreibfunktion werden erheblich verbessert.

Stark komprimierte Daten liegen im Arbeitsspeicher.

Es werden keine echten, sondern nur virtuelle Dateien verwendet.

Optimizer und Executer verarbeiten Abfragen und Ausführungspläne.

Der transaktionale Versionsspeicher

Er unterstützt Deltadaten für schnelle Schreibvorgänge.

Er verfügt über einen asynchronen Delta-Merge.

Er ermöglicht den Consistent View Manager.

bildet den Kern des zeilenbasierten Speichers.

Die Schreiboperationen finden hauptsächlich im transaktionalen Versionsspeicher statt.

INSERT schreibt ebenfalls in das persistierte Segment.

Der Hauptspeicher wird komprimiert und leseoptimiert; die Daten werden aus dem Hauptspeicher gelesen.

Der Deltaspeicher ist für Schreib- operationen schreiboptimiert.

Die sichtbare Version wird vom Speicher in das persistierte Segment verschoben.

Veraltete Datensatzversionen werden aus dem transaktionalen Versionsspeicher gelöscht.

Über den asynchronen Merge werden Daten aus dem Deltaspeicher in den Hauptspeicher verschoben.

Tabellen im zeilenbasierten Speicher haben einen primären Index.

Die Komprimierung erfolgt über die Dictionary- und andere angewandte Komprimierungsmethoden.

Während der Merge-Operation ist die Spaltentabelle weiterhin für Lese- und Schreiboperationen verfügbar. Zu diesem Zweck wird intern ein zweiter Delta- und Hauptspeicher verwendet.

Die Merge-Operation kann auch manuell mithilfe eines SQL-Befehls ausgelöst werden.

Die Zeilen-ID (Row ID) verweist auf den primären Schlüssel.

Es können sekundäre Indizes erstellt werden.

Die Zeilen-ID (Row ID) enthält das Segment und die Seite für den Datensatz.

Indizes im zeilenbasierten Speicher sind nur im Arbeitsspeicher vorhanden.

Die Indexdefinition wird in den Tabelle-Metadaten gespeichert.

 

Tabelle 1.2

Zeilenbasierter Speicher im Vergleich zu spaltenbasiertem Speicher

1

In-Memory-Computing, Big Data und SAP HANA

1.2.4 Die Möglichkeiten von SAP HANA

SAP HANA kann vieles, aber nicht alles. In diesem Abschnitt zeigen wir Ihnen, was mit SAP HANA möglich ist und was nicht.

Was SAP HANA kann

Abbildung 1.9 zeigt das Spektrum der Analyseanforderungen, die mit einer SAP-HANA-fähigen Lösung erfüllt werden können.

Leitende Business Line Gelegentliche Business- Finanz- Angestellte Manager Manager Benutzer

Leitende

Business

Line

Gelegentliche

Business-

Finanz-

Angestellte

Manager

Manager

Benutzer

Analysten

analysten

Dashboarding
Dashboarding
Scorecarding
Scorecarding

Reporting

Query
Query

Analyse

Planung
Planung

Verwendung von Echtzeit-

Überwachung der

Prognose zur zukünftigen

Planung nachfolgender

oder historischen Daten

Unternehmens-

Unternehmensentwicklung

Schritte mithilfe von

zur Entdeckung des Geschehenen

entwicklung mit gelenktem oder Self-

mithilfe statistischer Inhalte, » Was-wäre-wenn«- sowie

einer umfassenden Unternehmensplanung

Service-Zugriff

vorausschauender Analysen

Abbildung 1.9 SAP HANA – Analysefunktionen

Ihre SAP-HANA-basierte Lösung kann unterschiedlichsten Geschäftsanforde- rungen gerecht werden. Wie Sie bereits wissen, kann SAP HANA Milliarden von Zeilen mit Informationen in Bruchteilen von Sekunden zusammenbrin- gen und analysieren. Die Optionen und Funktionen, die auf diese Weise ermöglicht werden, variieren je nach Branche und Benutzer. Es sind sowohl umfassende als auch gezielte Analysen möglich, wie sie in Abbildung 1.10 dargestellt sind.

Mit SAP HANA haben Sie die Möglichkeit, all diese Fragen zu beantworten. Die Anwendungsoptionen werden daher nur durch die Anforderungen Ihres Unternehmens begrenzt.

Das Potenzial von SAP HANA für die praktische Anwendung umfasst zahlrei- che Branchen und Anwendungsfälle:

Handel

Kundenbindung

Telekommunikation

SAP HANA – Einführung

1.2

Fertigungsindustrie

Verkehrssteuerung

Betrugsbekämpfung

Umfassender Einsatz

Gezielter Einsatz

Analytisches Reporting

Trending

Szenariomodellierung

Advanced Analytics

Ansichten aufreißen, sortieren oder ändern, um Marktverände- rungen nachzuverfolgen und Poduktrangfolgen zu überwachen

Analyse von Umsatz- trends und des Marktes durch sinnvolle Daten- organisation und -analyse

Szenariomodellierung oder -vergleich für einen tieferen Einblick in die Finanzdaten bzw. Ertragslage des Unternehmens

Die Überwachung von Mustern in Daten und Texten trägt zum Schutz vor Betrug bzw. zur Prognose möglicher positiver oder negativer Resultate bei.

Marktveränderungen

Produktrangfolgen

 
Marktveränderungen Produktrangfolgen   Gelegentliche Leitende Business Finanz- und
Marktveränderungen Produktrangfolgen   Gelegentliche Leitende Business Finanz- und
Marktveränderungen Produktrangfolgen   Gelegentliche Leitende Business Finanz- und
Gelegentliche Leitende Business Finanz- und Statistik- Benutzer Angestellte Manager

Gelegentliche

Leitende

Business

Finanz- und

Statistik-

Benutzer

Angestellte

Manager

Geschäftsanalysten

analysten

(Konsumenten)

(Konsumenten) (Experten)
(Konsumenten) (Experten)
(Konsumenten) (Experten)

(Experten)

Abbildung 1.10 Bandbreite der SAP-HANA-Analyseoptionen

Dies sind nur einige der scheinbar unzähligen Möglichkeiten, die derzeit entwickelt und diskutiert werden. Für alle werden große Mengen an jeder- zeit verfügbaren Daten benötigt. Die gängigsten Einsatzbereiche von SAP HANA sind (derzeit):

CDR-Analyse (Call Detail Record)

Verkaufsortanalyse

Qualitäts- und Produktionsanalyse

intelligentes Netz / intelligentere Versorgungsunternehmen

RFID-Tracking und -Analyse

Betrugs-/Risikomanagement und -modellierung

umfassendes und vollständiges Verständnis der Kundenanforderungen und -gewohnheiten

Prognosemodellierung

Was-wäre-wenn-Szenarios

Preisoptimierung

1

In-Memory-Computing, Big Data und SAP HANA

Was SAP HANA nicht kann

Da Sie nun die Grundzüge von SAP HANA und die Möglichkeiten dieser Datenbank kennen, erfahren Sie im Folgenden, was SAP HANA nicht ist:

SAP HANA ist keine Berichterstellungslösung. Es beinhaltet also keine Funktion zur Berichterstellung. Zur Erzeugung von Berichten müssen Sie ein BI-Werkzeug wie z.B. die SAP-BusinessObjects-Business-Intelligence- (BI-)Plattform installieren und anbinden. Weitere Informationen zu SAP BusinessObjects BI und SAP HANA finden Sie in Kapitel 7, »SAP HANA und SAP Business Intelligence«.

SAP HANA ist kein ETL-Werkzeug (ETL = Extraktion, Transformation, Laden). SAP HANA benötigt zur Gewinnung von Daten entweder ein eigenständiges ETL-Werkzeug oder SAP Data Services. Weitere Informa- tionen zu ETL für SAP HANA finden Sie in Kapitel 12, »Datenbereitstel- lung«.

SAP HANA ist kein Datenmodellierungswerkzeug. Zur Erstellung von Datenmodellen können Sie SAP HANA Studio verwenden. Wenn Sie SAP BW auf SAP HANA einsetzen, können Sie aber weiterhin auch die Daten- modellierungswerkzeuge von SAP BW nutzen. Weitere Informationen zu SAP HANA Studio finden Sie in Kapitel 10, »Datenmodellierung mit SAP HANA Studio«, und in Kapitel 11, »Erweiterte Konzepte in SAP HANA Studio«.

SAP HANA ist kein Modul von SAP ERP und unterscheidet sich als Werk- zeug vollständig hiervon. SAP HANA kann als Datenbank eingesetzt wer- den, auf der die SAP-ERP-Lösung aufgebaut wird. Es handelt sich aber nicht um ein Transaktionssystem.

SAP HANA ist kein SAP BW. SAP BW ist ein Werkzeug für ein persistentes, hochstrukturiertes Datenmodell, das auf einem erweiterten Sternschema- konzept basiert. Bei SAP HANA ist dies nicht der Fall.

SAP HANA ist kein Qualitätsmanagementwerkzeug. Ein solches sollten Sie allerdings unbedingt haben!

Wir haben Ihnen nun die Möglichkeiten und Einschränkungen von SAP HANA im Detail erläutert. Ihnen steht mit SAP HANA eine äußerst schnelle Datenbank zur Verfügung, die durch entsprechende Hardware, ETL, Model- lierung und eine BI- bzw. Transaktionslösung unterstützt werden muss. Letztendlich hängt die Leistung von SAP HANA davon ab, was Sie daraus machen. Viele Kunden setzen SAP HANA mit einer finalen Lösung gleich, wie z.B. einem SAP-Werkzeug oder einer bestimmten Funktionalität. Sätze

SAP HANA – Einführung

1.2

wie »Wir werden SAP-HANA-Reporting implementieren« oder »Können Sie uns SAP HANA zeigen?« sind keine Seltenheit. Allerdings kann SAP-HANA- Reporting nicht implementiert werden, da es sich nicht um ein Reporting- werkzeug handelt. Und obwohl wir Ihnen ein SAP-HANA-Paket und die Datenbanktabellen in SAP HANA zeigen könnten, ist dies genauso schwierig wie die Demonstration einer Oracle-Datenbank. SAP HANA steht für Power und Geschwindigkeit. Sehen Sie daher SAP HANA eher als einen Wegbereiter an, und behalten Sie immer im Hinterkopf, dass es allein darauf ankommt, was Sie mit Ihren Daten und Informationen tun, die sich auf SAP HANA befinden.

1.2.5 SAP HANA – Akzeptanzkriterien

Nachdem Sie erfahren haben, was SAP HANA ist und wie es eingesetzt wer- den kann, scheint die Antwort auf die Frage, wie man Unternehmen davon überzeugt, SAP HANA einzusetzen, einfach zu sein. In vielerlei Hinsicht ist die Frage tatsächlich einfach. Unternehmen suchen schlicht nach Möglich- keiten, neue Anforderungen zu erfüllen oder aktuelle Prozesse zu beschleu- nigen. Das ist aber nur eine Perspektive.

Im Wesentlichen möchten Unternehmen Informationen für alle in optimier- ter Form an den entsprechenden Stellen nutzbar und zugänglich machen, um so bessere Entscheidungen und Maßnahmen treffen zu können. Es sind Lösungen gefragt, die Daten und Informationen so verarbeiten und bereit- stellen (Beschaffung) können, dass sie zuverlässig sind (Verwaltung) und für Berichte und Analysen (sowohl für langfristig definierte als auch für ad hoc erstellte) genutzt werden können, die wiederum Maßnahmen ermöglichen (siehe Abbildung 1.11). Unternehmen verknüpfen dies mit der Anforderung an eine vollständige Transparenz der Informationen, wodurch die Geschwin- digkeit der gewonnenen Erkenntnisse erhöht wird. Außerdem binden sie das Informationskonzept als strategischen Vorteil in die Unternehmenskul- tur mit ein.

Unternehmen entscheiden sich für den Einsatz von SAP HANA, um die Bereitstellung dieser Analyselösungen zu ermöglichen, die Performance ihrer bestehenden SAP-BW-Systeme zu beschleunigen und eigenständige oder Unternehmenslösungen zur Erfüllung der Reporting- und Analysean- forderungen aufzubauen, die mit den bestehenden Lösungen nicht abge- deckt werden können (oder so umfangreiche Daten oder Rechenleistungen benötigen, dass Ergebnisse nicht in einem angemessenen Zeitraum bereitge- stellt werden können). Ähnliche Erwartungen haben Unternehmen, die SAP

1

In-Memory-Computing, Big Data und SAP HANA

HANA als einen Wegbereiter für ihre SAP-ERP-Systeme auffassen: Vorhan- dene Lösungen sollen schneller werden, bzw. neue, eigenständige Lösungen sollen entwickelt werden, sodass bisher nur unzureichend erfüllbare Aufga- ben künftig in angemessener Form ausgeführt werden können.

Benutzerorientiertes Design

Verwalten Berichten Datenqualität Handeln Beschaffen Herausfinden Messgr. & Maßn. Ableiten
Verwalten
Berichten
Datenqualität
Handeln
Beschaffen
Herausfinden
Messgr. & Maßn.
Ableiten
Prozessintegration
Mobilität
Warnen
Nachforschen

Soziale Kollaboration

Messgr. & Maßn. Ableiten Prozessintegration Mobilität Warnen Nachforschen Soziale Kollaboration Cloud
Messgr. & Maßn. Ableiten Prozessintegration Mobilität Warnen Nachforschen Soziale Kollaboration Cloud

Cloud

Messgr. & Maßn. Ableiten Prozessintegration Mobilität Warnen Nachforschen Soziale Kollaboration Cloud
Messgr. & Maßn. Ableiten Prozessintegration Mobilität Warnen Nachforschen Soziale Kollaboration Cloud

Abbildung 1.11 Beschaffung, Verwaltung, Berichte, Maßnahmen

Zudem verstehen die Unternehmen SAP HANA als eine Basis für die Zukunft. Wie Sie bereits wissen, kann SAP HANA die zugrunde liegende Datenbankplattform für SAP-ERP-Umgebungen und alle anderen Transak- tionssysteme werden. SAP baut zahlreiche neue Anwendungen, Prozesse und Lösungen auf dieser Plattform auf. Wenn Unternehmen ihre bestehen- den Datenbanklizenzen erneuern müssen, prüfen sie auch ihre langfristigen Pläne und treffen Entscheidungen darüber, in welche Plattform sie investie- ren möchten. Obwohl SAP HANA für die SAP-Business-Suite-Anwendungen noch sehr neu ist, erkennen die Unternehmen die langfristige Roadmap und führen SAP HANA jetzt ein, um eine Basis zu schaffen.

In den nachfolgenden Kapiteln dieses Buchs erörtern wir, welche Rolle Big Data für die von zahlreichen Unternehmen gewünschten vorausschauenden und erweiterten Analysen spielt. Bei der Lektüre dieses Buchs und bei weite- ren Recherchen zu den Themen SAP HANA und In-Memory-Computing wer- den Sie feststellen, dass keine erweiterte Analyselösung ohne das Thema Big Data auskommt. SAP HANA bietet den Benutzern die Möglichkeit, Milliar- den von Informationen gleichzeitig zu analysieren, und es muss gewährleis- tet werden, dass diese Milliarden von Daten zuverlässig, vollständig und zugänglich sind. Je mehr SAP die SAP-HANA-Technologie weiterentwickelt, desto kritischer wird dieser Aspekt.

Einführung in die Implementierungsoptionen

1.3

1.3 Einführung in die Implementierungsoptionen

Bisher haben Sie erfahren, was unter In-Memory-Computing und Big Data zu verstehen ist und wie SAP HANA diese beiden Konzepte vereint. Als Nächstes sollten Sie sich einen Überblick über Ihre Möglichkeiten bei der Implementierung von SAP HANA verschaffen.

Nachdem Sie die für Sie wichtigsten Funktionen ermittelt haben, müssen Sie sich für ein entsprechendes Implementierungsszenario entscheiden. Dieser Abschnitt beleuchtet die drei Hauptmöglichkeiten: SAP HANA als Grundlage für ein Standalone Data Warehouse für Analysen, SAP BW auf SAP HANA und SAP Business Suite auf SAP HANA.

SAP HANA Rapid Deployment Solutions

Es gibt jedoch auch noch eine vierte Option: SAP Rapid Deployment Solutions für SAP HANA. Da wir uns in diesem Buch auf die Grundlagen von SAP HANA kon- zentrieren, wird diese Option nicht weiter erläutert. Für weitere Informationen über SAP Rapid Deployment Solutions im Allgemeinen, einschließlich SAP HANA, empfehlen wir Ihnen Rapid Deployment of SAP Solutions (SAP PRESS, 2014). Die- ses Buch finden Sie unter www.sap-press.de/3432.

Die Informationen in diesem Abschnitt sind nur als Einleitung gedacht. In Kapitel 2, »SAP-HANA-On-Premise-Implementierungsoptionen«, werden die drei Implementierungsoptionen ausführlicher beschrieben.

1.3.1 Data Warehouse für Analysen

Bei der Standalone-Implementierung von SAP HANA als Data Warehouse für Analysen wird in einem Unternehmen eine neue SAP-HANA-Instanz imple- mentiert, um eine spezielle Reporting- oder Analyseanforderung zu erfüllen. Ein Beispiel hierfür ist eine Reportinglösung, für deren Aufbau normaler- weise Tausende von Arbeitsstunden oder Milliarden von Datenzeilen benö- tigt werden – eine Anforderung, die Ihre BI-Umgebung Ihrer Meinung nach niemals hätte handhaben können.

Diese SAP-HANA-Installationen richten sich an eine bestimmte Stelle oder eine einzelne Lösung und könnten deshalb für das Unternehmen von erheb- lichem Wert sein, da dieses eine Problem, das entweder als nicht lösbar oder aufgrund des hohen Aufwands als nicht kosteneffektiv eingestuft wurde, behoben wird. In dieser SAP-HANA-Implementierung müssen Daten über ETL-Prozesse in SAP HANA eingebunden, das Datenmodell erstellt (was bei Weitem nicht so anspruchsvoll oder komplex wie in SAP BW, aber dennoch

1

In-Memory-Computing, Big Data und SAP HANA

mit einem gewissen Aufwand verbunden ist), ein BI-Werkzeug installiert und Berichte erzeugt werden. Hierzu erhalten Sie später noch nähere Infor- mationen.

1.3.2 SAP BW auf SAP HANA

Mit der Option SAP BW auf SAP HANA soll die Performance des bestehen- den SAP-BW-Systems optimiert werden. Dabei kann entweder eine beste- hende Datenbank (Oracle, DB2 usw.) durch eine SAP-HANA-Datenbank ersetzt werden oder eine Sidecar-Version von SAP BW, die auf SAP HANA läuft, ausgeführt werden.

1.3.3 SAP Business Suite auf SAP HANA

Der Einsatz der SAP Business Suite auf SAP HANA wirft viele Fragen bezüg- lich der Trennung zwischen OLTP (Online Transactional Processing) und OLAP (Online Analytical Processing) auf, wie sie in Data Warehouses vor- herrscht. Muss das Reporting wirklich von der Vorgangsbearbeitung getrennt werden? Die Antwort auf diese Frage hängt von Ihrem Zeitplan ab. Auf kurze Sicht gibt es eine Vielzahl hilfreicher und lohnenswerter Modelle in SAP BW, SAP Advanced Planner and Optimizer (APO), SAP Business Plan- ning and Consolidation (BPC), Integrierte Planung (IP) und allen anderen auf Data Warehouses basierten Werkzeugen. Diese Werkzeuge haben jedoch alle Achillesfersen; sie arbeiten nicht in Echtzeit und sind auf separate Infra- strukturen und Datenbewegungen angewiesen. Die Diskussion innerhalb von SAP und zwischen SAP-Kunden über die langfristigen Trends in Hinblick auf die Trennung von OLAP und OLTP ist also weiterhin aktuell.

Die neue Botschaft von SAP ist »Run simple«, und die Fähigkeit, OLTP und OLAP in einer Plattform auszuführen, ist ein Weg von SAP, diese Botschaft auch umzusetzen. In diese Vision werden viele Hoffnungen gesetzt, und es ist beträchtlicher Entwicklungsaufwand nötig, um Daten im OLTP-System so zu organisieren, dass sie für das Reporting genutzt werden können. Dies kann durch separate SAP-HANA-Reportingtabellen im SAP-ERP-System erreicht werden, indem Sichten auf Daten mit SAP HANA Studio erzeugt werden bzw. SAP HANA Live eingesetzt wird.

Für die nähere Zukunft bietet SAP BW eine integrierte Plattform für modell- orientierte Analysen von Daten, die während des Vorgangs erhalten bleiben und mit externen Daten integriert werden müssen. Diese Plattform enthält auch das Corporate Memory für vorherige Vorgänge. Die Zukunftsvision

Einführung in die Implementierungsoptionen

1.3

eines integrierten BI- und SAP-ERP-Systems auf derselben Plattform bleibt also eine Zukunftsvision und ein Ziel.

Durch die Auslagerung des SAP-ERP-Systems auf eine SAP-HANA-Plattform ist es jedoch möglich, Vorgänge schneller auszuführen, Datenbanken zu ver- kleinern und damit die Administration zu vereinfachen. Außerdem stehen neue Analysefunktionen im SAP-ERP-System zur Verfügung.

Wenn Sie sich für eine Implementierung der SAP Business Suite auf SAP HANA entscheiden, haben Sie verschiedene Möglichkeiten. Ähnlich wie bei SAP BW auf SAP HANA können Sie Ihre vorhandene SAP Business Suite voll- ständig auf SAP HANA migrieren oder eine Sidecar-Instanz Ihrer SAP Busi- ness Suite erzeugen und dann nur einen Teil der Suite auf SAP HANA migrie- ren. Erste Anwender der SAP Business Suite auf SAP HANA können die Implementierung von Sidecar-Lösungen nutzen, um Einzelaktivitäten her- auszufiltern, die die Systeme hoher Arbeitsbelastung aussetzen und sie von den wichtigen Vorgangsaktivitäten trennen. So können Unternehmen die Vorteile von SAP HANA nutzen, ohne ihre gesamten operativen Aktivitäten auf einmal auslagern zu müssen und damit ein scheinbar hohes Risiko in Kauf zu nehmen. Je vertrauter und sicherer diese Unternehmen mit dieser Lösung werden, desto mehr SAP-Business-Suite-Anwendungen werden sie auf SAP HANA verschieben, bis sie eine vollständig SAP-HANA-fähige Lösung aufgebaut haben.

SAP Business Suite auf SAP HANA für kleine und mittelständische Unternehmen

Bei SAP Business One handelt es sich um ein Vorgangssystem für kleine und mit- telständische Unternehmen. Das Produkt bietet Unterstützung sowohl für die Anwendung als auch für In-Memory-Datenstrukturen für SAP HANA. Dies führt zu einer erheblichen Vereinfachung in der Serverlandschaft und zu beträchtlichen Leistungssteigerungen bei der Vorgangsbearbeitung und Ausführung von Jobs. Durch die Komprimierung der Datenbank werden zudem Sicherungs- und Disas- ter-Recovery-Zeiten verkürzt.

Damit Sie die Vorteile der neuen Funktionen nutzen können, bietet SAP eingebet- tete kontextbezogene Dashboards für den Transaktionsbildschirm an. Diese bein- halten grundlegende Grafiken für Positionen wie die meistgekauften Produkte von Kunden, Kredit-Dashboards, Echzeittrends von Beständen, Lieferantenanalysen und Cashflow-Prognosen.

Eine weitere Option für kleine und mittlere Unternehmen ist SAP HANA Enterprise Cloud. Weitere Informationen zu SAP HANA in der Cloud finden Sie in Kapitel 3, »SAP HANA in der Cloud«.

1

In-Memory-Computing, Big Data und SAP HANA

Alternativ können Sie auch die Leistung des bereits vorhandenen SAP-ERP- Systems optimieren, indem Sie die gesamte vorhandene Datenbank (Oracle, DB2 usw.) von Anfang an durch eine SAP-HANA-Datenbank ersetzen. In die- sem Fall wird einfach die vorhandene Datenbank auf SAP HANA migriert. Die Funktionen der SAP-ERP-Anwendungen bleiben erhalten, und Konfigu- rationen und Anpassungen können mit dem Wissen optimiert werden, dass die SAP-HANA-Funktionen Unterstützung für die Lösung bieten.

1.4

Zusammenfassung

Sie wissen nun, welche Fragen Sie stellen müssen, und Sie verstehen jetzt besser, was SAP HANA ist und was es nicht ist. Ebenso haben Sie erfahren, wie SAP HANA die Anforderungen Ihres Unternehmens erfüllen kann.

In den folgenden Kapiteln werden wir einige der hier angesprochenen The- men näher betrachten, sodass Sie am Ende des Buchs die Informationen besitzen, die Sie benötigen, um SAP HANA und die Auswirkungen auf Ihr Unternehmen entsprechend bewerten zu können.

Kapitel 2

2

Nachdem Sie jetzt wissen, was SAP HANA ist und wie es möglicherweise in Ihr Unternehmen passt, ist es nun an der Zeit, die verfügbaren On-Premise-Optionen im Detail kennenzulernen.

SAP-HANA-On-Premise-

Implementierungsoptionen

Wie Sie sicherlich bemerkt haben, gibt es den zunehmenden Trend, Anwen- dungen und Infrastrukturen in cloudbasierte Umgebungen zu verschieben und somit die Kosten und Verantwortlichkeiten für den Erwerb und die Wartung der Hardware von der IT-Abteilung auf die Host-Provider zu über- tragen. Dies ist auch bei SAP der Fall. Entsprechend ist SAP HANA in unter- schiedlichen Cloudversionen verfügbar. Allerdings sind die On-Premise- Implementierungen immer noch die gängigste Methode, um SAP-HANA- fähige Lösungen in Unternehmensumgebungen umzusetzen. In diesem Kapitel erhalten Sie deshalb Informationen über die drei Möglichkeiten der On-Premise-Implementierung von SAP HANA: SAP HANA als ein Data Warehouse für Analysen, SAP BW auf SAP HANA und SAP Business Suite auf SAP HANA. Insbesondere werden die technischen Unterschiede zwischen den drei Implementierungen sowie die verschiedenen Anforderungen und allgemeinen Schritte der Projektplanung besprochen. Zum Abschluss des Kapitels erhalten Sie einige Hinweise, die Sie bei der Auswahl der für Sie geeigneten Implementierung beachten sollten.

SAP HANA in der Cloud

Weitere Informationen zu SAP HANA in der Cloud finden Sie in Kapitel 3, »SAP HANA in der Cloud«.

2.1 SAP HANA als Data Warehouse für Analysen

Die erste SAP-HANA-Implementierungsmöglichkeit, die wir besprechen möchten, ist das Data Warehouse für Analysen, das entweder in einem Data

2

SAP-HANA-On-Premise-Implementierungsoptionen

Warehouse des Unternehmens oder als Sidecar zur Erweiterung der beste- henden Analyse- oder Berichtanforderungen umgesetzt werden kann. Die Data-Warehouse-Implementierung von SAP HANA für Analysen beinhaltet kein SAP-BW-System.

Im ersten Kapitel wurde SAP HANA im Wesentlichen als Datenbank und Grundlage für die Lösungsbereitstellung beschrieben. In der im Folgenden näher erläuterten Implementierung wird SAP HANA weit mehr. Es umfasst einen kompletten Satz aus Komponenten und Aufgaben: Hardware, die SAP- HANA-Datenbank, die spezifischen Softwarekomponenten, die implemen- tiert werden müssen, das Modellierungsstudio, die BI-Werkzeuge und die Administration von SAP HANA.

Hierbei handelt es sich nicht um eine umfassende Plug&Play-Lösung. (Tat- sächlich ist SAP HANA in keinem Szenario plug&play-fähig.) Wenn Sie sich für diese Implementierung von SAP HANA entscheiden, erhalten Sie Folgen- des:

SAP HANA Studio

SAP Host Agent 7.2

SAPCAR 7.10

SAP (Sybase) Replication Server 16

SAP HANA Load Controller 1.00

SAP Landscape Transformation 1 – SHC for ABA

Dieser Technologiesatz kann nicht ohne Weiteres implementiert werden, da dafür Hardware, ein BI-Werkzeug oder die Absicht, über Microsoft Excel auf Daten zuzugreifen, sowie ein Datenintegrationswerkzeug erforderlich sind. Bei den Quellsystemen für Ihre SAP-HANA-Datenbanken, also den Sys- temen, aus denen die Daten stammen, muss es sich nicht unbedingt um SAP- Umgebungen handeln. Vielmehr legt Ihre Wahl der Quellsysteme das Werk- zeug fest, das Sie zum Laden von Daten einsetzen können, und bestimmt Ihre Optionen für diese Werkzeuge.

Die gute und zugleich schlechte Nachricht hinsichtlich der Data-Warehouse- Implementierung von SAP HANA für Analysen ist, dass Sie sie von Grund auf neu aufbauen müssen. Mit anderen Worten, sie bietet Ihnen mehr Frei- heit und Flexibilität, verlangt jedoch auch zusätzlichen Aufwand. Sie müssen planen und konfigurieren, wie die Daten geladen werden. Sie müssen das eingeschränkte Datenmodell planen und konfigurieren. Sie müssen die Benutzer, die Sicherheit und die Berechtigungen planen und konfigurieren.

SAP HANA als Data Warehouse für Analysen

2.1

Sie müssen das Interface für die BI-Lösung planen und konfigurieren (und es anschließend installieren und implementieren). Sie müssen die Reporting- und die Analyseschicht planen und konfigurieren.

Auch wenn dies zunächst nach einem gewaltigen Aufwand klingt, wird mit einem Blick auf die Vorteile dieser Implementierung deutlich, warum sie sich dennoch lohnt. Sie bietet:

Reportinglösungen, die Sie mit Ihren SAP-Werkzeugen so nie zuvor ein- setzen konnten (oder niemals in Betracht gezogen hätten)

die Anzeige riesiger Datenmengen mit sehr hohem Detaillierungsgrad in Echtzeit (oder nahezu Echtzeit)

direkten Zugriff auf Milliarden von Informationszeilen

sekundenschnellen Zugriff auf Milliarden von hochdetaillierten SAP- und/ oder Nicht-SAP-Transaktionsdaten auf Betriebsebene

direkten Zugriff auf Milliarden von Zeilen an Nicht-SAP-Daten

Reporting- oder Analyselösungen, die (heute) einen riesigen Anteil der Rechenleistung beanspruchen oder manuelle Datenaggregation erfordern

Erkenntnisse innerhalb von Sekunden, damit Sie auf das Verhalten Ihrer Mitarbeiter, Lieferanten und Kunden reagieren können, dieses vorhersa- gen und schließlich beeinflussen können, indem Sie deren Verhaltenswei- sen verstehen

Denken Sie daran, dass der Sinn und Zweck der Data-Warehouse-Implemen- tierung von SAP HANA für Analysen darin besteht, die gesamte Lösung von Grund auf neu zu konzipieren: Sie bauen neue, (sehr) umfangreiche In- Memory-Datenbanken auf und erstellen dann ein entsprechendes Datenmo- dell und einen Satz von Reporting- und Analysefunktionen. Diese Implemen- tierung von SAP HANA steht in keinem Zusammenhang mit SAP-BW-Imple- mentierungen, die Sie womöglich bereits einsetzen.

In Tabelle 2.1 werden einige Aspekte aufgeführt, die beim Einschätzen des Aufwands für eine Implementierung von SAP HANA als Data Warehouse zu beachten sind.

Mithilfe dieser Aspekte können Sie den Umfang und den Aufwand für Ihre SAP-HANA-Implementierung bestimmen und ein Mitarbeitermodell sowie einen Zeitplan für die Implementierung erstellen. SAP-HANA-Data-Ware- house-Implementierungen können einige Wochen bis hin zu einigen Mona- ten beanspruchen. Die Einrichtung und Installation des eigentlichen Systems – der leeren Datenbank – dauert nur eine Woche oder auch weniger, ein-

2

SAP-HANA-On-Premise-Implementierungsoptionen

schließlich der Zeit für den Wissensaustausch mit Ihren Administratoren. Der übrige Aufwand liegt in der Definition und dem Aufbau der Lösung und der unterstützenden Komponenten.

Aspekt

Wichtige Überlegung

Anwendungsfall

SAP-Geschäftsprozess oder Nicht-SAP-Daten erforderlich

Datenbeschaffung

Auswahl und Konfiguration des ETL-Werkzeugs/-Pro- zesses (SLT, SAP [Sybase] Replication Server, SAP Data Services)

Auswirkungen auf Enterprise Data Warehouse (EDW)

Reengineering vorhandener EDW-Lösungen oder manueller Prozesse

Zugriff/Benutzerinteraktion

Integration oder Auswirkungen von SAP Business- Objects BI (oder anderer BI-Werkzeuge): Universen, Dashboards, SAP-BusinessObjects–Explorer-Daten, Berichte

Datenmodellierung

SAP-HANA-Modellierungsobjekte (Attribut-, Analyse- und Berechnungssichten)

Sicherheit

Entwurf des SAP-HANA-Sicherheitsmodells

Landschaft

SAP-HANA-Sizing und Installation

Operationen

Disaster Recovery, Sicherung, Verfügbarkeit

Tabelle 2.1

Überlegungen zu SAP HANA als Data Warehouse

Ein Unternehmen kann eine einfache SAP-HANA-Lösung innerhalb weniger Wochen konzipieren und testen, wenn zu Beginn alle erforderlichen Bestandteile vorliegen, d.h., wenn die Daten griffbereit sind. Mit anderen Worten, die Daten müssen falls nötig harmonisiert werden und die erwünschten Berichte und/oder Analysen gut definiert werden.

Wenn Sie ein größeres, komplexeres SAP-HANA-Ausgangsprojekt benöti- gen, können Sie selbstverständlich auch dies in Angriff nehmen, indem Sie ein langfristigeres Projekt mitsamt allen relevanten Aspekten planen. Ein komplexes Pilotprojekt, bei dem beispielsweise Kreditkarten-Transaktionen in einem großen Finanzinstitut untersucht werden, kann durchaus schon einmal drei Monate dauern.

SAP HANA als Data Warehouse für Analysen

2.1

Eine »einfache« SAP-HANA-Lösung

Eine »einfache« SAP-HANA-Lösung kann hilfreich sein, um die Systemleistung und das Gesamtkonzept zu testen und zu bewerten. Dabei handelt es sich eher um ein Pilotprogramm als um einen »Proof of Concept«. Der Unterschied besteht darin, dass es sich bei einem Pilotprogramm um eine tatsächliche Produktionslösung handelt – wenn auch um eine kleine oder eine für einen einzelnen, hoch speziali- sierten Anwendungsfall. Diese Lösungen können zum Validieren der SAP-HANA- Funktionen für das Unternehmen und die Benutzer verwendet werden und anschließend als Grundlage dienen, auf der aufgebaut werden kann.

Unabhängig davon, ob es sich bei Ihrem Projekt um ein kleines Pilotprojekt oder um ein großes, komplexes Programm handelt, sollten Sie sicherstellen, dass Ihr internes Team von erfahrenen SAP-HANA-Experten unterstützt wird. Wenngleich der Aufbau einer SAP-HANA-Lösung in vielerlei Hinsicht dem Aufbau einer traditionellen (Nicht-SAP-)BI-Lösung entspricht, ist SAP HANA eine neue Technologie mit neuen Werkzeugen und Funktionen.

Im Folgenden beschreiben wir die technischen Voraussetzungen und erfor- derlichen Qualifikationen für ein Unternehmen, das die Implementierung von SAP HANA als Data Warehouse in Betracht zieht. Abschließend finden Sie eine allgemeine Übersicht über die Bestandteile eines entsprechenden Projektplans.

2.1.1 Technische Voraussetzungen

Die Implementierung von SAP HANA als Data Warehouse wird von Grund auf aufgebaut. Die erforderliche Architektur ist in Abbildung 2.1 dargestellt.

Mit dieser Architektur wird die Grundlage geschaffen, um neue Reporting- und Analyselösungen für Ihre Transaktionsdaten aufzubauen. Darüber hin- aus können Sie jedoch einen zusätzlichen Datensatz aus diesen Transaktions- systemen in die SAP-HANA-Datenbank übernehmen, der schneller geladen wird, detaillierter ist und ein größeres Volumen aufweist.

Für die SAP-HANA-Datenbank werden Hardware sowie die für diese Hard- ware erforderlichen Betriebssysteme benötigt.

Tabelle 2.2 zeigt ein Beispiel der verfügbaren Optionen eines Lieferanten für die Hardwarekonfiguration.

2

SAP-HANA-On-Premise-Implementierungsoptionen

SAP BusinessObjects Mobile

SAP Crystal Reports
SAP Crystal
Reports
SAP BusinessObjects Mobile SAP Crystal Reports Web Intelligence Dashboards BusinessObjects Common ABAP Semantic Layer
Web Intelligence
Web
Intelligence
Dashboards
Dashboards
BusinessObjects Common ABAP Semantic Layer SAP BW BWA SAP Business Suite Nicht-SAP
BusinessObjects Common
ABAP
Semantic Layer
SAP BW
BWA
SAP Business Suite
Nicht-SAP
Replikation/ETL Explorer SAP HANA
Replikation/ETL
Explorer
SAP HANA
Suite Nicht-SAP Replikation/ETL Explorer SAP HANA SAP BusinessObjects Mobile Web Intelligence SAP Crystal

SAP BusinessObjects Mobile

Web Intelligence
Web
Intelligence
SAP Crystal Reports
SAP Crystal
Reports
Dashboards
Dashboards
BusinessObjects Common Semantic Layer
BusinessObjects Common Semantic Layer
BusinessObjects Common Semantic Layer
BusinessObjects Common Semantic Layer
BusinessObjects Common Semantic Layer
BusinessObjects Common Semantic Layer

BusinessObjects Common Semantic Layer

BusinessObjects Common Semantic Layer

Abbildung 2.1 Data Warehouse für Analysen: Architektur

Baustein

Server

CPUs

Memory

Protokoll-

Daten-

Vor-

(MTM)

speicher

speicher

installierte

Software

XS

x3690 X5

2

× Intel

256

GB

10

× 200 GB 1.8* MLC

Ja

(7147-HAx)

Xeon

DDR3

SSD (Kombination von Protokoll- und Daten- speicher)

E7-2870

(16 × 16 GB)

S

x3690 X5

2

× Intel

256

GB

10

× 200 GB 1,8* MLC

Ja

(7147-HBx)

Xeon

DDR3

SSD (Kombination von Protokoll- und Daten- speicher)

E7-2870

(16 × 16 GB)

S+

x3950 X5

2

× Intel

256

GB

1.2

TB

× 900 GB 10k SAS HDD

8

Ja

(7143-H1x)

Xeon

DDR3

FusionIO

E7-8870

(16 × 16 GB)

M

x3950 X5

4

× Intel

512

GB

1.2

TB

× 900 GB 10k SAS HDD

8

Ja

(7143-H2x)

Xeon

DDR3

FusionIO

E7-8870

(32 × 16 GB)

L-Option

x3950 X5

8

× Intel

1 TB DDR3 (64 × 16 GB)

2 × 1.2 TB FusionIO

16 × 900 GB 10k SAS HDD

Keine

(M+ Skalie-

(7143-H2x

Xeon

Vorinstal-

rungs-Kit)

+ 7143-

E7-8870

   

lation bei

H3x)

 

7143-H3x

Tabelle 2.2 TabelleVerfügbare2.2

Optionen