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á.
# Sistema de arquivos S3A
Esta seção aborda os protocolos para o Spark em execução no Amazon Elastic Map Reduce (EMR) ao usar o sistema de arquivos S3A.
# S3A MagicV2 Committer
Com o lançamento do EMR-6.15.0, o Amazon EMR apresenta um novo tipo de committer S3A conhecido como MagicV2 committer. Para obter informações completas sobre esse recurso, consulte as seções relevantes da documentação.
O MagicV2 Committer representa uma implementação aprimorada do código aberto [MagicCommitter](https://javadoc.io/static/org.apache.hadoop/hadoop-aws/3.4.0/org/apache/hadoop/fs/s3a/commit/magic/MagicS3GuardCommitter.html), projetada especificamente para otimizar a gravação de arquivos no Amazon S3 por meio do sistema de arquivos S3A. Assim como seu antecessor, ele aproveita os recursos de upload em várias partes do Amazon S3 para eliminar as operações tradicionais de listagem e renomeação normalmente associadas às fases de commit de trabalhos e tarefas.
Em comparação com o original MagicCommitter, o committer MagicV2 demonstra desempenho superior gravando arquivos no local de saída do trabalho durante a fase de confirmação da tarefa, em vez da fase de confirmação do trabalho. Essa abordagem permite a gravação distribuída de arquivos e elimina a necessidade de armazenamento temporário de metadados de commit no Amazon S3, resultando em maior economia. Além disso, o MagicV2 committer oferece maior flexibilidade, permitindo a substituição de caminhos de arquivos em várias threads durante o processo de commit.
## Habilitar o MagicV2 Committer
Para habilitar o MagicV2 committer, passe a seguinte configuração na configuração do seu trabalho ou use a configuração core-site para definir a propriedade. Para obter mais informações, consulte [Configure applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
```
mapreduce.outputcommitter.factory.scheme.s3a=org.apache.hadoop.fs.s3a.commit.S3ACommitterFactory
fs.s3a.committer.magic.enabled=true
fs.s3a.committer.name=magicv2
fs.s3a.committer.magic.track.commits.in.memory.enabled=true
```
Para workloads que exigem a substituição do diretório existente antes de confirmar ou gravar os novos arquivos, é necessário a seguinte configuração adicional, juntamente com a configuração mencionada anteriormente.
```
fs.s3a.committer.magic.overwrite.and.commit=true
fs.s3a.committer.magic.delete.directory.threads=thread size
```
O valor padrão para a configuração `threads` é `20`. No entanto, esse parâmetro deve ser ajustado quando houver um grande número de diretórios a serem sobrescritos para obter melhor performance. Isso está disponível apenas no EMR-7.2.0 e versões superiores.
## Considerações
+ Se a Java Virtual Machine (JVM) travar ou for encerrada enquanto as tarefas estiverem em execução e gravando dados no Amazon S3, é mais provável que os uploads em várias partes incompletos sejam abandonados. Por esse motivo, ao usar o MagicV2 committer, certifique-se de seguir as práticas recomendadas para gerenciar uploads em várias partes com falha. Para obter mais informações, consulte a seção [Práticas recomendadas para trabalhar com buckets do S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) no Guia de gerenciamento do Amazon EMR.
+ Se um trabalho falhar, todos os arquivos confirmados pelas tarefas bem-sucedidas ainda estarão visíveis no caminho de destino. Nesses casos, o usuário precisará limpar manualmente os arquivos confirmados antes de executar novamente o trabalho no mesmo caminho de destino.
+ O MagicV2 Committer consome uma pequena quantidade de memória para cada arquivo gravado por uma tentativa de tarefa até que a tarefa seja confirmada ou cancelada. Na maioria dos trabalhos, a quantidade de memória consumida é insignificante. Porém, em alguns casos em que um único processo de executor lida com um grande número de tarefas ao mesmo tempo, isso pode sobrecarregar a memória, e o contêiner ou executor pode ficar sem memória (OOM). Aumentar a memória do contêiner ou do executor deve resolver esse problema.
# Guia de migração: EMRFS para o Sistema de arquivos S3A
Começando na versão EMR-7.10.0, o Sistema de arquivos S3A é o conector padrão de sistema de arquivos/S3 para clusters do EMR em todos os esquemas de arquivos do S3, entre eles:
+ **s3://**
+ **s3n://**
+ **s3a://**
Essa alteração se aplica a todas as implantações do EMR EC2, incluindo EKS e EMR Serverless.
Se quiser continuar usando o EMRFS, você pode configurar isso adicionando a seguinte propriedade ao arquivo de configuração `core-site.xml`:
```
fs.s3.impl
com.amazon.ws.emr.hadoop.fs.EmrFileSystem
```
## Migração das configurações existentes do EMRFS para configurações do S3A
**nota**
O Amazon EMR implementa o mapeamento automático de configurações entre o EMRFS e o S3A quando condições específicas são atendidas. O processo de mapeamento ocorre automaticamente quando as configurações do S3A são indefinidas, enquanto as configurações correspondentes do EMRFS estão presentes. Essa funcionalidade de mapeamento automático se estende às configurações em nível de bucket, permitindo uma integração perfeita entre as configurações do EMRFS e do S3A. Como ilustração, quando você configura uma configuração de criptografia específica do bucket no EMRFS usando 'fs.s3.bucket.amzn-s3-demo-bucket1. serverSideEncryption.kms.keyId' com um valor de “XYZ”, o sistema mapeia isso automaticamente para a configuração equivalente do S3A definindo 'fs.s3a.encryption.key' como “XYZ” para o bucket especificado amzn-s3-demo-bucket1.
O seguinte conjunto predefinido de configurações do EMRFS será automaticamente convertido em seus respectivos equivalentes de configuração do S3A. Todas as configurações atualmente implementadas por meio de substituições de cluster ou de trabalho farão a transição perfeita para o sistema de arquivos S3A sem exigir configurações ou modificações manuais adicionais.
Por padrão, esse recurso de mapeamento de configurações é ativado automaticamente. Os usuários que desejam desabilitar essa conversão automática podem fazer isso adicionando a seguinte propriedade ao arquivo de configuração core-site.xml.
```
fs.s3a.emrfs.compatibility.enable
false
```
**nota**
O mapeamento da chave de criptografia do EMRFS (fs.s3. serverSideEncryption.kms.keyID ou fs.s3.cse.kms.keyID) a S3A (fs.s3a.encryption.key) ocorre somente quando a criptografia SSE-KMS ou CSE-KMS está ativada em qualquer sistema de arquivos.
**Mapeamento de configurações do EMRFS para o S3A**
| Nome da configuração do EMRFS | Nome da configuração do S3A |
| --- | --- |
| fs.s3.aimd.adjustWindow | fs.s3a.aimd.adjustWindow |
| fs.s3.aimd.enabled | fs.s3a.aimd.enabled |
| fs.s3.aimd.increaseIncrement | fs.s3a.aimd.increaseIncrement |
| fs.s3.aimd.initialRate | fs.s3a.aimd.initialRate |
| fs.s3.aimd.maxAttempts | fs.s3a.aimd.maxAttempts |
| fs.s3.aimd.minRate | fs.s3a.aimd.minRate |
| fs.s3.aimd.reductionFactor | fs.s3a.aimd.reductionFactor |
| fs.s3.sts.endpoint | fs.s3a.assumed.role.sts.endpoint |
| fs.s3.sts. sessionDurationSeconds | fs.s3a.assumed.role.session.duration |
| fs.s3.authorization.roleMapping | fs.s3a.authorization.roleMapping |
| fs.s3.authorization.ugi.groupName.enabled | fs.s3a.authorization.ugi.groupName.enabled |
| fs.3. credentialsResolverClass | fs.s3a.credentials.resolver |
| fs.s3n.multipart.uploads.enabled | fs.s3a.multipart.uploads.enabled |
| fs.s3n.multipart.uploads.split.size | fs.s3a.multipart.size |
| fs.3. serverSideEncryption.kms. customEncryptionContext | fs.s3a.encryption.context |
| fs.3. enableServerSideCriptografia | fs.s3a.encryption.algorithm |
| fs.3. serverSideEncryption.kms.keyID/fs.s3.cse.kms.keyID | fs.s3a.encryption.key |
| fs.s3.cse.kms.region | fs.s3a.encryption.cse.kms.region |
| fs.s3.authorization.audit.enabled | fs.s3a.authorization.audit.enabled |
| fs.s3.buckets.create.enabled | fs.s3a.bucket.probe |
| fs.s3.delete. maxBatchSize | fs.s3a.bulk.delete.page.size |
| fs.s3.filestatus.metadata.enabled | fs.s3a.metadata.cache.enabled |
| fs.s3.maxConnections | fs.s3a.connection.maximum |
| fs.s3.maxRetries | fs.s3a.retry.limit |
| fs.s3.metadata.cache.expiration.seconds | fs.s3a.metadata.cache.expiration.seconds |
| fs.s3.buffer.dir | fs.s3a.buffer.dir |
| fs.s3.canned.acl | fs.s3a.acl.default |
| fs.s3.positionedRead.optimization.enabled | fs.s3a.positionedread.optimization.enabled |
| fs.3. readFullyIntoBuffers.Otimização.Ativado | fs.s3a. readFullyIntoBuffers.Otimização.Ativado |
| fs.s3.signerType | fs.s3a.signing-algorithm |
| fs.s3.storageClass | fs.s3a.create.storage.class |
| fs.s3.threadpool.maxSize | fs.s3a.threads.max |
| fs.3. useRequesterPayscabeçalho | fs.s3a.requester.pays.enabled |
| fs.s3n.block.size | fs.s3a.block.size |
| fs.s3n.endpoint | fs.s3a.endpoint |
| fs.s3n.ssl.enabled | fs.s3a.connection.ssl.enabled |
| fs.s3.open. acceptsFileStatus | fs.s3a.open. acceptsFileStatus |
| fs.s3. conexão. maxIdleMilliSegundos | fs.s3a.connection.idle.time |
| fs.s3.s3 .habilitado AccessGrants | fs.s3a.access.grants.enabled |
| AccessGrantsfs.s3.s3. Volte para o IAM | fs.s3a.access.grants.fallback.to.iam |
### Condições e limitações
+ Todos os motores EMR — Spark, Flink, Tez MapReduce, Hive etc. usarão o S3A como o conector S3 padrão, exceto os motores Trino e Presto.
+ O EMR S3A não oferece suporte para integração com o EMR Ranger. Considere migrar para AWS Lake Formation.
+ AWS Não há suporte RecordServer para Lake Formation Support with For EMR Spark with S3A. Considere usar o Spark Native FGAC.
+ AWS O S3 Select não é suportado.
+ A opção de limpar periodicamente o upload incompleto de várias peças (MPU) não está disponível com o S3A - Considere configurar a política de [ciclo de vida do bucket do S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) para eliminar pendências. MPUs
+ [Para migrar do EMRFS para o S3A usando a criptografia S3 CSE-CUSTOM, o provedor de chave personalizada precisa ser reescrito da interface para a interface do Keyring. [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider)](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/choose-keyring.html) Consulte a configuração de [CSE-CUSTOM](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-s3a-cse-custom.html) do S3A para obter mais informações.
+ Os diretórios do Amazon S3 criados usando o EMRFS são marcados com o sufixo '\$1\$1folder\$1', enquanto os diretórios criados usando o sistema de arquivos S3A terminam com o sufixo '/', que é consistente com os diretórios criados por meio do console do S3. AWS
+ Para usar um provedor de credenciais personalizadas do S3, defina a propriedade de configuração do S3A `fs.s3a.aws.credentials.provider` com a mesma classe de provedor de credenciais usada anteriormente na configuração `fs.s3.customAWSCredentialsProvider` do EMRFS.
### Configurações do EMRFS sem suporte
As seguintes configurações do EMRFS foram identificadas como sem suporte ou obsoletas e, consequentemente, nenhum mapeamento direto será fornecido para suas contrapartes de configuração do S3A. Essas configurações específicas não serão convertidas ou transferidas automaticamente durante a migração para o sistema de arquivos S3A.
**Configurações do EMRFS sem suporte e motivos**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/emr-s3a-migrate.html)