SPSS Modeler Integration mit IBM DB2 Analytics Accelerator Master-Thesis

Größe: px
Ab Seite anzeigen:

Download "SPSS Modeler Integration mit IBM DB2 Analytics Accelerator Master-Thesis"

Transkript

1 Universität Leipzig Fakultät für Mathematik und Informatik Institut für Informatik SPSS Modeler Integration mit IBM DB2 Analytics Accelerator Master-Thesis Leipzig, Oktober 2012 vorgelegt von Markus Nentwig Studiengang Master Informatik Betreuender Hochschullehrer: Prof. Dr. Erhard Rahm Fakultät für Mathematik und Informatik Abteilung Datenbanken Dr. Michael Hartung Fakultät für Mathematik und Informatik Abteilung Datenbanken Externer Betreuer: Dipl.-Inf. Oliver Benke IBM Deutschland Research & Developement GmbH

2 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Aufbau der Arbeit Grundlagen Mainframe IBM System z Datenbanksysteme Wissensentdeckung in Datenbanken Business Intelligence und Predictive Analytics IBM SPSS Modeler IBM SPSS Modeler Client IBM SPSS Modeler Server IBM SPSS Modeler CLEF Data-Mining-Modelle Entscheidungsbaum CHAID CART Assoziationsanalyse Apriori FP-growth Data-Warehouse-Systeme Data-Warehouse-Appliance Übersicht IDAA IDAA im Detail IBM Netezza Analytics Performance IDAA Stand der Technik Modellierung auf Basis existierender Technologie SPSS Modeler auf System z Externes Data-Warehouse-System Machbarkeitsstudie Modellierung auf IDAA Ansatz II

3 Inhaltsverzeichnis Prototypische Erweiterungen Herausforderungen Industrie-Blueprints als Anwendungsfall Retail Prediction Promotions Blueprint Profitability and Customer Retention for Telecommunications Blueprint Umsetzung Abbildung auf DB2 für z/os Extraktion der verwendeten Daten Vergrößerung der Datengrundlage Import auf DB2 für z/os Integration in IDAA Offload auf IDAA Anpassung von Algorithmen RFM-Analyse Assoziationsanalyse Optimierung Evaluation Setup Ergebnisse Verwendung von Algorithmen für Messungen Zusammenfassung 75 Abkürzungsverzeichnis 76 Literaturverzeichnis 77 Erklärung 83 III

4 Abbildungsverzeichnis 2.1 Parallel Sysplex CRISP-DM Referenz-Modell SPSS Modeler verschiedene Knoten IBM SPSS Modeler Benutzeroberfläche Client- / Server-Komponenten CLEF-Architektur Übersicht der IDAA-Komponenten Weg von Queries durch ein z/os DB Technische Grundlagen im IBM DB2 Analytics Accelerator Query Bearbeitung in einem Snippet Blade IBM Netezza Analytics Paket (INZA) Modellierung auf System z ETL-Prozess für eine Quelle Zusammenarbeit SPSS Modeler, IDAA und Prototyp Stream für Retail Blueprint Input-Tabellen im Szenario des Retail Prediction Blueprints Output-Tabellen beim Retail Blueprint Supernode RFM and Sales Potential Parameter RFM-Aggregatknoten Parameter RFM-Analyse Supernode Calculate Channel Propensity Assoziationsanalyse im Telecommunikationsblueprint Ein- und Ausgabetabelle im Telekommunikations-Szenario Klassendiagramm für Programm zur Vervielfältigung z/os ISPF-Subsystem SDSF-Subsystem Log IBM DB2 Analytics Accelerator Studio Verteilung der Kaufbeträge Stream SPSS Modeler Berechnung Entscheidungsbaum Stream SPSS Modeler Inner Join und Random Sample Stream SPSS Modeler RFM-Analyse IV

5 Tabellenverzeichnis 2.1 Unterschiede transaktionale und analytische Datenbankanfragen Beispielwerte RFM Klassifizierung Auszug Tabelle Tarif-Optionen Vorbereitung für FP-growth auf Netezza Vergleich der Assoziationsregeln auf SPSS / IDAA Vergleich Grenzen RFM-Analyse SPSS / IDAA V

6 1 Einleitung 1.1 Motivation Data-Warehouses finden ihren Einsatz bei der Integration verschiedener Datenquellen auf einer gemeinsamen Plattform. Diese zentrale Anlaufstelle wird dann zur weiteren Verwendung der Daten im Rahmen von analytischen Aufgaben eingesetzt. Die Datenbasis wird dabei mit Hilfe statistischer Methoden in einem Data-Mining-Prozess aufbereitet. Das Ziel dieses Prozesses ist die Erstellung von Modellen wie einer Assoziationsanalyse, welche dann über Regelsätze häufige Assoziationen in der Datengrundlage widergibt. Die berechneten Modelle können dann zur Beurteilung künftiger Entwicklungen genutzt werden, was als Scoring bezeichnet wird. Zum Beispiel kann neuen Kunden darüber eine Produktempfehlung auf Grundlage der Käufe anderer Kunden gegeben werden. Berechnungen direkt auf der Datenbank, bezeichnet als In-Database Analytics, oder intelligente Aktualisierungsstrategien für operationale Datenbestände in das Data-Warehouse sind dabei Entwicklungen, die schneller zu Ergebnissen führen, wodurch neue Einsatzmöglichkeiten wie Echtzeit-Betrugserkennung bei großen Datenmengen ermöglicht werden. Im Mainframe-Umfeld existiert mit dem IBM DB2 Analytics Accelerator eine Data-Warehouse-Lösung, die durch ihre Appliance-Struktur schnell und einfach einsatzfähig ist. Der massiv parallele Aufbau ist dabei optimal für analytischen Workload geeignet. Durch die tiefe Integration in das bestehende DB2- System sowie der Möglichkeit, In-Database Analytics auszuführen, gibt es viele potentielle Verwendungen, ein Beispiel dafür stellt die nachfolgend präsentierte Integration von Data-Mining-Prozessen in den DB2 Analytics Accelerator dar. 1.2 Zielsetzung Die vorliegende Arbeit beschreibt einen Architekturansatz, der im Rahmen einer Machbarkeitsstudie bei IBM entwickelt wurde. Dadurch wird der IBM DB2 Analytics Accelerator als eine Data-Warehouse-Appliance dazu in die Lage versetzt, über angepasste Schnittstellen Data-Mining-Modelle über entsprechende Algorithmen direkt auf dem Accelerator zu erstellen. Neben dieser Beschrei- 1

7 1.3 Aufbau der Arbeit bung wird die bisherige Verwendung des DB2 Analytics Accelerators sowie das zugehörige Umfeld von Datenbanksystemen bis zum System z Mainframe vorgestellt. Darauf aufbauend werden praxisnahe Anwendungsfälle präsentiert, die unter Anwendung von intelligenten Methoden auf gespeicherten Kundendaten statistische Modelle erstellen. Für diesen Prozess wird die Datengrundlage zuerst vorbereitet und angepasst, um sie dann in dem zentralen Data-Mining-Schritt nach neuen Zusammenhängen zu durchsuchen. Resultate wie Modelle können dann für weitere Prozesse wie Scoring von neuen Kundendaten verwendet werden. Dieser komplette Lebenszyklus von Data-Mining-Prozessen kann mit Software wie dem IBM SPSS Modeler dargestellt werden, so ausgeführt für die Anwendungsfälle auf der Datenbank DB2 für z/os. Dieser Phase folgt eine Abbildung der Vorgehensweise unter SPSS Modeler auf den DB2 Analytics Accelerator, wobei für einige Algorithmen explizit untersucht wird, wie eine Portierung auf die neue Plattform stattfinden kann. Im letzten Teil der Ausarbeitung werden die Resultate der durchgeführten Tätigkeiten aufgezeigt und jeweils für SPSS Modeler und den DB2 Analytics Accelerator vergleichend gegenübergestellt. 1.3 Aufbau der Arbeit Nachdem in diesem Kapitel das Thema der Arbeit motiviert wurde, folgt in Kapitel 2 ein Überblick der eingesetzten Technologien wie dem Mainframe oder Datenbanksystemen sowie Methoden und Prozesse zur Wissensentdeckung in Data-Warehouse-Systemen. Im Kapitel 3 wird der Stand der Technik dargestellt, wobei Themen aus den Grundlagen neu verknüpft werden und damit eine Einsatzmöglichkeit zeigen. Im Kapitel 4 wird die Umsetzung präsentiert, dabei wird das erlangte Wissen angewandt und Anwendungsfälle von einer bestehenden Architektur auf eine neue abgebildet. Im Anschluß daran werden in Kapitel 5 einige Ergebnisse eingeschätzt und am Ende erfolgt in Kapitel 6 eine Zusammenfassung. 2

8 2 Grundlagen In diesem Kapitel erfolgt eine Vorstellung von Technologien, die im weiteren Verlauf der Ausarbeitung verwendet werden. Dabei wird im Abschnitt 2.1 der Mainframe als zentrale Schaltstelle gezeigt und daraufhin im Abschnitt 2.2 um den Begriff Datenbanksystem erweitert, sowie mit DB2 ein Vertreter vorgestellt. Mit dem allgemeinen Anwachsen der Rechenleistung ist es interessant geworden, neues Wissen aus bereits vorhandenen Datenbanken zu gewinnen, um damit bestehende Prozesse zu optimieren. Diese Wissensentdeckung wird im Abschnitt 2.3 behandelt. Weiterhin gibt es an dieser Stelle eine Einordnung der Begriffe Business Intelligence und Predictive Analytics und abschließend wird IBM SPSS Modeler als mögliches Werkzeug für Data-Mining-Prozesse präsentiert. Im letzten Abschnitt 2.5 wird dann dargestellt, wie ein Data-Warehouse- System bei diesem Prozess helfen kann. Abschließend wird mit dem IBM DB2 Analytics Accelerator eine Data-Warehouse-Appliance beschrieben, die schnell einsatzfähig ist. 2.1 Mainframe IBM System z In vielen Großunternehmen bilden IBM-Mainframes das zentrale Rückgrat der IT-Infrastruktur und zeichnen sich für ihre Zuverlässigkeit, Verfügbarkeit und Wartbarkeit aus. Diese drei Eigenschaften sind ein zentrales Designziel bei System z und werden etwa über umfangreiche Funktionen zur Systemüberprüfung, die kritische Fehler möglichst zeitig erkennen und melden oder redundante Hardwarekomponenten, die ohne Einfluß auf den Betrieb ersetzt werden können, gewährleistet. Dabei können tausende Programme sowie Ein- und Ausgabegeräte unterstützt werden, um damit gleichzeitig tausenden Benutzern Dienste bereitzustellen. In diesem Kontext kann zudem eine Verfügbarkeit von bis zu 99,999% erreicht werden [EKOO11]. Im Vergleich zur Konkurrenz im Bereich Server Plattformen ist der Mainframe System z zudem seit Jahren am besten bewertet [Spr10, SR11]. Für große Kunden in Geschäftsbereichen wie Bank- oder Versicherungswesen zählen neben den eben genannten Punkten auch die Abwärtskompatibilität für Software zu den Stärken von den IBM Systemen. Dies bedeutet, dass der Maschinencode von Programmen auf älteren als auch aktuellen System z Mainframes ohne Anpassungen lauffähig sind. Auch im Bereich Sicherheit und Skalierbarkeit bietet System z Eigenschaften, 3

9 2.1 Mainframe IBM System z die von Plattformen nicht erreichen [HKS04]. Einige Mechanismen zur Erfüllung dieser Eigenschaften werden im Folgenden kurz vorgestellt. Parallel Sysplex Bis zu 32 Einzelsysteme können - wie in Abbildung 2.1 dargestellt - miteinander verbunden werden und bieten so mehr Leistung und eine erhöhte Verfügbarkeit, falls eines der Systeme ausfallen sollte. Der Verbund wird über eine zentrale Instanz, die Coupling Facility (CF), gesteuert. Die CF verwaltet unter anderem Locks beim Zugriff auf Ressourcen, steuert die Cache-Verwaltung und verteilt die Workloads mithilfe der eingehenden Status-Informationen. Zudem existiert eine zentrale Zeitgebung über den Sysplex Timer für alle im Verbund befindlichen Systeme. [HKS04] CF Sysplex Timer Network DB2A DB2B DB2C Abbildung 2.1: Ein Parallel Sysplex ist ein Verbund von mehreren System z Maschinen, mit dem die Verfügbarkeit und die Skalierbarkeit weiter steigt. (Quelle: [BAP + 06]) GDPS Eine Erweiterung vom Sysplex ist der Geographically Dispersed Parallel Sysplex, der es ermöglicht, trotz Totalausfall eines Rechenzentrums, etwa aufgrund einer Naturkatastrophe, den Betrieb an entfernter Stelle aufrecht zu erhalten. Detailliertere Informationen dazu sind in [KCPS12] veröffentlicht. 4

10 2.1 Mainframe IBM System z Betriebsysteme System z unterstützt verschiedene Betriebssysteme, die jeweils auf einer logischen Partition (LPAR) residieren. Wichtige Beispiele sind hier z/os, z/vm und Linux on System z, unter z/vm wiederum können verschiedene weitere Betriebssysteminstanzen laufen. Über eine TCP/IP-Verbindung (HiperSocket) kann ein Datenaustausch zwischen Betriebsystemen in getrennten LPARs auf einer Maschine über den jeweiligen Hauptspeicher stattfinden. [HKS04] WLM Die Verwaltung von Workload findet auf einem System z über den integrierten Workload Manager (WLM) statt. Dieser ermöglicht es, verschiedene Workloads auf mehreren Instanzen von z/os dynamisch innerhalb festgelegter Grenzen zu steuern. Dabei werden Prioritäten für bestimmte Aufgaben explizit beeinflusst, um Service Level Agreements, etwa für Antwortzeiten bei Datenbankanwendungen, zu erfüllen. Dafür werden Prozesse in verschieden wichtige Service-Klassen eingeteilt, worüber der Workload über Ziel-Definitionen dynamisch gesteuert werden kann. Der WLM steuert zudem auch Ressourcen bei der Verwendung von einem Parallel Sysplex in Zusammenarbeit mit der Coupling Facility. [CDF + 08] Sicherheit Auf System z existieren verschiedene Mechanismen, um die Sicherheit von Daten und die Trennung von verschiedenen Betriebssystemen auf einer Maschine zu gewährleisten. Dazu zählt RACF Resource Access Control Facility, was ein Sicherheitsframework für System z darstellt, wodurch Funktionen zur Authentifizierung und Autorisierung von Nutzer und Ressourcen, also zur Zugriffskontrolle sowie zur Protokollierung aller Vorgänge bereitstellt werden. Diese werden zudem auch von Subsystemen wie CICS oder DB2 für eine bessere Transaktionssicherheit eingesetzt. Weiterhin ist der PR/SM (Processor Resource/System Manager) als Hypervisor dafür verantwortlich, die verfügbare Hardware logisch aufzuteilen und somit jedem laufenden Betriebssystem begrenzte Ressourcen zuzuteilen. Festgelegte Datenpartitionen werden dabei als LPAR bezeichnet, das entsprechende Betriebssystem kennt nur die ihm zugewiesene Hardware und hat keinen Zugriff auf andere Systeme. [HKS04] Channel Subsystem Das Channel Subsystem entlastet die zentralen Prozessoren (CP), indem es den Datenfluss zwischen dem Hauptspeicher und Ein- /Ausgabegeräten koordiniert. Die Besonderheit dabei ist, dass über ein Channel Subsystem bis zu 256 I/O-Geräte angebunden werden können, die dann direkt von einer LPAR genutzt werden. Damit können Verbindungen zu externen Geräten aufrecht erhalten werden und zeitgleich von den CPs weitere Operationen bearbeitet werden. [HKS04, EKOO11] 5

11 2.2 Datenbanksysteme 2.2 Datenbanksysteme Die heutige Informationsgesellschaft baut auf Computersystemen auf, die Daten bereitstellen und abspeichern. In vielen Unternehmen und Organisationen gehört die Verwaltung von Datenbeständen zu den wichtigsten Herausforderungen - die Umsetzung erfolgt in der Regel mithilfe von Datenbanksystemen. Ein Datenbanksystem ist ein Software-Produkt, welches zum einen die Datenbank mit den Nutzerdaten beinhaltet, zum anderen ein Datenbankmanagementsystem (DBMS), um bestimmte Anforderungen beim Umgang mit der Datenbank zu erfüllen. Durch diese Struktur wird eine zentrale Verwaltung der Daten losgelöst von möglichen Anwendungen erreicht. Ein wichtiges Konzept bei der Arbeit mit Datenbanksystemen ist das Transaktionsparadigma, welches Mechanismen zur Wahrung von Qualität und Korrektheit einzelner Transaktionen auf der Datenbank beschreibt. Eine Transaktion ist dabei eine modellhafte Abbildung von Ereignissen wie einer Geldüberweisung oder einer Ausleihe in einer Bibliothek. Das Paradigma fordert, dass jede Transaktion den folgend kurz beschriebenen ACID-Eigenschaften genügt, was mit wachsender Datenbankgröße und steigenden Zugriffszahlen durch verschiedene Benutzer neue Herausforderungen mit sich bringt. [HR99] Atomicity Es gibt zwei Möglichkeiten, wie eine Transaktion verläuft: Entweder wird sie ohne Probleme ausgeführt oder beim Auftreten von Fehlern nicht durchgeführt. In diesem zweiten Fall werden eventuell durchgeführte Teilschritte wieder rückgängig gemacht. [HR99] Consistency Mit der Konsistenz-Eigenschaft wird gewährleistet, dass nach einer Transaktion alle Integritätsbedingungen erfüllt sind und die Datenbank insgesamt wie vor der Trankaktion in einem widerspruchsfreien Zustand ist. Bei einer Banküberweisung bleibt etwa die Summe der beiden beteiligten Konten gleich. Zudem wird mit dieser Eigenschaft die korrekte physikalische Speicherung der Daten zugesichert. [HR99] Isolation Diese Eigenschaft bietet trotz mehreren Nutzern, die auf die Datenbank zugreifen wollen, jedem einzelnen Nutzer eine logische Trennung und gewährleistet damit parallele Verwendung der Daten. Dafür werden etwa Verfahren zur Synchronisierung wie Sperr-Mechanismen implementiert. [HR99] Durability Eine einmal vollständige ausgeführte Transaktion kann durch nachfolgende Fehler nicht mehr korrumpiert werden, das heißt, sie ist dauerhaft. [HR99] Für einen produktiven Einsatz müssen zusätzlich Aspekte wie etwa Verfügbarkeit und Fehlertoleranz betrachtet werden [HR99]. Zur Unterscheidung von Datenbanksystemen können Kriterien wie die Art der Externspeicheranbin- 6

