Was ist der SAP Data Hub?

Vor kurzem war ich auf der TDWI Konferenz 2017 auf dem SAP Special Day, der unter dem Motto „Ihr Fahrplan zum Digital Enterprise“ stand.

Eigentlich hatte ich hier verschiedene Perspektiven zu den aktuellen Themen wie auch etwas Praxiserfahrungen erwartet. Doch dann hat Jan Bungert (Head of Database & Data Management Germany) folgende Folie in seinem Vortrag aufgebaut:

TDWI2017_1
SAP-Vorstellung einer datengetriebenen Architektur

Nun, klar, HANA kenne ich, SAP Vora, alles von Hadoop über S3 bis hin zu Tensorflow. Selbst mit Tensorflow konnte ich was anfangen. Aber was ist „SAP Data Hub“?

 

Beim erste Googlen bin ich bei SAP Hybris Data Hub gelandet. Nun, das hörte sich ja jetzt auch gar nicht so falsch an. Nur hat halt hier niemand was von Hybris gesagt. Auch sollte das noch gar nicht alles sein. In einer weiteren Präsentation wurde es mit einem Kundenbeispiel konkreter:

TDWI2017_2.PNG

Wie es aussieht, übernimmt hier der SAP Data Hub das ganze Datenmanagement, bis zur Anflanschung an BW/4HANA über SAP Vora.

Ein paar konkretere Screenshots gab es auch dazu:

TDWI2017_3
SAP Data Hub – Übersicht und Monitoring
TDWI2017_4
SAP Data Hub – Prüfung von Daten in Flatfile
TDWI2017_5
SAP Data Hub – Datenfluss-Modellierung

Wenn so ein Produkt bisher kaum auffindbar ist, dann gibt es zwei Möglichkeiten:

-> Das Produkt ist neu.

-> Das Produkt hat einen neuen Namen.

Wie geschrieben, kommt man bei „SAP Data Hub“ eher bei einem SAP Hybris-Produkt raus, das so heißt. Dieses gibt es jedoch, soweit für mich nachvollziehbar, seit Jahren. Der SAP Data Hub wird aber laut PAM zum Q3/2017 allgemein verfügbar. Die Hilfe ist momentan verfügbar für Release 1.0 SPS0.

Aus der SAP-Hilfe kann man entnehmen, dass das System auf HANA XS läuft und SAP Vora, Spark und HANA Smart Data Integration unterstützt. Dies zeigt so auch der Architekturüberblick:

SAP_DATA_HUB_Architecture
SAP Data Hub – Architektur

 

Denke ich daran, dass SAP beim letzten DSAG AK-Treffen für BI & Analytics im Kontext von SAP Leonardo auch noch eine neue Big Data Strategie aufgezeigt hat, dann zeigt sich doch, das SAP sich hier stark mit neuen eigenen Produkten engagiert, während man sich gleichzeitig mit Open Source-Komponenten ergänzt. Dort war zwar noch nicht von SAP Data Hub die rede, aber es bleibt zu hoffen, dass dies nachher aus einer Hand gesteuert wird.

Auf jeden Fall wird es nicht langweilig. Vielleicht auch nicht einfacher. Wir werden sehen, was kommuniziert wird, sobald die Marketingmaschine dazu anläuft.

BI – Die alten Regeln gelten nicht mehr

