Odwołanie do tabeli systemu historii zapytań

Ten artykuł zawiera informacje dotyczące tabeli systemu historii zapytań, w tym konspektu schematu tabeli.

ścieżka tabeli: ta tabela systemowa znajduje się w system.query.history.

Dostępność rekordów

Dokumenty są zazwyczaj dostępne w ciągu jednej godziny. Dostarczanie danych do nowych przestrzeni roboczych może zająć więcej czasu.

Gdy tabela historii zapytań korzysta z kluczy zarządzanych przez klienta, ta dostępność nie ma zastosowania. Zobacz Odczytywanie zaszyfrowanych pól.

Korzystanie z tabeli historii zapytań

Tabela historii zapytań zawiera rekordy zapytań wykonywanych za pomocą magazynów SQL, obliczeń serwerless dla notebooków i zadań oraz potoków Lakeflow wykorzystujących serwerless lub klasyczne obliczenia. Tabela zawiera rekordy ze wszystkich przestrzeni roboczych na Twoim koncie, które znajdują się w tym samym regionie co przestrzeń, z której korzystasz do dostępu do tabeli.

Domyślnie tylko administratorzy mają dostęp do tabeli systemowej. Jeśli chcesz udostępnić dane tabeli użytkownikowi lub grupie, usługa Databricks zaleca utworzenie dynamicznego widoku dla każdego użytkownika lub grupy. Zobacz Tworzenie widoku dynamicznego.

Schemat tabeli systemu historii zapytań

Tabela historii zapytań używa następującego schematu:

Uzyskaj dostęp do tekstu oświadczenia maskowanego

Oświadczenia SQL mogą zawierać wrażliwe informacje, takie jak imiona klientów, adresy e-mail lub inne dane osobowe (PII). Pole statement_text zwraca się <REDACTED> domyślnie. Administratorzy kont i członkowie databricks_pii_access grupy mogą przeczytać pełny tekst zapytania.

Aby utworzyć grupę oraz zarządzać jej członkostwem i uprawnieniami, zobacz Utwórz i zarządzaj grupądatabricks_pii_access.

Rozwiązywanie problemów nakładających się masek kolumnowych

Jeśli już zastosowałeś maskę kolumnową do statement_text, na przykład za pomocą polityki kontroli dostępu opartej na atrybutach (ABAC), zapytania przeciwko system.query.history mogą zawiódć z .COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS Tylko jedna maska kolumnowa może być przypisana do kolumny dla danego użytkownika.

Aby rozwiązać konflikt, musisz być administratorem metastore lub mieć MANAGE go na stole. Użyj reguł dla wielu filtrów i masek, aby zidentyfikować nakładające się polityki, a następnie zawęż lub usuń maskę na .statement_text

Odczytywanie zaszyfrowanych pól

Gdy obszary robocze używają kluczy zarządzanych przez klienta dla usług zarządzanych, pola statement_text i error_message w tabeli systemowej są domyślnie szyfrowane. Dzieje się tak, ponieważ tabele systemowe przechowują dane z i mogą być dostępne dla wszystkich obszarów roboczych w regionie. Aby odszyfrować i wyświetlić zaszyfrowane pola tabeli systemu, administratorzy kont muszą dodać konfigurację klucza do system samego katalogu. Aby wykonać tę operację, musisz mieć uprawnienia MANAGE do system katalogu.

Gdy tabela historii zapytań korzysta z kluczy zarządzanych przez klienta, typowa dostępność rekordów w dostępności rekordów nie ma zastosowania.

Możesz utworzyć nowy klucz lub użyć go ponownie. Używając pełnego identyfikatora klucza, uruchom następujące polecenie:

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

Daj do 24 godzin na system.query.history rozpoczęcie wyświetlania zaszyfrowanych pól.

Wyświetlanie profilu zapytania dla rekordu

Aby przejść do profilu zapytania zapytania na podstawie rekordu w tabeli historii zapytań, wykonaj następujące czynności:

1. Zidentyfikuj interesujący rekord, a następnie skopiuj rekord .statement_id
2. Odwołaj się do właściwości rekordu workspace_id, aby upewnić się, że jesteś zalogowany do tego samego obszaru roboczego co rekord.
3. Kliknij Historia zapytań na pasku bocznym obszaru roboczego.
4. W polu Identyfikator oświadczenia wklej statement_id wartość w rekordzie.
5. Kliknij nazwę zapytania. Pojawi się przegląd metryk zapytań.
6. Kliknij Zobacz profil zapytania.

Zrozumienie metryk skanowania

Tabela historii zapytań zawiera wiele metryk zebranych podczas skanowania. Możesz obliczyć następujące dodatkowe metryki z kolumn tabeli:

• table_bytes: Całkowity skompresowany rozmiar, w bajtach, plików w skanowanych tabelach. Obliczone jako pruned_files_bytes + read_files_bytes.
• table_files: Całkowita liczba plików w zeskanowanych tabelach. Obliczone jako read_files + pruned_files.

Zrozumienie kolumny query_source

Kolumna query_source zawiera zestaw unikatowych identyfikatorów jednostek Azure Databricks zaangażowanych w wykonywanie instrukcji.

Jeśli kolumna query_source zawiera wiele identyfikatorów, to oznacza, że wykonanie instrukcji wyzwolono przez wiele jednostek. Na przykład wynik zadania może wyzwolić alert, który wywołuje zapytanie SQL. W tym przykładzie wszystkie trzy identyfikatory zostaną wypełnione w pliku query_source. Wartości tej kolumny nie są sortowane według kolejności wykonywania.

Możliwe źródła zapytań to:

• alert_id: deklaracja wyzwolona przez alert
• sql_query_id: instrukcja wykonana z tej sesji edytora SQL
• dashboard_id: instrukcja wykonywana na pulpicie nawigacyjnym
• genie_space_id: instrukcja wykonana z agenta genie
• notebook_id: instrukcja wykonana z notesu
• job_info.job_id: instrukcja wykonana w ramach zadania
• job_info.job_run_id: polecenie wykonane w trakcie uruchomienia zadania
• job_info.job_task_run_id: Instrukcja wykonana w ramach uruchomienia zadania

Prawidłowe kombinacje „query_source”

W poniższych przykładach pokazano, jak kolumna query_source jest wypełniana w zależności od sposobu uruchamiania zapytania:

• Podczas uruchamiania zadania wykonywane są zapytania, które obejmują wypełnioną strukturę job_info.

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

• Zapytania z alertów obejmują element sql_query_id i 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
}

• Zapytania z pulpitów nawigacyjnych obejmują element dashboard_id, ale nie 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
}