Posts

Wie passt Machine Learning in eine moderne Data- & Analytics Architektur?

Einleitung

Aufgrund vielfältiger potenzieller Geschäftschancen, die Machine Learning bietet, arbeiten mittlerweile viele Unternehmen an Initiativen für datengetriebene Innovationen. Dabei gründen sie Analytics-Teams, schreiben neue Stellen für Data Scientists aus, bauen intern Know-how auf und fordern von der IT-Organisation eine Infrastruktur für “heavy” Data Engineering & Processing samt Bereitstellung einer Analytics-Toolbox ein. Für IT-Architekten warten hier spannende Herausforderungen, u.a. bei der Zusammenarbeit mit interdisziplinären Teams, deren Mitglieder unterschiedlich ausgeprägte Kenntnisse im Bereich Machine Learning (ML) und Bedarfe bei der Tool-Unterstützung haben. Einige Überlegungen sind dabei: Sollen Data Scientists mit ML-Toolkits arbeiten und eigene maßgeschneiderte Algorithmen nur im Ausnahmefall entwickeln, damit später Herausforderungen durch (unkonventionelle) Integrationen vermieden werden? Machen ML-Funktionen im seit Jahren bewährten ETL-Tool oder in der Datenbank Sinn? Sollen ambitionierte Fachanwender künftig selbst Rohdaten aufbereiten und verknüpfen, um auf das präparierte Dataset einen populären Algorithmus anzuwenden und die Ergebnisse selbst interpretieren? Für die genannten Fragestellungen warten junge & etablierte Software-Hersteller sowie die Open Source Community mit “All-in-one”-Lösungen oder Machine Learning-Erweiterungen auf. Vor dem Hintergrund des Data Science Prozesses, der den Weg eines ML-Modells von der experimentellen Phase bis zur Operationalisierung beschreibt, vergleicht dieser Artikel ausgewählte Ansätze (Notebooks für die Datenanalyse, Machine Learning-Komponenten in ETL- und Datenvisualisierungs­werkzeugen vs. Speziallösungen für Machine Learning) und betrachtet mögliche Einsatzbereiche und Integrationsaspekte.

Data Science Prozess und Teams

Im Zuge des Big Data-Hypes kamen neben Design-Patterns für Big Data- und Analytics-Architekturen auch Begriffsdefinitionen auf, die Disziplinen wie Datenintegration von Data Engineering und Data Science vonein­ander abgrenzen [1]. Prozessmodelle, wie das ab 1996 im Rahmen eines EU-Förderprojekts entwickelte CRISP-DM (CRoss-Industry Standard Process for Data Mining) [2], und Best Practices zur Organisation erfolgreich arbeitender Data Science Teams [3] weisen dabei die Richtung, wie Unternehmen das Beste aus den eigenen Datenschätzen herausholen können. Die Disziplin Data Science beschreibt den, an ein wissenschaftliches Vorgehen angelehnten, Prozess der Nutzung von internen und externen Datenquellen zur Optimierung von Produkten, Dienstleistungen und Prozessen durch die Anwendung statistischer und mathematischer Modelle. Bild 1 stellt in einem Schwimmbahnen-Diagramm einzelne Phasen des Data Science Prozesses den beteiligten Funktionen gegenüber und fasst Erfahrungen aus der Praxis zusammen [5]. Dabei ist die Intensität bei der Zusammenarbeit zwischen Data Scientists und System Engineers insbesondere bei Vorbereitung und Bereitstellung der benötigten Datenquellen und später bei der Produktivsetzung des Ergebnisses hoch. Eine intensive Beanspruchung der Server-Infrastruktur ist in allen Phasen gegeben, bei denen Hands-on (und oft auch massiv parallel) mit dem Datenpool gearbeitet wird, z.B. bei Datenaufbereitung, Training von ML Modellen etc.

Abbildung 1: Beteiligung und Interaktion von Fachbereichs-/IT-Funktionen mit dem Data Science Team

Mitarbeiter vom Technologie-Giganten Google haben sich reale Machine Learning-Systeme näher angesehen und festgestellt, dass der Umsetzungsaufwand für den eigentlichen Kern (= der ML-Code, siehe den kleinen schwarzen Kasten in der Mitte von Bild 2) gering ist, wenn man dies mit der Bereitstellung der umfangreichen und komplexen Infrastruktur inklusive Managementfunktionen vergleicht [4].

Abbildung 2: Versteckte technische Anforderungen in maschinellen Lernsystemen

Konzeptionelle Architektur für Machine Learning und Analytics

Die Nutzung aller verfügbaren Daten für Analyse, Durchführung von Data Science-Projekten, mit den daraus resultierenden Maßnahmen zur Prozessoptimierung und -automatisierung, bedeutet für Unternehmen sich neuen Herausforderungen zu stellen: Einführung neuer Technologien, Anwendung komplexer mathematischer Methoden sowie neue Arbeitsweisen, die in dieser Form bisher noch nicht dagewesen sind. Für IT-Architekten gibt es also reichlich Arbeit, entweder um eine Data Management-Plattform neu aufzubauen oder um das bestehende Informationsmanagement weiterzuentwickeln. Bild 3 zeigt hierzu eine vierstufige Architektur nach Gartner [6], ausgerichtet auf Analytics und Machine Learning.

Abbildung 3: Konzeptionelle End-to-End Architektur für Machine Learning und Analytics

Was hat sich im Vergleich zu den traditionellen Data Warehouse- und Business Intelligence-Architekturen aus den 1990er Jahren geändert? Denkt man z.B. an die Präzisionsfertigung eines komplexen Produkts mit dem Ziel, den Ausschuss weiter zu senken und in der Produktionslinie eine höhere Produktivitätssteigerung (Kennzahl: OEE, Operational Equipment Efficiency) erzielen zu können: Die an der Produktherstellung beteiligten Fertigungsmodule (Spezialmaschinen) messen bzw. detektieren über zahlreiche Sensoren Prozesszustände, speicherprogrammierbare Steuerungen (SPS) regeln dazu die Abläufe und lassen zu Kontrollzwecken vom Endprodukt ein oder mehrere hochauflösende Fotos aufnehmen. Bei diesem Szenario entsteht eine Menge interessanter Messdaten, die im operativen Betrieb häufig schon genutzt werden. Z.B. für eine Echtzeitalarmierung bei Über- oder Unterschreitung von Schwellwerten in einem vorher definierten Prozessfenster. Während früher vielleicht aus Kostengründen nur Statusdaten und Störungsinformationen den Weg in relationale Datenbanken fanden, hebt man heute auch Rohdaten, z.B. Zeitreihen (Kraftwirkung, Vorschub, Spannung, Frequenzen,…) für die spätere Analyse auf.

Bezogen auf den Bereich Acquire bewältigt die IT-Architektur in Bild 3 nun Aufgaben, wie die Übernahme und Speicherung von Maschinen- und Sensordaten, die im Millisekundentakt Datenpunkte erzeugen. Während IoT-Plattformen das Registrieren, Anbinden und Management von Hunderten oder Tausenden solcher datenproduzierender Geräte („Things“) erleichtern, beschreibt das zugehörige IT-Konzept den Umgang mit Protokollen wie MQTT, OPC-UA, den Aufbau und Einsatz einer Messaging-Plattform für Publish-/Subscribe-Modelle (Pub/Sub) zur performanten Weiterverarbeitung von Massendaten im JSON-Dateiformat. Im Bereich Organize etablieren sich neben relationalen Datenbanken vermehrt verteilte NoSQL-Datenbanken zum Persistieren eingehender Datenströme, wie sie z.B. im oben beschriebenen Produktionsszenario entstehen. Für hochauflösende Bilder, Audio-, Videoaufnahmen oder andere unstrukturierte Daten kommt zusätzlich noch Object Storage als alternative Speicherform in Frage. Neben der kostengünstigen und langlebigen Datenauf­bewahrung ist die Möglichkeit, einzelne Objekte mit Metadaten flexibel zu beschreiben, um damit später die Auffindbarkeit zu ermöglichen und den notwendigen Kontext für die Analysen zu geben, hier ein weiterer Vorteil. Mit dem richtigen Technologie-Mix und der konsequenten Umsetzung eines Data Lake– oder Virtual Data Warehouse-Konzepts gelingt es IT-Architekten, vielfältige Analytics Anwendungsfälle zu unterstützen.

Im Rahmen des Data Science Prozesses spielt, neben der sicheren und massenhaften Datenspeicherung sowie der Fähigkeit zur gleichzeitigen, parallelen Verarbeitung großer Datenmengen, das sog. Feature-Engineering eine wichtige Rolle. Dazu wieder ein Beispiel aus der maschinellen Fertigung: Mit Hilfe von Machine Learning soll nach unbekannten Gründen für den zu hohen Ausschuss gefunden werden. Was sind die bestimmenden Faktoren dafür? Beeinflusst etwas die Maschinenkonfiguration oder deuten Frequenzveränderungen bei einem Verschleißteil über die Zeit gesehen auf ein Problem hin? Maschine und Sensoren liefern viele Parameter als Zeitreihendaten, aber nur einige davon sind – womöglich nur in einer bestimmten Kombination – für die Aufgabenstellung wirklich relevant. Daher versuchen Data Scientists bei der Feature-Entwicklung die Vorhersage- oder Klassifikationsleistung der Lernalgorithmen durch Erstellen von Merkmalen aus Rohdaten zu verbessern und mit diesen den Lernprozess zu vereinfachen. Die anschließende Feature-Auswahl wählt bei dem Versuch, die Anzahl von Dimensionen des Trainingsproblems zu verringern, die wichtigste Teilmenge der ursprünglichen Daten-Features aus. Aufgrund dieser und anderer Arbeitsschritte, wie z.B. Auswahl und Training geeigneter Algorithmen, ist der Aufbau eines Machine Learning Modells ein iterativer Prozess, bei dem Data Scientists dutzende oder hunderte von Modellen bauen, bis die Akzeptanzkriterien für die Modellgüte erfüllt sind. Aus technischer Sicht sollte die IT-Architektur auch bei der Verwaltung von Machine Learning Modellen bestmöglich unterstützen, z.B. bei Modell-Versionierung, -Deployment und -Tracking in der Produktions­umgebung oder bei der Automatisierung des Re-Trainings.

