PDF Herunterladen

Autor:

Michael Falck
COO
michael.falck@relexsolutions.com

Marko Nikula
Chief Architect
marko.nikula@relexsolutions.com

Unternehmen und Wirtschaftsanalytiker gleichermaßen verwenden den Begriff Big Data seit nunmehr über 10 Jahren, in unterschiedlichsten Zusammenhängen. Es ist nicht leicht, präzise Definitionen aufzutun. Das McKinsey Global Institute (MGI) hat sich, neben anderen, auf die folgende festgelegt:

„Big Data bezeichnet ein Datenvolumen, dessen Erfassung, Speicherung, Verwaltung und Analyse von herkömmlicher Datenbanksoftware nicht bewältigt werden kann.“

Leider ist dies eine derart breitgefächerte Definition, dass sie dadurch beinahe schon bedeutungslos wird.

Wenn es bei Big Data lediglich um die Kapazität und Leistungsfähigkeit von Computern ginge, läge die gängigste Antwort klar auf der Hand: Man wartet, bis der CFO des Unternehmens den Erwerb von mehr Server-Speicherplatz freigibt und Big Data funktioniert wie von alleine. Aber mehr ist nicht notwendigerweise besser, wie jeder Erwachsene bestätigen wird, der einem sechsjährigen Kind unbegrenzt viel Eiscreme gibt.

Lassen Sie uns den Hype kurz vergessen. Big Data ist weder Wunderwaffe noch Universallösung. Aber es gibt unumstrittene Vorteile, nicht nur in den in diesem Zusammenhang zumeist besprochenen Geschäftsbereichen Marketing oder dem Onlinehandel. Gewaltige Vorteile können auch eher traditionelle Geschäftsprozesse aus Big Data ziehen. Wie das Supply Chain Management zum Beispiel:

  1. Erhöhte Datentransparenz und schnellerer Zugang zu Daten und Berechnungen,
  2. schnellere und detailliertere Leistungskontrolle und Identifizierung von Ausnahmen,
  3. schnellere und exaktere Entscheidungsfindung anhand automatisierter Algorithmen sowie
  4.  schnellere und exaktere Auswertung und Analyse.

Nach dem McKinsey Global Institute kann das Hinzuziehen von Big Data-Lösungen im Supply Chain Management die erzielten Gewinnmargen um 5% – 35% steigern.
Ferner existiert die Technologie bereits, die derart große Datenmengen verarbeitet, analysiert und dadurch erst für Ihr Unternehmen relevant macht. Und sollten Sie bereit sein, Anbietern etablierter Altsysteme, deren hochpreisigen Premiumangeboten und ihrem „Markenwert“ aus dem Weg zu gehen, ist die Technologie, die Sie benötigen sogar überraschend erschwinglich. Auch für Tier 2 und kleinere Unternehmen.

Big Data-Stärken ausbauen mit der Technologie von RELEX

Der Einzelhandel generiert seit jeher Informationen in großen Mengen. Im digitalen Zeitalter hat sich diese Menge gar vervielfacht und wurde zudem stetig zugänglicher. RELEXs Technologie bedient sich fortgeschrittener Algorithmen und Analysen, die diese Datenmengen in eine starke Informationsquelle verwandeln können. Dadurch werden Bedarfsprognosen präziser, man erhält dynamische Momentaufnahmen in Echtzeit und eine unverzügliche Visualisierung des enormen Einflusses, den Entscheidungen im Supply Chain Management auf Ihr Unternehmen haben.

Die Schlüsselelemente der Technologie von RELEX werden in folgender Abbildung veranschaulicht:

Daten werden spaltenförmig angelegt und gespeichert. Dies ermöglicht eine extreme Komprimierung durch den Einsatz bereichsspezifischer Datensatzmuster. Dadurch kann die gesamte Datenbank In-Memory, also im Arbeitsspeicher betrieben werden. Dies, in Verbindung mit der Tatsache, dass alle zeitintensiven Prozesse parallel ablaufen, führt zu extrem schnellen Berechnungen und starker Performance.

