Hyperkonvergenz: Mehr Intelligenz für das Rechenzentrum

Wer heute dafür verantwortlich ist, die IT-Infrastruktur seines Unternehmens oder einer Organisation zu steuern, der steht vor einer ganzen Reihe Herausforderungen: Skalierbar, beliebig flexibel und mit möglichst kurzer „time-to-market“ für neue Services – so sollte es sein. Die Anforderungen an Kapazität und Rechenpower können sich schnell ändern. Mit steigenden Nutzerzahlen oder neuen Anwendungen, die geliefert werden sollen. Weder Kunden noch Management haben Zeit oder Verständnis dafür, dass neue Dienste wegen neuer Hardwareanforderungen nur langsam oder mit langem Vorlauf ausgerollt werden können.

Unternehmen wollen deshalb schnell und flexibel auf neue Anforderungen und Produkterweiterungen reagieren können. Dabei kommt in der Praxis häufig sehr heterogene Infrastruktur zum Einsatz: On-Premise-Systeme vor Ort, externe Data Center und Cloud-Lösungen müssen zuverlässig, nahtlos und insbesondere auch sicher die Services bereit stellen, die Kunden oder Mitarbeiter nutzen. Wichtig dabei: die Storage- und Computing-Kapazität sollte flexibel skalierbar sein und sich auch kurzfristig geänderten Anforderungen und Prioritäten anpassen können. Zum Beispiel: Innerhalb von kurzer Zeit deutlich mehr virtuelle Desktopsysteme für User bereit stellen.

Smarte Software für Rechenzentren

Der beste Weg für den CIO und die IT-Abteilung, diese neuen Herausforderungen zu lösen, sind „Hyperkonvergenz“-Systeme. Dabei handelt es sich um kombinierte Knoten für Storage und Computing-Leistung im Rechenzentrum, die dank smarter Software beliebig erweitert oder ausgetauscht werden können. Hierbei handelt es sich um SDS-Systeme („Software defined Storage“) – die Speicherkapazität und Rechenleistung der einzelnen Systeme wird von der Software smart abstrahiert und gebündelt.

Das Unternehmen Cisco zeigt, wie die Zukunft im Rechenzentrum aussehen wird: die neue Plattform HyperFlex setzt genau hier an. Wie der Name andeutet, bietet HyperFlex eine Hyperkonvergenz-Plattform für das Rechenzentrum auf Basis von Intel® Xeon® Prozessoren*. Der Kern ist hier die Software, die auf dem eigenen Filesystem „HX Data Platform“ aufsetzt. Damit erweitern Kunden ihr bestehendes System schnell und einfach. Diese Hyperkonvergenz-Lösung ist darauf ausgelegt, nicht als Silo parallel zu bereits bestehender Infrastruktur zu stehen, sondern zu einem Teil der bestehenden Hard- und Software zu werden.

Denn die Verwaltung von HyperFlex-Knoten ist in Ciscos bestehendem UCS Management integriert. So dauert es nur wenige Minuten, bis neue Nodes zu einem System hinzugefügt sind. Nach wenigen Klicks sind die zusätzlichen Knoten installiert, konfiguriert, provisioniert und somit live in Betrieb. Besonders hilfreich für dynamische Unternehmen: HyperFlex macht es sehr einfach möglich, im Betrieb selektiv Storage-, RAM-c oder Computing-Kapazität zu erweitern – unabhängig voneinander.  Sollten Knoten ausfallen, verkraftet das System dies ohne Ausfall oder Datenverlust.

Weiterführende Informationen zu den Cisco HyperFlex Systemen finden Sie mit einem Klick hier.

Dieser Sponsored Post entstand in Zusammenarbeit mit Cisco & Intel.

*Intel, the Intel logo, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation in the U.S. and/or other countries.

Intelligence Gathering

Beispiele für Data Science stehen häufig im Kontext von innovativen Internet-StartUps, die mit entsprechenden Methoden individuelle Kundenbedürfnisse in Erfahrung bringen. Es gibt jedoch auch eine Dunkle Seite der Macht, auf die ich nachfolgend über ein Brainstorming eingehen möchte.

Was ist Intelligence Gathering?

Unter Intelligence Gathering wird jegliche legale und illegale Beschaffung von wettbewerbsentscheidenden Informationen verstanden, von traditioneller Marktforschung bis hin zur Wirtschaftsspionage. Unter Intelligence Gathering fallen die Informationsbeschaffung und die Auswertung, wobei nicht zwangsläufig elektronische Beschaffungs- und Auswertungsszenarien gemeint sind, auch wenn diese den Großteil der relevanten Informationsbeschaffung ausmachen dürften.

Welche Data Science Methoden kommen zum Einsatz?