Die Bereiche Analyze und Deliver zeigen in Bild 3 einige bekannte Analysefähigkeiten, wie z.B. die Bereitstellung eines Standardreportings, Self-service Funktionen zur Geschäftsplanung sowie Ad-hoc Analyse und Exploration neuer Datasets. Data Science-Aktivitäten können etablierte Business Intelligence-Plattformen inhaltlich ergänzen, in dem sie durch neuartige Kennzahlen, das bisherige Reporting „smarter“ machen und ggf. durch Vorhersagen einen Blick in die nahe Zukunft beisteuern. Machine Learning-as-a-Service oder Machine Learning-Produkte sind alternative Darreichungsformen, um Geschäftsprozesse mit Hilfe von Analytik zu optimieren: Z.B. integriert in einer Call Center-Applikation, die mittels Churn-Indikatoren zu dem gerade anrufenden erbosten Kunden einen Score zu dessen Abwanderungswilligkeit zusammen mit Handlungsempfehlungen (Gutschein, Rabatt) anzeigt. Den Kunden-Score oder andere Risikoeinschätzungen liefert dabei eine Service Schnittstelle, die von verschiedenen unternehmensinternen oder auch externen Anwendungen (z.B. Smartphone-App) eingebunden und in Echtzeit angefragt werden kann. Arbeitsfelder für die IT-Architektur wären in diesem Zusammenhang u.a. Bereitstellung und Betrieb (skalierbarer) ML-Modelle via REST API’s in der Produktions­umgebung inklusive Absicherung gegen unerwünschten Zugriff.

Ein klassischer Ansatz: Datenanalyse und Machine Learning mit Jupyter Notebook & Python

Jupyter ist ein Kommandozeileninterpreter zum interaktiven Arbeiten mit der Programmiersprache Python. Es handelt sich dabei nicht nur um eine bloße Erweiterung der in Python eingebauten Shell, sondern um eine Softwaresuite zum Entwickeln und Ausführen von Python-Programmen. Funktionen wie Introspektion, Befehlszeilenergänzung, Rich-Media-Einbettung und verschiedene Editoren (Terminal, Qt-basiert oder browserbasiert) ermöglichen es, Python-Anwendungen als auch Machine Learning-Projekte komfortabel zu entwickeln und gleichzeitig zu dokumentieren. Datenanalysten sind bei der Arbeit mit Juypter nicht auf Python als Programmiersprache begrenzt, sondern können ebenso auch sog. Kernels für Julia, R und vielen anderen Sprachen einbinden. Ein Jupyter Notebook besteht aus einer Reihe von “Zellen”, die in einer Sequenz angeordnet sind. Jede Zelle kann entweder Text oder (Live-)Code enthalten und ist beliebig verschiebbar. Texte lassen sich in den Zellen mit einer einfachen Markup-Sprache formatieren, komplexe Formeln wie mit einer Ausgabe in LaTeX darstellen. Code-Zellen enthalten Code in der Programmiersprache, die dem aktiven Notebook über den entsprechenden Kernel (Python 2 Python 3, R, etc.) zugeordnet wurde. Bild 4 zeigt auszugsweise eine Analyse historischer Hauspreise in Abhängigkeit ihrer Lage in Kalifornien, USA (Daten und Notebook sind öffentlich erhältlich [7]). Notebooks erlauben es, ganze Machine Learning-Projekte von der Datenbeschaffung bis zur Evaluierung der ML-Modelle reproduzierbar abzubilden und lassen sich gut versionieren. Komplexe ML-Modelle können in Python mit Hilfe des Pickle Moduls, das einen Algorithmus zur Serialisierung und De-Serialisierung implementiert, ebenfalls transportabel gemacht werden.

 

Abbildung 4: Datenbeschaffung, Inspektion, Visualisierung und ML Modell-Training in einem Jupyter Notebook (Pro-grammiersprache: Python)

Ein Problem, auf das man bei der praktischen Arbeit mit lokalen Jupyter-Installationen schnell stößt, lässt sich mit dem “works on my machine”-Syndrom bezeichnen. Kleine Data Sets funktionieren problemlos auf einem lokalen Rechner, wenn sie aber auf die Größe des Produktionsdatenbestandes migriert werden, skaliert das Einlesen und Verarbeiten aller Daten mit einem einzelnen Rechner nicht. Aufgrund dieser Begrenzung liegt der Aufbau einer server-basierten ML-Umgebung mit ausreichend Rechen- und Speicherkapazität auf der Hand. Dabei ist aber die Einrichtung einer solchen ML-Umgebung, insbesondere bei einer on-premise Infrastruktur, eine Herausforderung: Das Infrastruktur-Team muss physische Server und/oder virtuelle Maschinen (VM’s) auf Anforderung bereitstellen und integrieren. Dieser Ansatz ist aufgrund vieler manueller Arbeitsschritte zeitaufwändig und fehleranfällig. Mit dem Einsatz Cloud-basierter Technologien vereinfacht sich dieser Prozess deutlich. Die Möglichkeit, Infrastructure on Demand zu verwenden und z.B. mit einem skalierbaren Cloud-Data Warehouse zu kombinieren, bietet sofortigen Zugriff auf Rechen- und Speicher-Ressourcen, wann immer sie benötigt werden und reduziert den administrativen Aufwand bei Einrichtung und Verwaltung der zum Einsatz kommenden ML-Software. Bild 5 zeigt den Code-Ausschnitt aus einem Jupyter Notebook, das im Rahmen des Cloud Services Amazon SageMaker bereitgestellt wird und via PySpark Kernel auf einen Multi-Node Apache Spark Cluster (in einer Amazon EMR-Umgebung) zugreift. In diesem Szenario wird aus einem Snowflake Cloud Data Warehouse ein größeres Data Set mit 220 Millionen Datensätzen via Spark-Connector komplett in ein Spark Dataframe geladen und im Spark Cluster weiterverarbeitet. Den vollständigen Prozess inkl. Einrichtung und Konfiguration aller Komponenten, beschreibt eine vierteilige Blog-Serie [8]). Mit Spark Cluster sowie Snowflake stehen für sich genommen zwei leistungsfähige Umgebungen für rechenintensive Aufgaben zur Verfügung. Mit dem aktuellen Snowflake Connector für Spark ist eine intelligente Arbeitsteilung mittels Query Pushdown erreichbar. Dabei entscheidet Spark’s optimizer (Catalyst), welche Aufgaben (Queries) aufgrund der effizienteren Verarbeitung an Snowflake delegiert werden [9].

Abbildung 5: Jupyter Notebook in der Cloud – integriert mit Multi-Node Spark Cluster und Snowflake Cloud Data Warehouse

Welches Machine Learning Framework für welche Aufgabenstellung?

Bevor die nächsten Abschnitte weitere Werkzeuge und Technologien betrachten, macht es nicht nur für Data Scientists sondern auch für IT-Architekten Sinn, zunächst einen Überblick auf die derzeit verfügbaren Machine Learning Frameworks zu bekommen. Aus Architekturperspektive ist es wichtig zu verstehen, welche Aufgabenstellungen die jeweiligen ML-Frameworks adressieren, welche technischen Anforderungen und ggf. auch Abhängigkeiten zu den verfügbaren Datenquellen bestehen. Ein gemeinsamer Nenner vieler gescheiterter Machine Learning-Projekte ist häufig die Auswahl des falschen Frameworks. Ein Beispiel: TensorFlow ist aktuell eines der wichtigsten Frameworks zur Programmierung von neuronalen Netzen, Deep Learning Modellen sowie anderer Machine Learning Algorithmen. Während Deep Learning perfekt zur Untersuchung komplexer Daten wie Bild- und Audiodaten passt, wird es zunehmend auch für Use Cases benutzt, für die andere Frameworks besser geeignet sind. Bild 6 zeigt eine kompakte Entscheidungsmatrix [10] für die derzeit verbreitetsten ML-Frameworks und adressiert häufige Praxisprobleme: Entweder werden Algorithmen benutzt, die für den Use Case nicht oder kaum geeignet sind oder das gewählte Framework kann die aufkommenden Datenmengen nicht bewältigen. Die Unterteilung der Frameworks in Small Data, Big Data und Complex Data ist etwas plakativ, soll aber bei der Auswahl der Frameworks nach Art und Volumen der Daten helfen. Die Grenze zwischen Big Data zu Small Data ist dabei dort zu ziehen, wo die Datenmengen so groß sind, dass sie nicht mehr auf einem einzelnen Computer, sondern in einem verteilten Cluster ausgewertet werden müssen. Complex Data steht in dieser Matrix für unstrukturierte Daten wie Bild- und Audiodateien, für die sich Deep Learning Frameworks sehr gut eignen.

Abbildung 6: Entscheidungsmatrix zu aktuell verbreiteten Machine Learning Frameworks

Self-Service Machine Learning in Business Intelligence-Tools