Abbildung 1: Daten werden spaltenförmig angelegt und gespeichert. Dies ermöglicht eine extreme Komprimierung durch den Einsatz bereichsspezifischer Datensatzmuster. Dadurch kann die gesamte Datenbank In-Memory, also im Arbeitsspeicher betrieben werden. Dies, in Verbindung mit der Tatsache, dass alle zeitintensiven Prozesse parallel ablaufen, führt zu extrem schnellen Berechnungen und starker Performance.

Spaltenorientierte Datenbank

Datenbanktabellen sind im Wesentlichen in zwei Dimensionen aufgebaut: Spalten und Zeilen. Computerspeicher wie die Festplatte, haben nur eine Dimension- in etwa so wie die aus der Mode gekommene lineare Musikkassette. Dies bedeutet, dass alle Daten zunächst einheitlich in einen eindimensionalen Datenstrom angeordnet werden müssen, bevor sie im Speicher oder auf der Festplatte abgelegt werden können.

Es gibt zwei grundlegende Optionen, um eine Datenbank einheitlich in einen eindimensionalen Datenstrom anzuordnen: Das Zeilen- und das Spaltenlayout. Herkömmliche relationale Datenbänke verwenden das Zeilenlayout.

Zeilenlayout bedeutet, dass die Zeilen der Datenbanktabelle im Informationsfluss eine nach der anderen geschrieben werden: Jede Zeile in ihrer Vollständigkeit mit all ihren dazugehörigen Spalten. Für Anwendungen, die normalerweise alle oder die meisten Spalten benötigen, ist dies sinnvoll. Wenn eine Tabelle beispielsweise persönliche Daten erfasst, wird die Anwendung höchstwahrscheinlich Namen, Geschlecht, Geburtsjahr, Adresse etc. für jede Person beinhalten. Wenn der Datensatz, der einer Person zugeordnet ist, von der Datenbank des Arbeitsspeichers oder der Festplatte abgerufen wird, dann erscheinen alle Datensätze nebeneinander.

Im Spaltenlayout wird jede Spalte des Datenflusses der Reihe nach geschrieben. Also zunächst alle Zeilen von Spalte 1, dann alle Zeilen von Spalte 2 und so weiter. Dies ist gemeinhin sinnvoll für Analyseanwendungen, bei denen eine Tabelle bis zu hunderte Spalten beinhalten kann, von denen meist nur wenige gleichzeitig abgerufen werden müssen. Aber diejenigen, die abgerufen werden müssen, werden von einer Vielzahl von Zeilen gelesen. Wenn das Zeilenlayout verwendet wird – mit unserer Kassettenanalogie im Hinterkopf – bedeutet dies beim Lesen einer einzigen Spalte, dass jede Spalte jeder Zeile zunächst abgescannt werden muss. Verwendet man hingegen das Spaltenlayout, können die Daten für lediglich eine einzige Spalte abgerufen werden, ohne mit aufwändigem Abscannen der gesamten Daten Zeit zu verschwenden.

Extreme Komprimierung

Ein weiterer Vorteil der Verwendung des spaltenförmigen Layouts ist, dass Werte desselben Datentyps nebeneinander auf der Festplatte oder dem Arbeitsspeicher hinterlegt werden. Im Zeilenlayout können aneinander angrenzende Werte verschiedene Datentypen repräsentieren (z.B. der Name einer Person und ihr Geburtsjahr). Dies macht die Komprimierung weitaus ineffizienter.

Bei RELEX bestehen die meisten Daten aus Abverkauf, Bestellung, Lieferung, Inventarliste, Bedarfsvorausschau etc. Ein Großteil der Werte sind kleine, ganze Zahlen und viele der Werte ändern sich nicht sehr häufig. Ein Beispiel hierfür wäre die Inventarliste eines sich langsam drehenden Produktes. Der Wert bleibt oft für einige Tage unverändert. Die Kenntnis rund um die verschiedenen Typen der gespeicherten Werte ermöglicht eine umso extremere Datenkomprimierung. Der Komprimierungsfaktor beträgt in etwa das Zehnfache dessen, was mit dem Zeilenlayout erreicht werden kann. In anderen Worten: RELEX ist eine benutzerdefinierte Datenbank, die bei herkömmlichen relationalen Datenbänken 100 GB Speicherplatz benötigen würde, aber effektiv nur 10 GB benötigt. Der drastisch verringerte Speicherplatz wird auch in einer um ein Vielfaches erhöhten Leistungsfähigkeit reflektiert.