Vor Kurzem veröffentlichte Wayne W. Eckerson (WE) einen Artikel darüber, wie sich die Welt im BI-Umfeld verändert (hat). Er listet einige Erkenntnisse von seiner letzten TDWI-Konferenz und versucht auch dies zu erklären. Ich (SA) versuche einmal, ausgewählte Aussagen wieder zu geben und auf meine Situation zu übersetzen.

  • “There is no need for a dimensional model.”
    • WE: Heutige BI-Werkzeuge sind so gut, dass schlechtes Design kompensiert wird.
    • SA: InfoCubes sind in einen HANA-System nicht mehr notwendig. Bei einer Modellierung in HANA muss man nur bedingt auf Performance achten und Werkzeuge wie Lumira benötigen nichtmal In-Memory sondern nutzen SAP IQ als spaltenbasierte Datenbank um performance durch den Endanwender Millionen von Datensätzen verarbeiten zu können.
  • “There is no need for ETL tools.”
    • WE: nutze Spark für ETL in der Cloud oder in Hadoop-Umgebungen
    • SA: Ebenfalls Lumira hat hier schon gezeigt, wie auch recht komplexe Transformationen sowie die Anbindung an fast beliebige Datenquellen schnell und einfach möglich sind. Mit Agile Data Preparation hat die SAP sogar ein komplett eigenes Werkzeug dafür auf den Markt gebracht.
  • “You don’t need a relational database.”
    • WE: Du kannst alle deine Data Science-Aufgaben ins S3 und mit Spark erledigen.
    • SA: Zumindest meine ersten Erfahrungen mit BO Cloud legen nahe, dass Cloud doch noch die eine oder andere Kinderkrankheit hat. Allerdings garantiert Amazon 99,999999999 % Ausfallsicherheit. Das muss man intern erstmal leisten. Das man für Data Science nicht unbedingt eine relationale Datenbank benötigt, ist aber glaube ich wirklich nichts Neues. Gerade wenn es um unstrukturierte Daten geht und um extrem große Datenmengen sind andere Ansätze gefragt.
  • “Code is not the enemy.”
    • WE:  Schreibe ETL-Code in Spark und verwalte ihn in Git Hub; es ist befreiend
    • SA: Git scheint heute im HANA oder SAP Cloud-Umfeld schon der neue Standard zu sein. In einer superagilen Welt verwundert der Erfolg von Git Hub daher nicht.
  •  “We don’t move data.”
    • WE: Wir bauen logische views in Hadoop für analytische Anwendungsfälle
    • SA: Auch HANA und vor allem S/4HANA setzen auf virtuelle Datenmodelle, welche für analytische Zwecke optimiert sind. Mit Core Data Services wird aktuell von SAP eine neue Grundlage geschaffen, dieses Konzept in der Breite umzusetzen.
  •  “We design from physical to logical, not logical to physical.”
    • WE: Wir laden Rohdaten in das System, dann bauen wir logische views für jeden Anwendungsfall; wir modellieren nicht zuerst.
    • SA: Passt zum vorherigen Punkt und unterstützt und erweitert diesen. In einem S/4HANA liegen die Daten schon vor, jedoch nicht unbedingt für analytische Zwecke. Erst durch das virtuelle Datenmodell bereite ich die „Rohdaten“ auf. In einem NoSQL-System oder Data Lake lege ich Daten ab, wie Sie kommen. In zum Teil völlig verschiedenen Schemata für die Sie ursprünglich gedacht waren. Wie ich diese für die Analyse im Sinne von Data Science benötige, kann ich vorab noch nicht sagen. Dabei kann man jedoch noch gut zu den traditionellen Ansätzen differenzieren, bei denen der Analysezweck im vorhinein recht klar ist (z. B. Analyse von Umsatzdaten nach verschiedenen Dimensionen). Schema-on-Read ist nichts, was der Fachbereich mal nebenher macht, weil er eine Fragestellung beantwortet haben möchte. Und dann gibt es auch noch agile Ansätze wie Data Vault.
  • “We design for secondary use cases, not the primary one, which has a limited shelf life.”
    • WE: Wir laden Daten und speichern diese auf Detailebene, so dass wir diese für neue Einsatzzwecke verwenden können, sobald der Bedarf dafür aufkommt.
    • SA: Die Aggregation von Daten geschieht immer für einen bestimmten Zweck. Information geht dabei verloren. Natürlich sollte es für ein HANA-System in der SAP-Welt kein Problem sein, sehr granulare Daten zu speichern. Jedoch kann dies sehr teuer sein. Mit Ansätzen wie Dynamic Tiering und Nearline Storage hat SAP Ansätze, das zu handhaben. Eine Alternative für BW könnten Ansätze wie SparrowBI sein.
  • “Your data architecture is as important or more than your data model.”
    • WE: Wie die Daten im Dateisystem abgelegt werden ist wichtig. Sonst wird man mit den Daten wenig anfangen können.
    • SA: Themen wie Datenqualität, Metadatenmanagement und Data-Lineage spielen hier eine wichtige Rolle, soll der Data Lake nicht zum Datensumpf werden.
  • “Architecture is way more important when you move to the cloud.”
    • WE: Wenn du deine Cloud nicht richtig konfigurierst, wird es evtl. teurer als gedacht.
    • SA: Mit Cloud-Konzepten herrscht weniger Erfahrung als in der On-Premise-Welt. Die leichte Verfügbarkeit der Ressourcen verführt dazu, erstmal großzügig damit umzugehen. Evtl. muss hier neu und eher elastisch gedacht werden.
  • “Applications are dependent on analytics.”
    • WE: Wir benötigen DevOps um die Entwicklung von Anwendungen und Analytic zu koordinieren.
    • SA: S/4HANA setzt massiv auf Hybrid Transactional Analytical Processing (HTAP) und verbindet immer mehr operative Anwendungen mit analytischen Funktionen.
  • “Either you evolve and change, or die.”
    • WE: Sei offen gegenüber Hadoop, Spark und der Cloud.
    • SA: Das sich SAP gegenüber den Open Source-Technologien wie Hadoop und Spark z. B. im Rahmen von HANA Vora öffnet ist ein wichtiges Zeichen. Bei Cloud versucht sich SAP als Vorreiter und setzt darauf wie auf HANA und zeigt damit auch die Richtung.