Alle. Unter dem Oberbegriff von Intelligence Gathering fallen die vielfältigsten Motive der Informationsgewinnung um Wettbewerbsvorteile zu erzielen. Genutzt werden statistische Datenanalysen, Process Mining, Predictive Analytics bis hin zu Deep Learning Netzen. Viele Einsatzzwecke bedingen ein gutes Data Engineering vorab, da Daten erstmal gesammelt, häufig in großen Mengen gespeichert und verknüpft werden müssen. Data Scraping, das Absammeln von Daten aus Dokumenten und von Internetseiten, kommt dabei häufig zum Einsatz. Dabei werden manchmal auch Grenzen nationaler Gesetze überschritten, wenn z. B. über die Umgehung von Sicherheitsmaßnahmen (z. B. IP-Sperren, CAPTCHA, bis hin zum Passwortschutz) unberechtigte Zugriffe auf Daten erfolgen.

Welche Daten werden beispielsweise analysiert?

  • Social-Media-Daten
  • Freie und kommerzielle Kontaktdatenbanken
  • Internationale Finanzdaten (Stichwort: SWIFT)
  • Import-Export-Daten (Stichworte: PIERS, AMS)
  • Daten über Telefonie und Internetverkehr (Sitchwort: Vorratsdatenspeicherung)
  • Positionsdaten (z. B. via GPS, IPs, Funkzellen, WLAN-Mapping)
  • Daten über den weltweiten Reiseverkehr (Stichworte: CRS, GDS, PNR, APIS)

Das volle Potenzial der Daten entfaltet sich – wie jeder Data Scientist weiß – erst durch sinnvolle Verknüpfung.

Welche Insights sind beispielsweise üblich? Und welche darüber hinaus möglich?

Übliche Einblicke sind beispielsweise die Beziehungsnetze eines Unternehmens, aus denen sich wiederum alle wichtigen Kunden, Lieferanten, Mitarbeiter und sonstigen Stakeholder ableiten lassen. Es können tatsächliche Verkaufs- und Einkaufskonditionen der fremden Unternehmen ermittelt werden. Im Sinne von Wissen ist Macht können solche Informationen für eigene Verhandlungen mit Kunden, Lieferanten oder Investoren zum Vorteil genutzt werden. Häufiges Erkenntnisziel ist ferner, welche Mitarbeiter im Unternehmen tatsächliche Entscheider sind, welche beruflichen und persönlichen Vorlieben diese haben. Dies ist auch für das gezielte Abwerben von Technologieexperten möglich.

Darüber hinaus können dolose Handlungen wie etwa Bestechung oder Unterschlagung identifiziert werden. Beispielsweise gab es mehrere öffentlich bekannt gewordene Aufdeckungen von Bestechungsfällen bei der Vergabe von Großprojekten, die US-amerikanische Nachrichtendienste auf anderen Kontinenten aufgedeckt haben (z. B. der Thomson-Alcatel-Konzern Korruptionsfall in Brasilien). Die US-Politik konnte dadurch eine Neuvergabe der Projekte an US-amerikanische Unternehmen erreichen.

Welche Akteure nutzen diese Methoden der Informationsgewinnung?

Die Spitzenakteure sind Nachrichtendienste wie beispielsweise der BND (Deutschland), die CIA (USA) und die NSA (USA).  In öffentlichen Diskussionen und Skandalen ebenfalls im Rampenlicht stehende Geheimdienste sind solche aus Frankreich, Großbritanien, Russland und China. Diese und andere nationale Nachrichtendienste analysieren Daten aus öffentlich zugänglichen Systemen, infiltrieren aber auch gezielt oder ungezielt fremde Computernetzwerke. Die Nachrichtendienste analysieren Daten in unterschiedlichsten Formen, neben Metadaten von z. B. Telefonaten und E-Mails auch umfangreiche Textinformationen, Bild-/Videomaterial sowie IT-Netzwerkverkehr. Der weltweit eingeschlagene Weg zur vernetzten Welt (Internet of Things) wird Intelligence Gathering weiter beflügeln.

[box]Anmerkung: Open Data Analytics

Eine Informationsquelle, die selbst von Experten häufig unterschätzt wird, ist die Möglichkeit der Gewinnung von Erkenntnissen über Märkte, Branchen und Unternehmen durch die Auswertung von öffentlich zugänglichen Informationen, die in gedruckter oder elektronischer Form in frei zugänglichen Open-Data-Datenbanken und Internetplattformen verfügbar gemacht werden, aber beispielsweise auch über Radio, Zeitungen, Journalen oder über teilweise frei zugängliche kommerzielle Datenbanken.[/box]

Die Nachrichtendienste analysieren Daten, um nationale Gefahren möglichst frühzeitig erkennen zu können. Längst ist jedoch bekannt, dass alle Nachrichtendienste zumindest auf internationaler Ebene auch der Wirtschaftsspionage dienen, ja sogar von Regierungen und Konzernen direkt dazu beauftragt werden.

Internet-Giganten wie Google, Baidu, Microsoft (Bing.com) oder Facebook haben Intelligence Gathering, häufig aber einfach als Big Data oder als Datenkrake bezeichnet, zu einem Hauptgeschäftszweck gemacht und sind nicht weit von der Mächtigkeit der Nachrichtendienste entfernt, in einigen Bereichen diesen vermutlich sogar deutlich überlegen (und zur Kooperation mit diesen gezwungen).

