Beiträge

BI in der Cloud – lohnt sich das?

,

Es gibt eine Menge einzelne BI-Angebote in der Cloud, aber ein komplettes Data-Warehouse? Ist das heute bereits realisierbar, oder lohnt es sich noch nicht?

Sollen DWH-Architekturen verändert oder neu aufgebaut werden, stellt sich zunehmend auch die Frage, ob das DWH mitsamt BI-Backend nicht auch in „die Cloud“ verlagert werden kann. Neben den dafür allseitig angeführten Argumenten wie verringerte Bereitstellungszeiten, Elastizität und Kostenersparnis reizen viele Entscheider gerade die Möglichkeiten, die BI-Tools in der Cloud versprechen: Anwender würden immer die aktuelle Version des BI-Stack nutzen und eine hohe Verfügbarkeit ließe sich trotz überschaubarer eigener IT-Ressourcen garantieren. Ein agiles Self-Service-BI verspräche zudem, die Mauer zwischen IT und Business zu überwinden, weil Anwender neue Auswertungen schnell und selbst entwerfen und auch sogleich testen könnten.

Welche Möglichkeiten bieten sich im Einzelnen zur Realisierung an?

Transaktionales BI

Viele Unternehmen sammeln die ersten Erfahrungen auf dem Weg in die Oracle-Cloud mit den „BI Apps“. Eigentlich sind diese eine On-Premise-Lösung, um schnell Daten aus einer Anwendung aufzubereiten und so darzustellen, wie man es von Oracles BI-Lösungen gewohnt ist – inklusive Dashboards und interaktiven Analysen. Relativ früh wurden die BI-Apps in der Oracle-Cloud angeboten. Für die gerne ebenfalls in der Cloud betriebenen Oracle-Applikationen wie HCM (Human Capital Management) existieren fertige Lösungen, die die gewünschten Ergebnisse bereits fertig aufbereitet präsentieren. Selbst die fachliche Logik, also das Wissen darum, welche für die Analyse notwendigen Zahlen in welchen Tabellen der Anwendung verborgen sind, wird bereits mitgeliefert. Der Kunde spart sich die gesamte Wertschöpfungskette des klassischen Data Warehouse: Quellsystem-Analyse, Datenmodellierung, ETL und Erstellung von Dashboards und Reports.

Die BI-Apps sind Teil des sogenannten Oracle-Transactional-Business-Intelligence (OTBI). Transaktional, weil die BI-Elemente direkt aus den operativen Vorsystemen, den transaktionalen Anwendungen, gespeist werden. Wann immer schnelle Analysen aus den Oracle-Applications benötigt werden, ist OTBI eine interessante Lösung: Obwohl schnell und schlank, steht die Aufbereitung der erhaltenen Daten denen der klassischen Präsentation, wie man sie aus On-Premise-OBIEE-Systemen gewohnt ist, kaum in etwas nach – und ist mit minimalem Aufwand in der Oracle-Cloud verfügbar. OTBI ist für viele Oracle-Cloud-Apps einfach als Zusatzoption buchbar.

Was das transaktionale Reporting nicht leistet, ist die Integration verschiedener Quellen, also die klassische Aufgabe des Enterprise Data Warehouse (EDWH). Daten können nur dort aufbereitet und dargestellt werden, wo die notwendigen Transformationen zwischen Quelle und BI-Darstellung durch Oracle vorbereitet sind. Sollen eigene Integrationen durchgeführt oder Daten aus verschiedenen Quellen konsolidiert werden, muss weiter ausgeholt werden.

BI Cloud Services und Analytics Cloud

Neben OTBI unterhält Oracle ein weiteres Cloud-basiertes Angebot: Business-Intelligence-Cloud-Services. BICS ist die Cloud-Alternative zur Installation des Oracle-Business-Intelligence-Servers (OBIEE) im eigenen Hause.

Zur Anpassung an die Cloud-Umgebung hat Oracle vor allem die Funktionalität des Admin-Tools in eine neue Oberfläche integriert. Das traditionelle Admin-Tool läuft lokal auf einem Entwickler-PC. Mit ihm wird das OBIEE-Repository erstellt: den physischen Datenbankobjekten werden logische Entitäten gegenübergestellt, die beispielsweise Tabellen durch Joins über entsprechende gemeinsame Attribute verbinden, und schließlich wird das für den Benutzer sichtbare Universum aus geschäftlichen Relationen definiert. Diese Funktionalität wurde nun mit Hilfe des neuen Cloud-Admin-Tools weitgehend vom Windows-Client und seiner in die Jahre gekommenen Optik befreit und per Web-Browser nutzbar gemacht.

