Ao longo dos anos, o cenário tecnológico do gerenciamento de dados deu origem a vários padrões de arquitetura, cada um deles cuidadosamente projetado para atender a casos de uso e requisitos específicos. Eles incluem padrões de armazenamento centralizado, como data warehouse, data lake e data lakehouse, além de padrões distribuídos, como data mesh. Cada uma dessas arquiteturas tem suas próprias vantagens e desvantagens. E como, historicamente, as ferramentas e as plataformas comerciais eram projetadas para se alinharem a um padrão de arquitetura específico, as organizações tinham dificuldade para se adaptar às necessidades comerciais em constante mudança, o que, obviamente, influenciou a arquitetura de dados.

Na Snowflake, achamos que recomendar um único padrão a ser adotado por todos os clientes não atende aos interesses deles. Em vez disso, nos esforçamos para ajudar os clientes, fornecendo uma plataforma capaz de criar arquiteturas com base no que funciona para suas organizações, mesmo que isso mude com o tempo. Com nossos clientes, observamos que a Lei de Conway se aplica com frequência. Os casos de uso, a tecnologia e as necessidades mudam e, portanto, a infraestrutura de dados deve permitir adaptar suas dimensões e evoluir com as mudanças. Temos o compromisso de oferecer uma opção e a capacidade de adaptação, mantendo nossos princípios fundamentais de segurança e governança sólidas, excelente desempenho e simplicidade.

Por exemplo, os clientes que precisam de um armazenamento centralizado de dados em grande volume e variedade, incluindo JSON, arquivos de texto, documentos, imagens e vídeo, criaram o data lake deles com o Snowflake. Além disso, muitos clientes com um repositório de tabelas em toda a empresa extremamente otimizado para SQL, e cargas de trabalho e relatórios de inteligência de mercado altamente simultâneos criaram um data warehouse no Snowflake. Os clientes que precisam combinar tudo isso para oferecer suporte a muitas ferramentas e linguagens diferentes criaram um data lakehouse. Muitos clientes preferem que as equipes sejam proprietárias de seus dados e sigam os padrões (em vez de ter uma equipe central de dados) para gerenciar a infraestrutura. Sendo assim, eles usaram o Snowflake como plataforma para seu data mesh.

Para acompanhar as necessidades de gerenciamento de dados em constante evolução, anunciamos novos recursos que oferecem suporte aos clientes em todos esses padrões.

A arquitetura de data lakehouse surgiu para combinar os benefícios de escalabilidade e flexibilidade dos data lakes com a governança, a aplicação de esquemas e as propriedades transacionais dos data warehouses. Desde o início, a plataforma Snowflake tem sido fornecida como um serviço, consistindo em armazenamento otimizado, processamento multicluster flexível e serviços de nuvem. Desde o lançamento em 2015, nosso armazenamento em tabela é, na verdade, um formato de tabela totalmente gerenciado, implementado sobre o armazenamento de objeto, semelhante ao que o mercado conhece hoje em código aberto, como Apache Iceberg, Apache Hudi e Delta Lake. Como o formato de tabela do Snowflake é totalmente gerenciado, recursos como criptografia, consistência transacional, controle de versão e Time Travel são fornecidos automaticamente.

Embora muitos clientes valorizem a simplicidade do armazenamento totalmente gerenciado e de um mecanismo de processamento único, multilíngue e multicluster para alimentar diversas cargas de trabalho, alguns preferem gerenciar seu próprio armazenamento usando formatos abertos. Por isso, adicionamos suporte ao Apache Iceberg. Embora existam outros formatos de tabela abertos, vemos o Apache Iceberg como o principal padrão aberto para formatos de tabela por vários motivos e, portanto, estamos priorizando o suporte a esse formato para atender melhor os clientes.