Finanzdienstleister wie Versicherungen und Investmentbanker nutzen Intelligence Gathering zur Reduzierung ihrer Geschäftsrisiken. Weitere Akteure sind traditionelle Industrieunternehmen, die auf einen Wettbewerbsvorteil durch Intelligence Methoden abzielen.

Nachfolgend beschränke ich mich weitgehend auf Intelligence Gathering für traditionelle Industrieunternehmen:

competitive-intelligence-wirtschaftsspionage

Industrielle Marktforschung

Die Industrielle Marktforschung ist eine auf bestimmte Branchen, Produkt- oder Kundengruppen spezialisierte Marktforschung die vor allem auf die Analyse des Kundenverhaltens abzielt. Diese kann auf vielen Wegen, beispielsweise durch gezielte Marktbeobachtung oder statistische Analyse der durch Kundenbefragung erhobenen Daten erfolgen. Customer Analytics und Procurement Analytics sind zwei Anwendungsgebiete für Data Science in der industriellen Marktforschung.

Business Intelligence und Competitive Intelligence

Der Begriff Business Intelligence ist aus der modernen Geschäftswelt nicht mehr wegzudenken. Business Intelligence bezeichnet die Analyse von unternehmensinternen und auch -externen Daten, um das eigene Unternehmen benchmarken zu können, eine Transparenz über die Prozesse und die Leistungsfähigkeit des Unternehmens zu erreichen. Das Unternehmen reflektiert sich mit Business Intelligence selbst.

Competitive Intelligence nutzt sehr ähnliche, in den überwiegenden Fällen genau dieselben Methoden, jedoch nicht mit dem Ziel, ein Abbild des eigenen, sondern ein Abbild von anderen Unternehmen zu erstellen, nämlich von direkten Konkurrenten des eigenen Unternehmens oder auch von strategischen Lieferanten oder Zielkunden.

Motivationen für Competitive Intelligence

Die Motivationen für die genaue Analyse von Konkurrenzunternehmen können sehr vielfältig sein, beispielsweise:

  • Ermittlung der eigenen Wettbewerbsposition für ein Benchmarking oder zur Wettbewerberprofilierung
  • (Strategische) Frühwarnung/-aufklärung
  • Due Diligence bei Unternehmenskauf oder Bewertung von Marktzugangschancen
  • Chancen-/Risikoanalyse für neue Angebote/Absatzregionen
  • Issues Monitoring (für das eigene Unternehmen relevante Themen)
  • Analyse von Kundenanforderungen
  • Satisfaction Surveys (eigene und Wettbewerberkunden bzw. -zulieferer)
  • Bewertung von Zulieferern (Loyalität, Preisgestaltung, Überlebensfähigkeit)

Viele dieser Anwendungsszenarien sind nicht weit weg von aktuellen Business Intelligence bzw. Data Science Projekten, die öffentlich kommuniziert werden. Beispielsweise arbeiten Data Scientists mit aller Selbstverständlichkeit im Rahmen von Procurement Analytics daran, Lieferantennetzwerke hinsichtlich der Ausfallrisiken zu analysieren oder auch in Abhängigkeit von Marktdaten ideale Bestellzeitpunkte zu berechnen. Im Customer Analytics ist es bereits Normalität, Kundenausfallrisiken zu berechnen, Kundenbedürfnisse und Kundenverhalten vorherzusagen. Die viel diskutierte Churn Prediction, also die Vorhersage der Loyalität des Kunden gegenüber dem Unternehmen, grenzt an Competetitve Intelligence mindestens an.

Wirtschaftsspionage

Während Competititve Intelligence noch mit grundsätzlich legalen Methoden der Datenbeschaffung und -auswertung auskommt, ist die Wirtschaftsspionage eine Form der Wirtschaftskriminalität, also eine illegale Handlung darstellt, die strafrechtliche Konsequenzen haben kann. Zur Wirtschaftsspionage steigern sich die Handlungen dann, wenn beispielsweise auch interne Dokumente oder der Datenverkehr ohne Genehmigung der Eigentümer abgegriffen werden.

Beispiele für Wirtschaftsspionage mit Unterstützung durch Data Science Methoden ist die Analyse von internen Finanztransaktionsdaten, des Datenverkehrs (über Leitungen oder Funknetze) oder des E-Mail-Verkehrs. Neue Methoden aus den Bereichen Machine Learning / Deep Learning werden auch die Möglichkeiten der Wirtschaftsspionage weiter beflügeln, beispielsweise durch Einsatz von gezielter Schrift-/Spracherkennung in Abhör-Szenarien.

Strafrechtliche Bewertung und Verfolgung