Einen großen Sprung nach vorne haben die Oracle-BI-Cloud-Angebote durch die Einführung der Analytics-Cloud (OAC) erfahren. Denn BICS wies einige Nachteile auf:

  • Es konnten ausschließlich die Inhalte einerDatenbank aufbereitet werden.
  • Es konnten keine Agenten verwendet werden.
  • Der BI-Publisher und Essbase wurden nicht unterstützt

BICS wurde daher eher als ein abteilungsfokussiertes Angebot eingeschätzt, das für den unternehmensweiten Einsatz nur bedingt tauglich schien. Dementsprechend verhielt sich auch das Preismodell: für USD 3.500[1],– pro Jahr erhielt der Kunde BICS mit einer dazugehörigen Cloud-Datenbank, die auf ein Storage-Volumen von 50 GB und einen Durchsatz von 300 GB begrenzt war.

OAC überwindet all diese Einschränkungen und bringt den zusätzlichen Vorteil mit, dass der zu Grunde liegende Datenbankdienst frei gewählt werden und auch eine bereits vorhandene Datenbanklizenz genutzt werden kann. Im Gegensatz zu BICS ist OAC ein für die Cloud neu entwickeltes Produkt[2]. Die Kosten belaufen sich in der „non-metered“, also pauschal abgerechneten Version auf USD 3.000,– pro Monat und OCPU[3]für die Standard und USD 6.000,– Listenpreis[4]pro Monat und OCPU für die Enterprise Edition. Die Enterprise Edition beinhaltet auch Essbase.

Angebot Kostenpunkt Umfang Zielgruppe
OTBI (-E) Je nach Anwendung Cloud Fusion
spezifisches  transaktionales Berichtswesen		 Abteilung bzw.
Organisation (-E)
BICS USD 30k/Jahr/10 Nutzer

(USD 1000/Monat +
USD 150/Monat/Named User)

 Abgespecktes OBIEE in der Cloud Abteilung
OAC USD 36(SE)-72k(EE)/Jahr/OCPU

+ DB + IaaS

 BI in der Cloud Abteilung und Unternehmen (mit eigener DB und ETL)

Wie jedes BI-Tool muss auch OAC mit den darzubietenden Daten bestückt werden. In der physischen Schicht des OBIEE bzw. BICS könnten natürlich transaktionale Daten der Vorsysteme direkt angeboten werden. Nun ist es aber so, dass die Data-Warehouse-Community ihre Referenzarchitektur nicht ohne Grund entworfen hat: Performance, Konformität und Konsistenz sind nur einige Schlagwörter, die eine Architektur bezeichnen, die sich auf Dauer zwar nicht ganz ohne Aufwand an Modellierung, Ladelogik und Speicherplatz realisieren lässt. Die aber eben doch in den allermeisten Fällen langfristig Zeit und Aufwand spart und zudem die entscheidenden Ergebnisse realistisch liefern kann.

DWH – Platform-as-a-Service

Ein klassisches, vollständiges Data-Warehouse kann Daten aus verschiedenen Quellen annehmen, aufbereiten und in ein gemeinsames Datenmodell integrieren. Die Daten werden – oft weiter zurückreichend als die Quellsysteme – historisiert, und durch Konsolidierung werden Redundanzen vermieden. Für die weitere Verarbeitung werden üblicherweise verschiedene Schichten angelegt: Die Stage, der Core und ein oder mehrere Data-Marts. Die Daten werden auseinandergenommen, transformiert und in ein dimensionales Modell geladen. Um das zu erreichen, werden eine Datenbank zur Ablage der jeweiligen Datenschichten und ein Extract-Transform-Load (ETL)-Tool benötigt.

Selbstverständlich bietet Oracle auch die Datenbank in der Cloud an. Dieses Angebot existiert in verschiedenen Ausprägungen[5]:

  • Database-Schema-Service: Ein Schema in einer Cloud-Datenbank mit 50 GB Volumen.
  • Exadata-Express: Eine Pluggable-Database (PDB) in einer 12.2 Cloud-Datenbank, ebenfalls mit einem Datenvolumen bis 50 GB.
  • Database-Cloud-Service (DBCS): Eine Datenbank auf einer Linux-VM in der Oracle-Public-Cloud, installierbar per Web-Tool in verschieden großen Ausprägungen.
  • Exadata-Cloud-Service: DBCS auf Exadata.
  • (Exadata)-Cloud-Service on Bare-Metal-Servers: DBCS auf einer dedizierter Hardware, die exklusiv für den Kunden reserviert ist (Private Cloud).

Für eine DWH-Datenbank empfiehlt sich, so lange – etwa aus Sicherheitsgründen[6]–  keine dedizierte Hardware benötigt wird, aber DWH-typische Anforderungen an Durchsatz und Zuverlässigkeit bestehen, der Exadata-Cloud-Service.

