DE112016005870T5

DE112016005870T5 - Such- und retrieval-datenverarbeitungssystem zum berechnen von nahezu-echtzeit-datenaggregationen

Info

Publication number: DE112016005870T5
Application number: DE112016005870.5T
Authority: DE
Inventors: John MacLean; Paul Veiser
Original assignee: Ab Initio Technology LLC
Current assignee: Ab Initio Technology LLC
Priority date: 2015-12-21
Filing date: 2016-12-20
Publication date: 2018-09-06
Also published as: US11989096B2; JP7082961B2; WO2017112697A1; SG11201804482UA; JP6609052B2; CA3009062A1; EP3798870A1; EP3394772A1; AU2016378560B2; CN108780466B; JP2019507403A; AU2016378560A1; EP3394772B1; US20170177446A1; JP2020030842A; EP3798870B1; SG10202000071TA; CA3009062C; CN108780466A; CN117194492A

Abstract

Ein Verfahren, das von einem Datenverarbeitungssystem zum Verarbeiten von Daten durchgeführt wird, wobei das Verfahren Folgendes umfasst: das intermittierende Empfangen von Daten aus einem oder mehreren Datenströmen, wobei die empfangenen Daten Datensätze umfassen; das Erfassen von zwei oder mehr bestimmten Datensätzen in den empfangenen Datensätzen, wobei die erfassten zwei oder mehr bestimmten Datensätze jeweils eine bestimmte Kennung umfassen; für diese bestimmte Kennung, das Erstellen einer Sammlung von Datensätzen; für mindestens einen bestimmten, in der Sammlung von Datensätzen enthaltenen Datensatz, das Durchsuchen von Datensätzen für die Aggregation einer Datenhistorie; und das Berechnen von kombinierten Daten; das Modifizieren eines Datensatzes durch Einfügen der kombinierten Daten in ein Feld des Datensatzes und durch das Einfügen von Daten aus mindestens einem der Datensätze in der Sammlung in ein anderes Feld des Datensatzes; basierend auf dem Anwenden der Regeln, das Schreiben eines oder mehrerer Befehle zum Initiieren einer oder mehrerer Aktionen in den Speicher.

Description

GEBIET DER TECHNIK
Diese Beschreibung betrifft Verfahren und Datenstrukturen, die besonders geeignet sind, Daten aus in einem Netzwerk verteilten Datenquellen abzurufen.
ALLGEMEINER STAND DER TECHNIK
In einem Beispiel aggregieren Systeme, die Anwendungen ausführen, Daten durch Abrufen von Daten, die in einem Data Warehouse (z.B. einem Data Warehouse das sich auf logistische Hubs, verteilte Maschinen, mobile Kommunikation oder Einzelhandelsgeschäfte bezieht) gespeichert sind, und aggregieren diese Daten im Batch. Diese Anwendungen werden oft als Batch-Anwendungen bezeichnet, da sie empfangene Daten (im Batch) in einem Data Warehouse speichern und diese dann aus dem Data Warehouse abrufen, um eine Aggregation zu berechnen, was während die Daten aggregiert werden zu einer Latenzzeit führt. Darüber hinaus haben diese Anwendungen aufgrund der großen Datenmengen Schwierigkeiten mit dem Aggregieren von Echtzeitdaten (und/oder den ausgelagerten Daten).
Bezugnehmend auf 1A umfasst die Umgebung 2 verschiedene Anwendungen (z.B. Engines), um verschiedene Arten von Anwendungen gegen Batch-Daten zu implementieren. In diesem Beispiel werden Daten aus den Datenquellen 3 im Enterprise Data Warehouse (EDW) 4 gespeichert. Die Logistikanwendungen 5a, 5b, 5c, 5d (die jeweils unterschiedliche Operationen, Regeln oder Anwendungen implementieren) rufen jeweils einzeln für diese Anwendung geeignete Daten aus dem EDW 4 ab. Jede dieser unterschiedlichen Anwendungen 5a, 5b, 5c, 5d wirkt auf unterschiedliche Datenarten und Datenströme ein und ruft somit die geeigneten Daten aus dem EDW 4 ab. Jede dieser unterschiedlichen Anwendungen 5a, 5b, 5c, 5d kann viele Operationen, Regeln und Anwendungen ausführen. Jede Anwendung nutzt denselben allgemeinen Workflow.
In einem anderen Beispiel ermöglicht es eine Benutzerschnittstelle für Regeln, wie sie z.B. in dem US-Patent 9,002,770 beschrieben ist, einem Benutzer (beispielsweise einem Benutzer), eine Regel (z.B. SMS-Verbrauch > 40) zur Verwendung in einer Anwendung zu definieren, ohne Computercode schreiben zu müssen, um für das Abrufen von Daten, die für die Regel relevant sind, auf entsprechende Datensätze in einer Datenbank zuzugreifen. Wenn ein Benutzer eine Anwendung definiert, schreibt er/sie im Allgemeinen Regeln (z.B. in eine Kalkulationstabelle) und sendet dann die Kalkulationstabelle an einen Computerprogrammierer, um den Code zum Implementieren der Regel zu schreiben. Mit der Benutzerschnittstelle für Regeln kann der Benutzer einfach in der Benutzerschnittstelle z.B. eine Regel auswählen (oder ein Symbol, das eine Regel repräsentiert) und einen Wert oder eine Bedingung für diese Regel angeben. Das System ist so konfiguriert, dass es die Befehle, die erforderlich sind, um die von dem Ereignis angegebenen Daten abzurufen, generiert. Über die Benutzerschnittstelle für Regeln kann der Benutzer die Regeln bearbeiten, ohne dass ein Programmierer die Regeln bearbeiten muss.
KURZDARSTELLUNG
In einigen Beispielen umfasst ein von einem Datenverarbeitungssystem zum Verarbeiten von Daten durchgeführtes Verfahren das intermittierende Empfangen von Daten aus einem oder mehreren Datenströmen, wobei die empfangenen Daten Datensätze enthalten; wenn weiterhin Daten aus dem Datenstrom oder den Datenströmen empfangen werden, das Erfassen von zwei oder mehr bestimmten Datensätzen in den empfangenen Datensätzen, wobei die erfassten zwei oder mehr bestimmten Datensätze jeweils eine bestimmte Kennung umfassen; für diese bestimmte Kennung das Erstellen einer Sammlung von Datensätzen, welche die erfassten zwei oder mehr bestimmten Datensätze umfassen; für mindestens einen bestimmten, in der Sammlung von Datensätzen enthaltenen Datensatz das Durchsuchen von Datensätzen für eine historische Aggregation von der jeweiligen Kennung zugeordneten Daten, wobei die historische Aggregation eine vorausberechnete Datenaggregation aus einer vorangegangenen Zeitspanne ist; und das Berechnen kombinierter Daten basierend auf dem mindestens einen bestimmten Datensatz und der historischen Aggregation; das Modifizieren eines Datensatzes durch Einfügen der kombinierten Daten in ein Feld des Datensatzes und durch das Einfügen von Daten aus mindestens einem der Datensätze in der Sammlung in ein anderes Feld des Datensatzes; das Verarbeiten des modifizierten Datensatzes durch Anwenden einer oder mehrerer Regeln auf den modifizierten Datensatz; basierend auf dem Anwenden der Regeln, das Schreiben eines oder mehrerer Befehle zum Initiieren einer oder mehrerer Aktionen in den Speicher und das Veröffentlichen des einen oder der mehreren Befehle in eine Warteschlange zum Initiieren der einen oder mehreren Aktionen. Ein System aus einem oder mehreren Computern kann dazu konfiguriert sein, bestimmte Operationen oder Aktionen durchzuführen, indem Software, Firmware, Hardware oder eine Kombination aus diesen in dem System installiert sind, die das System im Betrieb veranlasst oder veranlassen, die Aktionen auszuführen. Ein oder mehrere Computerprogramme können so konfiguriert sein, dass sie bestimmte Operationen oder Aktionen ausführen, indem sie Befehle enthalten, die, wenn sie von der Datenverarbeitungsvorrichtung ausgeführt werden, bewirken, dass die Vorrichtung die Aktionen ausführt.
Bei diesem Aspekt umfasst das Einfügen der Daten aus dem mindestens einen der Datensätze in der Sammlung in das andere Feld des Datensatzes: das Einfügen von Daten aus dem mindestens einen bestimmten in der Sammlung enthaltenen Datensatzes in das andere Feld des durch Einfügen modifizierten Datensatzes. Die Sammlung von Datensätzen ist ein erster Datensatz, der Daten aus den Datensätzen enthält und wobei das Verfahren ferner Folgendes umfasst: das Sammeln einer Vielzahl von Datensätzen; das Veröffentlichen der Datensätze in eine einzige Warteschlange; das Erfassen der zwei oder mehr bestimmten Datensätze aus der Warteschlange; das Zusammenfügen der zwei oder mehr bestimmten Datensätze in den ersten Datensatz, wobei die zwei oder mehr bestimmten Datensätze Daten umfassen, die unterschiedliche Arten von Ereignissen darstellen; und das Ergänzen des ersten Datensatzes mit den kombinierten Daten für den mindestens einen bestimmten Datensatz. Die vorangegangene Zeitspanne ist eine Zeitspanne vor dem Durchführen des Erfassens. Die Aktionen umfassen das Anhängen, von Kundenprofildaten für einen Kunden, der einem bestimmten Ereignis, das in dem ersten Datensatz enthalten ist, zugeordnet ist, an den ersten Datensatz und das Anhängen einer anhängbaren Suchdatei („appendable lookup file“, ALF) mit einer historischen Aggregation für das bestimmte Ereignis an den ersten Datensatz.
Bei diesem Aspekt umfasst das Berechnen der kombinierten Daten: das Hinzufügen von inkrementellen Daten zu der historischen Aggregation, wobei die inkrementellen Daten Daten von einem Zeitpunkt, zu dem die historische Aggregation berechnet wurde, bis zu einem nahezu gegenwärtigen Zeitpunkt, der innerhalb einer Minute vor dem gegenwärtigen Zeitpunkt liegt, umfassen und basierend auf dem Hinzufügen der inkrementellen Daten das Herstellen einer Nahezu-Echtzeit-Aggregation der Daten. Das Verfahren nach Anspruch 1, ferner umfassend: das Empfangen von Daten von einer Client-Vorrichtung eines Benutzers, die eine oder mehrere Regeln, die eine Anwendung definieren, darstellen; basierend auf den empfangenen Daten das Generieren der einen oder mehreren Regeln, welche die Anwendung definieren und basierend auf dem Ausführen der einen oder mehreren Regeln, das Implementieren der Anwendung gegen den intermittierend empfangenen Datenstrom bzw. die intermittierend empfangenen Datenströme. Das Empfangen des einen oder der mehreren Datenströme umfasst: das Empfangen eines ersten Datenstroms mit Daten, die ein Ereignis einer ersten Art darstellen, und das Empfangen eines zweiten Datenstroms mit Daten, die ein Ereignis einer zweiten Art darstellen.
Bei diesem Aspekt: das Ausführen einer oder mehrerer Anwendungen gegen einen veröffentlichten Aktionsauslöser, der in dem einen oder den mehreren Befehlen enthalten ist. ein Datensatz ein Ereignis enthält. Das Suchen umfasst das Suchen in einem Daten-Repository oder das speicherinterne Suchen.
Das Obengenannte kann insgesamt oder teilweise als ein Computerprogrammprodukt implementiert werden, das Befehle enthält, die gespeichert sind auf einem oder mehreren nichtflüchtigen maschinenlesbaren Speichermedien und/oder einem oder mehreren computerlesbaren Hardware-Speichergeräten, die eine Festplatte, eine Direktzugriffsspeichervorrichtung, wie etwa ein dynamischer Direktzugriffsspeicher, maschinenlesbare Hardware-Speichervorrichtungen und andere Arten von nichtflüchtigen maschinenlesbaren Speichervorrichtungen sind, und die auf einer oder mehreren Verarbeitungsvorrichtungen ausführbar sind. Das Obengenannte kann insgesamt oder teilweise als eine Vorrichtung, ein Verfahren oder ein elektronisches System implementiert werden, die bzw. das eine oder mehrere Verarbeitungsvorrichtungen und Speicher zum Speichern von ausführbaren Befehlen zum Implementieren der genannten Funktionen umfassen kann.
Die Details von einer oder mehreren Ausführungsformen sind in den begleitenden Zeichnungen und der nachfolgenden Beschreibung dargelegt. Andere Merkmale, Ziele und Vorteile der hierin beschriebenen Techniken werden aus der Beschreibung und den Zeichnungen und aus den Ansprüchen ersichtlich.
Figurenliste

Die 1A ist eine graphische Darstellung verschiedener Engines, die auf Batch-Daten in verschiedenen Datenströmen einwirken.
Die 1B ist eine graphische Darstellung einer Engine, die verschiedene Anwendungen implementiert und auf Batch- und Echtzeitdaten einwirkt.
Die 1C ist eine graphische Darstellung der Echtzeitausführung mit einem umfassenden Datensatz.
Die 2 ist ein graphische Darstellung eines Systems zum Berechnen von Nahezu-Echtzeit-Ereignisaggregationen.
Die 3 ist ein Beispiel für einen Ereignisdatensatz.
Die 4 ist eine graphische Darstellung eines Datenflussgraphen.
Die 5 bis 14 sind beispielhafte grafische Benutzerschnittstellen aus einer Ereignispalette.
Die 15 und 17 sind jeweils ein Ablaufdiagramm.
Die 16 ist eine graphische Darstellung des Berechnens von Nahezu-Echtzeit-Ereignisaggregationen.