Die strafrechtliche Verfolgung von datengetriebener Wirtschaftsspionage ist in der Regel schwierig bis praktisch unmöglich. Zu Bedenken gilt zudem, dass Datenabgriffe und -analysen mit Leichtigkeit in anderen Nationen außerhalb der lokalen Gesetzgebung durchgeführt werden können.

Nicht zu vergessen: Data Science ist stets wertfrei zu betrachten, denn diese angewandte Wissenschaft kann zur Wirtschaftsspionage dienen, jedoch genauso gut auch bei der Aufdeckung von Wirtschaftsspionage helfen.

Literaturempfehlungen

Folgende Bücher sind Quellen für einen tieferen Einblick in Intelligence Gathering und die Möglichkeiten von Data Science zur Informationsbeschaffung.


Wirtschaftsspionage und Intelligence Gathering: Neue Trends der wirtschaftlichen Vorteilsbeschaffung

Data Mining and Predictive Analysis: Intelligence Gathering and Crime Analysis

Kontrolle und Steuerung von Spark Applikationen über REST

Apache Spark erfreut sich zunehmender Beliebtheit in der Data Science Szene da es in Geschwindigkeit und Funktionalität eine immense Verbesserung bzw. Erweiterung des reinen Hadoop MapReduce Programmiermodells ist. Jedoch bleibt Spark ebenso wie Hadoop eine Technologie für Experten. Es erfordert zumindest Kenntnisse von Unix-Skripten und muss über die Command-Line gesteuert werden. Die vorhandenen Weboberflächen bieten nur sehr rudimentäre Einblicke in den Status von Spark Applikationen:

spark basic ui

Der Spark JobServer ist ein Open-Source Projekt, das eine REST-Schnittstelle (Representational State Transfer) für Spark anbietet. (In diesem YouTube Video wird anschaulich erläutert, was ein REST API ist und wozu es verwendet werden kann.) Vereinfacht gesagt, ermöglicht es der JobServer, Spark über diese REST-Schnittstelle als Webservice zu nutzen. Es ist möglich, über den JobServer Spark Kontexte und Applikationen (Jobs) zu managen und Kontexte über verschiedene Aufrufe der REST-Schnittstelle hinweg wiederzuverwenden. Jar Files mit Job Implementierungen können vorab über die gleiche Schnittstelle installiert werden, so dass es z.B. möglich ist, auch sehr feingranulare Jobs über die Schnittstelle zu steuern (vollständige Liste der Features).

Der Spark JobServer ist bereits bei verschiedenen Organisationen (u.a. Netflix, Zed Worldwide, KNIME, Azavea und Maana) im Einsatz. Diese Nutzer des JobServers verwenden ihn meist versteckt „unter der Haube“, um so ihre jeweiligen Werkzeuge Big-Data tauglich zu machen. So nutzt KNIME ab dem nächsten Release (Oktober 2015) den JobServer. Anwendern können dann Spark Jobs über eine grafische Oberfläche bequem von ihrem lokalen Rechner aus starten, monitoren und stoppen. In der folgenden Abbildung sehen Sie, wie Trainingsdaten auf den Server hochgeladen werden, um daraus verschiedene Machine Learning Modelle zu erstellen. Diese Modelle können dann auf Testdaten angewandt werden, die z.B. aus einer HIVE-Tabelle nach Spark importiert werden:

spark knime hive jobs

Jeder der dargestellten Knoten mit der Überschrift „Spark ***“, wie z.B. „Spark Decision Tree“, ist ein Spark Job im Sinne des JobServers. Weitere Beispiele für Spark Jobs sind verschiedene Vorverarbeitungsaufgaben wie das Sampling einer Tabelle oder ein Join über mehrere Tabellen.

Spark kann über den JobServer im Standalone-, Mesos- oder im Yarn-Client-Modus angesteuert werden. Eine sehr hilfreiche Erweiterung der eigentlichen Spark-Funktionalität bietet der JobServer über die sogenannten „Named RDDs“ an. Ein Resilient Distributed Dataset (RDD) ist im Prinzip ein Datensatz bzw. eine Tabelle in Spark. „Named RDDs“ erlauben die Weiterverwendung von RDDs über einzelne Jobs hinweg. So kann man Jobs modularer aufbauen und leichter Zwischenergebnisse inspizieren.

Ich kann aus eigener Erfahrung sagen, dass der JobServer die geeignete Middleware zwischen einer benutzerfreundlichen Oberfläche und Spark ist. Die Open-Source Community ist hier sehr aktiv und der JobServer lässt sich bei Bedarf gut erweitern.

Finance Controlling und NoSQL Data Science – zwei Welten treffen aufeinander

Wenn ein konservativer, geschäftskritischer Fachbereich auf neue Technologien mit anderen, kreativen Möglichkeiten trifft, führt das zu Reibungen, aber auch zu Ergebnissen, die andere Personen auf neue Ideen bringen können. Bei dem hier geschilderten Anwendungsfall geht es um die Ermittlung einer kurzfristigen Erfolgrechnung (KER) unter Nutzung von NoSQL-Technologien. Einer Aufgabenstellung, die für beide Seiten sehr lehrreich war.