Eckerson schließt mit den Worten „The only constant is change, and now is the time to change! „. Aber Veränderung ist kein Projekt oder etwas, was man jetzt mal angehen sollte. Um konkurrenzfähig zu bleiben muss Veränderung zum integralen Bestandteil der Unternehmenskultur werden.

SAP’s Wege zum Data Warehouse

Es ist immer wieder interessant, SAP dabei zuzuschauen, wie man aktuell z. B. im BI-Frontendbereich auf Vereinfachung (Simplification) setzt, andererseits im Bereich Data Warehouse einen Strauß bunter Lösungen entstehen lässt, der kaum noch überschaubar ist. Im Folgenden ein wenig die Geschichte, soweit diese für mich nachvollziehbar ist.

SAP BW erblickte 1997 mit dem Release 1.2A als Business Information Warehouse das Licht der Welt. Nach Jahren der Weiterentwicklung hat die SAP 2016 dem Produkt SAP BW ein Ende gesetzt, nur um es unter dem Namen SAP BW/4HANA neu auferstehen zu lassen. Aber das ist nicht die ganze Geschichte. Bereits mit dem Kauf von BusinessObjects und Sybase ließ sich bereits eine komplett vom SAP BW eigenständige BI- und Data Warehouse-Umgebung schaffen. Mit dem Aufkommen von HANA (als damals High-Performance ANalytical Applicance) war schnell klar, dass hier auch etwas neues entsteht. Und so bewirbt die SAP das HANA Data Warehouse, welches bereits 2013 von Thomas Zurek angedeutet wurde.

SAP BW stellen jedoch nicht die Ursprünge des Data Warehouses von SAP da. Bereits vorher war dies bei SAP vielfältig ein Thema. Geht man heute im SAP ERP durch den Customizing-Leitfaden, so findet man nach wie vor beispielsweise im Logistik-Umfeld das Logistics Data Warehouse.

Wenn man bei SAP also von Data Warehouse redet, muss man sich wirklich erstmal Fragen, welches man hier meint.

 

Pre-SAP BW (ERP DWH-Ansätze)

