Hana & Hadoop – Dreamteam für Big Data

SAP-Anwender, die einmal mit Hana arbeiten durften, reagieren meist begeistert von den Möglichkeiten und der sagenhaften Performance. Am liebsten würden sie möglichst viele Daten in Hana speichern und direkt „in-memory“ verarbeiten.

Leider hat die Sache einen Haken: Je mehr Hana genutzt wird, umso teurer wird es und umso mehr Ressourcen werden benötigt. Hinzu kommt eine generelle Einschränkung von Hana:

Der relationale Datenspeicher eignet sich zwar ideal für strukturierte Daten, bei unstrukturierten Daten wie Logs, Social-Media-Feeds, Dokumenten oder Bildern wird es aber schwierig. Genau dort hat aber Hadoop seine Stärken.

Eine Plattform wie Cloudera Enterprise ermöglicht die wirtschaftliche und flexible Speicherung, Verarbeitung und Analyse von Big Data, hat jedoch keine vergleichbare Funktionalität und Performance beim Hosting relationaler Workloads, etwa der Verarbeitung von Online-Transaktionen (OLTP) in einer Datenbank oder einem Data Warehouse.

Das ist alles nicht neu und viele Unternehmen betreiben in der Tat beide Plattformen nebeneinander, separat und getrennt voneinander, um die jeweiligen Stärken für sich zu nutzen.

Dabei wird aber oft übersehen, dass eine integrierte Architektur beider Lösungen das Beste aus beiden Welten kombinieren und gleichzeitig die Nachteile kompensieren kann.

Cloudera Enterprise kann dabei große Mengen unterschiedlichster Daten aufnehmen und den Ressourcenhunger von SAP Hana begrenzen. Insbesondere in folgenden Bereichen ergänzt es Hana ideal:

1. Datenmengen und -vielfalt: Traditionelle Datenmanagementsysteme stoßen hier an ihre Grenzen. Unternehmen müssen wegen der Kosten und technischen Komplexität Kompromisse eingehen und entscheiden, welche Daten sie behalten und welche nicht.Hinzu kommt, dass unstrukturierte Daten schwierig zu modellieren und zu speichern sind. Cloudera Enterprise eignet sich ideal dazu, sämtliche Daten einer Organisation bereitzustellen und zu speichern.
2. Ressourcennutzung: In einer integrierten Architektur können Prozesse ausgelagert werden. Hana kann die frei gewordenen Ressourcen dann nutzen, um Abfragen und Anwendungen bestmöglich zu bedienen.Am häufigsten werden ressourcenintensive ETL-Workloads ausgelagert, es ist aber auch möglich, Abfragen und Analysen an Cloudera Enterprise zu übertragen, vor allem bei sehr großen Datenmengen.
3. Kapazitätsprobleme: Es kann von Vorteil sein, Daten aus Hana auszulagern, beispielsweise historische Daten oder solche von geringem Wert. Damit wird es möglich, Analysen über längere Zeiträume zu fahren, ohne dass die vollständige Datenhistorie in Hana vorgehalten werden muss. Weniger Last auf Hana-Servern bedeutet automatisch auch geringere Kosten.
4. Analyse- und Abfrage-Ressourcen: In einer integrierten Architektur kann Hana die schnelle Verarbeitung von strukturierten und Online-Daten übernehmen, dabei kann es sich beispielsweise um OLTP, Data Warehousing oder OLAP (Online Analytical Processing) handeln.Cloudera Enterprise bietet ergänzend dazu die Möglichkeit, große Mengen unstrukturierter Online- und Offline-Daten zu verarbeiten. Organisationen können für sich abwägen, welche Verteilung unter Kosten- und Performance-Gesichtspunkten am meisten Sinn ergibt.

In einer integrierten Architektur können dabei gegenüber einem reinen Hana-Betrieb die Kosten spürbar sinken. Unternehmen können mit einfachen Tasks wie der Auslagerung von ETL-Workloads starten und sich Schritt für Schritt in eine kombinierte Analyse-Plattform vortasten.

Es ist über die Auslagerung einzelner Prozesse hinaus sogar möglich, Daten aus Hana abzuziehen und sie für Analysen an Cloudera Enterprise zu übertragen. Das kann sinnvoll sein, um Daten von unbekanntem Wert zu untersuchen, ohne dafür die teuren Ressourcen von Hana einzusetzen, die dann wiederum für wichtigere Workloads genutzt werden können.

Unter dem berühmten Strich bleibt festzuhalten, dass sich hier ein echtes Dreamteam abzeichnet: Unternehmen müssen sich nicht für eine Plattform entscheiden, in der Kombination bekommen sie das Beste aus beiden Welten.