Novo: melhorar o desempenho da consulta do Apache Iceberg no Amazon S3 com a Kind e a Zidra Compaction

Agora você pode usar kind e z-order compactação para melhorar Apache iceberg Efficiency de consulta em Tabelas Amazon S3 e Buckets S3 de uso geral.

Você normalmente usa iceberg para gerenciar conjuntos de dados analíticos em larga escala em Amazon Easy Storage Service (Amazon S3) com Catálogo de dados da AWS Glue ou com tabelas S3. As tabelas de iceberg suportam casos de uso, como streaming simultâneo e ingestão de lote, evolução do esquema e viagens no tempo. Ao trabalhar com conjuntos de dados de alto ou mais atualizado, os lagos de dados podem acumular muitos arquivos pequenos que afetam o custo e o desempenho de suas consultas. Você compartilhou que a otimização do format de dados do iceberg é operacionalmente complexa e geralmente exige o desenvolvimento e a manutenção de pipelines personalizados. Embora o padrão binpack Estratégia com compactação gerenciada fornece melhorias notáveis ​​de desempenho, introduzindo kind e z-order As opções de compactação para tabelas S3 e S3 oferecem ganhos ainda maiores para consultas filtradas em uma ou mais dimensões.

Duas novas estratégias de compactação: Kind e z-order
Para ajudar a organizar seus dados com mais eficiência, a Amazon S3 agora suporta duas novas estratégias de compactação: kind e z-orderalém do padrão binpack compactação. Essas estratégias avançadas estão disponíveis para mesas S3 totalmente gerenciadas e mesas de iceberg nos baldes de fins gerais S3 por meio de Otimizações do catalog de dados da AWS.

Kind A Compaction organiza arquivos com base em um pedido de coluna definido pelo usuário. Quando suas tabelas tiverem uma ordem de classificação definida, o S3 Tables Compaction agora o usará para agrupar valores semelhantes durante o processo de compactação. Isso melhora a eficiência da execução da consulta, reduzindo o número de arquivos digitalizados. Por exemplo, se sua tabela for organizada por kind compactação junto state e zip_codeconsultas que filtram nessas colunas digitalizarão menos arquivos, melhorando a latência e reduzindo o custo do motor da consulta.

Z-order A compactação vai um passo adiante, ativando a poda de arquivo eficiente em várias dimensões. Ele intercala a representação binária de valores de várias colunas em um único escalar que pode ser classificado, tornando essa estratégia particularmente útil para consultas espaciais ou multidimensionais. Por exemplo, se suas cargas de trabalho incluem consultas que filtram simultaneamente por pickup_locationAssim, dropoff_locatione fare_amountAssim, z-order A compactação pode reduzir o número complete de arquivos digitalizados em comparação com os layouts tradicionais baseados em classificação.

As tabelas S3 usam seus metadados da tabela de iceberg para determinar a ordem de classificação atual. Se uma tabela tiver uma ordem de classificação definida, nenhuma configuração adicional será necessária para ativar kind compactação – é aplicado automaticamente durante a manutenção contínua. Para usar z-ordervocê precisa atualizar a configuração de manutenção da tabela usando a API de tabelas S3 e definir a estratégia para z-order. Para mesas de iceberg em baldes de fins gerais S3, você pode configurar o catálogo de dados da AWS Glue para usar kind ou z-order Compactação durante a otimização, atualizando as configurações de compactação.

Apenas novos dados escritos após ativar kind ou z-order será afetado. Os arquivos compactados existentes permanecerão inalterados, a menos que você os reescreva explicitamente, aumentando o tamanho do arquivo de destino nas configurações de manutenção da tabela ou reescrevendo dados usando ferramentas padrão de iceberg. Esse comportamento foi projetado para fornecer controle sobre quando e quanto dados são reorganizados, equilibrando o custo e o desempenho.

Vamos ver em ação
Vou orientá -lo por um exemplo simplificado usando o Apache Spark e o Interface da linha de comando da AWS (AWS CLI). Eu tenho um cluster de faísca instalado e um balde de mesa S3. Eu tenho uma mesa chamada testtable em um testnamespace. Desativei temporariamente a compactação, o tempo para adicionar dados à tabela.

Depois de adicionar dados, verifico a estrutura do arquivo da tabela.

spark.sql("""
  SELECT 
    substring_index(file_path, '/', -1) as file_name,
    record_count,
    file_size_in_bytes,
    CAST(UNHEX(hex(lower_bounds(2))) AS STRING) as lower_bound_name,
    CAST(UNHEX(hex(upper_bounds(2))) AS STRING) as upper_bound_name
  FROM ice_catalog.testnamespace.testtable.information
  ORDER BY file_name
""").present(20, false)

