Referência à tabela de histórico de consultas do sistema

Este artigo inclui informações sobre a tabela do sistema de histórico de consultas, incluindo um resumo do esquema da tabela.

Caminho da tabela: Esta tabela do sistema encontra-se em system.query.history.

Disponibilidade de recordes

Os registos estão normalmente disponíveis dentro de uma hora. A entrega de dados para novos espaços de trabalho pode demorar mais do que isto.

Quando a tabela de histórico de consultas utiliza chaves geridas pelo cliente, esta disponibilidade não se aplica. Ver Leitura de campos encriptados.

Usando a tabela de histórico de consultas

A tabela de histórico de consultas inclui registos para consultas executadas usando SQL warehouses, computação serverless para notebooks e jobs, e pipelines Lakeflow que utilizam computação serverless ou clássica . A tabela inclui registos de todos os espaços de trabalho da sua conta que estão na mesma região do espaço de trabalho que usa para aceder à tabela.

Por padrão, apenas os administradores têm acesso à tabela do sistema. Se você quiser compartilhar os dados da tabela com um usuário ou grupo, o Databricks recomenda a criação de uma exibição dinâmica para cada usuário ou grupo. Consulte Criar uma vista dinâmica.

Esquema da tabela do sistema do histórico de consultas

A tabela de histórico de consultas usa o seguinte esquema:

Aceder ao texto da declaração mascarada

As instruções SQL podem conter informações sensíveis, como nomes de clientes, endereços de email ou outras informações pessoais identificáveis (PII). O statement_text campo devolve <REDACTED> por defeito. Administradores de contas e membros do databricks_pii_access grupo podem ler o texto completo da consulta.

Para criar o grupo e gerir a sua membresia e permissões, consulte Criar e gerir o databricks_pii_access grupo.

Resolução de problemas de máscaras de coluna sobrepostas

Se já aplicou uma máscara de coluna a statement_text, por exemplo, com uma política de controlo de acesso baseada em atributos (ABAC), consultas contra system.query.history podem falhar com COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS. Apenas uma máscara de coluna pode aplicar-se a uma coluna para um dado utilizador.

Para resolver o conflito, tens de ser administrador da metastore ou ter MANAGE disponível. Use filtros e máscaras conflitantes para identificar políticas sobrepostas, depois estreite ou remova a máscara em statement_text.

Leitura de campos encriptados

Quando os espaços de trabalho utilizam chaves geridas pelo cliente para serviços geridos, os statement_text campos e error_message na tabela do sistema são encriptados por defeito. Isto deve-se ao facto de as tabelas do sistema armazenarem dados e podem ser acedidas por todos os espaços de trabalho da região. Para desencriptar e exibir campos de tabelas de sistema encriptadas, os administradores de contas devem adicionar uma configuração de chave ao system próprio catálogo. Deve ter MANAGE permissão no system catálogo para realizar esta operação.

Quando a tabela de histórico de consultas utiliza chaves geridas pelo cliente, a disponibilidade típica de registos em Disponibilidade de Registo não se aplica.

Podes criar uma nova chave ou reutilizar uma já existente. Usando o ID da chave completo, execute o seguinte comando:

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

Espere até 24 horas para que a habilitação seja completada. Após a conclusão da habilitação, system.query.history começa a mostrar os campos encriptados para todos os novos registos. Registos criados antes da habilitação não podem ser desencriptados.

Exibir o perfil de consulta para um registro

Para navegar até o perfil de consulta de uma consulta com base em um registro na tabela de histórico de consultas, faça o seguinte:

1. Identifique o registo de interesse e, em seguida, copie o statement_id.
2. Faça referência ao registro workspace_id para garantir que você esteja conectado ao mesmo espaço de trabalho que o registro.
3. Clique no Histórico de consultas na barra lateral do espaço de trabalho.
4. No campo ID da declaração, cole o statement_id no registo.
5. Clique no nome de uma consulta. Uma visão geral das métricas de consulta é exibida.
6. Clique em Ver perfil da consulta.

Compreender métricas de varrimento

A tabela de histórico de consultas contém múltiplas métricas recolhidas durante a varredura. Pode calcular as seguintes métricas adicionais a partir das colunas da tabela:

• table_bytes: O tamanho total comprimido, em bytes, dos ficheiros nas tabelas digitalizadas. Calculado como pruned_files_bytes + read_files_bytes.
• table_files: O número total de ficheiros nas tabelas digitalizadas. Calculado como read_files + pruned_files.

Noções básicas sobre query_source coluna

A coluna query_source contém um conjunto de identificadores únicos de Azure Databricks entidades envolvidas na execução da instrução.

Se a query_source coluna contiver vários IDs, isso significa que a execução da instrução foi acionada por várias entidades. Por exemplo, um resultado de trabalho pode disparar um alerta que chama uma consulta SQL. Neste exemplo, todos os três IDs serão preenchidos em query_source. Os valores desta coluna não são ordenados por ordem de execução.

As possíveis fontes de consulta são:

• alert_id: Declaração acionada a partir de um alerta
• sql_query_id: Instrução executada a partir desta sessão do editor SQL
• dashboard_id: Declaração executada a partir do painel de controlo
• genie_space_id: Declaração executada a partir de um Agente Génio
• notebook_id: Declaração executada a partir de um notebook
• job_info.job_id: instrução executada dentro de um trabalho
• job_info.job_run_id: instrução executada a partir de uma execução de uma tarefa
• job_info.job_task_run_id: instrução executada dentro de uma tarefa de trabalho executada

Combinações válidas de query_source

Os exemplos a seguir mostram como a query_source coluna é preenchida dependendo de como a consulta é executada:

• As consultas executadas durante uma execução de trabalho incluem uma estrutura preenchida 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
}

• Consultas dos alertas incluem sql_query_id e 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
}

• As consultas dos painéis incluem um dashboard_id, mas não 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
}