12 2.2 Datenbanksysteme dung oder Rechnerkopplung herangezogen werden, womit drei Klassen gebildet werden können: Shared-Everything Bei dieser Klasse greifen alle Prozessoren des Rechners auf einen gemeinsamen Arbeitsspeicher zu. Zudem existiert nur eine Betriebssysteminstanz, wodurch das DBMS auf die komplette Datenbank zugreifen kann. Dieser Ansatz skaliert für Installationen ab einer bestimmten Größe schlechter als die beiden folgenden Architekturansätze. [Rah94] Shared-Disk wird auch als Database Sharing bezeichnet. Die wichtigste Eigenschaft ist hier, dass jedes DBMS wieder auf die gesamte Datenmenge zugreifen kann. Allerdings existieren mehrere Rechner, die über eine Cluster-Implementierung umgesetzt sind. Dabei kann die Rechnerkopplung lose (jeder Prozessor hat eigenen Hauptspeicher, Kooperation über voneinander unabhängige Systeme) oder nah (eigener Hauptspeicher pro Prozessor sowie gemeinsamer Hauptspeicher für alle Prozessoren) sein. Vor allem bei naher Rechnerkopplung profitieren alle Prozessoren von einer vereinfachten Kommunikation etwa bei Kontrollaufgaben, somit lässt sich in diesem Verbund die Verteilung von Workload am besten durchführen. [Rah94] Shared-Nothing Auch Database Distribution. Auf mehreren lose gekoppelten Rechnern (jeder Prozessor hat hat eigenen Hauptspeicher) wird je ein DBMS verwendet, um auf einen exklusiven Teil der Gesamtdatenmenge zuzugreifen. Dadurch bietet ein Shared-Nothing-System die beste Erweiterbarkeit / Skalierbarkeit, weil keine Kommunikation bei parallel stattfindendem Datenzugriff auf verschiedenen Teilsystemen nötig ist. [Rah94] Der Zugriff auf angebundene Daten erfolgt dabei über das Clustermodell Data Sharing, das heißt, jedes System kann auf alle Daten und jedes andere System direkt zugreifen, wenn es die Rechte dafür besitzt. DB2 für z/os ist ein Vertreter der relationalen Datenbanksysteme. DB2 zieht Vorteile aus den verfügbaren technischen Komponenten wie dem Parallel Sysplex (siehe Abbildung 2.1) oder dem Workload Manager (WLM), so können etwa über Shared Data mehrere DB2-Subsysteme (Instanzen) auf mehreren Mainframes zusammengefasst werden, die dann über die Coupling Facility (CF) auf gemeinsame Buffer Pools zugreifen können. Shared Data ist dabei eine erweiterte Form des Shared-Disk-Ansatzes, wobei die CF bei parallelen Zugriffen für eine bessere Nebenläufigkeit und Synchronisierung der Prozesse sorgt. Mit dem Shared Data Prinzip kann zudem eine erhöhte Verfügbarkeit sowie Lastbalancierung erreicht werden [BAP + 06]. Die Buffer Pools der CF arbeiten dann als zentraler Cache zwischen dem DB2 und den physikali- 7

13 2.3 Wissensentdeckung in Datenbanken schen Platten. Die zudem für Verwaltungsaufgaben zuständige CF entlastet die Einzelsysteme durch die Behandlung von Sperren und der Kohärenzkontrolle. Gleichzeitig kann mit dem WLM der anfallende Workload entsprechend eingestellter Zielvereinbarungen gesteuert werden, womit Engpässe verhindert werden. In einem DB2-Subsystem werden bestimmte logische und physikalische Strukturen bereitgestellt, mit deren Hilfe die Abbildung von Benutzerdaten auf Festplatten erfolgt. Die logischen Konstrukte lassen sich grob in Tabellen für die eigentlichen Datensätze und Datenbanken zur Gruppierung von Table- /Indexspaces unterteilen, die physikalischen Datenstrukturen werden nachfolgend eingeführt. [EKOO11, HKS04, Rah94] Tablespace Ein Tablespace beinhaltet eine oder mehrere Tabellen. Von dem logischen Konstrukt Tabelle erfolgt mit dem Bezug zu einem Tablespace die Zuordnung zu einem physikalischen Datensatz. Indexspace Für jeden Index in einer Tabelle wird ein Indexspace außerhalb der Tablespaces angelegt. Storage Group Die Storage Group beinhaltet normalerweise alle einer Datenbank zugehörigen Konstrukte (Table-/Indexspaces) und wird physikalisch einem oder mehreren Laufwerken zugeordnet. Metadaten wie Logs, der Datenbankkatalog oder sonstige Parameter werden nicht pro Datenbank gespeichert, sondern zentral im zugehörigen DB2- Subsystem. Auf System z existieren ausgereifte Hilfsprogramme zur DB2 Administration, diese werden unter anderem zur Datenverwaltung, zum Ausführen von Backup- oder Recovery-Aufgaben oder zur Konsistenzprüfung verwendet. Im Hintergrund werden zur Verwendung der Tools JCL-Skripte einsetzt, die über das Job Entry System (JES) Subsystem in z/os ausgeführt werden. [EKOO11] 2.3 Wissensentdeckung in Datenbanken Dieser Abschnitt beschäftigt sich vor allem mit den begrifflichen Einordnungen beim Durchsuchen von Datenbanken nach bisher verborgenen Zusammenhängen. Im Englischen als Knowledge Discovery in Databases (KDD) und synonym oft als Data-Mining bezeichnet, beschreibt der Prozess das Vorgehen, Daten vorzubereiten und durch die Anwendung von Algorithmen zu untersuchen, um schlußendlich die neu gewonnenen Informationen zu visualisieren und weiterzuverwenden. Dieses Vorgehen beschreibt zudem den Prozess der Datenanalyse passend, wobei das Ziel dieser Analyse die Wissensentdeckung darstellt. Dieses Ziel lässt sich mit der Ausführung folgender Schritte nach [HK00] und [AMH08] erreichen: 1. Initiale Überprüfung der Daten 8

14 2.3 Wissensentdeckung in Datenbanken 2. Benötigte Datenquellen miteinander kombinieren 3. Für die Analyse relevante Daten auswählen 4. Data-Mining im eigentlichen Sinne - Anwendung von intelligenten Methoden, um Muster zu erkennen 5. Muster-Auswertung mit Hilfe weiterer Algorithmen und Metriken 6. Präsentation des erarbeiteten Wissens über Möglichkeiten der Visualisierung und Wissensrepräsentation Diese Punkte umfassen wiederum im einzelnen verschiedene Teilaufgaben, welche dadurch mehr oder weniger aufwendig in der Umsetzung sind. Bei der initialen Prüfung können Inkonsistenzen wie fehlende Werte sowie Rauschen oder extreme Werte aus den Rohdaten gefiltert oder angepasst werden. Zudem können verschiedene Datenquellen wie transaktionale Datenbanken, komplexe Data-Warehouse-Konstrukte oder aber das World Wide Web zur Auswahl stehen, bei der Mustererkennung gibt es unterschiedliche Algorithmen, etwa Entscheidungsbäume oder Assoziationsmodelle, die jeweils ihren optimalen Einsatzbereich haben. All diese Punkte haben entscheidende Auswirkungen auf eine Datenanalyse und sollten mit Bedacht gewählt werden. [HK00, AMH08] Eine weitere methodische Vorgehensweise wird durch den Cross Industry Standard Process for Data Mining (CRISP-DM) beschrieben. Dabei werden sechs Phasen unterschieden, die wie in Abbildung 2.2 aufgezeigt miteinander verknüpft sind. So etwa müssen für bestimmte Modellierungsschritte die Daten in der vorherigen Stufe speziell angepasst werden oder aber die Bewertung der Modelle ergibt ein neues Verständnis für die auszuführende Aufgabe. Der oben beschriebene Data-Mining-Schritt mit der Anwendung von intelligenten Methoden ist dabei im CRISP-DM die Phase der Modellierung. Unteraufgaben sind dabei die Auswahl eines passenden Modells gefolgt von Testläufen, ob das Modell geeignet ist. Nach erfolgreichem Test kann das Modell mit den richtigen Parametern erstellt werden, wonach eine erste Einschätzung der Ergebnisse und eventuell nötige Neuerstellung vorgenommen werden kann. Die letzte Phase, der Einsatz, beschreibt dabei die tatsächliche Verwendung der Ergebnisse, um Prozesse zu verbessern. Dieser Einsatz kann in seinem Umfang stark variieren, eine Möglichkeit ist, dass ein einfacher Report über die erzielten Ergebnisse verfasst wird. Eine weitere Möglichkeit ist, dass die Resultate in weitere Prozesse integriert werden, berechnete Modelle können so etwa zur Bewertung von neuen Daten verwendet werden. [CCK + 00] Diese Verwendung wird als Scoring bezeichnet. Mit Hilfe von Modellen wird demnach eine Grundlage zur Bewertung von neuen Datensätzen geschaffen. Je nach Anforderung, wie schnell die Ergebnisse über ein Scoring bewertet werden sollen, gibt es unterschiedliche Umsetzungen. Ein Einsatz für Scoring in Echtzeit ist etwa, dass bei einem Einkauf aufgrund der gewählten Produkte ein Rabatt-Coupon auf die Rechnung passend zum Einkaufsverhalten gedruckt wird. [LK12, BL07] Im 9

15 2.3 Wissensentdeckung in Datenbanken Datenverständnis Geschäftsverständnis Einsatz Daten Datenvorbereitung Modellierung Evaluierung Abbildung 2.2: CRISP-DM Referenz-Modell, welches sechs ineinandergreifende Schritte des allgemeinen Verständnisses und der Datenbearbeitung zeigt. (Quelle: [CCK + 00]) 10

16 2.3 Wissensentdeckung in Datenbanken Gegensatz dazu wird beim Batch Scoring eine größere Menge an Datensätzen bewertet, dies erfolgt in der Regel nach der Ausführung der Transaktionen, so zum Beispiel können an einer Börse alle Transaktionen der letzten Stunde auf Unregelmäßigkeiten überprüft werden. Bei Batch Scoring wird das Ergebnis demnach nicht sofort benötigt, dafür auf großen Datenmengen berechnet, wohingegen beim Echtzeit-Scoring eine schnelle Reaktion von einer Anwendung gefordert wird, allerdings nur auf einem speziellen Datensatz. [Hof12] Dem allgemeinen Vorgehen folgt die Einordnung, welche Art von Zusammenhängen in den Daten gesucht werden soll. Dies kann etwa allgemeine Äußerungen über den Datenbestand betreffen, der ohne technische Unterstützung nicht zu erkennen wäre, also beschreibende Aussagen über die bestehenden Daten, was im Geschäftsumfeld Prozesse aus dem Bereich Business Intelligence kennzeichnet. Andererseits geht es auch darum, mit den vorhandenen Daten vorhersagende Aussagen über neue Transaktionen oder zukünftige Entwicklungen zu treffen, was in Unternehmen in den Bereich Predictive Analytics eingeordnet werden kann. Eine kurze Beschreibung von Business Intelligence respektive Predictive Analytics erfolgt im folgenden Abschnitt. [HK00] Business Intelligence und Predictive Analytics In [KMU06] wird Business Intelligence wie folgt beschrieben: Unter Business Intelligence (BI) wird ein integrierter, unternehmensspezifischer, IT-basierter Gesamtansatz zur betrieblichen Entscheidungsunterstützung verstanden. Dieses Zitat zeigt deutlich auf, dass BI als kompletter Prozess verstanden wird, der mit Methoden wie Data-Mining und Systemen wie einem Data-Warehouse als Hilfsmittel und damit über den Zugriff auf möglichst viele Informationen im Unternehmen Möglichkeiten bietet, bestehende Prozesse zu optimieren. Zudem zeigt die Definition den starken Fokus auf Technik, speziell geht es um die Optimierung von Geschäftsprozessen mit Informationstechnik. [KMU06] Predictive Analytics erweitert den bestehenden Begriff des BI um die analysierenden Komponenten, die mit Informationen aus dem Unternehmen und Data-Mining-Konzepten Erkenntnisse über zukünftige Entwicklungen gewinnen. Dabei liegt der Fokus auf der Erstellung von Modellen, mit welchen dann möglichst exakte Vorhersagen getroffen werden können. [Koe12] Mit dieser kurzen Einführung wird im nächsten Abschnitt mit SPSS Modeler ein Vertreter aus dem Bereich Predictive Analytics vorgestellt. 11

17 2.3 Wissensentdeckung in Datenbanken IBM SPSS Modeler Als mögliches Werkzeug für das eben vorgestellte Verfahren Predictive Analytics wird im Folgenden SPSS Modeler als eine Data-Mining-Workbench von IBM vorgestellt. SPSS Modeler wird zudem für die bearbeiteten Szenarien benötigt, um mit der jeweiligen Datengrundlage Data-Mining durchführen zu können. Dabei können mehrere Datenbanken miteinander verknüpft werden, die Informationen aufbereitet und daraufhin mit diesen Datensätzen neue Modelle erstellt werden. Diese können eingesetzt werden, um zum Beispiel Vorhersagen über mögliche Betrugsfälle im Versicherungsbereich zu liefern oder um nach Herzanfällen entsprechend der medizinischen Vorgeschichte eine optimale Behandlung zu leisten. Die wichtigsten Bestandteile des SPSS Modeler sind zum einen der Modeler Client, beschrieben im nächsten Abschnitt, sowie der Modeler Server, der im Hintergrund eine zentrale Verarbeitungsstelle für die Daten darstellt, näher erläutert in Abschnitt Zudem existiert mit dem Component-Level Extension Framework (CLEF) eine Grundlage zur Erstellung von Erweiterungen, diese wird im Abschnitt beschrieben IBM SPSS Modeler Client Der SPSS Modeler Client ist die grafische Benutzeroberfläche für den SPSS Modeler, mit welcher über verschiedene Arbeitsschritte Daten aus mehreren Quellen analysiert werden können. Arbeitsabläufe werden über diverse Knoten, verbunden durch gerichtete Kanten, in Streams als eine Art Flußdiagramm abgebildet, eine einfache Variante inklusive der Bedienoberfläche ist in Abbildung 2.4 exemplarisch zu sehen. Über die untere Menüleiste können aus verschiedenen Paletten Modellierungs- und Analyseknoten oder Datenbankoperationen ausgewählt werden und zu Streams kombiniert werden. Je nach Ziel des Streams bestehen Teilaufgaben des Modeler Clients aus Datenvorbereitung, Modellerstellung und Modellscoring. Die Vorbereitung der Daten umfasst dabei zum Beispiel das Einbinden von Datenbanken oder Dateien, in Abbildung 2.3 das erste Icon. Weiterhin sind die folgenden beiden Icons in der Abbildung der Datenvorbereitung zuzuordnen, in SPSS Modeler wird dieser Knotentyp auch Feldfunktion oder -operation genannt. Dabei werden etwa Datentypen angepasst, zusammengeführt oder Rollen für eine folgende Modell- Erstellung vergeben. Die zweite Zeile von Knoten in der Abbildung 2.3 zeigt zuerst ein Knoten zur Modellberechnung, der dann ein goldenes und damit berechnetes Modell folgt. Der letzte Knoten zeigt dann einen Ausgabeknoten in eine Tabelle einer Datenbank. In Abbildung 2.4 ist somit eine Datenvorbereitung zu sehen, an deren Ende mit dem Knoten RESPONSE die Modellberechnung stattfindet. Dies geschieht mit Trainingsdaten, bei denen das Ergebnis bereits bekannt ist, um das Modell möglichst gut zu trainieren. Die zweite Zeile 12

18 2.3 Wissensentdeckung in Datenbanken zeigt dann einen Scoring-Prozess, der mit dem vorher berechneten Modell Datensätze bewertet und die Ergebnisse in eine Tabelle schreibt. [sps12b, sps11c] Abbildung 2.3: SPSS Modeler Übersicht verschiedene Knoten IBM SPSS Modeler Server Zentrale Aufgaben des SPSS Modeler Server sind die Durchführung von Berechnungen, die in Streams genutzt werden, und die Bereitstellung von Erweiterungen sowie Diensten. So können Modelle direkt über entsprechende Schnittstellen auf z/os DB2 berechnet und bereitgestellt werden. Diese können dann über den SPSS Modeler Server Scoring Adapter genutzt werden, um Transaktionen direkt aus dem OLTP-Umfeld heraus über das Modell zu bewerten (Scoring). [ECRS12] Im Modeler Server werden zudem die Datenquellen eingebunden, sodass nicht jeder Client einzeln Daten erfragen muss. Zwei verschiedene Ansätze spiegeln einen typischen Einsatz des Modeler Servers wider. Dies ist zum einen die Nutzung des Servers auf dem gleichen Rechner, auf dem auch der Modeler Client installiert ist. In diesem Fall wird SPSS Modeler für kleinere Datenanalysen verwendet, etwa in kleineren Unternehmen oder bei geringem Datenvolumen. Der andere Ansatz ist eine Installation mit mehreren Modeler Clients, die über einen Modeler Server auf die Daten zugreifen. Dieser Server befindet sich dann zum Beispiel auf einem virtualisierten Linux auf System z und hat damit einen schnellen Zugriff auf angebundene Daten. [sps11d] IBM SPSS Modeler CLEF Das Component-Level Extension Framework (CLEF) ist eine Möglichkeit, die Funktionalität des SPSS Modelers um benutzerspezifische Aufgaben zu ergänzen. Eine Verwendung von CLEF kann sein, neue Nodes oder Menüpunkte im 13

19 2.3 Wissensentdeckung in Datenbanken Abbildung 2.4: IBM SPSS Modeler Benutzeroberfläche mit einfachem Stream, mit welchem nach der Datenaufbereitung ein Modell für Kunden im Telekommunikationsbereich erstellt wird. In der zweiten Zeile wird das berechnete Modell dann auf neue Kundendaten angewandt (Scoring) und beispielhaft in einer Tabelle ausgegeben. 14

