Looker-Ereignisdefinition für die Abrechnung nach Verbrauch

Auf dieser Seite wird das Konzept eines Looker-Ereignisses definiert. Dies ist der primäre Messwert für die Nutzung, der für nutzungsbasierte Preismodelle in Looker (Google Cloud Core) verwendet wird.

Hinweis :Looker-Ereignisse im Kontext der verbrauchsabhängigen Abrechnung stellen die Ausführung einer Abfrageaufgabe dar. Diese unterscheiden sich von Looker-Ereignissen in der Systemaktivität, die von Looker-Servern generierte Administrator- und Nutzer-Audit-Logs (z. B. create_dashboard, login oder delete_user) sind.

Was ist ein Looker-Ereignis?

Ein Looker-Ereignis ist eine Maßeinheit für die Nutzung Ihrer Looker-Instanz (Google Cloud Core). Sie stellt den Wert dar, der entsteht, wenn Looker eine Abfrage aus der semantischen Ebene generiert, Geschäftsdaten abruft und Transformationen oder visuellen Kontext auf diese Daten für einen Endnutzer anwendet.

Intern wird jedes Looker-Ereignis der Ausführung einer Abfrageaufgabe zugeordnet.

Definition einer Abfrageaufgabe

Eine Abfrageaufgabe ist die interne Darstellung eines Abfragevorgangs, unabhängig von der Quelle, die die Abfrage initiiert hat. Beispiele für eine Abfrageaufgabe:

• Eine Abfrage in einem Looker-Explore oder Self-Service-Explore ausführen
• Kachel in einem Dashboard oder Look aktualisieren
• PDF-Datei eines Explores, Looks oder einer Dashboardkachel erstellen
• Eine Abfrage, die als programmatische Anfrage über die Looker API ausgeführt wird, oder eine sekundäre Abfrage, die als Teil eines Explore mit zusammengeführten Ergebnissen ausgeführt wird
• Eine automatisierte Datenbereitstellung, bei der der Looker-Scheduler oder eine Benachrichtigung verwendet wird

Jede dieser Aufgaben entspricht einem Looker-Ereignis. Wenn Sie beispielsweise ein Dashboard aktualisieren, das 10 Kacheln enthält, werden 10 Abfrageaufgaben und damit 10 abrechenbare Looker-Ereignisse generiert.

Eine einzelne Abfrageaufgabe umfasst den gesamten Lebenszyklus eines Abfragevorgangs – vom Moment der Initiierung der Abfrage bis zum Beginn des Streamings der Ergebnisse zurück zur initiierenden Quelle.

Warum Abfrageaufgaben für die verbrauchsabhängige Abrechnung verwendet werden

Abfrageaufgaben eignen sich aus mehreren Gründen besonders gut, um sowohl den Kundenwert als auch die Nutzung von Systemressourcen in Looker zu messen:

• Darstellung von Kernwerten: Jede Hauptfunktion von Looker – einschließlich Dashboards, automatisierter Benachrichtigungen, geplanter Berichte und visueller Datenexploration – führt letztendlich eine Abfrage aus. Abfrageaufgaben spiegeln diese Wertgenerierung direkt wider.
• Umfassende Abdeckung: Bei diesem Messwert gibt es keine Lücken. Für jede Ausführung einer Abfrage wird eine Abfrageaufgabe generiert, unabhängig davon, wie die Anfrage initiiert wurde (z. B. über die Benutzeroberfläche, über eine API oder über eine geplante Bereitstellung).
• Normalisierter Wert: Der Messwert für die Abfrageaufgabe normalisiert den Wert des Datenabrufs unabhängig davon, ob die Ergebnisse aus der Datenbank oder aus dem internen Looker-Cache abgerufen werden.
• Einheitliche Messung: Im Gegensatz zu API-Endpunkten, die entweder mit oder ohne Bereich definiert werden können, was zu Unterschieden bei der Systemauslastung führt, bieten Abfrageaufgaben eine einheitliche Maßeinheit für alle Aktivitäten.

Nicht abrechenbare Abfrageaufgaben

Um eine gute Instanzleistung zu gewährleisten und eine klare, faire Nutzererfahrung zu ermöglichen, werden bestimmte Arten von Abfrageaufgaben aus dem Abrechnungsprozess ausgeschlossen. Für die folgenden Abfrageaufgaben generierte Looker-Ereignisse sind nicht abrechenbar:

1. Systemaktivitätsabfragen: Abfragen, die für interne Instrumentierungsmodelle ausgeführt werden, um Looker-Monitoring, Nutzungsberichte und Systemaktivität (unter der in helltool verwendeten internal_model-Konfiguration) zu ermöglichen. So können Administratoren immer auf Leistungs- und Telemetrieinformationen wie ESA (Elite System Activity) zugreifen, auch wenn sie Abrechnungs- oder Governance-Limits überschreiten.
2. Vorschlagsabfragen: Automatische Abfragen, die an die Datenbank gesendet werden, wenn ein Nutzer in ein Filtertextfeld eingibt, um Filtervorschläge zu generieren. Diese stellen keinen direkten, eigenständigen Wert für den Kunden dar und sind von der Abrechnung ausgeschlossen.
3. Ausführungen von Abfragen für persistente abgeleitete Tabellen (Persistent Derived Tables, PDTs): Abfragen, die zum Erstellen oder Neuerstellen von PDTs ausgeführt werden. Da PATs ein Tool zur Leistungsoptimierung sind, das zur Verbesserung der Nutzerfreundlichkeit empfohlen wird, werden Befehle zum Neuerstellen von PATs nicht separat in Rechnung gestellt, um die Verwendung nicht zu erschweren. Außerdem können sie auch inline während der Standardabfrageausführung ausgelöst werden.
4. PDF-Vorrender-Abfragen: Aufgaben, bei denen Abfragen ausgeführt werden, um den Cache während der PDF-Dokumentgenerierung zu füllen. Beim Drucken von PDFs werden zwei Abfragen pro Kachel ausgelöst: eine zum Speichern von Ergebnissen im Cache und eine zum Rendern aus dem Cache. Nur die endgültige Cache-Leseanfrage wird als abrechenbares Ereignis gezählt, die Vorab-Befüllungsanfrage wird ausgeschlossen.

5. Nicht erfolgreiche Anfragen: Alle Abfrageaufgaben, bei denen keine Ergebnisse für den Nutzer zurückgegeben werden. Diese Aufgaben umfassen Datenbankabfragen, die zu anderen Status als COMPLETE führen, einschließlich der folgenden:

   • ERROR
   • KILLED
   • CACHE_ONLY_MISS
   • REJECTED (Governance-Ablehnung)

Alle anderen Abfrageaufgaben, einschließlich Cache-Treffer, bleiben abrechenbar, um den Abfragetraffic, der von der Looker-Instanz verarbeitet wird, richtig zu erfassen.