Mit einfach zu bedienenden Business Intelligence-Werkzeugen zur Datenvisualisierung ist es für Analytiker und für weniger technisch versierte Anwender recht einfach, komplexe Daten aussagekräftig in interaktiven Dashboards zu präsentieren. Hersteller wie Tableau, Qlik und Oracle spielen ihre Stärken insbesondere im Bereich Visual Analytics aus. Statt statische Berichte oder Excel-Dateien vor dem nächsten Meeting zu verschicken, erlauben moderne Besprechungs- und Kreativräume interaktive Datenanalysen am Smartboard inklusive Änderung der Abfragefilter, Perspektivwechsel und Drill-downs. Im Rahmen von Data Science-Projekten können diese Werkzeuge sowohl zur Exploration von Daten als auch zur Visualisierung der Ergebnisse komplexer Machine Learning-Modelle sinnvoll eingesetzt werden. Prognosen, Scores und weiterer ML-Modell-Output lässt sich so schneller verstehen und unterstützt die Entscheidungsfindung bzw. Ableitung der nächsten Maßnahmen für den Geschäftsprozess. Im Rahmen einer IT-Gesamtarchitektur sind Analyse-Notebooks und Datenvisualisierungswerkzeuge für die Standard-Analytics-Toolbox Unternehmens gesetzt. Mit Hinblick auf effiziente Team-Zusammenarbeit, unternehmensinternen Austausch und Kommunikation von Ergebnissen sollte aber nicht nur auf reine Desktop-Werkzeuge gesetzt, sondern Server-Lösungen betrachtet und zusammen mit einem Nutzerkonzept eingeführt werden, um zehnfache Report-Dubletten, konkurrierende Statistiken („MS Excel Hell“) einzudämmen.

Abbildung 7: Datenexploration in Tableau – leicht gemacht für Fachanwender und Data Scientists

 

Zusätzliche Statistikfunktionen bis hin zur Möglichkeit R- und Python-Code bei der Analyse auszuführen, öffnet auch Fachanwender die Tür zur Welt des Maschinellen Lernens. Bild 7 zeigt das Werkzeug Tableau Desktop mit der Analyse kalifornischer Hauspreise (demselben Datensatz wie oben im Jupyter Notebook-Abschnitt wie in Bild 4) und einer Heatmap-Visualisierung zur Hervorhebung der teuersten Wohnlagen. Mit wenigen Klicks ist auch der Einsatz deskriptiver Statistik möglich, mit der sich neben Lagemaßen (Median, Quartilswerte) auch Streuungsmaße (Spannweite, Interquartilsabstand) sowie die Form der Verteilung direkt aus dem Box-Plot in Bild 7 ablesen und sogar über das Vorhandensein von Ausreißern im Datensatz eine Feststellung treffen lassen. Vorteil dieser Visualisierungen sind ihre hohe Informationsdichte, die allerdings vom Anwender auch richtig interpretiert werden muss. Bei der Beurteilung der Attribute, mit ihren Wertausprägungen und Abhängigkeiten innerhalb des Data Sets, benötigen Citizen Data Scientists (eine Wortschöpfung von Gartner) allerdings dann doch die mathematischen bzw. statistischen Grundlagen, um Falschinterpretationen zu vermeiden. Fraglich ist auch der Nutzen des Data Flow Editors [11] in Oracle Data Visualization, mit dem eins oder mehrere der im Werkzeug integrierten Machine Learning-Modelle trainiert und evaluiert werden können: technisch lassen sich Ergebnisse erzielen und anhand einiger Performance-Metriken die Modellgüte auch bewerten bzw. mit anderen Modellen vergleichen – aber wer kann die erzielten Ergebnisse (wissenschaftlich) verteidigen? Gleiches gilt für die Integration vorhandener R- und Python Skripte, die am Ende dann doch eine Einweisung der Anwender bzgl. Parametrisierung der ML-Modelle und Interpretationshilfen bei den erzielten Ergebnissen erfordern.

Machine Learning in und mit Datenbanken

Die Nutzung eingebetteter 1-click Analytics-Funktionen der oben vorgestellten Data Visualization-Tools ist zweifellos komfortabel und zum schnellen Experimentieren geeignet. Der gegenteilige und eher puristische Ansatz wäre dagegen die Implementierung eigener Machine Learning Modelle in der Datenbank. Für die Umsetzung des gewählten Algorithmus reichen schon vorhandene Bordmittel in der Datenbank aus: SQL inklusive mathematischer und statistische SQL-Funktionen, Tabellen zum Speichern der Ergebnisse bzw. für das ML-Modell-Management und Stored Procedures zur Abbildung komplexer Geschäftslogik und auch zur Ablaufsteuerung. Solange die Algorithmen ausreichend skalierbar sind, gibt es viele gute Gründe, Ihre Data Warehouse Engine für ML einzusetzen:

  • Einfachheit – es besteht keine Notwendigkeit, eine andere Compute-Plattform zu managen, zwischen Systemen zu integrieren und Daten zu extrahieren, transferieren, laden, analysieren usw.
  • Sicherheit – Die Daten bleiben dort, wo sie gut geschützt sind. Es ist nicht notwendig, Datenbank-Anmeldeinformationen in externen Systemen zu konfigurieren oder sich Gedanken darüber zu machen, wo Datenkopien verteilt sein könnten.
  • Performance – Eine gute Data Warehouse Engine verwaltet zur Optimierung von SQL Abfragen viele Metadaten, die auch während des ML-Prozesses wiederverwendet werden könnten – ein Vorteil gegenüber General-purpose Compute Plattformen.

Die Implementierung eines minimalen, aber legitimen ML-Algorithmus wird in [12] am Beispiel eines Entscheidungsbaums (Decision Tree) im Snowflake Data Warehouse gezeigt. Decision Trees kommen für den Aufbau von Regressions- oder Klassifikationsmodellen zum Einsatz, dabei teilt man einen Datensatz in immer kleinere Teilmengen auf, die ihrerseits in einem Baum organisiert sind. Bild 8 zeigt die Snowflake Benutzer­oberfläche und ein Ausschnitt von der Stored Procedure, die dynamisch alle SQL-Anweisungen zur Berechnung des Decision Trees nach dem ID3 Algorithmus [13] generiert.

Abbildung 8: Snowflake SQL-Editor mit Stored Procedure zur Berechnung eines Decission Trees

Allerdings ist der Entwicklungs- und Implementierungsprozess für ein Machine Learning Modell umfassender: Es sind relevante Daten zu identifizieren und für das ML-Modell vorzubereiten. Einfach Rohdaten bzw. nicht aggregierten Informationen aus Datenbanktabellen zu extrahieren reicht nicht aus, stattdessen benötigt ein ML-Modell als Input eine flache, meist sehr breite Tabelle mit vielen Aggregaten, die als Features bezeichnet werden. Erst dann kann der Prozess fortgesetzt und der für die Aufgabenstellung ausgewählte Algorithmus trainiert und die Modellgüte bewertet werden. Ist das Ergebnis zufriedenstellend, steht die Implementierung des ML-Modells in der Zielumgebung an und muss sich künftig beim Scoring „frischer Datensätze“ bewähren. Viele zeitaufwändige Teilaufgaben also, bei der zumindest eine Teilautomatisierung wünschenswert wäre. Allein die Datenaufbereitung kann schon bis zu 70…80% der gesamten Projektzeit beanspruchen. Und auch die Implementierung eines ML-Modells wird häufig unterschätzt, da in Produktionsumgebungen der unterstützte Technologie-Stack definiert und ggf. für Machine Learning-Aufgaben erweitert werden muss. Daher ist es reizvoll, wenn das Datenbankmanagement-System auch hier einsetzbar ist – sofern die geforderten Algorithmen dort abbildbar sind. Wie ein ML-Modell für die Kundenabwanderungsprognose (Churn Prediction) werkzeuggestützt mit Xpanse AI entwickelt und beschleunigt im Snowflake Cloud Data Warehouse bereitgestellt werden kann, beschreibt [14] sehr anschaulich: Die benötigten Datenextrakte sind schnell aus Snowflake entladen und stellen den Input für ein neues Xpanse AI-Projekt dar. Sobald notwendige Tabellenverknüpfungen und andere fachliche Informationen hinterlegt sind, analysiert das Tool Datenstrukturen und transformiert alle Eingangstabellen in eine flache Zwischentabelle (u.U. mit Hunderten von Spalten), auf deren Basis im Anschluss ML-Modelle trainiert werden. Nach dem ML-Modell-Training erfolgt die Begutachtung der Ergebnisse: das erstellte Dataset, Güte des ML-Modells und der generierte SQL(!) ETL-Code zur Erstellung der Zwischentabelle sowie die SQL-Repräsentation des ML-Modells, das basierend auf den Input-Daten Wahrscheinlichkeitswerte berechnet und in einer Scoring-Tabelle ablegt. Die Vorteile dieses Ansatzes sind liegen auf der Hand: kürzere Projektzeiten, der Einsatz im Rahmen des Snowflake Cloud Data Warehouse, macht das Experimentieren mit der Zuweisung dedizierter Compute-Ressourcen für die performante Verarbeitung äußerst einfach. Grenzen liegen wiederum bei der zur Verfügung stehenden Algorithmen.

Spezialisierte Software Suites für Machine Learning

Während sich im Markt etablierte Business Intelligence- und Datenintegrationswerkzeuge mit Erweiterungen zur Ausführung von Python- und R-Code als notwendigen Bestandteil der Analyse-Toolbox für den Data Science Prozess positionieren, gibt es daneben auch Machine-Learning-Plattformen, die auf die Arbeit mit künstlicher Intelligenz (KI) zugeschnittenen sind. Für den Einstieg in Data Science bieten sich die oft vorhandenen quelloffenen Distributionen an, die auch über Enterprise-Versionen mit erweiterten Möglichkeiten für beschleunigtes maschinelles Lernen durch Einsatz von Grafikprozessoren (GPUs), bessere Skalierung sowie Funktionen für das ML-Modell Management (z.B. durch Versionsmanagement und Automatisierung) verfügen.

