Referenz der Abfrageverlaufsystemtabelle

Dieser Artikel enthält Informationen zur Abfrageverlaufs-Systemtabelle, einschließlich einer Gliederung des Schemas der Tabelle.

Tabellenbereichspfad: Diese Systemtabelle befindet sich bei system.query.history.

Verfügbarkeit der Platten

Akten sind in der Regel innerhalb einer Stunde verfügbar. Die Datenlieferung für neue Arbeitsbereiche kann länger dauern.

Wenn die Abfrageverlauftabelle kundenverwaltete Schlüssel verwendet, gilt diese Verfügbarkeit nicht. Siehe "Verschlüsselte Felder lesen".

Verwenden der Abfrageverlaufstabelle

Die Abfragehistorik-Tabelle enthält Datensätze für Abfragen, die mit SQL-Warehouses ausgeführt werden, serverlose Rechenleistungen für Notebooks und Jobs sowie Lakeflow-Pipelines , die serverlose oder klassische Compute verwenden. Die Tabelle enthält Datensätze aus allen Arbeitsbereichen in Ihrem Konto, die sich in derselben Region wie der Arbeitsbereich befinden, den Sie zum Zugriff auf die Tabelle verwenden.

Standardmäßig haben nur Administratoren Zugriff auf die Systemtabelle. Wenn Sie die Daten der Tabelle für einen Benutzer oder eine Gruppe freigeben möchten, empfiehlt Databricks, eine dynamische Ansicht für jeden Benutzer oder jede Gruppe zu erstellen. Weitere Informationen finden Sie unter Erstellen einer dynamischen Ansicht.

Schema der Abfrageverlaufs-Systemtabelle

Die Abfrageverlaufstabelle verwendet das folgende Schema:

Zugriff auf maskierte Anweisungen

SQL-Anweisungen können sensible Informationen wie Kundennamen, E-Mail-Adressen oder andere personenbezogene Daten (PII) enthalten. Das Feld statement_text kehrt standardmäßig zurück.<REDACTED> Kontoadministratoren und Mitglieder der databricks_pii_access Gruppe können den vollständigen Anfragetext lesen.

Um die Gruppe zu erstellen und ihre Mitgliedschaft und Berechtigungen zu verwalten, siehe Erstelle und Verwaltung der databricks_pii_access Gruppe.

Fehlerbehebung überlappender Spaltenmasken

Wenn Sie bereits eine Spaltenmaske auf statement_textangewendet haben, beispielsweise mit einer attributbasierten Zugriffskontrollrichtlinie (ABAC), können Abfragen gegen system.query.history mit COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKSfehlschlagen. Für einen bestimmten Benutzer kann nur eine Spaltenmaske angewendet werden.

Um den Konflikt zu lösen, musst du Metastore-Admin sein oder einen Have MANAGE auf dem Tisch haben. Verwenden Sie widersprüchliche Filter und Masken , um überlappende Richtlinien zu identifizieren, und schränken Sie dann Ihre Maske auf ein oder entfernen Sie sie auf statement_text.

Lesen verschlüsselter Felder

Wenn Arbeitsbereiche kundenverwaltete Schlüssel für verwaltete Dienste verwenden, werden die Felder statement_text und error_message in der Systemtabelle standardmäßig verschlüsselt. Dies liegt daran, dass Systemtabellen Daten von allen Arbeitsbereichen in der Region speichern und darauf zugreifen können. Um verschlüsselte Systemtabellenfelder zu entschlüsseln und anzuzeigen, müssen Kontoadministratoren dem system Katalog selbst eine Schlüsselkonfiguration hinzufügen. Sie müssen über MANAGE Berechtigung für den system Katalog verfügen, um diesen Vorgang auszuführen.

Wenn die Abfragehistorie-Tabelle kundenverwaltete Schlüssel verwendet, gilt die typische Datensatzverfügbarkeit in Datensatzverfügbarkeit nicht.

Sie können entweder einen neuen Schlüssel erstellen oder einen vorhandenen schlüssel wiederverwenden. Führen Sie mit der vollständigen Schlüssel-ID den folgenden Befehl aus:

curl -v -X PATCH https://my-workspace-url/api/2.1/unity-catalog/catalogs/system -H 'Authorization: Bearer <pat token>' --data '{
"managed_encryption_settings": {
        "azure_key_vault_key_id": "https://my-key-vault.vault.azure.net/keys/my-key-name/my-key-version",
        "azure_encryption_settings": {
          "azure_tenant_id": "my-tenant-id"
        }
      }
}'