1-opener-image

Erinnern Sie sich noch an die Werbespots von Apple mit Justin Long und John Hodgman als menschlicher Apple und Personal Computer? Ähnlich wie in den Werbespots sind die beiden Bereiche Finance Controlling und Data Science zu betrachten. Der eine eher konservativ, geschäftskritisch, mit etablierten Methoden und Verfahren; der andere mit einem Zoo voller verschiedener Werkzeuge für den kreativen Umgang mit Daten. Insbesondere wenn dann auch noch NoSQL ins Spiel kommt, mag man glauben, dass keinerlei Berührungspunkte existieren. Dennoch eignen sich neue Technologien auch für etablierte Bereiche und können diese bereichern und auf neue Ideen bringen.

Bei einer kurzfristigen Erfolgsrechnung (sog. KER) handelt es sich um die Aufstellung kaufmännischer Kennzahlen und den Vergleich über Zeiträume. Unter anderem wird hierbei auch häufig von Deckungsbeitragsrechnung oder Betriebsergebnisrechnung gesprochen. Eine KER wird vom Controlling daher aus der kaufmännischen Software generiert (z.B. SAP FiCo) und zumeist nur als Datei oder tatsächlich noch auf Papier an Bereichsleiter oder die Geschäftsführung übergeben.

Ergänzend zu der standardisierten Aufstellung sollte es in dem hier geschilderten Fall möglich sein, dass die Berechnung der KER unter Berücksichtigung von Filtermöglichkeiten ad hoc durch einen Endanwender möglich sein soll. Das bedeutet, dass nicht mehr nur ausschließlich das Controlling die Erfolgsrechnung generieren kann, sondern auch jeder Fachbereich selbständig für sich. Dementsprechend müssen die Werkzeuge aus dem Data Science einmal konfiguriert und benutzerfreundlich bereitgestellt werden.

Die Generierung einer Erfolgrechnung mag auf den ersten Blick nicht direkt als Aufgabe für einen Data Scientist wirken, schließlich sind die Daten und deren Aufbau bekannt, genauso wie die Form des Endergebnisses. Dennoch stellen sich der Vielzahl bekannter Variablen, genauso viele unbekannte gegenüber. Denn wenn ein relationales Modell einfach in eine neue Technologie (NoSQL) überführt wird, hat man nichts dabei gewonnen. Erst der kreative Einsatz neuer Methoden und der etwas andere Umgang mit bekannten Daten führt zu einer Verbesserung und neuen Idee.

Daten

Bei den zu verarbeitenden Daten handelt es sich um Buchungsdaten (SAP Export), Plandaten (csv-Export aus einem Planungssystem) und um manuelle Informationen aus Excel (als csv-Dateien). Insgesamt sind es mindestens neun Datenquellen unterschiedlicher Qualität. Insbesondere bei den manuell erstellten Excel-Daten muss mehrfach geprüft werden, ob die Dateien in dem vereinbarten Format vorliegen. (Gerade bei manuell gepflegten Daten greift Murphys Law – immer!)

Die Inhalte der Excel-Daten reichern die anderen beiden Quelldaten durch weitere Informationen an. Hierbei handelt es sich u.a. um Mappinginformationen zur Ergänzung kurzer Schreibweisen oder maskierter Inhalte, damit diese durch Endanwender gelesen werden können. Beispielsweise sind Kostenstellen in Unternehmensbereiche, Abteilungen und Produktgruppen zu entschlüsseln.

Bei den Buchungsdaten aus dem SAP-System handelt es sich um die monatlichen Saldenwerte eines Kontos, die granular auf Kostenstelle, Marke, Periode und weitere Merkmale heruntergebrochen wurden. Damit wird also nicht pro Monat ein Kontensaldo übergeben, sondern eine Vielzahl von Salden je Konto, je nachdem, wie viele Merkmale geliefert werden.

Beispiel für eine Zeile aus dem SAP-Export:

Je Periode (im Regelfall: Monate) wird eine Datei geliefert; dabei ist aus dem Dateinamen die Betriebszugehörigkeit und die Periode abzulesen. Es gilt zudem, dass ein Unternehmen in mehr als 12 Perioden pro Jahr Buchungen durchführen kann (in diesem Fall bis zu 16).

Die Buchungsinformationen und alle weiteren Dateien werden mit einer Java-Anwendung in die NoSQL-Datenbank importiert. Hierbei wird auf eine multi-model Datenbank zurückgegriffen, um im späteren Verlauf verschiedene NoSQL-Technologien nutzen zu können (z.B. documentstore, graphdb, multi-value und bi-temporal).2-KER-Modell

Modellierung

Für jede Datenquelle wird eine Datensatzart genutzt. Relational gesprochen bedeutet das eine Tabelle je Quelle oder für Benutzer von document stores: eine “collection” für gleichartige Dokumente.

