Blog
Online-Erstellung von Daten für die Verarbeitung von Ereignisströmen

In vielen Geschäftsfällen, die wir bei Getindata in Zusammenarbeit mit unseren Kunden lösen, müssen wir Sitzungen analysieren: eine Reihe von zusammenhängenden Ereignissen von Akteuren, um Korrelationen oder Muster im Verhalten der Akteure zu finden. Einige dieser Fälle sind:
- Analyse von Benutzer-Web-Sitzungen für die Webanalyse.
- Trichteranalyse, Kohortenanalyse und vieles mehr, um zu verstehen, wie Produktnutzer mit dem Produkt interagieren, sich verhalten, konvertieren oder aussteigen.
- Erkennung von Betrug, Anomalien oder Bedrohungen, um diese schnell zu verhindern.
- Produktempfehlungen, Anregungen und vieles mehr...
Dies ist im Allgemeinen überall dort der Fall, wo Verhaltensanalysen eingesetzt werden.
Damit die Anwendungsfälle erforscht und Anwendungen entwickelt werden können, müssen wir Testdaten für Experimente, Funktionstests, Leistungstests, Demos und so weiter erstellen.
Zufallsgenerierte Ereignisse, die von den meisten Datengeneratoren erzeugt werden, sind nicht ausreichend. Die erzeugten Daten haben keinen Bezug. Es gibt keine Akteurssitzungen. Es gibt jedoch ein paar Projekte, die versucht haben, dieses Problem anzugehen. Eines davon ist GitHub - Interana/eventsim, das leider vor ein paar Jahren aufgegeben wurde.
Wie kann also eine Lösung aussehen, die die genannten Anwendungsfälle unterstützt? Wir können mit der Modellierung des Verhaltens der Akteure beginnen - was der Akteur tun kann und wie er sich im Laufe der Zeit entwickeln kann. So etwas kann als Zustandsautomat ausgedrückt werden.
Es fehlen noch einige Dinge. Zunächst einmal wollen wir nicht einfach nur einen Zustandsautomaten haben und dann Übergänge durch das Schreiben von Codezeilen aufrufen, denn dann würden wir wieder dort landen, wo wir angefangen haben. Wir möchten, dass unser Zustandsautomat auf der Grundlage einer bestimmten Wahrscheinlichkeit automatisch einen Übergang ausführt.
Anwendungsfall der Stream-Verarbeitung
Nehmen wir ein Beispiel, bei dem wir an der Mustererkennung arbeiten. Wir versuchen, Nutzer von Bankanwendungen zu finden, die über die Aufnahme eines Kredits nachgedacht, ihn aber nicht aufgenommen haben. Wir versuchen, Nutzer mit geringem Guthaben zu finden, die eine Kreditseite geöffnet und diese wieder verlassen haben, ohne einen Kredit aufzunehmen. Das Modell einer solchen Interaktion mit der Anwendung könnte so aussehen:

Der Benutzer kann sich bei einer Anwendung anmelden und wenn er online ist, kann er einen Kreditbildschirm öffnen oder die Anwendung verlassen. Vom Kreditbildschirm aus können sie entweder einen Kredit aufnehmen oder die Anwendung verlassen.
Aber was bedeuten 0,1% Wahrscheinlichkeit? Das ist die Wahrscheinlichkeit, dass unser Zustandsautomat diesen Übergang bei jedem Schritt automatisch durchführt. Wenn wir eine reale Dauer eines Schritts festlegen, z.B. 1 Minute. Eine Wahrscheinlichkeit von 0,1% würde bedeuten, dass sich der Benutzer im Durchschnitt einmal in 17 Stunden anmeldet. Oder anders ausgedrückt, in jeder Minute wird sich 1 von 1000 Benutzern anmelden.
Damit können wir einen Klickstrom von Benutzeraktionen erzeugen. Aber was ist mit dem Gleichgewicht? Sie lässt sich nicht einfach in einem endlichen Automaten ausdrücken. Wir könnten darüber nachdenken, eine neue Gruppe von Zuständen hinzuzufügen Offline low balance, Online low balance,Loan Screen low balance aber es sieht wie eine Verdoppelung aus und es wird noch unübersichtlicher, wenn wir etwas Zusätzliches hinzufügen wollen, wie zum Beispiel einen Kreditsaldo.

Da das Gleichgewicht die Menge der möglichen Aktionen nicht beeinflusst, sollte es nicht als Zustand modelliert werden. Es ist lediglich ein Attribut eines bestimmten Benutzers, der unseren Zustandsautomaten durchläuft, dessen Wert ausgegeben werden kann, wenn wir bei Übergängen Ereignisse erzeugen. Mit Hilfe von Attributen können wir zu unserem einfacheren Zustandsautomaten zurückkehren, aber diesmal angereichert mit neuen Aktionen, die nicht den Zustand, sondern den Wert der Attribute ändern. Wie können wir Daten generieren, die für die Stream-Verarbeitung geeignet sind?