20 2.4 Data-Mining-Modelle SPSS Modeler anzubieten, um bestehende Funktionen zu erweitern oder um neue Modelle zu unterstützen. Die Architektur ist wie der SPSS Modeler ein Client/Server-Modell, sowohl die Client- als auch Server-Komponenten sind in Abbildung 2.5 dargestellt. Im einfachsten Fall wird für eine Erweiterung nur eine Spezifikationsdatei benötigt. Über die Java API sowie der Verwendung eigener Java-Klassen können zudem größere Änderungen an der Benutzeroberfläche durchgeführt werden. Schon mit der Installation von IBM SPSS Modeler kommen viele CLEF-Erweiterungen zum Einsatz, so etwa Modelle wie K- Nearest-Neighbor (KNN), Neuronales Netz, Cox-Regression oder Bayessches Netz. Diese Modelle werden wie jede andere Berechnung auf dem Server ausgeführt, wofür serverseitig Erweiterungen in C/C++ (Shared Libaries) vorhanden sein müssen, welche die Umsetzung steuern beziehungsweise die Berechnung durchführen. Verwaltungsaufgaben können etwa sein, dass der Modeler Server den Client anfragt, welches Modell erstellt werden soll oder das nach der Modellerstellung nicht mehr benötigte Objekte gelöscht werden. [sps12c] 2.4 Data-Mining-Modelle In IBM SPSS Modeler können auf der Grundlage von Daten neue Zusammenhänge gefunden werden, die dann als Modelle eingesetzt werden, um Prozesse zu optimieren. Im weiteren Verlauf der Arbeit werden einige Modelle verwendet, über welche in diesem Abschnitt ein Überblick gegeben werden soll. Dabei werden zuerst zwei Algorithmen zur Erstellung von Entscheidungsbäumen erläutert, wonach zwei Methoden zur Berechnung von Regelsätzen für eine Enscheidungsanalyse vorgestellt werden Entscheidungsbaum Mit Entscheidungsbäumen kann eine automatische Klassifizierung von Datenobjekten mit Hilfe von Entscheidungsregeln, welche an den Knotenpunkten im Baum überprüft werden, durchgeführt werden. Mit einem fertig erstellten Entscheidungsbaum können demnach neue Daten schnell in bestimmte Klassifikationen eingeordnet werden. Unterschieden werden dabei binäre und nicht-binäre Bäume, bei binären Entscheidungsbäumen erfolgt eine Beschränkung auf zwei Auswahlmöglichkeiten als Ergebnis einer Regel. Entscheidungsbäume finden in vielen Data-Mining-Szenarien Verwendung, da Sachverhalte mit vielen Eigenschaften gut abgebildet werden können, die dann zusätzlich von Menschen intuitiv zu handhaben sind. Die Erstellung von Entscheidungsbäumen kann entweder manuell erfolgen oder über Algorithmen, die einen Entscheidungsbaum induzieren. Dabei gibt es unterschiedliche Methoden wie CHAID von Kass [Kas80] oder CART von Breiman et al. [BFOS84]. 15

21 2.4 Data-Mining-Modelle Erweiterungsmodule im Client Spezifikationsdatei (*.xml) Bilder, Hilfsdateien, Dateien zur Übersetzung erweiterung.jar oder *.class Dateien CLEF clientseitige Java API SPSS Modeler Client SPSS Modeler Server CLEF serverseitige C-API Erweiterungsmodule im Server serverseitige shared Libraries (erweiterung.dll) C++ Helper Abbildung 2.5: Client- / Server-Komponenten der CLEF-Architektur: Die clientseitigen Erweiterungsmodule kommunizieren über die Java API mit dem Client, welcher die nötige Kommunikation mit dem Server aufrecht erhält. Dieser wiederum verständigt sich serverseitig mit einer C API, um Node-Funktionen auszuführen. (Quelle: [sps12c]) 16

22 2.4 Data-Mining-Modelle CHAID ist ein Vertreter zur Erstellung nicht-binärer Bäume und wird oft im Marketing eingesetzt, auf Basis von CART hingegen werden ausschließlich binäre Entscheidungsbäume erstellt. In jedem Falle ist für die Erstellung eines Entscheidungsbaumes eine möglichst große Menge von Trainingsdatensätzen nötig, welche viele Parameter zur Einschätzung des Szenarios beinhaltet. Beispielsweise sollten für ein Kreditrating die Einkommenszahlen, die Anzahl der Kreditkarten und der Erfolg oder Misserfolg über die Rückzahlung vermerkt sein. Der Vorgang zur Erstellung ähnelt sich bei CHAID und CART, der Baum wird jeweils von oben herab rekursiv aufgebaut, dabei wird an jedem Knoten über ein Selektionsmaß das Attribut auswählt, welches die Daten am besten aufteilt. In den darunterliegenden Knoten wird aus den verbliebenen Attributen erneut das statistisch relevanteste gewählt und dadurch die Datenmenge erneut aufgeteilt. Dies erfolgt entweder solange, bis keine Attribute mehr zur Auswahl stehen oder durch die Wahl der maximalen Tiefe des Baumes, nachdem der Algorithmus stoppen soll. [HK00, sps12d] CHAID CHAID (Chi-squared Automatic Interaction Detectors) prüft alle zu bewertenden Attribute über den χ 2 -Test und ermittelt darüber das Attribut mit der höchsten statistischen Signifikanz, welches damit an dieser Stelle den optimalen Parameter zur Aufteilung für den nächsten Knoten darstellt. Eine Stärke von CHAID ist, dass nicht-binäre Bäume erstellt werden können. Die Beliebtheit im Bereich Marketing stammt daher, dass die Aufteilung in mehrere Unterkategorien (etwa 4 Einkommenskategorien) auf einer Ebene des Baumes für die Einteilung in Marktsegmente genutzt wird. [sps12d, HL06] CART In dem Buch Classification and Regression Trees (CART) von Breiman et al. [BFOS84] wird die Generierung von binären Entscheidungsbäume beschrieben. Die Auswahl für die nächste Aufteilung findet durch die Berechnung eines statistischen Maßes, entweder der Gini-Koeffizient oder über den mittleren Informationsgehalt. Die Wahl des Attributes mit dem höchsten Informationsgehalt versucht dabei etwa, die Daten mit hohem Informationsgehalt zuerst einzuordnen, damit danach weniger Information fehlt, um die Klassifizierung abzuschließen. Nach der Erstellung des Baumes können über Pruning (oder Beschneiden) des Baumes unerwünschte Anomalien oder eine zu hohe Anpassung auf die Gegebenheiten der Testdaten (Overfitting) ausgefiltert werden. Diese Aufgabe wird am besten mit Transaktionen durchgeführt, die nicht in den Testdaten vorhanden sind. Der resultierende Baum ist dann oft einfacher als ein nicht beschnittener Baum. [HK00, HL06] 17

23 2.4 Data-Mining-Modelle Assoziationsanalyse Treten bestimmte Datensätze in einer Menge von Transaktionen regelmäßig zusammen auf, etwa beim Kauf von einem Handy und einer Handytasche oder bei einer Patientenuntersuchung Symptome wie Halsschmerzen und Fieber, lassen sich diese zu Regeln zusammenfassen, die zu neuen Erkenntnissen in Datenbeständen führen können. Die Erstellung dieser Regelsätze auf einer Datenmenge innerhalb festgelegter Grenzen wird als Assoziationsanalyse bezeichnet, Einsatzbereiche sind zum Beispiel das Finden von neuen Zusammenhängen in Datenbeständen oder eine unterstützende Analyse für eine Klassifizierung von Daten. Bei der Suche nach Regeln sind zwei Parameter besonders wichtig. Zum einen der Support, der angibt, für welche Prozentzahl der Transaktionen die Regel gilt und zum anderen die Konfidenz, die aussagt, bei wieviel Prozent der Käufer die Wahl Handy zu Handytasche führt. Zusätzlich werden in der Regel für eine Analyse der minimale Wert für Support und Konfidenz angegeben, damit zur Berechnung eine untere Grenze für etwaige Regeln feststeht. Die Menge der gefundenen Regeln wird auch als häufige Itemsets bezeichnet. Ein einzelnes Itemset ist also eine Anzahl von Items, die zusammen häufig auftreten. Für die Durchführung der Assoziationsanalyse können verschiedene Algorithmen verwendet werden, wofür im Folgenden zwei Vertreter vorgestellt werden. [HK00] Apriori Bereits 1994 von Agrawal et al. [AIS93] vorgestellt, findet Apriori in zwei Teilschritten häufige Regelsätze. Zuerst erfolgt die Generierung von Kandidaten, beginnend mit Itemsets der Länge k = 1. Demnach werden alle häufigen Items als Kandidaten behandelt, welche die Bedingungen für den minimalen Support erfüllen. Mit diesen Itemsets erfolgt die Suche nach Itemsets der Länge k + 1, was solange durchgeführt wird, bis keine neuen häufigen Itemsets mehr gefunden werden können. In jedem Unterschritt werden Werte aussortiert, die den minimalen Support nicht erreichen. Ab k 2 wird das Wissen über die zurückliegend (k 1) als häufig befundenen Kandidaten in einem zweigeteilten Subprozess verwendet, um die Kandidaten der folgenden Stufe (k) zu ermitteln. Join der Kandidaten aus k 1 mit sich selbst. Prune (Aussortieren) von möglichen Kandidaten, die Teilmengen enthalten, welche nicht in denen aus Schritt k 1 bekannt waren. Dieser Prozess wird so lange fortgeführt, bis keine neuen Kandidaten gefunden werden können. Mit den berechneten Kandidaten werden alle Transaktionen in der Datenbank nach Kandidaten wie folgt erneut durchsucht. Jede Fundstelle eines jeden Kandidaten in einer beliebigen Teilmenge einer Transaktion wird 18

24 2.4 Data-Mining-Modelle gezählt und am Ende wird die Anzahl der Fundstellen pro Kandidat genutzt, um das Support-Kriterium zu überprüfen. Nach der Generierung der Kandidaten kann der zweite Teilschritt ausgeführt werden. Dies umfasst die Erstellung der tatsächlichen Regeln mit der Prüfung, ob der Mindestwert für die Konfidenz erreicht wird. Da die Konfidenz die Wahrscheinlichkeit widergibt, mit welcher nach Item A auch Item B folgt, kann der Wert über die Bedingte Wahrscheinlichkeit P (B A) ermittelt werden. [HK00, AIS93] Konfidenz(A B) = P (B A) = Support(A B) Support(A) (2.1) Diese Gleichung 2.1 wird für alle Regeln angewandt, die auf folgende Art und Weise bestimmt werden: Berechne für jeden Kandidaten k die nichtleeren Teilmengen t Gib für jedes t k die Regel t k \ t an, wenn gilt: Support(k) Support(t) Minimum Konfidenz (2.2) Das Ergebnis ist die Menge aller Regelsätze mit den geforderten Eigenschaften auf der gegebenen Datengrundlage. [HK00] FP-growth Der Ansatz für den FP-growth-Algorithmus (Frequent-pattern-growth) ist aus der Erkenntnis heraus entstanden, dass die Generierung von Kandidaten bei Apriori umfangreich ausfallen kann. Wenn bei Apriori eine große Menge an Kandidaten existiert, muss für viele Kandidaten überprüft werden, ob sie Teilmengen enthalten, die nicht im vorherigen Schritt bekannt waren. Das Ziel des FP-growth ist es daher, die Generierung von Kandidaten allgemein zu vermeiden. Im ersten Schritt wird analog zum Apriori das Vorkommen von einzelnen Items in der Datenbank vermerkt, die entstehende Liste L wird absteigend, beginnend mit dem häufigsten Eintrag gespeichert. Darauf aufbauend wird jede Transaktion aus der Datenbasis in einen FP-tree nach folgendem Schema einsortiert. Die einzelnen Posten einer Transaktion werden nach ihrer Position in der Liste L in einen Baum einsortiert, immer beginnend bei der Wurzel, die den Wert null hat. Wenn in einem ersten Schritt A, B und C einsortiert werden sollen, ist A das Kind von null, B das Kind von A und schließlich C von B. Jedem Knoten wird die Häufigkeit des Vorkommens angeheftet, an dieser Stelle für jeden Knoten 1. Als nächstes soll die Transaktion mit A, B, D und C einsor- 19

25 2.5 Data-Warehouse-Systeme tiert werden. Da A schon als Kind unter der Wurzel existiert, wird hier nur die Häufigkeit des Vorkommens auf 2 erhöht, was zudem auch für B zutrifft. D ist bisher nicht als Kind von B eingetragen, wird demnach neu angelegt und mit 1 bewertet. Das letzte Item C existiert zwar schon in einem benachbarten Pfad, allerdings wird es unter D neu als Kind erzeugt und das Vorkommen in diesem Pfad mit 1 bewertet. Nachdem Einfügen aller Transaktionen in den Baum werden in der Liste L alle vorkommenden Stellen des jeweiligen Items als Referenz angegeben. Anstatt Kandidaten zur Erstellung von Regeln zu verwenden, erfolgt das Mining jetzt über die Suche von Mustern in dem FP-tree. Beginnend mit dem seltensten Wert s aus der Liste L werden alle Pfade zur Wurzel notiert, die das Support-Kriterium erfüllen. Diese Pfade werden pro Wert in L als neuer, bedingter FP-tree gespeichert und geben Regeln wider, die s enthalten. [HK00] 2.5 Data-Warehouse-Systeme Zu Beginnn von diesem Abschnitt soll eine Definition des Begriffs nach einem Zitat von Inmon [Inm96] den Grundgedanken von einem Data-Warehouse widerspiegeln: A data warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management s decisionmaking process. Relevant ist somit einerseits der Begriff subject-oriented als Anwendungsbezug auf die jeweilige Umgebung, in der ein Data-Warehouse eingesetzt werden soll. Mit integrated wird der Hinweis gegeben, dass verschiedene Datengrundlagen in eine gebündelte und angepasste Datenbank aufgenommen werden. Weiterhin wird mit time-variant ausgedrückt, dass Daten über einen längeren Zeitraum vorliegen sollen und somit historische Analysen ermöglicht werden. Letztlich der Ausdruck nonvolatile, welcher nahelegt, dass die Daten vom transaktionalen System getrennt werden und somit nach dem Laden auf das Data-Warehouse in der Regel nicht mehr geändert werden [HK00]. Ergänzt um Funktionen zur Datenintegration und -analyse entsteht das Data-Warehouse- System, wobei die Vorgehensweise oft ist, die Daten einmal pro Woche aus den Quellsystemen zu importieren und dann darauf viele lesende Zugriffe laufen zu lassen, etwa zur Erstellung von Berichten. Dieser Prozess der Datenbeschaffung wird allgemein auch als ETL-Prozess bezeichnet und findet in einer vom operationalen Geschäft unabhängigen Staging Area (auch Arbeitsbereich) statt, um bestehende Vorgänge nicht zu beeinflussen. Die nachfolgenden drei Schritte beschreiben den ETL-Prozess näher nach [BG08]: 20

26 2.5 Data-Warehouse-Systeme Extract Die Extraktion der geforderten Daten erfolgt aus den Quellsystemen über festgelegte Schnittstellen wie ODBC. An dieser Stelle finden die ersten Überprüfungen statt, ob die Daten korrekt erfasst worden sind. Aufgrund der Komplexität des ETL-Prozesses wird dieser Schritt meist nur periodisch durchgeführt. Transform Dieser Arbeitschritt beinhaltet die Anpassung der Quelldaten an das Zielformat, beispielsweise mit der Anpassung von Datentypen oder Datumsangaben an die Data-Warehouse-Umgebung. Zudem fällt in diesen Schritt die Überprüfung der Daten auf eventuell fehlende oder doppelt vorhandene Werte, auch können veraltete Datensätze anders behandelt oder potentiell fehlerhafte Daten aussortiert werden. Load Der abschließende Lade-Prozess überführt die vorbereiteten Datensätze in das Data-Warehouse. Dies kann durch den Aufbau einer historischen Struktur erfolgen, etwa durch eine blockweise Speicherung pro Import (stündlich, täglich). Eine zweite Möglichkeit ist, die alten Daten zu verwerfen und nur die neuen Datensätze zu speichern. [BG08] Der Aufbau eines Data-Warehouse-Systems dient somit vor allem dem Bearbeiten von analytischen Datenbankanfragen (OLAP, Online Analytical Processing) und unterscheidet sich mit diesem Fokus stark von transaktionalen Systemen (OLTP, Online Transaction Processing). Aus diesem Grund werden in Tabelle 2.1 einige grundsätzliche Unterschiede zwischen beiden Anfragetypen. Resultierend daraus ist für transaktionalen Workload auf einem Datenbanksystem die Shared-Disk-Architektur optimal geeignet. Zum Beispiel kann die Verteilung von Aufgaben besser auf einem Shared-Disk-System gesteuert werden, auch sind bei einem Ausfall von Prozessoren keine Daten unerreichbar und eine parallele Ausführung von Anfragen ist zudem auch einfacher zu administrieren. Wenn bestimmte Daten, die von einem Rechner in einem Shared-Nothing-System verwaltet werden, überlastet ist, gibt es keine Möglichkeit, die Belastung zu verringern. Für analytischen Workload auf einem Data- Warehouse ist der Shared-Nothing-Ansatz jedoch der interessantere, weil ein paralleler und unabhängiger Zugriff auf die Daten hinter einem Rechner stattfinden kann. Bei umfangreichen Anfragen können für die vorhandenen Datensätze auf jedem Teilsystem Aufgaben durchgeführt werden. [Rah94] Die Anbieter von Data-Warehouse-Systemen erreichen die geforderten Eigenschaften mit dem Einsatz verschiedener Techniken wie spezieller Hardware oder Optimierung der SQL-Ausführung. Auch gibt es verschiedene Schwerpunkte der Hersteller wie Skalierbarkeit, Flexibilität oder Unterschiede in der Geschwindigkeit, neue Daten in das Data-Warehouse zu übernehmen. Demnach gibt es bei der Konzeption von Data-Warehouse-Systemen je nach Zielsetzung und Anforderungen mehr oder weniger geeignete Kandidaten. [BG08] 21

