Dr. André Lougear

Process-Mining: Es werde Licht

/0 Comments/in , , , /by

Anzeige

Nur wer seine Prozesse kennt, kann sie optimieren

Gewachsene und in verschiedenen Systemen umgesetzte Prozesse sind meist nicht definiert und dokumentiert. Wer hat einen Prozess wann, warum und wofür angelegt? Nach welchem Schema verläuft er? Gibt es verschiedene Prozessvarianten, die durch unterschiedliche Parameter gesteuert sind? Diese Fragen können viele Unternehmen nicht beantworten und ihre betrieblichen Abläufe nicht optimieren – mit der Folge, dass sie weder ihre Transparenz steigern noch die Kosten senken und von Wettbewerbsvorteilen profitieren können.

Ohne transparente, aktuelle und einheitliche Prozessdokumentation ist der Aufwand zur Aneignung des Prozesswissens unnötig hoch – zumal die Intransparenz sehr teuer ist. Insbesondere für Unternehmen im Finance-Umfeld ist eine transparente, aktuelle Dokumentation Pflicht. Nur so können Wirtschaftsprüfer oder Revisionsabteilungen Unregelmäßigkeiten und Verstöße gegen Compliance-Richtlinien in Prozessen identifizieren und nachweisen, dass Firmen normative Vorgaben wie die Mindestanforderungen an das Risikomanagement (MaRisk) der BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) einhalten.

Prozesse sichtbar machen

Durchblick gewährt das Process-Mining. Es macht die in Technik verborgenen Prozesse sichtbar. Als Bestandteil des Business-Process-Managements (BPM) ermöglicht es, Prozesse aus ihren digitalen Spuren in ERP-, CRM- oder proprietären Systemen zu rekonstruieren und auszuwerten. Viele Unternehmen wissen nicht, wie viele digitale Abläufe es gibt, wie sie chronologisch vonstattengehen, wie sie zusammenhängen, welche Prozessvariante wie viele Anwender wie häufig durchlaufen – und was das kostet. Ausgangspunkt des Process-Minings ist eine Sammlung der Prozessschritte. Mit statistischen Modellen lässt sich dann der Kernprozess ermitteln, der als Basis für alle Prozessabläufe Abweichungen offenbart.

Beispiel: Bestellanforderung in SAP anlegen

Der Standardprozess ist einfach: Bestellanforderung ins SAP-System eingeben, an Prozessfreigeber senden, von ihm prüfen und freigeben lassen. Die Realität könnte aber so sein: Mitarbeiter A bittet Mitarbeiter B per E-Mail, den Prozess einer Bestellanforderung in SAP anzulegen. Also sammelt Mitarbeiter B Informationen in einer Excel-Liste und legt sie auf dem Server ab – und weicht damit vom Standard ab. Da Mitarbeiter B die Freigabe des Vorgesetzten von A benötigt, fragt er ihn per E-Mail, ob er die Bestellung auslösen darf – eine weitere Abweichung. Nach Freigabe schickt Mitarbeiter B die Bestellung an den Lieferanten, ohne den Prozess in SAP anzulegen – schließlich drängt die Zeit. Die Folge: Im ERP-System fehlen Bestellanforderung und Freigabe. Wieso und warum, ist im Nachhinein nicht mehr nachvollziehbar.

Prozesse visualisieren und modellieren

Licht ins Dunkel bringt die Prozessvisualisierung. Sind Prozesse in Dashboards, Diagrammen, Tabellen und Tachoelementen dargestellt, können Unternehmen einfach nachvollziehen, wie Prozesse samt Varianten ablaufen und wie sie verknüpft sind. Auf Basis der Visualisierung ist es möglich, einzelne Abläufe zu modellieren: Man überträgt Prozessabläufe in ein standardisiertes Modell, das Prozessinformationen wie In- und Outputs, beteiligte Rollen, Dokumente und IT-Systeme beinhaltet. Umfangreiche Analysen und Simulationen erlauben dann, Prozesse zu bewerten und Optimierungspotenziale aufzudecken. Ist nachvollziehbar, wie ein Gesamtprozess mit allen Varianten abläuft, können Unternehmen Modifikationen abbauen und einen effizienten Prozess definieren.