Eine beliebte Machine Learning-Suite ist das Open Source Projekt H2O. Die Lösung des gleichnamigen kalifornischen Unternehmens verfügt über eine R-Schnittstelle und ermöglicht Anwendern dieser statistischen Programmiersprache Vorteile in puncto Performance. Die in H2O verfügbaren Funktionen und Algorithmen sind optimiert und damit eine gute Alternative für das bereits standardmäßig in den R-Paketen verfügbare Funktionsset. H2O implementiert Algorithmen aus dem Bereich Statistik, Data-Mining und Machine Learning (generalisierte Lineare Modelle, K-Means, Random Forest, Gradient Boosting und Deep Learning) und bietet mit einer In-Memory-Architektur und durch standardmäßige Parallelisierung über alle vorhandenen Prozessorkerne eine gute Basis, um komplexe Machine-Learning-Modelle schneller trainieren zu können. Bild 9 zeigt wieder anhand des Datensatzes zur Analyse der kalifornischen Hauspreise die webbasierte Benutzeroberfläche H20 Flow, die den oben beschriebenen Juypter Notebook-Ansatz mit zusätzlich integrierter Benutzerführung für die wichtigsten Prozessschritte eines Machine-Learning-Projektes kombiniert. Mit einigen Klicks kann das California Housing Dataset importiert, in einen H2O-spezifischen Dataframe umgewandelt und anschließend in Trainings- und Testdatensets aufgeteilt werden. Auswahl, Konfiguration und Training der Machine Learning-Modelle erfolgt entweder durch den Anwender im Einsteiger-, Fortgeschrittenen- oder Expertenmodus bzw. im Auto-ML-Modus. Daran anschließend erlaubt H20 Flow die Vorhersage für die Zielvariable (im Beispiel: Hauspreis) für noch unbekannte Datensätze und die Aufbereitung der Ergebnismenge. Welche Unterstützung H2O zur Produktivsetzung von ML-Modellen anbietet, wird an einem Beispiel in den folgenden Abschnitten betrachtet.

Abbildung 9: H2O Flow Benutzeroberfläche – Datenaufbereitung, ML-Modell-Training und Evaluierung.

Vom Prototyp zur produktiven Machine Learning-Lösung

Warum ist es für viele Unternehmen noch schwer, einen Nutzen aus ihren ersten Data Science-Aktivitäten, Data Labs etc. zu ziehen? In der Praxis zeigt sich, erst durch Operationalisierung von Machine Learning-Resultaten in der Produktionsumgebung entsteht echter Geschäftswert und nur im Tagesgeschäft helfen robuste ML-Modelle mit hoher Güte bei der Erreichung der gesteckten Unternehmensziele. Doch leider erweist sich der Weg vom Prototypen bis hin zum Produktiveinsatz bei vielen Initativen noch als schwierig. Bild 10 veranschaulicht ein typisches Szenario: Data Science-Teams fällt es in ihrer Data Lab-Umgebung technisch noch leicht, Prototypen leistungsstarker ML-Modelle mit Hilfe aktueller ML-Frameworks wie TensorFlow-, Keras- und Word2Vec auf ihren Laptops oder in einer Sandbox-Umgebung zu erstellen. Doch je nach verfügbarer Infrastruktur kann, wegen Begrenzungen bei Rechenleistung oder Hauptspeicher, nur ein Subset der Produktionsdaten zum Trainieren von ML-Modellen herangezogen werden. Ergebnispräsentationen an die Stakeholder der Data Science-Projekte erfolgen dann eher durch Storytelling in MS Powerpoint bzw. anhand eines Demonstrators – selten aber technisch schon so umgesetzt, dass anderere Applikationen z.B. über eine REST-API von dem neuen Risiko Scoring-, dem Bildanalyse-Modul etc. (testweise) Gebrauch machen können. Ausgestattet mit einer Genehmigung vom Management, übergibt das Data Science-Team ein (trainiertes) ML-Modell an das Software Engineering-Team. Nach der Übergabe muss sich allerdings das Engineering-Team darum kümmern, dass das ML-Modell in eine für den Produktionsbetrieb akzeptierte Programmiersprache, z.B. in Java, neu implementiert werden muss, um dem IT-Unternehmensstandard (siehe Line of Governance in Bild 10) bzw. Anforderungen an Skalierbarkeit und Laufzeitverhalten zu genügen. Manchmal sind bei einem solchen Extraschritt Abweichungen beim ML-Modell-Output und in jedem Fall signifikante Zeitverluste beim Deployment zu befürchten.

Abbildung 10: Übergabe von Machine Learning-Resultaten zur Produktivsetzung im Echtbetrieb

Unterstützt das Data Science-Team aktiv bei dem Deployment, dann wäre die Einbettung des neu entwickelten ML-Modells in eine Web-Applikation eine beliebte Variante, bei der typischerweise Flask, Tornado (beides Micro-Frameworks für Python) und Shiny (ein auf R basierendes HTML5/CSS/JavaScript Framework) als Technologiekomponenten zum Zuge kommen. Bei diesem Vorgehen müssen ML-Modell, Daten und verwendete ML-Pakete/Abhängigkeiten in einem Format verpackt werden, das sowohl in der Data Science Sandbox als auch auf Produktionsservern lauffähig ist. Für große Unternehmen kann dies einen langwierigen, komplexen Softwareauslieferungsprozess bedeuten, der ggf. erst noch zu etablieren ist. In dem Zusammenhang stellt sich die Frage, wie weit die Erfahrung des Data Science-Teams bei der Entwicklung von Webanwendungen reicht und Aspekte wie Loadbalancing und Netzwerkverkehr ausreichend berücksichtigt? Container-Virtualisierung, z.B. mit Docker, zur Isolierung einzelner Anwendungen und elastische Cloud-Lösungen, die on-Demand benötigte Rechenleistung bereitstellen, können hier Abhilfe schaffen und Teil der Lösungsarchitektur sein. Je nach analytischer Aufgabenstellung ist das passende technische Design [15] zu wählen: Soll das ML-Modell im Batch- oder Near Realtime-Modus arbeiten? Ist ein Caching für wiederkehrende Modell-Anfragen vorzusehen? Wie wird das Modell-Deployment umgesetzt, In-Memory, Code-unabhängig durch Austauschformate wie PMML, serialisiert via R- oder Python-Objekte (Pickle) oder durch generierten Code? Zusätzlich muss für den Produktiveinsatz von ML-Modellen auch an unterstützenden Konzepten zur Bereitstellung, Routing, Versions­management und Betrieb im industriellen Maßstab gearbeitet werden, damit zuverlässige Machine Learning-Produkte bzw. -Services zur internen und externen Nutzung entstehen können (siehe dazu Bild 11)

Abbildung 11: Unterstützende Funktionen für produktive Machine Learning-Lösungen

Die Deployment-Variante „Machine Learning Code-Generierung“ lässt sich gut an dem bereits mit H2O Flow besprochenen Beispiel veranschaulichen. Während Bild 9 hierzu die Schritte für Modellaufbau, -training und -test illustriert, zeigt Bild 12 den Download-Vorgang für den zuvor generierten Java-Code zum Aufbau eines ML-Modells zur Vorhersage kalifornischer Hauspreise. In dem generierten Java-Code sind die in H2O Flow vorgenommene Datenaufbereitung sowie alle Konfigurationen für den Gradient Boosting Machine (GBM)-Algorithmus gut nachvollziehbar, Bild 13 gibt mit den ersten Programmzeilen einen ersten Eindruck dazu und erinnert gleichzeitig an den ähnlichen Ansatz der oben mit dem Snowflake Cloud Data Warehouse und dem Tool Xpanse AI bereits beschrieben wurde.

Abbildung 12: H2O Flow Benutzeroberfläche – Java-Code Generierung und Download eines trainierten Models

Abbildung 13: Generierter Java-Code eines Gradient Boosted Machine – Modells zur Vorhersage kaliforn. Hauspreise

Nach Abschluss der Machine Learning-Entwicklung kann der Java-Code des neuen ML-Modells, z.B. unter Verwendung der Apache Kafka Streams API, zu einer Streaming-Applikation hinzugefügt und publiziert werden [16]. Vorteil dabei: Die Kafka Streams-Applikation ist selbst eine Java-Applikation, in die der generierte Code des ML-Modells eingebettet werden kann (siehe Bild 14). Alle zukünftigen Events, die neue Immobilien-Datensätze zu Häusern aus Kalifornien mit (denselben) Features wie Geoposition, Alter des Gebäudes, Anzahl Zimmer etc. enthalten und als ML-Modell-Input über Kafka Streams hereinkommen, werden mit einer Vorhersage des voraussichtlichen Gebäudepreises von dem auf historischen Daten trainierten ML-Algorithmus beantwortet. Ein Vorteil dabei: Weil die Kafka Streams-Applikation unter der Haube alle Funktionen von Apache Kafka nutzt, ist diese neue Anwendung bereits für den skalierbaren und geschäftskritischen Einsatz ausgelegt.

Abbildung 14: Deployment des generierten Java-Codes eines H2O ML-Models in einer Kafka Streams-Applikation

Machine Learning as a Service – “API-first” Ansatz

In den vorherigen Abschnitten kam bereits die Herausforderung zur Sprache, wenn es um die Überführung der Ergebnisse eines Datenexperiments in eine Produktivumgebung geht. Während die Mehrheit der Mitglieder eines Data Science Teams bevorzugt R, Python (und vermehrt Julia) als Programmiersprache einsetzen, gibt es auf der Abnehmerseite das Team der Softwareingenieure, die für technische Implementierungen in der Produktionsumgebung zuständig sind, womöglich einen völlig anderen Technologie-Stack verwenden (müssen). Im Extremfall droht das Neuimplementieren eines Machine Learning-Modells, im besseren Fall kann Code oder die ML-Modellspezifikation transferiert und mit wenig Aufwand eingebettet (vgl. das Beispiel H2O und Apache Kafka Streams Applikation) bzw. direkt in einer neuen Laufzeitumgebung ausführbar gemacht werden. Alternativ wählt man einen „API-first“-Ansatz und entkoppelt das Zusammenwirken von unterschiedlich implementierten Applikationen bzw. -Applikationsteilen via Web-API’s. Data Science-Teams machen hierzu z.B. die URL Endpunkte ihrer testbereiten Algorithmen bekannt, die von anderen Softwareentwicklern für eigene „smarte“ Applikationen konsumiert werden. Durch den Aufbau von REST-API‘s kann das Data Science-Team den Code ihrer ML-Modelle getrennt von den anderen Teams weiterentwickeln und damit eine Arbeitsteilung mit klaren Verantwortlichkeiten herbeiführen, ohne Teamkollegen, die nicht am Machine Learning-Aspekt des eines Projekts beteiligt sind, bei ihrer Arbeit zu blockieren.