In-Memory Kalkulation

Die Komprimierung ermöglicht, dass alle Daten im Arbeitsspeicher abgelegt werden können. Dies bedeutet, dass Suchanfragen der Datenbank im RAM des Computers ablaufen, im Gegensatz zur Datenabfrage, die ihre Information zunächst von physischen Festplatten beziehen muss. Dies vermindert erneut drastisch die Anfrageantwortzeit und spiegelt sich ebenfalls in vielfach erhöhter Leistungsfähigkeit wider.

Parallelisierung

RELEX’ innere Architektur, die aus mehreren Threads besteht, ermöglicht alle zeitintensiven Arbeitsgänge parallel laufen zu lassen, was erneut zu einer spürbar verbesserten Performance führt. Datenladezeiten, Auswertungsmöglichkeiten der Suchanfragen und Kalkulationen sind durch die simultane Verwendung mehrerer Prozessoren beschleunigt.

Die Entwicklung der RELEX-Lösung

RELEX beinhaltet ein integriertes spezialangefertigtes Datenbanksystem. In unserem Sektor ist dies recht unüblich. Seit dem Aufstieg relationaler Datenbanken in den 1970er Jahren musste das vorherrschende Model einer Unternehmenssoftware beides anbieten: Eine Datenbank und die Anwendung als zwei getrennte Softwarelösungen. Meist wurden diese sogar von unterschiedlichen Anbietern bezogen. Die Datenbank fungiert als eine Art Server, an den sich die Anwendungssoftware koppeln lässt. Um zu verstehen, warum sich RELEX dazu entschlossen hat, ein benutzerdefiniertes Datenbanksystem zu programmieren, müssen zunächst die Einschränkungen, die ein Client-Server-Modell mit sich bringt, nachvollzogen werden.

Anwendungsgrenzen von Client-Server-Modellen für Datenbanken

Diese Grenzen lassen sich am einfachsten durch folgende Analogie erläutern: Stellen Sie sich vor, der Datenbankserver ist die Archivabteilung eines großen Unternehmens. Die Anwendungssoftware ist die Abteilung für Business Development. Diese benötigt Informationen aus der Archivabteilung. Beide Abteilungen liegen in unterschiedlichen Gebäuden. Und den Mitarbeitern der Abteilung für Business Development ist der Zutritt zum Gebäude der Archivabteilung nicht gestattet. Nun müssen die Mitarbeiter in Briefen schildern, was sie benötigen. Die Mitarbeiter der Archivabteilung lesen diese Briefe, finden die benötigten Informationen im Archiv und schicken diese zurück an den Absender.

Die Mitarbeiter der Archivabteilung verstehen nichts von den Daten in ihrem Archiv. Für sie sind es lediglich Zahlen. Dies bedeutet, dass die Kollegen der Business Development-Abteilung ihre Anfragen sehr präzise formulieren müssen. Sie könnten sich vorstellen, ein Mitarbeiter im Business Development schreibt in seinem Brief an das Unternehmensarchiv: „Bitte gehen Sie durch alle Einträge in Aktenschrank X und berechnen Sie die Gesamtsumme von Y. Aber bitte ignorieren Sie alle Einträge, bei denen „A“ den Wert von „Z“ ergibt.“ In der Datenbankwelt werden diese Briefe zum Beziehen von Informationen Suchanfrage genannt. Sie werden gewöhnlich in SQL geschrieben, der Programmiersprache der Spezialisten. Die Antwortschreiben der Mitarbeiter der Archivabteilung müssen dann entweder kompakte Zusammenfassungen einiger der Daten des Archivs sein (so wie Summe, Durchschnitt, Minimum oder Maximum) oder eine Kopie einer stark begrenzten Anzahl von Einträgen. Wir sollten annehmen, dass das Archiv eine derart große Anzahl von Einträgen enthält, dass es absolut unmöglich wäre, sie alle zu kopieren und zu verschicken. Daher müssen die Kollegen der Business Development Abteilung ihre Anfragen höchst präzise formulieren, um die benötigten Antworten zu erhalten.

SQL Erweiterungen

