Governança de custos do conector Snowflake para ServiceNow¶
Preview Feature — Open
Available to accounts in all Snowflake regions except government regions.
Este tópico fornece as práticas recomendadas para controle de custos e localização do tamanho de warehouse ideal para o conector Snowflake para ServiceNow.
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.
Se você usar uma configuração sem servidor, poderá consultar a exibição SERVERLESS_TASK_HISTORY, filtrar o nome do conector e verificar a coluna CREDITS_USED para obter o custo.
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 IN ('APP_PRIMARY', ‘<role created for the connector to ingest data>’)
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).
Para conectores configurados para usar tarefas sem servidor, você pode consultar a exibição SERVERLESS_TASK_HISTORY. A exibição expõe as colunas CREDITS_USED e DATABASE_NAME, a última das quais você pode usar para filtrar o nome do conector.
Custo de armazenamento¶
O conector Snowflake para ServiceNow armazena dados em dois lugares:
No banco de dados do conector, que é criado a partir do compartilhamento público e que 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 ServiceNow. As respostas do ServiceNow não geram custo pelo 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 funções externas no 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_FUNCTION.
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 a programação 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 STOP_CONNECTOR e RESUME_CONNECTOR.
Você pode automatizar o início e a parada do conector com tarefas sem servidor. 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
SCHEDULE USING CRON 0 17 * * MON-FRI Europe/London
AS CALL <my_connector_servicenow>.PUBLIC.RESUME_CONNECTOR();
CREATE TASK stop_connector_before_business_hours
SCHEDULE USING CRON 0 9 * * MON-FRI Europe/London
AS CALL <my_connector_servicenow>.PUBLIC.STOP_CONNECTOR();