Bild 15 zeigt ein einfaches Szenario, bei dem die Gegenstandserkennung von beliebigen Bildern mit einem Deep Learning-Verfahren umgesetzt ist. Einzelne Fotos können dabei via Kommandozeileneditor als Input für die Bildanalyse an ein vortrainiertes Machine Learning-Modell übermittelt werden. Die Information zu den erkannten Gegenständen inkl. Wahrscheinlichkeitswerten kommt dafür im Gegenzug als JSON-Ausgabe zurück. Für die Umsetzung dieses Beispiels wurde in Python auf Basis der Open Source Deep-Learning-Bibliothek Keras, ein vortrainiertes ML-Modell mit Hilfe des Micro Webframeworks Flask über eine REST-API aufrufbar gemacht. Die in [17] beschriebene Applikation kümmert sich außerdem darum, dass beliebige Bilder via cURL geladen, vorverarbeitet (ggf. Wandlung in RGB, Standardisierung der Bildgröße auf 224 x 224 Pixel) und dann zur Klassifizierung der darauf abgebildeten Gegenstände an das ML-Modell übergeben wird. Das ML-Modell selbst verwendet eine sog. ResNet50-Architektur (die Abkürzung steht für 50 Layer Residual Network) und wurde auf Grundlage der öffentlichen ImageNet Bilddatenbank [18] vortrainiert. Zu dem ML-Modell-Input (in Bild 15: Fußballspieler in Aktion) meldet das System für den Tester nachvollziehbare Gegenstände wie Fußball, Volleyball und Trikot zurück, fragliche Klassifikationen sind dagegen Taschenlampe (Torch) und Schubkarre (Barrow).

Abbildung 15: Gegenstandserkennung mit Machine Learning und vorgegebenen Bildern via REST-Service

Bei Aufbau und Bereitstellung von Machine Learning-Funktionen mittels REST-API’s bedenken IT-Architekten und beteiligte Teams, ob der Einsatzzweck eher Rapid Prototyping ist oder eine weitreichende Nutzung unterstützt werden muss. Während das oben beschriebene Szenario mit Python, Keras und Flask auf einem Laptop realisierbar ist, benötigen skalierbare Deep Learning Lösungen mehr Aufmerksamkeit hinsichtlich der Deployment-Architektur [19], in dem zusätzlich ein Message Broker mit In-Memory Datastore eingehende bzw. zu analysierende Bilder puffert und dann erst zur Batch-Verarbeitung weiterleitet usw. Der Einsatz eines vorgeschalteten Webservers, Load Balancers, Verwendung von Grafikprozessoren (GPUs) sind weitere denkbare Komponenten für eine produktive ML-Architektur.

Als abschließendes Beispiel für einen leistungsstarken (und kostenpflichtigen) Machine Learning Service soll die Bildanalyse von Google Cloud Vision [20] dienen. Stellt man dasselbe Bild mit der Fußballspielszene von Bild 15 und Bild 16 bereit, so erkennt der Google ML-Service neben den Gegenständen weit mehr Informationen: Kontext (Teamsport, Bundesliga), anhand der Gesichtserkennung den Spieler selbst  und aktuelle bzw. vorherige Mannschaftszugehörigkeiten usw. Damit zeigt sich am Beispiel des Tech-Giganten auch ganz klar: Es kommt vorallem auf die verfügbaren Trainingsdaten an, inwieweit dann mit Algorithmen und einer dazu passenden Automatisierung (neue) Erkenntnisse ohne langwierigen und teuren manuellen Aufwand gewinnen kann. Einige Unternehmen werden feststellen, dass ihr eigener – vielleicht einzigartige – Datenschatz einen echten monetären Wert hat?

Abbildung 16: Machine Learning Bezahlprodukt (Google Vision)

Fazit

Machine Learning ist eine interessante “Challenge” für Architekten. Folgende Punkte sollte man bei künftigen Initativen berücksichtigen:

  • Finden Sie das richtige Geschäftsproblem bzw geeignete Use Cases
  • Identifizieren und definieren Sie die Einschränkungen (Sind z.B. genug Daten vorhanden?) für die zu lösende Aufgabenstellung
  • Nehmen Sie sich Zeit für das Design von Komponenten und Schnittstellen
  • Berücksichtigen Sie frühzeitig mögliche organisatorische Gegebenheiten und Einschränkungen
  • Denken Sie nicht erst zum Schluss an die Produktivsetzung Ihrer analytischen Modelle oder Machine Learning-Produkte
  • Der Prozess ist insgesamt eine Menge Arbeit, aber es ist keine Raketenwissenschaft.

Quellenverzeichnis

[1] Bill Schmarzo: “What’s the Difference Between Data Integration and Data Engineering?”, LinkedIn Pulse -> Link, 2018
[2] William Vorhies: “CRISP-DM – a Standard Methodology to Ensure a Good Outcome”, Data Science Central -> Link, 2016
[3] Bill Schmarzo: “A Winning Game Plan For Building Your Data Science Team”, LinkedIn Pulse -> Link, 2018
[4] D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo, D. Dennison: “Hidden technical debt in Machine learning systems”. In NIPS’15 Proceedings of the 28th International Conference on Neural Information Processing Systems – Volume 2, 2015
[5] K. Bollhöfer: „Data Science – the what, the why and the how!“, Präsentation von The unbelievable Machine Company, 2015
[6] Carlton E. Sapp: “Preparing and Architecting for Machine Learning”, Gartner, 2017
[7] A. Geron: “California Housing” Dataset, Jupyter Notebook. GitHub.com -> Link, 2018
[8] R. Fehrmann: “Connecting a Jupyter Notebook to Snowflake via Spark” -> Link, 2018
[9] E. Ma, T. Grabs: „Snowflake and Spark: Pushing Spark Query Processing to Snowflake“ -> Link, 2017
[10] Dr. D. James: „Entscheidungsmatrix „Machine Learning“, it-novum.com ->  Link, 2018
[11] Oracle Analytics@YouTube: “Oracle DV – ML Model Comparison Example”, Video -> Link
[12] J. Weakley: Machine Learning in Snowflake, Towards Data Science Blog -> Link, 2019
[13] Dr. S. Sayad: An Introduction to Data Science, Website -> Link, 2019
[14] U. Bethke: Build a Predictive Model on Snowflake in 1 day with Xpanse AI, Blog à Link, 2019
[15] Sergei Izrailev: Design Patterns for Machine Learning in Production, Präsentation H2O World, 2017
[16] K. Wähner: How to Build and Deploy Scalable Machine Learning in Production with Apache Kafka, Confluent Blog -> Link, 2017
[17] A. Rosebrock: “Building a simple Keras + deep learning REST API”, The Keras Blog -> Link, 2018
[18] Stanford Vision Lab, Stanford University, Princeton University: Image database, Website -> Link
[19] A. Rosebrock: “A scalable Keras + deep learning REST API”, Blog -> Link, 2018
[20] Google Cloud Vision API (Beta Version) -> Link, abgerufen 2018

 

 

 

 

Interview: Profitiert Business Intelligence vom Data Warehouse in der Cloud?

Interview mit Ross Perez, Senior Director, Marketing EMEA bei Snowflake

Read this Article in English:
“Does Business Intelligence benefit from Cloud Data Warehousing?”

Profitiert Business Intelligence vom Cloud Data Warehousing?

Ross Perez ist Senior Director Marketing EMEA bei Snowflake. Er leitet das Snowflake-Marketingteam in EMEA und ist damit beauftragt, die Diskussion über Analysen, Daten und Cloud-Data-Warehousing in EMEA voran zu bringen. Vor Snowflake war Ross Produkt Marketer bei Tableau Software, wo er die Iron Viz Championship gründete, den weltweit größten und aufwändigsten Wettbewerb für Datenvisualisierung.

Data Science Blog: Ross, Business Intelligence (BI) ist kein wirklich neuer Trend. In 2019/2020 sollte es kein Thema mehr sein, Daten für das ganze Unternehmen verfügbar zu machen. Stimmt das soweit?

BI ist definitiv ein alter Trend, denn Berichterstattung gibt es schon seit 50 Jahren. Die Menschen sind es gewohnt, Statistiken und Daten für das gesamte Unternehmen und sogar für ihre Geschäftsbereiche zu erhalten. Die Verwendung von BI zur Bereitstellung von Analysen für alle Mitarbeiter im Unternehmen und die Ermutigung zur Entscheidungsfindung auf der Grundlage von Daten für den jeweiligen Bereich ist jedoch relativ neu. In vielen Unternehmen, mit denen Snowflake zusammenarbeitet, gibt es eine neue Gruppe von Mitarbeitern, die gerade erst den Zugriff auf Self-Service-BI- und Visualisierungstools wie Tableau, Looker und Sigma erhalten haben und nun auch anfangen, Antworten auf ihre Fragen zu finden.

Data Science Blog: Bi jetzt ging es im BI vor allem darum Dashboards für Geschäftsberichte zu erstellen. Und dabei spielte das Data Warehouse (DWH) die Rolle des Backends. Heute haben wir einen noch viel größeren Bedarf an Datentransparenz. Wie sollten Unternehmen damit umgehen?

Da immer mehr Mitarbeiter in immer mehr Abteilungen immer häufiger auf Daten zugreifen möchten, steigt die Nachfrage nach Back-End-Systemen – wie dem Data Warehouse – rapide. In vielen Fällen verfügen Unternehmen über Data Warehouses, die nicht für diese gleichzeitige und heterogene Nachfrage gebaut wurden. Die Erfahrungen der Mitarbeiter mit dem DWH und BI sind daher oftmals schlecht, denn Endbenutzer müssen lange auf ihre Berichte warten. Und nun kommt Snowflake ins Spiel: Da wir die Leistung der Cloud nutzen können, um Ressourcen auf Abruf bereitzustellen, können wir beliebig viele Benutzer gleichzeitig bedienen. Snowflake kann zudem unbegrenzte Datenmengen sowohl in strukturierten als auch in halbstrukturierten Formaten speichern.