27 2.6 Data-Warehouse-Appliance Vergleich transaktional analytisch Aktion auf Daten- vor allem Schreiben, vor allem Lesen, bank wenig Lesen Hinzufügen Struktur der An- kurz, einfach struk lang, komplex frage turiert Anzahl Anfragen viele wenige Verarbeitete Daten- geringe Anzahl große Anzahl sätze pro Abfrage Eigenschaften der zeitaktuell, dynamisch historisch, stabil Daten Anwender viele Sachbe- wenige Analysten arbeiter Antwortzeit im Sekundenbereich eher Minuten - Stunden oder weniger Tabelle 2.1: Unterschiede bei transaktionalen und analytischen Datenbankanfragen, basierend auf [BG08] 2.6 Data-Warehouse-Appliance Data-Warehouse-Appliances stellen für Kunden eine Komplettlösung dar, die vordefinierte Software und Hardware einsetzt, um die Konzeption zur Erstellung von einem Data-Warehouse zu erleichtern. Im Detail bedeutet das, dass eine solche Appliance ein System aus Hardware und Software zum Data- Warehousing darstellt, um in diesem Gesamtpaket ohne weitere Ergänzungen benutzbar zu sein. Die Hardware umfasst dabei neben Servern auch die kompletten Storage-Kapazitäten, wonach die Preisgestaltung der Data-Warehouse- Appliances erfolgt. Anbieter von Data-Warehouse-Appliances wie Teradata oder IBM setzen bei der technischen Umsetzung auf eine massiv parallele Berechnung (MPP-System) und verwenden dabei einen Shared-Nothing Rechnerverbund [Bal, BBF + 12]. Abgerundet werden diese Pakete durch Dienstleistungen etwa bei Inbetriebnahme und Wartung und in diesem Gesamtpaket zudem damit beworben, leichter zu administrieren und schneller einsatzbereit zu sein als bisherige Data-Warehouse-Systeme. [BFAE12] Als Beispiel für diese Appliances wird im Folgenden der IBM DB2 Analytics Accelerator (IDAA) vorgestellt. 22

28 2.6 Data-Warehouse-Appliance Übersicht IDAA Anhand von Abbildung 2.6 soll als erster Schritt die Sicht von außen auf ein System z196 mit angeschlossenem IDAA gezeigt werden. Dabei wird deutlich, dass der Beschleuniger über 10 Gbit Netzwerkanschlüsse mit dem Mainframe verbunden ist. Aus Anwendungs- und Benutzersicht ist der DB2 Analytics Accelerator nicht zu erkennen, er ist demnach von extern gesehen vollkommen transparent. Dies bringt unter anderem den Vorteil mit sich, dass der Accelerator in die durch z/os vorhandenen Sicherheitskonzepte eingebunden wird. Weiterhin muss die Sicherheit der Daten durch die alleinige Anbindung an das System z nur auf diesem einen System gewährleistet werden. werden muss. Die Administration erfolgt über das Eclipse-basierte IDAA Data Studio, welches über Schnittstellen im DB2 auf den IDAA zugreifen kann. Welche Query über den DB2 Analytics Accelerator beschleunigt werden oder ansonsten vom DB2 selbst besser bearbeitet werden, entscheidet das DB2 automatisch nach vorgegebenen Regeln. [BBF + 12] Abbildung 2.6: Übersicht der IDAA-Komponenten: Anwendungen greifen ohne Änderung über das DB2 auf die Daten zu, im Hintergrund werden bestimmte Queries durch Netezza beschleunigt. Die Administration des DB2 Analytics Accelerator erfolgt über das Programm IDAA Data Studio. (Quelle: [BBF + 12]) 23

29 2.6 Data-Warehouse-Appliance Nach dieser allgemeinen Einführung werden einzelne Komponenten genauer beschrieben, wofür Bezug auf Abbildung 2.7 genommen wird. Zu erkennen ist in der Abbildung der zentrale Punkt für die Ausführung von Queries: DB2 auf z/os. Von der Anwendung an die DB2 API abgesetzt, wird jede eingehende Datenbankanfrage direkt weitergereicht an den DB2 Optimizer, wo abgeschätzt wird, auf welchem System die Anfrage geringere Bearbeitungskosten erzeugt. Demnach ist der Optimizer für die Verteilung von Queries nach vorgegebenen Abbildung 2.7: Weg von SQL Queries durch ein z/os DB2, dabei trifft der DB2 Optimizer die Entscheidung, ob die Query über den DB2 Analytics Accelerator beschleunigt wird (Quelle: [BBF + 12]). Kriterien verantwortlich und entscheidet, ob die Ausführung vom DB2 selbst übernommen wird, oder ob sie an den DB2 Analytics Accelerator weitergeleitet wird. Dabei werden etwa Voraussetzungen wie das Vorhandensein eines Beschleunigers überprüft und zudem, welche Tabellen bereits vorhanden und damit accelerated sind, um dann mithilfe von Heuristiken festzustellen, ob die Query für IDAA geeignet ist. Komplexe analytische Queries auf Faktentabellen sind ein Beispiel, welches vom Accelerator besonders stark profitieren kann, im Gegensatz dazu sind Anfragen auf einzelne, über Indices optimierte Tabellen weniger geeignet für die massiv parallele Bearbeitung auf dem IDAA und werden daher direkt auf DB2 ausgeführt. Direkt vom DB2 bearbeitete Queries wer- 24

30 2.6 Data-Warehouse-Appliance den nach der Optimierung über die jeweiligen Zugriffspfade ausgeführt und das entsprechende Ergebnis über die DB2 API an die ursprüngliche Anwendung geschickt. Datenbankanfragen, bei denen mit einer Beschleunigung gerechnet wird, werden noch auf der DB2 auf z/os durch den IDAA DRDA 1 Requestor an den IDAA Server Coordinator (auch SMP Host) weitergeleitet, welcher die einzige Schnittstelle zwischen dem Mainframe und der IDAA Erweiterung selbst darstellt. Insgesamt ist durch diese Aufteilung des Workloads eine Umgebung für gemischten Workload, wie etwa OLTP- und OLAP-Workload, geschaffen. Die weitere Verarbeitung findet dann auf der Erweiterung selbst statt und wird im nächsten Abschnitt näher betrachtet. [BBF + 12] IDAA im Detail Der Aufbau des DB2 Analytics Accelerator ist in drei Bereiche untergliedert, die in Abbildung 2.8 zu sehen sind. Bei der Hardware wird dabei vor allem auf Technologie der von IBM aquirierten Netezza Corporation gesetzt, was im Folgenden näher erläutert wird. Alle eingehenden Queries werden im grün markierten Bereich SMP Hosts in einem ersten Schritt verarbeitet. Die SMP Hosts, aufgrund ihrer Aufgabenstellung auch DB2 Analytics Accelerator Server oder Coordinator genannt, steuern die Query-Verteilung und sind wie bereits in Abschnitt beschrieben für den Datenaustausch mit dem z/os DB2 verantwortlich, außerdem wird darüber das System administriert. Die Verteilung der Queries erfolgt auf den in der Abbildung darunterliegenden blauen Bereich mit seinen Snippet Blades, von diesen auch Worker Nodes genannten Blades kann ein Accelerator bis zu zwölf Stück besitzen. Jedes dieser Snippet Blades wiederum beherbergt acht CPU Cores sowie acht FPGAs sowie lokalen Hauptspeicher. Desweiteren ist jeder Worker Node exklusiv mit acht Festplatten aus dem grauen Bereich Disk Enclosures verbunden, er kann demnach nur auf Daten auf diesem Verbund zugreifen, was dem Cluster-Ansatz Shared- Nothing entspricht. Diese unabhängig voneinander arbeitenden Snippet Blades werden im Verbund als Assymetric Massive Parallel Processing-System bezeichnet, da die Aufgaben von den SMP Hosts verteilt werden und auf jedem Snippet Blade eigener Hauptspeicher sowie Shared-Nothing Zugriff auf den angeschlossenen Speicher existiert. Diese parallele Verarbeitung ist vor allem für OLAP-typischen Workload mit komplexen Anfragen auf große Datenmengen nützlich. [Rah94, BBF + 12] Als nächstes wird die Verarbeitung von Queries auf dem Snippet Blade beschrieben. Die erste Aufgabe ist es, die komprimierten Daten vom angeschlos- 1 Distributed Relational Database Architecture, Standard für Interoperabilität bei Datenbanken von The Open Group: (zuletzt aufgerufen am ) 25

31 2.6 Data-Warehouse-Appliance Abbildung 2.8: Technische Grundlagen im IBM DB2 Analytics Accelerator, die SMP Hosts in der Mitte sind für die zentrale Verteilung der Aufgaben auf die darunterliegenden Snippet Blades zuständig. Snippet Blades wiederum erledigen die Arbeit mithilfe FPGA-Hardwarebeschleunigung und sind jeweils exklusiv pro Blade an einen Verbund von acht Festplatten angeschlossen (Quelle: [BBF + 12]). 26

32 2.6 Data-Warehouse-Appliance senen Festplattenverbund zu lesen und im Hauptspeicher zu cachen. Ab hier erfolgt die Bearbeitung der Daten in mehreren parallelen Streams, was in Abbildung 2.9 schematisch für einen der acht FPGA pro Snippet Blade dargestellt ist. Der FPGA holt die Daten per Direct Memory Access aus dem Hauptspeicher und dekomprimiert diese. Danach beschränkt der FPGA die Spalten und Zeilen entsprechend der SELECT und WHERE Angaben. Dekomprimieren und Beschränken der Spalten und Zeilen sind somit spezielle Aufgaben, auf deren Bearbeitung der FPGA konfiguriert ist. Durch die hardwarebasierte Vorverarbeitung im FPGA operiert die CPU auf einer stark reduzierten Datenmenge und erledigt komplexe Aufgaben wie Joins und Aggregationen, die nicht im FPGA implementiert sind. [BBF + 12] Abbildung 2.9: Query Bearbeitung in einem Snippet Blade, auf jedem der acht Cores wird ein Teil der Daten bearbeitet, dabei übernimmt jeweilig der FPGA das Dekomprimieren und das Beschränken der Daten auf die benötigten Zeilen und Spalten. Danach kann die CPU die überbleibenden komplexen Aufgaben auf reduziertem Ausgangsmaterial durchführen (Quelle: [BBF + 12]) IBM Netezza Analytics IBM Netezza Analytics (INZA) gibt externen Anwendungen die Möglichkeit, direkt auf der Netezza-Hardware analytische Aufgaben durchzuführen. Mit 27

33 2.6 Data-Warehouse-Appliance diesen auch In-Database Analytics genannten Funktionalitäten können etwa Modellierungs- oder Scoringschritte in SAS oder IBM SPSS massiv parallel auf dem DB2 Analytics Accelerator berechnet werden. Zudem bietet INZA eine Entwicklungsumgebung für eigene Erweiterungen an, mit denen Aufgaben wie MapReduce auf Hadoop auf IDAA berechnet werden können. Eine Übersicht der unterstützten Programme und Frameworks, die auf Netezza Analytics zurückgreifen können, ist in Abbildung 2.10 zu sehen. Die Funktionsweise ist in jedem Fall, dass Anwendungen Stored Procedures in DB2 auf z/os aufrufen, welche den Befehl mitsamt den Parametern weiterleiten an Netezza. Dort wird eine weitere Stored Procedure aufgerufen, die dann die entsprechenden INZA-Befehle ausführt. [Man09] Abbildung 2.10: IBM Netezza Analytics Paket (INZA), verwendet zur Ausführung von analytischen Funktionen direkt auf dem DB2 Analytics Accelerator. (Quelle: [Man09]) Performance IDAA Für eine Einschätzung der Performance von IDAA wird auf einen Bericht zurückgegriffen, der für eine Beschleunigung eines SAP NetWeaver Business Warehouse erstellt wurde [RM11]. Auf einer Datenbasis von 2 und 18 Millionen Datensätzen wurde dabei getestet, welche Leistungsteigerungen bei typischen Queries wie massiven Aggregationen oder vielen Restriktionen erreicht 28

34 2.6 Data-Warehouse-Appliance werden können. Bei der kleineren Datengrundlage wurde im Schnitt eine Beschleunigung von Faktor 9 erreicht, bei 18 Millionen Datensätzen erreicht der Test eine 73x schnellere Bearbeitung. Aufgrund der hoch parallelen Architektur der IDAA ist zudem zu erwarten, dass bei noch größeren Datenmengen bessere Ergebnisse erzielt werden. Ein zweiter Test wurde mit Hilfe zufällig erzeugter Datenbankanfragen auf einer Basis von 6 Millionen Datensätzen durchgeführt, wobei die Steigerung der Performance im Durchschnitt den Faktor 12 ergeben hat. In einer zweiten Arbeit für ein großes Versicherungsunternehmen beträgt der Geschwindigkeitszuwachs für verschiedene typische Business-Reporting- Anfragen auf bis zu 813 Millionen Datensätzen Faktor 13 bis 1908 [Pes12]. 29

35 3 Stand der Technik Nach der Beschreibung von grundlegenden Technolgien und Vorgehensweisen im letzten Kapitel wird darauf aufbauend ausgeführt, wie das Zusammenspiel zwischen den beteiligten Komponenten aussehen kann. Im ersten Abschnitt 3.1 werden aus diesem Grund zwei verschiedene Umgebungen für einen typischen Einsatz von SPSS Modeler in Unternehmen vorgestellt. Die dabei gezeigten Probleme und Schwächen werden im Abschnitt 3.2 als Herausforderung für eine Machbarkeitsstudie gesehen, die untersucht, inwiefern Modellierungsprozesse im IBM SPSS Modeler mit Hilfe eines DB2 Analytics Accelerator beschleunigt werden können. Im Zuge dessen wird der dabei entstandene Prototyp zur Umsetzung beschrieben und auf bestehende Herausforderungen eingegangen. Letztendlich werden im Abschnitt 3.3 zwei praxisnahe Szenarien vorgestellt, die für eine Performance-Messung zum einen auf Basis existierender Technologie und zum anderen unter Verwendung des Prototypen genutzt werden sollen. Im weiteren Verlauf der Arbeit werden diese Szenarien zudem genutzt, um nötige Anpassungen für die Abbildung auf den DB2 Analytics Accelerator zu untersuchen. 3.1 Modellierung auf Basis existierender Technologie In diesem Abschnitt sollen zwei verschiedene Ansätze präsentiert werden, wie in Unternehmen oder Organisationen OLAP-typische Aufgaben wie Data- Mining durchgeführt werden. Dazu wird im ersten Teil eine auf System z aufbauende Umgebung gezeigt, in welcher SPSS Modeler unter Linux auf System z direkt auf die per Data Sharing eingebundenen Ressourcen zugreifen kann. Der zweite Teil stellt dann eine Lösung dar, in der über ETL- Prozesse eine Auslagerung der Daten in ein externes Data-Warehouse-System erfolgt SPSS Modeler auf System z SPSS Modeler läuft in diesem Szenario auf Linux for System z, was in Abbildung 3.1 aufgezeigt wird. Dort ist zu sehen wie der Zugriff auf das DB2 30

36 3.1 Modellierung auf Basis existierender Technologie und damit den angeschlossenen Ressourcen von SPSS Modeler aus per Hiper- Socket ermöglicht wird. Demnach führt SPSS Modeler in diesem Ansatz analytische Queries direkt über DB2 aus. Über Data Sharing erfolgt dabei zum Beispiel Lastbalancierung, welche durch die Coupling Facility (CF) gesteuert wird. In bestimmten Szenarien kann es dazu kommen, dass OLAP-Workload nicht mit der höchsten Priorität bearbeitet wird. Die Beeinflußung und Steuerung der Ressourcen erfolgt dabei zum Beispiel über den z/os WLM. [BAP + 06] Wenn das OLTP-System etwa zusätzliche Ressourcen braucht, werden OLAP- Aufgaben auf DB2 B beschränkt und laufen mit begrenzten Ressourcen. Ein weiteres Szenario kann sein, dass OLAP-Aufgaben allgemein künstlich beschränkt werden, wodurch komplexer analytischer Workload viel Zeit zur Ausführung benötigt. Nach langen Berechnungen werden die Ergebnisse unter Umständen nicht mehr benötigt, die Nutzung der DB2-Rechenzeit muss jedoch troztdem bezahlt werden. Außerdem ist für historische Daten, die nicht mehr geändert werden, die Datenhaltung in einem transaktionalem Datenbanksystem nicht optimal. Dieses Szenario wird im Kapitel 5 für den vergleichenden Performance-Test verwendet. CF DB2 A OLTP, hohe Priorität... DB2 B OLAP, niedrige Priorität Linux on System z mit SPSS Modeler... t HiperSocket Abbildung 3.1: Modellierung auf System z über SPSS Modeler auf Linux on System z, dabei werden analytische Aufgaben über niedrige Prioritäten bei der Lastbalancierung beschränkt, wenn bestimmte Bedingungen eintreten. [BAP + 06] 31

37 3.2 Machbarkeitsstudie Modellierung auf IDAA Externes Data-Warehouse-System 3.2 In diesem zweiten Szenario werden die Daten per ETL-Prozess aus dem bestehenden transaktionalen System z in ein externes Data-Warehouse-System übertragen. Dieses System wird dann zur Ausführung von analytischen Aufgaben verwendet, wobei es den Vorteil hat, dass es nach der Überführung in das Data-Warehouse ohne Beeinflußung durch transaktionalen Workload arbeiten kann. Jedoch gibt es einige Nachteile, die im weiteren erläutert werden. Der ETL-Prozess ist mit seiner Anpassung an das neue Data-Warehouse- System mit seinen Gegebenheiten eine große Herausforderung, der zudem dazu führt, dass der Prozess nur bei Bedarf oder in gewissen Abständen stattfindet. Somit wird oft auf veralteten Daten gearbeitet. Weiterhin ist eine Rückführung von Ergebnissen mit einem erneuten Transformationsprozess verbunden. Durch die Verwendung einer getrennten Data-Warehouse-Lösung ist zudem die Sicherheit und Integrität der Daten mehr gefährdet, da beispielsweise neue Angriffsvektoren für Eindringlinge entstehen, die durch das gewachsene Sicherheitskonzept auf System z vermieden werden können. OLTP DBS ETL Ergebnisse OLAP Data- Warehouse Abbildung 3.2: ETL-Prozess für eine Quelle, wobei zusätzlich eine Rückführung für Ergebnisse in das Datenbanksystem gezeigt wird. 3.2 Machbarkeitsstudie Modellierung auf IDAA IBM System z ist für seine starke transaktionale Leistung bekannt, für große analytische Workloads muss das System jedoch anderen Anforderungen gerecht werden. Oft werden dafür isolierte Data-Warehouse-Systeme verwendet, die über komplexe ETL-Prozesse mit Daten befüllt werden. Die Verwendung von weiteren Systemen bringt zudem neue Fragen bei der Gewährleistung Datensicherheit und -integrität mit sich. Diese und weitere Kritikpunkte sind in den beiden im letzten Abschnitt 3.1 vorgestellten Szenarien ausführlicher dargestellt. Dieser Abschnitt stellt eine Machbarkeitsstudie des IBM Systems Optimization Competency Centers vor, die darauf abzielt, die oben genannten Kritikpunkte als Herausforderung zu sehen, um SPSS Modeler Workload wie 32