Prozesse freigeben, versionieren und publizieren

Neben der Prozessvisualisierung sollte die Process-Mining-Lösung auch die Prozessfreigabe unter Berücksichtigung der Governance-Vorgaben unterstützen. Das erlaubt, Mitarbeitern Rollen wie Prozesseigner, -freigeber oder -prüfer zuzuweisen und eine automatisierte Freigabe zu etablieren. Sind die Daten sauber versioniert und zentral abgelegt, ist für eine lückenlose Dokumentation gesorgt. Um die Mitarbeiter entsprechend zu informieren, sollte das Tool eine einfache Publizierung unterstützen und Informationen zu Risiken, Kennzahlen und IT-Systemen bereitstellen. Außerdem sollten sich Mitarbeiter in die Prozessgestaltung einbringen können.

Informationen auslesen und auswerten – auch in der Cloud

Um eine Prozessdokumentation automatisiert zu erstellen, braucht es einen Algorithmus, der prozessrelevante Informationen aus allen IT-Systemen und Applikationen in das BPM-Tool einspielt. Über Konnektoren zu SAP ERP, Microsoft Dynamics CRM und proprietären IT-Lösungen lässt es sich an Bestandssysteme nahtlos anbinden. Das erlaubt, Informationen zielführend abzugleichen, bedarfsgerecht aufzubereiten und gewinnbringend zu nutzen. Idealerweise ist eine Process-Mining-Software fester Bestandteil eines BPM-Systems (BPMS), das die Prozessplanung, -ausführung, -analyse und -optimierung unterstützt. Eine Monitoring-Komponente sollte es gestatten, Kennzahlen zu erfassen, zu überwachen und auszuwerten. Für maximale Flexibilität ist gesorgt, wenn sich das BPM-System in der Cloud betreiben und bedarfsgerecht anpassen lässt. So können Anwender auf zyklische Lastspitzen mit einem individuellen Ressourcenmanagement reagieren.

Augen auf bei der Anbieter-Auswahl

Neben dem Funktionsumfang ist auch der IT-Dienstleister wichtig. Idealerweise bietet er eine BPM-Suite mit Process-Mining als Teilkomponente. Ein großer, internationaler IT-Systemintegrator mit Erfahrung in allen Branchen hat die nötige Manpower und Erfahrung für komplexe BPM-Projekte. Im Idealfall bietet er Unternehmen State-of-the-art-Technologie und stellt ihnen kompetente, erfahrene Prozessberater zur Seite, die sie in technischen Belangen wie Setup, Integration und Inbetriebnahme sowie dem Auslesen der Daten aus IT-Systemen unterstützen – für eine zielführende Prozessoptimierung und ein wirksames Change-Management. Wenn der Dienstleister über das BPM-Projekt hinaus wertvolle Hilfestellung leistet, können Unternehmen dank Process-Mining wettbewerbsfähiger, innovativer und damit langfristig erfolgreicher werden.

Editorial Staff

New Sponsor: Snowflake

/0 Comments/in , /by

Dear readers,

we have good news again: Now we welcome snowflake as our new Data Science Blog Sponsor! So we are booked out for the moment regarding sponsoring. Snowflake provides data warehousing for the cloud and has an unique data, access and feature model, the snowflake. Now we are looking forward to editorial contributions by snowflake.

Snowflake is the only data warehouse built for the cloud. Snowflake delivers the performance, concurrency and simplicity needed to store and analyze all data available to an organization in one location. Snowflake’s technology combines the power of data warehousing, the flexibility of big data platforms, the elasticity of the cloud, and live data sharing at a fraction of the cost of traditional solutions. Snowflake: Your data, no limits. Find out more at snowflake.net.

Furthermore, snowflake will also sponsor our Data Leader Days 2018 in November in Berlin!

Derry Holding