+--------------------------------------------------------------+------------+------------------+----------------+----------------+
|file_name                                                     |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name|
+--------------------------------------------------------------+------------+------------------+----------------+----------------+
|00000-0-66a9c843-5a5c-407f-8da4-4da91c7f6ae2-0-00001.parquet  |1           |837               |Quinn           |Quinn           |
|00000-1-b7fa2021-7f75-4aaf-9a24-9bdbb5dc08c9-0-00001.parquet  |1           |824               |Tom             |Tom             |
|00000-10-00a96923-a8f4-41ba-a683-576490518561-0-00001.parquet |1           |838               |Ilene           |Ilene           |
|00000-104-2db9509d-245c-44d6-9055-8e97d4e44b01-0-00001.parquet|1000000     |4031668           |Anjali          |Tom             |
|00000-11-27f76097-28b2-42bc-b746-4359df83d8a1-0-00001.parquet |1           |838               |Henry           |Henry           |
|00000-114-6ff661ca-ba93-4238-8eab-7c5259c9ca08-0-00001.parquet|1000000     |4031788           |Anjali          |Tom             |
|00000-12-fd6798c0-9b5b-424f-af70-11775bf2a452-0-00001.parquet |1           |852               |Georgie         |Georgie         |
|00000-124-76090ac6-ae6b-4f4e-9284-b8a09f849360-0-00001.parquet|1000000     |4031740           |Anjali          |Tom             |
|00000-13-cb0dd5d0-4e28-47f5-9cc3-b8d2a71f5292-0-00001.parquet |1           |845               |Olivia          |Olivia          |
|00000-134-bf6ea649-7a0b-4833-8448-60faa5ebfdcd-0-00001.parquet|1000000     |4031718           |Anjali          |Tom             |
|00000-14-c7a02039-fc93-42e3-87b4-2dd5676d5b09-0-00001.parquet |1           |838               |Sarah           |Sarah           |
|00000-144-9b6d00c0-d4cf-4835-8286-ebfe2401e47a-0-00001.parquet|1000000     |4031663           |Anjali          |Tom             |
|00000-15-8138298d-923b-44f7-9bd6-90d9c0e9e4ed-0-00001.parquet |1           |831               |Brad            |Brad            |
|00000-155-9dea2d4f-fc98-418d-a504-6226eb0a5135-0-00001.parquet|1000000     |4031676           |Anjali          |Tom             |
|00000-16-ed37cf2d-4306-4036-98de-727c1fe4e0f9-0-00001.parquet |1           |830               |Brad            |Brad            |
|00000-166-b67929dc-f9c1-4579-b955-0d6ef6c604b2-0-00001.parquet|1000000     |4031729           |Anjali          |Tom             |
|00000-17-1011820e-ee25-4f7a-bd73-2843fb1c3150-0-00001.parquet |1           |830               |Noah            |Noah            |
|00000-177-14a9db71-56bb-4325-93b6-737136f5118d-0-00001.parquet|1000000     |4031778           |Anjali          |Tom             |
|00000-18-89cbb849-876a-441a-9ab0-8535b05cd222-0-00001.parquet |1           |838               |David           |David           |
|00000-188-6dc3dcca-ddc0-405e-aa0f-7de8637f993b-0-00001.parquet|1000000     |4031727           |Anjali          |Tom             |
+--------------------------------------------------------------+------------+------------------+----------------+----------------+
solely exhibiting prime 20 rows

Observo que a tabela é feita de vários arquivos pequenos e que os limites superior e inferior para os novos arquivos têm sobreposição – os dados certamente não são classificados.

Eu defino o pedido de classificação da tabela.

spark.sql("ALTER TABLE ice_catalog.testnamespace.testtable WRITE ORDERED BY identify ASC")

Eu habilito a compactação de tabela (é ativada por padrão; desativei no início desta demonstração)

aws s3tables put-table-maintenance-configuration --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable --type icebergCompaction --value "standing=enabled,settings={icebergCompaction={technique=kind}}"

Então, espero o próximo trabalho de compactação para acionar. Eles são executados ao longo do dia, quando há arquivos pequenos suficientes. Posso verificar o standing da compactação com o seguinte comando.

aws s3tables get-table-maintenance-job-status --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable

Quando a compactação é concluída, inspeciono os arquivos que compõem minha tabela mais uma vez. Vejo que os dados foram compactados em dois arquivos e os limites superior e inferior mostram que os dados foram classificados nesses dois arquivos.

spark.sql("""
  SELECT 
    substring_index(file_path, '/', -1) as file_name,
    record_count,
    file_size_in_bytes,
    CAST(UNHEX(hex(lower_bounds(2))) AS STRING) as lower_bound_name,
    CAST(UNHEX(hex(upper_bounds(2))) AS STRING) as upper_bound_name
  FROM ice_catalog.testnamespace.testtable.information
  ORDER BY file_name
""").present(20, false)

+------------------------------------------------------------+------------+------------------+----------------+----------------+
|file_name                                                   |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name|
+------------------------------------------------------------+------------+------------------+----------------+----------------+
|00000-4-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|13195713    |50034921          |Anjali          |Kelly           |
|00001-5-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|10804307    |40964156          |Liza            |Tom             |
+------------------------------------------------------------+------------+------------------+----------------+----------------+

Existem menos arquivos, eles têm tamanhos maiores e há um melhor agrupamento na coluna de classificação especificada.

Para usar z-orderEu sigo os mesmos passos, mas eu defino technique=z-order na configuração de manutenção.

Disponibilidade regional
Kind e z-order Compaction está agora disponível em Todas as regiões da AWS onde as tabelas Amazon S3 são suportadas e para os baldes S3 de uso geral, onde está disponível otimização com o catálogo de dados da AWS Glue. Não há cobrança adicional para tabelas S3 além das taxas de uso e manutenção existentes. Para otimizações de catalogação de dados, as taxas de computação se aplicam durante a compactação.

Com essas mudanças, consultas que filtram no kind ou z-order As colunas se beneficiam de tempos de varredura mais rápidos e custos reduzidos do motor. Na minha experiência, dependendo do meu format de dados e padrões de consulta, observei melhorias de desempenho de três vezes ou mais ao mudar de binpack para kind ou z-order. Diga -nos quanto seus ganhos estão com seus dados reais.

Para saber mais, visite o Tabelas Amazon S3 página do produto ou revise o Documentação de manutenção de tabelas S3. Você também pode começar a testar as novas estratégias em suas próprias tabelas hoje usando a API S3 Tables ou Otimizações de cola da AWS.

– seb