Verwenden des Ereignis-Scrollvorgangs zum Exportieren von Analysedaten
Verwenden Sie die/events/scroll Vorgang zum Exportieren von 10.000 oder mehr Analyseereignisdatensätzen mit der REST-API.
Die Standardmethode zum Abrufen von Analytics-Ereignisdaten über die API Connect Analytics-REST-API ist die Verwendung des /events API-Aufrufs. Der/events Der API-Aufruf ist für den schnellen Abruf der aktuellsten Ereignisdaten optimiert und auf die Rückgabe von maximal 10.000 API-Ereignisdatensätzen beschränkt. Wenn Sie mehr als 10.000 Ereignisdatensätze abrufen möchten, verwenden Sie die/events/scroll API, die für den Abruf großer Mengen analytischer Ereignisdaten optimiert ist.
Wenn Sie Ihre Analysedaten abfragen mit/events/scroll , OpenSearch findet alle Ereignisdatensätze, die Ihrer Abfrage entsprechen, und erstellt einen Zeiger, der als Bildlaufkontext bezeichnet wird. Anschließend verwenden Sie den Bildlaufkontext, um die Ereignisdaten stapelweise abzurufen.
/events/scroll Abfragen gleichzeitig auszuführen und den Scroll-Kontext zu löschen, nachdem Ihre Ereignisdaten abgerufen wurden.Exportieren von Analyseereignissen mit/events/scroll
Der/events/scroll Der Vorgang gibt Ereignisdaten stapelweise zurück. Sie definieren die Batchgröße beim ersten Aufruf von/events/scroll , und rufen Sie dann jeden Stapel in nachfolgenden Aufrufen ab. Jeder weitere Anruf muss an/events/scroll innerhalb einer bestimmten Zeit, die als Keep-Alive-Zeit des Scroll-Kontexts bezeichnet wird. Das Verfahren ist wie folgt:
- Machen Sie den ersten
/events/scrollAnruf. Geben Sie die Batchgröße und die Keep-Alive-Zeit für den Scroll-Vorgang an. Um beispielsweise Ereignisdaten in Batches von 1000 zurückzugeben und den Scroll-Kontext 10 Minuten lang aktiv zu halten, senden Sie den folgenden JSON-Code per POST an/events/scroll:{ "size": 1000, # Return the first 1000 event records. "scroll": 10m # Keep the scroll context alive for 10 minutes. }sizedefiniert die Batchgröße.scrolldefiniert die Keep-Alive-Zeit und verwendet das Format <Zahl><Einheiten>, Zum Beispiel: 30s, 5m, 3h, 1d. Der Maximalwert fürscrollIst 1d.
Beispielantwort:{ "total": 5926, # The total events found that match the query. "scroll_id": "FGl....", # Scroll context id to be used to get the next batch. "events": [...] # First batch of event data. } - Machen Sie den nächsten
/events/scrollAnruf unter Angabe derscroll_idaus der vorherigen Antwort:{ "size": 1000, "scroll_id": "<as returned from previous call>", "scroll": 10m }Die API gibt den nächsten Batch von 1000 Ereignisdatensätzen zurück und einen neuenscroll_idfür den nächsten Anruf.Notiz: Wenn deinscroll_idabgelaufen ist, wird die folgende Antwort zurückgegeben:{ "status": 404, "message": [ { "trace": "7c7b3b11ee0e95b61452e8a78086d8e2", "errors": [ { "code": "search_context_missing_exception", "message": "No search context found for id [48420]", "more_info": "" } ] } ] }Wenn dein
scroll_idabläuft, müssen Sie von vorne beginnen. Stellen Sie eine höhere Keep-Alive-Zeit für den Scroll-Kontext ein, um mehr Zeit für die Rückgabe von Ereignisdatensatz-Batches und den nächsten/events/scrollAnruf getätigt werden. - Machen Sie weiter
/events/scrollAnrufe, Aktualisierung derscroll_idjedes Mal mit der Antwort vom vorherigen Anruf. - Nach dem letzten Aufruf zum Abrufen Ihrer Ereignisdaten löschen Sie den Scroll-Kontext mit einem POST an
/events/scroll/delete:{"scroll_id": "<as returned from previous call>"}Beispielantwort:{ "succeeded": true, "num_freed": 15 }Notiz: Der Scroll-Kontext wird automatisch gelöscht, wenn er abläuft. Wenn Sie jedoch über eine lange Keep-Alive-Zeit verfügen, wird empfohlen, ihn explizit zu löschen, um Ressourcen freizugeben.
Ausgearbeitetes Beispiel
/events/scroll API./events/scroll Anrufe und aktualisieren Sie diescroll_id bei jedem Anruf. Ein Beispiel für ein „ Python “-Skript finden Sie unter https://ibm.biz/apic-analytics-events-scroll.- Ermitteln Sie die Gesamtzahl der Ereignisdatensätze, um die optimale Batchgröße und die Anzahl der durchzuführenden Anrufe zu ermitteln:
curl -k -X GET --url 'https://example.api.connect.com/analytics/analytics/cloud/events/count' -H 'Authorization: Bearer <bearer_token>'{ "total": 12453 }Bei 12.453 Ereignissen kann eine Batchgröße von 1.250 und insgesamt 10 Aufrufe ein guter Kompromiss zwischen Ausgabegröße und Anzahl der Aufrufe sein.
- Stellen Sie die erste Anfrage und geben Sie dabei eine Batchgröße von 1250 und eine Keep-Alive-Zeit für den Scroll-Kontext von 5 Minuten an:
curl -k -X POST -d '{"size": "1250", "scroll": "5m"}' --url 'https://example.api.connect.com/analytics/analytics/cloud/events/scroll' -H 'Content-Type: application/json' -H 'Authorization: Bearer <bearer_token>'Gibt Folgendes zurück:{ "total": 12453, # The total events found that match the query. "scroll_id": "<scroll_id>", "events": [...] # First batch of 1250 events. } - Machen Sie die zweite Anfrage und geben Sie dabei die
scroll_idvon der vorherigen Anfrage zurückgegeben:curl -k -X POST -d '{"size": "1250", "scroll": "5m", "scroll_id": "<scroll_id from previous response>"}' --url 'https://example.api.connect.com/analytics/analytics/cloud/events/scroll' -H 'Content-Type: application/json' -H 'Authorization: Bearer <bearer_token>' - Wiederholen Sie die Anfrage noch 8 Mal und aktualisieren Sie die
scroll_idjedes Mal mit der Ausgabe der vorherigen Anfrage.Da die Gesamtzahl der Ereignisse 12.453 beträgt und die Batchgröße 1.250 ist, gibt die letzte Anforderung nur 1.203 Ereignisse zurück.
Alle nachfolgenden Anfragen, die Sie an den
scroll_idGibt ein leeres Ereignis-Array zurück. - Löschen Sie den Scroll-Kontext:
curl -k -X POST -d '{"scroll_id": "<scroll_id from previous response>"}' --url 'https://example.api.connect.com/analytics/analytics/cloud/events/scroll/delete' -H 'Content-Type: application/json' -H 'Authorization: Bearer <bearer_token>'
Leistungsvergleich von/events/scroll Und/events
/events Die API kann nicht mehr als 10.000 Ereignisse abrufen (und auch keine Stapel mit 1.000 oder mehr). Daher werden diese Felder als „n. z.“ markiert.| Stapelgröße | Anzahl der Aufrufe | /eventsZeit |
/events/scrollZeit |
|---|---|---|---|
| 100 | 10 | 7 | 9 |
| 500 | 2 | 3 | 4 |
| 1.000 | 1 | nicht zutreffend | 3 |
| 2.000 $ | 1 | nicht zutreffend | 5 |
| Stapelgröße | Anzahl der Aufrufe | /eventsZeit |
/events/scrollZeit |
|---|---|---|---|
| 100 | 100 | 67 | 75 |
| 500 | 20 Jahre | 27. | 32 |
| 1.000 | 10 | nicht zutreffend | 24 |
| 2.000 $ | 5 | nicht zutreffend | 20 Jahre |
| Stapelgröße | Anzahl der Aufrufe | /eventsZeit |
/events/scrollZeit |
|---|---|---|---|
| 100 | 1.000 | nicht zutreffend | 732 |
| 500 | 200 | nicht zutreffend | 299 |
| 1.000 | 100 | nicht zutreffend | 258 |
| 2.000 $ | 50 | nicht zutreffend | 196 |
| Stapelgröße | Anzahl der Aufrufe | /eventsZeit |
/events/scrollZeit |
|---|---|---|---|
| 100 | 7603 | nicht zutreffend | 5647 |
| 500 | 1521 | nicht zutreffend | 2423 |
| 1.000 | 761 | nicht zutreffend | 2158 |
| 2.000 $ | 381 | nicht zutreffend | 1919 |
technote says: "Scroll contexts will stay alive for 10 minutes by default " and "Due to an OpenSearch limitation, if the
scrollparameter is not included on subsequent requests withscroll_id, no scroll ID will be returned."For this reason, simplest just to tell user to always specify it, and don't rely on the default for the first call.