Allerdings ist von den verfügbaren Methoden, Daten in DBCS zu laden (SQL-Developer-Anbindung, APEX-Maske, REST- und SOAP-Interface sowie ein spezieller Adapter namens DataSync) nur letztere in der Lage, überhaupt Daten in den in DWH-Umgebungen üblichen Größenordnungen entgegenzunehmen. Es handelt sich dabei um ein Java-Tool, das die Daten aus der Quelle lädt und in die DBCS-Datenbank schiebt.

Der eigentlich angestrebte Weg, Daten der Quell-Systeme in ein DWH zu laden, ist aber in der Regel die Nutzung eines ETL-Tools, im Oracle Umfeld gerne des Oracle-Data-Integrators (ODI). Der ODI verfügt über eine Vielzahl von Lade-Adaptern, aber die besten Ergebnisse werden der Erfahrung nach mit der Nutzung von direkten Datenbank-Links erzielt, zumindest, wenn das Quellsystem auch eine Oracle-Datenbank verwendet.

Infrastructure-as-a-Service

Viele Anbieter von Cloud-Lösungen haben versucht, den Markt mit einer naheliegenden Strategie aufzurollen: Zunächst werden die Angebote mit überschaubarer Komplexität in die Cloud verlagert: Produkte, die mit möglichst wenig Anpassungen bei einer möglichst großen Kundenzahl erfolgreich einsatzbar sein könnten.

Auch Oracle hatte im ersten Schritt universell einsetzbare Produkte als Software-as-a-Service (SaaS) oder Platform-as-a-service (PaaS) anzubieten: HCM, BI-Apps, OTBI-Bausteine und BICS. Aber spätestens, wenn ein mehrschichtiges DWH mit selbstmodellierten Schichten, verschiedenen, auch noch nicht in der Cloud vorliegenden Quellen und angepassten ETL-Strecken, die diese konsolidieren aufgebaut werden soll, reichen die vorgefertigten Cloud-Angebote nicht mehr aus, und es bleibt nur der Ansatz Infrastructure-as-a-Service (IaaS) übrig. Hier wird zwar die Infrastruktur in der Cloud betrieben, aber deren Grenzschicht ist das Betriebssystem. Der Kunde erhält eigene virtuelle Maschinen, auf denen er dann die DWH-Komponenten selbst installieren und betreiben muss.

So gibt es zwar ein Produkt mit dem Namen „Oracle Data Integrator Cloud Service“, aber die Installationsanleitung umfasst sämtliche Schritte, die nötig sind, um das Repository, das Studio und die Agenten manuell auf der Kommandozeile in einer VM zu installieren.

In diesem Markt ist das Angebot von Oracle vergleichbar, wenn nicht austauschbar, mit dem anderer Anbieter wie AWS[7]. Es können zwar einige der ursprünglichen Ziele der Cloud-Migration realisiert werden, der Kunde muss keine eigene Hardware vorhalten und pflegen, aber der Aufwand für die Installation und Wartung der Software bleibt ihm nicht erspart.

Das Endresultat ist ein Gemischtwarenladen

Der Autor hat im vergangenen Jahr ein Cloud-DWH-Einführungsprojekt begleitet, das sämtliche hier diskutierten Aspekte umfasste und auch von Oracle konzipiert wurde.

Der Prototyp der neuen BI-Landschaft bestand aus Applikationen, die größtenteils bereits in der Cloud verwendet wurden: HCM, UCM, Field Service, Finance. ETL wurde mit dem ODI ausgeführt, der als IaaS-Komponente in der Oracle-Compute-Cloud installiert war. Die ODI Studio Clients liefen lokal oder auf einem Terminal-Server in der Compute-Cloud. Modelliert wurde mit einem lokal auf den Entwickler-PCs installierten SQL-Developer-Data-Modeler. Die Versionskontrolle erfolgte über Subversion, dessen Server wiederum in der Compute-Cloud beheimatet war. Die Datenbanken waren in einer Exadata-Cloud-Service-Quarter-Rack-Umgebung untergebracht. Als BI-Komponente diente BI-Analytics-Cloud-Service. Daten aus bestehenden On-Premise-Systemen wurden über einen ODI-Agenten geladen und teilweise in der Storage-Cloud abgelegt.

Eines der angetroffenen Probleme war, das selbst die Oracle-Cloud-Apps nicht immer über automatisiert benutzbare Schnittstellen verfügten, sondern darauf ausgelegt waren, Exporte als Dateien, die per Hand aus einer GUI erzeugt werden sollen, auszuführen. Werden solche Applikationen On-Premise betrieben, existiert meist die Möglichkeit, ETL direkt aus dem Datenmodell der Anwendung zu betreiben – bei den Cloud-Apps ist die Datensenke der Anwendung aber ein geschlossenes System.

