Considerações sobre armazenamento de dados¶
Este tópico fornece diretrizes e práticas recomendadas para controlar os custos de armazenamento de dados associados à proteção contínua de dados (CDP), particularmente para tabelas.
O CDP, que inclui o Time Travel e o Fail-safe, é um conjunto padrão de recursos disponíveis para todas as contas Snowflake, sem custo adicional. Entretanto, como sua conta é cobrada por todos os dados armazenados em tabelas, esquemas e bancos de dados criados na conta, o CDP tem um impacto nos custos de armazenamento, com base na quantidade total de dados armazenados e no período de tempo em que os dados são armazenados.
O armazenamento é calculado e cobrado pelos dados, independentemente de estar no estado ativo, Time Travel ou Fail-safe. Como estes estados do ciclo de vida são sequenciais, os dados atualizados/excluídos que são protegidos pelo CDP continuarão a incorrer em custos de armazenamento até que saiam do estado Fail-safe.
Nota
TIME_TRAVEL_BYTES e FAILSAFE_BYTES incorrerá em custos quando você carregar dados usando INSERT, COPY ou SNOWPIPE. Isso acontece pois a desfragmentação de pequenas micropartições elimina pequenas micropartições e cria uma nova micropartição que tem os mesmos dados. As micropartições excluídas contribuem para TIME_TRAVEL_BYTES e FAILSAFE_BYTES.
Neste tópico:
Monitoramento do armazenamento de dados¶
Armazenamento para sua conta (somente administradores de conta)¶
Se você tiver a função ACCOUNTADMIN (ou seja, é um administrador de nível superior para sua conta Snowflake), pode usar Snowsight ou Classic Console para visualizar o armazenamento de dados em toda a sua conta:
- Snowsight
Select Admin » Cost Management » Consumption.
- Classic Console
Clique em Account
» Billing & Usage » Average Storage Used
Esta página exibe a média total de armazenamento de dados para sua conta, assim como o total para todos os bancos de dados, estágios internos e nomeados e dados no Fail-safe.
Para obter mais informações, consulte Exploração do custo de armazenamento.
Armazenamento de tabelas individuais¶
Qualquer usuário com os privilégios apropriados pode visualizar o armazenamento de dados para tabelas individuais. O Snowflake fornece os seguintes métodos para a visualização do armazenamento de dados de tabela:
- Classic Console
Clique em Databases
» <nome_bd> » Tables- SQL
Execute um comando SHOW TABLES.
ou
Consulte um dos seguintes:
Exibição TABLE_STORAGE_METRICS (no Snowflake Information Schema).
Exibição Exibição TABLE_STORAGE_METRICS (em Account Usage).
Dos três métodos, TABLE_STORAGE_METRICS fornece as informações mais detalhadas porque inclui uma discriminação do armazenamento físico (em bytes) para os dados de tabela nos três estados seguintes do ciclo de vida do CDP:
Ativo (coluna ACTIVE_BYTES)
Time Travel (coluna TIME_TRAVEL_BYTES)
Fail-safe (coluna FAILSAFE_BYTES)
A exibição também fornece colunas para distinguir entre armazenamento próprio e armazenamento referenciado ao clonar tabelas (consulte a seção abaixo).
Armazenamento de arquivos preparados (para carregamento de dados)¶
Para oferecer suporte a o carregamento em massa de dados em tabelas, o Snowflake utiliza estágios onde os arquivos contendo os dados a serem carregados são armazenados. O Snowflake suporta tanto estágios internos quanto externos.
Os arquivos de dados preparados em estágios internos do Snowflake não estão sujeitos aos custos adicionais associados ao Time Travel e ao Fail-safe, mas incorrem em custos padrão de armazenamento de dados. Como tal, para ajudar a gerenciar seus custos de armazenamento, a Snowflake recomenda que você monitore esses arquivos e os remova dos estágios uma vez que os dados tenham sido carregados e os arquivos não sejam mais necessários. Você pode escolher remover estes arquivos durante o carregamento de dados (usando o comando COPY INTO <tabela>) ou depois (usando o comando REMOVE).
Para obter mais informações, consulte Considerações sobre o carregamento de dados.
Dica
A remoção periódica em arquivos preparados pode ter outros benefícios, tais como um melhor desempenho no carregamento de dados.
Clonagem de tabelas, esquemas e bancos de dados¶
O recurso de clonagem zero-copy do Snowflake fornece uma maneira conveniente de tirar rapidamente um “instantâneo” de qualquer tabela, esquema ou banco de dados e criar uma cópia derivada daquele objeto que inicialmente compartilha o armazenamento subjacente. Isto pode ser extremamente útil para a criação de backups instantâneos que não incorram em custos adicionais (até que sejam feitas alterações no objeto clonado).
Entretanto, a clonagem torna o cálculo do uso total de armazenamento mais complexo, pois cada clone tem seu próprio ciclo de vida separado. Isto significa que mudanças podem ser feitas no objeto original ou no clone independentemente um do outro, e estas mudanças são protegidas através do CDP.
Por exemplo, quando um clone é criado a partir de uma tabela, não utiliza armazenamento de dados porque compartilha todas as micropartições existentes da tabela original no momento em que foi clonado; no entanto, linhas podem então ser adicionadas, excluídas ou atualizadas no clone independentemente da tabela original. Cada mudança no clone resulta em novas micropartições que são de propriedade exclusiva do clone e são protegidas através do CDP.
Além disso, os clones podem ser clonados, sem limitações no número ou iterações de clones que podem ser criados (por exemplo, pode-se criar um clone de um clone de um clone e assim por diante), o que resulta em uma hierarquia em nível n de objetos clonados, cada um com sua própria porção de armazenamento de dados compartilhada e independente.
IDs de tabela¶
Cada tabela do Snowflake tem uma ID que a identifica de forma única. Além disso, cada tabela também está associada a uma CLONE_GROUP_ID. Se uma tabela não tem clones, então ID e CLONE_GROUP_ID são idênticas. Estas IDs são exibidas em TABLE_STORAGE_METRICS.
Armazenamento próprio vs. armazenamento referenciado¶
Quando uma tabela é clonada, recebe uma nova ID e a CLONE_GROUP_ID para a tabela original. No momento em que o clone é criado, todas as micropartições em ambas as tabelas são totalmente compartilhadas. O armazenamento associado a estas micropartições é propriedade da tabela mais antiga do grupo de clones, e o clone referencia estas micropartições.
Depois que um clone é criado, ambas as tabelas dentro do grupo de clones têm ciclos de vida separados, de modo que qualquer operação DML em qualquer uma das tabelas cria novas micropartições que são de propriedade de suas respectivas tabelas. O armazenamento associado a estas micropartições pode ser consultado usando a coluna RETAINED_FOR_CLONE_BYTES na exibição TABLE_STORAGE_METRICS.
Como cada tabela dentro de um grupo de clones tem um ciclo de vida independente, a propriedade do armazenamento dentro dessas tabelas às vezes precisa ser transferida para uma tabela diferente dentro do grupo de clones. Por exemplo, considere um grupo de clones que consiste em:
Tabela original:
Clonado para:
Clonado para:
T1
»
T2
»
T3
Se T2 e T3 compartilham algumas micropartições e T2 é descartada, então a propriedade desse armazenamento deve ser transferida antes que T2 entre no Fail-safe. No Snowflake, esta transferência ocorre no momento em que as micropartições saem do estado Time Travel e, de outra forma, entrariam no estado Fail-safe. No caso acima, as micropartições que antes pertenciam a T2 são transferidas para T3 quando o período de retenção do Time Travel expira.
Gerenciamento de custos para tabelas de curta duração¶
O CDP é projetado para fornecer proteção a longo prazo para seus dados. Esses dados são normalmente armazenados em tabelas permanentes. A menos que especificado de outra forma no momento de sua criação, as tabelas no Snowflake são criadas como permanentes.
Durante um processo de ETL ou modelagem de dados, podem ser criadas tabelas que são de curta duração. Para estas tabelas, não faz sentido incorrer nos custos de armazenamento do CDP. O Snowflake fornece dois mecanismos separados para oferecer suporte a tabelas de curta duração:
Tabelas temporárias
Tabelas transitórias
Tabelas temporárias¶
Semelhante a outros bancos de dados SQL, uma tabela temporária existe apenas dentro de uma única sessão de usuário e apenas dentro da duração da sessão. As tabelas temporárias do Snowflake não têm Fail-safe e tem um período de retenção do Time Travel de apenas 0 ou 1 dia; entretanto, o período do Time Travel termina quando a tabela é descartada.
Assim, o total máximo de cobranças do CDP incorridas por uma tabela temporária é de 1 dia (ou menos se a tabela for explicitamente descartada, ou descartada como resultado do encerramento da sessão). Durante este período, o Time Travel pode ser realizado na tabela.
Importante
Uma conexão e uma sessão são conceitos diferentes dentro do Snowflake. Quando você faz login no Snowflake, uma ou mais sessões podem ser criadas. Uma sessão do Snowflake só é encerrada se o usuário encerrar explicitamente a sessão ou se a sessão terminar devido a inatividade após 4 horas. A desconexão do Snowflake não encerra as sessões ativas. Assim, uma sessão do Snowflake pode durar muito tempo, e quaisquer tabelas temporárias criadas dentro dessa sessão continuarão a existir até que elas sejam descartadas ou que a sessão seja encerrada.
Para evitar custos inesperados de armazenamento para tabelas temporárias, a Snowflake recomenda criá-las conforme necessário dentro de uma sessão e descartá-las quando não forem mais necessárias.
Tabelas transitórias¶
As tabelas transitórias são exclusivas do Snowflake. Têm características tanto de tabelas permanentes como temporárias:
Ao contrário das tabelas temporárias, as tabelas transitórias não estão associadas a uma sessão; elas são visíveis para todos os usuários que têm permissões de acesso a essa tabela. Além disso, à semelhança das tabelas permanentes, elas persistem além da sessão em que foram criadas.
De acordo com as tabelas temporárias, as tabelas transitórias não têm Fail-safe e têm um período de retenção do Time Travel de apenas 0 ou 1 dia.
Assim, o total máximo de cobranças do CDP incorridas por uma tabela transitória é de 1 dia. Durante este período, o Time Travel pode ser realizado na tabela.
Gerenciamento de custos para tabelas grandes e de alta rotatividade¶
Em plataformas de dados, as tabelas são tipicamente tabelas de fatos ou dimensões, que têm diferentes padrões de uso e, portanto, diferentes considerações de armazenamento:
As tabelas de fatos são normalmente muito grandes e experimentam um baixo grau de rotatividade (atualizações ou exclusões de linhas). A maioria das mudanças nas tabelas de fatos são inserções de novos dados ou, em alguns casos, exclusões de dados mais antigos. O CDP é ideal para tabelas de fatos, pois oferece proteção total dos dados a um custo de armazenamento muito baixo.
As tabelas de dimensões têm um padrão de atualização diferente. As atualizações e exclusões de linhas são muito mais comuns em tabelas de dimensões. Quando uma ou mais linhas de uma tabela são atualizadas ou excluídas, as micropartições subjacentes que armazenam esses dados iniciam as transições do ciclo de vida associadas ao CDP. Para tabelas de dimensões de alta rotatividade, o armazenamento resultante associado aos dados do Time Travel e do Fail-safe pode ser muito maior do que o armazenamento das tabelas ativas.
Para a grande maioria das tabelas de dimensões, o custo de armazenamento do CDP associado a estas atualizações é razoável. As tabelas de dimensões são geralmente pequenas em tamanho e, mesmo se frequentemente atualizadas, o custo do armazenamento no Snowflake é baixo, e os benefícios do CDP superam de longe os custos.
Para algumas tabelas maiores e de alta rotatividade, os custos de armazenamento associados ao CDP podem ser significativos. Quando múltiplas atualizações são feitas em uma tabela, todas as micropartições impactadas são recriadas e depois transitam através do ciclo de vida de armazenamento do CDP.
As tabelas de dimensões de alta rotatividade podem ser identificadas calculando a proporção de FAILSAFE_BYTES dividida por ACTIVE_BYTES na exibição TABLE_STORAGE_METRICS. Qualquer tabela com uma grande proporção é considerada como uma tabela de alta rotatividade. Como o armazenamento no Snowflake é barato e a maioria das tabelas de alta rotação consome uma quantidade modesta de armazenamento total, mesmo que a proporção seja alta, a opção preferida é criar estas tabelas como permanentes e usar o CDP para proteger os dados.
Em alguns casos, o custo de armazenamento para tabelas de dimensões de alta rotatividade é excessivo e você pode preferir uma opção alternativa ao CDP. Como exemplo extremo, considere uma tabela com linhas associadas a cada micropartição dentro da tabela (que consiste em 200 GB de armazenamento físico). Se cada linha for atualizada 20 vezes por dia, a tabela consumiria o seguinte armazenamento:
- Ativo
200 GB
- Time Travel
4 TB
- Fail-safe
28 TB
- Armazenamento total
32,2 TB
Para tabelas de dimensões grandes e de alta rotatividade que incorrem em custos excessivamente exagerados do CDP, a solução é criar estas tabelas como transitórias com retenção do Time Travel igual a zero (ou seja, DATA_RETENTION_TIME_IN_DAYS=0) e depois copiar estas tabelas periodicamente para uma tabela permanente. Isto cria efetivamente um backup completo destas tabelas. Como cada backup é protegido pelo CDP, quando um novo backup é criado, o antigo pode ser excluído.
Usando o exemplo acima, os custos de armazenamento associados à mesma tabela de dimensões de alta rotatividade com 200 GB, que tinha o backup realizado uma vez por dia, seriam:
- Ativo
200 GB
- Time Travel
200 GB
- Fail-safe
1,4 TB
- Backup
200 GB
- Armazenamento total
2 TB
Dica
Os backups devem ser realizados com a frequência necessária para garantir a recuperação total no caso de perda de dados. Para estas tabelas, a Snowflake recomenda que sejam feitos backups pelo menos uma vez por dia.