Erste Schritte mit Data Explorer erweiterten Modus

Wichtig

Das feature Data Explorer befindet sich in der öffentlichen Vorschau. Wir rechnen mit laufenden Änderungen daran, während wir weiterhin Feedback sammeln und für die Kundennutzung optimieren.

Data Explorer erweiterten Modus ist für komplexere Abfragen und tiefere Einblicke unter Verwendung der Abfragesprache Azure Data Explorer konzipiert– einer SQL-ähnlichen Sprache, die für die Ad-hoc-Datenuntersuchung optimiert ist. Informationen zum Schreiben nicht technischer Abfragen finden Sie im Tutorial Erste Schritte mit Data Explorer grundlegenden Modus.

Erstellen benutzerdefinierter Abfragen

Um mit dem Erstellen eigener Abfragen im erweiterten Modus zu beginnen, ist es wichtig, zunächst die Form der Daten zu verstehen, auf die Sie zugreifen.

Die Tabelle events.all

Die events.all Tabelle ist das Standardziel für alle eingehenden Ereignisse. Es handelt sich um eine einzelne halbstrukturierte Tabelle mit Spalten für allgemeine Werte wie Zeit & Ereignisnamen. Sie werden sich schnell mit der Spalte EventData vertraut machen, die die vollständige ursprüngliche JSON-Nutzlast enthält und in fast allen Abfragen nützlich ist. Sie können die folgende Dokumentation in der Tabelle events.all lesen.

Die Anatomie einer Abfrage

Ein Abfrageausdruck beginnt am häufigsten mit dem Namen der Tabelle. Darauf folgt das Pipetrennzeichen (|). Als Nächstes kommt ein oder mehrere Operatoren. Jeder Operator wird durch das Pipetrennzeichen getrennt.

Eine Abfrage kann bevorzugt in einer einzelnen Zeile oder mithilfe eines Zeilenrücklaufs vor jedem Pipetrennzeichen ausgedrückt werden. Dies macht keinen Unterschied für die Abfrage selbst.

Der Abfragebereich kann mehrere Abfragen enthalten. Dadurch können Sie ganz einfach mit einem einfachen Ausdruck beginnen, die Ausführung überprüfen und darauf aufbauen.

Eine Leerzeile trennt eine Abfrage von einer anderen. Ihre Cursorposition bestimmt, welche Abfrage ausgeführt wird, wenn Sie die Schaltfläche "Ausführen" drücken. Sie können auch einen Teil der Abfrage hervorheben, um nur diesen Ausdruck auszuführen.

Erstellen Ihrer ersten Abfrage

Nun erstellen wir Ihre erste Abfrage von Grund auf neu. Sie können den Tabellennamen im Abfragebereich eingeben. Aber wir werden eine kleine Abkürzung verwenden. Suchen Sie die events.all Tabelle im Bereich Ressourcen. Möglicherweise müssen Sie Ihre Titel-ID-Datenbank erweitern, indem Sie auf den Pfeil klicken.

Nachdem Sie die events.all Tabelle gefunden haben, doppelklicken Sie auf den Tabellennamen. Sie werden feststellen, dass dieser Ausdruck dem Abfragebereich hinzugefügt wurde.

Notiz

In der Vorschau müssen Sie die Klammern und einfachen Anführungszeichen um den Tabellennamen manuell hinzufügen. Es wird eine Korrektur für diese Unannehmlichkeiten ausgeführt.

['events.all']
| 

Notieren Sie sich die Klammern und einfachen Anführungszeichen um den Namen. Wenn der Tabellen- oder Spaltenname ein "" enthält. diese sind erforderlich. Der Cursor befindet sich jetzt an der richtigen Position, um Ihren ersten Operator zu erstellen. Beginnen wir mit der Verwendung des Take-Operators.

['events.all']
| take 100

Führen Sie diese Abfrage aus. Beachten Sie, dass im Ergebnisbereich jetzt 100 Zeilen mit Rohdaten angezeigt werden.

Wählen Sie im Bereich Ergebnisse die oberste Zeile aus. Navigieren Sie mit dem Pfeil nach rechts zur spalte FullName_Name. Dies ist der Name des Ereignisses. Pfeil nach unten, bis Sie ein player_logged_in Ereignis gefunden haben. Wenn Sie eine gefunden haben, zeigen Sie mit der rechten Maustaste zur Spalte EventData, und doppelklicken Sie darauf. Nun sollte Folgendes angezeigt werden:

Ihre Abfrage kann mithilfe der Punktnotation (.) auf alle Eigenschaften im EventData-JSON-Code verweisen. Sie können dies jetzt versuchen, indem Sie Ihre Abfrage so ändern, dass nur player_logged_in Ereignisse von einem einzelnen Spieler zurückgegeben werden. Doppelklicken Sie auf die EntityID-GUID, und kopieren Sie sie in die Zwischenablage.

Aktualisieren Sie nun Ihre Abfrage wie folgt, und fügen Sie die kopierte GUID ein:

['events.all']
| where FullName_Name == 'player_logged_in'
| where Entity_Id == 'paste from clipboard here'

Tipp

Doppelte Gleichheitszeichen werden verwendet, um die Äquivalenz von Zeichenfolgen auszuwerten. Einfache Anführungszeichen am Anfang und Ende legen eine Zeichenfolge fest.

Führen Sie die Abfrage aus, und im Ergebnisbereich werden player_logged_in Ereignisse nur für den ausgewählten Player angezeigt. Sie können die Punktnotation verwenden, um auf mehrere geschachtelte Ebenen der JSON-Hierarchie zu verweisen, indem Sie einfach einen Punkt zwischen jeder Ebene hinzufügen.

Nun erstellen wir eine zweite Abfrage, um Spieleranmeldungen nach Region zu gruppieren. Ohne das, was Sie geschrieben haben, zu löschen, drücken Sie zweimal die EINGABETASTE. Fügen wir unserer nächsten Abfrage einen Kommentar hinzu, indem wir "//" verwenden. Kommentare werden nicht ausgeführt und sind hilfreich, um die Absicht hinter jeder Abfrage nachzuverfolgen.

//Player logins by platform

Doppelklicken Sie erneut im Ressourcenbereich auf die Tabelle events.all. Dieses Mal fügen wir dem Ausdruck ein Zeittrennzeichen hinzu, um die Abfrage auf die letzten drei Tage zu begrenzen.

//Player logins by platform
['events.all']
| where Timestamp > ago(30d)
| where FullName_Name == 'player_logged_in'

Führen Sie diese Abfrage aus, um eine vollständige Liste aller Anmeldeereignisse in den letzten drei Tagen zu erhalten. Wir möchten jedoch wissen, wie viele verschiedene Spieler sich angemeldet haben, nicht die Anzahl der Ereignisse. Dazu verwenden wir den distinct-Operator nach Entitäts-ID.

['events.all']
| where Timestamp > ago(3d)
| where FullName_Name == 'player_logged_in'
| distinct Entity_Id

Diese Abfrage gibt eine Liste der Entitäts-IDs zurück, die sich in den letzten drei Tagen angemeldet haben. Im Bereich Ergebnisse wird die Anzahl der Datensätze angezeigt, sodass die Gesamtanzahl angezeigt wird.

Nun rufen wir die Anzahl der Spieler ab, die sich von jeder Plattform angemeldet haben. Dazu benötigen wir die eindeutige Anzahl von Entitäts-IDs, die nach der Plattformeigenschaft im EventData-JSON gruppiert sind. Hierfür ist der summarize -Operator erforderlich. Da summarize keine dynamischen Typen unterstützt, müssen wir plattform auch in eine Zeichenfolge umwandeln.

['events.all']
| where Timestamp > ago(3d)
| where FullName_Name == 'player_logged_in'
| summarize dcount(Entity_Id) by tostring(EventData.Platform)

Lassen Sie uns dies mit einer Blüte abschließen. Durch Hinzufügen eines einzelnen zusätzlichen Ausdrucks können wir unsere Ergebnisse als Säulendiagramm rendern.

['events.all']
| where Timestamp > ago(3d)
| where FullName_Name == 'player_logged_in'
| summarize dcount(Entity_Id) by tostring(EventData.Platform)
| render columnchart

Beispielabfragen

Wir haben gerade erst die Oberfläche der Arten von Abfragen gekratzt, die in Explorer erstellt werden können. Weitere Beispielabfragen können von der seite Explorer geladen werden, indem Sie auf "What's This" (What's This) klicken. Jede dieser Beispielabfragen wird ausgewählt, um einige der verschiedenen verfügbaren Operatoren zu veranschaulichen und zu veranschaulichen, wie sie auf reale Fragen angewendet werden können.

Notiz

Da die Form Ihrer Daten von unserem Demodataset abweichen kann, müssen Sie die Beispielabfrage möglicherweise so ändern, dass sie für Ihr Szenario ausgeführt wird.

Limits

Es gibt zwei Grenzwerte für die Abfragenutzung Explorer:

1. Maximale Abfragelaufzeit: Eine einzelne Abfrage darf nicht länger als 30 Sekunden ausgeführt werden. Wenn dieser Grenzwert überschritten wird, wird die Abfrage beendet, und Sie erhalten eine Fehlermeldung.

2. Intervallnutzung: Für jeden Titel ist eine kumulierte Gesamtlaufzeit von drei Minuten pro angegebenem 10-Minuten-Intervall zulässig. Wenn dieser Grenzwert überschritten wird, erhalten Sie eine Fehlermeldung und müssen warten, bevor Sie zusätzliche Abfragen ausführen.

Datenaufbewahrung

Standardmäßig werden Data Explorer Abfragen auf heißem Speicher ausgeführt, der im Verwaltungstool konfiguriert werden kann. Abfragen, die über die im heißen Speicher gespeicherten Daten hinaus suchen, weisen deutlich längere Laufzeiten auf und können ein Timeout aufweisen.