Applying Data Science Techniques in Python to Evaluate Ionospheric Perturbations from Earthquakes

/0 Comments/in , , , , , , , /by

Multi-GNSS (Galileo, GPS, and GLONASS) Vertical Total Electron Content Estimates: Applying Data Science techniques in Python to Evaluate Ionospheric Perturbations from Earthquakes

1 Introduction

Today, Global Navigation Satellite System (GNSS) observations are routinely used to study the physical processes that occur within the Earth’s upper atmosphere. Due to the experienced satellite signal propagation effects the total electron content (TEC) in the ionosphere can be estimated and the derived Global Ionosphere Maps (GIMs) provide an important contribution to monitoring space weather. While large TEC variations are mainly associated with solar activity, small ionospheric perturbations can also be induced by physical processes such as acoustic, gravity and Rayleigh waves, often generated by large earthquakes.

In this study Ionospheric perturbations caused by four earthquake events have been observed and are subsequently used as case studies in order to validate an in-house software developed using the Python programming language. The Python libraries primarily utlised are Pandas, Scikit-Learn, Matplotlib, SciPy, NumPy, Basemap, and ObsPy. A combination of Machine Learning and Data Analysis techniques have been applied. This in-house software can parse both receiver independent exchange format (RINEX) versions 2 and 3 raw data, with particular emphasis on multi-GNSS observables from GPS, GLONASS and Galileo. BDS (BeiDou) compatibility is to be added in the near future.

Several case studies focus on four recent earthquakes measuring above a moment magnitude (MW) of 7.0 and include: the 11 March 2011 MW 9.1 Tohoku, Japan, earthquake that also generated a tsunami; the 17 November 2013 MW 7.8 South Scotia Ridge Transform (SSRT), Scotia Sea earthquake; the 19 August 2016 MW 7.4 North Scotia Ridge Transform (NSRT) earthquake; and the 13 November 2016 MW 7.8 Kaikoura, New Zealand, earthquake.

Ionospheric disturbances generated by all four earthquakes have been observed by looking at the estimated vertical TEC (VTEC) and residual VTEC values. The results generated from these case studies are similar to those of published studies and validate the integrity of the in-house software.

2 Data Cleaning and Data Processing Methodology

Determining the absolute VTEC values are useful in order to understand the background ionospheric conditions when looking at the TEC perturbations, however small-scale variations in electron density are of primary interest. Quality checking processed GNSS data, applying carrier phase leveling to the measurements, and comparing the TEC perturbations with a polynomial fit creating residual plots are discussed in this section.