Data Science Blog: Würden Sie sagen, dass das DWH der Schlüssel dazu ist, ein datengetriebenes Unternehmen zu werden? Was sollte noch bedacht werden?

Absolut. Ohne alle Ihre Daten in einem einzigen, hoch-elastischen und flexiblen Data Warehouse zu haben, kann es eine große Herausforderung sein, den Mitarbeitern im Unternehmen Einblicke zu gewähren.

Data Science Blog: So viel zur Theorie, lassen Sie uns nun über spezifische Anwendungsfälle sprechen. Generell macht es einen großen Unterschied, welche Daten wir speichern und analysieren wollen, beispielsweise Finanz- oder Maschinendaten. Was dürfen wir dabei nicht vergessen, wenn es um die Erstellung eines DWHs geht?

Finanzdaten und Maschinendaten sind sehr unterschiedlich und liegen häufig in unterschiedlichen Formaten vor. Beispielsweise weisen Finanzdaten häufig ein relationales Standardformat auf. Daten wie diese müssen mit Standard-SQL einfach abgefragt werden können, was viele Hadoop- und noSQL-Tools nicht sinnvoll bereitstellen konnten. Zum Glück handelt es sich bei Snowflake um ein SQL-Data-Warehouse nach ANSI-Standard, sodass die Verwendung dieser Art von Daten problemlos möglich ist.

Zum anderen sind Maschinendaten häufig teilstrukturiert oder sogar völlig unstrukturiert. Diese Art von Daten wird mit dem Aufkommen von Internet of Things (IoT) immer häufiger, aber herkömmliche Data Warehouses haben sich bisher kaum darauf vorbereitet, da sie für relationale Daten optimiert wurden. Halbstrukturierte Daten wie JSON, Avro, XML, Orc und Parkett können in Snowflake zur Analyse nahtlos in ihrem nativen Format geladen werden. Dies ist wichtig, da Sie die Daten nicht reduzieren müssen, um sie nutzen zu können.

Beide Datentypen sind wichtig und Snowflake ist das erste Data Warehouse, das nahtlos mit beiden zusammenarbeitet.

Data Science Blog: Zurück zum gewöhnlichen Anwendungsfall im Business, also der Erstellung von Verkaufs- und Einkaufs-Berichten für die Business Manager, die auf Daten von ERP-Systemen – wie etwa von Microsoft oder SAP – basieren. Welche Architektur könnte für das DWH die richtige sein? Wie viele Layer braucht ein DWH dafür?

Die Art des Berichts spielt weitgehend keine Rolle, da Sie in jedem Fall ein Data Warehouse benötigen, das alle Ihre Daten unterstützt und alle Ihre Benutzer bedient. Idealerweise möchten Sie es auch in der Lage sein, es je nach Bedarf ein- und auszuschalten. Das bedeutet, dass Sie eine Cloud-basierte Architektur benötigen… und insbesondere die innovative Architektur von Snowflake, die Speicher und Computer voneinander trennt und es Ihnen ermöglicht, genau das zu bezahlen, was Sie verwenden.

Data Science Blog: Wo würden Sie den Hauptteil der Geschäftslogik für einen Report implementieren? Tendenziell eher im DWH oder im BI-Tool, dass für das Reporting verwendet word? Hängt es eigentlich vom BI-Tool ab?

Das Tolle ist, dass Sie es frei wählen können. Snowflake kann als Data Warehouse für SQL nach dem ANSI-Standard ein hohes Maß an Datenmodellierung und Geschäftslogik-Implementierung unterstützen. Sie können aber auch Partner wie Looker und Sigma einsetzen, die sich auf die Datenmodellierung für BI spezialisiert haben. Wir sind der Meinung, dass es am besten ist, wenn jedes Unternehmen für sich selbst entscheidet, was der individuell richtige Ansatz ist.

Data Science Blog: Snowflake ermöglicht es Organisationen, Daten in der Cloud zu speichern und zu verwalten. Heißt das aber auch, dass Unternehmen ein Stück weit die Kontrolle über ihre eigenen Daten verlieren?

Kunden haben die vollständige Kontrolle über ihre Daten und Snowflake kann keinen Teil ihrer Daten sehen oder ändern. Der Vorteil einer Cloud-Lösung besteht darin, dass Kunden weder die Infrastruktur noch das Tuning verwalten müssen. Sie entscheiden, wie sie ihre Daten speichern und analysieren möchten, und Snowflake kümmert sich um den Rest.

Data Science Blog: Wie groß ist der Aufwand für kleinere oder mittelgroße Unternehmen, ein DWH in der Cloud zu errichten? Und bedeutet es auch, dass damit ein teures Langzeit-Projekt verbunden ist?

Das Schöne an Snowflake ist, dass Sie in wenigen Minuten mit einer kostenlosen Testversion beginnen können. Nun kann der Wechsel von einem herkömmlichen Data Warehouse zu Snowflake einige Zeit in Anspruch nehmen, abhängig von der von Ihnen verwendeten Legacy-Technologie. Snowflake selbst ist jedoch recht einfach einzurichten und sehr gut mit historischen Werkzeugen kompatibel. Der Einstieg könnte daher nicht einfacherer sein.

Was der BREXIT für die Cloud-Strategie bedeutet

Datensouveränität wird nach dem Brexit eine der größten Herausforderungen für Unternehmen sein. Geschäftsführer sind sich der Bedeutung dessen bewusst und fürchten die Gefahr eines „Data cliff edge“, wenn die Trennung Großbritanniens von der EU endgültig beschlossene Sache sein wird.

Ohne ein klares Gespür dafür zu haben, welche Vorschriften und Compliance-Anforderungen bald gelten werden, versuchen britische Unternehmen herauszufinden, wie sie ihre Daten bestmöglich schützen, Geschäftsverzögerungen verhindern und kostspielige Fehler vermeiden können. Die Vieldeutigkeit rund um den Brexit wirft mehr Fragen als Antworten auf, darunter: Wo sollten britische Unternehmen ihre Daten speichern? Sollten sie alle ihre Rechenzentren nach Großbritannien verlegen? Wie wirkt sich der Besitz von Rechenzentren auf den Datenschutz aus? Welche Bedrohungen bestehen, wenn nach Abschluss des Brexit Daten innerhalb oder außerhalb des Vereinigten Königreichs gespeichert werden?

Für Führungskräfte sind der Mangel an Antworten und die Angst vor dem Unbekannten frustrierend. In dieser ungewissen Zeit können smarte Geschäftsführer aber den Brexit für ihre Zwecke lenken, indem sie ihn als Chance und nicht als Hindernis für sich nutzen.

Die unsicher regulierte Zukunft

Für Unternehmen mit Sitz in Großbritannien, die Datenspeicherung und private Cloud-Dienste anbieten, ist vor allem der Ort, an dem sich die Daten befinden, von Belang. Die Gewährleistung der Sicherheit und Kontrolle über eigene Daten ist von zentraler Bedeutung. Gleichzeitig ist jedoch auch die Einhaltung unbekannter zukünftiger Vorschriften und Gesetze zum Datenschutz und zum Datentransfer ein Muss.

Grundlage ist die Einhaltung der Datenschutzverordnung (DSGVO) vom 25. Mai 2018, da das Vereinigte Königreich zu diesem Zeitpunkt noch immer Teil der EU war. Nach Angaben des Information Commissioner’s Office (ICO) des Vereinigten Königreichs – einer unabhängigen Behörde, die sich für die Wahrung von Informations- und Datenschutzrechten von Einzelpersonen einsetzt – bestätigte die britische Regierung, dass ein Austritt aus der EU keine Auswirkungen auf die DSGVO haben wird. Was in diesem Jahr, wenn sich Großbritannien und die EU endgültig voneinander trennen, passieren wird, kann man nur vermuten. Die Ratschläge von ICO sind richtungsweisend: „Bereiten Sie sich darauf vor, die Bestimmungen der DSGVO zu erfüllen und voranzukommen.“

Bemerkenswerterweise schreibt die DSGVO nicht vor, wo Unternehmen ihre Daten aufbewahren müssen. Es ist lediglich erforderlich, dass die EU-Organisationen ihre Daten innerhalb der EU speichern und außerhalb der EU unzugänglich machen müssen. Ausnahme: die Daten betreffen eine DSGVO-konforme Organisation. Wie sich dieses Mandat auf das Vereinigte Königreich auswirkt, muss noch gesehen werden. Denn das Vereinigte Königreich war ja zum Zeitpunkt der Ausarbeitung der Verordnung Teil der EU. Es ist unklar, ob das Vereinigte Königreich am Ende mit der DSGVO konform sein wird.

Aus globaler Sicht muss Großbritannien herausfinden, wie der Datenaustausch und der grenzüberschreitende Datenfluss reguliert werden können. Der freie Datenfluss ist wichtig für Unternehmen und Innovation, was bedeutet, dass das Vereinigte Königreich Vereinbarungen, wie die EU sie mit den USA getroffen haben, benötigt. Ein Privacy Shield, das den Austausch personenbezogener Daten zu gewerblichen Zwecken ermöglicht. Ob das Vereinigte Königreich Vereinbarungen wie den Privacy Shield umsetzen kann, oder neue Vereinbarungen mit Ländern wie den USA treffen muss, ist etwas, was nur die Zeit zeigen wird.

Wo sind die Daten?