Ja auch heute noch stößt man bei vielen Unternehmen auf die verschiedenen Ausprägungen, welche noch deutlich weiter als das SAP BW zurückreichen. Da gibt es das Logistik-Informationssystem (LIS), welches für verschiedene Logistik-Module vorkonfigurierte, verdichtete Datenebenen bietet und quasi ein embedded Realtime-Reporting mit einer oft akzeptablen Performance liefert. Mit dem bereits erwähnten Logistic Data Warehouse, war (und ist) es möglich eigene Verdichtungsebenen und Fortschreibungsregeln zu definieren um dann flexibel darauf auswerten zu können. Wer BW-Releases vor 7.0 kennt und sich die Fortschreibung im LIS einmal angeschaut hat, wird überrascht gewesen sein und danach wissen, woher das Fortschreibungskonzept dafür stammte.

Auch vom CO-PA kennt man verschiedene Verdichtungsebenen und Auswertungswerkzeuge. Das Ganze gipfelt im EIS/FIS – also im Führungsinformationssystem, welches schon den Ansatz hat, sich auch den verschiedenen Informationssystemen oder auch externen Daten eine Datenbasis auszuwerten, welche flexibel ausgewertet werden kann.

Auch wenn hier Teile wie gesagt durchaus in vielen Unternehmen noch aktiv sind, so wurde doch irgendwann aus sicherlich vielfältigen und nachvollziehbaren Gründen (Performance, Systemlast, Flexibilität, …) entschieden einen Schritt weiter zu gehen. Dieser Schritt war SAP BW.

 

SAP BW

Wie anfangs erwähnt, hat das SAP BW seinen Anfang etwa 1997 oder 1998 mit dem veröffentlichen Release 1.2A. Das Projekt startete als “Reporting Server”, was möglicherweise die Grundlage für die bekannten RS*-Transaktionen gelegt haben dürfte.

Der Sprung zum Release 2.0 kam im August 2000 mit 2.0B, bei dem z. B. das Operational Data Store seinen Weg ins BW gefunden hat. Eine gewisse Erfolgsgeschichte, haben sich daraus doch 3 Varianten und zuletzt das Advanced DSO entwickelt. Im Dezember 2000 folgte bereits 2.1C.

Mit dem Release 3.0A wechselte der Name von Business Information Warehouse mit dem Akronym BIW zu noch kürzer BW.

Ein großer Sprung ereignete sich dann wieder März 2004. Damals kam das Thema Netweaver auf, und das BW-Release 3.5 war Teil von SAP Netweaver 2004.

Vermutlich am 06.06.2006 gab es ein einen großen Releasesprung. Zuerst unter dem Namen SAP NetWeaver 2014s BI capabilities (so wurde mir das damals von SAP gesagt 😉 ) sollte dies das Release SAP BI 7.0 werden. Eine kurze Periode, in der die SAP dem BW den Namen Business Intelligence verpasste. Kurz deshalb, weil SAP 2007 ein Übernahmeangebot für BusinessObjects machte und 2008 diese vollendete. BI wanderte vom BW zu BusinessObjects und das BW bekam mit dem Release 7.3 offizell wieder seine Bezeichnung BW zurück.

Noch ein wichtiger Meilenstein kam mit dem 7.0-Release. Der BWA (Business Warehouse Accelerator), damals noch unter dem Namen BIA (Business Intelligence Accelerator) wurde released. Der erste Ausflug in die In-Memory Welt für SAP BI/BW und der Vorläufer von HANA.

Mit dem Release 7.3 gab es neben der Rückkehr zum Namen BW auch noch zum nächsten großen Sprung. Mit SAP BW powered by SAP HANA. Mit SAP HANA hatte SAP Ende 2010 einen großen Schritt gewagt und heute, knapp 6 Jahre später fast ihre gesamt Produktstrategie darauf ausgerichtet. Nur etwa 1 Jahr später ging SAP BW 7.3 SP5 in den Ramp-Up für HANA.

