Trabalhar com tabelas do Apache Iceberg usando o SQL do Amazon Athena

O Amazon Athena fornece suporte integrado para o Apache Iceberg e não exige etapas ou configurações adicionais. Esta seção fornece uma visão geral detalhada dos recursos suportados e orientações de alto nível sobre o uso do Athena para interagir com as tabelas Iceberg.

Compatibilidade de versões e recursos

nota

As seções a seguir pressupõem que você esteja usando a versão 3 do motor Athena.

Suporte à especificação da tabela Iceberg

A especificação da tabela Apache Iceberg especifica como as tabelas Iceberg devem se comportar. O Athena oferece suporte ao formato de tabela versão 2, portanto, qualquer tabela Iceberg que você criar com o console, a CLI ou o SDK usa essa versão inerentemente.

Se você usa uma tabela Iceberg criada com outro mecanismo, como o Apache Spark no Amazon EMR ou AWS Glue, certifique-se de definir a versão do formato da tabela usando as propriedades da tabela. Como referência, consulte a seção Criando e escrevendo tabelas Iceberg anteriormente neste guia.

Suporte ao recurso Iceberg

Você pode usar o Athena para ler e gravar em tabelas Iceberg. Quando você altera os dados usando as DELETE FROM instruçõesUPDATE, eMERGE INTO, o Athena suporta somente o merge-on-read modo. Essa propriedade não pode ser alterada. Para atualizar ou excluir dados com copy-on-write, você precisa usar outros mecanismos, como o Apache Spark no Amazon EMR ou. AWS Glue A tabela a seguir resume o suporte aos recursos do Iceberg no Athena.

		Suporte DDL		Suporte a DML		AWS Lake Formation para segurança (opcional)
	Formato da tabela	Create table	Evolução do esquema	Leitura de dados	Gravação de dados	Controle de acesso de linha/coluna
Amazon Athena	Versão 2	✓	✓	✓	XC opy-on-write	✓
					✓ M erge-on-read	✓

nota

O Athena não oferece suporte a consultas incrementais.

Trabalhando com mesas Iceberg

Para começar rapidamente a usar o Iceberg no Athena, consulte a seção Introdução às tabelas do Iceberg no Athena SQL, anteriormente neste guia.

A tabela a seguir lista as limitações e recomendações.

Cenário	Limitação	Recomendação
Tabela de geração de DDL	As tabelas de iceberg criadas com outros mecanismos podem ter propriedades que não estão expostas no Athena. Para essas tabelas, não é possível gerar o DDL.	Use a instrução equivalente no mecanismo que criou a tabela (por exemplo, a SHOW CREATE TABLE instrução do Spark).
Prefixos aleatórios do Amazon S3 em objetos que são gravados em uma tabela Iceberg	Por padrão, as tabelas Iceberg criadas com o Athena têm write.object-storage.enabled a propriedade ativada.	Para desativar esse comportamento e obter controle total sobre as propriedades da tabela Iceberg, crie uma tabela Iceberg com outro mecanismo, como o Spark no Amazon EMR ou. AWS Glue
Consultas incrementais	Atualmente, não há suporte no Athena.	Para usar consultas incrementais para permitir pipelines incrementais de ingestão de dados, use o Spark no Amazon EMR ou. AWS Glue

Migração de tabelas existentes para o Iceberg

Para migrar suas tabelas atuais do Athena AWS Glue (também conhecidas como tabelas do Hive) para o formato Iceberg, você pode usar a migração de dados local ou completa:

• A migração local é o processo de gerar os arquivos de metadados do Iceberg sobre os arquivos de dados existentes.

• A migração completa de dados cria a camada de metadados do Iceberg e também reescreve os arquivos de dados existentes da tabela original para a nova tabela do Iceberg.

As seções a seguir fornecem uma visão geral das APIs disponíveis para migrar tabelas e orientações para escolher uma estratégia de migração. Para obter mais informações sobre essas duas estratégias, consulte a seção Migração de tabelas na documentação do Iceberg.

Migração local

A migração local elimina a necessidade de reescrever todos os arquivos de dados. Em vez disso, os arquivos de metadados do Iceberg são gerados e vinculados aos seus arquivos de dados existentes. O Iceberg oferece três opções para implementar a migração local:

• Usando o snapshot procedimento, conforme explicado nas seções Tabela de instantâneos e Procedimento do Spark: instantâneo na documentação do Iceberg.

• Usando o add_files procedimento, conforme explicado nas seções Adicionar arquivos e Procedimento do Spark: add_files na documentação do Iceberg.

• Usando o migrate procedimento, conforme explicado nas seções Migrar tabela e Procedimento do Spark: Migrar na documentação do Iceberg.

Atualmente, o procedimento de migração não funciona diretamente com o AWS Glue Data Catalog— ele funciona somente com o metastore Hive. Se você precisar usar o migrate procedimento em vez de snapshot ouadd_files, você pode usar um cluster temporário do Amazon EMR com o metastore Hive (HMS). Essa abordagem requer a versão 1.2 ou posterior do Iceberg.

Digamos que você queira criar a seguinte tabela do Hive:

Você pode criar essa tabela do Hive executando este código no console do Athena:

CREATE EXTERNAL TABLE 'hive_table'(
  'id' bigint, 
  'data' string)
