Referentie systeemtabel voor queryhistorie

Dit artikel bevat informatie over de tabel met querygeschiedenissystemen, inclusief een overzicht van het schema van de tabel.

tabelpad: deze systeemtabel bevindt zich op system.query.history.

Beschikbaarheid van platen

Records zijn meestal binnen een uur beschikbaar. Datalevering voor nieuwe werkplekken kan langer duren dan dit.

Wanneer de querygeschiedenistabel klantbeheerde sleutels gebruikt, geldt deze beschikbaarheid niet. Zie Versleutelde velden lezen.

De querygeschiedenistabel gebruiken

De querygeschiedenistabel bevat records voor queries die worden uitgevoerd met SQL-warehouses, serverless compute voor notebooks en jobs, en Lakeflow-pijplijnen die serverless of classic compute gebruiken. De tabel bevat records van alle werkruimtes in je account die in dezelfde regio liggen als de werkruimte die je gebruikt om toegang te krijgen tot de tabel.

Standaard hebben alleen beheerders toegang tot de systeemtabel. Als u de gegevens van de tabel wilt delen met een gebruiker of groep, raadt Databricks u aan een dynamische weergave te maken voor elke gebruiker of groep. Zie Een dynamische weergave maken.

Schema van systeemtabel voor querygeschiedenis

De tabel querygeschiedenis maakt gebruik van het volgende schema:

Toegang tot gemaskeerde statementtekst

SQL-statements kunnen gevoelige informatie bevatten zoals klantnamen, e-mailadressen of andere persoonlijk identificeerbare informatie (PII). Het veld keert statement_text standaard terug.<REDACTED> Accountbeheerders en leden van de databricks_pii_access groep kunnen de volledige querytekst lezen.

Om de groep aan te maken en het lidmaatschap en de rechten te beheren, zie Create and manage the databricks_pii_access group.

Probleemoplossing voor overlappende kolommaskers

Als je al een kolommasker hebt toegepast op statement_text, bijvoorbeeld met een attribuutgebaseerd toegangscontrolebeleid (ABAC), kunnen queries tegen system.query.history falen met COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS. Er kan slechts één kolommasker op een kolom van toepassing zijn voor een bepaalde gebruiker.

Om het conflict op te lossen, moet je een metastore-admin zijn of een enkele op MANAGE tafel liggen. Gebruik Conflicterende filters en maskers om overlappende beleidsregels te identificeren, en beperk of verwijder vervolgens je masker op statement_text.

Versleutelde velden lezen

Wanneer werkruimten door de klant beheerde sleutels gebruiken voor beheerde services, worden de statement_text en error_message velden in de systeemtabel standaard versleuteld. Dit komt doordat systeemtabellen gegevens opslaan uit en toegankelijk zijn voor alle werkruimten in de regio. Als u versleutelde systeemtabelvelden wilt ontsleutelen en weergeven, moeten accountbeheerders een sleutelconfiguratie toevoegen aan de system catalogus zelf. U moet MANAGE toestemming hebben op de system catalogus om deze bewerking uit te voeren.

Wanneer de querygeschiedenistabel klantbeheerde sleutels gebruikt, geldt de gebruikelijke recordbeschikbaarheid in Recordbeschikbaarheid niet.

U kunt een nieuwe sleutel maken of een bestaande sleutel opnieuw gebruiken. Voer de volgende opdracht uit met behulp van de volledige sleutel-id:

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"
        }
      }
}'

Reken tot 24 uur in voor de voltooiing van de activatie. Na voltooiing system.query.history van enablement begint het de versleutelde velden voor alle nieuwe records weer te geven. Records die vóór de enablement zijn aangemaakt, kunnen niet worden ontsleuteld.

Het queryprofiel voor een record weergeven

Ga als volgt te werk om naar het queryprofiel van een query te navigeren op basis van een record in de tabel querygeschiedenis:

1. Identificeer de record van interesse en kopieer record statement_id.
2. Verwijs naar het record's workspace_id zodat u zich in dezelfde werkruimte bevindt als het record.
3. Klik op Querygeschiedenis in de zijbalk van de werkruimte.
4. Plak het in het veld statement_id op het record.
5. Klik op de naam van een query. Er wordt een overzicht van metrische querygegevens weergegeven.
6. Klik op Bekijk queryprofiel.

Inzicht in scanmetrieken

De querygeschiedenistabel bevat meerdere metrieken die tijdens de scan zijn verzameld. Je kunt de volgende extra metrieken berekenen uit de kolommen van de tabel:

• table_bytes: De totale gecomprimeerde grootte, in bytes, van de bestanden in de gescande tabellen. Berekend als pruned_files_bytes + read_files_bytes.
• table_files: Het totale aantal bestanden in de gescande tabellen. Berekend als read_files + pruned_files.

Inzicht in query_source kolom

De kolom query_source bevat een set unieke id's van Azure Databricks entiteiten die betrokken zijn bij de uitvoering van de instructie.

Als de query_source kolom meerdere id's bevat, betekent dit dat de uitvoering van de instructie is geactiveerd door meerdere entiteiten. Een taakresultaat kan bijvoorbeeld een waarschuwing activeren die een SQL-query aanroept. In dit voorbeeld worden alle drie de id's ingevuld binnen query_source. De waarden van deze kolom worden niet gesorteerd op uitvoeringsvolgorde.

Mogelijke querybronnen zijn:

• alert_id: Instructie geactiveerd vanuit een waarschuwing
• sql_query_id: Instructie uitgevoerd vanuit deze SQL-editorsessie
• dashboard_id: Instructie uitgevoerd vanuit een dashboard
• genie_space_id: Instructie uitgevoerd van een Genie-agent
• notebook_id: Instructie uitgevoerd vanuit een notebook
• job_info.job_id: Instructie uitgevoerd binnen een taak
• job_info.job_run_id: Instructie uitgevoerd vanaf een taakuitvoering
• job_info.job_task_run_id: Instructie uitgevoerd binnen een taakuitvoering

Geldige combinaties van query_source

In de volgende voorbeelden ziet u hoe de query_source kolom wordt ingevuld, afhankelijk van hoe de query wordt uitgevoerd:

• Query's die tijdens een taakuitvoering worden uitgevoerd, bevatten een gevulde job_info struct:

  {
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
}

• Query's van waarschuwingen omvatten een sql_query_id en 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
}

• Query's van dashboards bevatten een dashboard_id, maar nee 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
}