Um die Analogie noch etwas weiterzuentwickeln: Stellen Sie sich nun vor, dass die Mitarbeiter im Business Development hin und wieder sehr komplizierte Berechnungen jener Daten vornehmen müssen, die sich im Archiv befinden. Die Berechnung ist derart komplex, dass sie im Informationsanfragebrief an das Archiv nicht erläutert werden kann. Anstatt die Angestellten im Archiv die Berechnungen vornehmen zu lassen um dann lediglich die Ergebnisse zu erhalten, müssen sie nun Kopien aller benötigten Einträge anfordern, um die Berechnungen eigenhändig durchzuführen.

Datenbankserver erlauben für gewöhnlich, die Beschränkung der SQL-Sprache über einen Erweiterungsmechanismus zu umgehen, wie zum Beispiel benutzerdefinierte Funktionen oder bereits gespeicherte Abläufe. Diese Erweiterungen sind häufig in der anbieterspezifischen Sprache geschrieben. Das Endergebnis ist, dass ein Teil der Datenverarbeitung, die eigentlich von der Anwendungssoftware erledigt werden würde, nun über den Datenbankserver läuft. Dies ermöglicht, dass die Verarbeitung näher an der Datenquelle stattfindet und somit die Menge an Daten, die zwischen Anwendungssoftware und Datenbank hin- und hergeschoben werden müssten, drastisch minimiert werden kann. In unserer Analogie bedeutete dies, die Angestellten der Archivabteilung auszubilden und ihnen auch kompliziertere Datenanfragen näher zu bringen. Sie vielleicht sogar mit Tafeln und Notebooks auszustatten, damit sie Zwischenergebnisse notieren können.

Benutzerdefinierte Funktionen und gespeicherte Abfrageverfahren haben das Potential, die Gesamteffizienz von Software, die sich eines Datenbankservers bedient, enorm zu erhöhen. Aber auch diese haben ihre Einschränkungen. Die nutzerspezifische Sprache ist kein adäquates Pendant zu einer vollwertigen Programmiersprache.

Auch die möglichen Datenzugriffsmuster sind eingeschränkt. In unserer Analogie könnten Sie sich dies mit folgender Datenabfrage vorstellen: „Oh, und falls der Eintrag ein Produkt betrifft, das ein anderes Produkt im Sortiment ersetzt, dann gehen Sie bitte zu Aktenschrank Q und holen Sie den entsprechenden Eintrag aus Aktenschrank F hervor. Aber nur wenn…“. Es gibt also immer Geschäftsprozesse, die von den Erweiterungsmechanismen nicht völlig flüssig wiedergegeben und ausgedrückt werden können.

Engpässe beseitigen

Als nächstes stellen wir uns etwas wirklich Radikales vor: Wir geben den Mitarbeitern im Business Development vollen Zugriff auf die Archive. Wir könnten sogar so weit gehen, ihren Arbeitsplatz in das Archiv zu verlegen, sodass sie jederzeit von dort aus arbeiten können. Sobald sie nun Informationen aus den Aktenschränken benötigen, können sie sich einfach von ihrem Platz erheben und finden, was sie brauchen. Kein detailliertes Aufschreiben ihrer Anfrage in einer Sprache mit beschränktem Vokabular und kein Kopieren und Hin- und Herschicken von Daten mehr.

Das ist im Wesentlichen, wie RELEX’ Software funktioniert. Die Datenbank und die Anwendung ist eine einzelne, nahtlose Software. Jeder leistungskritische Arbeitsprozess kann immer auf dem niedrigstmöglichen Kapazitätslevel durchgeführt werden, indem der Datenfluss durch den „digitalen Feuerwehrschlauch“ geleitet wird, anstatt durch einen Strohhalm. Darüber hinaus können Daten bei der Speicherung derart organisiert werden, dass auftretende Fragen bereits von vornherein mit einkalkuliert werden. Dies führt zu höchstmöglicher Leistung.

Wenn das Modell einer integrierten Datenbank derart großartige Vorteile mit sich bringt, wieso verfolgt dann nicht jedes Softwareunternehmen diesen Ansatz? Ein Grund könnte sein, dass der Aufbau und die Entwicklung eines benutzerdefinierten Datenbanksystems gleichermaßen anspruchsvoll wie zeitintensiv ist. In den meisten Fällen wiegen die Vorteile die Risiken und die benötigte Arbeitszeit nicht auf. Ein serienmäßig produzierter Standard-Datenbankserver kann meist eine „genügend gute“ Leistung bieten.