38 3.2 Machbarkeitsstudie Modellierung auf IDAA die Erstellung von Data-Mining-Modellen auf DB2 Analytics Accelerator zu ermöglichen. Für die Beschreibungen in diesem Abschnitt wurde dabei teilweise auf IBM-interne Dokumentationen zurückgegriffen. Die grundsätzliche Vorstellung des Ansatzes erfolgt im Abschnitt und daran anschließend werden die dafür entwickelten Erweiterungen für die bestehenden Systeme in Abschnitt präsentiert. Im letzten Abschnitt werden dann einige Herausforderungen dargestellt, die im Rahmen des neuen Ansatzes auftreten Ansatz Einer der treibenden Gedanken der Machbarkeitsstudie ist, dass der relativ neue IBM DB2 Analytics Accelerator basierend auf seiner Netezza-Technologie sehr gut für OLAP-typische Aufgaben geeignet ist. Bisher fand die Nutzung des Accelerators ausschließlich für einzelne, vom DB2 delegierte Queries statt. Ziel der Studie ist die Evaluierung, ob IDAA für die Erstellung von Data- Mining-Modellen - etwa mit SPSS Modeler - geeignet ist. Gegenstand der Untersuchung ist damit der komplette für die Modellierung nötige Zyklus, beginnend mit der Datenvorbereitung, gefolgt von der Modellerstellung, aber auch ein mögliches Update des Modells bei aktualisierten Daten sowie dem Prozess, dass berechnete Modell zum Scoring im transaktionalen Umfeld zu nutzen. Auf der technischen Seite sind dafür einige prototypische Erweiterungen wie eine angepasste grafische Oberfläche im SPSS Modeler sowie Anpassungen am DB2 und auf dem Accelerator benötigt, diese werden im folgenden Abschnitt detaillierter ausgeführt. Mithilfe von praxisrelevanten Szenarien soll zudem der mögliche Einsatzzweck gezeigt werden, außerdem werden die gewählten Beispiele in einem Performance-Test vergleichend mit der bisherigen Berechnung und mit dem neuen Ansatz verwendet. Mit der Nutzung des DB2 Analtics Accelerator für komplette analytische Berechnungen kann unter Umständen auf die Einbindung eines externen Data-Warehouse-Systems verzichtet werden, was die Komplexität für analytische Prozesse reduziert. Mögliche Vorteile sind zudem wegfallende ETL-Prozesse und somit auch ein schnellerer Zugriff auf die Daten, desweiteren ist durch die Zentralisierung auf die Plattform System z ein hohes Maß an Sicherheit vorhanden Prototypische Erweiterungen Damit Modelle und analytische Funktionen aus SPSS Modeler heraus direkt auf dem DB2 Analytics Accelerator aufgerufen werden können, müssen Änderungen an mehreren Stellen vorgenommen werden. Diese Änderungen sind von IBM im Zusammenhang mit der Machbarkeitsstudie entwickelt worden. Allgemein muss eine Zugriffsmöglichkeit von SPSS Modeler auf die INZA- 33

39 3.2 Machbarkeitsstudie Modellierung auf IDAA Befehle geschaffen werden, allerdings kann SPSS Modeler nicht direkt mit dem Accelerator kommunzieren. Da das ganze Szenario relativ komplex ist, wird in Abbildung 3.3 eine Übersicht über einen möglichen Aufruf gegeben. Die Änderungen für jeden Teilschritt werden nun beschrieben. Aufbauend auf einem Stream in SPSS Modeler Client wird unter Zurhilfenahme von CLEF- Erweiterungen auf dem SPSS Modeler Server SQL-Code generiert. Anstatt der Berechnung einer analytischen Funktion wie etwa einer Assoziationsanalyse löst die CLEF-Erweiterung den Aufruf der entsprechenden INZA-Funktion aus, die als Stored Procedure verpackt wird. Diese Stored Procedure wird an das DB2-Subsystem weitergeleitet, welches mit dem DB2 Analytics Accelerator verbunden ist. Dort wird der Aufruf samt Parameter von der DB2 API weitergeleitet an den Accelerator, genauer den SMP Host. Auf dem SMP Host innerhalb vom DB2 Analytics Accelerator erfolgt der Aufruf der tatsächlichen Stored Procedure und der folgenden Berechnung auf den einzelnen Snippet Blades (S- Blade). Das resultierende Modell wird dann auf dem DB2 Analytics Accelerator als Netezza-Tabelle gespeichert Herausforderungen Mit der neuesten Version 3.1 des IBM DB2 Analytics Accelerator kann ein automatisiertes Aktualisieren der Daten auf dem Accelerator nach Änderungen auf der DB2-Seite aktiviert werden. Basierend auf den Daten sind Data-Mining- Modelle entstanden, die dementsprechend auch aktualisiert werden müssen, damit die Ergebnisse beispielsweise für Business Analytics Prozesse verwendet werden können. Bei manchen Modellen, wie etwa der Assoziationsanalyse, gibt es Ansätze zum inkrementellen Data-Mining, was bedeutet, dass das Modell nicht komplett neu berechnet, sondern unter Verwendung der neuen Daten aktualisiert wird. Diese Idee wird im Abschnitt 4.3 näher untersucht und damit eine mögliche Optimierung vorgeschlagen. Eine weitere Herausforderung ist der Umgang mit Zwischenergebnissen, die auf der IDAA-Seite erstellt werden und dann auch auf DB2 gehandhabt werden müssen. Um die temporären Daten nicht auf DB2 kopieren zu müssen, werden auf DB2 stattdessen nur sogenannte Proxy-Tabellen ohne den wirklichen Inhalt angelegt. Sobald auf diese Tabellen zugegriffen wird, erfolgt eine Weiterleitung an die tatsächliche Tabelle auf dem IDAA. Der DB2 Analytics Accelerator beschleunigt normalerweise SQL-Queries, die vom DB2 Optimizer an den Accelerator weitergeleitet werden. Für analytische Aufgaben wie eine Modellerstellung müssen die entsprechenden mathematischen Funktionen auch auf dem Accelerator implementiert werden. Für die Machbarkeitsstudie kann dabei auf viele bereits implementierte Modelle zurückgegriffen werden, die für eine andere Nutzung mit SPSS Modeler ge- 34

40 3.2 Machbarkeitsstudie Modellierung auf IDAA SPSS Modeler Client: Stream mit Nodes CLEF-Erweiterung Server: Generierung SQL DB2 Aufruf der Stored Procedure API: Weiterreichen von Befehl und Parameter DB2 Analytics Accelerator Aufruf der INZA Stored Procedure SMP Host: Aufteilung Berechnung S-Blade S-Blade S-Blade... Abbildung 3.3: Zusammenarbeit von SPSS Modeler, dem DB2 Analytics Accelerator und den prototypischen Erweiterungen, um INZA-Befehle auszuführen. 35

41 3.3 Industrie-Blueprints als Anwendungsfall dacht sind [sps11b]. Diese und weitere Funktionen sind im Rahmen des INZA- Paketes vorhanden, wodurch viele Modelle wie Entscheidungs- und Regressionsbäume, Assoziationsanalysen, Cluster-Algorithmen oder Bayessches Netz schon verfügbar sind. Einige Algorithmen fehlen allerdings momentan noch, so gibt es zum Beispiel noch keine Möglichkeit, ein Neuronales Netz aufzubauen. 3.3 Industrie-Blueprints als Anwendungsfall Um Aussagen über die Machbarkeit des Ansatzes mit IDAA zur Modellberechnung treffen zu können, werden nachfolgend Szenarien beschreiben, wie sie auch in der Wirtschaft zum Einsatz kommen. Die Grundlage für diese Szenarien bilden IBM Industry Models wie das IBM Retail Data Warehouse General Information Manual oder das IBM Telecommunications Data Warehouse General Information Manual, aus welchen praxisnahe Blueprints zur Umsetzung von Geschäftsprozessen entstanden sind [IBM09, IBM11]. Aus diesem Grund wird der IBM SPSS Retail Promotions Blueprint im Abschnitt beschrieben. Erklärt werden dann die stattfindenden Schritte im Rahmen der Datenvorbereitung und der Modellberechnung, wobei dafür ein Entscheidungsbaum aus SPSS Modeler genutzt wird. Im darauffolgenden Abschnitt wird der Blueprint Profitability and Customer Retention for Telecommunications verwendet, um eine Assoziationsanalyse inklusive Datenvorbereitung abzubilden. In beiden Fällen werden dabei IBM-interne Dokumentationen verwendet. Außerdem wird der jeweils ursprüngliche Blueprint aufgrund der Komplexität nur in Teilen umgesetzt, um die gewählten Algorithmen isoliert und detailliert zu beschreiben Retail Prediction Promotions Blueprint Eine typische Anwendung im Einzelhandel kann es sein, dass mit Hilfe von Kundendaten Vorhersagen zum künftigen Kaufverhalten der Kunden getätigt werden sollen. Diese Vorhersage wird von einem vorher erstellten mathematischen Modell auf der Grundlage von bisher gesammelten Kundendaten getroffen und kann zur weiteren Nutzung für neue Datensätze vorgehalten werden. Dem Ergebnis entsprechend angepasst wird dem Käufer über das potentiell richtige Medium - etwa Post, oder direkt im Shop - die Werbebotschaft mitgeteilt. Je nach Erfolg oder Mißerfolg kann das Modell dann an neue Parameter angepasst und somit verbessert werden. Der ursprüngliche Blueprint Retail Prediction Promotions beinhaltet drei Szenarien, von welchem im Folgenden allein auf Direct Mail Promotions eingegangen wird. 36

42 3.3 Industrie-Blueprints als Anwendungsfall Online Promotions oder Warenkorbanalyse. Kunden befinden sich in einem Online-Shop eines Unternehmens, dabei sollen entsprechend ihres Verhaltens interessante Angebote angezeigt werden. Store Promotions Durch Verkaufszahlen nach Aktionen im Geschäft werden vorhergesagte und realisierte Werte verglichen, worüber künftige Aktionen besser geplant werden können. Direct Mail Promotions Auf Grund der erstellten Profile und dem Verhalten von Kunden wird über mathematische Modelle berechnet, ob verschiedene Werbeträger beim Konsumenten eine Reaktion wie etwa Kauf eines Produktes hervorrufen. Dementsprechend kann die Zustellung von Werbung auf dem potentiell richtigen Medium ausgeliefert werden. Durch die Begrenzung auf das Szenario Direct Mail Promotions wird die Komplexität des Problems reduziert, jedoch wird dadurch eine Konzentration auf ausgewählte Elemente erreicht, welche dann detailliert untersucht werden. Im Beispiel geht es speziell um das Modell Entscheidungsbaum sowie allgemeine Datenbankoperationen wie Merge, Filter, Distinct und Aggregate. In Abbildung 3.4 ist der Stream zu sehen, der zum einen Daten für die weitere Verwendung vorbereitet und zum anderen das Modell berechnet, mit dem dann weitergearbeitet werden kann. Die ersten beiden Schritte zeigen einen Teil der Datenvorbereitung. Zu Beginn werden dabei die zwei Tabellen CST_TRANSAC- TION_SAMPLE und TRANSACTION_LOG als Datengrundlage eingebunden, die neben zwei später verwendeten Tabellen in Abbildung 3.5 gezeigt werden. Die beiden Tabellen werden dann sogleich mit einen Inner Join (Merge) über die Warenkorb-Transaktions-ID MKT_BSKT_TXN_ID zusammengeführt werden. Der erste Knoten im zweiten Schritt, RFM and Sales potential, kennzeichnet einen Supernode, unter welchem verschiedene im nächsten Absatz erklärte Operationen ausgeführt werden. Anschließende erfolgt eine erneute Zusammenführung der Daten per Inner Join über die CUST_ID, diesmal mit historischen Informationen über das Antwortverhalten der verschiedenen Kommunikationskanäle aus der Tabelle CST_CHANNEL_RESPONSE. Im übernächsten Absatz wird als dritter Schritt der Supernode Calculate Channel Propensity beschrieben, welcher für die Berechnung der Modelle verantwortlich ist. Im vierten Schritt werden die durch die Modellberechnung gewonnenen Daten mit der Tabelle CST_DEMOGRAPHY zusammengeführt, in welcher Informationen zur Reaktion von Kunden auf Werbekampagnen abgelegt sind. Abschließend werden die verarbeiteten Informationen in die Tabelle CST_RFM_CHANNEL_- PROPENSITY_DM_DATA geschrieben. Diese und eine weitere Ausgabetabelle sind in Abbildung 3.6 veranschaulicht. Zusammenfassend kann festgestellt werden, dass der Stream Modelle bereitstellt, mit denen neue Kunden möglichst schnell auf dem für sie passenden Kommunikationsmittel angesprochen werden können. 37

43 3.3 Industrie-Blueprints als Anwendungsfall Abbildung 3.4: Dieser Stream aus dem Retail Blueprint zeigt die komplette Vorverarbeitung von Daten und der darauf folgenden Modellberechnung unter dem Supernode Calculate Channel Propensity. Diese berechneten Modelle können dann zum Scoring von neuen Daten herangezogen werden. Die letzten Schritte im Stream schreiben neu gewonnene Informationen in Tabellen, die dann etwa als Eingabe für andere Streams oder zur Auswertung der Ergebnisse verwendet werden können. 38

44 3.3 Industrie-Blueprints als Anwendungsfall Abbildung 3.5: Input-Tabellen im gewählten Szenario des Retail Prediction Blueprints: Zuerst verwendet werden die beiden Tabellen CST_- TRANSACTION_SAMPLE und TRANSACTION_LOG, gefolgt von der Tabelle CST_CHANNEL_RESPONSE nach einigen Operationen. Einige Schritte später folgt als letzte Input-Tabelle CST_DEMOGRAPHY. 39

45 3.3 Industrie-Blueprints als Anwendungsfall Abbildung 3.6: Output-Tabellen beim Retail Blueprint: Direkt nach der Modellberechnung werden die Ergebnisse in der Tabelle CST_CHANNEL_- RESPONSE_PROPENSITY gespeichert. Es folgt eine Verknüpfung mit weiteren Daten, um die Daten abschließend in die Tabelle CST_RFM_- CHANNEL_PROPENSITY_DM_DATA zu schreiben. 40

46 3.3 Industrie-Blueprints als Anwendungsfall Supernode RFM and Sales potential Der erste Supernode, zu sehen in Abbildung 3.7, berechnet für jeden Kunden den RFM-Score, der sich aus drei Teilen zusammensetzt. R steht für Recency und gibt an, wann der Kunde das letzte Mal einen Einkauf getätigt hat, F steht für Frequency und sagt, wie regelmäßig der Kunde zu Besuch ist und M schließlich bedeutet Monetary Value und verdeutlicht, wie viel Geld der Kunde im Durchschnitt ausgibt. Für jede Kategorie aus R, F und M werden dann entsprechend der vorhandenen Einzelwerte ähnlich wie für Schulnoten diskrete Bereiche gefunden, mit denen eine Einteilung stattfinden kann, zum Beispiel 1-5 für niedrige bis hohe Bereiche für den durchschnittlichen Betrag beim Einkauf. Zudem kann den einzelnen Kategorien ein Gewicht zugeteilt werden, um etwa regelmäßig Einkäufe mehr zu belohnen als einmalige teure Anschaffungen. [MH07] Abbildung 3.7: Supernode RFM and Sales Potential: Zu Beginn findet die eigentliche RFM-Analyse statt, im Nachhinein werden Kunden ab einem bestimmten RFM-Wert als loyal bezeichnet und zudem werden die Gesamt-Kaufbeträge in den Aggregate-Knoten aufaddiert. In der Datenvorbereitung werden die Eingabewerte für die RFM-Analyse im Stream fehlerhaft aufbereitet. Eine einfache Lösung wäre an dieser Stelle, einen RFM-Aggregatknoten vorzuschalten, der die Daten für die RFM-Analyse passend aufbereitet. Im folgenden wird erläutert, warum Änderungen stattfinden müssen und zudem wie die Anpassungen für diesen konkreten Fall aussehen. 41

47 3.3 Industrie-Blueprints als Anwendungsfall Die Eingabedaten bestehen aus Transaktionen, die über eine ID (MKT_BSKT_- TXN_ID) gekennzeichnet werden. Jede Transaktion beinhaltet mehrere Tupel (Produkte, die ein Kunde in dieser Transaktion kauft), die einer Transaktion zugeordnet sind. Für diese Tupel sind jeweils die Eingabewerte TXN_BOOK_- DT (für Recency), CUST_ID (für Frequency) und TOT_SALE_AMT (für Monetary Value) verzeichnet. Jedes dieser Tupel wird fälschlicherweise in der Eingabe verwendet, wodurch sich die Ergebnisse in die Richtung der RFM-Scores von Transaktionen mit vielen gekauften Produkten verschiebt. Für eine vergleichende Analyse ist dies nicht relevant, da bei einem Vergleich mit den gleichen Eingabedaten in beiden Szenarien auch die gleiche Verschiebung stattfindet. [sps12e] Für eine reale Berechnung auf Kundendaten sollten die Eingabedaten vorher über einen Distinct auf der Transaktions-ID angepasst werden, womit die für eine RFM-Analyse uninteressanten einzelnen Produkte aussortiert werden. Dem folgend wird ein RFM-Aggregatknoten vor die RFM-Analyse geschaltet, welcher die Daten korrekt vorbereitet. In Abbildung 3.8 wird dieser Knoten verdeutlicht, auf die drei Eingabefelder ID, Date und Value wird im folgenden eingegangen. Die CUST_ID wird dabei als eindeutige ID für die Berechnung der Grenzen von Recency, Frequency und Monetary Value verwendet, da für jeden Kunden nur je ein Wert berechnet werden soll. Als Date wird dann wie in der Abbildung des RFM-Aggregatknotens zu sehen TXN_BOOK_DT verwendet, um den Abstand vom letzten Einkauf des Kundens bis zum heutigen Tag zu berechnen. Bisher wurde für jede Transaktion das Datum aus TXN_BOOK_DT erneut in die Berechnung der Recency aufgenommen, was falsch ist, da an dieser Stelle nur der zuletzt durchgeführte Kauf wichtig ist. Über den RFM-Aggregatknoten wird somit der korrekte Recency-Wert eines jeden Kunden in der passenden Spalte Recency übertragen. Bisher wird die CUST_ID direkt als Eingabe für Frequency verwendet, womit der Wert der Kundennummern gleichgesetzt wird mit der Anzahl der Einkäufe, was erneut nicht korrekt ist. Dementsprechend verteilten sich zudem die Bereiche der Frequency auf die vorhandenen Kundennummern, so etwa auf die Werte Der Widerspruch wird an dieser Stelle spätestens deutlich, da jede verzeichnete Transaktion mindestens einem Einkauf entspricht, die Anzahl der Einkäufe also nicht 0 sein kann. Im RFM- Aggregatknoten wird demzufolge über das Vorkommen der CUST_ID die korrekte Anzahl der Einkäufe bestimmt und als neue Spalte Frequency bereitgestellt. Der dritte Wert Value im RFM-Aggregatknoten bereitet den Wert Monetary Value vor, indem er den Kaufbetrag einer einzelnen Transaktion TOT_- SALE_AMT zugewiesen bekommt. Die einzelnen Kaufbeträge führen dann in Verbindung mit der CUST_ID zur Berechnung des durchschnittlichen Kaufbetrag eines jeden Kunden, was in der neuen Spalte Monetary gespeichert wird. 42