Daten Online Generator
Wir haben ein Tool entwickelt, das all diese Aufgaben übernimmt Data Online Generator GitHub - getindata/doge-datagen kann das Verhalten von Benutzern, Systemen oder anderen Akteuren auf der Grundlage eines probabilistischen Modells simuliert werden. Es handelt sich um einen Zustandsautomaten, der von mehreren Subjekten automatisch auf der Grundlage der für jeden möglichen Übergang definierten Wahrscheinlichkeit durchlaufen wird.
Um den obigen Zustandsautomaten auszudrücken, müssen wir eine Liste der Zustände, den Anfangszustand, eine Fabrik zur Erzeugung des Anfangszustands der Benutzer, die Anzahl der Benutzer, die Ticklänge und die Anzahl der zu simulierenden Ticks definieren. Dann müssen wir jeden Übergang, seinen Namen, den Anfangs- und Endzustand, die Wahrscheinlichkeit des Übergangs und optionale Rückrufe und Senken definieren. Der Callback wird während des Übergangs aufgerufen und ermöglicht die Änderung von Benutzerattributen. Er kann auch dazu verwendet werden, bedingte Übergänge zu implementieren. Wenn False zurückgegeben wird, wird der Zustandsautomat am Übergang gehindert. Zum Beispiel können wir den Übergang von Spending blockieren, wenn der Saldo Null ist. Ereignissenken werden verwendet, um Ereignisse während einer Transition zu erzeugen. Derzeit wird DOGE-datagen mit Senken für Datenbank und Kafka ausgeliefert.
datagen = DataOnlineGenerator(['offline', 'online', 'loan_screen'], 'offline', UserFactory(), 10, 60000, 1000, 1644549708000)
datagen.add_transition('income', 'offline', 'offline', 0.01,
action_callback=income_callback, event_sinks=[balance_sink])
datagen.add_transition('spending', 'offline', 'offline', 0.1,
action_callback=spending_callback, event_sinks=[trx_sink, balance_sink])
datagen.add_transition('login', 'offline', 'online', 0.1, event_sinks=[clickstream_sink])
datagen.add_transition('logout', 'online', 'offline', 70, event_sinks=[])
datagen.add_transition('open_loan_screen ', 'online', 'loan_screen', 30, event_sinks=[clickstream_sink])
datagen.add_transition('close_loan_screen', 'loan_screen', 'online', 40, event_sinks=[clickstream_sink])
datagen.add_transition('take_loan', 'loan_screen', 'online', 10,
action_callback=take_loan_callback, event_sinks=[clickstream_sink, loan_sink, balance_sink])
datagen.start()
Beispielhafte Ausgabe:
$ kafka-avro-console-consumer --topic clickstream --consumer.config ~/.confluent/local.conf --bootstrap-server localhost:9092 --from-beginning
{"user_id":"7","event":"login","timestamp":1644549768000}
{"user_id":"7","event":"open_loan_screen ","timestamp":1644549828000}
{"user_id":"7","event":"take_loan","timestamp":1644550008000}
{"user_id":"1","event":"login","timestamp":1644556668000}
{"user_id":"1","event":"open_loan_screen ","timestamp":1644556728000}
{"user_id":"1","event":"close_loan_screen","timestamp":1644556968000}
{"user_id":"4","event":"login","timestamp":1644559668000}
{"user_id":"4","event":"open_loan_screen ","timestamp":1644559728000}
{"user_id":"4","event":"close_loan_screen","timestamp":1644559788000}
$ kafka-avro-console-consumer --topic trx --consumer.config ~/.confluent/local.conf --bootstrap-server localhost:9092 --from-beginning
{"user_id":"8","amount":75,"timestamp":1644553008000}
{"user_id":"6","amount":47,"timestamp":1644558708000}
{"user_id":"3","amount":42,"timestamp":1644563808000}
{"user_id":"0","amount":85,"timestamp":1644583128000}
{"user_id":"2","amount":40,"timestamp":1644597228000}
{"user_id":"5","amount":18,"timestamp":1644601308000}
postgres=# select * from balance;
timestamp | user_id | balance
---------------+---------+---------
1644550008000 | 7 | 10933
1644553008000 | 8 | 409
1644558708000 | 6 | 320
1644563808000 | 3 | 577
1644583128000 | 0 | 259
1644597228000 | 2 | 697
1644601308000 | 5 | 702
postgres=# select * from loan;
timestamp | user_id | loan
---------------+---------+-------
1644550008000 | 7 | 10000
Fazit
Data Online Generator kann nicht nur während der Entwicklung und beim Experimentieren verwendet werden, sondern auch als Teil automatisierter Testpipelines. Er ist so konzipiert, dass er flexibel ist, um viele Anwendungsfälle zu unterstützen. Außerdem ist er erweiterbar und ermöglicht die einfache Implementierung neuer Ereignis-Sinks. Besuchen Sie unseren GitHub, um Beispiele für die Arbeit mit dem Data Online Generator zu sehen.
Wenn Sie an Stream Processing interessiert sind, sollten Sie sich unsere CEP-Plattform ansehen.
Verfasst von
Grzegorz Liter
Unsere Ideen
Weitere Blogs
Contact