O Iceberg Tables (em breve, em versão preliminar pública) é um tipo de tabela única que oferece o gerenciamento fácil e o excelente desempenho do Snowflake aos dados armazenados externamente em um formato aberto. O Iceberg Tables também torna mais fácil e mais econômico o processo de integração sem exigir ingestão inicial. Para proporcionar flexibilidade aos clientes em relação à integração do Snowflake em sua arquitetura, o Iceberg Tables pode ser configurado para usar tanto o Snowflake quanto um serviço externo como o AWS Glue como o catálogo das tabelas para rastrear metadados. Isso pode ser feito com um simples comando SQL de uma linha para converter para o Snowflake em uma operação de metadados apenas.

Independentemente da configuração de um catálogo do Iceberg Tables, muitos aspectos permanecem consistentes:

• Os dados são armazenados externamente no bucket de armazenamento fornecido pelo cliente.
• O desempenho de consulta do Snowflake é, em média, pelo menos duas vezes melhor do que o do External Tables.
• Muitos outros recursos funcionam, incluindo compartilhamento de dados, controles de acesso baseados em funções, Time Travel, Snowpark, Object Tagging, Row Access Policies e políticas de mascaramento.

E quando o Iceberg Tables usa o Snowflake como o catálogo de tabelas para gerenciar metadados, há mais benefícios:

• O Snowflake pode executar operações de gravação como INSERT, MERGE, UPDATE e DELETE.
• Operações automáticas de manutenção de armazenamento, como compactação, expiração de snapshots e exclusão de arquivos órfãos.
• (Opcional) Clustering automático para consultas mais rápidas.
• O Apache Spark pode utilizar o kit de desenvolvimento de software (software development kit, SDK) do catálogo Iceberg do Snowflake para ler Iceberg Tables sem precisar usar recursos de processamento do Snowflake.

Um data lake é um padrão interessante de arquitetura devido à capacidade de armazenamento de objetos capaz de armazenar praticamente qualquer formato de arquivo, de qualquer esquema, em grande escala e a um custo relativamente baixo. Em vez de definir o esquema antecipadamente, o usuário pode decidir quais dados e esquemas são necessários para o seu caso de uso. O Snowflake há muito tempo oferece suporte a tipos de dados semiestruturados e formatos de arquivo como JSON, XML, Parquet e, mais recentemente, armazenamento e processamento de dados não estruturados, como documentos PDF, imagens, vídeos e arquivos de áudio. Quer os arquivos sejam mantidos no armazenamento gerenciado pelo Snowflake (estágio interno) ou no armazenamento de objetos externo (estágio externo), temos novos recursos para dar suporte a esses tipos de dados e casos de uso.

Expandimos nosso suporte a dados semiestruturados com a capacidade de inferir facilmente o esquema de arquivos JSON e CSV (em breve, disponível ao público) em um data lake. O esquema de dados semiestruturados tende a evoluir com o tempo. Sistemas que geram dados acrescentam novas colunas para acomodar informações adicionais, o que exige que as tabelas subsequentes evoluam de acordo. Para apoiar melhor esse processo, adicionamos suporte à evolução do esquema da tabela (em breve, disponível ao público).

Para casos de uso que envolvem arquivos como documentos PDF, imagens, vídeos e arquivos de áudio, agora você também pode usar o Snowpark para Python e Scala (disponível ao público) para processar dinamicamente qualquer tipo de arquivo. Os engenheiros e cientistas de dados podem fazer uso do mecanismo rápido do Snowflake com acesso seguro a bibliotecas de código aberto para processar imagens, vídeo, áudio, entre outros.

O SQL é, de longe, a linguagem mais comum para cargas de trabalho de data warehouse, e continuamos a expandir os limites dos tipos de processamento que podem ser realizados com SQL. Por exemplo, com o novo suporte para AS OF JOINs (em breve, em versão preliminar privada), os analistas de dados agora podem criar consultas muito mais simples que combinam dados de séries temporais. Esses casos de uso são comuns em serviços financeiros, Internet das Coisas (IoT) e casos de uso de engenharia de recursos, onde as junções de registros de data/hora não são correspondências exatas, mas sim aproximadas do registro mais próximo precedente ou seguinte. Estamos também melhorando o suporte para análises de dados avançadas no Snowflake ao aumentar o limite de tamanho de arquivo para carregamento, em breve em versão preliminar privada. No momento, é possível carregar objetos grandes (de até 128 MB), frequentemente necessários em casos de uso envolvendo processamento de linguagem natural, análise de imagem e análise de sentimento.

