Implementação do Snowflake

A conta é configurada para que várias equipas possam trabalhar nela em segurança e com custos controlados: uma região na cloud, bases de dados e esquemas por camada, uma hierarquia de funções, virtual warehouses por tarefa, processos de carregamento para as fontes de dados, transformações em dbt e monitorização do consumo de créditos.

Fazemos isto no âmbito da plataforma de dados e IA, para que os relatórios e os modelos usem os mesmos dados.

Um consultor Snowflake desenha as funções, os warehouses e os processos de carregamento, e configura as transformações e a monitorização dos custos. O próprio Snowflake recomenda uma hierarquia de funções personalizadas e aconselha a não juntar, na mesma função, permissões de administração da conta e permissões de acesso aos dados.

ACCOUNTADMIN é a função mais elevada e, segundo o Snowflake, deve ser atribuída a um número limitado de utilizadores. Não existe nenhuma função que contorne todas as verificações de permissões.

O Snowflake funciona em Amazon Web Services, Google Cloud e Microsoft Azure. Escolhe-se uma região, como Azure West Europe ou Google Cloud europe-west4, ambas nos Países Baixos.

Para executar queries e carregar dados, é necessário um virtual warehouse: capacidade de processamento que se ativa separadamente. A dimensão determina a capacidade de processamento de cada cluster, e cada aumento de dimensão duplica o consumo de créditos por hora.

O Snowflake cobra a utilização dos warehouses ao segundo, com um mínimo de um minuto por cada ativação. Com auto-suspend, um warehouse é desativado após um período de inatividade; auto-resume volta a ativá-lo na query seguinte.

Um resource monitor acompanha uma quota de créditos e pode emitir avisos ou suspender warehouses. Só ACCOUNTADMIN pode criar estes monitores; para as funcionalidades serverless, utiliza-se um orçamento.

O Snowflake armazena as tabelas, enquanto o dbt as transforma em modelos com testes. Na nossa análise de churn, descrevemos esta combinação: modelos que selecionam colunas, fazem cálculos e produzem um conjunto de dados combinado.

Atenção: por predefinição, o dbt cria tabelas transient no Snowflake, sem Fail-safe. É possível escolher um warehouse específico para cada modelo. Saiba também mais sobre a implementação do dbt.

Em lotes, com COPY INTO a partir de um stage, num warehouse à escolha, cobrado pelo tempo de funcionamento. Ou continuamente, com Snowpipe: os ficheiros são carregados assim que chegam a um stage, usando capacidade de processamento do Snowflake e com cobrança baseada na quantidade de dados carregados.

Para fontes como um sistema ERP ou CRM, normalmente utiliza-se antes uma ferramenta de carregamento ou uma pipeline que fornece os ficheiros ou as tabelas.

Com Time Travel, é possível recuperar dados anteriores. O período de retenção predefinido é de um dia; para objetos permanentes, pode ser prolongado, exceto na Standard Edition. Uma tabela apagada pode ser restaurada com UNDROP. Depois desse período, os dados passam para Fail-safe e já não é possível recuperá-los diretamente.

Com um zero-copy clone, cria-se um ambiente de testes que só gera custos de armazenamento quando se fazem alterações.

Não. Segundo a nossa página de parceiros, somos Databricks Partner e Microsoft Partner. Trabalhamos com Snowflake quando se adequa a uma organização ou quando já está implementado, como na Athlon.

Se estiver a ponderar entre plataformas, apresentamos as diferenças de forma objetiva. Leia também sobre a implementação do Databricks; a decisão é sua.