BESCHREIBUNG
Ein mit dieser Offenbarung übereinstimmendes System empfängt intermittierend (z.B. periodisch oder kontinuierlich) Daten aus verschiedenen Datenquellen. Während die Daten intermittierend empfangen werden, sammelt das System die Daten in einem einzigen Datenstrom (z.B. durch mehrfaches Veröffentlichen der empfangenen Daten in eine Warteschlange) und fügt die Daten in Nahezu-Echtzeit (z.B. in einer Millisekunde, zwei Millisekunden etc.) zu einem einzigen, umfassenden Datensatz zusammen, z.B. durch Generieren eines umfassenden Datensatzes, der die mehrfach in die Warteschlange veröffentlichten Daten enthält. Die Daten werden in Nahezu-Echtzeit aus den Datenquellen gesammelt und nicht (im Batch) aus einem Data Warehouse abgerufen. Diese gesammelten Daten umfassen Ereignisse, einschließlich beispielsweise eines Datensatzes, der Daten enthält, die das Auftreten einer Aktion anzeigen (z.B. das Ausführen eines Sprachanrufs oder die Dauer eines Sprachanrufs) oder Daten, die das Auftreten einer Aktion anzeigen. Durch das Zusammenführen der Daten aus diesen verschiedenen Datenquellen umfasst der umfassende Datensatz unterschiedliche Arten von Ereignissen (z.B. Short Message Service (SMS)-Ereignisse, Sprachereignisse, Datenereignisse etc.). Das System reichert diesen umfassenden Datensatz mit Ereignisaggregationen, Nichtereignis-Daten, Statusdaten und verschiedene Dimensionen, wie z.B. Kundendaten (z.B. ein Kundenprofil), Kontodaten etc., an.
Im Allgemeinen umfasst eine Dimension Daten, die sich auf eine Entität beziehen (z.B. einen Kunden, einen Händler etc.), die mit einem Ereignis verknüpft ist. Im Allgemeinen umfasst eine Ereignisaggregation Daten, die eine Menge eines in der Aggregation über einen bestimmten Zeitraum aufgetretenen Ereignisses anzeigen. Nichtereignis-Daten umfassen im Allgemeinen Daten, die ein Nichtauftreten eines Ereignisses anzeigen. Beispielsweise können Nichtereignis-Daten eine Zeitspanne angeben, die vergangen ist, seit ein Benutzer zuletzt eine Text- oder SMS-Nachricht gesendet hat. Statusdaten umfassen im Allgemeinen Daten, die einen Status (z.B. eine Weiterentwicklung) einer bestimmten Anwendung (z.B. einer Kampagne), Implementierung oder Ausführung anzeigen.
Das System ermöglicht das Ausführen mehrerer, unterschiedlicher Anwendungen auf mehreren Ebenen (z.B. auf der Ebene eines Abonnenten (Kunden), eines Händlers (Einzelhändlers) etc.), gegen einen einzigen umfassenden Datensatz, anstatt dass jede Anwendung, bzw. jede Art von Ebene gegen Daten ausgeführt wird, die im Batch aus einem Daten-Repository abgerufen werden. In diesem Beispiel repräsentiert jede dieser Ebenen eine bestimmte Art von Entität, wie beispielsweise einen Abonnenten eines Mobilgeräts, einen Händler für Mobilgeräte etc. Um diese „any event“-Anwendungen zu erstellen, umfasst das System eine Ereignispalette, die eine Schnittstelle für einen Benutzer (z.B. einen Benutzer) umfasst, um auf eine Sammlung von vordefinierten Ereignissen, Ereignisaggregationen, Nichtereignissen und Anwendungszuständen zuzugreifen und diese anzuzeigen, die bei der Definition einer Reihe von Regeln (z.B. Regeln) verwendet werden können (z.B. durch eine Regelumgebung einschließlich einer Benutzerschnittstelle für Regeln). Das heißt, die Ereignispalette legt eine bestimmte Anordnung von Ereignissen und Daten fest, sodass die Benutzerschnittstelle für Regeln verwendet werden kann, um geeignete Regeln, die diese Ereignisse enthalten oder auf diesen Ereignissen basieren, zu erstellen. Beispielsweise kann die Ereignispalette (z.B. von der Regelumgebung zur Definition von Regeln) dazu verwendet werden, für ein Programm eine Regel zu definieren, die festlegt, dass, wenn ein Kunde zwanzig SMS-Nachrichten gesendet hat, dem Kunden ein Guthaben von fünf Dollar zur Verfügung gestellt wird. In diesem Beispiel kann der Benutzer beim Definieren der Regel eine Ereignisaggregation für SMS-Nachrichten verwenden. Da die Ereignispalette eine Reihe von Ereignissen und Ereignisaggregationen enthält, die für verschiedene Arten von Anwendungen auf verschiedenen Ebenen und für unterschiedliche Arten von Ereignissen verfügbar sind, kann ein Benutzer mithilfe der Ereignispalette mehrere, unterschiedliche Arten von Anwendungen, die jeweils mehrere Arten von Ereignissen umfassen, erstellen. In diesem Beispiel generiert das System einen Ereignisdatensatz, der Werte für alle Ereignisse (oder mindestens einen Teil der Ereignisse) enthält, die in der Ereignispalette definiert sind. In einem Beispiel sind die in der Ereignispalette definierten Werte von Ereignissen in Unterdatensätzen (z.B. einem Datensatz, der in einem Datensatz enthalten ist) in dem Ereignisdatensatz aufgenommen. Beispielsweise definiert die Ereignispalette Abonnentenprofil-Ereignisse, die in einem Profil-Unterdatensatz im Ereignisprotokoll gespeichert sind. In einem Beispiel ist der Ereignisdatensatz ein umfassender Datensatz aller Ereignisse, die in der Ereignispalette enthalten sind. In diesem Beispiel enthält der Ereignisdatensatz einen Datensatz mit Einzeldaten.
Durch das Ausführen einer Anwendung gegen einen vorbelegten (oder vorproduzierten) Ereignisdatensatz ermöglicht das System verglichen mit der Verarbeitungszeit, die erforderlich wäre, wenn das System die Daten, gegen welche die Anwendung ausgeführt wird, aus einem Data Warehouse oder einer Datenbank abrufen müsste, eine schnellere Verarbeitung von Anwendungen in Echtzeit und mit Echtzeitdaten. Dieser Prozess des Generierens der Ereignisdatensatzes führt zu einer Denormalisierung von Daten, bei dem die gleichen Daten gezielt über mehrere Datensätze verteilt werden (z.B. die Ereignisdatensätze, Datenbankeinträge, welche die Daten speichern, etc.). Die Denormalisierung der Daten sorgt für eine erhöhte Verarbeitungsgeschwindigkeit bei der Anwendungsausführung, da das System keine Datenbankabfrage zum Abrufen der Daten mehr ausführen muss.
Um eine Echtzeitausführung einer Anwendung mit Ereignissen in der Ereignispalette gegen Echtzeit-Datenströme zu ermöglichen, generiert das System einen umfassenden Datensatz aller Ereignisse in der Ereignispalette, um eine Latenzzeit zu verringern, die mit der Durchführung von Datenbankabfragen für relevante Daten während der Ausführung der Anwendung verbunden ist, und um eine Latenzzeit zu verringern, die mit der Durchführung von Anreicherungen während der Anwendungsausführung verbunden ist (z.B. Berechnen von Aggregationen während der Anwendungsausführung).
Vielmehr wird für jedes im Echtzeit-Datenstrom empfangene Ereignis ein Ereignisdatensatz vorab erstellt, der die vollständige Ereignispalette und Anreicherungen (z.B. Echtzeit-Aggregationen) enthält, und der Ereignisdatensatz wird in einer Warteschlange zur Anwendungsausführung veröffentlicht, wodurch „any event“-Anwendungen mit Mehrfachereignissen generiert werden, die eine geringe Latenzzeit aufweisen und die Anwendung unabhängig von Datenbankabfragen und Lookups ausgeführt werden kann. Zusätzlich bietet das System durch das Generieren dieses einzelnen Datensatzes (z.B. des umfassenden Datensatzes), der alle Ereignisse (die einem bestimmten Schlüssel oder einer Kennung zugeordnet sind) enthält, eine erhöhte Flexibilität, da der Datensatz auf alle Engines und Anwendungen angewendet werden kann, anstatt dass für jede Anwendung eine Datenbankabfrage und ein Datenbankabruf durchgeführt werden müssen. In einem Beispiel umfasst dieser Schlüssel oder diese Kennung einen Benutzeridentifikationsschlüssel (ID-Schlüssel). In diesem Beispiel sammelt und gruppiert das System anhand von Benutzer-ID-Schlüsseln alle Ereignisse für einen bestimmten Benutzer. Darüber hinaus bietet dieses System eine erhöhte Flexibilität, da die Engines nicht vorkonfiguriert werden müssen, um bestimmte Datenarten von einem EDW abzurufen und/oder bestimmte Felder in Datensätzen in einer EDW abzufragen. Vielmehr generiert das System den umfassenden Datensatz (der alle Ereignisse enthält, die einem bestimmten Schlüssel, wie z.B. dem oben beschriebenen Benutzer-ID-Schlüssel zugeordnet sind) und kann dann die Anwendungen oder Engines gegen die Daten in dem umfassenden Datensatz ausführen, sodass die Ausführung der Anwendung auf der Grundlage der in dem umfassenden Datensatz enthaltenen Daten „on the fly“ erfolgen kann.
Bezug nehmend auf die 1B empfängt das System 6 Daten aus den Datenquellen 7, (z.B. in einem Netzwerk verteilten Datenquellen) und implementiert den Sammelprozess 9, um die Daten z. B. durch Mehrfachveröffentlichen der Daten in eine Warteschlange in einem einzigen Datenstrom zu sammeln. Wie weiter unten näher beschrieben generiert das System 6 aus den Daten, die in der Warteschlange mehrfach veröffentlicht sind, einen umfassenden Datensatz von Ereignissen, die in den Daten enthalten sind. In diesem Beispiel sammelt das System 6 die Daten in Nahezu-Echtzeit während die Daten aus den Datenquellen 7 (z.B. Datenquellen im Zusammenhang mit Logistikzentren, verteilten Maschinen, Mobilkommunikation oder Einzelhandelsgeschäften) empfangen werden. Im Rahmen der Sammlung speichert das System 6 die Daten (oder einen Teil der Daten) in dem EDW 8. Die Sammlung der Daten selbst erfolgt in Nahezu-Echtzeit-Daten, da die Daten beispielsweise aus den Datenquellen 7 empfangen werden, anstatt anschließend aus einem Data Warehouse abgerufen zu werden. Da der umfassende Datensatz aus diesen gesammelten Daten (und nicht aus Daten, die von einem Data Warehouse abgerufen werden) generiert wird, wird der umfassende Datensatz in Nahezu-Echtzeit generiert und aktualisiert, während die Daten gesammelt werden. Das System 6 umfasst außerdem die Erfassungs- und Aktions-Engines 10 zum Anwenden von Regeln auf die gesammelten Daten (z. B. die Daten in dem umfassenden Datensatz), die erfassen, dass ein oder mehrere Teile der gesammelten Daten eine oder mehrere Bedingungen der Regeln erfüllen, und geeignete Aktionen ausführen. In diesem veranschaulichenden Beispiel führen die Erfassungs- und Aktions-Engines 10 Regeln für die Anwendungen 11a, 11b, 11c, 11d aus, bei denen es sich um unterschiedliche Arten von Anwendungen handelt. Jede der Anwendungen 11a, 11b, 11c, 11d kann als Datenflussgraph, der über eine Umgebung zur Definition von Regeln konfiguriert wird, implementiert werden. Da die Erfassungs- und Aktions-Engines 10 gegen einen einzigen umfassenden Datensatz ausgeführt werden, sind die Erfassungs- und Aktions-Engines 10 in der Lage, verschiedene unterschiedliche Anwendungen 11a, 11b, 11c, 11d gegen einen Datenstrom (z.B. den umfassenden Datensatz) zu implementieren, anstatt unterschiedliche Engines gegen unterschiedliche Datenströme, die jeweils für die unterschiedlichen Anwendungen geeignet sind, auszuführen.
Bezugnehmend auf 1C verwendet die ereignisbasierte Anwendung 12 bei ihrer Ausführung einen umfassenden Datensatz, der unter Verwendung der oben beschriebenen Techniken generiert wird. In diesem Beispiel gibt die Anwendung 12 basierend auf Ereignissen, die für einen oder mehrere bestimmte Abonnenten in dem Ereignisdatensatz enthalten sind, verschiedene Ereignisauslöser und Aktionen vor. Die Anwendung 12 enthält verschiedene Entscheidungspunkte (z.B. „Hat ein Abonnent 50 SMS-Nachrichten verbraucht?“). Für einen bestimmten Abonnenten den die Anwendung erwartet, entscheiden die Erfassungs- und Aktions-Engines 10 anhand der im Ereignisdatensatz für den Abonnent enthaltenen Ereignisse (oder anhand von deren Nichtvorhandensein) und anhand des Status eines Abonnenten in der Anwendung (z.B. „Anwendungsstatus“), welcher Zweig der Anwendung 12 durchlaufen werden soll. Im Allgemeinen bezieht sich der Anwendungsstatus auf eine bestimmte Komponente (beispielsweise einen bestimmten Ereignisauslöser oder eine bestimmte Aktion), zu dem bzw. zu der ein Abonnent während der Ausführung der Anwendung übergegangen ist. Beispielsweise gibt der Anwendungsstatus an, welcher Ereignisauslöser oder welche Aktion in einer Anwendung gerade für einen bestimmten Abonnent ausgeführt wird. In einigen Beispielen warten die Erfassungs- und Aktions-Engines 10 während bestimmter Zeitspannen, bevor sie eine Verzweigung in der Anwendung 12 auswählen. Durch das Warten während dieser vorgegeben Zeitspannen analysieren die Erfassungs- und Aktions-Engines 10 neue Ereignisse, die in den Ereignisdatensätze eingefügt werden.
In diesem Beispiel enthält die Anwendung 12 den Ereignisauslöser 19, der vorgibt, dass bei der Aktivierung des Dienstes für einen bestimmten Abonnenten die Erfassungs- und Aktions-Engines 10 die Initiierungsaktion 20 zur Überwachung einer Menge der von dem bestimmten Abonnenten in zwei Tagen verbrauchten SMS-Nachrichten ausführt. Der Ereignisauslöser 19 ist in diesem Beispiel eine aufschiebende Bedingung für eine Regel, die von der Anwendung 12 ausgeführt wird. Bei Erfüllung des Ereignisauslösers 19 führen die Erfassungs- und Aktions-Engines 10 die Initiierungsaktion 20 aus. Die Erfassungs- und Aktions-Engines 10 ermitteln, wann ein bestimmter Abonnent den Ereignisauslöser 19 erfüllt, indem sie ein Aktivierungsereignis in dem umfassenden Datensatz erfassen, und ermitteln einen dem Aktivierungsereignis zugeordneten Abonnenten über die Abonnenten-ID.
Wenn der Abonnent in diesem Beispiel mindestens fünfzig SMS-Nachrichten in den letzten zwei Tagen konsumiert hat, (wie z.B. durch eine SMS-Verbrauchs-Ereignisaggregation in dem Ereignisdatensatz vorgegeben), wird der Ereignisauslöser 13 ausgeführt. Der Ereignisauslöser 13 führt die vorgeschlagene Aufladeaktion 14 aus, die dazu führt, dass die Erfassungs- und Aktions-Engines 10 diesen bestimmten Abonnenten dazu veranlassen, aufzuladen. Wenn der Abonnent eine Aufladevorgang ausführt, wird der Eintrag in dem Ereignisdatensatz für diesen bestimmten Abonnenten mit einem Ereignis aktualisiert, das den Aufladevorgang repräsentiert. Dieses Aktualisieren des Ereignisdatensatzes bewirkt, dass die Anwendung 12 den Ereignisauslöser 15 ausführt, der vorgibt, dass bei erfolgreichem Aufladen die Aktion 16 ausgeführt wird, die eine SMS mit einem Paketvorschlag an den Abonnenten sendet. Ein Paketvorschlag ist im Allgemeinen ein Vorschlag zum Kauf eines Service-Pakets oder Service-Bundles.
Wenn der Benutzer eine Antwort auf die Paketvorschlags-SMS sendet, wird der Ereignisdatensatz mit einem Ereignis aktualisiert, das die Antwort darstellt und das darstellt, dass die Antwort in weniger als drei Stunden empfangen wurde. Die Erfassungs- und Aktions-Engines 10 erfassen die Aktualisierung in dem Ereignisdatensatz und bewirken, dass der Ereignisauslöser 17 ausgeführt wird. Der Ereignisauslöser 17 gibt vor, die Aktion 18 zum Beenden der Anwendung (für diesen bestimmten Abonnenten) auszuführen, wenn die Antwort in weniger als zehn Stunden empfangen wird, da der Abonnent den Paketkauf erfüllt hat. Wenn der Eintrag für den bestimmten Abonnenten in dem Ereignisdatensatz angibt, dass der bestimmte Abonnent keine Antwort auf die Aktion 16 gesendet hat, gibt die Anwendung 12 außerdem die Aktion 25 des Beendens der Anwendung für diesen bestimmten Abonnenten vor.
In einem Beispiel gibt der Eintrag für den bestimmten Abonnenten in dem Ereignisdatensatz - beispielsweise durch das Fehlen eines Auflade-Ereignisses oder durch ein abgeleitetes Ereignis, das eine Fehlen des Aufladens angibt - an, dass der Abonnent keine Aufladung durchgeführt hat. In diesem Beispiel gibt die Anwendung 12 den Ereignisauslöser 23 des Abwartens für drei Stunden vor, beispielsweise um zu überwachen, ob der Benutzer das Aufladen in den nächsten drei Stunden durchführt. Nach Ablauf der drei Stunden bewirkt der Ereignisauslöser 23, dass eine Erinnerungsaktion 24 zum Senden einer SMS mit einer Erinnerung zum Aufladen an den Abonnenten ausgeführt wird. Wenn der Abonnent nicht auf die Erinnerungs-SMS antwortet, gibt die Anwendung 12 die Aktion 26 vor, mit der die Anwendung für diesen bestimmten Abonnent beendet wird.
Als Reaktion auf die Aktion 20 kann ein Eintrag für den bestimmten Abonnenten angeben, dass der Abonnent in den letzten zwei Tagen nicht mindestens fünfzig SMS verbraucht hat. Der Eintrag kann dies über ein abgeleitetes Ereignis angeben, welches das Fehlen eines Verbrauchs von fünfzig SMS angibt, oder über eine SMS-Verbrauchs-Ereignisaggregation, die angibt, dass der Verbrauch weniger als fünfzig SMS betrug. In diesem Beispiel enthält die Anwendung 12 den Ereignisauslöser 21, der fünf Tage abwartet und dann die Aktion 22 des Sendens einer Erinnerungs-SMS ausführt. Falls der Abonnent nach dem Senden der Erinnerung innerhalb von weiteren fünf Tagen immer noch keine fünfzig SMS verbraucht hat (wie z.B. durch Ereignisse für diesen Abonnenten im Ereignisdatensatz angegeben), gibt die Anwendung 12 den Ereignisauslöser 27 zum Ausführen der Aktion 28 vor, die eine Warnung an das Kundenrückgewinnungsteam sendet (z.B. um das Team zu benachrichtigen, dass der Verbraucher den Dienst nicht nutzt) und die Anwendung für diesen bestimmten Abonnenten beendet.
Bezugnehmend auf die 2 generiert die Umgebung 30 einen umfassenden Datensatz aus verschiedenen Arten von Ereignissen in Nahezu-Echtzeit während die Ereignisse empfangen werden. In diesem Beispiel umfasst die Umgebung 30 das Sammel-, Erfassungs- und Aktions-System (SEA)-System) 32 zum Sammeln von Ereignissen, Erfassen der Erfüllung einer oder mehrerer vordefinierter Bedingungen (wie in Regeln vorgegeben) in den Ereignissen und zum Durchführen geeigneter Aktionen für die erkannten Ereignisse. In diesem Beispiel ist das SEA-System 32 auch ein Such- und Retrieval-System zum Durchsuchen von Datensätzen in dem Data Warehouse 38 (und/oder im Speicher des SEA-Systems 32), um die Batch-Daten 40 abzurufen und z.B. außerdem Profildaten abrufen, die zur Erweiterung der empfangenen Echtzeitdaten verwendet werden. In einem Beispiel verarbeitet das SEA-System 32 über zwei Milliarden Ereignisse pro Tag für fünfzig Millionen Abonnenten und berechnet Aggregationen für jede der Ereignis-arten. In diesem Beispiel empfängt das SEA-System 32 die Echtzeit-Datenströme 34 von den Datenquellen 36. Wie hierin verwendet, umfasst Echtzeit Nahezu-Echtzeit und im Wesentlichen Echtzeit, ist aber nicht darauf beschränkt, wobei für diese jeweils eine Zeitverzögerung zwischen dem Zeitpunkt des Datenempfangs oder -zugriffs und der aktuellen Verarbeitung dieser Daten existieren kann, wobei die Daten dennoch während sie empfangen werden in Echtzeit verarbeitet werden. Aus den Echtzeitdatenströmen 34 empfängt das SEA-System 32 intermittierend Daten, die Ereignisse enthalten. Die empfangenen Daten umfassen außerdem verschiedene Arten von Ereignissen. In einem Beispiel enthält ein erster der Echtzeitdatenströme Daten, die eine erste Ereignisart darstellen, und ein zweiter der Echtzeitdatenströme enthält Daten, die eine zweite Ereignisart darstellen. Das SEA-System 32 enthält eine Sammel-Engine 42 zum Sammeln der verschiedenen Arten von Ereignissen, die in den Echtzeitdatenströmen 34 empfangen werden. Da die Sammel-Engine 42 auf Echtzeit-Ereignisse und nicht auf aus einem EDW extrahierte Daten einwirkt, kann das SEA-System 32 sofort auf Ereignisse (während sie empfangen werden) und auf die Nahezu-Echtzeit-Aggregation von Ereignissen reagieren, was auch eine sofortige Sichtbarkeit der Anwendungsergebnisse ermöglicht. Die Sammel-Engine 42 sammelt die Ereignisse in einem einzigen Datenstrom und veröffentlicht die Ereignisse mehrfach in die Warteschlange. In einem Beispiel sammelt die Sammel-Engine 42 die Ereignisse, indem sie die empfangenen Ereignisse unter Verwendung kontinuierlicher Datenströme kontinuierlich verarbeitet, wie in dem U.S. Patent Nr. 6,654,907 beschrieben, dessen gesamter Inhalt hierin durch Bezugnahme aufgenommen ist.
Während weiterhin Ereignisse aus den Echtzeitdatenströmen 34 intermittierend von der Sammel-Engine 42 empfangen werden, erfasst die Sammel-Engine 42 (z.B. in der Warteschlange) zwei oder mehr bestimmte Ereignisse, die sich eine gemeinsame Qualität teilen, wie etwa, dass sie in der Ereignispalette enthalten sind oder dass sie einem bestimmten Benutzerattribut (z.B. einer Benutzerkennung (ID), einem Benutzerschlüssel etc.) zugeordnet sind. In einem Beispiel besteht die gemeinsame Qualität in entsprechenden Werten für ein bestimmtes Feld (z.B. ein Benutzer-ID-Feld) der zwei oder mehr bestimmten Ereignisse, wobei die zwei oder mehr bestimmten Ereignisse von einer bestimmten Ereignisart sind und/oder die zwei oder mehr bestimmten Ereignisse durch die Ereignispalette definiert sind.
Die Sammel-Engine 42 generiert eine Sammlung von Ereignissen, welche die erfassten zwei oder mehr bestimmten Ereignisse enthalten. In diesem Beispiel generiert die Sammel-Engine 42 einen Ereignisdatensatz 46, der die Sammlung der erfassten Ereignisse enthält. Die Sammel-Engine 42 fügt auch Anreicherungen und Aggregationen 44, z.B. einen umfassenden Datensatz, in den Ereignisdatensatz 46 ein. Im Allgemeinen handelt es sich bei einer Anreicherung um Daten, die in einem Data Warehouse gespeichert sind (die zuvor empfangen oder vorausberechnet wurden) und die sich auf ein Ereignis beziehen. Ein Ereignis kann beispielsweise eine Anzahl von SMS-Nachrichten angeben, die ein Benutzer gesendet hat, und kann außerdem eine Benutzer-ID für diesen Benutzer enthalten. In diesem Beispiel speichert das Data Warehouse 38 Daten, welche dieselbe Benutzer-ID enthalten (oder mit dieser verknüpft sind). Diese gespeicherten Daten umfassen Benutzerprofildaten, die z.B. den neuesten Handgerättyp des Benutzers enthalten. Für einen Kunden, der einem bestimmten Ereignis, das in dem Ereignisdatensatz 46 enthalten ist, zugeordnet ist, hängt die Sammel-Engine 42 Kundenprofildaten an den Ereignisdatensatz 46 an oder fügt sie in diesen ein.
Die Sammel-Engine 42 berechnet außerdem eine oder mehrere Aggregationen (d.h. Ereignisaggregationen) für ein oder mehrere Ereignisse, die in dem Ereignisdatensatz 46 enthalten sind. Für ein bestimmtes Ereignis für einen bestimmten Benutzer (wie durch die in dem Ereignis enthaltene Benutzer-ID angegeben) ruft die Sammel-Engine 42 aus dem Data Warehouse 38 Batch-Daten 40 für dieses bestimmte Ereignis für diesen bestimmten Benutzer ab. Die Batch-Daten 40 enthalten eine historische Aggregation, die sich auf das bestimmte Ereignis bezieht, wobei die historische Aggregation eine vorausberechnete Aggregation von Ereignisdaten aus einer vorangegangenen Zeitspanne, z.B. einer Zeitspanne von einer Startzeit bis zu einem bestimmten Zeitpunkt vor der Ausführung der Ereigniserfassung, ist. Im Allgemeinen umfassen Ereignisdaten Daten, die eine bestimmte Qualität, ein bestimmtes Attribut oder eine bestimmte Eigenschaft eines Ereignisses anzeigen (z.B. eine Menge an verbrauchten Daten für ein Datenverbrauchs-Ereignis). Eine Qualität eines Ereignisses umfasst beispielsweise ein bestimmtes Feld (das in dem Ereignis enthalten ist), einen bestimmten Wert eines Felds, das in dem Ereignis enthalten ist, einen bestimmten Benutzer-ID-Schlüssel, der in einem Ereignis enthalten oder diesem zugeordnet ist, ein Fehlen eines bestimmten Feldes oder Wertes des bestimmten Feldes für das Ereignis etc. Basierend auf Daten, die in dem Echtzeitdatenstrom 34 für das bestimmte Ereignis für den bestimmten Benutzer enthalten sind, und auf der historischen Aggregation, berechnet die Sammel-Engine 42 kombinierte Ereignisdaten, z.B. eine Nahezu-Echtzeit-Aggregation für das Ereignis. Die Sammel-Engine 42 reichert den Ereignisdatensatz 46 mit den kombinierten Ereignisdaten für das mindestens eine bestimmte Ereignis an.
In einem Beispiel ist eines der Ereignisse in dem Ereignisdatensatz 46 der Datenverbrauch für John Doe, dem die Benutzer-ID 5454hdrm zugeordnet ist. In diesem Beispiel ruft die Sammel-Engine 42 aus dem Data Warehouse 38 die Batch-Daten 40 für das Ereignis „Datenverbrauch“ ab, das mit der Benutzer-ID 5454hdrm verknüpft ist. Um eine Nahe-Echtzeit-Aggregation für dieses Ereignis für diesen bestimmten Benutzer zu berechnen, aggregiert die Sammel-Engine 42 Batch-Daten 40 mit inkrementellen Daten 41, um die Nahezu-Echtzeit-Aggregation 43 für dieses Ereignis zu berechnen.
In diesem Beispiel umfassen die inkrementellen Daten 41 einen Teil der aus den Echtzeitdatenströmen 34 empfangenen Daten, die sich auf den Ereignistyp, der für diesen bestimmten Benutzer aggregiert wird, beziehen. Die inkrementellen Daten 41 treten ab einem Zeitpunkt, zu dem die historische Aggregation zuletzt berechnet wurde, bis zu einem nahezu aktuellen Zeitpunkt, z.B. wenn Nahezu-Echtzeitdatenströme empfangen werden, auf. Beispielsweise geben die Batch-Daten 40 an, dass der Benutzer John Doe im letzten Monat fünfundsechzig Megabyte Daten verbraucht hat, und die inkrementellen Daten 41 geben an, dass der Benutzer John Doe in den letzten fünf Minuten 1 Megabyte Daten verbraucht hat. Durch Aggregieren der Batch-Daten 40 mit den inkrementellen Daten 41 berechnet die Sammel-Engine 42 die Nahe-Echtzeit-Aggregation '43 für dieses bestimmte Datenverbrauchs-Ereignis für den Kunden John Doe.
Die Sammel-Engine 42 fügt die Nahezu-Echtzeit-Aggregation 43 in den Ereignisdatensatz 46 ein, z.B. als Teil des Datensatzes für dieses bestimmte Ereignis für diesen bestimmten Benutzer. Die Sammel-Engine 42 fügt außerdem an den Ereignisdatensatz 46 eine anhängbare Nachschlagedatei (ALF) mit der historischen Aggregation für das bestimmte Ereignis, beispielsweise wie durch die Batch-Daten 40 angegeben, an. Die Sammel-Engine 42 hängt die ALF mit der historischen Aggregation an, um die Verwendung der historischen Aggregation bei der Berechnung neuer Nahezu-Echtzeit-Aggregationen, z.B. wenn neue Ereignisse empfangen werden, zu unterstützen.
In diesem Beispiel sendet die Sammel-Engine 42 den Ereignisdatensatz 46 an die Erfassungs-Engine 48. Die Erfassungs-Engine 48 enthält Regeln 50, die beispielsweise Regeln zum Implementieren verschiedener unterschiedlicher Anwendungen für unterschiedliche Arten von Entitäten enthalten. Die Erfassungs-Engine 48 enthält eine einzige Engine zum Implementieren der verschiedenen Anwendungen, sowie Anwendungen. In diesem Beispiel empfängt das SEA-System 32 Daten von einer Client-Vorrichtung eines Benutzers, die eine oder mehrere Regeln repräsentieren, welche eine Anwendung definieren. Beispielsweise kann der Benutzer die Ereignispalette verwenden, um die Regeln zu definieren. Das SEA-System 32 generiert auf Basis der empfangenen Daten die eine oder die mehreren Regeln, welche die Anwendung definieren. Das SEA-System 32 übergibt diese eine oder diese mehreren Regeln an Prozesse z.B. die Erfassungs-Engine 48 - die so konfiguriert sind, dass sie die eine oder die mehreren Regeln implementieren. Die Erfassungs-Engine 48 implementiert eine Anwendung basierend auf der Ausführung der Regeln 50 gegen den Ereignisdatensatz 46. Die Erfassungs-Engine 48 enthält außerdem die Statusübergänge 53, einschließlich z.B. Daten, die einen Status in einer Anwendung angeben, zu dem ein Benutzer übergegangen oder fortgeschritten ist. Auf Basis der Statusübergänge 53 identifiziert die Erfassungs-Engine 48, welche Aktionen in einer Anwendung ausgeführt werden und/oder welche Entscheidungszweige in der Anwendung ausgeführt werden sollen. Basierend auf dem Status eines bestimmten Abonnenten in einer Anwendung - wie durch die Statusübergänge 53 für diesen Abonnent angegeben - identifiziert die Erfassungs-Engine 48 beispielsweise, in Übereinstimmung mit dem Status des bestimmten Abonnenten in der Anwendung, welche Komponente einer Anwendung bereits ausgeführt wurde und welche Komponente der Anwendung als nächstes ausgeführt werden soll.
Der Ereignisdatensatz 46 enthält verschiedene Arten von Ereignissen, wie beispielsweise SMS-Ereignisse, Sprachereignisse, Datenereignisse etc. Dementsprechend enthalten die Regeln 50 Regeln mit Bedingungen für die verschiedenen unterschiedlichen Arten von Ereignissen. Im Allgemeinen enthält eine Regel eine Bedingung, deren Erfüllung die Ausführung einer Aktion bewirkt. In diesem Beispiel kann eine Regel („Regel 1“) die Bedingung enthalten, dass ein Benutzer in den letzten sechs Monaten dreißig SMS-Nachrichten gesendet hat. Bei Erfüllung dieser Bedingung gibt die Regel 1 eine Aktion vor, bei der dem Benutzer ein Guthaben von $5 gewährt wird. Eine weitere Regel („Regel 2“) kann die Bedingung enthalten, dass ein Benutzer im letzten Monat weniger als 50 Megabyte Daten verbraucht hat. Bei Erfüllung dieser Bedingung gibt Regel 2 eine Aktion vor, die dem Benutzer beispielsweise einen Verbrauchsrabatt anbietet, um einen erhöhten Datenverbrauch anzuregen. In diesem Beispiel verwenden Regel 1 und Regel 2 jeweils unterschiedliche Arten von Ereignissen (d.h. SMS-Ereignisse bzw. Datenereignisse). Die Erfassungs-Engine 48 kann ein Programm ausführen, das Regeln enthält, die von unterschiedlichen Arten von Ereignissen abhängig sind, da der Ereignisdatensatz 46 ein einziger umfassender Datensatz ist, der unterschiedliche Ereignisarten enthält. Darüber hinaus ist die Erfassungs-Engine 48 eine einzige Engine, die Anwendungen für mehrere unterschiedliche Anwendungen ausführt, da die Erfassungs-Engine 48 einen Ereignisdatensatz 46 erhält, der alle Ereignisarten für alle verschiedenen Betriebsebenen enthält. Das heißt, die Erfassungs-Engine 48 ist so konfiguriert, dass sie eine Vielzahl von verschiedenen Anwendungen gegen einen einzigen umfassenden Datensatz, d.h. den Ereignisdatensatz 46, ausführt, anstatt dass unterschiedliche Engines unterschiedliche Anwendungen gegen unterschiedliche Ereignisdatensätze (die jeweils die Art von Daten enthalten, die für eine jeweilige Anwendung geeignet sind) ausführen.
Bei der Erfassung eines Ereignisses (oder einer Aggregation von Ereignissen) in dem Ereignisdatensatz 46, das mindestens eine der Bedingungen in den Regeln 50 erfüllt, veröffentlicht die Erfassungs-Engine 48 den Aktionsauslöser 51 an die Warteschlange 52 zur Einleitung einer oder mehrerer Aktionen (die z.B. durch die Regeln mit den erfüllten Bedingungen vorgegeben sind). In einem Beispiel enthält der Aktionsauslöser Daten, die angeben, welche Aktionen ausgeführt werden sollen, für welche Anwendung sie ausgeführt werden, und einen Benutzer (z.B. einen Abonnenten oder einen Händler, für den die Aktion ausgeführt wird). Die Erfassungs-Engine 48 überträgt die Warteschlange 52 an die Aktions-Engine 54 zur Ausführung der in dem Aktionsauslöser 51 angegebenen Aktion. In diesem Beispiel ist die Aktions-Engine 54 so konfiguriert, dass sie verschiedene Aktionen ausführt, wie z.B. das Ausgeben von Guthaben an Benutzerkonten, das Übertragen von Nachrichten, das Senden von Rabattnachrichten etc.
In der Regel enthalten aus Datenströmen gesammelte Daten nicht alle Informationen, die ein SEA-System für die Verarbeitung benötigt, wie beispielsweise Benutzername und Profilinformationen. In solchen Fällen werden die Daten (d.h. die aus den Datenströmen gesammelten Daten) durch Kombinieren der Profildaten mit den empfangenen Daten in dem Echtzeitdatenstrom und durch Berechnen von Nahezu-Echtzeit-Aggregationen erweitert. Durch Kombinieren der Profildaten mit Daten aus dem Echtzeitdatenstrom und durch Berechnen der Nahe-Echtzeit-Aggregationen generiert das Such- und Retrieval-System aussagekräftige Datensätze (z.B. die empfangenen Nahezu-Echtzeit-Daten, die einem Schlüssel zugeordnet sind, die Profildaten für diesen Schlüssel, und die Nahezu-Echtzeit-Aggregationen für diesen Schlüssel), die auf die Verarbeitungsanforderungen des Such- und Retrieval-Systems zugeschnitten sind. Im Allgemeinen umfassen die Verarbeitungsanforderungen die verschiedenen von dem System auszuführenden Operationen (und/oder auszuführenden Regeln), sowie verschiedene Daten, die für das Ausführen dieser Operationen erforderlich sind. Zusätzlich hilft diese Vorausberechnung oder Generierung eines Datensatzes, der „alle Ereignisse“ oder Felder enthält, die mit Daten vorausgefüllt sind, die jedem der Ereignisse in dem Ereignisdatensatz (und/oder einem vordefinierten Satz von Feldern) entsprechen, eine Überlastung bei Engpässen in dem Netzwerk, z.B. zu einem Zeitpunkt der Verarbeitung der Echtzeitdatenströme, zu vermeiden und zu reduzieren. Dies liegt daran, dass alle für die Verarbeitung erforderlichen Daten in einem einzigen Datensatz (z.B. einem Datensatz aus Datensätzen) enthalten sind, sodass in jedem Stadium oder Schritt der Verarbeitung eines Datensatzes oder einer Sammlung von Datensätzen das Datenretrieval sowie Berechnungen und Datenbankabfragen eliminiert oder reduziert werden. Zusätzlich kann das System durch das Speichern eines Großteils der Erweiterungsdaten (z.B. Profildaten) in dem Speicher oder in einem gecachten Index in dem SEA-System schneller auf diese Daten zugreifen, da es den vorausberechneten Datensatz (der Datensätze) generiert.
Beispielsweise ist das hier beschriebene System so konfiguriert, dass es die Anreicherungen und Erweiterungsdaten zu Zeitpunkten in den Speicher (oder in einen indizierten Cache) lädt, an denen das System unter geringerer Last steht im Vergleich zur Last zu anderen Zeitpunkten. Da das System die Flexibilität aufweist, die Erweiterungsdaten zu Zeitpunkten vorzuladen, zu denen das System ansonsten unter einer geringeren Last steht, ermöglicht das System eine Lastverteilung, indem es die Erweiterungsdaten z.B. zu Zeiten verringerter Last in den Speicher lädt, anstatt dies in Echtzeit tun zu müssen, wenn die Verarbeitung der Datensätze stattfindet (und das wäre ein Zeitraum erhöhter Last).
Bezugnehmend auf die 3 umfasst der Ereignisdatensatz 60 die Felder 62a, 62b und die Unterdatensätze 62c bis 62i. In einer Abwandlung ist jeder der Unterdatensätze 62c bis 62i ein Feld zum Einfügen eines Datensatzes (oder eines Teils desselben). In diesem Beispiel enthält der Ereignisdatensatz 60 einen erweiterten Datensatz, der z.B. die empfangenen Nahezu-Echtzeit-Daten enthält, die einem Schlüssel, den Profildaten für diesen Schlüssel, und den Nahezu-Echtzeit-Aggregationen für diesen Schlüssel zugeordnet sind. Im Allgemeinen ist ein Unterdatensatz ein Datensatz innerhalb eines Datensatzes. Der Unterdatensatz als solcher enthält also eine Vielzahl von Feldern. In diesem Beispiel enthält der Ereignisdatensatz 60 alle Felder und/oder Unterdatensätze, die durch das System, beispielsweise bei der Durchführung der Ereigniserfassung verarbeitet und analysiert werden.
In diesem Beispiel umfasst der Ereignisdatensatz 60 das ID-Feld 62a für eine Abonnenten-ID, die einen Abonnenten eindeutig identifiziert, der dem Ereignis, das durch diesen Ereignisdatensatz repräsentiert wird, zugeordnet ist. Der Ereignisdatensatz 60 enthält außerdem das Ereignisart-Feld 62b, um die Ereignisart zu spezifizieren, die detektiert wird in den Nahezu-Echtzeitdatenströmen, für welche dieser Ereignisdatensatz generiert wird. Es gibt verschiedene Arten von Ereignissen, beispielsweise Datenereignisse, Sprachereignisse, SMS-Ereignisse etc. In diesem Beispiel ist die Ereignisart ein Sprachereignis des Abonnenten wie beispielsweise in den zuletzt empfangenen Daten angegeben. In diesem Beispiel empfängt das SEA-System 32 die Echtzeitdatenströme 34 und erfasst in den Echtzeitdatenströmen 34 ein Sprachereignis für einen Abonnenten, dem eine bestimmte Abonnenten-ID zugeordnet ist. Das SEA-System 32 generiert als Reaktion den Ereignisdatensatz 60 und fügt die erfasste Abonnenten-ID (z.B. ist die Abonnenten-ID von „1Q7QF“ in das ID-Feld 62a eingefügt) und die Daten, welche die erfasste Ereignisart (z.B. Sprachereignis) angeben, in das Ereignisart-Feld 62b ein. In diesem Beispiel enthält das Sprachereignis Daten, die den aktuellen Sprachverbrauch des Abonnenten anzeigen. In diesem Beispiel sind die Daten, die den Sprachverbrauch des Abonnenten anzeigen, inkrementelle Daten, da sie einen inkrementellen Verbrauch für dieses bestimmte Ereignis repräsentieren (z.B. eine Sprachverbrauchsmenge für das bestimmte Ereignis für diese bestimmte Entität von einem gegenwärtigen Zeitpunkt bis zu dem Zeitpunkt, an dem die Daten für dieses Ereignis zuvor im Batch in dem Data Warehouse 38 gespeichert wurden).
Der Ereignisdatensatz 60 enthält einen Sprachereignis-Unterdatensatz 62c mit Feldern zum Speichern von Daten, welche Qualitäten oder Eigenschaften des Sprachereignisses selbst angeben, wie z.B. die Geolokalisierung, in der das Sprachereignis aufgetreten ist (z.B, Geolokalisierung: Istanbul), einen Zeitpunkt, zu dem das Sprachereignis empfangen wurde (z.B. Empfangszeitpunkt: 12:00:01), und die Dauer des Sprachereignisses (z.B. Dauer: 42 Minuten: 07 Sekunden).
Der Ereignisdatensatz 60 enthält außerdem Ereignis-Unterdatensätze für die anderen Arten von Ereignissen (z.B. SMS-Ereignisse und Datenereignisse), selbst wenn diese anderen Arten von Ereignissen nicht erfasst werden. In diesem Beispiel enthält der Ereignisdatensatz 60 den SMS-Ereignis-Unterdatensatz 62d und den Datenereignis-Unterdatensatz 62e, die jeweils den Wert „null“ haben, um anzugeben, dass diese Ereignisarten nicht in dem erfassten Ereignis für das der Ereignisdatensatz 60 generiert wird, enthalten sind. Der Ereignisdatensatz 60 enthält jedoch den SMS-Ereignis-Unterdatensatz 62d und den Datenereignis-Unterdatensatz 62e, um einen vollständigen Datensatz des Status aller Ereignisarten zu dem Zeitpunkt zu erstellen, zu dem der Ereignisdatensatz 60 generiert wird.
Der Ereignisdatensatz 60 enthält außerdem einen Abonnentenprofil-Unterdatensatz 62f zum Einfügen eines Abonnentenprofils. In diesem Beispiel ruft das SEA-System 32 aus dem Data Warehouse 38 ein Abonnentenprofil für den Abonnenten ab, der durch die in dem ID-Feld 62a enthaltene Abonnenten-ID repräsentiert wird. Das SEA-System 32 fügt das abgerufene Abonnentenprofil (z.B. eine Dimension für das Ereignis) in Felder in dem Abonnentenprofil-Unterdatensatz 62f ein. In diesem Beispiel enthält der Abonnentenprofil-Unterdatensatz 62f ein Tariffeld und ein Adressfeld und ein Feld für den Ausreichungszeitpunkt, wie in dem veranschaulichenden Beispiel der 3 gezeigt.
Der Ereignisdatensatz 60 enthält außerdem einen Anreicherungs-Unterdatensatz 62g zum Einfügen verschiedener Anreicherungen und Ereignisaggregationen. In diesem Beispiel enthält der Anreicherungs-Unterdatensatz 62g Nahezu-Echtzeit-Sprach-, Daten- und SMS-Aggregationen. In diesem Beispiel basiert die Sprachaggregation auf einer historischen (z.B. Batch-) Aggregation des Sprachverbrauchs für diesen bestimmten Benutzer und dem inkrementellen Sprachverbrauch, wie beispielsweise in dem Feld für die Dauer des Sprachereignis-Unterdatensatzes 62c angegeben. Die Datenaggregation basiert auf Batch-Daten, welche den historischen Datenverbrauch und den inkrementellen Datenverbrauch für diesen Tag angeben, wie sie in dem Speicher des SEA-Systems 32 gespeichert sind, anstatt an ein EDW übergeben zu werden. Die SMS-Aggregation basiert auf Batch-Daten, welche den historischen SMS-Verbrauch und den inkrementellen SMS-Verbrauch für diesen Tag angeben, wie sie in dem Speicher des SEA-Systems 32 gespeichert sind. In einem Beispiel werden in Echtzeitdatenströmen empfangene Daten in dem Speicher (z.B. des SEA-Systems 32) gespeichert und dann in bestimmten Zeitintervallen, z.B. am Ende des Tages, zur Speicherung an das EDW übergeben. Bei der Ermittlung der Datenaggregation für den Anreicherungs-Unterdatensatz 62g des Ereignisdatensatzes 60 aggregiert das SEA-System 32 die Batch-Daten mit den inkrementellen Daten (welche den Datenverbrauch für den bestimmten Abonnenten angeben), die sich im Speicher befinden. Obwohl der Ereignisdatensatz 60 für ein Sprachereignis generiert wird, ist der Anreicherungs-Unterdatensatz 62g dennoch mit Daten- und SMS-Aggregationen gefüllt, da diese Aggregationen für das Ausführen einer Anwendung erforderlich sein können (z.B. wenn bestimmte Komponenten einer Anwendung eine Ausführungsbedingung haben, die auf Daten- und/oder SMS-Aggregationen basiert).
Der Ereignisdatensatz 60 enthält außerdem einen Anwendungsstatus-Unterdatensatz 62i, der einen Status in einer Anwendung, zu dem ein Abonnent übergegangen ist, angibt. In diesem Beispiel enthält der Anwendungsstatus-Unterdatensatz 62i ein Statusfeld, das angibt, welche Anwendung aus einer Vielzahl von verschiedenen Anwendungen ausgeführt wird (d.h. Anwendung 29a) und welche Komponente innerhalb dieser Anwendung ausgeführt wird (d.h. Komponente 23b). In einem Beispiel wird der Anwendungsstatus über den Unterdatensatz 62i verfolgt. Der Anwendungsstatus ist für die Logik von Bedeutung; der Status ist erforderlich, um bestimmte Arten von Anwendungen zu implementieren.
Bezugnehmend auf die FIG. 4 führt der Datenflussgraph 70 einen Prozess gegen Einzeldaten aus, die in einem Echtzeitdatenstrom enthalten sind. In diesem Beispiel führt das SEA-System 32 den Datenflussgraphen 70 beim Erzeugen eines Ereignisdatensatzes, wie z.B. des Ereignisdatensatzes 60, und beim Anreichern des Ereignisdatensatzes mit Profildaten und mit Aggregationen aus. Der Datenflussgraph 70 weist mehrere Graphkomponenten auf, die eine Mehrzahl von Datenverarbeitungsentitäten (z.B. eine oder mehrere CPUs) darstellen, die verbunden sind durch eine oder mehrere Verknüpfungen, welche Datenflüsse zwischen den Datenverarbeitungsentitäten darstellen. Der Datenflussgraph 70 enthält eine Subscribe-Komponente 72, die einen Quellendatenleser oder mehrere Quellendatenleser abonniert (z.B. Daten von diesem bzw. diesen empfängt). Durch die Subscribe-Komponente 72 greift der Datenflussgraph 70 in Echtzeit auf Einzeldaten zu, die in einem Echtzeitdatenstrom enthalten sind. In diesem Beispiel erhält die Subscribe-Komponente 72 einen Echtzeitdatenstrom (z.B. mit Tausenden von Datensätzen) aus einer Datenwarteschlange (die z.B. eine anfängliche Verarbeitung des Datenstroms durchführen kann, um seine Lesbarkeit zu gewährleisten). Daten fließen von der Subscribe-Komponente 72 zu der Teilungskomponente 74, welche die in den Datenflüssen empfangenen Datenelemente (die Ereignisse enthalten) nach Ereignisarten partitioniert oder teilt. In diesem Beispiel ist die Teilungskomponente 74 so konfiguriert, dass sie die verschiedenen in der Ereignispalette definierten Ereignisarten erfasst, und teilt die verschiedenen Ereignisarten anderen Komponenten zu, die zum Verarbeiten einer bestimmten Ereignisart konfiguriert sind.
In diesem Beispiel enthält der Datenflussgraph 70 die Verbrauchsereigniskomponente 76, die Ereigniskomponente 78, die Systemereigniskomponente 80 und die Ereigniskomponente 82. Daten fließen von der Teilungskomponente 74 zu einer oder mehreren der Ereigniskomponente 76, der Ereigniskomponente 78, der Systemereigniskomponente 80 und der Ereigniskomponente 82.
Die Verbrauchsereigniskomponente 76 umfasst Operationen zum Verarbeiten von Verbrauchsereignissen, einschließlich z.B. Ereignisse, die eine Menge an SMS-Verbrauch, Sprachverbrauch, Datenverbrauch etc. angeben. Diese Operationen identifizieren, welcher Teil eines Datensatzes, der ein Ereignis umfasst, Daten enthält, welche die Verbrauchsmenge angeben und welche(r) Teil(e) des Datensatzes andere Arten von Daten umfasst bzw. umfassen, wie beispielsweise Daten, die eine Benutzer-ID angeben, oder andere Arten von Daten, die einen Benutzer eindeutig identifizieren.
In diesem Beispiel enthält die Abonnentenereigniskomponente 78 Operationen zum Verarbeiten von Abonnentenereignissen, einschließlich z.B. Ereignisse, die einen Kunden oder einen Abonnenten betreffen. Es gibt verschiedene Arten von Abonnentenereignissen, darunter z.B. Aktivierungsereignisse (d.h. wann hat ein Benutzer ein mobiles Gerät aktiviert), Ortsereignisse (d.h. ein geografischer Ort, von dem aus ein Benutzer ein mobiles Gerät verwendet) etc. Diese Operationen, die in der Abonnentenereigniskomponente 78 enthalten sind, analysieren die Datensätze, welche die Abonnentenereignisse enthalten, um zu identifizieren, welcher Teil eines Datensatzes das Abonnentenereignis enthält und welcher Teil des Datensatzes identifizierende Benutzerdaten enthält.
Die Systemereigniskomponente 80 umfasst Operationen zum Verarbeiten von Systemereignissen, einschließlich z.B. Ereignisse, die sich auf Benutzerinteraktionen mit einem System beziehen. Es gibt verschiedene Arten von Systemereignissen, einschließlich z.B. Ereignisse, die Ruhetage von Abonnenten, Ausführungsantworten von Abonnenten etc. angeben. Diese Operationen, die in der Systemereigniskomponente 80 enthalten sind, analysieren die Datensätze, welche die Systemereignisse enthalten, um zu identifizieren, welcher Teil eines Datensatzes das Systemereignis enthält und welcher Teil des Datensatzes identifizierende Benutzerdaten enthält, als Vorbereitung auf das Einfügen dieser Daten in einen umfassenden Datensatz.
Die Ereigniskomponente 82 enthält Operationen zum Verarbeiten einer bestimmten Art von Ereignis, einschließlich z.B. Ereignisse, die sich auf einen Vertreter oder einen Einzelhändler beziehen. Es gibt verschiedene Arten von Händlerereignissen, einschließlich z.B. Ereignisse, die Händlerverkäufe, verkaufte Produkte etc. angeben. Diese Operationen, die in der Ereigniskomponente 82 enthalten sind, analysieren die Datensätze, welche die Ereignisse enthalten, um zu identifizieren, welcher Teil eines Datensatzes das Ereignis enthält und welcher Teil des Datensatzes identifizierende Benutzerdaten enthält, als Vorbereitung auf das Einfügen dieser Daten in einen umfassenden Datensatz.
Der Datenflussgraph 70 enthält außerdem die Komponente 84 für abgeleitete Ereignisse, die Operationen zum Identifizieren abgeleiteter Ereignisse enthält. Im Allgemeinen umfasst ein abgeleitetes Ereignis ein Ereignis, das von anderen Daten abgeleitet ist und/oder von einem Auftreten oder einem Fehlen eines Auftretens abgeleitet ist. Es gibt verschiedene Arten von abgeleiteten Ereignissen, z.B. Ereignisse, die eine Anzahl von „Ruhetagen Sprache“ eines Abonnenten, eine Anzahl von „Ruhetagen SMS“ eines Abonnenten, oder eine Anzahl von „Ruhetagen Daten“ eines Abonnenten angeben. In diesem Beispiel umfasst die Komponente 84 für abgeleitete Ereignisse Operationen zum Bestimmen dieser abgeleiteten Ereignisse. In einem Beispiel ermittelt das SEA-System 32 diese abgeleiteten Ereignisse, indem es das Fehlen einer bestimmten Ereignisart (z.B. SMS-Verbrauch) für einen bestimmten Benutzer in den Ereignissen, die in dem Echtzeitdatenstrom empfangen werden, erfasst. Das SEA-System 32 ermittelt bei der Erfassung, ob ein bestimmtes Ereignis in einer Schwellenzeitspanne nicht aufgetreten ist, um das Vorhandensein eines abgeleiteten Ereignisses zu erfassen. Um zu bestimmen, ob ein Fehlen während der Schwellenzeitspanne vorliegt, ruft das SEA-System 32 Daten für diesen bestimmten Benutzer aus einem Daten-Repository ab, einschließlich z.B. Daten, die ein zuvor aufgetretenes Ereignis angeben. Wenn dieses bestimmte Ereignis während einer Schwellenzeitspanne nicht vorhanden ist, erfasst das SEA-System 32 ein abgeleitetes Ereignis. In diesem Beispiel erfasst das SEA-System 32 abgeleitete Ereignisse für einen oder mehrere der Benutzer (z.B. Abonnenten, Händler etc.) basierend auf den Daten (oder deren Fehlen) in den eingehenden Echtzeitdatenströmen und basierend auf anderen Daten (Ereignissen), die in einem Daten-Repository gespeichert sind.
In diesem Beispiel enthält der Datenflussgraph 70 eine Verbindungskomponente 86, die eine Verbindungsoperation implementiert. Die Operation „Verbinden“ kombiniert verschiedene Arten von Daten, z.B. Ereignisse aus den Ereigniskomponenten 76, 78, 80, 82, 84. In diesem Beispiel fließen Daten von den Ereigniskomponenten 76, 78, 80, 82, 84 zu der Verbindungskomponente 86, welche die Ereignisse in einem umfassenden Datensatz zusammenfasst. In diesem Beispiel sendet jede der Ereigniskomponenten 76, 78, 80, 82, 84 an die Verbindungskomponente 86 ein Ereignis in Verbindung mit Daten, die eine dem Ereignis zugeordnete Entität eindeutig identifizieren, wie beispielsweise eine Benutzer-ID für die Entität.
In diesem Beispiel fließen Daten von der Verbindungskomponente 86 zu der Abonnentenanreicherungs-Komponente 87, die Operationen zur Anreicherung des umfassenden Datensatzes mit Profildaten für eine bestimmte Art von Entität, d.h. einen Abonnenten, umfasst. In diesem Beispiel sind die Daten, die von der Verbindungskomponente 86 zu der Abonnentenanreicherungs-Komponente 87 fließen, Daten, die angeben, welche Ereignisse in dem umfassenden Datensatz Abonnentenereignisse und den Abonnentenereignissen zugeordnete Benutzer-IDs sind, z.B. um ein Nachschlagen von Abonnentenprofilen für diese Abonnenten zu ermöglichen. Für ein bestimmtes Ereignis, das in dem umfassenden Datensatz enthalten ist, verwenden in der Abonnentanreicherungs-Komponente 87 enthaltene Operationen die Benutzer-ID für dieses Ereignis, um Profildaten für einen durch die Benutzer-ID angegebenen Benutzer (aus einem Daten-Repository) abzurufen. Die Abonnentenanreicherungs-Komponente 87 fügt die abgerufenen Profildaten, z.B. in Verbindung mit dem Ereignis, in den umfassenden Datensatz ein.
Daten fließen von der Anreicherungskomponente 87 zu der Anreicherungskomponente 88, die Operationen zur Anreicherung des umfassenden Datensatzes mit Profildaten für eine weitere bestimmte Art von Entität, d.h. einen Händler, enthält. In diesem Beispiel sind die Daten, die von der Anreicherungskomponente 87 zur Anreicherungskomponente 88 fließen, Daten, die angeben, welche Ereignisse in dem umfassenden Datensatz bestimmte Ereignisarten sind und welche Daten Benutzer-IDs (d.h. Händler-IDs) sind, die einer bestimmten Entität zugeordnet sind (die diesen bestimmten Ereignisarten zugeordnet ist), um beispielsweis ein Nachschlagen von Profilen zu ermöglichen, die dieser Entität zugeordnet sind.
In einem Profil sind Verschiedene Arten von Daten enthalten, z.B. Daten, die angeben, ob die Entität ein bevorzugter Lieferant ist, oder nicht, ob die Entität Teil einer Kette ist oder nicht, und wenn ja, von welcher Kette etc. Für ein bestimmtes Ereignis, das in dem umfassenden Datensatz enthalten ist, verwenden in der Anreicherungskomponente 88 enthaltene Operationen die Benutzer-ID für dieses Ereignis, um Profildaten für einen durch die Benutzer-ID angegebenen Händler (aus einem Daten-Repository) abzurufen. Die Anreicherungskomponente 88 fügt die abgerufenen Profildaten, z.B. in Verbindung mit dem Ereignis für diese Entität, in den umfassenden Datensatz ein.
Daten fließen von der Anreicherungskomponente 88 zu der Verbrauchsaggregationskomponente 90, die Operationen zum Berechnen von Nahezu-Echtzeit-Aggregaten für verschiedene Arten von Ereignissen, einschließlich z.B. Verbrauchsereignisse, umfasst. Für ein bestimmtes Ereignis für einen bestimmten Benutzer (z.B. Abonnenten oder Händler) ruft die Verbrauchsaggregationskomponente 90 die Batch-Daten für diesen Benutzer ab (z.B. die Daten, die eine vorausberechnete Aggregation angeben, die in dem Batch gespeichert ist) und fügt inkrementelle Daten (z.B. ein oder mehrere Ereignisse, die in dem Echtzeitdatenstrom empfangen werden) zu den Batch-Daten hinzu, um die Nahezu-Echtzeit-Aggregation zu berechnen. Die Verbrauchsaggregationskomponente 90 fügt die berechnete Nahe-Echtzeit-Ereignisaggregation, beispielsweise für ein bestimmtes Ereignis für einen bestimmten Benutzer, in den umfassenden Datensatz ein. In einem Beispiel hängt die Verbrauchsaggregationskomponente 90 auch eine ALF-Datei mit Aggregationen (z.B. Sprachaggregationen, Datenaggregationen, Aufladeaggregationen etc.) in verschiedenen Zeitabständen (z.B. täglich, wöchentlich, monatlich etc.) an den umfassenden Datensatz an. Im Allgemeinen ist ein Aufladen ein Hinzufügen von zusätzlichem Geld, Minuten und/oder Daten zu einem Prepaid-Telefonie- oder Mobilfunkvertrag.
In diesem Beispiel gibt es verschiedene, unterschiedliche Arten von Aggregationen, wie z.B. Kalenderaggregationen (z.B. eine Ereignisaggregation für einen Tag, eine Woche, einen Monat etc.), die auf Minibatch-Weise berechnet werden (z.B. alle N Minuten) und an den umfassenden Datensatz angefügt werden. Im Allgemeinen umfasst Minibatch eine vorausberechnete Aggregation von Ereignisdaten, die in bestimmten Zeitintervallen (z.B. alle N Minuten) auftreten und in einem Data Warehouse (im Batch) gespeichert werden. Eine Kalenderaggregation in dem Data Warehouse wird kontinuierlich und/oder periodisch aktualisiert, um die neueste Minibatch-Aggregation für diese bestimmte Kalenderaggregation zu beinhalten. Im Allgemeinen tritt eine Minibatch-Aggregation häufiger auf als eine Batch-Aggregation, die z.B. alle drei Tage auftreten kann, anstatt alle drei Minuten, wie bei der Minibatch-Aggregation. Da Minibatch-Aggregationen häufiger auftreten, aggregieren derartige Aggregationen kleinere Datenmengen. Es gibt außerdem Zeitfenster-Aggregationen (z.B. eine Ereignisaggregation für die letzte Minute, die letzten N Stunden, die letzten N Tage etc.), die beim Eintreffen von Ereignisse während der Anreicherung berechnet und ebenfalls an den umfassenden Datensatz angefügt werden. Diese Zeitfenster-Aggregationen werden im Speicher des SEA-Systems 32 gespeichert, anstatt an ein EDW übergeben zu werden, und werden daher beim Eintreffen von Ereignissen in Echtzeit berechnet.
Daten fließen von der Verbrauchsaggregationskomponente 90 zur Veröffentlichungskomponente 92, die den umfassenden Datensatz beispielsweise in eine Warteschlange veröffentlicht, um zu ermöglichen, dass mehrere unterschiedliche Anwendungen gegen den umfassenden Datensatz ausgeführt werden. Durch das Veröffentlichen des umfassenden Datensatzes in die Warteschlange wird jeder der Unterdatensätze (in dem umfassenden Datensatz) als ein Eintrag in die Warteschlange aufgenommen, wenn die verschiedenen Anwendungen gegen die Warteschlangeneinträge ausgeführt werden.
In einer Variante kann der Datenflussgraph keine Verbindungskomponente enthalten, z.B. wenn die verschiedenen Formate einer Sammeloperation in gemeinsame Nutzdaten umgewandelt werden. In diesem Beispiel gibt es keine Verbindungskomponente, da keine spezifischen Ereignisformate erfasst werden müssen. In einem Beispiel führt der Datenflussgraph 70 außerdem Zeitfensteraggregations-Berechnungen durch, und Kalenderaggregationen (z.B. Batchaggregationen) werden von außerhalb der Anreicherungskomponente (z.B. den Komponenten 87, 88) separat ausgeführt.
In diesem Beispiel enthält der Datenflussgraph 70 Eckpunkte (die Datenverarbeitungskomponenten oder Datensätze darstellen), die durch gerichtete Verknüpfungen (die Flüsse von Arbeitselementen, d.h. Daten, darstellen) zwischen den Eckpunkten verbunden sind. Ein System zum Ausführen solcher Datenflussgraphen ist in dem US-Patent 5,966,072 mit dem Titel „Executing Computations Expressed as Graphs“ beschrieben, dessen gesamter Inhalt hierin durch Bezugnahme aufgenommen ist. Gemäß diesem System erstellte Datenflussgraphen stellen Verfahren bereit zum Verschieben von Daten in einzelne, durch Graphkomponenten dargestellte Prozesse und aus diesen heraus, zum Verschieben von Daten zwischen den Prozessen und zum Definieren einer Reihenfolge für die Prozesse. Dieses System umfasst Algorithmen, die aus beliebigen verfügbaren Verfahren prozessübergreifende Kommunikationsverfahren auswählen (Kommunikationspfade gemäß den Verknüpfungen des Graphen können beispielsweise TCP/IP- oder UNIX-Domain-Sockets oder gemeinsam genutzten Speicher verwenden, um Daten zwischen den Prozessen zu übergeben).
Die in dieser Beschreibung beschriebenen Prozesse oder Verfahren können durch ein Computersystem ausgeführt werden, wobei das Computersystem Folgendes umfasst: eine Entwicklungsumgebung, die mit einem Datenspeicher gekoppelt ist, wobei die Entwicklungsumgebung zum Aufbau einer Datenverarbeitungsanwendung konfiguriert ist, die dem Datenflussgraphen zugeordnet ist, der die graphbasierte Berechnung implementiert, die an Daten ausgeführt wird, die von einem oder mehreren Eingabedatensätzen durch den Graphen der Graphkomponenten zu einem oder mehreren Ausgabedatensätzen fließen, wobei der Datenflussgraph durch Datenstrukturen in dem Datenspeicher vorgegeben ist, wobei der Datenflussgraph eine Vielzahl von Knoten aufweist, die durch die Datenstrukturen vorgegeben sind und die durch eine oder mehrere Verknüpfungen verbundenen Graphkomponenten repräsentieren, wobei die Verknüpfungen durch die Datenstrukturen vorgegeben sind und Datenflüsse zwischen den Graphkomponenten repräsentieren; und/oder eine Laufzeitumgebung, die mit dem Datenspeicher gekoppelt ist und auf einem oder mehreren Computern gehostet wird, wobei die Laufzeitumgebung ein Vorabausführungsmodul umfasst, das zum Lesen der gespeicherten Datenstrukturen konfiguriert ist, die den Datenflussgraphen angeben, und um Rechenressourcen für die Durchführung der Berechnung der Graphkomponenten zuzuweisen und zu konfigurieren, wobei die Laufzeitumgebung ein Ausführungsmodul umfasst, um die Ausführung der dem Datenflussgraphen zugeordneten Berechnungen zu planen und zu steuern.
Unter Bezugnahme auf die 5 bis 14 werden verschiedene grafische Benutzerschnittstellen gezeigt, die verschiedene Ereignisse in der Ereignispalette anzeigen. Jedes dieser Ereignisse (in der Ereignispalette dargestellt) kann in einem Ereignisdatensatz (in einem entsprechenden Feld oder Unterdatensatz) enthalten sein. Diese Einbeziehung aller Ereignisse in den Ereignisdatensatz ermöglicht es einem Benutzer, eine Anwendung basierend auf verschiedenen Ereignissen zu definieren und diese definierte Anwendung gegen einen Ereignisdatensatz auszuführen (anstatt eine Datenbank nach geeigneten Daten abfragen zu müssen), da der Ereignisdatensatz alle (oder einen Teil) der Ereignisse in der Ereignispalette enthält, die bei der Definition der Anwendung verwendet werden könnten.
Bezugnehmend auf die 5 ist die grafische Benutzerschnittstelle 100 in der Ereignispalette enthalten. In diesem Beispiel ist die Ereignispalette eine Anwendung, die eine Reihe von grafischen Benutzerschnittstellen umfasst, die verfügbare vordefinierte Ereignisse anzeigen, die beim Definieren einer oder mehrerer Regeln verwendet werden können. In diesem Beispiel enthält eine Regel einen Ausdruck, der eine aufschiebende Bedingung definiert, deren Erfüllung die Ausführung einer Aktion bewirkt. Über die Ereignispalette kann der Benutzer einen Ausdruck definieren, der auf einem Ereignis basiert. Beispielsweise kann der Ausdruck bedeuten, dass ein bestimmtes Ereignis einen Schwellenwert oder einen vordefinierten Wert erreicht. Für diesen Ausdruck kann der Benutzer außerdem eine oder mehrere Aktionen definieren, die nach Erfüllung des Ausdrucks ausgeführt werden sollen.
In diesem Beispiel zeigt die grafische Benutzerschnittstelle 100 verschiedene Eingaben an, die beim Definieren eines Ausdrucks für eine Regel verwendet werden können, sowie Daten, die Attribute von erfassten Ereignissen anzeigen. Das Aktuelle-Zeit-Attribut 102a zeigt Daten an, die eine aktuelle oder gegenwärtige Zeit zeigen. Das Ereigniszeit-Attribut 102b zeigt Daten an, die eine Zeit angeben, zu der ein Ereignis zuletzt erfasst wurde. Nach Auswahl des Ereigniszeit-Attributs 102b kann ein Benutzer das zuletzt erfasste Ereignis einsehen. Die Ereignisart-Daten 102c zeigen Daten an, welche die verschiedenen Arten von Ereignissen anzeigen, die bei der Definition einer Regel verwendet werden können. Diese Ereignisse werden auf verschiedenen Ebenen erfasst, einschließlich z.B. auf Abonnentenebene und Händlerebene. Nach der Auswahl der Ereignisart-Daten 102c wird die Auflistung 107 der mehreren unterschiedlichen Arten von Ereignissen angezeigt. In diesem Beispiel gibt es ein Aktivierungsereignis, das angibt, wann ein Gerät aktiviert wird, ein Tarifwechselereignis, das angibt, wann eine Entität einen Tarif für ein Mobilgerät wechselt, ein Ruhetage-Ereignis, das eine Anzahl von Tagen angibt, an denen ein Benutzer ein mobiles Gerät nicht verwendet hat, ein Handgerät-Wechsel-Ereignis, das angibt, wann ein Benutzer ein mobiles Gerät gewechselt hat, etc.
Die grafische Benutzerschnittstelle 100 umfasst außerdem Schlüssel-Daten 102d, die einen Schlüssel für eine Entität, wie eine Händler-ID oder eine Abonnenten-ID, anzeigen. Das heißt, die Schlüssel-Daten 102d zeigen Daten an, die einen Schlüssel oder eine Benutzer-ID für eine bestimmte Entität anzeigen, für die ein Ereignis in der grafischen Benutzerschnittstelle 100 betrachtet wird, wenn die grafische Benutzerschnittstelle 100 zum Betrachten aktueller Ereignisse verwendet wird. In diesem Beispiel kann ein Benutzer mehrere unterschiedliche Schlüssel durchblättern (oder auswählen), um mehrere unterschiedliche Ereignisse zu sehen, die diesen jeweiligen Schlüsseln zugeordnet sind. Bei der Auswahl eines bestimmten Schlüssels wird jedes Datum oder Datenfeld 102a bis 102m aktualisiert, um Werte für diesen bestimmten Schlüssel anzuzeigen.
In diesem Beispiel ermöglicht es die grafische Benutzerschnittstelle 100 einem Benutzer, erfasste Ereignisse beispielsweise über nicht gezeigte Steuerelemente anzusehen. Wenn der Benutzer ein bestimmtes erfasstes Ereignis betrachtet, werden die Schlüssel-Daten 102d (z.B. eine aktualisierte Kennung) aktualisiert, um die ID für das betrachtete Ereignis anzuzeigen. Wenn der Benutzer ein weiteres, anderes Ereignis auswählt, werden die Schlüssel-Daten 102 aktualisiert, um die ID für dieses weitere, andere Ereignis anzuzeigen. Die grafische Benutzerschnittstelle 100 umfasst die Anwendungsstatusdaten 102e, die z.B. Daten umfassen, die eine Start- und Endzeit für eine Anwendung, eine Anzahl von Aktionen, die für eine bestimmte Anwendung ausgeführt wurden, etc. angeben.
Die grafische Benutzerschnittstelle 100 umfasst außerdem die Abonnentenprofildaten 102f, von denen eine Auswahl die verschiedenen Arten von Abonnentenprofildaten anzeigt, die in den umfassenden Datensatz eingefügt werden und zur Verwendung beim Definieren von Regeln verfügbar sind. Die grafische Benutzerschnittstelle 100 umfasst außerdem die Abonnentenereignisse 102g, deren Auswahl die verschiedenen Arten von Abonnentenereignissen anzeigt, die in den umfassenden Datensatz eingefügt werden und zur Verwendung beim Definieren von Regeln verfügbar sind. Die grafische Benutzerschnittstelle 100 umfasst außerdem die synthetischen Abonnentenereignisse 102h, deren Auswahl die verschiedenen Arten von synthetischen Abonnentenereignissen anzeigt, die in den umfassenden Datensatz eingefügt werden und zur Verwendung beim Definieren von Regeln verfügbar sind. Im Allgemeinen ist ein synthetisches Ereignis ein abgeleitetes Ereignis. Die grafische Benutzerschnittstelle 100 umfasst außerdem die Abonnentenaggregationen 102i, deren Auswahl Nahezu-Echtzeit-Aggregationen für verschiedene Abonnentenereignisse anzeigt.
Die grafische Benutzerschnittstelle 100 umfasst außerdem die Profildaten 102j, deren Auswahl die verschiedenen Arten von Profildaten anzeigt, die in den umfassenden Datensatz eingefügt werden und zur Verwendung beim Definieren von Regeln verfügbar sind. Die grafische Benutzerschnittstelle 100 umfasst außerdem die Ereignisse 102k, deren Auswahl die verschiedenen Arten von Ereignissen anzeigt, die in den umfassenden Datensatz eingefügt werden und zur Verwendung beim Definieren von Regeln verfügbar sind. Die grafische Benutzerschnittstelle 100 umfasst außerdem die synthetischen Ereignisse 102m, deren Auswahl die verschiedenen Arten von synthetischen Ereignissen anzeigt, die in den umfassenden Datensatz eingefügt werden und zur Verwendung beim Definieren von Regeln verfügbar sind. Die grafische Benutzerschnittstelle 100 umfasst außerdem die Aggregationen 102l, deren Auswahl Nahezu-Echtzeit-Aggregationen für verschiedene Ereignisse anzeigt. In diesem Beispiel enthält ein umfassender Datensatz die Ereignisse 102g. Für ein bestimmtes Abonnentenereignis enthält der umfassende Datensatz außerdem ein Profil für diesen Abonnenten sowie synthetische Ereignisse und Aggregationen. Der umfassende Datensatz enthält die Ereignisse 102k. Für ein bestimmtes Ereignis, das einer Entität zugeordnet ist, enthält der umfassende Datensatz außerdem ein Profil für diese Entität sowie synthetische Ereignisse und Aggregationen für diese Entität.
Bezugnehmend auf die 6 zeigt die grafische Benutzerschnittstelle 110 Ereignisse 112 an, die in der Ereignispalette enthalten sind. In diesem Beispiel enthalten die Abonnentenprofildaten 114 die Profildaten 114a, die Handgerätdaten 114b, Value Added Service (VAS)-Daten 114c (z.B. Klingeltöne), die Kontostandsdaten 114d, die Versicherungsdaten 114e und die Zusatzangebot-Daten 114f. Jede dieser Datenarten umfasst verschiedene Arten von Unterdaten, z.B. granularere oder detailliertere Daten, die in eine der Kategorien eingeteilt sind, die durch die Daten 114a bis 114f dargestellt werden.
In diesem Beispiel umfassen die Handgerätdaten 114b granulare Daten 116, d.h. die Abonnentennummer, die „Mobile Station International Subscriber Directory Number“ (MSISDN), die Marke, das Modell, die „International Mobile Station Equipment Identity“ (IMEI), die „International Mobile Subscriber Identity“ (IMSI), ein Zielsegment, und allgemeine Paketfunkdienste (GPRS). In diesem Beispiel zeigen die verschiedenen Arten von granularen Daten 116 aktuelle Werte eines bestimmten Benutzerdatensatzes für die verschiedenen Arten von Benutzerdaten an. In diesem Beispiel zeigen die Abonnent-Nummer-Daten den Wert 116a an, welcher der Wert der Abonnent-Nummer für einen bestimmten Abonnenten ist, für den Ereignisse und Daten über die grafische Benutzerschnittstelle 110 betrachtet werden. Die grafische Benutzerschnittstelle 110 zeigt außerdem die granularen Daten 118 für die Profildaten 114a an, um granulare, profilspezifische Daten, wie z.B. eine Ursprungs-Entität und ein Freischaltdatum, bereitzustellen. Diese granularen Daten 116, 118 sind in dem umfassenden Datensatz in Verbindung mit Abonnentenereignissen als eine Anreicherung für ein Abonnentenereignis enthalten.
Bezugnehmend auf die 7 ist die grafische Benutzerschnittstelle 120 in der Ereignispalette enthalten und umfasst die Ereignisse 122. In diesem Beispiel enthalten die Profildaten 124 die granularen Daten 126, wie beispielsweise Name, MSISDN, Adresse etc. Diese granularen Daten 126 sind in Verbindung mit einem Ereignis in dem umfassenden Datensatz enthalten.
Bezugnehmend auf die 8 ist die grafische Benutzerschnittstelle 130 in der Ereignispalette enthalten und zeigt die verschiedenen Arten von Abonnentenereignissen 132 an, die für das Definieren von Regeln zur Verfügung stehen und in dem umfassenden Datensatz enthalten sind. Die Abonnentenereignisse 132 umfassen das Aktivierungsereignis 132a (Angabe, ob ein Benutzer ein Telefon aktiviert hat), das Zusatzangebot-Ereignis 132b (Angabe, ob ein Benutzer auf ein zusätzliches Angebot reagiert hat), das Datenverbrauchs-Ereignis 132c (Angabe der Datenverbrauchsmenge eines Benutzers), das Handgerät-Wechsel-Ereignis 132d (Angabe, ob ein Benutzer ein Handgerät aufgerüstet oder gewechselt hat), Kaufereignis 132e (Angabe, ob ein Benutzer einen Kauf getätigt hat), Tarifwechsel-Ereignis 132f (Angabe, ob ein Benutzer einen Geräte-Tarif gewechselt hat), Gewinnspiel-Registrierungs-Ereignis 132g (Angabe, ob ein Benutzer eine Gewinnspiel-Registrierung durchgeführt hat), Auflade-Ereignis 132h (Angabe, ob ein Benutzer eine mobile Karte oder ein mobiles Gerät aufgeladen hat), Restguthaben-Ereignis 132i (Angabe eines Restbetrags auf einem Konto), Antwort-SMS-Ereignis 132j (Angabe, ob ein Benutzer auf eine SMS-Nachricht geantwortet hat), SMS-Verbrauchsereignis 132k (Angabe einer SMS-Verbrauchs-Menge), Datenverbrauchs-Ereignis 132l (Angabe einer Sprachverbrauchs-Menge), VAS-Ereignis 132n und Gutschein-Ereignis 132o. Jedes dieser Abonnentenereignisse ist in dem Ereignisdatensatz in Verbindung mit einem Abonnentenprofil und einer Abonnenten-ID für Abonnenten, für die diese Ereignisse erfasst werden, und auch in Verbindung mit Ereignisaggregationen für diese Ereignisse enthalten.
Bezugnehmend auf die FIG. In 9 zeigt die grafische Benutzerschnittstelle 136 verschiedene Arten 138 von Aktivierungsereignissen 132a an. Beispielsweise ist eine Art eines Aktivierungsereignisses das Datum eines Aktivierungsprozesses, welches ein Datum angibt, an dem die Aktivierung durch einen Abonnenten verarbeitet wird. In diesem Beispiel wird ein Live-Wert (z.B. 2014-06-26 10:55:28) aus einem bestimmten Abonnentendatensatz neben dem Aktivierungsdatum angezeigt, da ein Benutzer die aktuellen Ereigniswerte von Datensätzen (z.B. in dem umfassenden Datensatz) betrachtet, während der Benutzer eine Regel definiert. Wie bereits beschrieben, kann ein Benutzer durch die aktuellen Ereigniswerte verschiedener Datensätze blättern.
Bezugnehmend auf die FIG. In 10 zeigt die grafische Benutzerschnittstelle 140 die Arten 142 der Restguthaben-Ereignisse 132i an. In diesem Beispiel werden diese Restguthaben-Ereignisse 132i in den umfassenden Datensatz aufgenommen, z.B. wenn sie für verschiedene Abonnenten erfasst werden. Bezugnehmend auf die 11 zeigt die grafische Benutzerschnittstelle 150 verschiedene Arten 152 von Zusatzangebot-Ereignissen 132b zur Aufnahme in den umfassenden Datensatz an. Bezugnehmend auf die 12 zeigt die grafische Benutzerschnittstelle 160 Arten 162 von Handgerät-Wechsel-Ereignissen 132d an, die in dem umfassenden Datensatz enthalten sind.
Bezugnehmend auf die 13 umfasst die grafische Benutzerschnittstelle 170 die Ereignisse 171. In diesem Beispiel werden die verschiedenen Arten von synthetischen Ereignissen 172 gezeigt, einschließlich: Ruhetage-Ereignisse 174, (die eine Anzahl von Tagen angeben, an denen ein Benutzer ein mobiles Gerät nicht verwendet hat), Ausführungsantwort-Ereignisse 176 (die angeben, ob ein Benutzer ein Angebot erfüllt oder angenommen hat), Kulanztage-Ereignisse 178 (die eine Anzahl von Tagen angeben, in denen zugelassen wird, dass ein Benutzer sich mit einer Zahlung oder einer anderen erforderlichen Aktion verspätet, bevor eine Erinnerung oder eine andere Maßnahme erfolgt), „Kein-Ereignis“-Ereignisse 180 (die das Fehlen eines beliebigen Ereignisses innerhalb eines bestimmten Zeitraums angeben - beispielsweise, wenn ein Abonnenten innerhalb von dreißig Tagen keine Ereignisse oder Aktionen durchgeführt hat), und Timer-Ereignisse 182 (die angeben, dass ein bestimmter Zeitpunkt gekommen ist). In diesem Beispiel zeigt die grafische Benutzerschnittstelle 170 außerdem die verschiedenen Arten 179 von Ruhetage-Ereignissen an, d.h. eine Zeitspanne, in der keine Aktivität oder keine Gerätebenutzung vorhanden ist. Es gibt verschiedene Arten von Ruhetage-Ereignissen, wie beispielsweise „Ruhetage Aufladung“, „Ruhetage SMS“, „Ruhetage Sprache“, „Ruhetage Daten“ und „Tage vollständiger Ruhe“. In diesem Beispiel zeigt die grafische Benutzerschnittstelle 170 außerdem den Zeitstempel 182a für das Timerereignis 182 an. In diesem Beispiel sind die synthetischen Ereignisse 172 in einem Ereignisdatensatz für einen Abonnenten enthalten, z.B. indem sie in dem Anreicherungs-Unterdatensatz enthalten sind, in einem Unterdatensatz, der für synthetische Abonnentenereignisse reserviert ist (z.B. einem Unterdatensatz für synthetische Abonnentenereignisse), oder in dem Anreicherungs-Unterdatensatz.
Bezugnehmend auf die 14 umfasst die Ereignispalette die graphische Benutzerschnittstelle 190 und ermöglicht es einem Benutzer, beim Definieren einer Regel verschiedene Ereignisaggregationen auszuwählen. In diesem Beispiel umfasst die grafische Benutzerschnittstelle 190 die Ereignisse 192, welche die Abonnentenaggregationen 194 umfassen. Wie zuvor beschrieben, ist eine Abonnentenaggregation eine Nahezu-Echtzeit-Aggregation für ein bestimmtes Abonnentenereignis, wobei die Nahezu-Echtzeit-Aggregation eine Aggregation der Batch-Daten für das bestimmte Abonnentenereignis und der inkrementellen Daten für das jeweilige Abonnentenereignis ist, die in dem Echtzeitdatenstrom empfangen werden. In diesem Beispiel umfassen die Abonnentenaggregationen 194 die Daten-Übersicht-Aggregationen 194a (z.B. eine Aggregation des Datenverbrauchs über verschiedene Zeiträume), die Aufladungs-Übersicht-Aggregationen 194b (z.B. eine Aggregation der Aufladungen des mobilen Geräts über verschiedene Zeiträume), die SMS-Übersicht-Aggregationen 194c (z.B. eine Aggregation des SMS-Verbrauchs über verschiedene Zeiträume), die Sprach-Übersicht-Aggregationen 194d (z.B. eine Aggregation des Sprachverbrauchs über verschiedene Zeiträume), und die Monatliche-Aktivität-Aggregationen 194e (z.B. Aggregationen, die über monatliche Zeiträume erfolgen).
Die grafische Benutzerschnittstelle 190 zeigt die verschiedenen Arten von Ereignissen an, die in den Sprach-Übersicht-Aggregationen 194d enthalten sind. Diese Ereignissarten umfassen die täglichen Sprachereignis-Aggregationen 196 (z.B. eine Aggregation verschiedener Arten des täglichen Sprachverbrauchs für einen bestimmten Abonnenten), die wöchentlichen Sprachereignis-Aggregationen 198 (z.B. eine Aggregation des wöchentlichen Sprachverbrauchs für einen bestimmten Abonnenten), und die monatlichen Sprachereignis-Aggregationen 200 (z.B. eine Aggregation des monatlichen Sprachverbrauchs für einen bestimmten Abonnenten). Innerhalb der täglichen Sprachereignis-Aggregationen 196 gibt es verschiedene Aggregationen, einschließlich beispielsweise die täglichen Sprache-Insgesamt-Aggregationen 196a, die täglichen Sprache-im-Netz-(z.B. in dem Netzwerk oder über das Netzwerk) Aggregationen 196b, die täglichen Sprache-nicht-im-Netz-(z.B. Roaming) Aggregationen 196c, und die täglichen „International Direct Dialed (IDD)“-SprachAggregationen 196d (z.B. Auslandsgespräche). Für die täglichen Sprache-Insgesamt-Aggregationen 196a bestimmt das SEA-System 32 außerdem verschiedene Arten von täglichen Sprache-Insgesamt-Aggregationen, wie beispielsweise tägliche Sprachanrufe 204 (z.B. Daten, die täglich eine Menge an Sprachanrufen für einen bestimmten Abonnenten angeben), tägliche Sprachausgabe 206 (z.B., Daten, die einen Geldbetrag angeben, der von einem bestimmten Abonnenten täglich für Sprachanrufe ausgegeben wird), und die tägliche Sprachdauer 208 (z.B. Daten, die eine Dauer der täglichen Anrufe für einen bestimmten Abonnenten angeben). Diese verschiedenen Arten von Sprach-Übersicht-Aggregationen 194d werden zu dem Datensatz hinzugefügt, der generiert wird, um die verschiedenen Ereignisse in der Ereignispalette zu beinhalten.
Die grafische Benutzerschnittstelle 190 zeigt außerdem verschiedene Arten von Aufladungs-Übersicht-Aggregationen 194b an, wie etwa die tägliche Aufladungs-Übersicht-Aggregationen 210 (z.B. eine Menge von über einen Tag aggregierten Aufladungen für einen bestimmten Abonnenten), sowie die wöchentlichen Aufladungs-Übersicht-Aggregationen 212 und die monatlichen Aufladungs-Übersicht-Aggregationen 214. In diesem Beispiel gibt es verschiedene Arten von täglichen Aufladungs-Übersicht-Aggregationen 210, umfassend die täglichen Aufladungen 216 (z.B. wieviele Male ein bestimmter Abonnenten an einem bestimmten Tag eine Aufladung durchgeführt hat), und den täglichen Aufladungsbetrag 218 (z.B. einen Betrag von Aufladungen, die von einem bestimmten Abonnenten an einem Tag ausgeführt werden). In diesem Beispiel werden diese verschiedenen Arten von Aufladungs-Übersicht-Aggregationen 194b zu dem umfassenden Datensatz, der durch das SEA-System 32 generiert wird, hinzugefügt.
Bezugnehmend auf die FIG. 15 führt das SEA-System 32 beim Durchführen von ereignisbasiertem Marketing den Prozess 220 aus, bei dem mehrere unterschiedliche Anwendungen (z.B. Anwendungen oder Programme) gegen Echtzeitdatenströme ausgeführt werden, während die Daten empfangen werden. Im Betrieb empfängt das SEA-System 32 intermittierend (220) Daten von einem oder mehreren Datenströmen, wobei solche Daten Ereignisse enthalten. Während weiterhin Ereignisse aus dem einen oder den mehreren Datenströmen intermittierend empfangen werden, erfasst (222) das SEA-System 32 zwei oder mehr bestimmte Ereignisse in den empfangenen Ereignissen, wobei die erfassten zwei oder mehr bestimmten Ereignisse eine gemeinsame Qualität aufweisen, wie beispielsweise, dass sie in der Ereignispalette definiert sind. In einem anderen Beispiel könnte die gemeinsame Qualität eine gemeinsame Benutzer-ID oder ein gemeinsamer Benutzerschlüssel sein, da das SEA-System 32 Ereignisse für eine bestimmte Entität erfasst. Das SEA-System 32 generiert (oder aktualisiert) (224) eine Sammlung von Ereignissen, welche die erfassten zwei oder mehr bestimmten Ereignisse enthalten. In einem Beispiel, bei dem die Sammlung bereits generiert wurde (z.B. während einer vorherigen Iteration des Prozesses 220), aktualisiert das SEA-System 32 die Sammlung, z.B. mit neu erfassten Ereignissen. Beispielsweise generiert das SEA-System 32 einen Datensatz (z.B. einen umfassenden Datensatz) der erfassten Ereignisse. In diesem Datensatz ist jedes Ereignis einer Entitäts-ID, z.B. einer Abonnenten-ID oder einer Entitäts-ID, zugeordnet. In diesem Beispiel ist die Entitäts-ID bereits dem Ereignis in dem Echtzeitdatenstrom zugeordnet, und das SEA-System 32 fügt die Entitäts-ID und das Ereignis in den umfassenden Datensatz ein.
Das SEA-System 32 reichert die Ereignisse in dem umfassenden Datensatz an, indem es dem Datensatz Profildaten für die Entitäten, die den jeweiligen Ereignissen zugeordnet sind, hinzufügt (oder anhängt) und indem es Ereignisaggregationen hinzufügt. In einem Beispiel ruft das SEA-System 32 für mindestens ein bestimmtes Ereignis, das in der Sammlung von Ereignissen enthalten ist, aus einem Datenspeicher eine historische Aggregation ab (226), die sich auf das mindestens eine bestimmte Ereignis bezieht, wobei die historische Aggregation eine vorausberechnete Aggregation von Ereignisdaten aus einem früheren Zeitraum ist. In diesem Beispiel ist die historische Aggregation eine vorausberechnete Aggregation von einem Startzeitpunkt zu einem Endzeitpunkt. Diese vorausberechnete Aggregation wird in dem Batch (von einzelnen Ereignissen, die im Zeitraum zwischen der Startzeit und der Endzeit auftreten) berechnet und wird als Batch-Daten bezeichnet. Außerdem berechnet (228) das SEA-System 32 kombinierte Ereignisdaten basierend auf dem mindestens einen bestimmten Ereignis und der historischen Aggregation. In diesem Beispiel sind die kombinierten Ereignisdaten die Nahezu-Echtzeit-Aggregation für das bestimmte Ereignis für einen bestimmten Abonnenten.
Die Nahezu-Echtzeit-Aggregation basiert auf der historischen Aggregation (für diese bestimmte Art von Ereignis für diesen bestimmten Abonnenten) und den inkrementellen Ereignissen (für diese bestimmte Ereignisart für diesen bestimmten Abonnenten), die seit der letzten Batch-Berechnung der Ereignisaggregation in dem Echtzeitdatenstrom empfangen worden sind. Zu einem Zeitpunkt, zu dem die kombinierten Ereignisdaten berechnet werden, kann das inkrementelle Ereignis zu diesem Zeitpunkt in den Nahezu-Echtzeitdatenströmen empfangen werden, oder in dem Speicher des SEA-Systems 32 gespeichert werden, wenn die kombinierten Ereignisdaten berechnet werden, nachdem das inkrementelle Ereignis in den Nahezu-Echtzeit Datenströmen empfangen wurde, aber bevor das inkrementelle Ereignis in einem EDW gespeichert wird. Diese Nahezu-Echtzeit-Aggregation wird zusammen mit den anderen oben beschriebenen Anreicherungen in den umfassenden Datensatz für das entsprechende Ereignis eingefügt. Die Regeln (die mehrere Anwendungen und/oder Anwendungen definieren) werden gegen diesen umfassenden Datensatz (der die Ereignisse und Anreicherungen enthält) ausgeführt, z.B. indem die in dem umfassenden Datensatz enthaltenen Unterdatensätze durch eine Regelmaschine, welche die Regeln implementiert, geleitet werden. Das SEA-System 32 bestimmt (229), ob eine oder mehrere der ausgeführten Regeln durch den Inhalt des umfassenden Datensatzes (z.B. durch den Inhalt eines der Unterdatensätze in dem umfassenden Datensatz) erfüllt sind. Bei Erfassung eines Unterdatensatzes (der ein bestimmtes Ereignis für eine bestimmte Entität und zugehörige Anreicherungen und Aggregationen enthält), der die aufschiebende Bedingung einer Regel erfüllt, identifiziert das SEA-System 32 eine Aktion für diese Regel und generiert einen Aktionsauslöser, der Daten enthält, die angeben, welche Aktion ausgeführt werden soll und für welche Entität. Basierend auf den kombinierten Ereignisdaten veröffentlicht (230) das SEA-System 32 den Aktionsauslöser an eine Warteschlange zum Initiieren einer oder mehrerer Aktionen. In diesem Beispiel ist der Aktionsauslöser ein Eintrag in der Warteschlange. Das SEA-System 32 analysiert die Einträge in der Warteschlange (z.B. in einer First-In-First-Out-Reihenfolge) und führt die durch die Aktionsauslöser vorgegebenen Aktionen aus, wie z.B. das Senden einer SMS-Nachricht, die eine Entität auf ein Angebot aufmerksam macht, bzw. initiiert diese.
Nach dem Veröffentlichen des Aktionsauslösers oder wenn das SEA-System 32 feststellt, dass keine der ausgeführten Regeln durch den Inhalt des umfassenden Datensatzes (z.B. durch den Inhalt eines der Unterdatensätze in dem umfassenden Datensatz) erfüllt ist, bestimmt (232) das SEA-System 32, ob eine oder mehrere der Anwendungen noch ausgeführt werden. Wenn eine oder mehrere der Anwendungen noch ausgeführt werden, wiederholt das SEA-System 32 die Aktionen 222, 224, 226, 228, 230, 232 z.B. bis zur Beendigung der Anwendung. Wenn die Anwendung nicht mehr ausgeführt wird, stoppt (234) das SEA-System 32 den Prozess 220.
Bezugnehmend auf die 16 veranschaulicht die Umgebung 240 eine beispielhafte Umsetzung von ereignisbasiertem Marketing. In diesem Beispiel führt das SEA-System 32 den Abhörprozess 241 (z.B. auf der Sammel-Engine 42) aus, um intermittierend (z.B. kontinuierlich) einen oder mehrere Echtzeitdatenströme abzuhören, zu empfangen und zu verarbeiten. Der Abhörprozess 241 empfängt und verarbeitet die inkrementellen Daten 242 für eine bestimmte Ereignisart für einen bestimmten Abonnenten (z.B. den aktuellen SMS-Verbrauch von 1 Nachricht). Zum Berechnen der Nahezu-Echtzeit-Aggregationen ruft das SEA-System 32 Batch-Daten 248 ab für die Art des in inkrementellen Daten 242 dargestellten Ereignisses (z.B. ein SMS-Ereignis). In diesem Beispiel enthalten die Batch-Daten 248 eine historische Aggregation des SMS-Verbrauchs für die Entität, die den inkrementellen Daten 242 zugeordnet ist. In diesem Beispiel berechnet das SEA-System 32 den aggregierten SMS-Verbrauch 254 (für die bestimmte Entität, die den Daten 242, 248 zugeordnet ist) durch Aggregieren der inkrementellen Daten 242 mit den Batch-Daten 248. In einer Abwandlung kann das SEA-System 32 außerdem auf zusätzliche inkrementelle Daten für den SMS-Verbrauch aus dem Speicher des SEA-Systems 32 zugreifen, beispielsweise wenn zuvor neue inkrementelle Daten empfangen wurden, das SEA-System 32 jedoch seinen Batch-Prozess zur Speicherung dieser neu empfangenen Daten in einem EDW noch nicht ausgeführt hat. In dieser Variante generiert das SEA-System 32 die nahezu in Echtzeit aggregierten SMS-Verbrauchsdaten 254, indem es die inkrementellen Daten 242, die Batch-Daten 248 und die zusätzlichen, im Speicher gespeicherten inkrementellen Daten aggregiert.
Das SEA-System 32 berechnet außerdem den aggregierten Sprachverbrauch 258 (für die den Daten 242 zugeordnete bestimmte Entität), indem es inkrementelle Sprachverbrauchs-daten (wie im Speicher des SEA-Systems 32 gespeichert) mit Batch-Sprachverbrauchsdaten (aus einem EDW abgerufen) aggregiert. Das SEA-System 32 berechnet außerdem die aggregierten Daten-Verbrauchsdaten 259 (für die den Daten 242 zugeordnete bestimmte Entität), indem es den inkrementellen Datenverbrauch (wie im Speicher des SEA-Systems 32 gespeichert) mit dem Batch-Datenverbrauch (aus einem EDW abgerufen) aggregiert. Das SEA-System berechnet den aggregierten Sprachverbrauch 258 und die aggregierten Daten-Verbrauchsdaten 259 für die Aufnahme in den Ereignisdatensatz 260, damit der Ereignisdatensatz 260 von einer Anwendung verwendet werden kann, in der bestimmte Aktionen von Schwellenwerten für den aggregierten Daten- und/oder Sprachverbrauch abhängig sind.
Das SEA-System 32 generiert den Ereignisdatensatz 260, in dem es Folgendes in den Ereignisdatensatz 260 einfügt: das Abonnenten-ID-Feld 242, das Ereignisart-Feld 244, den Sprachereignis-Unterdatensatz 246, den SMS-Ereignis-Unterdatensatz 250 (der das aktuelle SMS-Verbrauchsereignis 242 enthält), den Datenereignis-Unterdatensatz 251, den Abonnentenprofil-Unterdatensatz 252, den Anreicherungs-Unterdatensatz 253, und den Anwendungsstatus-Unterdatensatz 261, wobei jeder dieser Arten von Unterdatensätzen zuvor mit Bezug auf die 3 beschrieben wurde. In diesem Beispiel enthält der Anreicherungs-Unterdatensatz 253 die aggregierten SMS-Verbrauchsdaten 254, die aggregierte Sprachverbrauchsdaten 258 und die aggregierten Datenverbrauchsdaten 259. In diesem Beispiel ist das aktuelle SMS-Verbrauchsereignis 242 in dem SMS-Ereignis-Unterdatensatz 250 gespeichert.
In diesem Beispiel führt das SEA-System 32 eine Erfassungs-Engine aus 269, um eine oder mehrere Anwendungen gegen den Ereignisdatensatz 260 auszuführen, um festzustellen, welche aufschiebenden Bedingungen der Regeln in der einen oder den mehreren Anwendungen durch den Ereignisdatensatz 260 erfüllt sind. In diesem Beispiel erfasst das SEA-System 32, dass das aktuelle SMS-Verbrauchsereignis 242 in dem SMS-Ereignis-Unterdatensatz 250 eine der Vorbedingungen einer Regel in einer Anwendung zum Upgrade von Kunden erfüllt. Basierend auf dieser Erfassung generiert das SEA-System 32 einen Aktionsauslöser 268, um die vorgegebene Aktion auszuführen. In diesem Beispiel gibt der Aktionsauslöser 268 eine Aktion vor, bei der ein Kunde per E-Mail kontaktiert und über eine Werbeaktion zur Aktualisierung des Dienstes informiert wird. Das SEA-System 32 führt den Aktionsauslöser aus, um zu bewirken, dass die E-Mail 270 an den Benutzer gesendet wird.
Bezugnehmend auf die 17 wird der Prozess 300 durch ein Such- und Retrieval-Datenverarbeitungssystem zum Verarbeiten von Daten durchgeführt. Im Betrieb empfängt (302) das System intermittierend Daten aus einem oder mehreren Datenströmen, wobei die empfangenen Daten Datensätze umfassen. Während weiterhin Daten aus dem einen Datenstrom oder den mehreren Datenströmen empfangen werden, erfasst (304) das System zwei oder mehr bestimmte Datensätze in den empfangenen Datensätzen, wobei die erfassten zwei oder mehr bestimmten Datensätze jeweils eine bestimmte Kennung umfassen. In diesem Beispiel erfasst das System mit einem Schlüssel versehene Datensätze, z.B. Datensätze, die einer bestimmten Kennung oder einem bestimmten Schlüssel zugeordnet sind. Für diese bestimmte Kennung erstellt (306) das System eine Sammlung von Datensätzen, welche die erfassten zwei oder mehr bestimmten Datensätze umfassen. Für mindestens einen bestimmten, in der Sammlung von Datensätzen enthaltenen Datensatz sucht (308) das System Datensätze in einem Daten-Repository (und/oder Daten, die gecacht oder im Speicher zwischengespeichert sind) für eine historische Aggregation von der jeweiligen Kennung zugeordneten Daten, wobei die historische Aggregation eine vorberechnete Datenaggregation aus einer vorangegangenen Zeitspanne ist. Das System berechnet (310) kombinierte Daten basierend auf dem mindestens einen bestimmten Datensatz und auf der historischen Aggregation. In diesem Beispiel enthalten die kombinierten Daten eine Erweiterung, da die aus den Echtzeitdatenströmen empfangenen Daten diese kombinierten Daten nicht enthalten.
Das System modifiziert (312) außerdem einen Datensatz durch Einfügen der kombinierten Daten in ein Feld des Datensatzes und durch das Einfügen von Daten aus mindestens einem der Datensätze in der Sammlung in ein anderes Feld des Datensatzes. Beispielsweise kann der modifizierte Datensatz einen Datensatz aller Ereignisse enthalten, z.B. den Ereignisdatensatz 60 (3). In diesem Beispiel können die kombinierten Daten Sprachaggregationsdaten sein und in den Anreicherungs-Unterdatensatz 62g eingefügt werden. In diesem Beispiel ist der Anreicherungs-Unterdatensatz ein Feld in dem Ereignisdatensatz 60. In einem anderen Beispiel kann der modifizierte Datensatz einen Datensatz mit Feldern enthalten, die mit anderen Datensätzen oder anderen empfangenen oder berechneten Daten zu füllen sind. Das System fügt außerdem Daten von mindestens einem der Datensätze in der Sammlung in ein anderes Feld des Datensatzes ein. Wenn beispielsweise einer der Datensätze, die in der Sammlung enthalten sind, ein Sprache-Datensatz ist, den Ort, die Dauer und den Zeitpunkt des Empfangs eines Sprachanrufs angibt, fügt das System diese Daten aus dem Sprach-Datensatz in das Feld 62c des Datensatzes 60 ein. In diesem Beispiel kann das System dem Datensatz außerdem weitere Anreicherungen oder Erweiterungen hinzufügen - z.B. als Profildaten - die in das Feld 62f des Datensatzes 60 eingefügt werden.
Das System verarbeitet außerdem den modifizierten Datensatz durch Anwenden einer oder mehrerer Regeln auf den modifizierten Datensatz. Basierend auf dem Anwenden der Regeln schreibt (314) das System einen oder mehrere Befehle zum Initiieren einer oder mehrerer Aktionen in den Speicher des Systems. In einigen Beispielen enthält ein Befehl einen Aktionsauslöser. Das System veröffentlicht (316) den einen oder die mehreren Befehle in eine Warteschlange zum Initiieren der einen oder der mehreren Aktionen.
Unter Verwendung der hier beschriebenen Techniken definiert eine Ereignispalette verschiedene Arten von Ereignissen (z.B. SMS, Sprache, Daten etc.) auf verschiedenen Ebenen (z.B. einer Händlerebene, einer Abonnentenebene etc.). Unter Verwendung dieser vordefinierten Ereignisse kann ein Benutzer (z.B. ein Analyst) Regeln definieren, die bei Erfüllung eines oder mehrerer der in der Ereignispalette definierten Ereignisse ausgeführt werden sollen. Damit ein einziges System mehrere Anwendungen ausführen kann, die Regeln für diese verschiedenen Arten von Ereignissen und Betriebsebenen enthalten, generiert das System einen umfassenden Datensatz der in der Ereignispalette enthaltenen Ereignisse und reichert diese Ereignisse mit Profildaten und Aggregationen an, um eine Nahezu-Echtzeit-Anwendung bereitzustellen, die Nahezu-Echtzeit-Aggregationen implementieren kann.
Anstatt eine Batch-Anwendung zu implementieren, kann die Echtzeitanwendung, die unter Verwendung der hierin beschriebenen Techniken ausgeführt wird, eine Mehrfachereignis- Anwendung sein, die Aggregations-Historien in Echtzeit für große Datenvolumen und niedrige Latenzzeit generiert. Durch die Nahezu-Echtzeit-Verarbeitung der Daten über kontinuierliche Datenflüsse, die Generierung des umfassenden Datensatzes und den Aufbau der Aggregate sowohl im Batch als auch inkrementell, ist das hier beschriebene System in der Lage, Daten effizienter und schneller zu aggregieren und eine Anwendung mit einer geringeren Latenzzeit bei der Ausführung von Mehrfachereignis-Anwendungen mit Nahezu-Echtzeit Aggregationen auszuführen. In einem Beispiel generiert und berechnet das System einen Datensatz (z.B. einen umfassenden Datensatz) von Ereignissen, Anreicherungen (z.B. Profilinformationen) und Aggregationen für einen bestimmten Schlüssel, z.B. vor dem Veröffentlichen des Datensatzes in eine Anwendung. Dadurch ist das System zur Laufzeit rechentechnisch effizienter, wenn die Anwendungen ausgeführt und auf die generierten Datensätze angewendet werden, beispielsweise weil das System bereits Aggregationen vorausberechnet und Profilinformationen abgefragt hat und diese vorausberechneten Informationen zur Verarbeitung in den Datensatz aufgenommen hat und dadurch bei der Ausführung der Anwendungen keine Latenzzeit in die Verarbeitung einbringen muss. Insbesondere ermöglichen dem System die Vorausberechnung der Aggregationen, das Vorabgenerieren und Kompilieren von Unterdatensätzen und das Generieren eines einzigen Datensatzes, der alle Felder (einschließlich Felder für Aggregationen) und Unterdatensätze für Daten und Ereignisse enthält, zu deren Analyse das System für die Ereigniserfassung konfiguriert ist, und die Vorausbelegung mindestens einiger dieser Felder mit den vorberechneten Aggregationen oder mit Echtzeit-Aggregationen (basierend auf der Aggregation der inkrementellen Daten mit den vorausberechneten Aggregationen) einen einzigen umfassenden Datensatz für die Datenverarbeitung zu produzieren, anstatt dass das System auf Daten zugreifen und diese abrufen und Aggregationen berechnen muss, während die Verarbeitung der Datensätze durchgeführt wird und während Datensätze empfangen werden. Diese Generierung des einzelnen Datensatzes mit allen Feldern und Unterdatensätzen ermöglicht einen effizienteren Datenzugriff und eine effizientere Datenverarbeitung durch das System, verglichen mit der Effizienz des Zugreifens auf Daten aus einem Data Warehouse zur Laufzeit und das Berechnen von Aggregationen zur Laufzeit. Unter Verwendung der hier beschriebenen Techniken veröffentlicht das System diesen generierten Datensatz (d.h. den einzelnen Datensatz) an eine Warteschlange zur Verarbeitung durch das System und verringert dadurch die Laufzeitlatenz bei der Verarbeitung von Datensätzen.
Die oben beschriebenen Techniken können unter Verwendung von Software zur Ausführung auf einem Computer implementiert werden. Beispielsweise bildet die Software Prozeduren in einem oder mehreren Computerprogrammen, die auf einem oder mehreren programmierten oder programmierbaren Computersystemen (die verschiedene Architekturen aufweisen können, wie z.B. verteilt, Client/Server oder Grid) ausgeführt werden, die jeweils mindestens einen Prozessor, mindestens ein Datenspeichersystem (einschließlich flüchtiger und nichtflüchtiger Speicher und/oder Speicherelemente), mindestens ein Eingabegerät oder einen Eingabeport und mindestens ein Ausgabegerät oder einen Ausgabeport umfassen. Die Software kann beispielsweise ein oder mehrere Module eines größeren Programms bilden, das andere Dienstleistungen im Zusammenhang mit dem Entwurf und der Konfiguration von Datenflussgraphen bereitstellt. Die Knoten und Elemente des Graphen können implementiert werden als Datenstrukturen, die in einem computerlesbaren Medium gespeichert sind, oder als andere organisierte Daten, die einem in einem Daten-Repository gespeicherten Datenmodell entsprechen.
Die Software kann bereitgestellt werden auf einem Speichermedium und/oder einer Hardware-Speichervorrichtung, wie etwa einer CD-ROM, das/die durch einen programmierbaren Universal- oder Spezialcomputer lesbar ist, oder kann über ein Kommunikationsmedium eines Netzwerks (codiert in einem propagierten Signal) auf ein Speichermedium des Computers, auf dem es ausgeführt wird, übertragen werden. Alle Funktionen können auf einem Spezialcomputer oder mit Spezialhardware, wie z.B. Koprozessoren, ausgeführt werden. Die Software kann auf eine verteilte Art implementiert werden, bei der verschiedene Teile der durch die Software vorgegebenen Berechnung von verschiedenen Computern ausgeführt werden. Jedes derartige Computerprogramm wird vorzugsweise auf einem Speichermedium oder -gerät (z.B. Festkörperspeicher oder -medien oder magnetische oder optische Medien), das durch einen programmierbaren Universal- oder Spezialcomputer lesbar ist, gespeichert, oder auf dieses heruntergeladen, um den Computer zu konfigurieren und zu betreiben, wenn das Speichermedium oder -gerät von dem Computersystem gelesen wird, um die hier beschriebenen Prozeduren auszuführen. Es kann auch in Betracht gezogen werden, dass das erfindungsgemäße System implementiert wird als ein computerlesbares Speichermedium, das mit einem Computerprogramm konfiguriert wird, wobei das so konfigurierte Speichermedium bewirkt, dass ein Computersystem in einer spezifischen und vordefinierten Weise arbeitet, um die hierin beschriebenen Funktionen auszuführen.
Mehrere Ausführungsformen der Erfindung wurden beschrieben. Es versteht sich jedoch, dass verschiedene Abwandlungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Beispielsweise können einige der oben beschriebenen Schritte unabhängig von der Reihenfolge sein und somit in einer anderen Reihenfolge als der beschriebenen ausgeführt werden. Darüber hinaus sind die vorhergehenden Beispiele und Techniken für mehrere unterschiedliche Anwendungen breit einsetzbar.
Es versteht sich, dass die vorhergehende Beschreibung den Umfang der Erfindung, der durch den Umfang der beigefügten Ansprüche definiert ist, veranschaulichen und nicht einschränken soll. Beispielsweise können einige der oben beschriebenen Funktionsschritte in einer anderen Reihenfolge ausgeführt werden, ohne die Gesamtverarbeitung wesentlich zu beeinflussen. Andere Ausführungen liegen innerhalb des Umfangs der nachfolgenden Ansprüche.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 9002770 [0004]
US 6654907 [0024]
US 5966072 [0058]

