Corporate (Big) Data 2015 – Eine Bestandsaufnahme

Wir schreiben das Jahr 2015 nach Christus. Alle relevanten Unternehmensdaten sind durch SAP Systeme besetzt. Alle Unternehmensdaten? Nein! Eine wachsende Zahl von Datenquellen hört nicht auf Widerstand zu leisten 😉
Dieser Blog ist der Versuch einer Bestandsaufnahme. Was ist BigData? Wie nahm diese Entwicklung ihren Anfang und welche Systeme gibt es der Datenflut Herr zu werden? Wie ist die Situation in den Unternehmen heute? Warum werden Daten, die typischerweise nicht in einem Datawarehouse gespeichert sind immer interessanter? Was bietet SAP zur Interaktion mit diesen Daten?

FIVE1 Bits wie Sterne im Universum

1997 hatte Professor Michael Lesk, Inhaber des Lehrstuhls für Informationswissenschaften an der Rutgers University die These aufgestellt, dass alle Informationen die jemals auf der Welt festgehalten wurden sich zu 12 Exabytes subsummieren. Er betrachtete geschriebene Texte, Bilder, Filme, Radioübertragungen, Musik und Telefonie.
Die Universität von Kalifornien veröffentlichte 2014 eine von EMC gesponserte Studie wonach in 2012 2,8 Zettabytes und in 2013 4,4 Zettabytes Informationen erzeugt wurden. Vergleicht man die Zahlen aus 1997 und 2014 direkt miteinander, so stellt man fest, dass bis zu diesem Zeitpunkt 99,8 Prozent der gespeicherten Informationen in den letzten beiden Jahren produziert wurde. Unterstellt man nach Moore’s law, dass die Informationsmenge sich jedes Jahr verdoppelt, werden wir 2020 so viele Bits gespeichert haben, wie es Sterne im Universum gibt. 44 Zettabytes oder 44 Trillionen Gigabytes.

Neben dem enormen Wachstum der Datenmenge hat sich auch die Zahl der möglichen Datenquellen drastisch erhöht. Neben Daten aus Facebook, LinkedIn und Twitter zählen auch Informationen aus Blogs und Foren, Daten aus dem Webshop, Emails, Office- und pdf-Dateien dazu. Beispielsweise werden Vereinbarungen mit Kunden und Partnern per E-Mail getroffen, Geschäftsberichte und Verträge sind in Textverarbeitungs- oder PDF-Dateien gespeichert, Listen und Aufstellungen sind in Tabellenblättern erfasst und Absprachen über technische Details liegen in Präsentationen oder digitalen Zeichnungen vor. Ebenso Bilder, Audio- und Video-Material. Aber auch Maschinendaten aus der Produktion (BDE), RFID-Funkchip-Erfassungen und sonstige Sensordaten an Gebäuden, Fahrzeugen oder Gütern. Diese Vielfalt unterschiedlichster Datenquellen zieht eine Vielzahl von unterschiedlichsten Datenstrukturen nach sich.

Sind Daten(-quellen) auf Grund ihrer Beschaffenheit nicht, oder nicht optimal geeignet um in einem klassischen Datawarehouse gespeichert zu werden, so subsummiert man diese unter dem Begriff BigData. BigData beschreibt die Entwicklung immer mehr Daten in Auswertungen einfließen zu lassen, so dass Berechnungen immer schneller erfolgen müssen um immer bessere, weil fundiertere Entscheidungen treffen zu können. Gartner (Anbieter von Marktforschung und Analyse in der Technologie-Industrie) beschrieb schon 2001 diese Entwicklung mit Hilfe der drei Vs. Volume, Velocity und Variety. Die Herausforderungen die sich Unternehmen in der Datenverarbeitung demnach stellen müssen sind:

  • Der exponentiellen Anstieg der Datenmenge (Volume),
  • die Geschwindigkeit (Velocity) in welcher die Daten anfallen und
  • die Vielfalt (Variety) der Datenstrukturen.

Diese Beschreibung hat sich als de-facto Standard zur Definition des Begriffs „Big Data“ entwickelt.

Erste Ansätze einen Nutzen aus den für relationale Datenbanken schwer zu verarbeitenden Daten zu ziehen gab es bereits in den 1970er Jahren.

Erste Ansätze einen Nutzen aus den für relationale Datenbanken schwer zu verarbeitenden Daten zu ziehen gab es bereits in den 1970er Jahren. Daraus hervor gingen eine Reihe alternativer Ansätze die man unter dem Begriff der NoSQL (sprich „not only SQL“) Datenbanken zusammen fassen kann. Hier gelang 2004 ein entscheidender Durchbruch. Google stellte das so genannte Map/Reduce Framework vor, welches in der Lage war auch sehr große Datenmengen effizient zu verarbeiten. Die Verarbeitungslogik wird in diesem Ansatz stets zu den Daten transferiert – und nicht wie traditionell üblich umgekehrt (bspw. SAP ABAP Applikationsserver). Durch Kombination des Frameworks mit einer verteilter Datenablage auf mehreren Systemen („BigTable“) in einem eigenen Filesystem (GFS) gelang es Google Daten bis in den Petabyte-Bereich mit vergleichsweise günstiger Hardware („Commodity-Hardware“) zu speichern.