Bei der gewählten Datenbank wird allerdings nicht zwischen verschiedenen “collections” unterschieden. Nur durch ein Feld je Datensatz wird der Typ des Datensatzes festgelegt. In der Anwendung wird dieses Feld interpretiert und der Datensatz entsprechend angezeigt (anhand von Templates für die JSON-Ausgabe). Da – wie bei document stores üblich – die Dokumente ein dynamisches Schema aufweisen, können sich alle Datensätze in ihrer Art und Ausprägung (Key/Values) unterscheiden.

Als Ergänzung zu den bisherigen Quelldaten werden innerhalb der Datenbank weitere Datensätze für das Layout der KER-Ausgabe angelegt. Diese beschreiben im Prinzip nur die Reihenfolge und den Inhalt der späteren Ausgabe (dazu später mehr).

Nach dem Import der Datensätze werden innerhalb der Datenbank zwischen den Datensätzen Verlinkungen (Graphen) etabliert. So zeigen beispielsweise alle Buchungen auf das jeweils betroffene Konto oder eine KER-Ergebniszeile auf eine Kontengruppe. Aus der Skizze zum Datenmodell können die relevanten Verlinkungen abgelesen werden.

Anzumerken ist hier, dass ein Konto in mehreren Kontengruppen auftreten kann. Eine einzelne n:m-Verlinkung wird daher in diesem Fall über separate Datensätze abgehandelt und nicht in einem Datensatz mit einer Unterstruktur. Das wäre zwar auch möglich, erschwert und verlangsamt allerdings etwaige Aktualisierungen, da die csv-Quelle nur eine Zeile je Zuweisung liefert.

Für die Speicherung der Buchungsinformationen wird auf die Funktionalität der bi-temporalen Datenhaltung 3-bitemporalzurückgegriffen. Hierbei erhält jeder Feldinhalt in einem Datensatz (optional) den Vermerk des Gültigkeitszeitpunktes. Neben dem Transaktionszeitpunkt (wann wurden die Daten gespeichert) ist also auch erkennbar ab (oder auch bis) wann ein Inhalt gültig ist. Dabei ist zu beachten, dass “nicht-gültig” etwas anderes ist, als “falsch”. In dieser Art der Verwendung steht “nicht-gültig” für “nicht mehr aktuell” oder auch “noch nicht aktuell”.

Durch diese Art der Datensatzspeicherung reduziert sich die Anzahl der Buchungsdatensätze auf einen Bruchteil des ursprünglichen Datenbestandes. Beispiel: Es werden jeden Monat 10.000 Buchungen geliefert. Für 16 Monate ergeben sich somit 160.000 Datensätze. Da diese bi-temporal gespeichert werden, bleibt es bei 10.000 Datensätzen in der Datenbank mit je max. 16 Gültigkeitswerten je Feld (für jede Periode).

Hier sei noch angemerkt, dass ein Wert so lange gültig ist, bis ein anderer Wert diesen ergänzt. Wird also für Januar ein bestimmter Wert geliefert und im Laufe des Jahres nicht geändert, bleibt dieser bestehen und wird nicht nochmal gespeichert. Statt 16 Einträgen, bleibt es also bei einem.

Ergänzend dazu stellt sich die Frage zum Umgang mit den Perioden 13 bis 16. Da ein Jahr nur 12 Monate besitzt, können diese nicht einfach mit einem falschen Datum gespeichert werden. Hier greift allerdings der Umstand, dass speziell in diesem Anwendungsfall erst am Ende eines Monats durch den Monatsabschluss alle Buchungen korrekt sind. Innerhalb eines Monats ist das nicht der Fall. Es gibt also genau einen (und nur einen) korrekten Zeitpunkt, an dem die Werte korrekt und gültig sind. Die Werte einer Buchung zu diesem Zeitpunkt werden also nur zu einem Tag in dem Datensatz gespeichert.

Schaut man sich nun den Screenshot des Datensatzes mit den Monatswerten an, fällt auf, dass die Salden-Werte (im Feld “SAP-Werte”) jeweils zum Zweiten eines Monats gespeichert wurden. Da es nur einen gültigen Wert je Monat gibt, ist das Datum irrelevant (es hätte auch der Dritte oder Vierte des Monats sein können). Für jede Periode größer 12 wurde einfach vorgesehen, dass diese ab dem 13.12. eines Jahres hinterlegt werden (d.h. für Periode 14 der 14.12.; Periode 15 der 15.12. usw.). Und da zum Anfang eines Jahres alle Buchungen zu bestimmten Konten auf Null gesetzt werden müssen (also zum 01.01.) bietet sich der Zweite eines Monats an.

Nach dem Einlesen aller gelieferten csv-Dateien, erfolgt die Erzeugung von weiteren Datensätzen für das Layout der Ergebnisrechnung. Diese werden einmalig angelegt und können über eine Benutzeroberfläche vom Anwender angepasst werden.