Claims

Ein Verfahren, das von einem Datenverarbeitungssystem zum Verarbeiten von Daten durchgeführt wird, wobei das Verfahren Folgendes umfasst: das intermittierende Empfangen von Daten aus einem oder mehreren Datenströmen, wobei die empfangenen Daten Datensätze umfassen; während weiterhin Daten aus dem einen Datenstrom oder den mehreren Datenströmen empfangen werden, das Erfassen von zwei oder mehr bestimmten Datensätzen in den empfangenen Datensätzen, wobei die erfassten zwei oder mehr bestimmten Datensätze jeweils eine bestimmte Kennung umfassen; für diese bestimmte Kennung das Erstellen einer Sammlung von Datensätzen, welche die erfassten zwei oder mehr bestimmten Datensätze umfassen; für mindestens einen bestimmten, in der Sammlung von Datensätzen enthaltenen Datensatz, das Durchsuchen von Datensätzen für eine historische Aggregation von Daten, die der bestimmten Kennung zugeordnet sind, wobei die historische Aggregation eine vorberechnete Datenaggregation aus einer vorangegangenen Zeitspanne ist; und das Berechnen kombinierter Daten basierend auf dem mindestens einen bestimmten Datensatz und auf der historischen Aggregation; das Modifizieren eines Datensatzes durch Einfügen der kombinierten Daten in ein Feld des Datensatzes und durch das Einfügen von Daten aus mindestens einem der Datensätze in der Sammlung in ein anderes Feld des Datensatzes; das Verarbeiten des modifizierten Datensatzes durch Anwenden einer oder mehrerer Regeln auf den modifizierten Datensatz; basierend auf dem Anwenden der Regeln, das Schreiben eines oder mehrerer Befehle zum Initiieren einer oder mehrerer Aktionen in den Speicher und das Veröffentlichen des einen oder der mehreren Befehle in eine Warteschlange zum Initiieren der einen oder der mehreren Aktionen.
Verfahren nach Anspruch 1, wobei das Einfügen der Daten aus dem mindestens einen der Datensätze in der Sammlung in das andere Feld des Datensatzes Folgendes umfasst: das Einfügen von Daten aus dem mindestens einen bestimmten Datensatz, der in der Sammlung enthalten ist, in das andere Feld des durch Einfügen modifizierten Datensatzes.
Verfahren nach Anspruch 1, wobei die Sammlung von Datensätzen ein erster Datensatz ist, der Daten aus den Datensätzen enthält, und wobei das Verfahren ferner Folgendes umfasst: das Sammeln einer Vielzahl von Datensätzen; das Veröffentlichen der Datensätze in eine einzige Warteschlange; das Erfassen der zwei oder mehr bestimmten Datensätze aus der Warteschlange; das Zusammenfügen der zwei oder mehr bestimmten Datensätze in den ersten Datensatz, wobei die zwei oder mehr bestimmten Datensätze Daten umfassen, die unterschiedliche Arten von Ereignissen repräsentieren, und das Ergänzen des ersten Datensatzes mit den kombinierten Daten für den mindestens einen bestimmten Datensatz.
Verfahren nach Anspruch 1, wobei die vorangegangene Zeitspanne eine Zeitspanne vor dem Durchführen des Erfassens ist.
Verfahren nach Anspruch 1, ferner Folgendes umfassend: das Anhängen von Kundenprofildaten für einen Kunden, der einem bestimmten Ereignis, das in dem ersten Datensatz enthalten ist, zugeordnet ist, an den ersten Datensatz und das Anhängen einer anhängbaren Nachschlagedatei („appendable lookup file“, ALF) mit einer historischen Aggregation für das bestimmte Ereignis an den ersten Datensatz.
Verfahren nach Anspruch 1, wobei das Berechnen der kombinierten Daten Folgendes umfasst: das Hinzufügen von inkrementellen Daten zu der historischen Aggregation, wobei die inkrementellen Daten Daten von einem Zeitpunkt, zu dem die historische Aggregation berechnet wurde, bis zu einem nahezu gegenwärtigen Zeitpunkt, der innerhalb einer Minute vor dem gegenwärtigen Zeitpunkt liegt, umfassen, und basierend auf dem Hinzufügen der inkrementellen Daten, das Herstellen einer Nahezu-Echtzeit-Aggregation der Daten.
Verfahren nach Anspruch 1, ferner Folgendes umfassend: das Empfangen von Daten, die eine oder mehrere Regeln, welche eine Anwendung definieren, repräsentieren, von einer Client-Vorrichtung eines Benutzers; basierend auf den empfangenen Daten das Generieren der einen oder der mehreren Regeln, welche die Anwendung definieren und basierend auf dem Ausführen der einen oder mehreren Regeln, das Implementieren der Anwendung gegen den einen intermittierend empfangenen Datenstrom bzw. die mehreren intermittierend empfangenen Datenströme.
Verfahren nach Anspruch 1, wobei das Empfangen des einen oder der mehreren Datenströme Folgendes umfasst: das Empfangen eines ersten Datenstroms mit Daten, die eine erste Ereignisart repräsentieren und das Empfangen eines zweiten Datenstroms mit Daten, die eine zweite Ereignisart repräsentieren.
Verfahren nach Anspruch 1, ferner das Ausführen einer oder mehrerer Anwendungen gegen einen veröffentlichten Aktionsauslöser, der in dem einen oder den mehreren Befehlen enthalten ist.
Verfahren nach Anspruch 1, wobei ein Datensatz ein Ereignis enthält.
Verfahren nach Anspruch 1, wobei das Suchen das Suchen in einem Daten-Repository oder das speicherinterne Suchen umfasst.
Ein Datenverarbeitungssystem zum Verarbeiten von Daten, Folgendes umfassend: einen oder mehrere Prozessoren und eine oder mehrere maschinenlesbare Hardware-Speichervorrichtungen, die Befehle speichern, welche ausführbar sind, um zu bewirken, dass der eine oder die mehreren Prozessoren Operationen ausführt bzw. ausführen, die Folgendes umfassen: das intermittierende Empfangen von Daten aus einem oder mehreren Datenströmen, wobei die empfangenen Daten Datensätze umfassen; während weiterhin Daten aus dem einen Datenstrom oder den mehreren Datenströmen empfangen werden, das Erfassen von zwei oder mehr bestimmten Datensätzen in den empfangenen Datensätzen, wobei die erfassten zwei oder mehr bestimmten Datensätze jeweils eine bestimmte Kennung umfassen; für diese bestimmte Kennung das Erstellen einer Sammlung von Datensätzen, welche die erfassten zwei oder mehr bestimmten Datensätze umfassen; für mindestens einen bestimmten, in der Sammlung von Datensätzen enthaltenen Datensatz das Durchsuchen von Datensätzen für eine historische Aggregation von Daten, die der bestimmten Kennung zugeordnet sind, wobei die historische Aggregation eine vorberechnete Datenaggregation aus einer vorangegangenen Zeitspanne ist und das Berechnen kombinierter Daten basierend auf dem mindestens einen bestimmten Datensatz und auf der historischen Aggregation; das Modifizieren eines Datensatzes durch Einfügen der kombinierten Daten in ein Feld des Datensatzes und durch das Einfügen von Daten aus mindestens einem der Datensätze in der Sammlung in ein anderes Feld des Datensatzes; das Verarbeiten des modifizierten Datensatzes durch Anwenden einer oder mehrerer Regeln auf den modifizierten Datensatz; basierend auf dem Anwenden der Regeln, das Schreiben eines oder mehrerer Befehle zum Initiieren einer oder mehrerer Aktionen in den Speicher und das Veröffentlichen des einen oder der mehreren Befehle in eine Warteschlange zum Initiieren der einen oder der mehreren Aktionen.
System nach Anspruch 12, wobei das Einfügen der Daten aus dem mindestens einen der Datensätze in der Sammlung in das andere Feld des Datensatzes Folgendes umfasst: das Einfügen von Daten aus dem mindestens einen bestimmten Datensatz, der in der Sammlung enthalten ist, in das andere Feld des durch Einfügen modifizierten Datensatzes.
System nach Anspruch 12, wobei die Sammlung von Datensätzen ein erster Datensatz ist, der Daten aus den Datensätzen enthält, und wobei die Operationen ferner Folgendes umfassen: das Sammeln einer Vielzahl von Datensätzen; das Veröffentlichen der Datensätze in eine einzige Warteschlange; das Erfassen der zwei oder mehr bestimmten Datensätze aus der Warteschlange; das Zusammenfügen der zwei oder mehr bestimmten Datensätze in den ersten Datensatz, wobei die zwei oder mehr bestimmten Datensätze Daten umfassen, die unterschiedliche Arten von Ereignissen repräsentieren, und das Ergänzen des ersten Datensatzes mit den kombinierten Daten für den mindestens einen bestimmten Datensatz.
System nach Anspruch 12, wobei die vorangegangene Zeitspanne eine Zeitspanne vor dem Durchführen des Erfassens ist.
System nach Anspruch 12, wobei die Operationen ferner Folgendes umfassen: das Anhängen von Kundenprofildaten für einen Kunden, der einem bestimmten Ereignis, das in dem ersten Datensatz enthalten ist, zugeordnet ist, an den ersten Datensatz und das Anhängen einer anhängbaren Nachschlagedatei („appendable lookup file“, ALF) mit einer historischen Aggregation für das bestimmte Ereignis an den ersten Datensatz.
System nach Anspruch 12, wobei das Berechnen der kombinierten Daten Folgendes umfasst: das Hinzufügen von inkrementellen Daten zu der historischen Aggregation, wobei die inkrementellen Daten Daten von einem Zeitpunkt, zu dem die historische Aggregation berechnet wurde, bis zu einem nahezu gegenwärtigen Zeitpunkt, der innerhalb einer Minute von dem gegenwärtigen Zeitpunkt liegt, umfassen und basierend auf dem Hinzufügen der inkrementellen Daten das Herstellen einer Nahezu-Echtzeit-Aggregation der Daten.
Maschinenlesbare Hardware-Speichervorrichtung oder mehrere maschinenlesbare Hardware-Speichervorrichtungen, die Befehle speichern, welche ausführbar sind, um zu bewirken, dass der eine oder die mehreren Prozessoren Operationen ausführt bzw. ausführen, die Folgendes umfassen: das intermittierende Empfangen von Daten aus einem oder mehreren Datenströmen, wobei die empfangenen Daten Datensätze umfassen; während weiterhin Daten aus dem einen Datenstrom oder den mehreren Datenströmen empfangen werden, das Erfassen von zwei oder mehr bestimmten Datensätzen in den empfangenen Datensätzen, wobei die erfassten zwei oder mehr bestimmten Datensätze jeweils eine bestimmte Kennung umfassen; für diese bestimmte Kennung das Erstellen einer Sammlung von Datensätzen, welche die erfassten zwei oder mehr bestimmten Datensätze umfassen; für mindestens einen bestimmten, in der Sammlung von Datensätzen enthaltenen Datensatz das Durchsuchen von Datensätzen für eine Aggregation von historischen, der jeweiligen Kennung zugeordneten Daten, wobei die historische Aggregation eine vorberechnete Datenaggregation aus einer vorangegangenen Zeitspanne ist, und das Berechnen kombinierter Daten basierend auf dem mindestens einen bestimmten Datensatz und auf der historischen Aggregation; das Modifizieren eines Datensatzes durch Einfügen der kombinierten Daten in ein Feld des Datensatzes und durch das Einfügen von Daten aus mindestens einem der Datensätze in der Sammlung in ein anderes Feld des Datensatzes; das Verarbeiten des modifizierten Datensatzes durch Anwenden einer oder mehrerer Regeln auf den modifizierten Datensatz; basierend auf dem Anwenden der Regeln, das Schreiben eines oder mehrerer Befehle zum Initiieren einer oder mehrerer Aktionen in den Speicher, und das Veröffentlichen des einen oder der mehreren Befehle in eine Warteschlange zum Initiieren der einen oder der mehreren Aktionen.
Maschinenlesbare Hardware-Speichervorrichtung oder mehrere maschinenlesbare Hardware-Speichervorrichtungen nach Anspruch 18, wobei das Einfügen der Daten aus dem mindestens einen der Datensätze in der Sammlung in das andere Feld des Datensatzes Folgendes umfasst: das Einfügen von Daten aus dem mindestens einen bestimmten Datensatz, der in der Sammlung enthalten ist, in das andere Feld des durch Einfügen modifizierten Datensatzes.
Maschinenlesbare Hardware-Speichervorrichtung oder mehrere maschinenlesbare Hardware-Speichervorrichtungen nach Anspruch 18, wobei die Sammlung von Datensätzen ein erster Datensatz ist, der Daten aus den Datensätzen enthält, und wobei die Operationen ferner Folgendes umfassen: das Sammeln einer Vielzahl von Datensätzen; das Veröffentlichen der Datensätze in eine einzige Warteschlange; das Erfassen der zwei oder mehr bestimmten Datensätze aus der Warteschlange; das Zusammenfügen der zwei oder mehr bestimmten Datensätze in den ersten Datensatz, wobei die zwei oder mehr bestimmten Datensätze Daten umfassen, die unterschiedliche Arten von Ereignissen repräsentieren, und das Ergänzen des ersten Datensatzes mit den kombinierten Daten für den mindestens einen bestimmten Datensatz.