48 3.3 Industrie-Blueprints als Anwendungsfall Abbildung 3.8: Parameter für den RFM-Aggregatknoten 43

49 3.3 Industrie-Blueprints als Anwendungsfall Die neuen Spalten Recency, Frequency und Monetary werden dann als Eingabewerte für die eigentliche RFM-Analyse verwendet, wie in Abbildung 3.9 verwendet, womit eine Einordnung aller Kunden in die jeweils passenden Kategorien stattfindet. Danach wird mit W als Wert der Kategorie und G als Gewicht der RFM Score für jeden Kunden wie folgt berechnet. Abbildung 3.9: Parameter für den Knoten RFM-Analyse RF M = W Recency G Recency + W Frequency G Frequency + W Monetary G Monetary (3.1) = (3.2) = 352 (3.3) Mit diesem RFM-Wert können die Klienten verschiedene Klassen eingeteilt werden, etwa um Kunden mit hohem RFM-Wert mehr Rabatt anzubieten als denen mit geringeren Werten. Im Stream folgt ein Typoperator, der zwei Datentypen leicht ändert: NBR_ITM und OU_IP_ID wechseln von Real zu Integer. Es folgt eine Zweiteilung des Streams. Zum einen findet sich ein Ableitungsknoten Loyal, hier wird eine neue Tabellenspalte angelegt in der ein Kunde als treu eingestuft wird, wenn die RFM-Analyse einen bestimmten festgesetzten Wert überschreitet. Zum anderen werden über zwei Aggregierungsknoten die Felder 44

50 3.3 Industrie-Blueprints als Anwendungsfall TOT_SALE_AMT und TOT_SALE_AMT_Mean mit den entsprechend aufsummierten Einzelwerten angelegt. Dabei kann angemerkt werden, dass die Aggregierung etwa für TOT_SALE_AMT ohne Nutzen ist, da der Durchschnitt von x gleichen Werten wieder x entspricht. Der zudem in diesem Schritt eingefügte Record_Count gibt die Anzahl der Produkte pro Transaktion an und wird im nächsten Aggregate-Knoten durch die Gesamtzahl der gekauften Produkte pro Kunde überschrieben. Letztlich erfolgt eine Zusammenführung der Teil- Streams und ein Distinct über die CUST_ID, wonach die Daten zum Haupt- Stream zurückgegeben werden. Supernode Calculate Channel Propensity In diesem Supernode, welcher in Abbildung 3.10 zu sehen ist, findet die tatsächliche Modellierung nach dem vorgegebenen Modell CHAID statt. Zu Beginn wird in je einem Typknoten pro Modell das Ziel der Berechnung angegeben, zum Beispiel das Feld SMS_RE- SPONSE für das gleichnamige Modell. Infolgedessen stoßen die vier blauen CHAID Knoten mit den bisher bekannten Daten - den Trainingsdaten - die Generierung des jeweiligen Modells an. Im Stream wird das berechnete Modell je durch ein CHAID Modell-Nugget angezeigt. Das erstellte Modell-Nugget kann dann in jedem beliebigen Stream zum Scoring verwendet werden. Nach der Modellberechnung werden für drei der vier Teilstreams die doppelten Attribute herausgefiltert, die nur für die Berechnung benötigt wurden. Im letzten Abschnitt vom Supernode wird ein Merge - wieder als Inner Join - in eine gemeinsame Tabelle durchgeführt und danach zum einen in die Tabelle CST_- CHANNEL_RESPONSE geschrieben und zum anderen an den Haupt-Stream zurückgegeben. [sps12b] Profitability and Customer Retention for Telecommunications Blueprint Mit dem zweiten Blueprint wird ein Szenario aus der Telekommunikationsbranche beschrieben, welches sich mit dem Thema Gewinnmaximierung und Kundenbindung beschäftigt. Ein Mittel dafür kann es sein, mit Hilfe von Call Centern Kunden anzurufen, welche in bestimmte Verhaltensmuster fallen. Weiterhin kann es nützlich sein, Kunden mit großem Umsatz über spezielle Aktionen einen hohen Anreiz zu geben, dem Unternehmen treu zu bleiben. Auf diese Art und Weise können weitere Prozesse gefunden werden, die unter Zuhilfenahme von gespeicherten Kundendaten eine wichtige Grundlage zur Optimierung ausmachen. Im Umfang des Blueprints finden sich verschiedene Analyseprozesse, welche Themen wie Kundenabwanderung im Prepaidund Postpaid-Bereich, den Kundenwert, die Zufriedenheit und Zusammenhänge bei den verwendeten Tarif-Optionen umfassen. Über die Verwendung 45

51 3.3 Industrie-Blueprints als Anwendungsfall Abbildung 3.10: Supernode Calculate Channel Propensity: Modellberechnung in den CHAID-Knoten pro Kommunikationskanal. Berechnetes goldenes Nugget erstellt dann mit den Eingabedaten die Werte pro Kunde. 46

52 3.3 Industrie-Blueprints als Anwendungsfall von Entscheidungsbaum-, Regressionsmodellen oder der Assoziationsanalyse werden mit Hilfe der gespeicherten Informationen über einzelne Kunden neue Erkenntnisse gewonnen werden, die dann etwa für gezieltes Marketing eingesetzt werden. Im folgenden werden die Zusammenhänge für Tarif-Optionen im Prepaid-Bereich mit einer Assoziationsanalyse beschrieben und weiter untersucht. Wenn Brot und Butter eingekauft wird, besteht eine 90% Chance, dass auch Milch gekauft wird. Diese Aussage stammt aus einer Arbeit von Agrawal et al. [AIS93] aus dem Jahr 1994, in welcher erstmals das Finden von Assoziationsregeln in großen Datenmengen beschrieben wird. Analog dazu könnte eine Aussage im Telekommunikationsbereich heißen: Wer eine Daten- und SMS- Option gebucht hat, nutzt zu 90% auch eine Auslands-Option. Die 90% geben dabei an, in wie vielen Fällen die Wahl von Daten- und SMS-Option auch zur Entscheidung für die Auslands-Option führt. Die Regelsätze werden über die Analyse der vergangenen Transaktionen gefunden, im hier untersuchten Beispiel werden dafür die Buchungen der gewählten Tarifoptionen aller Kunden auf mögliche Assoziationen untersucht. [AIS93] Abbildung 3.11: Stream zur Umsetzung einer Assoziationsanalyse auf Grundlage von kundenbezogenen Tarif-Optionen im Telekommunikationsbereich: Die obere Zeile zeigt die Datenvorbereitung, um in der unteren Zeile das Modell zu berechnen und dieses abschließend auf Kundendaten zu nutzen. Zu diesem Zweck wird der in Abbildung 3.11 gezeigte SPSS Modeler Stream verwendet. Der Schritt der Datenvorbereitung fällt dabei mit drei Nodes kurz aus, da die benötigten Tarif-Optionen der Kunden wie SMS PACKAGE oder ADVANCED DATA PACKAGE sowie die Kundennummer in der Tabelle CST_- 47

53 3.3 Industrie-Blueprints als Anwendungsfall PRODUCTS vorliegen. Diese Tabelle sowie die einzige Ausgabetabelle sind in Abbildung 3.12 zu sehen. Der zweite Node benennt einige Attribute um und übergibt die Daten an den Type -Knoten, der die Rollen für die Modellberechnung festlegt. Außerdem legt dieser Knoten für jede Tarif-Option die den Wertebereich als Flag fest, wodurch nur die Boolschen Werte Y oder N verwendet werden. Dem folgt die Erstellung des Modells im blauen Node Association Model und gleich danach die Anwendung des errechneten Modell- Nugget auf die Testdaten. Die automatisch generierten Spaltennamen werden im nachkommenden Node umbenannt, weil sie sonst zu lang für DB2 sind. Abschließend werden diese Ergebnisse in eine neue Tabelle PREPAID_RESPONSE geschrieben, womit die Aufgabe des Streams erfüllt ist. Abbildung 3.12: Ein- und Ausgabetabelle im Telekommunikations-Szenario: In CST_PRODUCTS sind die interessanten Tarif-Optionen abgelegt. Die Ergebnistabelle PREPAID_RESPONSE zeigt zusätzlich zu den gewählten Optionen die mit der Modellberechnung gewonnenen Attribute beginnend mit $. 48

54 4 Umsetzung In den Grundlagen im Kapitel 2 wurden Technologien wie SPSS Modeler und der IBM DB2 Analytics Accelerator eingeführt, aufbauend darauf erfolgte im Kapitel 3 eine Einschätzung des Ansatzes, die Modellierung auf SPSS Modeler durch IDAA zu beschleunigen sowie eine Vorstellung von praxisnahen Szenarien aus industrierelevanten Dienstleistungsprozessen. Dieses Vorwissen wird in diesem Kapitel verknüpft, um die gewählten Szenarien aus Einzelhandel und Telekommunikation zum einen auf z/os DB2 abzubilden und zum anderen auf den DB2 Analytics Accelerator. Bei der Abbildung auf DB2 für z/os, welche in Abschnitt 4.1 beschrieben wird, wird zudem auf einige aufgetretene Probleme und deren Lösung eingegangen. Wenn die Daten auf z/os DB2 verfügbar sind, können die Streams unter SPSS Modeler ausgeführt werden. Die weitere Integration der Daten mit dem DB2 Analytics Accelerator wird im Abschnitt 4.2 dargestellt, das Augenmerk richtet sich dann aber vor allem auf die Herausforderung, Algorithmen und Modelle wie die Assoziationsanalyse über Netezza-Algorithmen direkt auf dem Accelerator abzubilden. Damit wird eine Basis für einen Performance-Test sowie weitere Arbeiten geschaffen. So gibt es etwa einige Möglichkeiten zur Optimierung mit dem neuen Ansatz auf IDAA, ein Beispiel für eine schnellere Modellerstellung wird am Ende des Kapitels im Abschnitt 4.3 beschrieben. 4.1 Abbildung auf DB2 für z/os Die verwendeten Blueprints setzen als Datenbankanbindung im SPSS Modeler auf DB2 für Linux, UNIX und Windows, was sich an vielen Stellen von DB2 auf z/os unterscheidet. Aus diesem Grund wird in diesem Abschnitt beschrieben, wie die in Abschnitt 3.3 erläuterten Szenarien auf einem z/os-system mit DB2 lauffähig gemacht werden. Dabei wird der Abschnitt entsprechend der unterschiedlichen Aufgaben in drei Bereiche aufgeteilt. Da aufgrund der Komplexität der Blueprints nur Ausschnitte aus diesen verwendet werden, erfolgt im ersten Abschnitt eine Beschreibung, wie die benötigten Daten aus den Blueprints extrahiert werden und welche Probleme dabei aufgetreten sind. Die nächste Aufgabe beinhaltet die Vergrößerung der extrahierten Daten, beschrieben im Abschnitt Dies wird als Vorbereitung auf den vergleichenden Performance-Test durchgeführt. Abschließend werden die vorbereiteten 49

55 4.1 Abbildung auf DB2 für z/os Datensätze mit JCL-Skripten auf das DB2 transferiert, was in zusammengefasst wird Extraktion der verwendeten Daten Im verwendeten Szenario Direct Mail Promotions aus dem Retail Prediction Promotions Blueprint werden vier Tabellen zur Gewinnung der Eingabedaten für die Modellberechnung sowie zwei weitere Tabellen für die Ergebnisse benötigt. Alle Tabellen ergeben sich direkt aus dem SPSS Modeler Stream, der zu dem Szenario gehört und im Abschnitt beschrieben wird. Für die weitere Verwendung stehen die Tabellen als Dateien mit kommaseparierten Werten in den Anlagen des Blueprints zur Verfügung. Eine wichtige Änderung ist in der Tabelle TRANSACTION_LOG nötig, das Feld TXN_BOOK_DT hat anfangs das Format YYYYMMDD, DB2 benötigt Datumsangaben allerdings im Format YYYY-MM-DD. Mit dem Unix-Tool sed kann die Anpassung in einem Arbeitsschritt beispielsweise über das folgende Kommando geschehen (eine Zeile): sed -e s:\(200[2-4]\)\([0-1][0-9]\)\([0-3][0-9]\):\1-\2-\3:g TRANSACTION_LOG > output Das Szenario aus dem Bereich Telekommunikation setzt beim Import der Daten in den SPSS Modeler mit einer Enterprise View auf eine Abstraktionsschicht, daher müssen die Quellen zur Umsetzung manuell im verwendeten SPSS Modeler Stream ermittelt werden. Dabei fällt auf, das viele Tabellenspalten im ursprünglichen Anwendungsfall wie etwa MARITAL STATUS oder auch NUMBER OF CHILDREN nicht verwendet werden, daher werden diese für die weiteren Messungen aussortiert, womit eine Konzentration auf die Assoziationsanalyse erfolgt. Über zwei Eingabetabellen kann der Zugriff auf die relevanten Information erfolgen, etwa welche Tarif-Optionen ein Kunde gewählt hat und zudem, ob er Prepaid- oder Postpaid-Kunde ist. Ergänzt durch eine Ausgabetabelle sind in diesem Szenario drei Tabellen erfordert. Anders als bei dem Retail Blueprint sind in diesem Anwendungsfall keine weiteren Anpassungen der Daten nötig Vergrößerung der Datengrundlage Die durch den Blueprint bereitgestellte Datenbasis ist oft zu klein, um damit eine praxisnahe Überprüfung der Performance durchzuführen. Die verwendeten Daten im Retail Blueprint sind beispielsweise etwa 15 Megabyte 50

56 4.1 Abbildung auf DB2 für z/os groß, die im Telekommunikations-Blueprint sogar nur knapp über 600 Kilobyte. Um zudem die durch den DB2 Analytics Accelerator gegebene parallele Architektur gut nutzen zu können, muss der Umfang der Datengrundlage stark vergrößert werden, um eine sinnvolle Performance-Analyse durchführen zu können. Ein dafür geschriebenes kleines Java-Tool besteht aus zwei Klassen, die in Abbildung 4.1 für das Retail-Szenario zu sehen sind. In der Klasse MorePredictionData werden Startparameter wie multiplier und maxrecordcount eingelesen, daraufhin werden die Quelldateien mit den CSV-Datensätzen eingelesen und über Methoden aus der Klasse DataWriter vervielfältigt. Dabei werden die Primärschlüssel der Tabellen so angepasst, dass deren referentielle Integrität gewahrt bleibt. Bei dem Szenario aus dem Abbildung 4.1: Klassendiagramm für Programm zur Vervielfältigung, MorePredictionData stellt einen allgemeinen Rahmen dar und ruft pro Quelldatei die benötigten Methoden aus der instanziierten Klasse DataWriter auf, die zur Vervielfältigung benötigt werden. (Verwendete Software: IBM Rational Software Architect) Retail Blueprint wird dabei in den Tabellen CST_DEMOGRAPHY und CST_- CHANNEL_RESPONSE die CUST_ID angepasst, zudem in TRANSACTION_LOG die MKT_BSKT_TXN_ID und in der Tabelle CST_TRANSACTION_SAMPLE werden beide IDs angeglichen. Wenn die Anzahl der Zeilen in der Zieldatei zu groß wird, werden automatisch durchnummerierte neue Dateien erstellt. Über Startparameter kann angegeben werden, um welchen Faktor die Datenbasis vergrößert werden soll und wie viele Zeilen pro angelegter Datei nicht überschritten 51

57 4.1 Abbildung auf DB2 für z/os werden dürfen. Nach erfolgreicher Vervielfältigung der Ausgangsdaten können die Daten auf das DB2 importiert werden Import auf DB2 für z/os Um die Daten auf das DB2 für z/os importieren zu können, müssen verschiedene vorbereitende Schritte auf dem Mainframe durchgeführt werden, die nachfolgend aufgezählt und dann detailliert erklärt werden. Anlegen von benötigten Datasets Upload der Datenbasis per FTP auf den Mainframe Datenbankobjekte anlegen Laden der CSV-Dateien in die Datenbank Die meisten Teilschritte benötigen Zugriff auf das ISPF-Subsystem (Interactive System Productivity Facility) des verwendeten Mainframes, in dieser Arbeit wird dafür der 3270-Client von IBM (Personal Communications) verwendet. Ein Screenshot vom ISPF ist in Abbildung 4.2 zu sehen, dieser zeigt die Standardansicht nach der Anmeldung. Dabei sind alle verfügbaren Subsysteme zeilenweise aufgelistet und können über die weißen Anfangsbuchstaben gestartet werden. Für die weiteren Arbeiten werden drei Systeme benötigt, die nachkommend kurz beschschrieben werden. PDF ISPF/Program Development Facility, etwa zum Anlegen und Bearbeiten von Datasets, zudem aber auch zum Submit von JCL-Skripts. SDSF System Display and Search Facility zur Prüfung, ob Jobs beendet worden sind oder nicht und zudem, um in den angelegten Logs nach Fehlern beim Ausführen von Skripten zu suchen. DB2 Zugriff auf das DB2-Subsystem für administrative Aufgaben wie Änderung von Rechten, dem direkten Ausführen von SQL Statements oder zur Prüfung, ob Tabellen und deren Inhalten angelegt worden sind. Der erste Teilschritt betrifft das Anlegen von Datasets auf z/os, was über das PDF-Subsystem durchgeführt werden kann. In diesem Fall wurden die Datasets NENTWIG.DATA und NENTWIG.JCL.LOAD angelegt, zum einen für die vorbereiteten CSV-Dateien und zum anderen für die benötigten JCL-Skripte zum Erstellen und Laden der Tabellen. Im nächsten Abschnitt können dann die Daten vom Quellrechner per FTP-Verbindung auf den Mainframe gespielt werden, als Übertragsungsart muss dabei ASCII verwendet werden, was allerdings oft die Voreinstellung ist. In jedem Fall werden die CSV-Dateien per FTP übertragen, aber auch die JCL-Skripte können so auf einem beliebigen Rechner geschrieben werden. Dies bringt den Vorteil mit sich, das der in ISPF integrierte Texteditor mitsamt seiner gewöhnungsbedürftigen Bedienung nur zum Absenden der Skripte verwendet werden muss. Der dritte Schritt beschäftigt sich mit 52

