As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Melhores práticas para otimizar as cargas de trabalho do Apache Iceberg O Iceberg é um formato de tabela projetado para simplificar o gerenciamento de data lake e aprimorar o desempenho da carga de trabalho. Casos de uso diferentes podem priorizar aspectos diferentes, como custo, desempenho de leitura, desempenho de gravação ou retenção de dados, então o Iceberg oferece opções de configuração para gerenciar essas compensações. Esta seção fornece informações para otimizar e ajustar suas cargas de trabalho do Iceberg para atender às suas necessidades. **Topics** + [ # Práticas recomendadas gerais ](best-practices-general.md) + [ # Otimizando o desempenho de leitura ](best-practices-read.md) + [ # Otimizando o desempenho de gravação ](best-practices-write.md) + [ # Otimizando o armazenamento ](best-practices-storage.md) + [ # Manutenção de tabelas usando compactação ](best-practices-compaction.md) + [ # Usando cargas de trabalho do Iceberg no Amazon S3 ](best-practices-workloads.md) # Práticas recomendadas gerais Independentemente do seu caso de uso, ao usar o Apache Iceberg on AWS, recomendamos que você siga essas melhores práticas gerais. + **Use a versão 2 do formato Iceberg.** Athena usa o formato Iceberg versão 2 por padrão. [Ao usar o Spark no Amazon EMR AWS Glue ou para criar tabelas do Iceberg, especifique a versão do formato conforme descrito na documentação do Iceberg.](https://iceberg.apache.org/docs/nightly/configuration/#reserved-table-properties) + **Use o AWS Glue Data Catalog como seu catálogo de dados.** Athena usa o. AWS Glue Data Catalog por padrão. Ao usar o Spark no Amazon EMR AWS Glue ou para trabalhar com o Iceberg, adicione a seguinte configuração à sua sessão do Spark para usar o. AWS Glue Data Catalog Para obter mais informações, consulte a seção [Configurações do Spark para o Iceberg no AWS Glue](iceberg-glue.md#glue-spark-config) início deste guia. ``` "spark.sql.catalog..type": "glue" ``` + **Use o AWS Glue Data Catalog como gerenciador de bloqueio.** O Athena usa o AWS Glue Data Catalog como gerenciador de bloqueio por padrão para tabelas Iceberg. Ao usar o Spark no Amazon EMR AWS Glue ou para trabalhar com o Iceberg, certifique-se de configurar sua sessão do Spark para AWS Glue Data Catalog usá-la como gerenciador de bloqueio. Para obter mais informações, consulte [Optimistic Locking na documentação](https://iceberg.apache.org/docs/latest/aws/#optimistic-locking) do Iceberg. + **Use a compressão Zstandard (ZSTD).** O codec de compactação padrão do Iceberg é o gzip, que pode ser modificado usando a propriedade table. `write..compression-codec` O Athena já usa o ZSTD como codec de compactação padrão para tabelas Iceberg. Em geral, recomendamos o uso do codec de compactação ZSTD porque ele equilibra o GZIP e o Snappy e oferece bom read/write desempenho sem comprometer a taxa de compactação. Além disso, os níveis de compressão podem ser ajustados para atender às suas necessidades. Para obter mais informações, consulte [Níveis de compressão ZSTD no Athena na documentação do Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-support-zstd-levels.html). O Snappy pode fornecer o melhor desempenho geral de leitura e gravação, mas tem uma taxa de compactação menor do que GZIP e ZSTD. Se você priorizar o desempenho, mesmo que isso signifique armazenar grandes volumes de dados no Amazon S3, o Snappy pode ser a melhor escolha. # Otimizando o desempenho de leitura Esta seção discute as propriedades da tabela que você pode ajustar para otimizar o desempenho de leitura, independentemente do mecanismo. ## Particionamento Assim como nas tabelas do Hive, o Iceberg usa partições como camada primária de indexação para evitar a leitura de arquivos de metadados e arquivos de dados desnecessários. As estatísticas das colunas também são consideradas como uma camada secundária de indexação para melhorar ainda mais o planejamento de consultas, o que leva a um melhor tempo geral de execução. ### Particionar dados Para reduzir a quantidade de dados que são digitalizados ao consultar tabelas do Iceberg, escolha uma estratégia de partição balanceada que se alinhe aos padrões de leitura esperados: + Identifique as colunas que são usadas com frequência em consultas. Esses são candidatos ideais para particionamento. Por exemplo, se você normalmente consulta dados de um determinado dia, um exemplo natural de uma coluna de partição seria uma coluna de data. + Escolha uma coluna de partição de baixa cardinalidade para evitar criar um número excessivo de partições. Muitas partições podem aumentar o número de arquivos na tabela, o que pode afetar negativamente o desempenho da consulta. Como regra geral, “muitas partições” podem ser definidas como um cenário em que o tamanho dos dados na maioria das partições é menor que 2 a 5 vezes o valor definido por. `target-file-size-bytes` **nota** Se você costuma consultar usando filtros em uma coluna de alta cardinalidade (por exemplo, uma `id` coluna que pode ter milhares de valores), use o recurso de particionamento oculto do Iceberg com transformações de bucket, conforme explicado na próxima seção. ### Use particionamento oculto Se suas consultas geralmente são filtradas por um derivado de uma coluna de tabela, use partições ocultas em vez de criar explicitamente novas colunas para funcionarem como partições. Para obter mais informações sobre esse recurso, consulte a [documentação do Iceberg](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning). Por exemplo, em um conjunto de dados que tem uma coluna de carimbo de data/hora (por exemplo,`2023-01-01 09:00:00`), em vez de criar uma nova coluna com a data analisada (por exemplo,`2023-01-01`), use transformações de partição para extrair a parte da data do carimbo de data/hora e criar essas partições rapidamente. Os casos de uso mais comuns para particionamento oculto são: + **Particionamento em data ou hora**, quando os dados têm uma coluna de carimbo de data/hora. O Iceberg oferece várias transformações para extrair as partes de data ou hora de um carimbo de data/hora. + **Particionamento em uma função hash de uma coluna, quando a coluna** de particionamento tem alta cardinalidade e resultaria em muitas partições. O bucket do Iceberg transforma grupos de vários valores de partição em menos partições ocultas (bucket) usando funções de hash na coluna de particionamento. Consulte as [transformações de partição](https://iceberg.apache.org/spec/#partition-transforms) na documentação do Iceberg para obter uma visão geral de todas as transformações de partição disponíveis. As colunas usadas para particionamento oculto podem se tornar parte dos predicados de consulta por meio do uso de funções SQL regulares, como e. `year()` `month()` Os predicados também podem ser combinados com operadores como `BETWEEN` e. `AND` **nota** O Iceberg não pode realizar a remoção de partições para funções que geram um tipo de dados diferente; por exemplo,. `substring(event_time, 1, 10) = '2022-01-01'` ### Use a evolução da partição Use a [evolução de partições do Iceberg](https://iceberg.apache.org/docs/latest/evolution/#partition-evolution) quando a estratégia de partição existente não for a ideal. Por exemplo, se você escolher partições horárias que acabem sendo muito pequenas (apenas alguns megabytes cada), considere mudar para partições diárias ou mensais. Você pode usar essa abordagem quando a melhor estratégia de particionamento para uma tabela inicialmente não está clara e você deseja refinar sua estratégia de particionamento à medida que obtém mais informações. Outro uso efetivo da evolução de partições é quando os volumes de dados mudam e a estratégia atual de particionamento se torna menos eficaz com o tempo. Para obter instruções sobre como desenvolver partições, consulte as [extensões ALTER TABLE SQL](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) na documentação do Iceberg.  ## Ajustando tamanhos de arquivos A otimização do desempenho da consulta envolve minimizar o número de arquivos pequenos em suas tabelas. Para um bom desempenho de consulta, geralmente recomendamos manter os arquivos Parquet e ORC maiores que 100 MB. O tamanho do arquivo também afeta o planejamento de consultas para tabelas Iceberg. À medida que o número de arquivos em uma tabela aumenta, também aumenta o tamanho dos arquivos de metadados. Arquivos de metadados maiores podem resultar em um planejamento de consultas mais lento. Portanto, quando o tamanho da tabela aumentar*,* aumente o tamanho do arquivo**** para aliviar a expansão exponencial dos metadados. Use as práticas recomendadas a seguir para criar arquivos de tamanho adequado nas tabelas do Iceberg. ### Defina o tamanho do arquivo de destino e do grupo de linhas O Iceberg oferece os seguintes parâmetros-chave de configuração para ajustar o layout do arquivo de dados. Recomendamos que você use esses parâmetros para definir o tamanho do arquivo de destino e o grupo de linhas ou tamanho do traçado. | **Parâmetro** | **Valor padrão** | **Comentário** | | --- |--- |--- | | `write.target-file-size-bytes` | 512 MB | Esse parâmetro especifica o tamanho máximo do arquivo que o Iceberg criará. No entanto, alguns arquivos podem ser gravados com um tamanho menor que esse limite. | | `write.parquet.row-group-size-bytes` | 128 MB | Tanto o Parquet quanto o ORC armazenam dados em partes para que os mecanismos possam evitar a leitura do arquivo inteiro em algumas operações. | | `write.orc.stripe-size-bytes` | 64 MB | | `write.distribution-mode` | Nenhum, para a versão 1.1 e inferior do IcebergHash, começando com a versão 1.2 do Iceberg | O Iceberg solicita que o Spark classifique os dados entre suas tarefas antes de gravar no armazenamento. | + Com base no tamanho esperado da tabela, siga estas diretrizes gerais: + **Tabelas pequenas** (até alguns gigabytes) — Reduza o tamanho do arquivo de destino para 128 MB. Reduza também o tamanho do grupo de linhas ou da faixa (por exemplo, para 8 ou 16 MB). + **Tabelas de médio a grande porte** (de alguns gigabytes a centenas de gigabytes) — Os valores padrão são um bom ponto de partida para essas tabelas. Se suas consultas forem muito seletivas, ajuste o grupo de linhas ou o tamanho da faixa (por exemplo, para 16 MB). + **Tabelas muito grandes** (centenas de gigabytes ou terabytes) — Aumente o tamanho do arquivo de destino para 1024 MB ou mais e considere aumentar o tamanho do grupo de linhas ou da faixa se suas consultas geralmente extraírem grandes conjuntos de dados. + Para garantir que os aplicativos Spark que gravam nas tabelas do Iceberg criem arquivos de tamanho adequado, defina a `write.distribution-mode` propriedade como ou. `hash` `range` Para obter uma explicação detalhada da diferença entre esses modos, consulte [Escrevendo modos de distribuição](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) na documentação do Iceberg. Essas são diretrizes gerais. Recomendamos que você execute testes para identificar os valores mais adequados para suas tabelas e cargas de trabalho específicas. ### Execute a compactação regular As configurações na tabela anterior definem um tamanho máximo de arquivo que as tarefas de gravação podem criar, mas não garantem que os arquivos tenham esse tamanho. Para garantir tamanhos de arquivo adequados, execute a compactação regularmente para combinar arquivos pequenos em arquivos maiores. Para obter orientação detalhada sobre como executar a compactação, consulte a [compactação Iceberg](best-practices-compaction.md) mais adiante neste guia. ## Otimize as estatísticas da coluna O Iceberg usa estatísticas de colunas para realizar a remoção de arquivos, o que melhora o desempenho das consultas ao reduzir a quantidade de dados que são digitalizados pelas consultas. Para se beneficiar das estatísticas de colunas, certifique-se de que o Iceberg colete estatísticas de todas as colunas que são usadas com frequência em filtros de consulta. Por padrão, o Iceberg coleta estatísticas somente para as [primeiras 100 colunas em cada tabela](https://github.com/apache/iceberg/blob/ae15c7e36973501b40443e75816d3eac39eddc90/core/src/main/java/org/apache/iceberg/TableProperties.java#L276), conforme definido pela propriedade da tabela. `write.metadata.metrics.max-inferred-column-defaults` Se sua tabela tiver mais de 100 colunas e suas consultas frequentemente referenciarem colunas fora das primeiras 100 colunas (por exemplo, você pode ter consultas que filtram na coluna 132), certifique-se de que o Iceberg colete estatísticas sobre essas colunas. Há duas opções para conseguir isso: + Ao criar a tabela Iceberg, reordene as colunas para que as colunas necessárias para consultas estejam dentro do intervalo de colunas definido por `write.metadata.metrics.max-inferred-column-defaults` (o padrão é 100). Observação: se você não precisar de estatísticas em 100 colunas, poderá ajustar a `write.metadata.metrics.max-inferred-column-defaults` configuração para um valor desejado (por exemplo, 20) e reordenar as colunas para que as colunas necessárias para ler e escrever consultas caiam nas primeiras 20 colunas no lado esquerdo do conjunto de dados. + Se você usar apenas algumas colunas nos filtros de consulta, poderá desativar a propriedade geral da coleta de métricas e escolher seletivamente colunas individuais para as quais coletar estatísticas, conforme mostrado neste exemplo: ``` .tableProperty("write.metadata.metrics.default", "none") .tableProperty("write.metadata.metrics.column.my_col_a", "full") .tableProperty("write.metadata.metrics.column.my_col_b", "full") ``` Observação: as estatísticas das colunas são mais eficazes quando os dados são classificados nessas colunas. Para obter mais informações, consulte a seção [Definir a ordem de classificação](#read-sort-order) mais adiante neste guia. ## Escolha a estratégia de atualização correta Use uma copy-on-write estratégia para otimizar o desempenho de leitura, quando operações de gravação mais lentas forem aceitáveis para seu caso de uso. Essa é a estratégia padrão usada pelo Iceberg. Copy-on-write resulta em melhor desempenho de leitura, porque os arquivos são gravados diretamente no armazenamento de forma otimizada para leitura. No entanto, em comparação com merge-on-read, cada operação de gravação leva mais tempo e consome mais recursos computacionais. Isso apresenta uma compensação clássica entre latência de leitura e gravação. Normalmente, copy-on-write é ideal para casos de uso em que a maioria das atualizações é colocada nas mesmas partições de tabela (por exemplo, para cargas diárias em lote). Copy-on-write as configurações (`write.update.mode`,`write.delete.mode`, e`write.merge.mode`) podem ser definidas no nível da tabela ou de forma independente no lado do aplicativo. ## Use compressão ZSTD Você pode modificar o codec de compactação usado pelo Iceberg usando a propriedade table. `write..compression-codec` Recomendamos que você use o codec de compressão ZSTD para melhorar o desempenho geral nas tabelas. Por padrão, as versões 1.3 e anteriores do Iceberg usam a compressão GZIP, que fornece um read/write desempenho mais lento em comparação com o ZSTD. Observação: alguns mecanismos podem usar valores padrão diferentes. Esse é o caso das [tabelas Iceberg criadas com o Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-support-iceberg.html) ou o Amazon EMR versão 7.x. ## Definir a ordem de classificação Para melhorar o desempenho de leitura nas tabelas do Iceberg, recomendamos que você classifique sua tabela com base em uma ou mais colunas usadas com frequência em filtros de consulta. A classificação, combinada com as estatísticas das colunas do Iceberg, pode tornar a remoção de arquivos significativamente mais eficiente, o que resulta em operações de leitura mais rápidas. A classificação também reduz o número de solicitações do Amazon S3 para consultas que usam as colunas de classificação nos filtros de consulta. Você pode definir uma ordem de classificação hierárquica no nível da tabela executando uma instrução de linguagem de definição de dados (DDL) com o Spark. Para ver as opções disponíveis, consulte a [documentação do Iceberg](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table--write-ordered-by). Depois de definir a ordem de classificação, os gravadores aplicarão essa classificação às operações subsequentes de gravação de dados na tabela Iceberg. Por exemplo, em tabelas particionadas por date (`yyyy-mm-dd`) em que a maioria das consultas é filtrada`uuid`, você pode usar a opção DDL `Write Distributed By Partition Locally Ordered` para garantir que o Spark grave arquivos com intervalos não sobrepostos. O diagrama a seguir ilustra como a eficiência das estatísticas de coluna melhora quando as tabelas são classificadas. No exemplo, a tabela classificada precisa abrir apenas um único arquivo e se beneficia ao máximo da partição e do arquivo do Iceberg. Na tabela não classificada, qualquer um `uuid` pode existir potencialmente em qualquer arquivo de dados, portanto, a consulta precisa abrir todos os arquivos de dados. ![\[Definindo a ordem de classificação nas tabelas Iceberg\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/apache-iceberg-on-aws/images/setting-sort-order.png) A alteração da ordem de classificação não afeta os arquivos de dados existentes. Você pode usar a compactação Iceberg para aplicar a ordem de classificação a eles. Usar as tabelas classificadas do Iceberg pode diminuir os custos de sua carga de trabalho, conforme ilustrado no gráfico a seguir. ![\[Custos de comparação para mesas Iceberg e Parquet\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cost-graph.png) Esses gráficos resumem os resultados da execução do benchmark TPC-H para tabelas Hive (Parquet) em comparação com as tabelas classificadas do Iceberg. No entanto, os resultados podem ser diferentes para outros conjuntos de dados ou cargas de trabalho. ![\[Resultados do benchmark TPC-H para mesas Parquet versus Iceberg\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/apache-iceberg-on-aws/images/s3-api-calls.png) # Otimizando o desempenho de gravação Esta seção discute as propriedades da tabela que você pode ajustar para otimizar o desempenho de gravação nas tabelas do Iceberg, independentemente do mecanismo. ## Definir o modo de distribuição da tabela O Iceberg oferece vários modos de distribuição de gravação que definem como os dados de gravação são distribuídos nas tarefas do Spark. Para uma visão geral dos modos disponíveis, consulte [Escrevendo modos de distribuição](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) na documentação do Iceberg. Para casos de uso que priorizam a velocidade de gravação, especialmente em cargas de trabalho de streaming, defina como. `write.distribution-mode` `none` Isso garante que o Iceberg não solicite embaralhamento adicional do Spark e que os dados sejam gravados assim que forem disponibilizados nas tarefas do Spark. Esse modo é particularmente adequado para aplicativos Spark Structured Streaming. **nota** Definir o modo de distribuição de gravação como `none` tende a produzir vários arquivos pequenos, o que degrada o desempenho de leitura. Recomendamos a compactação regular para consolidar esses arquivos pequenos em arquivos de tamanho adequado para o desempenho da consulta. ## Escolha a estratégia de atualização correta Use uma merge-on-read**** estratégia para otimizar o desempenho de gravação, quando operações de leitura mais lentas nos dados mais recentes forem aceitáveis para seu caso de uso. Quando você usa merge-on-read, o Iceberg grava atualizações e exclui no armazenamento como pequenos arquivos separados. Quando a tabela é lida, o leitor precisa mesclar essas alterações com os arquivos base para retornar a visão mais recente dos dados. Isso resulta em uma penalidade de desempenho nas operações de leitura, mas acelera a gravação de atualizações e exclusões. Normalmente, merge-on-read é ideal para streaming de cargas de trabalho com atualizações ou trabalhos com poucas atualizações espalhadas por várias partições de tabela. Você pode definir merge-on-read as configurações (`write.update.mode``write.delete.mode`, e`write.merge.mode`) no nível da tabela ou de forma independente no lado do aplicativo. O uso merge-on-read requer a execução de compactação regular para evitar que o desempenho de leitura se degrade com o tempo. A compactação reconcilia atualizações e exclusões com arquivos de dados existentes para criar um novo conjunto de arquivos de dados, eliminando assim a penalidade de desempenho incorrida no lado da leitura. Por padrão, a compactação do Iceberg não mescla arquivos excluídos, a menos que você altere o padrão da `delete-file-threshold` propriedade para um valor menor (consulte a documentação do [Iceberg](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files)). Para saber mais sobre compactação, consulte a seção Compactação do [Iceberg](best-practices-compaction.md) mais adiante neste guia. ## Escolha o formato de arquivo correto O Iceberg suporta a gravação de dados nos formatos Parquet, ORC e Avro. O parquet é o formato padrão. Parquet e ORC são formatos colunares que oferecem desempenho de leitura superior, mas geralmente são mais lentos para gravar. Isso representa a compensação típica entre desempenho de leitura e gravação. Se a velocidade de gravação for importante para seu caso de uso, como em cargas de trabalho de streaming, considere escrever no formato Avro `write-format` configurando como `Avro` nas opções do gravador. Como o Avro é um formato baseado em linhas, ele fornece tempos de gravação mais rápidos ao custo de um desempenho de leitura mais lento. Para melhorar o desempenho de leitura, execute a compactação regular para mesclar e transformar pequenos arquivos Avro em arquivos Parquet maiores. O resultado do processo de compactação é determinado pela configuração da `write.format.default` tabela. O formato padrão do Iceberg é o Parquet, então se você escrever em Avro e depois executar a compactação, o Iceberg transformará os arquivos Avro em arquivos Parquet. Veja um exemplo abaixo: ``` spark.sql(f""" CREATE TABLE IF NOT EXISTS glue_catalog.{DB_NAME}.{TABLE_NAME} ( Col_1 float, <<<…other columns…>> ts timestamp) USING iceberg PARTITIONED BY (days(ts)) OPTIONS ( 'format-version'='2', write.format.default'=parquet) """) query = df \ .writeStream \ .format("iceberg") \ .option("write-format", "avro") \ .outputMode("append") \ .trigger(processingTime='60 seconds') \ .option("path", f"glue_catalog.{DB_NAME}.{TABLE_NAME}") \ .option("checkpointLocation", f"s3://{BUCKET_NAME}/checkpoints/iceberg/") .start() ``` # Otimizando o armazenamento Atualizar ou excluir dados em uma tabela Iceberg aumenta o número de cópias de seus dados, conforme ilustrado no diagrama a seguir. O mesmo vale para a execução da compactação: ela aumenta o número de cópias de dados no Amazon S3. Isso porque o Iceberg trata os arquivos subjacentes a todas as tabelas como imutáveis. ![\[Resultados da atualização ou exclusão de dados em uma tabela Iceberg\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/apache-iceberg-on-aws/images/optimizing-storage.png) Siga as práticas recomendadas nesta seção para gerenciar os custos de armazenamento. ## Habilite o S3 Intelligent Tiering Use a classe de armazenamento [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html) para mover automaticamente os dados para o nível de acesso mais econômico quando os padrões de acesso mudarem. Essa opção não tem sobrecarga operacional nem impacto no desempenho.   Observação: não use os níveis opcionais (como Archive Access e Deep Archive Access) no S3 Intelligent-Tiering com tabelas Iceberg. Para arquivar dados, consulte as diretrizes na próxima seção. [Você também pode usar as regras de [ciclo de vida do Amazon S3 para definir suas próprias regras](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) para mover objetos para outra classe de armazenamento do Amazon S3, como S3 Standard-IA ou S3 One Zone-IA (consulte Transições suportadas e restrições relacionadas na documentação do Amazon S3).](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#lifecycle-general-considerations-transition-sc) ## Arquivar ou excluir instantâneos históricos Para cada transação confirmada (inserção, atualização, mesclagem, compactação) em uma tabela Iceberg, uma nova versão ou instantâneo da tabela é criada. Com o tempo, o número de versões e o número de arquivos de metadados no Amazon S3 se acumulam. É necessário manter instantâneos de uma tabela para recursos como isolamento de instantâneos, reversão de tabelas e consultas de viagem no tempo. No entanto, os custos de armazenamento aumentam com o número de versões que você retém. A tabela a seguir descreve os padrões de design que você pode implementar para gerenciar custos com base em seus requisitos de retenção de dados. | **Padrão de design** | **Solução** | **Casos de uso** | | --- |--- |--- | | **Excluir instantâneos antigos** | Use a [instrução VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) no Athena para remover instantâneos antigos. Essa operação não incorre em nenhum custo computacional. [Como alternativa, você pode usar o Spark no Amazon EMR AWS Glue ou remover instantâneos. Para obter mais informações, consulte expire\$1snapshots na documentação do Iceberg.](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) | Essa abordagem exclui instantâneos que não são mais necessários para reduzir os custos de armazenamento. Você pode configurar quantos instantâneos devem ser retidos ou por quanto tempo, com base em seus requisitos de retenção de dados.Essa opção executa uma exclusão definitiva dos instantâneos. Você não pode reverter ou viajar no tempo para instantâneos expirados. | | **Defina políticas de retenção para instantâneos específicos** | Use tags para marcar instantâneos específicos e definir uma política de retenção no Iceberg. Para obter mais informações, consulte [Tags históricas](https://iceberg.apache.org/docs/latest/branching/#historical-tags) na documentação do Iceberg. Por exemplo, você pode reter um snapshot por mês durante um ano usando a seguinte instrução SQL no Spark no Amazon EMR: 
ALTER TABLE glue_catalog.db.table 
CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS
Use o Spark no Amazon EMR AWS Glue ou remova os demais snapshots intermediários não marcados. | Esse padrão é útil para a conformidade com requisitos comerciais ou legais que exigem que você mostre o estado de uma tabela em um determinado momento no passado. Ao colocar políticas de retenção em instantâneos marcados específicos, você pode remover outros instantâneos (não marcados) que foram criados. Dessa forma, você pode atender aos requisitos de retenção de dados sem reter cada snapshot criado. | | **Arquive instantâneos antigos** | Use as tags do Amazon S3 para marcar objetos com o Spark. (As tags do Amazon S3 são diferentes das tags Iceberg; para obter mais informações, consulte a documentação do [Iceberg](https://iceberg.apache.org/docs/latest/aws/#s3-tags).) Por exemplo: 
spark.sql.catalog.my_catalog.s3.delete-enabled=false and \
spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive
Use o Spark no Amazon EMR AWS Glue ou [para](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) remover instantâneos. Quando você usa as configurações no exemplo, esse procedimento marca objetos e os separa dos metadados da tabela Iceberg em vez de excluí-los do Amazon S3. Use as regras de ciclo de vida do S3 para fazer a transição de objetos marcados como `to_archive` uma das classes de armazenamento do [S3 Glacier.](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) Para consultar dados arquivados: [Restaure os objetos arquivados](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html) (essa etapa não é necessária se os objetos tiverem sido transferidos para a classe de armazenamento Amazon Glacier Instant Retrieval). Use o [procedimento register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) no Iceberg para registrar o instantâneo como uma tabela no catálogo. Para obter instruções detalhadas, consulte a postagem do AWS blog [Melhore a eficiência operacional das tabelas Apache Iceberg criadas nos data lakes do Amazon S3](https://aws.amazon.com/blogs/big-data/improve-operational-efficiencies-of-apache-iceberg-tables-built-on-amazon-s3-data-lakes/).  | Esse padrão permite que você mantenha todas as versões e instantâneos da tabela a um custo menor.Você não pode viajar no tempo ou reverter para instantâneos arquivados sem primeiro restaurar essas versões como novas tabelas. Isso geralmente é aceitável para fins de auditoria.Você pode combinar essa abordagem com o padrão de design anterior, definindo políticas de retenção para instantâneos específicos. | ## Excluir arquivos órfãos Em determinadas situações, os aplicativos do Iceberg podem falhar antes que você confirme suas transações. Isso deixa os arquivos de dados no Amazon S3. Como não houve confirmação, esses arquivos não serão associados a nenhuma tabela, então talvez seja necessário limpá-los de forma assíncrona. Para lidar com essas exclusões, você pode usar a [instrução VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) no Amazon Athena. Essa instrução remove instantâneos e também exclui arquivos órfãos. Isso é muito econômico, porque o Athena não cobra pelo custo computacional dessa operação. Além disso, você não precisa agendar nenhuma operação adicional ao usar a `VACUUM` instrução. Como alternativa, você pode usar o Spark no Amazon EMR AWS Glue ou executar `remove_orphan_files` o procedimento. Essa operação tem um custo computacional e precisa ser programada de forma independente. Para obter mais informações, consulte a [documentação do Iceberg](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files). # Manutenção de tabelas usando compactação O Iceberg inclui recursos que permitem realizar [operações de manutenção da tabela](https://iceberg.apache.org/docs/latest/maintenance/) depois de gravar dados na tabela. Algumas operações de manutenção se concentram na simplificação dos arquivos de metadados, enquanto outras aprimoram a forma como os dados são agrupados nos arquivos para que os mecanismos de consulta possam localizar com eficiência as informações necessárias para responder às solicitações do usuário. Esta seção se concentra nas otimizações relacionadas à compactação. ## Compactação de iceberg No Iceberg, você pode usar a compactação para realizar quatro tarefas: + Combinação de arquivos pequenos em arquivos maiores que geralmente têm mais de 100 MB. Essa técnica é conhecida como *embalagem de lixo*. + Mesclando arquivos excluídos com arquivos de dados. Os arquivos excluídos são gerados por atualizações ou exclusões que usam a merge-on-read abordagem. + (Re) classificando os dados de acordo com os padrões de consulta. Os dados podem ser gravados sem qualquer ordem de classificação ou com uma ordem de classificação adequada para gravações e atualizações. + Agrupar os dados usando curvas de preenchimento de espaço para otimizar padrões de consulta distintos, particularmente a classificação de ordem z. Ativado AWS, você pode executar operações de compactação e manutenção de tabelas para o Iceberg por meio do Amazon Athena ou usando o Spark no Amazon EMR ou. AWS Glue Ao executar a compactação usando o procedimento [rewrite\$1data\$1files](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files), você pode ajustar vários botões para controlar o comportamento da compactação. O diagrama a seguir mostra o comportamento padrão do empacotamento de lixo. Compreender a compactação de compartimentos é fundamental para entender as implementações de classificação hierárquica e classificação de ordem Z, porque elas são extensões da interface de embalagem de compartimentos e operam de maneira semelhante. A principal distinção é a etapa adicional necessária para classificar ou agrupar os dados. ![\[Comportamento padrão de embalagem de compartimentos em tabelas Iceberg\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/apache-iceberg-on-aws/images/compaction.png) Neste exemplo, a tabela Iceberg consiste em quatro partições. Cada partição tem um tamanho diferente e um número diferente de arquivos. Se você iniciar um aplicativo Spark para executar a compactação, o aplicativo criará um total de quatro grupos de arquivos para processar. Um grupo de arquivos é uma abstração do Iceberg que representa uma coleção de arquivos que serão processados por uma única tarefa do Spark. Ou seja, o aplicativo Spark que executa a compactação criará quatro trabalhos do Spark para processar os dados. ## Ajustando o comportamento de compactação As propriedades principais a seguir controlam como os arquivos de dados são selecionados para compactação: + [MAX\$1FILE\$1GROUP\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_FILE_GROUP_SIZE_BYTES) define o limite de dados para um único grupo de arquivos (tarefa do Spark) em 100 GB por padrão. Essa propriedade é especialmente importante para tabelas sem partições ou tabelas com partições que abrangem centenas de gigabytes. Ao definir esse limite, você pode dividir as operações para planejar o trabalho e progredir, evitando o esgotamento dos recursos no cluster. Nota: Cada grupo de arquivos é classificado separadamente. Portanto, se você quiser realizar uma classificação em nível de partição, deverá ajustar esse limite para corresponder ao tamanho da partição. + [MIN\$1FILE\$1SIZE\$1BYTES ou MIN\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_BYTES) [assumem como padrão 75 por cento do tamanho do arquivo de destino](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_DEFAULT_RATIO) definido no nível da tabela. Por exemplo, se uma tabela tiver um tamanho alvo de 512 MB, qualquer arquivo menor que 384 MB será incluído no conjunto de arquivos que serão compactados. + [MAX\$1FILE\$1SIZE\$1BYTES ou MAX\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_BYTES) [assumem como padrão 180 por cento do tamanho do arquivo de destino](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_DEFAULT_RATIO). Assim como as duas propriedades que definem tamanhos mínimos de arquivo, essas propriedades são usadas para identificar arquivos candidatos para o trabalho de compactação. + [MIN\$1INPUT\$1FILES especifica o número mínimo de arquivos](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_INPUT_FILES) a serem compactados se o tamanho da partição da tabela for menor que o tamanho do arquivo de destino. O valor dessa propriedade é usado para determinar se vale a pena compactar os arquivos com base no número de arquivos (o padrão é 5). + [DELETE\$1FILE\$1THRESHOLD](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#DELETE_FILE_THRESHOLD) especifica o número mínimo de operações de exclusão de um arquivo antes de ser incluído na compactação. A menos que você especifique o contrário, a compactação não combina arquivos excluídos com arquivos de dados. Para habilitar essa funcionalidade, você deve definir um valor limite usando essa propriedade. Esse limite é específico para arquivos de dados individuais, portanto, se você defini-lo como 3, um arquivo de dados será regravado somente se houver três ou mais arquivos de exclusão que façam referência a ele. Essas propriedades fornecem informações sobre a formação dos grupos de arquivos no diagrama anterior. Por exemplo, a partição rotulada `month=01` inclui dois grupos de arquivos porque excede a restrição de tamanho máximo de 100 GB. Por outro lado, a `month=02` partição contém um único grupo de arquivos porque tem menos de 100 GB. A `month=03` partição não atende ao requisito mínimo padrão de arquivo de entrada de cinco arquivos. Como resultado, ele não será compactado. Por fim, embora a `month=04` partição não contenha dados suficientes para formar um único arquivo do tamanho desejado, os arquivos serão compactados porque a partição inclui mais de cinco arquivos pequenos. Você pode definir esses parâmetros para o Spark executado no Amazon AWS Glue EMR ou. Para o Amazon Athena, você pode gerenciar propriedades semelhantes usando as propriedades da [tabela](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties) (que começam com o prefixo`optimize_`). ## Executando a compactação com o Spark no Amazon EMR ou AWS Glue Esta seção descreve como dimensionar adequadamente um cluster Spark para executar o utilitário de compactação do Iceberg. O exemplo a seguir usa o Amazon EMR Serverless, mas você pode usar a mesma metodologia no Amazon EMR no EC2 ou EKS, ou no. AWS Glue Você pode aproveitar a correlação entre grupos de arquivos e trabalhos do Spark para planejar os recursos do cluster. Para processar os grupos de arquivos sequencialmente, considerando o tamanho máximo de 100 GB por grupo de arquivos, você pode definir as seguintes propriedades do [Spark](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults): + `spark.dynamicAllocation.enabled` = `FALSE` + `spark.executor.memory` = `20 GB` + `spark.executor.instances` = `5` Se quiser acelerar a compactação, você pode escalar horizontalmente aumentando o número de grupos de arquivos que são compactados em paralelo. Você também pode escalar o Amazon EMR usando escalabilidade manual ou dinâmica. + **Dimensionamento manual** (por exemplo, por um fator de 4) + `MAX_CONCURRENT_FILE_GROUP_REWRITES`= `4` (nosso fator) + `spark.executor.instances`= `5` (valor usado no exemplo) x `4` (nosso fator) = `20` + `spark.dynamicAllocation.enabled` = `FALSE` + **Dimensionamento dinâmico** + `spark.dynamicAllocation.enabled`= `TRUE ` (padrão, nenhuma ação é necessária) + [MAX\$1CONCURRENT\$1FILE\$1GROUP\$1REWRITES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_CONCURRENT_FILE_GROUP_REWRITES) = `N ` (alinhe esse valor com`spark.dynamicAllocation.maxExecutors`, que é 100 por padrão; com base nas configurações do executor no exemplo, você pode definir como 20) `N` Essas são diretrizes para ajudar a dimensionar o cluster. No entanto, você também deve monitorar o desempenho de suas tarefas do Spark para encontrar as melhores configurações para suas cargas de trabalho. ## Executando a compactação com o Amazon Athena [O Athena oferece uma implementação do utilitário de compactação do Iceberg como um recurso gerenciado por meio da declaração OPTIMIZE.](https://docs.aws.amazon.com/athena/latest/ug/optimize-statement.html) Você pode usar essa instrução para executar a compactação sem precisar avaliar a infraestrutura. Essa instrução agrupa arquivos pequenos em arquivos maiores usando o algoritmo de empacotamento de compartimentos e mescla arquivos excluídos com arquivos de dados existentes. Para agrupar os dados usando classificação hierárquica ou classificação de ordem z, use o Spark no Amazon EMR ou. AWS Glue Você pode alterar o comportamento padrão da `OPTIMIZE` instrução na criação da tabela passando as propriedades da tabela na `CREATE TABLE` instrução ou após a criação da tabela usando a `ALTER TABLE` instrução. Para valores padrão, consulte a documentação do [Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties). ## Recomendações para executar a compactação | **Caso de uso** | **Recomendação** | | --- |--- | | **Executando a compactação da embalagem de lixeiras com base em um cronograma** | Use a `OPTIMIZE` declaração no Athena se você não souber quantos arquivos pequenos sua tabela contém. O modelo de preços do Athena é baseado nos dados digitalizados, portanto, se não houver arquivos a serem compactados, não haverá custo associado a essas operações. Para evitar o tempo limite nas tabelas do Athena, execute `OPTIMIZE` com base. per-table-partition Use o Amazon EMR ou AWS Glue com escalabilidade dinâmica quando você espera que grandes volumes de arquivos pequenos sejam compactados. | | **Executando a compactação de embalagens de lixo com base em eventos** | Use o Amazon EMR ou AWS Glue com escalabilidade dinâmica quando você espera que grandes volumes de arquivos pequenos sejam compactados. | | **Executando a compactação para classificar dados** | Use o Amazon EMR ou AWS Glue, porque a classificação é uma operação cara e pode precisar transferir dados para o disco. | | **Executando a compactação para agrupar os dados usando a classificação de ordem z** | Use o Amazon EMR ou AWS Glue, porque a classificação por ordem z é uma operação muito cara e pode precisar transferir dados para o disco. | | **Executando a compactação em partições que podem ser atualizadas por outros aplicativos devido à chegada tardia de dados** | Use o Amazon EMR ou. AWS Glue Ative a propriedade Iceberg [PARTIAL\$1PROGRESS\$1ENABLED](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#PARTIAL_PROGRESS_ENABLED). Quando você usa essa opção, o Iceberg divide a saída de compactação em vários commits. Se houver uma colisão (ou seja, se o arquivo de dados for atualizado durante a execução da compactação), essa configuração reduz o custo da nova tentativa, limitando-a à confirmação que inclui o arquivo afetado. Caso contrário, talvez seja necessário recompactar todos os arquivos. | | **Executando a compactação em partições frias (partições de dados que não recebem mais gravações ativas)** | Use o Amazon EMR ou. AWS Glue No `rewrite_data_files` procedimento, especifique um `where` predicado que exclua partições gravadas ativamente. Essa estratégia evita conflitos de dados entre gravadores e trabalhos de compactação e deixa apenas os conflitos de metadados que o Iceberg pode resolver automaticamente. | # Usando cargas de trabalho do Iceberg no Amazon S3 Esta seção discute as propriedades do Iceberg que você pode usar para otimizar a interação do Iceberg com o Amazon S3. ## Evite o particionamento a quente (erros HTTP 503) Alguns aplicativos de data lake executados no Amazon S3 manipulam milhões ou bilhões de objetos e processam petabytes de dados. Isso pode levar a prefixos que recebem um alto volume de tráfego, que normalmente são detectados por meio de erros HTTP 503 (serviço indisponível). Para evitar esse problema, use as seguintes propriedades do Iceberg: + `write.distribution-mode`Defina `hash` para `range` que o Iceberg grave arquivos grandes, o que resulta em menos solicitações do Amazon S3. Essa é a configuração preferida e deve abordar a maioria dos casos. + Se você continuar enfrentando erros 503 devido a um grande volume de dados em suas cargas de trabalho, você pode `write.object-storage.enabled` configurá-los no Iceberg. `true` Isso instrui o Iceberg a fazer o hash dos nomes dos objetos e distribuir a carga em vários prefixos aleatórios do Amazon S3. Para obter mais informações sobre essas propriedades, consulte [Write properties](https://iceberg.apache.org/docs/latest/configuration/#write-properties) na documentação do Iceberg. ## Use as operações de manutenção do Iceberg para liberar dados não utilizados Para gerenciar tabelas do Iceberg, você pode usar a API principal do Iceberg, os clientes do Iceberg (como o Spark) ou serviços gerenciados, como o Amazon Athena. [Para excluir arquivos antigos ou não utilizados do Amazon S3, recomendamos que você use somente o Iceberg APIs native [para remover instantâneos, remover](https://iceberg.apache.org/docs/latest/maintenance/#expire-snapshots)[arquivos de metadados antigos](https://iceberg.apache.org/docs/latest/maintenance/#remove-old-metadata-files) e excluir arquivos órfãos.](https://iceberg.apache.org/docs/latest/maintenance/#delete-orphan-files) Usar o Amazon S3 APIs por meio do Boto3, o Amazon S3 SDK ou o AWS Command Line Interface (AWS CLI), ou usar qualquer outro método que não seja do Iceberg para sobrescrever ou remover arquivos do Amazon S3 de uma tabela Iceberg leva à corrupção da tabela e a falhas de consulta. ## Replique dados em Regiões da AWS Ao armazenar tabelas do Iceberg no Amazon S3, você pode usar os recursos integrados no Amazon S3, [como replicação entre regiões (CRR) e pontos de acesso multirregionais (MRAP), para replicar](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) [dados em várias regiões](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html). Regiões da AWS O MRAP fornece um endpoint global para que os aplicativos acessem buckets S3 localizados em vários. Regiões da AWS O Iceberg não oferece suporte a caminhos relativos, mas você pode usar o MRAP para realizar operações do Amazon S3 mapeando buckets para pontos de acesso. O MRAP também se integra perfeitamente ao processo de replicação entre regiões do Amazon S3, o que introduz um atraso de até 15 minutos. Você precisa replicar os arquivos de dados e metadados. **Importante** Atualmente, a integração do Iceberg com o MRAP funciona somente com o Apache Spark. Se você precisar fazer o failover para o secundário Região da AWS, planeje redirecionar as consultas do usuário para um ambiente Spark SQL (como o Amazon EMR) na região de failover. Os recursos CRR e MRAP ajudam você a criar uma solução de replicação entre regiões para tabelas Iceberg, conforme ilustrado no diagrama a seguir. ![\[Replicação entre regiões para tabelas Iceberg\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cross-region-replication.png) Para configurar essa arquitetura de replicação entre regiões: 1. Crie tabelas usando a localização do MRAP. Isso garante que os arquivos de metadados do Iceberg apontem para o local do MRAP em vez do local físico do bucket. 1. Replique arquivos Iceberg usando o Amazon S3 MRAP. ****O MRAP oferece suporte à replicação de dados com um contrato de nível de serviço (SLA) de 15 minutos. O Iceberg impede que as operações de leitura introduzam inconsistências durante a replicação. 1. Disponibilize as tabelas AWS Glue Data Catalog na região secundária. Você pode escolher entre duas opções: + Configure um pipeline para replicar os metadados da tabela Iceberg usando a replicação. AWS Glue Data Catalog Esse utilitário está disponível no repositório de [replicação do GitHub Glue Catalog e do Lake Formation Permissions](https://github.com/aws-samples/lake-formation-pemissions-sync). Esse mecanismo controlado por eventos replica tabelas na região de destino com base nos registros de eventos. + Registre as tabelas na região secundária quando precisar fazer o failover. Para essa opção, você pode usar o utilitário anterior ou o [procedimento register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) do Iceberg e apontá-lo para o arquivo mais recente. `metadata.json`