USING parquet
LOCATION
  's3://datalake-xxxx/aws_workshop/iceberg_db/hive_table'

INSERT INTO iceberg_db.hive_table VALUES (1, 'a')

Se sua tabela do Hive estiver particionada, inclua a instrução de partição e adicione as partições de acordo com os requisitos do Hive.

ALTER TABLE default.placeholder_table_for_migration ADD 
    PARTITION (date = '2023-10-10')

Etapas:

1. Crie um cluster do Amazon EMR sem habilitar a AWS Glue Data Catalog integração, ou seja, não marque as caixas de seleção dos metadados das tabelas Hive ou Spark. Isso porque você usará o metastore nativo do Hive (HMS) que está disponível no cluster para essa solução alternativa.

   

2. Configure a sessão do Spark para usar a implementação do catálogo Iceberg Hive.

   "spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
   "spark.sql.catalog.spark_catalog": "org.apache.iceberg.spark.SparkSessionCatalog",
           "spark.sql.catalog.spark_catalog.type": "hive",

3. Valide se seu cluster do Amazon EMR não está conectado AWS Glue Data Catalog ao executando show databases ou. show tables

   

4. Registre a tabela do Hive no metastore Hive do seu cluster do Amazon EMR e, em seguida, use o procedimento Iceberg. migrate

   

   Esse procedimento cria os arquivos de metadados do Iceberg no mesmo local da tabela do Hive.

5. Registre a tabela Iceberg migrada no. AWS Glue Data Catalog

6. Volte para um cluster do Amazon EMR que tenha a AWS Glue Data Catalog integração ativada.

   

7. Use a seguinte configuração do Iceberg na sessão do Spark.

   "spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
           "spark.sql.catalog.glue_catalog": "org.apache.iceberg.spark.SparkCatalog",
           "spark.sql.catalog.glue_catalog.warehouse": "s3://datalake-xxxx/aws_workshop",
           "spark.sql.catalog.glue_catalog.catalog-impl": "org.apache.iceberg.aws.glue.GlueCatalog",
           "spark.sql.catalog.glue_catalog.io-impl": "org.apache.iceberg.aws.s3.S3FileIO",

Agora você pode consultar essa tabela no Amazon EMR ou no AWS Glue Athena.

Migração completa de dados

A migração completa de dados recria os arquivos de dados e os metadados. Essa abordagem leva mais tempo e requer recursos computacionais adicionais em comparação com a migração local. No entanto, essa opção ajuda a melhorar a qualidade da tabela: você pode validar os dados, fazer alterações no esquema e na partição, recorrer aos dados e assim por diante. Para implementar a migração completa de dados, use uma das seguintes opções:

• Use a declaração CREATE TABLE ... AS SELECT (CTAS) no Spark no Amazon EMR ou no Athena. AWS Glue  Você pode definir a especificação da partição e as propriedades da tabela para a nova tabela Iceberg usando as TBLPROPERTIES cláusulas PARTITIONED BY e. Você pode ajustar o esquema e o particionamento da nova tabela de acordo com suas necessidades, em vez de simplesmente herdá-los da tabela de origem.

• Leia a tabela de origem e grave os dados como uma nova tabela Iceberg usando o Spark no Amazon EMR ou AWS Glue (consulte Criação de uma tabela na documentação do Iceberg).

Selecionar uma estratégia de migração

Para escolher a melhor estratégia de migração, considere as perguntas na tabela a seguir.

Pergunta	Recomendação
Qual é o formato do arquivo de dados (por exemplo, CSV ou Apache Parquet)?	Considere a migração local se o formato do arquivo de tabela for Parquet, ORC ou Avro. Para outros formatos, como CSV, JSON e assim por diante, use a migração de dados completa.
Você quer atualizar ou consolidar o esquema da tabela?	Se você quiser desenvolver o esquema da tabela usando os recursos nativos do Iceberg, considere a migração local. Por exemplo, você pode renomear colunas após a migração. (O esquema pode ser alterado na camada de metadados do Iceberg.) Se você quiser excluir colunas inteiras dos arquivos de dados, recomendamos usar a migração de dados completa.
A tabela se beneficiaria com a mudança da estratégia de partição?	Se a abordagem de particionamento do Iceberg atender aos seus requisitos (por exemplo, novos dados são armazenados usando o novo layout de partição enquanto as partições existentes permanecem como estão), considere a migração local. Se você quiser usar partições ocultas em sua tabela, considere a migração completa dos dados. Para obter mais informações sobre partições ocultas, consulte a seção Práticas recomendadas.
A tabela se beneficiaria com a adição ou alteração da estratégia de ordem de classificação?	Adicionar ou alterar a ordem de classificação dos seus dados exige a reescrita do conjunto de dados. Nesse caso, considere usar a migração de dados completa. Para tabelas grandes em que é extremamente caro reescrever todas as partições da tabela, considere usar a migração local e executar a compactação (com a classificação ativada) para as partições acessadas com mais frequência.
A tabela tem muitos arquivos pequenos?	A mesclagem de arquivos pequenos em arquivos maiores exige a regravação do conjunto de dados. Nesse caso, considere usar a migração de dados completa. Para tabelas grandes em que é extremamente caro reescrever todas as partições da tabela, considere usar a migração local e executar a compactação (com a classificação ativada) para as partições acessadas com mais frequência.