58 4.1 Abbildung auf DB2 für z/os Abbildung 4.2: z/os ISPF-Subsystem Ansicht beim Start, weiterführende Subsysteme wie PDF, DB2 oder CICS können über den Aufruf der weißen Kürzel zu Beginn einer Zeile gestartet werden. 53

59 4.1 Abbildung auf DB2 für z/os dem Anlegen der benötigten Datenbankobjekte auf DB2 für z/os, die wichtigste Voraussetzung dafür sind die benötigten Rechte, um auf eine Storage Group zugreifen zu können oder um diese zu erstellen. Weiterhin braucht der Benutzer Rechte für das Anlegen von Datenbanken und Tablespaces auf dem entsprechenden System. Im DB2-Subsystem selbst können Rechte über Execute SQL Statements Grant/revoke privileges on objects geändert werden. Sind die Rechte geklärt, können kleinere SQL Statements direkt über Run or Explain SQL statements ausgeführt werden, wie hier beispielhaft für Storage Group, Database und einen Tablespace für den Retail Blueprint: CREATE STOGROUP SGRETAIL VOLUMES("*") VCAT DBNI; COMMIT; CREATE DATABASE RETAIL BUFFERPOOL BP2 INDEXBP BP1 STOGROUP SGRETAIL CCSID UNICODE; COMMIT; CREATE TABLESPACE TSTRANLO IN RETAIL USING STOGROUP SGRETAIL CCSID UNICODE COMPRESS YES; COMMIT; Damit sind alle Voraussetzungen zum Anlegen der benötigten Tabellen erfüllt und der nächste Schritt kann begonnen werden. An dieser Stelle werden JCL- Skripte (Job Control Language) verwendet, um Aufgaben über das JES (Job Entry Subsystem) an z/os zu delegieren. Dort wird die geforderte Aufgabe ausgeführt, wonach das JES erneut genutzt wird, um Ausgabeinformationen für den Nutzer aufzubereiten. Jede Aufgabe wird über ein JOB-Statement benannt und kann verschiedene EXEC-Statements besitzen, die Programme ausführen. Über DD-Statements werden zudem Ein- und Ausgabedaten spezifiziert. Normalerweise beginnen alle JCL-Statements mit //, eine detaillierte Übersicht zur Verwendung von JCL ist im entsprechenden User s Guide [zos01] zu finden. Um eine der benötigten Tabellen zu erstellen, wird folgendes JCL-Skript verwendet: //NENTWIGC JOB Add io table,msgclass=h, 54

60 4.1 Abbildung auf DB2 für z/os // CLASS=S,NOTIFY=NENTWIG,TIME=1440 //JOBLIB DD DSN=SYS1.DSN.V910.SDSNLOAD,DISP=SHR // DD DSN=SYS1.DSN.SNI1.SDSNEXIT,DISP=SHR //STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DBNI) RUN PROGRAM(DSNTEP2) PLAN(DSNTEP91) END //SYSIN DD * CREATE TABLE NENTWIG.TRANSACTION_LOG ( MKT_BSKT_TXN_ID INT, POS_TML_ID FLOAT, TXN_STRT_TMS VARCHAR(40), TXN_BOOK_DT DATE ) IN RETAIL.TSTRANLO CCSID UNICODE; Interessant ist hier zum Beispiel der Schritt STEP01, in welchem das Mainframe-Utility IKJEFT01 ausgeführt wird, welches die Ausführung von TSO-Befehlen (Time Sharing Option) im Batch Mode gestattet. Bei der Bedienung von z/os wird normalerweise ISPF verwendet, welches über Dialoge und Menüeinträge komfortabler zu bedienen ist als die TSO-Umgebung, bei der Befehle über eine Kommandozeile abgegeben werden. Im obigen Falle wird durch den Start von IKJEFT01 die Ausführung des Programms DSNTEP2 ermöglicht. DSNTEP2 wiederum ist ein DB2-Utility, mit welchem dynamische SQL Statements ausgeführt werden können. Das Skript wird im Texteditor im ISPF über sub (Submit) abgeschickt und verarbeitet. In diesem Falle wird die Tabelle NENTWIG.TRANSACTION_LOG mit den gegebenen Parametern angelegt und die Vorbereitungen sind abgeschlossen. [db210] Der abschließende Schritt importiert dann die auf bereits auf z/os gehaltenen Daten in die erstellten Tabellen, wofür erneut ein JCL-Skript verwendet wird, welches nach diesem Abschnitt abgebildet ist. Um die Übersichtlichkeit zu erhöhen, erfolgt eine Beschränkung auf die wichtigsten Zeilen des Skriptes, so etwa wird auf den Beginnn verzichtet, der im letzten Skript sehr ähnlich ist. Das EXEC-Statement in diesem Skript führt das DSNUTILB-Utility aus, mit welchem es ermöglicht wird, DB2-Utilities zu starten - in diesem Falle LOAD zum Befüllen von Tabellen. Die mit DATA beginnende Zeile gibt an, welches Dataset als Eingabe verwendet werden soll. Bei der Ausführung des LOAD-Utilities werden einige Parameter übergeben, so etwa REPLACE, welches den Inhalt im 55

61 4.1 Abbildung auf DB2 für z/os Tablespace vor dem Laden der neuen Daten komplett löscht oder ENFORCE NO, womit beim Laden der Daten keine Prüfung auf referentielle Integrität erfolgt. [db210] [...] //LOAD EXEC PGM=DSNUTILB,PARM=DBNI [...] //DATA DD DSN=NENTWIG.DATA.TRANLOGD,DISP=SHR LOAD DATA INDDN DATA REPLACE LOG NO ENFORCE NO FORMAT DELIMITED INTO TABLE NENTWIG.TRANSACTION_LOG ( MKT_BSKT_TXN_ID INT, POS_TML_ID FLOAT, TXN_STRT_TMS VARCHAR(40), TXN_BOOK_DT DATE ) Wenn alle Tabellen erstellt und geladen sind, kann der entsprechende Stream in SPSS Modeler ausgeführt werden. Außerdem ist damit die Grundlage für den Offload auf den DB2 Analytics Accelerator geschaffen, die im folgenden Abschnitt 4.2 beschrieben wird. Bei der Durchführung dieser Teilschritte sind einige Fehler aufgetreten. Die Ursachen dafür können im Nachhinein unter Umständen als trivial erscheinen, sind aber teilweise der Portierung der Blueprints von DB2 für Linux, UNIX und Windows auf DB2 für z/os geschuldet. Ein Beispiel dafür ist, dass die SQL Statements im Datenbankschema nicht die wichtige Großschreibung aller Schlüsselwörter beachten, in DB2 führt die Kleinschreibung allerdings dazu, dass die entsprechenden Tabellen nicht erstellt werden. Bei den Datentypen muss vor allem beachtet werden, dass in DB2 auf z/os kein DOUBLE, sondern FLOAT oder DECIMAL verwendet wird. Eine weitere Fehlerquelle wurde bereits im Abschnitt beschrieben. DB2 für z/os akzeptiert als Datumsformat nur YYYYMMDD, hier ist DB2 für Linux, UNIX und Windows flexibler. In dem Skript, in dem die Daten in die Tabellen geladen werden, müssen zudem unbedingt alle Attribute der Tabelle erneut angegeben werden, ansonsten schlägt das Laden fehl. Jede Tabelle benötigt zudem ihren eigenen Tablespace, was nach vielen Variationen bei der Wahl der Parameter im LOAD-Prozess festgestellt wurde. Mit dieser Anpassung sind weiterhin folgende Fehler weggefallen: 56

62 4.2 Integration in IDAA Verschiedene Unicode Fehler wie etwa CHAR CONVERSION FROM CCSID to 1208 FAILED. Dabei habe die Feststellung gemacht werden, dass beim Laden von Daten in Unicode-Tabellen ohne Angabe von Encoding-Parametern eine Konvertierung nach Unicode stattfindet [db212]. Tablespace im Status Recovery Pending und damit kein Zugriff auf die Daten möglich, dies ist beispielsweise bei mehreren LOAD nacheinander auf dem gleichen Tablespace, aber auch bei Unicode-Fehlern, aufgetreten. In der DB2 system administration kann dies unter Display/terminate utilities überprüft werden, wofür auf der Kommandozeile folgender Befehl eingegeben wird: -DIS DB(RETAIL) SPACENAM(TSTRANLO) LIMIT(*). Der Einfachkeit halber wurde beim Status RECP (Recovery Pending) der Tablespace neu angelegt. Nach dem Submit eines JCL-Skriptes wird dieses abgearbeitet und bei kleineren Aufgaben erfolgt innerhalb weniger Sekunden eine Rückmeldung über einen Fehlercode, der Aufschluß über den Erfolg oder Mißerfolg bei der Ausführung gibt, ein Beispiel dafür ist folgende Meldung: JOB08815 $HASP165 NENTWIGL ENDED AT BOEDWB1 MAXCC=0004 CN(INTERNAL) Interessant ist der Wert hinter MAXCC, bei 0 ist alles erfolgreich verarbeitet, bei 4 sind Warnungen aufgetreten und bei 8, 12 oder 16 sind Fehler aufgetreten, die eine erfolgreiche Ausführung verhindern. In einem der Fehlerfälle wird das SDSF (System Display and Search Facility) als zentralen Anlaufpunkt für die Job-Logs verwendet, um nach der Ursache des Fehlers zu suchen. Desweiteren hilft bei manchen Fehlern die eben erwähnte DB2 system administration, meist ist jedoch das SDSF nützlicher. Die Arbeit mit den Logs ist jedoch sehr zeitaufwändig, da es nahezu keine Aufbereitung der Daten gibt und die Logs unter Umständen sehr groß werden können. Ein Ausschnitt aus einem Log von einem JCL-Skript zum Laden von Daten ist in Abbildung 4.3 zu sehen, dieser zeigt einen JCL Fehler, durch welchen die Ausführung des Skriptes verhindert wird. 4.2 Integration in IDAA Die Integration in einen angeschlossenen DB2 Analytics Accelerator beinhaltet grunsätzlich zwei Schritte. Zum einen das Übertragen der Daten auf den Accelerator, und zum anderen die Untersuchung der verwendeten Algorithmen daraufhin, welche Anpassungen auf dem Accelerator zur Berechnung mit IBM 57

63 4.2 Integration in IDAA Abbildung 4.3: SDSF-Subsystem, zu sehen ist ein Ausschnitt aus einem Log für einen Job NENTWIGL, der ein LOAD ausführen soll. In diesem Beispiel ist der Fehler leicht zu finden, da es ein zeitiger und schwerer Fehler in der fünften Zeile ist: VOLUME SELECTION HAS FAILED FOR INSUFFICIENT SPACE 58

64 4.2 Integration in IDAA Netezza Analytics (INZA) nötig sind. Der Transfer der Daten auf den Accelerator wird im Abschnitt beschrieben, die wesentliche Aufgabe ist jedoch die Überprüfung und Anpassung der Algorithmen im Abschnitt mit Fokus auf RFM-Analyse und die Assoziationsanalyse Offload auf IDAA Die wichtigste Grundlage für einen Offload von Tabellen auf das angeschlossene IDAA ist, dass die Daten bereits auf dem DB2 verfügbar sind. Mit der Abbildung der Szenarien auf das DB2 wie in Abschnitt 4.1 beschrieben ist die Vorbereitung abgeschlossen. Mit dem auf Eclipse aufbauenden IBM DB2 Analytics Accelerator Studio können mit dem System verbundene Beschleuniger verwaltet werden, dazu gehört etwa das initiale Laden der Daten oder die Vergabe von Distribution Keys. Ein Beispiel für den Einsatz von Distribution Keys Abbildung 4.4: IBM DB2 Analytics Accelerator Studio, welches die beschleunigten Tabellen auf dem Accelerator VMNPS02 vom Nutzer NENTWIG anzeigt. Das IDAA Studio bietet Möglichkeiten zur Verwaltung von mehreren IDAA-Systemen sowie Optimierungen etwa bei der Verteilung der Tabelleninhalte über Distribution Keys. kann sein, dass ein bestimmtes, möglichst gleich verteiltes Attribut einer Faktentabelle gewählt wird, wodurch eine ähnliche Verteilung der Daten auf den 59

Einführungsveranstaltung: Data Warehouse

Einführungsveranstaltung: Data Warehouse Einführungsveranstaltung: 1 Anwendungsbeispiele Berichtswesen Analyse Planung Forecasting/Prognose Darstellung/Analyse von Zeitreihen Performancevergleiche (z.b. zwischen Organisationseinheiten) Monitoring

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

The integration of business intelligence and knowledge management

The integration of business intelligence and knowledge management The integration of business intelligence and knowledge management Seminar: Business Intelligence Ketevan Karbelashvili Master IE, 3. Semester Universität Konstanz Inhalt Knowledge Management Business intelligence

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Ermittlung von Assoziationsregeln aus großen Datenmengen. Zielsetzung

Ermittlung von Assoziationsregeln aus großen Datenmengen. Zielsetzung Ermittlung von Assoziationsregeln aus großen Datenmengen Zielsetzung Entscheidungsträger verwenden heutzutage immer häufiger moderne Technologien zur Lösung betriebswirtschaftlicher Problemstellungen.

Mehr

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Ein Data-Warehouse bzw. Datenlager ist eine zentrale Datensammlung (meist eine Datenbank), deren Inhalt sich aus Daten unterschiedlicher

Mehr

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Datei: Asklepius DA Flyer_Leistung_2 Seite: 1 von:5 1 Umfassende Datenanalyse Mit Asklepius-DA

Mehr

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Exposé zur Diplomarbeit Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

2. Microsoft Innovationstag Nord Integrierte Lösungen in der Öffentlichen Verwaltung

2. Microsoft Innovationstag Nord Integrierte Lösungen in der Öffentlichen Verwaltung 2. Microsoft Innovationstag Nord Integrierte Lösungen in der Öffentlichen Verwaltung Reporting, Analyse und Data Mining André Henkel, initions AG 22. und 23. Oktober 2013 in Hamburg

Mehr

PPC und Data Mining. Seminar aus Informatik LV-911.039. Michael Brugger. Fachbereich der Angewandten Informatik Universität Salzburg. 28.

PPC und Data Mining. Seminar aus Informatik LV-911.039. Michael Brugger. Fachbereich der Angewandten Informatik Universität Salzburg. 28. PPC und Data Mining Seminar aus Informatik LV-911.039 Michael Brugger Fachbereich der Angewandten Informatik Universität Salzburg 28. Mai 2010 M. Brugger () PPC und Data Mining 28. Mai 2010 1 / 14 Inhalt

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Kapitel 2 Terminologie und Definition

Kapitel 2 Terminologie und Definition Kapitel 2 Terminologie und Definition In zahlreichen Publikationen und Fachzeitschriften tauchen die Begriffe Data Warehouse, Data Warehousing, Data-Warehouse-System, Metadaten, Dimension, multidimensionale

Mehr

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

Mehr

Business Intelligence Data Warehouse. Jan Weinschenker

Business Intelligence Data Warehouse. Jan Weinschenker Business Intelligence Data Warehouse Jan Weinschenker 28.06.2005 Inhaltsverzeichnis Einleitung eines Data Warehouse Data Warehouse im Zusammenfassung Fragen 3 Einleitung Definition: Data Warehouse A data

Mehr

Oracle 10g revolutioniert Business Intelligence & Warehouse

Oracle 10g revolutioniert Business Intelligence & Warehouse 10g revolutioniert Business Intelligence & Warehouse Marcus Bender Strategisch Technische Unterstützung (STU) Hamburg 1-1 BI&W Market Trends DWH werden zu VLDW Weniger Systeme, mehr Daten DWH werden konsolidiert

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Data Mining-Modelle und -Algorithmen

Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining ist ein Prozess, bei dem mehrere Komponenten i n- teragieren. Sie greifen auf Datenquellen, um diese zum Training,

Mehr

Neuerungen Analysis Services

Neuerungen Analysis Services Neuerungen Analysis Services Neuerungen Analysis Services Analysis Services ermöglicht Ihnen das Entwerfen, Erstellen und Visualisieren von Data Mining-Modellen. Diese Mining-Modelle können aus anderen

Mehr

Agile Analytics Neue Anforderungen an die Systemarchitektur

Agile Analytics Neue Anforderungen an die Systemarchitektur www.immobilienscout24.de Agile Analytics Neue Anforderungen an die Systemarchitektur Kassel 20.03.2013 Thorsten Becker & Bianca Stolz ImmobilienScout24 Teil einer starken Gruppe Scout24 ist der führende

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery Kapitel II Datenbereitstellung 2004 AIFB / FZI 1 II. Datenbereitstellung 2004 AIFB / FZI 2 II. Datenbereitstellung Collect Initial Data identify relevant attributes identify inconsistencies between sources

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Das ultimative Daten Management

Das ultimative Daten Management Das ultimative Daten Management Beschreibung des Programms Rafisa AG Seestrasse 78 CH 8703 Erlenbach-Zürich Ziel und Zweck Das Program: ist ein multi-funktionales Programm, welches dazu dient, für den

Mehr

IBM Netezza Data Warehouse Appliances - schnelle Analysen mit hohen Datenmengen

IBM Netezza Data Warehouse Appliances - schnelle Analysen mit hohen Datenmengen IBM Netezza Data Warehouse Appliances - schnelle Analysen mit hohen Datenmengen Nahezu 70% aller Data Warehouse Anwendungen leiden unter Leistungseinschränkungen der unterschiedlichsten Art. - Gartner

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

Datawarehouse Architekturen. Einheitliche Unternehmenssicht

Datawarehouse Architekturen. Einheitliche Unternehmenssicht Datawarehouse Architekturen Einheitliche Unternehmenssicht Was ist Datawarehousing? Welches sind die Key Words? Was bedeuten sie? DATA PROFILING STAGING AREA OWB ETL OMB*PLUS SAS DI DATA WAREHOUSE DATA

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede Data Warehouse Version: June 26, 2007 Andreas Geyer-Schulz und Anke Thede Schroff-Stiftungslehrstuhl Informationsdienste und Elektronische Märkte Fakultät für Wirtschaftswissenschaften Gebäude 20.20 Rechenzentrum,