Rechenzentren können heute durch freien Datenfluss, sowohl im Vereinigten Königreich als auch in der EU betrieben werden. Das Vereinigte Königreich unterliegt gleichem Schutz und gleichen Vorschriften wie die EU. Viele Spekulationen beinhalten allerdings, dass in naher Zukunft britische Kunden von einem in Großbritannien ansässigen Rechenzentrum bedient werden müssen, ebenso wie europäische Kunden ein EU-Rechenzentrum benötigen. Es gibt keine Garantien. Unklar ist auch, ob diese Situation die Anbieter von Rechenzentren dazu veranlassen wird, den Umzug aus Großbritannien in Betracht zu ziehen, um sich stärker auf den Kontinent zu konzentrieren, oder ob sie sich an beiden Standorten gleichzeitig niederlassen werden. Das Wahrscheinlichste: Die Anbieter tendieren zu letzterem, wie auch Amazon Web Services (AWS). Selbst nach dem Brexit-Votum hielt Amazon an seinem Wort fest und eröffnete Ende letzten Jahres sein erstes AWS-Rechenzentrum in London. Dies unterstreicht sowohl sein Engagement für Großbritannien als auch das unternehmerische Engagement.

Aus dem Brexit eine Geschäftsmöglichkeit machen

Die Automatisierung des IT-Betriebs und die Einführung einer Cloud-Strategie könnten die ersten Schritte sein, um die unbeantworteten Fragen des Brexit zu lösen und daraus einen Vorteil zu machen. Es ist an der Zeit, die Vorteile dessen zu erkennen, teure Hardware und Software von Unternehmen vor Ort durch den Umstieg auf die öffentliche Cloud zu ersetzen. Dies ist nicht nur die kostengünstigere Option. Cloud-Anbieter wie AWS, Microsoft Azure und Google Cloud Platform (GCP) ersparen in diesem politischen Umfeld sogar Unternehmen die Verwaltung und Wartung von Rechenzentren. Einige Unternehmen sind möglicherweise besorgt über die steigenden Raten von Public-Cloud-Anbietern, ihre Preisanpassungen scheinen jedoch an den relativen Wertverlust des Sterlings gebunden zu sein. Selbst bei geringen Erhöhungen sind die Preise einiger Anbieter, wie AWS, noch immer deutlich niedriger als die Kosten, die mit dem Betrieb von Rechenzentren und privaten Clouds vor Ort verbunden sind, insbesondere wenn Wartungskosten einbezogen werden. Wenn man diesen Gedanken noch einen Schritt weiterführt, wie kann der Brexit als eine Chance für Unternehmen betrachtet werden?Organisationen sammeln alle Arten von Daten. Aber nur eine Handvoll von ihnen verwendet effektive Datenanalysen, die Geschäftsentscheidungen unterstützen. Nur wenige Unternehmen tun mehr, als ihre Daten zu speichern, da ihnen die Tools und Ressourcen fehlen, um nahtlos auf ihre Daten zuzugreifen, oder weil Abfragen teuer sind. Ohne ein für die Cloud konstruiertes Data Warehouse ist dieser Prozess bestenfalls eine Herausforderung, und der wahre Wert der Daten geht dabei verloren. Ironischerweise bietet der Brexit die Möglichkeit, dies zu ändern, da Unternehmen ihre IT-Abläufe neu bewerten und alternative, kostengünstigere Methoden zum Speichern von Daten suchen müssen. Durch den Wechsel zu einer öffentlichen Cloud und die Nutzung eines Data Warehouses für die Cloud können Unternehmen Beschränkungen und Einschränkungen ihrer Daten aufheben und diese für die Entscheidungsfindung zugänglich machen.

Der Brexit dient also als Katalysator einer datengesteuerten Organisation, die Daten verwendet, anstatt sie für schlechte Zeiten zu speichern. Am Ende scheint die Prognose der Verhandlungen in Brüssel doch eine ziemlich stürmische zu sein.

Cloudera und Hortonworks vollenden geplante Fusion

Kombiniertes „ Open-Source-Powerhouse” wird die branchenweit erste Enterprise Data Cloud vom Netzwerk-Rand (Edge) bis hin zu künstlicher Intelligenz bauen.

München, Palo Alto (Kalifornien), 03. Januar 2019 – Cloudera, Inc. (NYSE: CLDR) hat den Abschluss seiner Fusion mit Hortonworks, Inc. bekanntgegeben. Cloudera wird die erste Enterprise Data Cloud bereitstellen, die die ganze Macht der Daten freisetzt, welche sich in einer beliebigen Cloud vom Netzwerk-Rand (Edge) bis zur KI bewegen –  all dies basierend auf einer hundertprozentigen Open-Source-Datenplattform. Die Enterprise Data Cloud unterstützt sowohl hybride als auch Multi-Cloud-Deployments. Unternehmen erhalten dadurch die nötige Flexibilität, um Machine Learning und Analysen mit ihren Daten, auf ihre Art und Weise und ohne Lock-in durchzuführen.

„Heute startet ein aufregendes neues Kapitel für Cloudera als führender Anbieter von Enterprise Data Clouds”, so Tom Reilly, Chief Executive Officer von Cloudera. „Das kombinierte Team und Technologieportfolio etabliert das neue Cloudera als klaren Marktführer mit der Größe und den Ressourcen für weitere Innovationen und Wachstum. Wir bieten unseren Kunden eine umfassende Lösung, um die richtige Datenanalyse für Daten überall dort bereitzustellen, wo das Unternehmen arbeiten muss, vom Edge bis zur KI, mit der branchenweit ersten Enterprise Data Cloud”.  

Ergänzend dazu stellte das Forschungsunternehmen Forrester fest1, dass „diese Fusion … die Messlatte für Innovationen im Big-Data-Bereich höher legen wird, insbesondere bei der Unterstützung einer durchgehenden Big-Data-Strategie in einer Hybrid- und Multi-Cloud-Umgebung. Wir glauben, dass dies eine Win-Win-Situation für Kunden, Partner und Lieferanten ist.”

Cloudera wird weiterhin unter dem Symbol „CLDR” an der New Yorker Börse gehandelt. Die Aktionäre von Hortonworks erhielten 1,305 Stammaktien von Cloudera für jede Aktie von Hortonworks.

Das Cloudera-Management wird am 10. Januar 2019 um 19:00 Uhr ein Online-Meeting veranstalten, um zu diskutieren, wie das neue Cloudera Innovationen beschleunigen und die erste Enterprise Data Cloud der Branche liefern wird. Registrieren Sie sich jetzt. Die Veranstaltung wird am 14. Januar 2019 um 14:00 Uhr auch für die EMEA-Region stattfinden. Registrieren Sie sich hier für dieses Webinar.

1 „Cloudera And Hortonworks Merger: A Win-Win For All”, Beitrag von Noel Yuhanna im Forrester-Blog (4. Oktober 2018)

Über Cloudera

Bei Cloudera glauben wir, dass Daten morgen Dinge ermöglichen werden, die heute noch unmöglich sind. Wir versetzen Menschen in die Lage, komplexe Daten in klare, umsetzbare Erkenntnisse zu transformieren. Cloudera stellt dafür eine Enterprise Data Cloud bereit – für alle Daten, jederzeit, vom Netzwerkrand (Edge) bis hin zu künstlicher Intelligenz. Mit der Innovationskraft der Open-Source-Community treibt Cloudera die digitale Transformation für die größten Unternehmen der Welt voran. Erfahren Sie mehr unter  de.cloudera.com/.

Cloudera und damit verbundene Zeichen und Warenzeichen sind registrierte Warenzeichen der Cloudera Inc. Alle anderen Unternehmen und Produktnamen können Warenzeichen der jeweiligen Besitzer sein.

Cloudera beschleunigt die KI-Industrialisierung mit Cloud nativer Machine-Learning-Plattform

Neues Cloudera-Angebot vereinfacht Machine-Learning-Workflows mit einer einheitlichen Erfahrung für Data Engineering und Data Science auf Kubernetes.

München, Palo Alto (Kalifornien), 5. Dezember 2018 – Cloudera, Inc. (NYSE: CLDR) hat eine Vorschau auf eine neue, Cloud-basierte Machine-Learning-Plattform der nächsten Generation auf Basis von Kubernetes veröffentlicht. Das kommende Cloudera Machine Learning erweitert das Angebot von Cloudera für Self-Service Data Science im Unternehmen. Es bietet eine schnelle Bereitstellung und automatische Skalierung sowie eine containerisierte, verteilte Verarbeitung auf heterogenen Rechnern. Cloudera Machine Learning gewährleistet auch einen sicheren Datenzugriff mit einem einheitlichen Erlebnis in lokalen, Public-Cloud- und hybriden Umgebungen.

Im Gegensatz zu Data-Science-Tools, die nur Teile des Machine-Learning-Workflows adressieren oder nur für die Public Cloud verfügbar sind, kombiniert Cloudera Machine Learning Data Engineering und Data Science, auf beliebigen Daten und überall. Darüber hinaus werden Datensilos aufgelöst, um den kompletten Machine-Learning-Workflow zu vereinfachen und zu beschleunigen. Unternehmen können ab sofort hier Zugang zu einer Vorabversion von Cloudera Machine Learning anfragen.

Container und das Kubernetes-Ökosystem ermöglichen die Agilität der Cloud in verschiedenen Umgebungen mit einer konsistenten Erfahrung und ermöglichen die Bereitstellung skalierbarer Services für die IT in hybriden und Multi-Cloud-Implementierungen. Gleichzeitig sind Unternehmen bestrebt, komplette Machine-Learning-Workflows zu operationalisieren und zu skalieren. Mit Cloudera Machine Learning können Unternehmen Machine Learning von der Forschung bis zur Produktion beschleunigen. Benutzer sind in der Lage, Umgebungen einfach bereitzustellen und Ressourcen zu skalieren und müssen so weniger Zeit für die Infrastruktur und können mehr Zeit für Innovationen aufwenden.

