#

Forecast Komponenten

Der Kern der Forecast API sind die Datenverarbeitungs und -visualisierungs Komponenten. Anbei weitere Ãberlegungen zu den Komponenten. Anbei habe ich auch schon einen Projektnamen gefunden.

Projektname

Ursprünglich sollte das Projekt „Dat Orakel vun Kölle“ heissen :). Dieser Name ist jedoch bei der Packetbenennung unter Java nicht sehr vorteilhaft. Als habe ich mich im Umkreis der Orakel-Mythologie etwas umgeschaut und bin auf den schönen Namen „Pythia“ gestoÃen. Er entstammt der griechischen Mythologie um das Orakel von Delphi und ist der Name der Priesterin in Delphi, welche die Voraussagen durch die Macht Apollos kund tat. Dennoch möchte ich zumindest als Untertitel den Namen „Dat Orakel vun Kölle“ beibehalten.

Komponenten Lebenszyklus

Da die Daten einer Komponente von mehreren weiteren Komponenten parallel benutzt werden können, müssen diese als nebenläufige Prozesse umgesetzt werden. Entsprechend gibt es einen Komponenten Lebenszyklus:

  • Unconnected
    In diesem Zustand wurde eine Komponente erzeugt, besitzt jedoch noch keine Verbindung zu anderen Komponenten und ist entsprechend inaktiv.
  • Waiting
    In diesem Zustand wurde eine Komponente mit anderen Komponenten verbunden und wartet nun auf diejenige Komponente, welche ihr Daten liefert. Komponenten, die als Datenquelle dienen, wie z.B. Datenbankzugriffe oder Dateien, können diesen Zustand überspringen.
  • Calculating
    In diesem Zustand befindet sich eine Komponente, nachdem eine datenliefernde vorgeschaltete Komponente ihre Daten freigegeben hat. In diesem Zustand befinden sich Komponenten, welche gerade eine Berechnung durchführen. Ihre Daten stehen zu diesem Zeitpunkt anderen Komponenten noch nicht zur Verfügung. Visualisierende Komponenten können diesen Zustand dafür benutzen, um ihre Darstellung zu erzeugen. Datenquellen können hier die Daten aus einer externen Quelle lesen und validieren.
  • Ready
    In diesem Zustand hat eine Komponente alle benötigten Berechnungen durchgeführt und stellt nun ihre verarbeiteten Daten und Parameter den nächsten Komponenten zur Verfügung.
  • Der Zustandswechsel kann entsprechend dem folgenden Diagramm gewechselt werden.

    unconnected --[connect]--> waiting 
    
    waiting --[dependent Component ready]--> calculating 
    
    calculating --[calculations done]--> ready
    
    ready --[parameter change]--> waiting
    
    ready / waiting --[disconnect]--> unconnected
    
    calculating / ready --[reset]--> waiting
    

    Einige Komponenten, wie etwa die PCA oder ein Regressor, werden auf zwei verschiedenartige Datenmengen angewendet. Eine Datenmenge, die Trainingsmenge, dient dazu, die internen Parameter, wie etwa die Regressionsfunktion, zu bestimmen. Die zweite Menge, die Validierungsmenge, wird lediglich benutzt, um durch die Regressionsfunktion berechnet zu werden. Die Validierungsmenge entspricht in ihrer Funktion einer Datenmenge, welche zu einem weiteren Zeitpunkt durch das Modell prognostiziert werden soll.
    Allgemein muss die API zwei Modi unterstützen: Das Trainieren, als das Bestimmen der internen Parameter, und die Evaluierung des Modells auf weitere Daten. Die Vorverarbeitung der Daten wird auf beide Datenmengen angewendet. Bei der Evaluierung werden jedoch die internen Zustände der berechnenden Komponenten nicht mehr geändert.

    Datenbank Komponente

    Diese Komponete ermöglicht es aus einer Tabelle / View eine oder mehrere Spalten auszuwählen und diese nach einer gegebenen Spalte zu sortieren. Ãblicherweise sollte die Sortierspalte vom Typ Datum sein, damit jedem Datensatz ein Zeitpunkt zugeordnet werden kann. Liegen die Daten in einem äquidistanten Zeitraster zur Verfügung, so reicht die Angabe des ersten Zeitpunktes und des Zeitrasters aus. Die DB Komponente soll es dem Benutzer auch ermöglichen, einen beliebigen JDBC-Treiber zu benutzen.

    Flussblockierende Komponenten

    Einige Komponenten, wie etwa ein Optimierer, können den Datenfluss der überwachten Komponente blockieren. So kann ein Optimierer für die Kompression durch eine PCA die Ausgabe der PCA solange blockieren, bis die PCA durch den Optimierer in geeigneter Weise konfiguriert wurde. Entsprechend ist bei den Komponenten der Zustand „ready“ erst dann zu erreichen, wenn ihre blockierende Komponente ebenfalls den Zustand „ready“ erreicht hat. Daher müssen Komponenten in blockierende und nicht blockierende Komponenten unterteilt werden. Die blockierenden Komponenten erhalten von der blockierten Komponente als erste das „ready“-Signal. Erst wenn die blockierende Komponente ebenfalls den Zustand „ready“ erreicht, dürfen nicht blockierende Komponenten ein „ready“ Signal erhalten.

    Leave a Reply »»

    Note: All comments are manually approved to avoid spam. So if your comment doesn't appear immediately, that's ok. Have patience, it can take some days until I have the time to approve my comments.