Respostas do Databricks,sem notebook e sem uma linha de SQL.

Diga ao Connector Agent que você quer o Databricks, ou escolha o cartão dele no catálogo. Informe o server hostname e o HTTP path dos Connection details do seu SQL warehouse e depois cole um token de acesso no formulário seguro. Se quiser, informe um catálogo e um schema. Depois escolha as tabelas, defina com que frequência elas são atualizadas e aprove a primeira carga.

As tabelas e views do schema que você escolher, todas ou uma lista que você selecionar, com as colunas e os tipos delas. Funciona com Unity Catalog ou com o Hive metastore, por um SQL warehouse ou por um cluster all-purpose. O Querri só consegue ler o que o usuário ou o service principal do token consegue ler.

Uma releitura completa do schema pode ser agendada diária, semanal ou mensalmente. As sincronizações incrementais, guiadas por uma coluna de cursor como updated_at, rodam de hora em hora, diária ou semanalmente e trazem só as linhas além do último valor. Antes de uma reunião importante, dispare uma à mão. Linhas excluídas no Databricks continuam no Querri até a próxima atualização completa.

Não. O Querri só lê as suas tabelas do Databricks e nunca altera um registro nelas. Ele executa consultas de schema e SELECTs e nunca cria, atualiza ou exclui uma tabela ou linha. Essas consultas rodam no seu warehouse ou cluster, então uma sincronização usa a computação dele.

O Querri só consegue sincronizar o que foi concedido ao usuário ou ao service principal do token, então um service principal com acesso de leitura apenas ao schema que você quer é a configuração mais limpa. Depois da sincronização, as permissões do Unity Catalog deixam de valer pessoa a pessoa: o compartilhamento do Querri e um filtro de linhas para cada pessoa decidem o que ela vê.

Não. As perguntas são respondidas a partir de uma cópia que o Querri mantém das tabelas que você escolheu, atualizada no seu agendamento, então fazer uma pergunta nunca acorda um SQL warehouse nem impede que ele pare. Só as sincronizações consultam o Databricks. Uma resposta reflete os dados da sincronização mais recente.

Conecte também o NetSuite, e os dois chegam à mesma Biblioteca. O Querri pode cruzar o uso, os pedidos ou os envios do lakehouse com as faturas, os pedidos de venda e os pagamentos do NetSuite por um número de pedido ou um cliente em comum, e diz como fez o cruzamento. Defina uma vez qual uso é cobrável ou quando um pedido conta como enviado, e toda resposta segue essa definição.

Conecte o Salesforce ao lado do Databricks. O Querri cruza as contas entre os dois, de preferência por um ID guardado nos dois, para você colocar a atividade de produto ou de pedidos ao lado do pipeline, das renovações e dos casos em aberto. Se um cruzamento depender de um nome em vez de um ID, a resposta avisa.

Transforme a análise num projeto e associe um agendamento semanal. Na segunda de manhã ele é executado de novo sobre a cópia mais recente das suas tabelas do lakehouse e envia a cada gerente uma pasta de trabalho formatada só com a região dele, ou uma por cliente. O passo de baixar e colar deixa de existir.

Sincronize a tabela Delta em que o seu modelo grava a previsão, mais a tabela de pedidos ou de vendas. Defina uma vez o erro da previsão como um KPI, por região ou por produto. O Querri guarda o histórico dele desde o dia em que você começa, e os Insights noturnos sinalizam a região cujo erro se desvia.

Sim. Peça o dashboard em palavras simples, ou comece de um print de um que o seu time já usa, e altere-o pedindo. Um só dashboard pode misturar tabelas do lakehouse com dados do ERP, do CRM ou de planilhas, limitar cada pessoa às próprias linhas e ser incorporado no seu próprio app.

Sim. Depois de uma configuração única no Claude ou no ChatGPT, as perguntas sobre tabelas do lakehouse usam a sua Biblioteca do Querri, seguem as suas definições e regras e ficam dentro do que cada pessoa pode ver no Querri, então o assistente e os seus dashboards concordam.

Não. O conector precisa de um token de acesso, seja um token de acesso pessoal ou um de um service principal. O OAuth dependeria de um login no navegador, que não tem como ser concluído num servidor durante as sincronizações agendadas. O token de um service principal deixa a conexão independente de qualquer funcionário.

Uma conexão cobre um único catálogo e schema. Consultas SQL personalizadas não são suportadas, então selecione tabelas ou views. Não há OAuth nem escrita de volta, e as sincronizações incrementais não captam exclusões até a próxima atualização completa. Vários catálogos ou schemas significam simplesmente várias conexões.

Sim, pelo túnel VPN opcional nas configurações avançadas da conexão. Sem ele, o Querri recusa endereços privados e só se conecta por HTTPS na porta 443. Se um warehouse estiver parado ou o host estiver errado, a conexão desiste em poucos minutos em vez de ficar travada.

Sim. As linhas chegam em lotes de 50.000 em arquivos Parquet tipados, em vez de uma única extração gigante, e o progresso aparece à medida que as linhas chegam. Em tabelas que crescem todo dia, uma coluna de cursor faz cada execução ler só as linhas além da última. Você também pode limitar as linhas por tabela.

Não. Depois que as tabelas são sincronizadas, qualquer pessoa com acesso pergunta em linguagem natural. O Querri mostra os passos por trás de cada resposta, então alguém do time de dados pode conferir a lógica, e uma boa resposta pode ser salva como um projeto que é executado de novo com dados atualizados.

O Querri tem certificação SOC 2 Type II, HIPAA e ISO 27001:2022, e os seus dados nunca são usados para treinar um modelo. O seu token de acesso é criptografado em repouso, removido das mensagens de erro e nunca mostrado ao Connector Agent, e a conexão usa apenas HTTPS.