Im März 2014 folgte das Release SAP BW 7.4. Dieses Release sollte die möglichkeiten von HANA deutlich besser ausnutzen und neue Features auf Basis der HANA-Technologie liefern. Als Enabler für das Logical Data Warehouse sollte es alle Daten als In-Memory Data Fabric in einen gemeinsam Kontext stellen.

Im Herbst 2015 wurde SAP BW 7.5 vorgestellt. Es soll das letzte seiner Art sein. Das Release wurde in 2 Modi vorgestellt. SAP BW 7.5 powered by SAP HANA und SAP BW 7.5, edition for HANA. Mit dem Modus “edition for HANA” leitete die SAP den nächsten Schritt ein. Ein SAP BW, welches nur noch die neuen, HANA-optimierten Objekte einsetzt und die bisher eingesetzten Modellierungsobjekte wie InfoCubes, Datastore-Objekt, InfoSet, MultiProvider usw. obsolet macht. Neben der Modellierung verändern sich auch auch die Schnittstellentechnologien sowie die Modellierungsfläche, welche für neue Objekte von Anfang an in der Eclipse-Umgebung zu finden war.

 

SAP BW/4HANA

Am 07.09.2016 wurde BW/4HANA offiziell vorgestellt bzw. Verfügbar gemacht. Erste Informationen dazu wurden ab 31.08.2016 bekannt gegeben.

Mit BW/4HANA wurde das SAP BW auf Wartung gesetzt und es wird kein Neues Release mehr geben. BW/4HANA gilt als neues Produkt. Als logischer, jedoch nicht rechtlicher Nachfolger. Das lässt sich leicht darauf erklären, hier eine Menge Code z. B. für die bisherigen Modellierungsobjekte sowie für die BEx-Suite entfernt wurde.

Eine gute Annäherung und Vorstellung, was BW/4HANA bedeutet, bekommt man über die rund um den Startzeitpunkt veröffentlichten Blogs:

Thomas Zurek:

Neil McGovern

Marc Bernard

 

SAP HANA Data Warehouse

Zum SAP HANA Data Warehouse habe ich bereits ein wenig geschrieben und möchte im Wesentlichen darauf und auf die Blogs von Thomas Zurek verweisen:

Thomas Zurek:

Sowie zusammenfassende Blog-Einträge von mir:

 

SAP (Sybase) IQ Data Warehouse

2010 hat SAP Sybase übernommen, welches im Bereich BI/Datenmanagement Lösungen wie Sybase IQ, den PowerDesigner und eine Lösung für Complex Event Processing beisteuerte.

SAP IQ ist im BW-Umfeld am ehesten als Datenbank für Nearline-Storage (NLS) bekannt. Die Datenbank ist spaltenbasiert und auf sehr große Datenmengen (Petabyte). Zuletzt 2014 hat SAP IQ im Zusammenspiel mit SAP HANA einen neuen Weltrekord für das weltgrößte Data Warehouse mit 12,1 Petabyte aufgestellt.

Des weiteren dürfte SAP IQ im Frontendbereich bei SAP Lumira eine gewisse Bekanntheit haben, sollte man sich fragen, wo eigentlich die ganzen Daten gespeichert und verarbeitet werden, welche in die Lumira Desktop-Version integriert werden.

Schaut man sich die lose gekoppelte Umgebung des HANA DWH an, dann liegt der Gedanke nahe, dass man hier eigentlich eine HANA auch gegen eine SAP IQ austauschen könnte. Das scheint aber bei der SAP kein populäres Konzept zu sein.

Eher findet man die Datenbank zur Entlastung von HANA als schneller Nearline-Storage, welcher im Multi-Temperature-Konzept der SAP den Bereich der kalten Daten (cold) abdecken soll.

Alternativ zu IQ als NLS kommt auch immer öfters Hadoop ins Spiel. Vor allem, wenn man über Big Data spricht. Mit HANA Vora hat die SAP hier ja sogar einen eigenen Ansatz vorgestellt.

 

SAP & Data Warehouse vs. Data Lake