Die Apache Foundation entwickelte im Jahr 2005, nur ein Jahr nach Googles Vorstellung von Map-Reduce, federführend durch Yahoo, ein Framework namens Hadoop. Hadoop besteht im Kern aus drei Komponenten, die aber auch unabhängig voneinander betrieben werden könnten. Das Hadoop Distributed File System (HDFS) ermöglicht, ähnlich wie Googles BigTable, eine verteilte Datenablage über mehrere Systeme (Yahoo betrieb 2013 ein HDFS Cluster mit 365 Petabyte. ). Die Hadoop Plattform ist also enorm skalierbar – und das auf Basis von günstiger Hardware. Das Hadoop Map-Reduce Framework übernimmt die effiziente, verteilte Verarbeitung. YARN (Yet Another Resource Negotiator) verwaltet alle im Cluster verfügbaren Ressourcen wie RAM, CPU oder Speicherplatz. Es erweitert Hadoop um die Fähigkeit auch mit anderen Programmiermodellen neben Map-Reduce zusammen arbeiten zu können. Daneben gibt es weitere Komponenten die Hadoop sinnvoll erweitern.

Apache ZooKeeper dient der (verteilten) Konfiguration von verteilten Systemen. Zookeeper ermöglicht Hochverfügbarkeit durch redundante Services. Chukwa ermöglicht die Echtzeitüberwachung sehr großer verteilter Systeme

Die Apache Hive Datawarehouse Software stellt einen Mechanismus zur Strukturierung der im HDFS gespeicherten Informationen zur Verfügung. Mittels HiveQL, einer an SQL angelehnten Abfragesprache können diese dann abgefragt werden. Gleichzeitig erlaubt Hive aber auch die native map/reduce Programmierung.

HBase ist eine skalierbare, einfache Datenbank zur Verwaltung sehr großer Datenmengen innerhalb eines Hadoop-Clusters. Die HBase-Datenstruktur ist besonders für Daten geeignet, die selten verändert, dafür aber sehr häufig ergänzt werden. So lassen sich Milliarden von Zeilen verteilt und effizient verwalten.

Diese Aufzählung ließe sich noch eine Weile fortsetzen. Die vorgenannten Projekte sind nicht mehr als Beispiele für Open Source Initiativen im BigData Umfeld. Dennoch ist die Auswahl nicht ganz zufällig. Alle genannten Projekte haben ihre Marktreife bereits bei Unternehmen wie LinkedIn, Facebook, Google etc. bewiesen. Mit anderen Worten: Die Technik ist den Kinderschuhen bereits entwachsen. Apache Hadoop hat sich seit vielen Jahren im produktiven Betrieb bewährt. Kreditkarten-Anbieter waren bspw. bereits 2010 in der Lage nur auf Basis unseres Kaufverhaltens Ehescheidungen vorauszusagen. Was glauben Sie, wozu diese heute mit „BigData-Datenquellen“ in der Lage sind?

FIVE1 BigData 2015

Die Realität in den allermeisten Unternehmen sieht heute jedoch (noch) ganz anders aus. Ein Enterprise Datawarehouse bildet das Rückgrat des Informationsbedarfs der meisten Unternehmen. Für einen großen Teil der operativen Daten bildet es den Single Point of Truth (falls das bei Ihnen noch nicht so ist, dann rufen Sie uns am besten gleich an). Zu den häufigsten Datenquellen zählen neben ERP-Systemen auch CRM- und SRM-Systeme. So liefert das Datawarehouse Antworten auf bekannte, wiederkehrende Fragen in hoher Datenqualität. Dafür müssen Daten die in ein Datawarehouse übertragen werden für das Zielsystem aufbereitet sein. D.h. (Ausgangs-) Daten und (Ziel-) Datenmodell müssen in Einklang gebracht werden. Mit Hilfe von ETL-Verfahren (Extraktion, Transformation, Load) werden sie dann qualitätsgesichert und im Hinblick auf andere Datenquellen so weit wie möglich harmonisiert.

forrester-adoption-is-the-only-option-hadoop