Time delay and phase advance observables can be measured from dual-frequency GNSS receivers to produce TEC data. Using data retrieved from the Center of Orbit Determination in Europe (CODE) site (ftp://ftp.unibe.ch/aiub/CODE), the differential code biases are subtracted from the ionospheric observables.

2.1 Determining VTEC: Thin Shell Mapping Function

The ionospheric shell height, H, used in ionosphere modeling has been open to debate for many years and typically ranges from 300 – 400 km, which corresponds to the maximum electron density within the ionosphere. The mapping function compensates for the increased path length traversed by the signal within the ionosphere. Figure 1 demonstrates the impact of varying the IPP height on the TEC values.

Figure 1 Impact on TEC values from varying IPP heights. The height of the thin shell, H, is increased in 50km increments from 300 to 500 km.

2.2 Phase Smoothing

For dual-frequency GNSS users TEC values can be retrieved with the use of dual-frequency measurements by applying calculations. Calculation of TEC for pseudorange measurements in practice produces a noisy outcome and so the relative phase delay between two carrier frequencies – which produces a more precise representation of TEC fluctuations – is preferred. To circumvent the effect of pseudorange noise on TEC data, GNSS pseudorange measurements can be smoothed by carrier phase measurements, with the use of the carrier phase smoothing technique, which is often referred to as carrier phase leveling.

Figure 2 Phase smoothed code differential delay

2.3 Residual Determination

For the purpose of this study the monitoring of small-scale variations in ionospheric electron density from the ionospheric observables are of particular interest. Longer period variations can be associated with diurnal alterations, and changes in the receiver- satellite elevation angles. In order to remove these longer period variations in the TEC time series as well as to monitor more closely the small-scale variations in ionospheric electron density, a higher-order polynomial is fitted to the TEC time series. This higher-order polynomial fit is then subtracted from the observed TEC values resulting in the residuals. The variation of TEC due to the TID perturbation are thus represented by the residuals. For this report the polynomial order applied was typically greater than 4, and was chosen to emulate the nature of the arc for that particular time series. The order number selected is dependent on the nature of arcs displayed upon calculating the VTEC values after an initial inspection of the VTEC plots.

3 Results

3.1 Tohoku Earthquake

For this particular report, the sampled data focused on what was retrieved from the IGS station, MIZU, located at Mizusawa, Japan. The MIZU site is 39N 08′ 06.61″ and 141E 07′ 58.18″. The location of the data collection site, MIZU, and the earthquake epicenter can be seen in Figure 3.

Figure 3 MIZU IGS station and Tohoku earthquake epicenter [generated using the Python library, Basemap]

Figure 4 displays the ionospheric delay in terms of vertical TEC (VTEC), in units of TECU (1 TECU = 1016 el m-2). The plot is split into two smaller subplots, the upper section displaying the ionospheric delay (VTEC) in units of TECU, the lower displaying the residuals. The vertical grey-dashed lined corresponds to the epoch of the earthquake at 05:46:23 UT (2:46:23 PM local time) on March 11 2011. In the upper section of the plot, the blue line corresponds to the absolute VTEC value calculated from the observations, in this case L1 and L2 on GPS, whereby the carrier phase leveling technique was applied to the data set. The VTEC values are mapped from the STEC values which are calculated from the LOS between MIZU and the GPS satellite PRN18 (on Figure 4 denoted G18). For this particular data set as seen in Figure 4, a polynomial fit of  five degrees was applied, which corresponds to the red-dashed line. As an alternative to polynomial fitting, band-pass filtering can be employed when TEC perturbations are desired. However for the scope of this report polynomial fitting to the time series of TEC data was the only method used. In the lower section of Figure 4 the residuals are plotted. The residuals are simply the phase smoothed delay values (the blue line) minus the polynomial fit line (the red-dashed line). All ionosphere delay plots follow the same layout pattern and all time data is represented in UT (UT = GPS – 15 leap seconds, whereby 15 leap seconds correspond to the amount of leap seconds at the time of the seismic event). The time series shown for the ionosphere delay plots are given in terms of decimal of the hour, so that the format follows hh.hh.

Figure 4 VTEC and residual plot for G18 at MIZU on March 11 2011

3.2 South Georgia Earthquake

In the South Georgia Island region located in the North Scotia Ridge Transform (NSRT) plate boundary between the South American and Scotia plates on 19 August 2016, a magnitude of 7.4 MW earthquake struck at 7:32:22 UT. This subsection analyses the data retrieved from KEPA and KRSA. As well as computing the GPS and GLONASS TEC values, four Galileo satellites (E08, E14, E26, E28) are also analysed. Figure 5 demonstrates the TEC perturbations as computed for the Galileo L1 and L5 carrier frequencies.

Figure 5 VTEC and residual plots at KRSA on 19 August 2016. The plots are from the perspective of the GNSS receiver at KRSA, for four Galileo satellites (a) E08; (b) E14; (c) E24; (d) E26. The y-axes and x-axes in all plots do not conform with one another but are adjusted to fit the data. The y-axes for the residual section of each plot is consistent with one another.

Figure 6 Geometry of the Galileo (E08, E14, E24 and E26) satellites’ projected ground track whereby the IPP is set to 300km altitude. The orange lines correspond to tectonic plate boundaries.

4 Conclusion

The proximity of the MIZU site and magnitude of the Tohoku event has provided a remarkable – albeit a poignant – opportunity to analyse the ocean-ionospheric coupling aftermath of a deep submarine seismic event. The Tohoku event has also enabled the observation of the origin and nature of the TIDs generated by both a major earthquake and tsunami in close proximity to the epicenter. Further, the Python software developed is more than capable of providing this functionality, by drawing on its mathematical packages, such as NumPy, Pandas, SciPy, and Matplotlib, as well as employing the cartographic toolkit provided from the Basemap package, and finally by utilizing the focal mechanism generation library, Obspy.

Pre-seismic cursors have been investigated in the past and strongly advocated in particular by Kosuke Heki. The topic of pre-seismic ionospheric disturbances remains somewhat controversial. A potential future study area could be the utilization of the Python program – along with algorithmic amendments – to verify the existence of this phenomenon. Such work would heavily involve the use of Scikit-Learn in order to ascertain the existence of any pre-cursors.

Finally, the code developed is still retained privately and as of yet not launched to any particular platform, such as GitHub. More detailed information on this report can be obtained here:

Download as PDF

Benjamin Aunkofer

Maschinelles Lernen: Parametrisierte und nicht-parametrisierte Verfahren

/2 Comments/in , , , , , /by

Das ist Artikel 3 von 4 aus der Artikelserie – Was ist eigentlich Machine Learning?

Maschinelle Lernverfahren können voneinander unterschiedlich abgegrenzt werden, die den meisten Einsteigern bekannte Abgrenzung ist die zwischen überwachten und unüberwachten Verfahren. Eine weitere Abgrenzung zwischen den Lernverfahren, die weit weniger bekannt und verständlich ist, und um die es in diesem Artikel der Reihe gehen soll, ist die Unterscheidung in parametrisierte und nicht parametrisierte Lernverfahren. Gleich vorweg: Parametrisiert und nicht-parametrisierte bezieht sich auf das Modell (Trainingsergebnis), nicht auf die Algorithmen selbst (also nicht Parameter wie k-Werte, Iterations-, Gewichtungs- oder Regularisierungs-Parameter).

Parametrisierte Lernverfahren (parametric learning)

Parametrisierte Lernverfahren sind solche, die über ein Training mit sogenannten Trainingsdaten eine Funktion mit festen Parametern entwickeln, beispielsweise y = f(x) = x³ * a + x² * b + x *c + d. Diese Funktion hat dank einer festgesetzten Anzahl an Parametern eine feste Struktur, und genau dieser Fakt der Parameter-Struktur-Bestimmung a-priori macht das Lernverfahren zu einem parametrischen Lernverfahren. Nach dem Training stehen die Sturkur und die Parameter-Werte fest, beispielsweise y = x³ * 32 + x² * -4 + x * 2 + 102. Diese Funktion beschreibt den Zusammenhang zwischen dem Input x und dem Output y. Am einfachsten kann man sich das Prinzip des parametrischen Lernens demnach mit der Regression vorstellen: Eine Gerade oder eine Kurve wird über ein Trainingslauf durch eine Punktwolke gezogen und daraus die Funktion abgeleitet. Bei der Prädiktion wird diese Funktion dann dazu verwendet, mit den neuen Input-Werten den Output zu berechnen.

Mit dem Festsetzen der Struktur der Funktion bereits vor dem Training sind einige Vor- und Nachteile verbunden:

Parametrische Lernverfahren sind manchmal etwas einfacher zu verstehen, da sich das Modell durchweg als “feste” Formel betrachten lässt. Dieser Vorteil ist jedoch gleichermaßen eine Einschränkung, denn parametrische Verfahren sind eher dazu geeignet, einfachere Zusammenhänge (mit nicht all zu vielen Dimensionen) zu berechnen. Dafür läuft das Training und vor allem die Prädiktion bei parametrischen Verfahren sehr viel schneller ab, als es bei nicht-parametrischen Verfahren der Fall ist, immerhin müssen die Eingabewerte bei der Prädiktion nur in die Funktion mit bekannter Struktur eingefügt und ausgerechnet werden. Man kann sich also merken: Beim parametrischen Lernen stehen die Parameter vorher fest, beim Training werden nur die “richtigen” Werte für die Parameter gefunden.

Schlussendlich kann generell gesagt werden, dass parametrische Funktionen weniger Datenpunkte als nicht-parametrische Lernverfahren benötigen und bei weniger Daten bessere Ergebnisse liefern. Bei sehr großen Datenmengen werden parametrische Funktionen eher schlechter gegenüber nicht-parametrischen Verfahren und neigen etwas zur Unteranpassung.

Zu den parametrischen Lernverfahren gehören:

  • Lineare und nicht-lineare Regression
  • Lineare Diskriminazanalyse
  • Logistische Regression
  • Naive Bayes Klassifikation
  • einfache künstliche neuronale Netze (z. B. MLP)
  • lineare Support Vector Machines (SVM)

Nicht-parametrisierte Lernverfahren (nonparametric learning)

Spricht man vom nicht-parametrisierten Lernen, ist die Verwirrung eigentlich vorprogrammiert, denn es bedeutet keinesfalls, dass es keine Parameter gibt, ganz im Gegenteil! Nicht-parametrische Verfahren arbeiten in aller Regel mit sehr viel mehr Parametern als die parametrischen Verfahren. Und nicht-parametrische Verfahren sind häufig dann im Einsatz, wenn die Anzahl an Daten und Dimensionen sehr groß ist und wenn nicht klar ist, welche Dimensionen voneinander unabhängig sind, aber in Abhängigkeit mit dem Klassifikations-/Regressionsergebnis stehen.

Auch nicht-parametrische Lernverfahren entwickeln eine Funktion, die den Zusammenhang zwischen dem Input und dem Output beschreibt. Jedoch wird die Struktur der Funktion vor dem Training nicht konkret über eine bestimmte Anzahl an Parametern festgelegt. Die Anzahl an Parametern wird erst zur Laufzeit des Trainings bestimmt und hier könnte jede neue Zeile in der Tabelle der Trainingsdaten einen neuen Parameter bedeuten (also beispielsweise dazu führen, dass ein neuer Ast eines Entscheidungsbaumes entsteht – oder auch nicht!).

Die Modellstruktur wird nicht über eine Funktion mit festen Parametern festgelegt, sondern bei jeder Prädiktion aus den Daten ermittelt. Tendenziell neigen nicht-parametrisierte Verfahren etwas mehr zur Überanpassung als parametrisierte Verfahren.

Zu den nicht-parametrisierten Lernverfahren gehören:

  • k-nächste Nachbarn Klassifikation/Regression
  • Entscheidungsbaum Klassifikation/Regression
  • Nicht-lineare Support Vector Machines (RBF Kernel SVM)

Kleiner Abgleich des Verständnisses

Der Unterschied zwischen parametrisierten und nicht-parametrisierten Verfahren wird so häufig falsch verstanden, dass es sich lohnt, etwas Zeit in eine kleine Wiederholung zu investieren, jedoch aus der FAQ-Perspektive:

Warum ist die Regressionsanalyse ein parametrisiertes Lernverfahren?

Bei der klassischen Regressionsrechnung müssen wir noch vor dem Training festlegen, über welche Funktion wir trainieren wollen. Eine lineare Funktion wie y = x * a + b? Oder doch lieber eine nicht-lineare Funktion wie y = x² * a + x * b + c? Die Struktur der Funktion, mit der wir die Punktwolke beschreiben möchten und mit der wir dann im Nachgang Prädiktionen auf Basis von neuer x-Werte berechnen möchten, muss vor dem Training bestimmt werden.

Warum ist die k-nächste-Nachbarn-Bestimmung ein nicht-parametrisiertes Lernverfahren?

Hierbei handelt es sich um ein Lernen durch Ähnlichkeitsanalyse. Es werden gelabelte Datenpunkte gesammelt und erst bei der Prädiktion wird die multidimensionale Ähnlichkeit des neuen Datenpunktes mit den bekannten Datenpunkten bestimmt (Matrizen-Bildung über Distanzen zwischen den Datenpunkten im multidimensionalen Vektorraum). Das Modell lässt sich vorher nicht mal adäquat bestimmen.

Das Modell liegt sozusagen in den Daten. Der k-nächste-Nachbarn-Algorithmus (k-nN) zählt deshalb übrigens nicht nur zum nicht-parametrisierten Lernen, sondern ist darüber hinaus auch noch ein instanzbasiertes Lernen (Lazy Learning).

Warum sind Entscheidungsbäume nicht-parametrisierte Lernverfahren?

Entscheidungsbäume entwerfen Funktionen, die eine auf das Ergebnis bezogene Datenverteilung beschreiben. Jedoch wird vor der Entstehung dieses Modells (also vor dem Training) nicht die Anzahl der Parameter vorgegeben. Zwar ist es üblich, eine maximale Tiefe des Baumes vorzugeben (auch um Überanpassung zu vermeiden),  das Modell (die Struktur des Baumes) hängt jedoch von den Daten ab.

Warum ist Naive Bayes Klassifikation ein parametrisiertes Lernverfahren?

Naive Bayes Klassifikation gilt grundsätzlich als ein parametrisches Lernverfahren. Der Klassifikator errechnet eine Wahrscheinlichkeit, einer bestimmten Klasse zugehörig zu sein, über ein Produkt aus Wahrscheinlichkeiten des Auftretens voneinander (naive) unabhängiger Eingaben (x1, x2,… xn), in der Regel als multinominales Vokabular. Jede Eingabe (eindeutiges Element aus dem Vokabular) ist im Grunde eine Dimension und stellt einen Parameter dar, der im Vorfeld bekannt sein muss.

Es gibt allerdings auch Abwandlungen des Naive Bayes Klassifikators, bei denen mit Dichteschätzungen (1D Kernel Dichteschätzung) gerechnet wird, dann haben wir es wiederum mit Parametern zutun, die erst während der Trainingsphase entstehen.

Warum können Support Vector Machines sowohl parametrisierte als auch nicht-parametrisierte Lernverfahren darstellen?

Bei der linearen SVM werden die Werte der Parameter einer linearen Funktion (= feste Anzahl an Parametern) berechnet, die zwei Klassen linear trennt. Bei der nicht-linearen Klassentrennung funktioniert das leider nicht so einfach und es müssen kompliziertere Verfahren verwendet werden. Die bekannteste ist die Radial Basis Function Kernel-basierte SVM. Bei dieser RBF Kernel SVM wird eine Matrix über berechnete Distanzen zwischen den Datenpunkten erstellt und als Parameter verwendet. Da diese Parameter-Anzahl von den Daten abhängt, haben wir es mit einer nicht-parametrisierten Methode zutun (ähnlich wie beim k-nN).

Dario Zocholl

Data Science Survey by lexoro.ai

/3 Comments/in , , , , , /by

Ergebnisse unserer ersten Data Science Survey

Wie denken Data Scientists über ihre Skills, ihre Karriere und ihre Arbeitgeber? Data Science, Machine Learning, Künstliche Intelligenz – mehr als bloße Hype-Begriffe und entfernte Zukunftsmusik! Wir stecken mitten in massiven strukturellen Veränderungen. Die Digitalisierungswelle der vergangenen Jahre war nur der Anfang. Jede Branche ist betroffen. Schnell kann ein Gefühl von Bedrohung und Angst vor dem Unbekannten aufkommen. Tatsächlich liegen aber nie zuvor dagewesene Chancen und Potentiale vor unseren Füßen. Die Herausforderung ist es diese zu erkennen und dann die notwendigen Veränderungen umzusetzen.
Diese Survey möchte deshalb die Begriffe Data Science und Machine Learning einmal genauer beleuchten. Was steckt überhaupt hinter diesen Begriffen? Was muss ein Data Scientist können? Welche Gedanken macht sich ein Data Scientist über seine Karriere? Und sind Unternehmen hinsichtlich des Themas Machine Learning gut aufgestellt? Nun möchten wir die Ergebnisse dieser Umfrage vorstellen:



Link zu den Ergebnissen der ersten Data Science Survey by lexoro.ai

Interesse an einem Austausch zu verschiedenen Karriereperspektiven im Bereich Data Science/ Machine Learning? Dann registrieren Sie sich direkt auf dem lexoro Talent Check-In und ein lexoro-Berater wird sich bei Ihnen melden.

Redaktion

Pentaho User Meeting: Warum das CERN und die Bundespolizei auf Open Source setzen

/0 Comments/in , , /by

Anzeige

Was bewegt die größte Forschungsorganisation der Welt dazu, Open Source-Technologien einzusetzen? Wieso nutzt die Bundespolizei das offene Tool Pentaho Data Integration, um ihr Data Warehouse zu befüllen? Die Antworten geben die Anwender selbst auf dem Pentaho User Meeting am 6. März in Frankfurt.

Das CERN und die Bundespolizei sind nur zwei der Referenten, die auf dem Anwendertreffen ihre Datenprojekte vorstellen. Auf dem Pentaho User Meeting treffen sich seit Jahren alle Pentaho-Anwender aus dem deutschsprachigen Raum. Da spielt es keine Rolle, ob das Datenprojekt schon seit Jahren läuft oder noch nicht mal begonnen hat. Ob Newbie oder Professional – wer sich täglich mit Unternehmensdaten beschäftigt, ist auf dem User Meeting willkommen.

Das Pentaho User Meeting findet am 6. März von 10.00 bis 18.00 Uhr statt. Die Teilnahme ist kostenlos, aus Organisationsgründen (Raum, Catering) wird um eine Anmeldung gebeten. Anmelden können Sie sich hier.

Alles dreht sich um die Aufbereitung und Analyse von Daten

Das Pentaho User Meeting findet seit 2014 statt und dient dem Erfahrungs- und Wissensaustausch beim Einsatz mit der Data Analytics- und Big Data-Plattform Pentaho. Jeder Anwender ist herzlich eingeladen, sein Projekt oder Eigenentwicklung vorzustellen. In den letzten Jahren nahmen ca. 100 Anwender am Treffen teil, unter den Referenten waren u.a. Bosch, Swissport, Deutsche See und Wiener Wohnen Kundenservice.

Am 6. März wird es unter anderem um diese Themen gehen:

  • Realtime Analytics bei der Bundespolizei
  • Pentaho in einer Kubernetes-Verwaltung beim Fondsverwalter Netfonds
  • Migration von Reports von Business Objects auf Pentaho im CERN
  • Datei-Handling mit Pentaho Data Integration bei der Kapitalgesellschaft Hansainvest
  • Vorhersagemodelle für Predictive Analytics
  • IoT Analytics Use Case: das Smart Trains-Projekt von Virgin und Hitachi
  • SAP-Daten mit Pentaho integrieren und analysieren
  • Service Management Analytics: 360 Grad-Blick auf IT Services

Interviews mit den Referenten finden Sie hier.

Für Networking und Gespräche mit den Referenten und Anwendern bleibt in den Pausen genügend Zeit. Nach Abschluss der Veranstaltung laden wir alle Teilnehmer herzlich zu einem Get together bei Pizza und Bier ein! Alle Informationen zum Event, die Agenda und Anmeldung finden Sie hier.

Ps.: Aktuelle Updates zum Event gibt es auf Twitter unter #PUM18

Editorial Staff

New Sponsor: Cloudera

/1 Comment/in , /by

Dear readers,

we have good news: We welcome Cloudera as our new Data Science Blog Sponsor! Cloudera is one of the most famous platform and solution provider for big data analytics and machine learning. This also means editorial contributions by Cloudera for at least one year.

At Cloudera, we believe that data can make what is impossible today, possible tomorrow. We empower people to transform complex data into clear and actionable insights. We deliver the modern platform for machine learning and analytics optimized for the cloud. The world’s largest enterprises trust Cloudera to help solve their most challenging business problems.

Learn more about our new sponsor at cloudera.com.