Ich erinnere mich gut an einige Gespräche mit dem Fachbereich, bei denen mein Gegenüber der Meinung war, Big Data ist, wenn Excel nicht mehr ausreicht. Und dafür hätte man dann ja z. B. SAP BW.

Interessanterweise ist das auch oft das Bild, welches man durchaus bekommen kann. Oft werden Begriffe undifferenziert verwendet und Schlagwörter verwendet wie „wenn wir HANA haben, dann sind alle unsere Probleme gelöst“.

Gut das selbst die SAP mittlerweile erkannt hat, das HANA evtl. doch nicht die Eierlegende Wollmilchsau ist und an der einen oder anderen Stelle auf ergänzende Technologien angewiesen ist. HANA Vora (seit 03/2016 GA) ist so ein Beispiel.

Aber schon zuvor hat sich SAP gemeinsam mit Hortonworks an einer Big Data Reference Architecture versucht. Und wirbt gerne auch direkt bei den CIO’s mit ihrem Angebot, Big Data in den Griff zu bekommen.

Nun, wenn das DWH schon für Big Data steht, wofür benötigt man eigentlich ein HANA Vora oder gar ein Data Lake? Im folgenden möchte ich die beiden Konzepte etwas besser voneinander abgrenzen. Zuvor jedoch soll noch erwähnt sein, dass  DATAVERSITY einen empfehlenswerten Übersichtsartikel zu dem Thema bietet, welcher mich auch dazu inspiriert hat, hier einmal zu schauen, wo SAP sich dabei sieht..

Die erste Erwähnung und Prägung des Begriffs „Data Lake“ stammt wohl vom Chief Technology Officer von Pentaho:

If you think of a datamart as a store of bottled water – cleansed and packaged and structured for easy consumption – the data lake is a large body of water in a more natural state. The contents of the data lake stream in from a source to fill the lake, and various users of the lake can come to examine, dive in, or take samples.

– James Dixon, CTO Pentaho
Quelle: https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/

SAP hat aus meiner Sicht hier für kompakte 2 1/2 Minuten gar nicht schlecht ihre Sichtweise für die Bedeutung eines Data Lakes dargestellt.

Wie bekommt man den nun ein Gefühl, wie sich Data Lake tatsächlich von Data Warehouse abgrenzt?

DWHvsDL

Die dargestellten Aspekte zeigen gut, dass ein Data Lake und ein Data Warehouse durchaus sich ergänzenden Ansätze darstellen. Nur weil in den letzten Jahren neue Datenquellen relevanter und verwertbarer geworden sind, sind bisherige Ansätze nicht obsolet. Jedoch muss man auch sehen, dass, obwohl gewisse Ansätze und Zielsetzungen recht ähnlich sind, der Skill und die Herangehensweise doch sehr unterschiedlich sein können.

In ihrer Roadmap zeigt die SAP, dass Sie hier eine gemeinsame technologische Architektur mit einer zentralen HANA-Plattform sieht, in der in einer absehbaren Zukunft auch das SAP BW im HANA Data Warehouse aufgehen wird:

SAP HANA DW-Roadmap

Dabei hat eben auch HANA Vora seinen Platz und wird als verbindender und integrierter Bestandteil zwischen Hadoop und HANA in dieser zukünftigen SAP HANA Data Warehousing Plattform dargestellt:

HANA_DW_Plattform

Die Zeit wird zeigen ob diese doch verschiedenen Ansätze tatsächlich sinnvoll kombiniert werden können und evtl. das eine Konzept in dem anderen aufgeht. Oder ob die Ansätze nur eine theoretische Möglichkeit darstellen, mit welcher man schön Marketing machen kann, welche so jedoch nicht Realität werden wird.

openSAP: Big Data with SAP HANA Vora

Und weiter geht es auf openSAP mit einen interessanten Kurs im Bereich Analytics. Am 06. September 2016 startet „Big Data with SAP HANA Vora„.

openSAP_HANAVora.PNG