Gleichzeitig wächst der Druck der Unternehmen, sich mit BigData ernsthaft auseinander setzen zu müssen spürbar. Je mehr wir alle online gehen und je weiter die physische Welt mit der digitalen Welt verschmilzt, desto schneller werden bestehende IT Infrastrukturen im Bezug auf eines der drei Vs an ihre Grenzen stoßen. Immer dann haben wir einen potentiellen BigData Use-Case. Immer dann, wenn eine neue Anforderung aus Ihrem Fachbereich nicht mehr mit Hilfe der bestehenden Datenbasis beantwortet werden kann, sollten Sie prüfen ob die neu zu beschaffenden Daten mit der vorhandenen Technik (Kosten-) effizient analysiert werden können.

Wir werden in Zukunft Informationen aus völlig neue Daten ziehen (müssen). Wir werden diese Daten mit Informationen aus unserem existierenden Datenbestand auf bisher nicht für möglich gehaltene Art und Weise kombinieren, um neue Erkenntnisse aus ihnen zu ziehen. Anwender müssen sich (wieder) mit Data Mining beschäftigen, um ihrem Unternehmen einen Vorsprung zu verschaffen. Bevorzugte Einsatzgebiete sind Auswertungen von Kunden- und Produktdaten für Stornoanalysen oder die Neukundengewinnung, die Suche nach Cross- und Upselling-Optionen oder ein gezieltes Kampagnen-Management. Nie zuvor konnten wir soviel über unseren Markt, unseren Kunden, unsere Lieferanten und unsere Konkurrenten erfahren. So lassen sich nicht nur Entscheidungen verbessern, sondern auch Geschäftsprozesse dramatisch beschleunigen, optimieren und automatisieren. Stellen Sie sich für Ihre Branche, für Ihr Unternehmen die Möglichkeiten vor, die sich daraus ergeben.
Noch können Sie Ihrer Konkurrenz einen Schritt voraus sein, wenn Sie sich auf diese Themen einlassen. Tuen Sie es nicht, riskieren Sie selbst ins Hintertreffen zu geraten. Und das schneller als Sie vielleicht heute noch glauben. Natürlich bedeutet dies nicht Ihre bestehenden Systeme abzuschalten. Vielmehr ist die Hadoop-Plattform eine äußerst interessante Möglichkeit ihre heute Systemlandschaft und ihre relationale Datenbank intelligent zu ergänzen. Hadoop ist nicht länger optional, sagt Forrester und hat Recht.

Auch SAP sieht die genannten BigData Technologien (mittlerweile) als integralen Bestandteil einer zukünftigen BI Strategie. Natürlich in Ergänzung zu den eigenen Produkten, sprich SAP HANA.

Insbesondere mit Hilfe des Toolsets SAP Data Services (ab Version 4.2) können Informationen aus dem Hadoop-Ecosystem nach HANA übertragen werden. Die SAP HANA ist so in der Lage mittels Apache Hive verteilte Queries direkt auf dem Hadoop Filesystem auszuführen. Neben Hive unterstützt SAP Pig, MapReduce push down und Text data processing.

Auch SAP Lumira und andere SAP BI Tools können sich über Hive direkt mit Hadoop verbinden. So kann man im jüngsten Release von SAP Lumira auf Rohdaten in Hadoop zugreifen. Durch so genanntes „Data wrangling“ können diese Rohdaten dann weiter aufbereitet und somit erst wirklich nutzbar gemacht werden. Zum „Data wrangling“ zählt man das Anwenden von Algorithmen, das Trainieren von statistischen Modellen, das Parsen der Daten, die grafische Aufbereitung, Aggregation usw.

Fassen wir also zusammen. BigData ist keine Zukunftsmusik mehr, sondern real. SAP HANA ist weder die Voraussetzung für BigData, noch die Antwort. In-Memory ist auch nicht das Patentrezept für BigData – und SAP HANA nicht die einzige In-Memory Technik auf der Welt. Auch Hadoop ist per se keine Wunderwaffe zur Verarbeitung riesiger Datenmengen. Technik bleibt Mittel zum Zweck. Dennoch eröffnet die Kombination aus Hadoop und HANA großartige Möglichkeiten. Großartige Dinge lassen sich aber auch in der Kombination des SAP BW mit Hadoop, oder gänzlich ohne SAP Tool erzielen. Nur ohne Hadoop wird es wohl nicht mehr (lange) gehen.

Was Sie wirklich für Ihren BigData Use-Case brauchen, welcher Technikmix für Sie das beste Kosten/Nutzen Verhältnis aufweist und was in Ihrem Szenario den größten Mehrwert bietet, muss im Einzelfall beleuchtet werden. Machen Sie nicht einfach BigData, sondern fokussieren Sie auf den Nutzen! Gerne würden wir Sie bei Ihrer BigData Strategie unterstützen. Sprechen Sie mit uns. Wir evaluieren mit Ihnen die Möglichkeiten die sich aus Ihren Daten für Ihr Unternehmen eröffnen.

Getagged mit: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*