Wenn wir nun also über das überdurchschnittlich hohe Leistungsniveau von RELEX’ Systemen sprechen, was genau ist damit gemeint? Werfen wir einen Blick auf einige Kennzahlen. Zum Beispiel ist RELEX in der Lage

  • etwa 5 Milliarden Vorhersagen in einer Stunde zu treffen
  • etwa 1 Milliarde Transaktionen pro Stunde hochzuladen
  • 1 Millionen Produkte innerhalb von einer Sekunde nach Lieferbarkeit zu sortieren, von gut nach schlecht oder umgekehrt
  • Anfragen durchzuführen, wie z.B. „finde innerhalb von einer Minute alle Produkte die in den letzten 30 Tagen mehr als 100 EUR Umsatz erzielten und exportiere die Daten in ein csv-Dokument mit einer Millionen Zeilen.

Ist die RELEX-Technologie einzigartig?

Es gibt ähnliche Komponenten in anderen Big Data-Lösungen. Viele der großen Anbieter von Datenlagern ziehen ihren Nutzen aus spaltenbasierter Technologie. HP Vertica, Sybase und Teradata Columnar, um nur einige Beispiele zu nennen. Es gibt auch viele spezialangefertigte Lösungen wie SAP HANA und Oracle Exadata, die Datenbank, Speicher und Verarbeitung integrieren. Das Einzigartige an der RELEX-Lösung ist, dass wir von Anfang an den Anwendungsbereich, den geläufigsten Anwendungsfall und das Profil der typischsten Kundendaten vor unserem geistigen Auge hatten und sie genau nach diesen Kriterien erschaffen haben.

Viele der Unternehmen die Big Data Lösungen anbieten, konzentrieren sich auf die Technologie und stellen dabei nicht sicher, dass die Lösung auch den Anforderungen und Ansprüchen reeller Unternehmer gerecht werden muss. Das Ergebnis ist dann, dass wir viele technisch elegante Lösungen haben – die Probleme zu den Lösungen jedoch erst gefunden werden müssen. Normalerweise wollen Geschäftsleute unkomplizierte, geradlinige Lösungen für ihre spezifischen Probleme und keine allgemeingültige Standardlösung. Dies führt dann allzu oft dazu, dass Unternehmer eigenhändig technische Lösungen für ihre speziellen Bedürfnisse entwickeln müssen. Wir bieten unseren Kunden Lösungen an, die ihnen wahrhaft dabei helfen, ihre Geschäftsentwicklung zu optimieren. Wir unterstützen sie dabei, spezielle Hürden und Herausforderungen zu meistern, wie etwa individuelle Bedarfsvorhersagen oder die Sortimentsgestaltung.

Big Data – Großes Fazit

Big Data bietet eine wahre Gelegenheit. Viele der großen Entscheidungen sind Managemententscheidungen und keine technischen. So verhält es sich auch mit technologischen Errungenschaften. Man muss wissen was man braucht, um die richtige Entscheidung zu treffen. Und oft weiß man erst hinterher, was man zu Beginn eines Projektes gebraucht hätte. So ist das Leben.

RELEX bietet praktische, praxisorientierte und realistische Lösungen. Seit der Gründung wurde RELEX designt, um enorme Datenmengen zu bewältigen. Geradlinig, zweckmäßig und sinnvoll.

Unsere Arbeitsweise, gemeinsam mit Ihnen unser System in das Ihre zu integrieren, wird nicht von Anfang an alle Antworten auf Ihre Fragen liefern. Die Flexibilität unseres Systems erlaubt uns jedoch, an jeder Kreuzung neu zu entscheiden und unsere Route gegebenenfalls anzupassen. Und dem nicht genug, werden Sie nach einiger Zeit selbst in der Lage sein, diese Anpassungen eigenhändig vorzunehmen.

Die Technologie, die es Ihnen ermöglicht, enorme Datenmengen zu bewältigen, existiert bereits. Doch RELEX Systeme ändern sich und wachsen mit Ihnen mit. Typischerweise holen unsere Kunden drei Monate nach finaler Einführung ihr Investitionskapital in unser System wieder herein. Die Entscheidung, mit uns zusammen vorwärtszugehen, sollte demnach eine leichte sein.