Sicherlich nicht der erste Kurs zum Thema HANA. Konkret zu Big Data gab es jedoch bisher nur „Driving Business Results with Big Data“ vor einem guten Jahr und vielleicht „Text Analytics with SAP HANA Platform“ vom Januar diesen Jahres. In weniger guter Erinnerung ist mir geblieben, dass es damals bei „Driving Business REsults with Big Data“ ziemlich viel Werbung bzgl. SAP Services und RDS gab. Positiv war die Möglichkeit direkt an einem HANA-System in der Cloud auszuprobieren. Auch der Vortrag von Steve Lukas ist mir sehr gut in Erinnerung geblieben. Damals habe ich sogar ein paar Tweets dazu gemacht.

Nun gut, diesmal geht es über 3 Wochen um das Thema HANA Vora, Spark, Hadoop.

Die SAP Big Data-Lösung, welche erst seit 15.03.2016 allgemein verfügbar ist, zeigt den Willen der SAP auch im Bereich Big Data mitzumischen. War das bisher bei SAP jedoch immer einen HANA-Thema, zeigt SAP mit der Lösung, das HANA alleine eben doch nicht immer ausreicht um wirklich BIG data zu handhaben.

Der Kurs ist auf drei Wochen aufgeteilt:

  • Week 1: Overview: SAP HANA Vora
  • Week 2: SAP HANA Vora Data Modeling Tool
  • Week 3: Development in SAP HANA Vora

und adressiert:

  • Data Scientists
  • Anwendungsentwickler im HANA-Umfeld
  • Technische Business Analysten & Berater

Ein gewisses Wissen über Hadoop und Spark wird zwar vorausgesetzt, und zeigt, dass der Kurs wohl sehr technisch wird. Jedoch denke ich , selbst für den klassischen SAP BW-Berater, der evtl. noch nicht mal auf HANA ist, ist der Kurs einen Blick wert.

Ein guter Start, für den der sich evtl. etwas vorbereiten möchte, findet sich hier im SCN.

Big Data

Big Data beschreibt ein Phänomen vor dem Hintergrund stetig zunehmender Datenmengen durch Social Media und die digitale Transformation der Wirtschaft (Internet of Things, Industrie 4.0) im Zusammenspiel mit stetig zunehmender Rechnerkapazität sowie Speichermöglichkeiten (Cloud Computing).

Big Data ist ein Hype und aktuell im Gartner Hype Cycle bereits am Höhepunkt der Erwartungen vorbei in Richtung Desillusionierung unterwegs.

Big Data lässt sich lt. BITKOM durch die folgenden vier Aspekte beschreiben:

  • Volume / Datenmenge (Terrabyte, Petabyte, Exabyte, …)
  • Variety / Datenvielfalt (strukturiert, semi-strukturiert, unstrukturiert)
  • Velocity / Geschwindigkeit, in der neue Daten entstehen und verarbeitet werden
  • Analytics (Data Mining, Predictive Analytics, Visualisierung)

Typischerweise wird hier von den drei V’s gesprochen, wobei immer wieder neue V’s auftauchen wie z. B. Veracity (Richtigkeit, Genauigkeit der Daten). Durch Analytics wird dann der Nutzenaspekt hinzugefügt.

Die großen IT-Unternehmen wie Amazon, Google oder Facebook zeigen eindrucksvoll die Möglichkeiten, mit datengetriebenen Geschäftsmodellen erfolgreich zu sein. Durch die zunehmende Verfügbarkeit und Reife neuer Technologien (NoSQL-Datenbanken, Hadoop, In-Memory-Technologie, …), sowie erhoffter Nutzenpotentiale, versuchen immer mehr Unternehmen aus internen und externen Daten Wettbewerbsvorteile zu generieren.

Big Data erweitert die bisherigen Ansätze in den Bereichen Business Intelligence und Data Mining und stellt für jeden der drei V’s eine Reihe von Technologien zur Verfügung, um diese Aspekte handhabbar zu machen.