Zu den Fähigkeiten gehören:

  • Nahtlose Portierbarkeit über Private Cloud, Public Cloud und Hybrid Cloud auf Basis von Kubernetes.

  • Schnelle Cloud-Bereitstellung und automatische Skalierung.

  • Skalierbares Data Engineering und Machine Learning mit nahtloser Abhängigkeitsverwaltung durch containerisiertes Python, R und Spark-on-Kubernetes.

  • Hochgeschwindigkeits-Deep-Learning mit verteiltem GPU-Scheduling und Training.

  • Sicherer Datenzugriff über HDFS, Cloud Object Stores und externe Datenbanken hinweg.

„Teams produktiver zu machen, ist entscheidend für die Skalierung von Machine Learning im Unternehmen. Modelle konsistent über eine hochskalierbare, transparente Infrastruktur zu erstellen und einzusetzen und dabei überall auf Daten zuzugreifen, erfordert aber eine neuartige Plattform”, sagt Hilary Mason, General Manager, Machine Learning bei Cloudera. „Cloudera Machine Learning vereint die kritischen Funktionen von Data Engineering, kollaborativer Exploration, Modelltraining und -bereitstellung in einer Cloud-basierten Plattform, die dort läuft, wo Sie sie benötigen – mit den integrierten Sicherheits-, Governance- und Managementfunktionen, die unsere Kunden nachfragen.”

„Bei Akamai haben wir ausgereifte Web-Sicherheitssysteme auf der Grundlage einer umfassenden Datenanalyse und -verarbeitung aufgebaut. Dabei ist uns bewusst geworden, dass Geschwindigkeit und Skalierbarkeit entscheidend für die Erkennung von Anomalien im Internet sind”, sagt Oren Marmor, DevOps Manager, Web Security bei Akamai. „Die Agilität, die Docker und Kubernetes Apache Spark verleihen, ist für uns ein wichtiger Baustein, sowohl für Data Science als auch für Data Engineering. Wir freuen uns sehr über die Einführung der kommenden Cloudera Machine Learning Plattform. Die Möglichkeit, mit der Plattform das Abhängigkeitsmanagement von Betriebssystemen und Bibliotheken zu vereinfachen, ist eine vielversprechende Entwicklung.”


Matt Brandwein, Senior Director of Products bei Cloudera, erläutert im Video, wie die neue Cloudera Plattform Teams in die Lage versetzt, Machine Learning im Unternehmen zu entwickeln und einzusetzen.

Mit Cloudera Machine Learning sowie der Forschung und fachkundigen Beratung durch die Cloudera Fast Forward Labs bietet Cloudera einen umfassenden Ansatz zur Beschleunigung der Industrialisierung von KI.

Um Kunden dabei zu unterstützen, KI überall zu nutzen, hat das Applied Research Team von Cloudera kürzlich Federated Learning eingeführt, um Machine-Learning-Modelle von der Cloud bis zum Edge einzusetzen, gleichzeitig den Datenschutz zu gewährleisten und den Aufwand für die Netzwerkkommunikation zu reduzieren. Der Bericht bietet eine detaillierte, technische Erläuterung des Ansatzes sowie praktische technische Empfehlungen, die sich mit Anwendungsfällen in den Bereichen Mobilfunk, Gesundheitswesen und Fertigung befassen, einschließlich IoT-gesteuerter Predictive Maintenance.

„Federated Learning beseitigt Hindernisse für die Anwendung von Machine Learning in stark regulierten und wettbewerbsorientierten Branchen. Wir freuen uns sehr, unseren Kunden helfen zu können, damit Starthilfe für die Industrialisierung der KI zu erhalten”, so Mike Lee Williams, Forschungsingenieur bei Cloudera Fast Forward Labs.


Mike Lee Williams, Research Engineer bei den Cloudera Fast Forward Labs, erklärt im Video, wie Machine-Learning-Systeme mit Hilfe von Federated Learning ohne direkten Zugriff auf Trainingsdaten aufgebaut werden können. 

Über Cloudera

Bei Cloudera glauben wir, dass Daten morgen Dinge ermöglichen werden, die heute noch unmöglich sind. Wir versetzen Menschen in die Lage, komplexe Daten in klare, umsetzbare Erkenntnisse zu transformieren. Wir sind die moderne Plattform für Machine Learning und Analysen, optimiert für die Cloud. Die größten Unternehmen der Welt vertrauen Cloudera bei der Lösung ihrer herausforderndsten, geschäftlichen Probleme. Weitere Informationen finden Sie unter de.cloudera.com/.

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.

Die Risiken der Datenverwaltung in der Cloud

Die externe Cloud lockt als Alternative zu eigenen Servern, weil sie standardisierte und sofort nutzbare Dienste ohne Investitionskosten bietet. Immer mehr Unternehmen adoptieren webbasierte Technologien in ihren täglichen Aktivitäten und es scheint, dass eben jene webbasierte Applikationen und Business-Tools unsere Zukunft vorgeben. Diesen Vorteilen stehen jedoch auch Risiken gegenüber, die ein Unternehmen bedenken sollte, bevor der Schritt in die Cloud gewagt wird.

Dieser Artikel gibt einen kurzen Überblick über die drei größten Probleme beim Cloud Computing, um die Risiken gegenüber den Chancen besser abwägen zu können.

Datensicherheit – Der Schutz vor Datenverlust

In erster Linie ist eine externe Cloud immer noch nicht so sicher, wie Ihre eigene professionell gewartete IT-Infrastruktur. Die Übertragung der Daten über die externen Netzwerke ist vergleichsweise langsam und grundsätzlich riskant, sofern nicht aufwändig verschlüsselt wird. Viele Skandale rund um das Thema Datensicherheit traten im Grunde durch diese Vulnerabilität der Datenübertragung über dritte Netze auf. Was für unkritische Maschinendaten vielleicht noch akzeptabel sein mag, ist für Personendaten höchst kritisch. Für Unternehmen, die mit extrem sensiblen Daten arbeiten, ist dieser Faktor insofern ein großer Nachteil, als dass dieser zumindest durch Verschlüsselung entschärft werden muss.

Ein weiteres Problem von Unternehmen, die webbasierte Software aus externen Clouds verwenden, ist, dass sie nicht wissen, wo ihre Daten aufbewahrt werden. Die Unternehmen wissen oft nicht, in welchen Ländern die Rechenzentren lokalisiert sind, auf welchen Servern und mit welcher Hard- und Software ihre Daten verarbeitet und gespeichert werden. Gerade der Aspekt der nationalen Gesetzgebung und der eingesetzten Hard- und Software bedeutet ein Risiko der Verletzung von Datenschutzvorschriften. So können hinsichtlich des Datenschutzes Probleme enstehen, wenn Daten – auch nur anteilig – außerhalb der EU gespeichert werden.

Nur wenige Cloud-Dienste sichern glaubhaft und nachvollziehbar zu, dass die Daten in Deutschland oder der Schweiz verbleiben. Das Fehlen dieser Zusicherung ist mit dem Verlust der Datenkontrolle gleichzusetzen und sollte daher für besonders sensible Informationen gegeben sein.

Angriffe auf externe Clouds

Sämtliche Daten oder Systeme, die sich in der Cloud befinden, sind ein potenzielles Ziel für Hacker und könnten durch einen Angriff enthüllt werden. Externe Cloud-Systeme sind deshalb ein solch beliebtes Ziel für Hacker, da diese nicht nur von Ihnen, sondern auch von anderen Unternehmen, Instituten oder Privatpersonen genutzt werden. Auch der Cloud-Anbieter selbst kann angegriffen werden, so dass Ihre Daten in Gefahr sind, obwohl Sie eigentlich gar nicht das direkte Ziel des Hackers waren.

Besonders beliebt bei Cyberkriminellen, die sich Cloud-Service-Provider als Ziel festgesetzt haben, sind Attacken auf Web-Anwendungen. Die Versuche des Hackers, Sicherheitslücken von Web-Anwendungen auszunutzen sind deswegen viel zu oft von Erfolg geprägt, da es vielzählige Möglichkeit der Angriffe gibt, beispielsweise über SQL-Injection oder Session-Hijacking.

Spätestens seit dem NSA- und BND-Skandal sollten Sie auch hinsichtlich staatlicher Institute als Organe der Wirtschaftsspionage sensibilisiert sein. Sie wissen nie, wer außer Ihnen die Cloud-Dienste Ihres Anbieters noch nutzt oder deren Hard- bzw. Software anzapft.

Verzögerungen

Während sich die Risiken der Datensicherheit durch den Einsatz von internen Cloud statt externen Clouds noch recht gut vermeiden lässt, gilt ein Problem als Cloud-universell: Die Geschwindigkeit im alltäglichen Betrieb.

In Business ist Zeit bekanntlich Geld wert. Webbasierte Lösungen und externe Cloud sollten theoretisch Zeit einsparen, und in vielerlei Hinsicht tun sie das auch, beispielsweise bei der Ersteinrichtung. Im operativen Geschäft sieht das dann jedoch anders aus, denn webbasierte Lösungen kämpfen mit Latenzzeiten, Ladezeiten und Verzögerungen durch die Darstellung im Webbrowser. Es kommt auch heute immer noch vor, das sich Seiten nicht aufbauen und Informationen nicht abrufen lassen. Und wenn so was passiert, ist es Ihren Mitarbeitern nicht möglich, Ihre Arbeit fortzusetzen, der Prozess stoppt.

Desweiteren sind gute Offline-Modi immer noch eine Herausforderung für jeden Service-Anbieter, so dass Ihre Mitarbeiter stets online sein müssen, was sie wiederum an anderer Stelle zu einem leichten Ziel für Hacker werden.

Fazit – Die Abwägung zwischen Cloud und Nicht-Cloud

Stand heute haben webbasierte Dienstleistungen das Niveau der traditionellen Software noch nicht erreicht. Während die Cloud jeden Tag immer mehr Zugkraft gewinnt, hat die traditionelle Software jedoch noch lange nicht ausgedient. Jedes Unternehmen muss die Vor- und Nachteile der Cloud verantwortlich für sich und seine Stakeholder abwägen, um diese existenzgefährdenden Risiken im Vorfeld zu vermeiden und die beste Entscheidung für das Unternehmen zu treffen.