Mehr

Die Laborjournalführungs-Software professionell - zuverlässig

Die Laborjournalführungs-Software professionell - zuverlässig Produktinformation Die Laborjournalführungs-Software professionell - zuverlässig Integration von InfoChem ICEdit, ensochemeditor, MDL ISIS / Draw und CS ChemDraw Optional mit Schnittstelle zu anderen Datenbanksystemen

Mehr

REAL-TIME DATA WAREHOUSING

REAL-TIME DATA WAREHOUSING REAL-TIME DATA WAREHOUSING Lisa Wenige Seminarvortrag Data Warehousing und Analytische Datenbanken Friedrich-Schiller-Universität Jena - 19.01.12 Lisa Wenige 19.01.2012 2 Agenda 1. Motivation 2. Begriffsbestimmung

Mehr

MaxDB-Schulungsthemen

MaxDB-Schulungsthemen MaxDB-Schulungsthemen Ein Überblick über unser Angebot Allgemeine Hinweise zu unseren Schulungen Die Schulungen finden in der Regel als Inhouse Schulungen bei den interessierten Unternehmen statt. Die

Mehr

Analysen sind nur so gut wie die Datenbasis

Analysen sind nur so gut wie die Datenbasis Analysen sind nur so gut wie die Datenbasis Datenaufbereitung und Sicherung der Datenqualität durch den kontextbasierten MIOsoft Ansatz. Daten gelten längst als wichtiger Produktionsfaktor in allen Industriebereichen.

Mehr

SQL SERVER 2005 IM VERGLEICH ZU ORACLE 10G. Alexander Bittner, 07MIM Datenbanken II HTWK Leipzig, FbIMN

SQL SERVER 2005 IM VERGLEICH ZU ORACLE 10G. Alexander Bittner, 07MIM Datenbanken II HTWK Leipzig, FbIMN SQL SERVER 2005 IM VERGLEICH ZU ORACLE 10G Alexander Bittner, 07MIM Datenbanken II HTWK Leipzig, FbIMN Gliederung Rechnerarchitekturen Datenspeicherung Verbindungen / Instanzen SQL Standards Nebenläufigkeit

Mehr

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06 Business Intelligence Data Warehouse / Analyse Sven Elvers 2005-07-06 Einleitung Dieses Dokument beschreibt einen für das Verständnis relevanten Teil der Präsentation. Business Intelligence Motivation

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

3. Entscheidungsbäume. Verfahren zum Begriffslernen (Klassifikation) Beispiel: weiteres Beispiel: (aus Böhm 2003) (aus Morik 2002)

3. Entscheidungsbäume. Verfahren zum Begriffslernen (Klassifikation) Beispiel: weiteres Beispiel: (aus Böhm 2003) (aus Morik 2002) 3. Entscheidungsbäume Verfahren zum Begriffslernen (Klassifikation) Beispiel: weiteres Beispiel: (aus Böhm 2003) (aus Morik 2002) (aus Wilhelm 2001) Beispiel: (aus Böhm 2003) Wann sind Entscheidungsbäume

Mehr

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

Data Mining mit der SEMMA Methodik. Reinhard Strüby, SAS Institute Stephanie Freese, Herlitz PBS AG

Data Mining mit der SEMMA Methodik. Reinhard Strüby, SAS Institute Stephanie Freese, Herlitz PBS AG Data Mining mit der SEMMA Methodik Reinhard Strüby, SAS Institute Stephanie Freese, Herlitz PBS AG Data Mining Data Mining: Prozeß der Selektion, Exploration und Modellierung großer Datenmengen, um Information

Mehr

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Architektur und Konzepte Josef Kolbitsch Manuela Reinisch Übersicht Mehrstufiges BI-System Architektur eines Data Warehouses Architektur eines Reporting-Systems Benutzerrollen in

Mehr

Seminar Business Intelligence Teil II. Data Mining & Knowledge Discovery

Seminar Business Intelligence Teil II. Data Mining & Knowledge Discovery Seminar Business Intelligence Teil II Data Mining & Knowledge Discovery Was ist Data Mining? Sabine Queckbörner Was ist Data Mining? Data Mining Was ist Data Mining? Nach welchen Mustern wird gesucht?

Mehr

Motivation. Themenblock: Data Preprocessing. Einsatzgebiete für Data Mining I. Modell von Gianotti und Pedreschi

Motivation. Themenblock: Data Preprocessing. Einsatzgebiete für Data Mining I. Modell von Gianotti und Pedreschi Motivation Themenblock: Data Preprocessing We are drowning in information, but starving for knowledge! (John Naisbett) Was genau ist Datenanalyse? Praktikum: Data Warehousing und Data Mining Was ist Data

Mehr

Proaktive Entscheidungsunterstützung für Geschäftsprozesse durch neuronale Netze

Proaktive Entscheidungsunterstützung für Geschäftsprozesse durch neuronale Netze Proaktive Entscheidungsunterstützung für Geschäftsprozesse durch neuronale Netze INAUGURALDISSERTATION zur Erlangung des akademischen Grades eines Doktors der Wirtschaftswissenschaften an der Wirtschaftswissenschaftlichen

Mehr

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII Vorwort zur zweiten Auflage...V Vorwort zur ersten Auflage... VIII 1 Management Support Systeme und Business Intelligence Anwendungssysteme zur Unterstützung von Managementaufgaben...1 1.1 Computergestützte

Mehr

Matrikelnr: Name: Vorname: Aufgabe 1 2 3 4 Summe Maximal erreichbare 20 30 30 20 100 Punktzahl Erreichte Punktzahl. Note:

Matrikelnr: Name: Vorname: Aufgabe 1 2 3 4 Summe Maximal erreichbare 20 30 30 20 100 Punktzahl Erreichte Punktzahl. Note: Fakultät für Wirtschaftswissenschaft Matrikelnr: Name: Vorname: : Modul 32711 Business Intelligence Termin: 28.03.2014, 9:00 11:00 Uhr Prüfer: Univ.-Prof. Dr. U. Baumöl Aufbau und Bewertung der Aufgabe

Mehr

Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick. Volker.Hinz@microsoft.com

Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick. Volker.Hinz@microsoft.com Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick Volker.Hinz@microsoft.com Was sagt der Markt? Fakten Meinung der Analysten zu Microsofts Angeboten Nutzen

Mehr

Survival Guide für Ihr Business Intelligence-Projekt

Survival Guide für Ihr Business Intelligence-Projekt Survival Guide für Ihr Business Intelligence-Projekt Sven Bosinger Solution Architect BI Survival Guide für Ihr BI-Projekt 1 Agenda Was ist Business Intelligence? Leistungsumfang Prozesse Erfolgsfaktoren

Mehr

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II.

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II. II. bereitstellung Kapitel II bereitstellung 1 2 II. bereitstellung II.1 Grundlagen Collect Initial Data identify relevant attributes identify inconsistencies between sources Describe Data characterize

Mehr

Begriffsbestimmung CRISP-DM-Modell Betriebswirtschaftliche Einsatzgebiete des Data Mining Web Mining und Text Mining

Begriffsbestimmung CRISP-DM-Modell Betriebswirtschaftliche Einsatzgebiete des Data Mining Web Mining und Text Mining Gliederung 1. Einführung 2. Grundlagen Data Mining Begriffsbestimmung CRISP-DM-Modell Betriebswirtschaftliche Einsatzgebiete des Data Mining Web Mining und Text Mining 3. Ausgewählte Methoden des Data

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Heterogenes Speichermanagement mit V:DRIVE

Heterogenes Speichermanagement mit V:DRIVE Heterogenes Speichermanagement mit V:DRIVE V:DRIVE - Grundlage eines effizienten Speichermanagements Die Datenexplosion verlangt nach innovativem Speichermanagement Moderne Businessprozesse verlangen auf

Mehr

Logische Modellierung von Data Warehouses

Logische Modellierung von Data Warehouses Logische Modellierung von Data Warehouses Vertiefungsarbeit von Karin Schäuble Gliederung. Einführung. Abgrenzung und Grundlagen. Anforderungen. Logische Modellierung. Methoden.. Star Schema.. Galaxy-Schema..

Mehr

Oracle Database 10g Die RAC Evolution

Oracle Database 10g Die RAC Evolution Oracle Database 10g Die RAC Evolution Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 RAC-Revolution, RAC-Evolution & Computing Oracle8i mit OPS Oracle9i Rel.

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT

Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT Neue Technologien effizient nutzen Ehningen, 3. Juli 2014 Rodney Krick rk@aformatik.de aformatik Training & Consulting GmbH & Co. KG

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Motivation. Themenblock: Klassifikation. Binäre Entscheidungsbäume. Ansätze. Praktikum: Data Warehousing und Data Mining.

Motivation. Themenblock: Klassifikation. Binäre Entscheidungsbäume. Ansätze. Praktikum: Data Warehousing und Data Mining. Motivation Themenblock: Klassifikation Praktikum: Data Warehousing und Data Mining Ziel Item hat mehrere Attribute Anhand von n Attributen wird (n+)-tes vorhergesagt. Zusätzliches Attribut erst später

Mehr

Data Mining Anwendungen und Techniken

Data Mining Anwendungen und Techniken Data Mining Anwendungen und Techniken Knut Hinkelmann DFKI GmbH Entdecken von Wissen in banken Wissen Unternehmen sammeln ungeheure mengen enthalten wettbewerbsrelevantes Wissen Ziel: Entdecken dieses

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Der Mainframe-Kult ist tot! Host Einführung. 18.12.2001 Norbert Graß (CCI) Ein Gerücht. Werbekampagne eines Serverherstellers aus dem Jahr 1988

Der Mainframe-Kult ist tot! Host Einführung. 18.12.2001 Norbert Graß (CCI) Ein Gerücht. Werbekampagne eines Serverherstellers aus dem Jahr 1988 Host Einführung 18.12.2001 Norbert Graß (CCI) Ein Gerücht Der Mainframe-Kult ist tot! Werbekampagne eines Serverherstellers aus dem Jahr 1988 Norbert Graß/18.12.01-2- 1 Die Realität 90 % der weltweit größten

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Towards Automated Analysis of Business Processes for Financial Audits

Towards Automated Analysis of Business Processes for Financial Audits Towards Automated Analysis of Business Processes for Financial Audits Michael Werner Universität Hamburg michael.werner@wiso.uni hamburg.de Max Brauer Allee 60 22765 Hamburg StB Prof. Dr. Nick Gehrke Nordakademie

Mehr

Microsoft Lizenzierung SQL Server 2014. Bernd Löschner

Microsoft Lizenzierung SQL Server 2014. Bernd Löschner Bernd Löschner EDITIONEN Enterprise Edition für mission critical Anwendungen und large scale Data Warehousing. Business Intelligence Edition für Premium Unternehmen und self service BI. Standard Edition

Mehr

DATEN - Das Gold des 21. Jahrhunderts? Dr. Oliver Riedel, AUDI AG

DATEN - Das Gold des 21. Jahrhunderts? Dr. Oliver Riedel, AUDI AG DATEN - Das Gold des 21. Jahrhunderts? Dr. Oliver Riedel, AUDI AG Inhalt Globale und unternehmensspezifische Herausforderungen Von Big Data zu Smart Data Herausforderungen und Mehrwert von Smart Data 2

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

Komplexität der Information - Ausgangslage

Komplexität der Information - Ausgangslage Intuition, verlässliche Information, intelligente Entscheidung ein Reisebericht Stephan Wietheger Sales InfoSphere/Information Management Komplexität der Information - Ausgangslage Liefern von verlässlicher

Mehr

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG Oracle Database 11g Standard Edition One Die passende Datenbank-Lösung

Mehr

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben Transbase Hypercube ist eine Transbase -Option, die die innovative Hypercube-Technologie für komplexe analytische Anwendungen (OLAP)

Mehr

Marketing Intelligence Vorstellung der Softwarekomponenten. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Vorstellung der Softwarekomponenten. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Vorstellung der Softwarekomponenten Josef Kolbitsch Manuela Reinisch Übersicht Übersicht über die Systemlandschaft Übersicht über die Werkzeuge Workshop Systemlandschaft 1/8 Klassische

Mehr

IBM SPSS Modeler Entity Analytics - Erweiterte Konfiguration

IBM SPSS Modeler Entity Analytics - Erweiterte Konfiguration IBM SPSS Entity Analytics - Erweiterte Konfiguration Einführung Die vorgesehene Zielgruppe für dieses Handbuch sind Systemadministratoren, die IBM SPSS Entity Analytics (EA) für die Ausführung in einer

Mehr

Configuration Management mit Verbosy 17.04.2013 OSDC 2013. Eric Lippmann www.netways.de

Configuration Management mit Verbosy 17.04.2013 OSDC 2013. Eric Lippmann www.netways.de Configuration Management mit Verbosy 17.04.2013 OSDC 2013 Eric Lippmann Kurzvorstellung NETWAYS Expertise OPEN SOURCE SYSTEMS MANAGEMENT OPEN SOURCE DATA CENTER Monitoring & Reporting Configuration Management

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

BESCHAFFUNG UND LIZENZIERUNG

BESCHAFFUNG UND LIZENZIERUNG BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG: ORACLE LIZENZIERUNG Fragen Sie uns! Oracle Database 12c Standard

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

1Ralph Schock RM NEO REPORTING

1Ralph Schock RM NEO REPORTING 1Ralph Schock RM NEO REPORTING Bereit für den Erfolg Business Intelligence Lösungen Bessere Entscheidungen Wir wollen alle Mitarbeiter in die Lage versetzen, bessere Entscheidungen schneller zu treffen

Mehr

AGM Project & Education GmbH

AGM Project & Education GmbH AGM Project & Education GmbH Leipzig Datenschutzkonferenz dtb Kassel November 2011 20.11.2011 Detlev.Sachse@agm-onside.com 1 Zur Person 20.11.2011 Detlev.Sachse@agm-onside.com 2 Thema Data-Mining am Beispiel

Mehr

Was ist Analyse? Hannover, CeBIT 2014 Patrick Keller

Was ist Analyse? Hannover, CeBIT 2014 Patrick Keller Was ist? Hannover, CeBIT 2014 Patrick Keller Business Application Research Center Historie 1994: Beginn der Untersuchung von Business-Intelligence-Software am Lehrstuhl Wirtschaftsinformatik der Universität

Mehr

Data/Information Quality Management

Data/Information Quality Management Data/Information Quality Management Seminar WI/Informationsmanagement im Sommersemester 2002 Markus Berberov, Roman Eder, Peter Gerstbach 11.6.2002 Inhalt! Daten und Datenqualität! Einführung und Definition!

Mehr

Datenbanken und Oracle, Teil 2

Datenbanken und Oracle, Teil 2 Datenbanken und Oracle, Teil 2 Mathias Weyland Linux User Group Switzerland 29. Juni 2007 SQL*Plus CHAR/VARCHAR2 Dokumentation Teil I Nachträge 1 SQL*Plus 2 CHAR/VARCHAR2 3 Dokumentation SQL*Plus SQL*Plus

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Fachgruppe Statistik, Risikoanalyse & Computing. STAT672 Data Mining. Sommersemester 2007. Prof. Dr. R. D. Reiß

Fachgruppe Statistik, Risikoanalyse & Computing. STAT672 Data Mining. Sommersemester 2007. Prof. Dr. R. D. Reiß Fachgruppe Statistik, Risikoanalyse & Computing STAT672 Data Mining Sommersemester 2007 Prof. Dr. R. D. Reiß Überblick Data Mining Begrifflichkeit Unter Data Mining versteht man die Computergestützte Suche

Mehr

Anwendung der Predictive Analytics

Anwendung der Predictive Analytics TDWI Konferenz mit BARC@TDWI Track 2014 München, 23. 25. Juni 2014 Anwendung der Predictive Analytics Prof. Dr. Carsten Felden Dipl. Wirt. Inf. Claudia Koschtial Technische Universität Bergakademie Freiberg

Mehr

Information-Design-Tool

Information-Design-Tool Zusatzkapitel Information-Design-Tool zum Buch»HR-Reporting mit SAP «von Richard Haßmann, Anja Marxsen, Sven-Olaf Möller, Victor Gabriel Saiz Castillo Galileo Press, Bonn 2013 ISBN 978-3-8362-1986-0 Bonn

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

tcvision Freigabemitteilung Version 6

tcvision Freigabemitteilung Version 6 tcvision Freigabemitteilung Version 6 Stand: 5. Mai 2015 TCP/IP TCP/IP Verbindungen werden dynamisch auf- und abgebaut, um Stabilitätsproblemen in der Infrastruktur zu begegnen. Mit Hilfe des tcscript

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 374 Eignung von Verfahren der Mustererkennung im Process Mining Sabrina Kohne

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

Data Mining und maschinelles Lernen

Data Mining und maschinelles Lernen Data Mining und maschinelles Lernen Einführung und Anwendung mit WEKA Caren Brinckmann 16. August 2000 http://www.coli.uni-sb.de/~cabr/vortraege/ml.pdf http://www.cs.waikato.ac.nz/ml/weka/ Inhalt Einführung:

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Analytische Datenbanken und Appliances als Engine für erfolgreiche Business Intelligence

Analytische Datenbanken und Appliances als Engine für erfolgreiche Business Intelligence Analytische Datenbanken und Appliances als Engine für erfolgreiche Business Intelligence IBM Netezza Roadshow 30. November 2011 Carsten Bange Gründer & Geschäftsführer BARC Die Krise hat die Anforderungen

Mehr

O-BIEE Einführung mit Beispielen aus der Praxis

O-BIEE Einführung mit Beispielen aus der Praxis O-BIEE Einführung mit Beispielen aus der Praxis Stefan Hess Business Intelligence Trivadis GmbH, Stuttgart 2. Dezember 2008 Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg

Mehr

BARC-Studie Data Warehousing und Datenintegration

BARC-Studie Data Warehousing und Datenintegration Ergebnisse der BARC-Studie Data Warehouse Plattformen Dr. Carsten Bange BARC-Studie Data Warehousing und Datenintegration Data-Warehouse -Plattformen und Datenintegrationswerkzeuge im direkten Vergleich

Mehr

SAS Analytics bringt SAP HANA in den Fachbereich

SAS Analytics bringt SAP HANA in den Fachbereich Pressemitteilung Hamburg, 08. November 2013 SAS Analytics bringt SAP HANA in den Fachbereich Ergonomie kombiniert mit Leistungsfähigkeit: die BI-Experten der accantec group geben der neuen Partnerschaft

Mehr