Je suis en train de concevoir un système d'abandon de panier pour une entreprise de commerce électronique. Le système enverra un message à un utilisateur basé sur les règles ci-dessous:
J'utilise Google Cloud Dataflow pour traiter les données et décider si un message doit être envoyé. J'ai quelques options ci-dessous:
Je pense que la fenêtre coulissante pourrait fonctionner ici. Mais ma question est la suivante: peut-il y avoir une solution basée sur l'utilisation d'une fenêtre globale avec un déclencheur basé sur le temps de traitement et un délai pour ce cas d'utilisation? Pour autant que je sache, les déclencheurs basés sur la documentation Apache Beam => Les déclencheurs permettent à Beam d'émettre des résultats précoces, avant qu'une fenêtre donnée ne soit fermée. Par exemple, émettre après un certain laps de temps ou après l'arrivée d'un certain nombre d'éléments. Les déclencheurs permettent de traiter les données en retard en se déclenchant après que le filigrane de l'heure de l'événement ait dépassé la fin de la fenêtre.
Donc, pour mon cas d'utilisation et selon les concepts de déclenchement ci-dessus, je ne pense pas que le déclencheur puisse être déclenché après un délai défini pour chaque utilisateur (il est mentionné ci-dessus - ne peut émettre qu'après un certain nombre d'éléments, il est mentionné ci-dessus, mais pas sûr si cela pourrait être 1). Pouvez-vous confirmer?
3 Réponses :
Je pense que la fenêtre glissante est la bonne approche par rapport à ce que vous avez décrit, et je ne pense pas que vous puissiez résoudre cela avec trigger + delay. Si le fenêtrage glissant dans le temps des événements a du sens du point de vue de votre logique métier, essayez de l'utiliser d'abord, c'est à cela qu'il sert.
Je crois comprendre que même si vous pouvez utiliser un déclencheur pour produire des résultats précoces, il n'est pas garanti qu'il se déclenche à un moment précis (serveur / traitement) ou avec le nombre exact d'éléments (reçus jusqu'à présent pour la fenêtre). La condition de déclenchement autorise / débloque le runner à émettre le contenu de la fenêtre mais ne le force pas à le faire.
Dans le cas de l'heure de l'événement, cela a du sens, car peu importe quand l'événement arrive ou quand le déclencheur se déclenche, car si l'élément a un horodatage dans une fenêtre, alors il sera affecté à la fenêtre correcte, peu importe Quand ça arrive. Et lorsque le déclencheur se déclenchera pour la fenêtre, l'élément sera garanti d'être dans cette fenêtre s'il est arrivé.
Avec le temps de traitement, vous ne pouvez pas faire cela. Si l'événement arrive en retard, il sera pris en compte à ce moment-là et sera émis la prochaine fois que le déclencheur se déclenchera, en gros. Et comme le déclencheur ne garantit pas le moment exact où il se déclenche, vous pouvez potentiellement vous retrouver avec des données inattendues appartenant à des volets émis inopinément. Il est utile d'obtenir les premiers résultats en général, mais je ne suis pas sûr que vous puissiez raisonner sur le fenêtrage sur cette base.
De plus, le délai de déclenchement n'ajoute qu'un délai de tir (par exemple, s'il était censé se déclencher à 12 h 00, il ne se déclenchera pas à 12 h 05), mais il ne vous permet pas de décaler de manière fiable plusieurs déclenchements pour qu'il se déclenche à intervalles spécifiques.
Vous pouvez consulter le document de conception pour les déclencheurs ici: https://s.apache.org/ beam-triggers , et éventuellement un document de retard peuvent également être pertinents: https: // s. apache.org/beam-lateness
D'autres documents peuvent être trouvés ici, si vous êtes intéressé: https: // beam. apache.org/contribute/design-documents/ .
<₹Update:
Rui a souligné que ce cas d'utilisation peut être plus compliqué et probablement pas facilement résoluble par des fenêtres coulissantes. Cela vaut peut-être la peine d'examiner les fenêtres de session ou la logique manuelle en plus des touches + état + minuteries
Merci Anton pour la mise à jour.
Je pense qu'il est naturel de penser qu'il existe une solution comprenant le traitement par clé / élément, la fenêtre globale, le déclencheur de temps de traitement pour faire quelque chose comme dans le traitement de l'espace de temps, vérifier une série d'actions utilisateur et faire un regroupement pour obtenir le montant d'argent dans le panier /panier. Et une fois que le montant> 50 $, chaque action définira / référencera une minuterie pendant 30 minutes, et la minuterie se déclenchera s'il n'y a pas de fin de transaction ou de comportement d'achat supplémentaire et qu'un résultat sera émis. Si plus d'informations (données, etc.) peuvent être fournies, nous pourrions dire si Beam peut résoudre ce cas d'utilisation.
Je trouve l'état [1] et le timer [2] doc d'Apache Beam, qui devraient être capables de gérer ce cas d'utilisation spécifique sans utiliser le déclencheur de temps de traitement dans la fenêtre globale.
En supposant que les données entrantes sont des événements des actions des utilisateurs, et chaque événement (action) peut être saisi par user_id.
La belle propriété de l'état et de la minuterie est activée par clé et par fenêtre. Ainsi, vous pouvez accumuler l'état pour chaque user_id et l'état est le montant d'argent dans le panier dans ce cas. La minuterie peut être réglée à la première fois lorsque le montant dans le panier dépasse 50 $, et la minuterie peut être réinitialisée lorsque l'utilisateur a encore des actions d'achat dans les 30 minutes du temps de traitement.
Supposons que l'achèvement de la transaction est également un événement de clé user_id. Lorsqu'un événement de fin de transaction est vu, le minuteur peut être supprimé [3].
mise à jour:
Cette idée est entièrement sur le domaine du temps de traitement donc elle aura de faux messages d'alarme en fonction du problème de retard dans le système. La question est donc de savoir comment améliorer cette idée dans le domaine temporel des événements afin d'avoir moins de fausses alarmes. Une possibilité est la minuterie basée sur le temps des événements [4]. Je ne sais pas ce que signifie la minuterie basée sur l'heure de l'événement à ce moment.
[1] https: //beam.apache. org / blog / 2017/02/13 / stateful-processing.html
Les deux réponses 1 - Fenêtres coulissantes et 2 - Fenêtre globale sont incorrectes
Les fenêtres coulissantes ne sont pas correctes car - en supposant qu'il y ait une clé par utilisateur, un message sera envoyé 30 minutes après le premier démarrage de la navigation, même s'il est toujours en train de naviguer
Global Windows n'est pas correct car - cela entraînera l'envoi de messages toutes les 30 minutes à tous les utilisateurs, quel que soit l'endroit où ils se trouvent dans leur session actuelle
Même les fenêtres fixes seraient incorrectes dans ce cas, car en supposant qu'il y ait une clé par utilisateur, un message sera envoyé toutes les 30 minutes
La bonne réponse serait - Utilisez une fenêtre de session d'une durée de 30 minutes Ceci est correct car il enverra un message par utilisateur après que cet utilisateur soit inactif pendant 30 minutes
Voici quelques informations (y compris sur le fenêtrage global) que d'autres peuvent trouver utiles: beam.apache.org/documentation/programming-guide/...
Pouvez-vous s'il vous plaît essayer de donner la solution (peut-être en pseudo-code) basée sur une fenêtre glissante afin que je puisse comprendre votre cas d'utilisation et aider à voir si la fenêtre globale pourrait fonctionner?
Bien sûr, je vais essayer d'ajouter, mais en général, un déclencheur pour chaque élément est-il possible dans une fenêtre globale basée sur le retard?
Les déclencheurs (en particulier le déclencheur de temps de traitement et le déclencheur piloté par les données) peuvent être définis sur une fenêtre globale avec des données illimitées (sinon, aucune donnée ne sera émise car la fenêtre globale ne se ferme jamais). Si vous pouviez fournir plus d'informations sur votre cas d'utilisation, il serait utile de le confirmer.
Quelle que soit sa valeur, le message d'origine est une question copiée et collée à partir de l'examen pratique de Google Cloud Professional Data Engineer.