Configurar um warehouse de detecção

Importante

Lakewatch está em prévia privada. Para solicitar acesso, entre em contato com a equipe da sua conta do Azure Databricks.

Detecções agendadas rodam em um SQL warehouse que você fornece. O Lakewatch não cria nem gerencia esse warehouse. Em vez disso, você o cria no seu espaço de trabalho e o seleciona quando cria uma detecção agendada. Criar e dimensionar um warehouse geralmente requer permissões de administrador de workspace, então isso normalmente é uma tarefa de configuração administrativa.

Esta página recomenda uma configuração inicial para um warehouse de detecção. Você pode compartilhar um único depósito entre todas as detecções agendadas em um espaço de trabalho.

Prerequisites

Um warehouse de detecção deve rodar Databricks SQL 2026.35 e superiores. O Lakewatch verifica a versão que o warehouse está executando, não a configuração do canal. Se o Databricks fixou seu warehouse em uma versão específica do Databricks SQL, a versão fixada também deve atender a esse mínimo.

Para verificar a versão que um warehouse está usando, execute esta consulta nesse warehouse:

SELECT current_version().dbsql_version;

Veja a current_version função.

Erros de armazém sem suporte

Quando o Lakewatch confere a versão

O Lakewatch valida a versão do warehouse nestes pontos:

  • Quando você cria uma regra: o Lakewatch rejeita a regra se seu depósito de dados não tiver suporte.
  • Quando você muda o SQL warehouse de uma regra ou o run-as-principal: o Lakewatch rejeita a mudança se o warehouse não for suportado.
  • Quando o Lakewatch revalida regras existentes: Se o armazém de uma regra existente não for compatível, o Lakewatch para de executar a regra e registra um evento do sistema para ela.

Se o Lakewatch não consegue determinar a versão que um warehouse está executando, ele trata o warehouse como não suportado.

Use um depósito compatível

Se o Lakewatch rejeitar um warehouse por causa de sua versão, a mensagem de erro começa com uma das seguintes:

  • SQL warehouse '<name>' (<id>) is running a version that Lakewatch does not support.
  • Lakewatch could not verify that SQL warehouse '<name>' (<id>) is supported.

Para recuperar:

  1. Selecione um warehouse SQL que atenda à versão mínima ou entre em contato com o suporte da Databricks para obter ajuda na atualização do warehouse.
  2. Tente novamente a criação ou atualização da regra.

Se você mudar uma regra existente para outro warehouse suportado, o Lakewatch revalida a regra imediatamente. Se o warehouse atual da regra for atualizado para uma versão suportada, o Lakewatch retoma a execução da regra na próxima vez que for revalidada.

Um erro diferente significa que o Lakewatch não conseguiu rodar a verificação de versão:

  • Lakewatch could not validate the SQL warehouse runtime. Check warehouse availability and the rule's run-as permissions, then retry.

Nesse caso, verifique se o depósito está disponível e se o principal de execução da regra pode usá-lo, então tente novamente.

Para a maioria dos workspaces, comece com um único warehouse SQL serverless compartilhado por todas as suas detecções programadas:

Setting Valor recomendado
Tipo Serverless
Size 2X-Small
Clusters (min) 1
Clusters (máx.) ceil(peak concurrent rules / 10), até o máximo de 40 clusters
Parada automática 10 minutos

Um warehouse 2X-Small pode executar 100 ou mais detecções simples. Como um SQL warehouse é cobrado por tempo de atividade do cluster em vez de por consulta, quanto mais regras compartilham um warehouse, menor será o custo por regra.

Note

Um warehouse com apenas uma ou duas regras pode custar o mesmo que, ou mais do que, a computação serverless. A vantagem de custo vem de compartilhar um único warehouse entre várias instâncias.

Quando ajustar

Mude os padrões conforme sua carga de trabalho:

  • Muitas regras, regras altas ou regras intermitentes: aumente a contagem máxima de clusters para que as consultas não entrem em fila. Adicionar clusters (escalar horizontalmente) é o principal nivelador para a simultaneidade. Cada cluster oferece aproximadamente 10 slots de consulta.
  • Detecções críticas de latência: defina um piso quente (2 ou mais clusters) ou uma parada automática mais longa para evitar partidas a frio, a um custo mais alto.
  • Poucas regras, infrequentes ou sensíveis ao custo: Reduza a parada automática para 5 minutos (o mínimo) para diminuir o tempo de marcha lenta. Um warehouse frio reinicia em cerca de 5 segundos.
  • Consultas pesadas ou complexas (varreduras ou joins grandes): Aumente o tamanho do warehouse (pequeno, médio ou maior). Use um tamanho maior (ampliando) apenas quando uma consulta individual precisar de mais memória ou computação.

Atribuição de custo

Para acompanhar o custo de detecção por si só, use um warehouse dedicado para cargas de trabalho de detecção em vez de compartilhar um com outras atividades de consulta. Como a faturação é por tempo de atividade do cluster, um warehouse dedicado facilita atribuir custo à detecção.

Próximas Etapas 

  • Última atualização em