Fazit

Die aktuell[8]bereitstehenden Oracle-Cloud-BI-Angebote sind in erster Linie dort erfolgreich einsetzbar, wo es um schnelle, abgrenzbare Lösungen geht. Ein Enterprise-Datawarehouse ist aber in den meisten Fällen kein einfach abgrenzbares Projekt. Der Gedanke, die komplette Business-Intelligence in die Cloud zu verlagern, ist für Entscheider sehr attraktiv, aber nicht immer zufriedenstellend umsetzbar. Hier muss selbst konzipiert, entwickelt und installiert werden. Bestehende Hardware in die Cloud zu verlagern, das funktioniert bei Oracle wie bei Amazon selbstverständlich. Ob die Komplexität der Schnittstellen der unterschiedlichen Cloud-Produkte untereinander am Ende des Tages einfacher zu handhaben ist als technische Schnittstellen von On-Premise betriebenen Systemen, bleibt hingegen abzuwarten. Die Gesamtsumme an Komplexität sowohl technischer als auch vertraglicher Art erhöht sich durch den Cloud-Einsatz sicher nicht.

Und es gibt noch einen anderen Aspekt: Ein strategischer Vorteil eines EDWH ist, einen konsolidierten und vollständigen Datenpool jederzeit im Zugriff zu haben. Erfolgreiche Unternehmen möchten sich natürlich auf ihr Kerngeschäft konzentrieren und keine Unsummen für Anschaffung und Betrieb im Zweifel schnell veralteter IT ausgeben. Aber die Verteilung der eigenen Daten auf eine Vielzahl von gemieteten Cloud-Anwendungen birgt die Gefahr, eben diesen Vorteil aufzugeben. Es droht eine Zersiedelung des Datenbestandes, in der die Übersicht und vor allem auch die Hoheit über die eigenen Daten verloren gehen kann. Und die Entscheidung, die eigene IT nur bei einem Cloud-Provider anzusiedeln, erhöht wiederum die Abhängigkeit von eben diesem Anbieter[9].

Alternativ gibt es ja auch noch die Möglichkeit, sich eine private Cloud auf Basis der Engineered-Systems oder Cloud-Machine aufzubauen.

 [1] Bei den Preisen werden im Folgenden stets die Listenpreise angeführt

[2] BICS ist aus der Code-Basis des OBIEE entstanden, einem um die Jahrtausendwende entstandenen und mehrmals weiterverkauften Produkt, dessen Code-Qualität Gerüchten zufolge nicht geeignet war, daraus ein echtes Cloud-Produkt zu erzeugen. Siehe auch: http://redpillanalytics.com/introducing-oracle-analytics-cloud/

[3] Oracle Cloud Version der Prozessormetrik bei der Lizenzberechnung (Oracle Core Factor)

[4] https://cloud.oracle.com/enUS/oac/pricing, Stand Mitte 2017

[5] Sehr schön ist auch der „Oracle Public Cloud Data Transfer Service“ zum Migrieren großer Datenmengen in die Cloud: Oracle schickt dem Kunden eine ZS4 Storage Appliance, auf die die Daten zwischengelagert und dann an Oracle zurückgeschickt werden.

[6] Etwa wegen der aktuellen Angriffsmöglichkeiten auf die Isolation virtueller Systeme (Spectre und Meltdown)

[7] Nichtsdestotrotz läuft die Datenbank in der Oracle Cloud einer Enkitec-Studie zufolge deutlich effektiver als bei vergleichbaren IaaS-Providern wie AWS. Siehe auch: https://www.accenture.com/t20161013T060358Z__w__/us-en/_acnmedia/PDF-34/Accenture-Oracle-Cloud-Performance-Test-October2016.pdf

[8] Das angesprochene Projekt fand im Frühjahr 2017 statt.

[9] IT-Infrastruktur in die Cloud zu verlagern, bedeutet, sie von Fremdanbietern betreiben zu lassen, und bedingt ein engeres Verhältnis als etwa ein Lizenzabkommen für Software. Ändert der Anbieter beispielsweise kurzfristig seine Geschäftsbedingungen in einer inakzeptablen Weise, kann es sehr schwer fallen, die Cloud wieder zu verlassen. Für Aufsehen hat in der Oracle-Community im Januar 2017 beispielsweise die Entscheidung gesorgt, überraschend die Core-Factor-Table zu Ungunsten von Nicht-Oracle-IaaS-Providern zu ändern. Siehe: https://oracle-base.com/articles/misc/oracle-databases-in-the-cloud

/von