Continuamos comprometidos em aprimorar o desempenho e proporcionar economias de custo a nossos clientes. Com otimizações novas e aprimoradas, os clientes terão melhor desempenho e economia de custos de várias maneiras:

• Agora, as consultas ad-hoc em warehouses em casos de uso de aprendizado de máquina (machine learning, ML) com uso intenso de memória são mais rápidas e econômicas com o Query Acceleration Service para Snowpark Optimized Warehouses (disponível ao público).
• As instruções SELECT contendo cláusulas ORDER BY e LIMIT são mais rápidas, especialmente em tabelas grandes com top-k pruning (em breve, disponível ao público).
• Os custos de manutenção de Materialized View são reduzidos em mais de 50% com as novas eficiências no warehouse (disponível ao público).
• Agora, as consultas que utilizam funções não determinísticas como ANY_VALUE(), MODE() e outras tiram proveito de um cache de resultados para melhorar o desempenho. Com base em nossa análise, determinados padrões de consulta resultaram em uma redução de 13% nos créditos de trabalho para as consultas afetadas (disponível ao público).
• As instruções INSERT estão mais rápidas com o suporte adicionado ao Query Acceleration Service (em versão preliminar privada).
• Uma nova função para ajudar a estimar os custos de manutenção iniciais e contínuos do clustering automático em uma tabela específica (em versão preliminar privada).

Ficamos felizes em oferecer a nossos clientes esses novos recursos em uma única plataforma, permitindo que eles continuem desenvolvendo e adaptando a arquitetura de sua preferência com o Data Cloud. Entre em contato com o seu gerente de conta Snowflake para solicitar acesso a qualquer recurso mencionado acima em versão preliminar privada. Para recursos em versão preliminar pública ou disponíveis ao público, leia as notas de lançamento e a documentação para saber mais e começar a usar.

Para saber mais sobre como o Snowflake oferece suporte aos padrões de arquitetura descritos neste post de blog, visite nossas páginas para data warehouse, data lake, data lakehouse e data mesh.

Quer ver esses recursos em funcionamento? Confira a sessão do Snowday.

Declarações prospectivas
Este comunicado à imprensa contém declarações relativas a resultados futuros, como (i) a estratégia de negócios Snowflake, (ii) ofertas de produtos, serviços e tecnologias Snowflake, inclusive algumas que ainda estão em desenvolvimento ou que não se encontram disponíveis ao público geral, (iii) perspectivas de crescimento de mercado, tendências e concorrência, além de (iv) integração, interoperabilidade e disponibilidade de produtos Snowflake com e em plataformas de terceiros, entre outras declarações. Essas declarações prospectivas estão sujeitas a riscos, incertezas e suposições, incluindo, entre outros, os riscos descritos nos relatórios que apresentamos à Comissão de Valores Mobiliários dos EUA. Em vista desses riscos, incertezas e suposições, os resultados reais podem diferir de forma significativa e adversa daquilo que foi previsto ou pressuposto nas declarações prospectivas. As presentes declarações se sustentam somente na data em que foram feitas pela primeira vez. Exceto conforme exigido por lei, a Snowflake não assume qualquer obrigação de atualizar as declarações neste comunicado à imprensa. Consequentemente, você não deve se basear em quaisquer declarações prospectivas como previsões de eventos futuros.  

Neste comunicado à imprensa, todas as informações futuras sobre os produtos se destinam a descrever a direção geral de tal produto. O cronograma real de qualquer produto, recurso ou funcionalidade a ser disponibilizado pode ser diferente do que é apresentado neste comunicado à imprensa.