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.

Usando a tabela de histórico de consultas

A tabela de histórico de consultas inclui registos para consultas executadas usando SQL warehouses ou computação sem servidor para blocos de anotações e trabalhos . A tabela inclui registros de toda a conta de todos os espaços de trabalho na mesma região a partir da qual você acessa a 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 SQL completo.

O databricks_pii_access grupo não foi criado para ti. Um administrador de conta tem de criá-lo. O nome do grupo é sensível a maiúsculas e minúsculas.

Crie o grupo e gere a adesão usando qualquer um destes métodos:

• Consola da conta. Veja Adicionar grupos à sua conta.
• API de Grupos de Conta. Veja Gerir grupos usando a API.
• Sistema para Gestão de Identidade Multidomínio (SCIM). Veja Sincronizar utilizadores e grupos do Microsoft Entra ID usando SCIM.
• Gestão automática de identidade. Veja Gestão automática de identidades.

Se databricks_pii_access foi criado a partir das definições de administrador do espaço de trabalho, um administrador de conta pode revogar a permissão de gestão do administrador do espaço de trabalho no grupo:

1. Como administrador de conta, inicie sessão na consola da conta.
2. Na barra lateral, clique em Gerenciamento de usuários.
3. No separador Grupos , clique databricks_pii_accessem .
4. Clique na guia Permissões .
5. Remover o Gerenciar dos administradores do espaço de trabalho. Consulte Gerir permissões num grupo.

Depois de adicionares membros, os diretores podem databricks_pii_access ser desmascarados statement_text. Revise painéis, alertas e tarefas que leiam statement_text e confirme que o principal a gerir cada carga de trabalho está no grupo.

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 system.query.history começar a mostrar os campos encriptados.

::::

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.

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
}