.png)
Tabelas do Amazon S3: o futuro dos AWS Lakehouses
Recentemente introduzido pela AWS, o S3 Tables fornece tabelas Apache Iceberg totalmente gerenciadas diretamente no S3.
Neste post, explicaremos brevemente o que isso significa e sua importância, além de explorar algumas de suas principais características e limitações. Em seguida, ofereceremos algumas diretrizes úteis para analisar se essa ferramenta é apropriada para sua pilha de dados e como interagir com os dados salvos nela.
Apresentando as tabelas do Amazon S3
As tabelas do Amazon S3 fornecem armazenamento S3 para dados tabulares, representados em colunas e linhas, como em uma tabela de banco de dados SQL. Esses dados são armazenados em um novo tipo de bucket: um balde de mesa, em que as tabelas são sub-recursos.
Os baldes de mesa suportam o armazenamento de mesas no Iceberg Apache formato, permitindo o uso do SQL padrão para consultar suas tabelas com qualquer um dos mecanismos compatíveis com o Iceberg, como Amazon Athena, Amazon Redshift e Apache Spark.
Antes de nos aprofundarmos nas tabelas do S3 em si, vamos revisar alguns conceitos-chave relacionados a elas: Apache Iceberg e Data Lakehouses.
O que é o Apache Iceberg?
O Apache Iceberg é um formato de tabela de código aberto para grandes conjuntos de dados analíticos. É adiciona uma camada de abstração ao armazenamento de objetos, como o S3, permitindo que os dados possam ser consultados de forma confiável e eficiente por vários mecanismos diferentes.
Essa camada de abstração habilita recursos em um Data Lake que são típicos de data warehouses e bancos de dados relacionais, que geralmente são chamados de Data Lakehouse:
- Lagos de dados permitem que os usuários armazenem grandes volumes de dados a um baixo custo, ao mesmo tempo em que oferecem escalabilidade e flexibilidade. No entanto, eles carecem de alguns recursos cruciais para gerenciar esses dados, muitas vezes se tornando pântanos de dados. Eles dificultam a fiscalização da governança e da qualidade dos dados e não são otimizados para o desempenho das consultas.
- Data Lakehouses adicione a camada de abstração para fornecer, entre outros recursos, suporte a transações ACID e evolução de esquemas, ao mesmo tempo em que oferece suporte ao armazenamento em sistemas econômicos, como o Amazon S3.
Embora existam alguns concorrentes proprietários, como o Delta Lake da Databricks, o Iceberg se tornou a padrão para formatos de tabela Data Lakehouse. Ele oferece verdadeira interoperabilidade, sendo independente do fornecedor e amplamente adotado pelas principais plataformas, como Snowflake, Databricks e Dremio.
Além de permitir o uso de instruções SQL nos dados subjacentes e na evolução do esquema, o Apache Iceberg oferece suporte ao particionamento de dados e gerencia o controle de versão dos dados, permitindo viagens no tempo e reversões para estados anteriores. Ele também foi projetado para ser dimensionado, adequado para gerenciar tabelas com mais de centenas de gigabytes.
Opções de implementação do Data Lakehouse
Ao projetar e implementar um Data Lakehouse, tradicionalmente havia duas opções principais:
- Lakehouses de dados autogerenciados: Que incluem uma camada de armazenamento de dados, geralmente no S3 padrão ou no Google Cloud Storage, e um formato de tabela aberta, geralmente o Apache Iceberg. Essa opção oferece flexibilidade e baixos custos de armazenamento. No entanto, é necessário um alto grau de maturidade operacional para gerenciar o catálogo, otimizar o tamanho dos arquivos e lidar com gravações simultâneas.
- Plataformas proprietárias externas: Eles abstraem a manutenção e oferecem um desempenho incrível, mas geralmente vêm com taxas de licenciamento, altos custos de computação e um certo grau de dependência de fornecedores. Alguns exemplos dessas plataformas são Databricks e Snowflake.
Principais características das tabelas S3
O que diferencia esses novos buckets do Amazon S3 não é apenas o fato de eles oferecerem suporte a dados tabulares, mas também de gerenciá-los ativamente. Tradicionalmente, manter um data lake significava gerenciar cuidadosamente os metadados e os tamanhos dos arquivos, e as tabelas do S3 alteram essa dinâmica.
Esse gerenciamento é um fator-chave nos lagos modernos, pois seu gargalo mais importante é a degradação do layout de dados, geralmente chamada de problema de arquivos pequenos. Ao transmitir dados contínuos ou executar pipelines frequentes de ingestão de microlotes, milhares de arquivos fragmentados são gravados por hora. Essa hiperfragmentação cria uma falha em cascata em toda a arquitetura: ela aumenta o tamanho das listas de manifestos do Iceberg, sobrecarrega o catálogo de metadados e impõe uma enorme sobrecarga de abertura de arquivos no mecanismo de consulta. É exatamente por isso que a AWS introduziu o S3 Tables, integrando a manutenção automatizada de tabelas de forma nativa na camada de armazenamento.
Então, essencialmente, o Amazon S3 Tables oferece um ponto ideal entre a implementação do Iceberg autogerenciado e o aproveitamento de plataformas externas, que usam formatos e complementos proprietários.
A seguir estão algumas de suas principais características:
- Suporte integrado para Apache Iceberg
As tabelas nesses buckets são armazenadas nativamente no formato Iceberg, eliminando a necessidade de adicionar manualmente a camada de abstração sobre os arquivos simples no S3. Como mencionamos anteriormente, o Iceberg traz uma variedade de recursos para otimizar o desempenho da consulta e é o formato padrão de tabela aberta, consumível pela maioria dos fornecedores.
- Manutenção e otimização gerenciadas de tabelasO S3 executa continuamente as seguintes operações de manutenção automaticamente:
- Compactação: combinação de arquivos pequenos em arquivos maiores para reduzir a sobrecarga de metadados e tornar a verificação de consultas mais eficiente.
- Gerenciamento de instantâneos: expira os instantâneos antigos com base em períodos de retenção configuráveis, tornando os arquivos de dados correspondentes inatuais e limpando-os.
- Remoção de arquivos não referenciados: exclua arquivos de dados e metadados que não são mais referenciados por nenhum instantâneo.
- Expiração do registro: remoção de registros expirados com base em uma coluna de timestamp, disponível com o S3 Tables Intelligent-Tiering.
- Desacoplamento entre armazenamento e computação
O S3 Tables expõe um endpoint Iceberg REST Catalog, que é o padrão emergente para a interoperabilidade do catálogo Iceberg. Cada mecanismo de consulta compatível com o Iceberg pode ler e gravar diretamente em suas tabelas. Isso permite separar totalmente a camada de armazenamento dos mecanismos de computação. - Alta taxa de transferência
O S3 Tables é otimizado para as demandas de alta simultaneidade da análise moderna, fornecendo maiores transações por segundo (TPS) e melhor taxa de transferência de consultas em comparação com tabelas autogerenciadas em buckets de uso geral do S3. Ele também oferece a mesma durabilidade, disponibilidade e escalabilidade dos buckets S3 comuns.
- Gerenciamento e segurança de acesso
O acesso e as permissões para intervalos de tabelas, namespaces de tabelas e tabelas individuais podem ser gerenciados com o AWS Identity and Access Management (IAM), facilitando a governança de dados e integrando-a ao sistema de gerenciamento de segurança existente para outros recursos da nuvem da AWS.
Limitações das tabelas do S3
Embora o Amazon S3 Tables forneça uma variedade de recursos fortes, ele também oferece vantagens e desvantagens em controle, custo e flexibilidade, em comparação com catálogos Iceberg autogerenciados ou plataformas Lakehouse proprietárias (como Databricks ou Snowflake). A seguir estão algumas de suas principais limitações:
- A disponibilidade regional não é garantida
Nem todas as regiões da AWS oferecem suporte a esse serviço ainda. Você deve verificar a disponibilidade atual para suas regiões-alvo. - Flexibilidade limitada da classe de armazenamento
Um dos maiores pontos fortes do S3 é sua variedade de camadas de armazenamento, mas as tabelas do S3 são mais restritivas, suportando apenas o S3 Standard e o Intelligent-Tiering. Não há suporte para camadas frias individualmente. - Formato de arquivo único
Em baldes de tabela, o Iceberg é o único formato habilitado, você não pode armazenar registros brutos, CSVs ou imagens neles. - Menos métodos de acesso suportadosAo contrário do S3 padrão, você não pode gerar um URL pré-assinada para dar a terceiros acesso temporário a um arquivo de dados específico. O acesso deve passar pelo Catálogo REST do Iceberg. Além disso, baldes de mesa não suportam políticas de acesso público, todos os dados devem ser acessados por meio de APIs autenticadas da AWS ou mecanismos integrados.
- Aplicação da distinção entre maiúsculasPara garantir a compatibilidade com todos os serviços do AWS Analytics, os nomes e definições das tabelas devem usar todas as letras minúsculas.
Usa casos em que as tabelas S3 brilham
Descrevemos as características de Data Lakehouses, Iceberg e S3 Tables, mas, na prática: Como identificar se uma solução de dados específica se beneficiará da implementação de um Data Lakehouse e, mais especificamente, usando tabelas S3? Aqui estão algumas diretrizes para ajudar você a responder a essas perguntas.
Quando você precisa de um Data Lakehouse?
Você precisa de uma camada de abstração quando seu Data Lake começa a parecer um pântano de dados: você encontra dados corrompidos devido a gravações parciais e há dados redundantes ou não validados em seus arquivos. Além disso, se você precisa gerenciar arquivos linha por linha em vez de como uma unidade completa e seus esquemas estão sempre evoluindo, uma camada de abstração com um formato de tabela se torna essencial.
Um Data Lakehouse é ideal para implementar o armazenamento Bronze ou Raw Data em sua plataforma de dados, pois simplifica a governança de dados e reduz a duplicação de dados e os custos de infraestrutura. Ele permite que as organizações realizem análises de SQL de alto desempenho junto com aprendizado de máquina e streaming em tempo real.
Quando o S3 Tables é a escolha certa?
Depois de identificar a necessidade de um Data Lakehouse, o que torna as tabelas S3 especialmente adequadas? Aqui estão algumas características que podem tornar um caso específico um bom candidato para a implementação do S3 Tables:
- AWS como principal provedor de nuvem
Se a infraestrutura de nuvem da sua organização é construída principalmente na AWS, o S3 Tables é um recurso de primeira classe da AWS que se integra perfeitamente à sua infraestrutura principal. Você pode criar endpoints de interface VPC específicos, aplicar políticas do IAM, implementar pipelines de ingestão de código zero usando ferramentas como o Amazon Data Firehose e muito mais. - Necessidades de conformidade regulatória e auditoria
Setores como Fintech ou Healthcare geralmente exigem relatórios pontuais ou a capacidade de viajar no tempo e ver o estado de determinadas tabelas em uma data específica. Ao aproveitar o gerenciamento de versões nativas do Iceberg em um ambiente S3 gerenciado, você obtém controle de versão e auditoria integrados. Você pode consultar estados de dados históricos sem processos complexos de arquivamento manual.
- Ingestão de streaming de alta velocidade
O S3 Tables oferece um desempenho mensuravelmente melhor para cargas de trabalho de análise e streaming.- Ele suporta até 10 vezes mais operações por segundo do que um Iceberg Lakehouse autogerenciado em buckets S3 padrão, o que é essencial para cargas de trabalho com gravações simultâneas frequentes de vários pipelines.
- Como o desempenho da consulta depende muito da manutenção da tabela, as empresas com canais de ingestão de dados de alta velocidade (como streaming ou atualizações frequentes de ETL) se beneficiarão muito com a autootimização do S3 Tables.
- Ecossistemas de vários provedores
Em organizações em que muitos mecanismos de consulta e linguagens de programação diferentes são usados, a interoperabilidade fornecida pelo endpoint do Iceberg REST Catalog garante o acesso aos dados a todos os usuários, mantendo uma única versão dos dados. Por exemplo: a equipe de engenharia de dados usa o Spark, a equipe de Business Intelligence usa o Athena ou o Snowflake e a equipe de ciência de dados usa Python, e todas se conectam ao mesmo Data Lakehouse.
Quando as tabelas S3 podem não ser a melhor opção?
Há também algumas situações em que Lakehouses autogerenciados ou ferramentas proprietárias podem ser a melhor escolha, por exemplo:
- Necessidades de manutenção, controle e flexibilidade
Se você precisar de controle total sobre o layout do arquivo, as classes de armazenamento, as políticas de ciclo de vida e as propriedades da tabela Iceberg, sem as restrições que os serviços gerenciados impõem. Em uma configuração autogerenciada, você pode decidir exatamente quando executar a compactação, por exemplo. - Cargas de trabalho de arquivamento econômicas
Se você tiver uma grande quantidade de dados frios, que raramente são acessados, mas precisam ser mantidos por anos, os buckets de uso geral oferecem mais opções de classe de armazenamento, como Glacier Instant Retrieval ou Standard-IA. O custo de manutenção em um S3 Table Bucket será significativamente maior.
- Requisitos de co-localização de dados que não sejam do Iceberg
Se você precisar armazenar tabelas do Iceberg junto com dados não tabulares (imagens, registros, artefatos de ML) no mesmo bucket, são necessários buckets de uso geral.
Entendendo os custos
Ao avaliar as tabelas do S3 como um componente de sua plataforma de dados, é importante considerar o custo total de propriedade (TCO) em vez de apenas o custo de armazenamento. Embora o preço de armazenamento das tabelas do S3 seja estruturado de forma diferente do padrão S3 (e seja um pouco mais alto em GB), a diferença real vem do tempo de computação e engenharia.
Com o S3 Tables, você paga uma taxa nominal pela otimização de tabelas sem servidor executada pela AWS. No entanto, isso elimina a necessidade de ativar e pagar por seus próprios clusters EMR ou Glue apenas para executar trabalhos de OPTIMIZE, VACUUM ou de compactação. Isso é especialmente importante nos casos em que há gravações de alta frequência e várias tabelas, pois é necessária mais compactação e o custo operacional da manutenção aumenta.
Quando você considera os custos de computação economizados e as horas de engenharia recuperadas por não precisar criar e monitorar seus próprios pipelines de manutenção, o S3 Tables geralmente resulta em um TCO geral mais baixo.
Comentários sobre o desempenho da consulta
Outra consideração importante ao decidir sobre a infraestrutura do seu Data Lakehouse é o desempenho resultante da consulta de seus dados. Embora esse tópico seja complexo e exija uma postagem extensa por si só, reunimos alguns comentários importantes sobre ele.
A primeira coisa a saber é que o desempenho da consulta e os custos de computação no Apache Iceberg dependem de uma combinação de fatores, como: a arquitetura do mecanismo de execução, a eficiência das estruturas de arquivos subjacentes, a implementação do catálogo de metadados e as rotinas de manutenção aplicadas ao Lakehouse.
Para selecionar o mecanismo de consulta que consumirá seu Data Lakehouse, há duas opções principais:
- Plataformas ou armazéns de dados de proprietários externos
Como vimos, essas plataformas, como Databricks e Snowflake, podem hospedar todo o seu Data Lakehouse, mas também fornecem a tecnologia para consultá-lo. Cada mecanismo tem seus modelos primários de execução e alocação de recursos, bem como mecanismos de tratamento de concorrência e filosofias de otimização. Consequentemente, cada um tem cargas de trabalho específicas para as quais são mais adequadas.
Eles também podem consumir dados que residem em Lakehouses externos, como tabelas do S3 e opções autogerenciadas. Mas, em alguns casos, eles não podem oferecer o mesmo desempenho nessas fontes que nas internas.
- Mecanismos de consulta federados
Essas ferramentas permitem uma arquitetura de dados totalmente descentralizada, na qual os dados permanecem exclusivamente em Lakehouses ou tabelas S3 autogerenciadas e fornecem acesso direto ao SQL. Os motores mais proeminentes nessa categoria são Amazon Athena e Trino. Embora os dois mecanismos sejam projetados para execução distribuída de SQL em armazenamento de objetos, seus modelos operacionais são muito diferentes.
Esses motores são altamente econômicos para explorações ad hoc pouco frequentes. Para cenários de BI, quando você deseja criar relatórios comerciais sofisticados a partir de dados históricos, uma ferramenta de data warehouse, como o Amazon Redshift, é a escolha mais adequada.
Independentemente da ferramenta selecionada, o desempenho máximo do mecanismo de consulta depende muito do estado físico dos dados que estão no lago. Como mencionamos anteriormente, os Lakehouses modernos tendem a sofrer com o problema de arquivos pequenos. Uma solução gerenciada minimiza os esforços para evitar esse problema, enquanto, para organizações que operam mesas Iceberg autogerenciadas em armazenamento de uso geral, a implementação de uma rotina de manutenção rigorosa e automatizada não é negociável.
Como interagir com as tabelas do Amazon S3
Para acessar as tabelas armazenadas em um bucket de tabelas, você precisa integrá-las aos aplicativos de análise que suportam o Apache Iceberg. Há duas maneiras principais de fazer isso:
- Usando Catálogo de dados do AWS Glue, para se integrar principalmente aos serviços de análise da AWS e conectar-se a outros clientes terceirizados da Iceberg.
- Aproveitando o Endpoint REST Amazon S3 Tables Iceberg para se conectar diretamente a mecanismos de consulta de código aberto e outros serviços.
Integração do catálogo de dados do AWS Glue
Você pode integrar baldes de tabela ao catálogo de dados e aos serviços de análise da AWS usando controles de acesso do IAM por padrão ou, opcionalmente, usar os controles de acesso do Lake Formation.
Para realizar essa integração, você precisa habilitar a “Integração com os serviços de análise da AWS” para seus buckets de tabela, e o Amazon S3 adiciona o catálogo chamado catálogo de tabelas s3 como um catálogo federado no AWS Glue, na região atual. Em seguida, todos os buckets de tabelas, namespaces e tabelas atuais e futuras são preenchidos no catálogo de dados do AWS Glue nessa região, seguindo esta equivalência: os intervalos de tabela são mapeados como catálogos, os namespaces como bancos de dados e as tabelas permanecem tabelas.
- Você pode criar tabelas do Apache Iceberg em intervalos de tabela e acessá-las por meio dos seguintes mecanismos de análise da AWS: Amazon Athena, Amazon Redshift, Amazon EMR, Amazon Data Firehose, AWS Glue ETL, Quick and Querying S3 Tables with SageMaker Unified Studio.
- E você também pode usar mecanismos de análise de terceiros que suportam o Iceberg, por meio do Endpoint REST para AWS Glue Iceberg, usando qualquer cliente Iceberg, incluindo Spark, PyIceberg e muito mais.
Endpoint REST Amazon S3 Tables Iceberg
Você pode usar o endpoint Amazon S3 Tables Iceberg REST para acessar suas tabelas diretamente de qualquer cliente compatível com o Iceberg REST por meio de endpoints HTTP, para criar, atualizar ou consultar tabelas em buckets de tabelas do S3.
O endpoint implementa um conjunto de APIs REST Iceberg padronizadas especificadas na especificação da API aberta do catálogo REST do Apache Iceberg. O endpoint funciona traduzindo as operações da API REST do Iceberg em operações correspondentes às tabelas do S3.
Os seguintes serviços de análise e mecanismos de consulta da AWS podem acessar tabelas dessa forma: qualquer cliente Iceberg, incluindo Spark, PyIceberg e outros, bem como Amazon EMR e AWS Glue ETL.
Exemplo
Para usar o Endpoint REST Amazon S3 Tables Iceberg com PyIceberg, especifique as seguintes propriedades de configuração do aplicativo:
1rest_catalog = load_catalog(
2catalog_name,
3**{
4 "type" : "rest",
5 "warehouse" : "arn:aws:s3tables:<Region>:<accountID>:bucket/<bucketname>",
6 "uri": "https://s3tables.<Region>.amazonaws.com/iceberg",
7 "rest.sigv4-enabled": "true",
8 "rest.signing-name": "s3tables",
9 "rest.signing-region": "<Region>"
10 }
11)Em seguida, você pode usar a função de barra PyIceberg para ler dados de suas tabelas Iceberg, por exemplo. Você pode filtrar linhas, selecionar colunas específicas e limitar o número de registros retornados:
1table = rest_catalog.load_table(f"{database_name}.{table_name}")
2scan_df = table.scan(
3 row_filter=(
4 f"city = 'Amsterdam'"
5 ),
6 selected_fields=("city", "lat"),
7 limit=100,
8).to_pandas()
9
10print(scan_df)Conclusão
Para pilhas de dados modernas, a implementação de Data Lakehouses geralmente é um requisito, principalmente para implementar a camada de dados bruta, e o Apache Iceberg se tornou o formato padrão para isso.
Ao transformar o Apache Iceberg em uma camada de armazenamento totalmente gerenciada e sem servidor, a AWS está permitindo que as equipes recuperem as horas gastas na administração do banco de dados e se concentrem em obter o valor real de seus dados. Se sua equipe está enfrentando dificuldades com a manutenção do Iceberg ou se você deseja construir do zero uma casa de lago de alto desempenho e economia, o S3 Tables deve estar no topo de sua lista de avaliação.
Quer modernizar sua pilha de dados? No Marvik.ai, ajudamos as equipes a arquitetar e implementar soluções de dados escaláveis e preparadas para o futuro. Entre em contato para ver como podemos ajudar a aproveitar o S3 Tables e o Apache Iceberg para seus casos de uso específicos.
Fontes
- Trabalhando com tabelas e baldes de mesa do Amazon S3 - Amazon Simple Storage Service
- Iceberg Apache
- Lagos de dados modernos — Orientação prescritiva da AWS
- Amazon S3 Tables versus Apache Iceberg autogerenciado no S3: uma introdução técnica para startups | AWS Builder Center
- Baldes de mesa - Amazon Simple Storage Service
- Acessando dados de tabelas - Amazon Simple Storage Service
- Visão geral da integração das tabelas do Amazon S3 com os serviços de análise da AWS
- Integração das tabelas do Amazon S3 com os serviços de análise da AWS
- Acessando tabelas usando o endpoint REST Amazon S3 Tables Iceberg - Amazon Simple Storage Service
- Trabalhando com tabelas Iceberg usando PyIceberg — Orientação prescritiva da AWS
- Quando devo usar o Athena? - Atena da Amazônia





.png)