Wie in der Skizze zum Datenmodell zu erkennen, besteht das Layout der KER aus zwei Datensatztypen. Einmal aus der Layout-Definition (nur ein Datensatz) und zum Zweiten aus mehreren Ergebniszeilen, die jeweils über einen Datensatz beschrieben werden.

4-KER-Layout 5-KER-ErgZeile

 

 

 

 

 

 

 

Beide Datensatztypen bestehen dabei fast ausschließlich aus Linkfeldern (Graphen). Das KER-Layout verweist damit auf die beteiligten Zeilen in der Reihenfolge, wie sie später angezeigt werden; ein Datensatz für eine KER-Zeile verweist auf die jeweiligen Kontengruppen.

In einem zusätzlichen Textfeld einer KER-Zeile wird zudem die Formel eingetragen, über die bei der späteren Anzeige ad hoc das Ergebnis der jeweiligen Zeile berechnet wird (in dem abgebildeten, einfachen Fall nur die Summe zweier Kontengruppen). Dazu steht serverseitig die Bibliothek der Google V8 Javascript-Engine zur Verfügung.

Der Screenshot der Ergebniszeile zeigt zudem die Verwendung von “multi-values” in einem Datensatz. Hierbei können verschiedene Inhalte in einem Feld abgelegt und auch mit anderen Feldern kombiniert werden. In diesem Fall gehören jeweils eine Kontengruppe und der prozentuale Bezug zueinander. Andere Anwendungsfälle sind bspw. die Bankverbindungen oder Kontaktdaten einer Person, da diese auch aus mehreren, zusammengehörenden Feldern bestehen und jede Person mehrere besitzen kann.

Bis hierher wurden die Daten importiert, das Datenmodell aufgebaut und die Datensätze miteinander verlinkt. Aus der NoSQL-Trickkiste nutzen wir die bitemporale Datenhaltung, Graphen, multi-values und document stores. Dadurch wird die Anzahl der Datensätze reduziert und das Datenmodell vereinfacht. Im nächsten Schritt geht es darum, die KER-Ausgabe aufzubereiten und die Ergebnisse – unter Berücksichtigung von Filtermöglichkeiten – mit Hilfe von serverseitigem JavaScript zu berechnen.

Anwendung

Der Anwendungsfall KER-Liste ist im Rahmen eines Gesamtprojektes ein Teilaspekt. Daher wurde auf vorhandene Werkzeuge zurückgegriffen, um mit den gegebenen Mitteln den maximalen Nutzen zu erreichen.

Als System steht eine multi-model NoSQL-Platform zur Verfügung, die mehrere Bereiche der NoSQL-Welt abdeckt und nicht nur eine Datenbank beinhaltet, sondern gleich ein ganzes Arsenal an Werkzeugen, um Lösungen zu erschaffen. Dazu gehört unter anderem auch eine standardisierte Webanwendung, in der durch einfache Konfigurationen Anwendungen definiert werden und die es ermöglicht, die serverseitige Bibliothek der Google V8 Javascript-Engine zu nutzen. Dadurch wird ein Großteil des Anwendungsfalles aus der Softwareentwicklung herausgelöst und an den Fachbereich übertragen.

Hierbei ist zu beachten, dass der Data Scientist sich nicht von dem Fachthema vollständig lösen kann. Ein Grundverständnis ist notwendig, um zu verstehen, wie die Problemlage ist und was das Endergebnis sein soll. Genauso muss der Fachbereich Grundlagen des Datenhandlings und des Systems verstehen. Nur beide zusammen können in einer transparenten Kommunikationsstruktur Lösungen erarbeiten.

Nach der Konfiguration des Datenmodells und dem Import der Daten wurde alles Weitere in der Standardanwendung der NoSQL-Plattform umgesetzt. Dieses beinhaltet unter anderem die Konfiguration der Erfolgsrechnung, wie auch den JavaScript-Teil zur Ermittlung der Ergebnisse und später auch die grafische Ausgabe in Form eines Dashboards mit den gleichen Filter-Möglichkeiten der KER-Ausgabe.

Um innerhalb der Anwendung die kurzfristige Erfolgsrechnung zu erzeugen, wird auf die Funktion von Listen zurückgegriffen. Diese können, ausgehend von einem Datensatz, die Graph-Strukturen auflösen und so hierarchische Ausgaben erzeugen. Als Ergänzung dazu ist eine Integration von Javascript innerhalb der Listen möglich, so dass Berechnungen serverseitig durchgeführt und Ergebnisse zur Anzeige gebracht werden können. Darüber hinaus ist die Nutzung über eine HTTP API möglich, um die Anwendung ggf. später durch weitere Funktionen zu erweitern.6-KER-Modell-Hierarchisch

Ausgehend von dem definierten Datensatz für das KER-Layout ermöglicht die Listenfunktionalität die Konfiguration von sog. Sublisten (also Listen in Listen in Listen in …). Hierbei verfolgt die Liste die Graphenstruktur und bringt die jeweiligen Datensätze zur Anzeige. Durch das genutzte Modell ist der Startpunkt somit ein einzelner Datensatz, zu dem dann hierarchisch alle weiteren Datensätze dazu geladen werden.