Erwarte bis zu 24 Stunden, bis die Enablement abgeschlossen ist. Nach Abschluss der Enablement beginnt es, system.query.history die verschlüsselten Felder für alle neuen Datensätze anzuzeigen. Datensätze, die vor der Enablement erstellt wurden, können nicht entschlüsselt werden.

Anzeigen des Abfrageprofils für einen Datensatz

Gehen Sie wie folgt vor, um zu dem Abfrageprofil einer Abfrage zu navigieren, das auf einem Datensatz in der Abfrageverlaufstabelle basiert:

1. Identifizieren Sie den relevanten Datensatz und kopieren Sie dann dessen statement_id.
2. Verweisen Sie auf die workspace_id des Datensatzes, um sicherzustellen, dass Sie im Arbeitsbereich des Datensatzes angemeldet sind.
3. Wählen Sie in der Randleiste des Arbeitsbereichs Abfrageverlauf aus.
4. Fügen Sie in das Feld Anweisungs-ID die statement_id des Datensatzes ein.
5. Wählen Sie den Namen einer Abfrage. Es wird eine Übersicht über Abfragemetriken angezeigt.
6. Wählen Sie Siehe Abfrageprofil aus.

Verständnis von Scan-Metriken

Die Abfragehistorie-Tabelle enthält mehrere während des Scans erhobenen Metriken. Sie können die folgenden zusätzlichen Metriken aus den Spalten der Tabelle berechnen:

• table_bytes: Die gesamte komprimierte Größe, in Bytes, der Dateien in den gescannten Tabellen. Berechnet als pruned_files_bytes + read_files_bytes.
• table_files: Die Gesamtzahl der Dateien in den gescannten Tabellen. Berechnet als read_files + pruned_files.

Grundlegendes zur Spalte query_source

Die Spalte query_source enthält eine Reihe eindeutiger Bezeichner von Azure Databricks Entitäten, die an der Ausführung der Anweisung beteiligt sind.

Wenn die query_source Spalte mehrere IDs enthält, bedeutet dies, dass die Ausführung der Anweisung durch mehrere Entitäten ausgelöst wurde. Beispielsweise kann ein Auftragsergebnis eine Warnung auslösen, die eine SQL-Abfrage aufruft. In diesem Beispiel werden alle drei IDs innerhalb von query_source eingetragen. Die Werte dieser Spalte werden nicht nach Ausführungsreihenfolge sortiert.

Mögliche Abfragequellen sind:

• alert_id: Aus einer Warnung ausgelöste Aussage
• sql_query_id: Anweisung, die in dieser SQL-Editorsitzung ausgeführt wird
• dashboard_id: Aus einem Dashboard ausgeführte Anweisung
• genie_space_id: Erklärung, die von einem Genie Agent ausgeführt wurde
• notebook_id: Anweisung, die aus einem Notebook ausgeführt wird.
• job_info.job_id: Anweisung, die in einem Auftrag ausgeführt wird
• job_info.job_run_id: Anweisung, die in einer Jobausführung ausgeführt wird
• job_info.job_task_run_id: Anweisung, die in einer Auftragsaufgabe ausgeführt wird

Gültige Kombinationen von query_source

Die folgenden Beispiele zeigen, wie die query_source Spalte je nach Ausführung der Abfrage aufgefüllt wird:

• Abfragen, die während einer Auftragsausführung ausgeführt werden, umfassen eine aufgefüllte job_info Struktur:

  {
alert_id: null,
sql_query_id: null,
dashboard_id: null,
notebook_id: null,
job_info: {
job_id: 64361233243479,
job_run_id: null,
job_task_run_id: 110378410199121
},
legacy_dashboard_id: null,
genie_space_id: null
}

• Abfragen aus Warnungen umfassen eine sql_query_id und eine alert_id.

  {
alert_id: e906c0c6-2bcc-473a-a5d7-f18b2aee6e34,
sql_query_id: 7336ab80-1a3d-46d4-9c79-e27c45ce9a15,
dashboard_id: null,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
}

• Abfragen aus Dashboards umfassen eine dashboard_id, aber keine job_info:

  {
alert_id: null,
sql_query_id: null,
dashboard_id: 887406461287882,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
}