Governança de custos do Snowflake Connector for ServiceNow®V2¶
O Snowflake Connector para ServiceNow® V2 está sujeito aos Termos do Snowflake Connector.
Este tópico fornece as práticas recomendadas para controle de custos e localização do tamanho de warehouse ideal para o Snowflake Connector for ServiceNow®V2.
Como medir o custo do conector¶
Se o conector tiver uma conta separada apenas para ingestão e armazenamento de dados e a conta não mostrar nenhuma outra atividade (como a execução de consultas por usuários usando os dados ingeridos), você poderá ler o custo geral no nível da conta. Para saber mais, consulte Exploração do custo total.
Se a conta não for dedicada apenas ao conector ou você precisar investigar mais os custos, analise os custos cobrados pelos três componentes separadamente:
Para obter uma introdução a esses três componentes de custo, consulte Compreensão do custo total.
Recomendações gerais¶
Para obter o custo gerado pelo conector, recomendamos que você crie uma conta separada exclusivamente para usar o conector. Dessa forma, você pode rastrear a transferência de dados exata gerada pelo conector.
Se você não puder usar uma conta separada para o conector, tente o seguinte:
Crie um banco de dados separado para armazenar dados ingeridos para rastrear o custo de armazenamento mais facilmente.
Aloque um warehouse apenas para o conector para obter o custo de computação exato.
Use tags de objeto em bancos de dados e um warehouse para criar relatórios de custos personalizados.
Custo de computação¶
Recomendamos que você crie um warehouse separado apenas para o conector. Esta configuração permite criar monitores de recursos no warehouse. Você pode usar os monitores para enviar alertas de e-mail e suspender o warehouse, parando o conector quando a cota de crédito definida for excedida. O conector é retomado automaticamente após a renovação da cota de crédito. Observe que definir uma cota de crédito muito baixa em configurações em que grandes volumes de dados são ingeridos pode fazer com que o conector não ingira todos os dados.
Para obter mais informações sobre como verificar os créditos consumidos pelo warehouse, consulte Exploração do custo de computação. Você também pode atribuir tags de objeto ao warehouse e usar as tags para criar relatórios de custos.
Se o warehouse usado pelo conector for usado por outros fluxos de trabalho, você poderá dividir o custo por funções. Para dividir o uso por funções, use a consulta para dividir o uso do warehouse e adicione a seguinte cláusula WHERE
na exibição QUERY_HISTORY:
WAREHOUSE_NAME = '<connector warehouse name>' AND ROLE_NAME = 'APP_PRIMARY'
A consulta fornece apenas um custo aproximado.
Nota
Apenas um aplicativo nativo pode usar o warehouse, caso contrário, os custos de diferentes aplicativos são inseparáveis porque cada aplicativo nativo usa o mesmo nome de função (APP_PRIMARY).
Custo de armazenamento¶
O Snowflake Connector for ServiceNow®V2 armazena dados em dois locais:
No banco de dados do conector, que é criado a partir da listagem e contém o estado interno do conector.
No esquema especificado pelo usuário no qual os dados ingeridos são armazenados.
O armazenamento de dados também é usado pelo recurso de Fail-safe do Snowflake. A quantidade de dados armazenados no Fail-safe depende das atualizações da tabela feitas pelo conector. A quantidade de dados aumenta se as linhas da tabela ingeridas do ServiceNow® forem atualizadas frequentemente ou toda a tabela for recarregada. Normalmente, sete a dez dias após a configuração do conector, a quantidade de dados Fail-safe se estabiliza (supondo que nenhum recarregamento seja executado e que o fluxo de dados ingeridos esteja em uma taxa constante).
Se quiser verificar o uso de armazenamento no Snowsight, recomendamos que você tenha um banco de dados separado para armazenar os dados ingeridos. Dessa forma, você pode filtrar os gráficos de uso de armazenamento por objeto, que mostram o uso por bancos de dados separados. Você também pode fazer isso consultando a exibição DATABASE_STORAGE_USAGE_HISTORY e filtrando ambos os bancos de dados usados pelo conector.
Se o banco de dados contiver outros esquemas não relacionados ao conector, você poderá consultar o uso de armazenamento de um esquema específico dedicado aos dados ingeridos do conector. Você pode obter as informações da exibição TABLE_STORAGE_METRICS depois de filtrar por nomes de banco de dados e esquema e agregar colunas com uso de armazenamento.
Custo de transferência de dados¶
O conector usa funções externas para recuperar dados do ServiceNow®. O Snowflake cobra apenas pelo tráfego de saída gerado pelo conector, com base no tamanho das solicitações do conector para o ServiceNow®. As respostas do ServiceNow® não geram custo do lado do Snowflake.
As informações sobre o uso da transferência de dados estão disponíveis apenas na forma agregada para todas as integrações de acesso externas ao nível da conta. Para acessar o número de bytes transferidos, use a exibição DATA_TRANSFER_HISTORY e filtre pelo tipo de transferência EXTERNAL_ACCESS.
Custo da tarefa de verificação de saúde¶
O conector cria uma tarefa sem servidor que verificará regularmente o status de integridade da instância de seu aplicativo e enviará apenas o resultado resumido (se estiver íntegro ou não) ao Snowflake. A tarefa é criada após a conclusão do assistente de instalação (ou chamando FINALIZE_CONNECTOR_CONFIGURATION
nas planilhas). Ele roda em segundo plano e gera um custo fixo de até 0,5 crédito/dia, mesmo se nenhuma tabela ServiceNow® estiver habilitada para replicação.
A tarefa não pode ser interrompida ou descartada manualmente. No entanto, para reduzir esse custo, você pode chamar o procedimento PAUSE_CONNECTOR
, que desabilitará a tarefa e não gerará nenhum custo quando o conector não for utilizado.
Otimização de custo¶
Como determinar o tamanho ideal do warehouse para a instância do conector¶
Para encontrar o tamanho ideal do warehouse para o conector, você deve considerar os fatores que afetam o desempenho do conector, como o tamanho da instância do ServiceNow, o número de tabelas habilitadas e o cronograma para sincronizar cada tabela. Por exemplo, se apenas algumas tabelas estiverem habilitadas, o conector pode não se beneficiar do aumento da paralelização.
Recomendamos que você defina um conjunto de expectativas mensuráveis, como intervalos de tempo em que todas as tabelas devem ser sincronizadas, e escolha o menor tamanho de warehouse que atenda a essas expectativas. Para grandes quantidades de dados ingeridos com dezenas de tabelas sincronizadas, a recomendação padrão é um warehouse Large. Por outro lado, quando você deseja apenas experimentar o conector e habilitar uma única tabela para ingestão, um warehouse X-Small deve ser suficiente. Para saber se é possível reduzir o tamanho do warehouse, consulte Monitoramento da carga do warehouse.
Como iniciar e parar o conector automaticamente dentro de um período especificado¶
Para economizar custos, você pode executar o conector somente durante um período especificado (por exemplo, fora do horário comercial), chamando os procedimentos PAUSE_CONNECTOR
e RESUME_CONNECTOR
.
Você pode automatizar a pausa e a retomada do conector com tarefas. Por exemplo, para executar o conector fora do horário comercial UTC, você pode usar a seguinte consulta:
CREATE TASK start_connector_after_business_hours
WAREHOUSE = <my_warehouse>
SCHEDULE USING CRON 0 17 * * MON-FRI Europe/London
AS CALL <my_connector_servicenow>.PUBLIC.RESUME_CONNECTOR();
CREATE TASK stop_connector_before_business_hours
WAREHOUSE = <my_warehouse>
SCHEDULE USING CRON 0 9 * * MON-FRI Europe/London
AS CALL <my_connector_servicenow>.PUBLIC.PAUSE_CONNECTOR();
Configuração de um cronograma de ingestão de dados personalizado¶
É possível configurar cronogramas de ingestão específicos para qualquer tabela. Isso pode ser usado para reduzir o uso do warehouse e a carga ServiceNow® por exemplo, durante o horário comercial. Por exemplo, para ingerir uma tabela example_table
apenas uma vez por semana durante uma corrida de fim de semana:
CALL <my_connector_servicenow>.PUBLIC.CONFIGURE_TABLES_SCHEDULE(['example_table'], { 'type': 'custom', 'value': { 'hour': 11, 'dayOfWeek': '6' } });
Isso fará com que o conector realize a ingestão dos dados para a tabela example_table
às 11 AM UTC todo sábado.