Die entstehende Baumstrukur ist im ersten Schritt leer und muss im Anschluss durch JavaScript gefüllt werden. Dazu wird einerseits auf die Inhalte aus der untersten Ebene zurückgegriffen, um die Saldenwerte zu lesen; andererseits auch auf die hinterlegten Formeln jeder Ergebniszeile, um mit den Summen der Kontengruppen die Ergebnisse zu ermitteln.

Das Zauberwort bei der Nutzung von Javascript heißt hier “eval”. Durch diese Funktion werden Strings als Script evaluiert. Im Detail werden durch reguläre Ausdrücke die Begriffe in den Formeln (Namen der Kontengruppen) durch die Summenwerte der jeweiligen Kontengruppe ersetzt und danach mit Hilfe von “eval” ausgeführt. Das Ergebnis wird dann an die entsprechende Position in der Liste geschrieben.

Im Weiteren erhalten bestimmte Werte noch unterschiedliche Formate, um den kosmetischen Aspekt zu erfüllen. Am Ende erhält der Anwender eine KER-Liste.

7-ker-Beispiel

Filter

Die Generierung einer vollständigen KER dauert bis zu fünf Sekunden. Dabei liegen bis zu 40.000 Buchungsdatensätze zu Grunde. Durch einen interaktiven Filter kann der Anwender den Umfang der Liste und die Berechnung entsprechend einschränken. Folgende Felder aus den Buchungsdatensätzen stehen dabei für Filterkombinationen zur Verfügung:

  • Buchungskreise (Filialen): 14
  • Geschäftsbereich (Abteilung): 32
  • Kostenstelle: 56
  • Marke: 9
  • Absatzkanal: 12

Hierbei kann der Anwender jede beliebige Kombination in jeder erdenklichen Reihenfolge zur Filterung nutzen. Die Liste wird entsprechend neu berechnet und in unter fünf Sekunden zur Anzeige gebracht (wegen der reduzierten Datenmenge häufig in unter einer Sekunde).

Als Ergänzung zu den Filtermöglichkeiten kann auch der zeitliche Aspekt berücksichtigt werden. Da die Buchungsinformationen bitemporal gespeichert wurden, besteht in der Liste die Möglichkeit, ein beliebiges Datum zu wählen und sich die Werte dazu anzeigen zu lassen.

Gesamtfunktion und Ausblick

Durch den generalistischen Ansatz des Datenmodells und der gewählten Datenbank konnte nicht nur die kurzfristige Erfolgsrechnung in der üblichen, tabellarischen Form ausgegeben werden. Ferner wurde eine grafische Ausgabe mit der Bibliothek d3.js realisiert, so dass jede Führungskraft in der Lage ist, eine ad hoc Analyse durchzuführen. (Ich spreche hier gerne von KRV-tauglich. “Kinder, Rentner, Vorstände”).

Derzeitig wird JavaScript innerhalb von Listen genutzt, um bei Bedarf Werte zu errechnen. Als Ausblick steht hier in Kürze die Möglichkeit zur Verfügung, dass Scripte auch innerhalb von Datensätze abgelegt und autonom von der Datenbank selber ausgeführt werden. Das hat zur Folge, dass Objekte (Datensätze) Algorithmen beinhalten und selbständig Informationen suchen und generieren.

Verwendete NoSQL-Methoden

  • document store
  • GraphDB
  • multi-Value
  • Bitemporal

Erwähnte Technologien, Produkte und Marken in diesem Artikel

Der hier beschriebene Anwendungsfall soll zeigen, dass Data Science nicht nur Endergebnisse liefert, die quasi durch eine “black box” entstanden, dessen Vorgehensweise nur eingeweihte Personen beherrschen und beurteilen können. Es ist vielmehr so, dass die “Wissenschaft” das Wissen dafür schafft, damit ein “normaler” Anwender mit den Daten umgehen kann und einen Mehrwert daraus erhält.

Automatisierte Extraktion von Rohstoffpreisen aus HTML basierten Dokumenten

Ein im ETL-Kontext häufiger Anwendungsfall ist die periodische Extraktion beliebiger Zeichenketten aus heterogenen Datenquellen. Ziel dieses Artikel ist, am Beispiel der beiden Industriemetalle Aluminium und Kupfer zu demonstrieren, wie mit vergleichsweise geringem Aufwand ein Monitoring von Rohstroffpreisen realisiert werden kann. Die tragende Technologie im Hinblick des Extraktionsprozesses wird hierbei die vielseitige Programmiersprache PHP sein. Die Speicherung der Rohstoffpreise wird MongoDB übernehmen und zur Koordinierung der einzelnen Elemente findet ein wenige Zeilen umfassendes Bash-Script, welches periodisch vom cron Daemon gestartet wird, Verwendung. Read more