

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# S3A-Dateisystem
<a name="emr-s3a-file"></a>

Dieser Abschnitt behandelt Protokolle für Spark, die auf Amazon Elastic Map Reduce (EMR) ausgeführt werden, wenn das S3A-Dateisystem verwendet wird.

# S3A MagicV2 Committer
<a name="s3a-magicv2-committer"></a>

Mit der Version EMR-6.15.0 führt Amazon EMR einen neuen S3A-Committer-Typ ein, der als MagicV2-Committer bekannt ist. Umfassende Informationen zu dieser Funktion finden Sie in den entsprechenden Abschnitten der Dokumentation.

Der MagicV2 Committer stellt eine erweiterte Open-Source-Implementierung dar [MagicCommitter](https://javadoc.io/static/org.apache.hadoop/hadoop-aws/3.4.0/org/apache/hadoop/fs/s3a/commit/magic/MagicS3GuardCommitter.html), die speziell für die Optimierung des Schreibens von Dateien auf Amazon S3 über das S3A-Dateisystem entwickelt wurde. Wie sein Vorgänger nutzt es die mehrteiligen Upload-Funktionen von Amazon S3, um die traditionellen Listen- und Umbenennungsvorgänge zu eliminieren, die normalerweise mit Job- und Task-Commit-Phasen verbunden sind.

Im Vergleich zum Original weist der MagicV2-Committer eine überragende Leistung auf MagicCommitter, da er Dateien während der Commit-Phase der Aufgabe und nicht während der Commit-Phase des Jobs an den Ausgabespeicherort des Jobs schreibt. Dieser Ansatz ermöglicht das verteilte Schreiben von Dateien und macht die temporäre Speicherung von Commit-Metadaten auf Amazon S3 überflüssig, was zu einer verbesserten Kosteneffizienz führt. Darüber hinaus bietet der MagicV2-Committer mehr Flexibilität, da er das Überschreiben von Dateipfaden in mehreren Threads während des Commit-Prozesses ermöglicht.

## Aktivieren Sie den MagicV2 Committer
<a name="s3a-magicv2-committer-enable"></a>

Um den MagicV2-Committer zu aktivieren, übergeben Sie die folgende Konfiguration in Ihrer Job-Konfiguration oder verwenden Sie die Core-Site-Konfiguration, um die Eigenschaft festzulegen. Weitere Informationen finden Sie unter [Konfigurieren von Anwendungen](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
```

Für Workloads, bei denen das bestehende Verzeichnis vor dem Commit oder Schreiben der neuen Dateien überschrieben werden muss, ist neben der zuvor genannten Konfiguration die folgende zusätzliche Konfiguration erforderlich.

```
fs.s3a.committer.magic.overwrite.and.commit=true
fs.s3a.committer.magic.delete.directory.threads=thread size
```

Der Standardwert für die Konfiguration ist`threads`. `20` Dieser Parameter sollte jedoch angepasst werden, wenn eine große Anzahl von Verzeichnissen überschrieben werden muss, um die Leistung zu verbessern. Dies ist nur in EMR-7.2.0 und höher verfügbar.

## Überlegungen
<a name="considerations"></a>
+ Wenn die Java Virtual Machine (JVM) abstürzt oder beendet wird, während Aufgaben ausgeführt werden und Daten auf Amazon S3 geschrieben werden, ist es wahrscheinlicher, dass unvollständige mehrteilige Uploads zurückbleiben. Aus diesem Grund sollten Sie bei der Verwendung des MagicV2-Committers unbedingt die bewährten Methoden für den Umgang mit fehlgeschlagenen mehrteiligen Uploads befolgen. Weitere Informationen finden Sie im Abschnitt [Bewährte Methoden für die Arbeit mit Amazon S3 S3-Buckets](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) im Amazon EMR Management Guide.
+ Wenn ein Job fehlschlägt, sind alle Dateien, die durch die erfolgreichen Aufgaben übertragen wurden, weiterhin im Zielpfad sichtbar. In solchen Fällen muss der Benutzer die übergebenen Dateien manuell bereinigen, bevor er den Job auf demselben Zielpfad erneut ausführen kann.
+ Der MagicV2-Committer verbraucht für jede Datei, die bei einem Task-Versuch geschrieben wurde, eine geringe Menge an Speicher, bis die Aufgabe festgeschrieben oder abgebrochen wird. Bei den meisten Jobs ist die Menge an Arbeitsspeicher, die ry verbraucht, vernachlässigbar. In einigen Fällen, in denen ein einzelner Executor-Prozess eine große Anzahl von Aufgaben gleichzeitig abwickelt, kann dies jedoch zu einer hohen Speicherbelastung führen, sodass dem Container oder Executor möglicherweise der Arbeitsspeicher (OOM) ausgeht. Dieses Problem sollte durch eine Erhöhung des Container- oder Executor-Speichers behoben werden.

# Migrationshandbuch: EMRFS zum S3A-Dateisystem
<a name="emr-s3a-migrate"></a>

Ab der Version EMR-7.10.0 ist das S3A-Dateisystem der Standard-Dateisystem/s3-Konnektor für EMR-Cluster für alle S3-Dateischemas, einschließlich der folgenden:
+ **s3://**
+ **s3n://**
+ **s3a://**

Diese Änderung gilt für alle EMR-Bereitstellungen EC2, einschließlich EKS und EMR Serverless.

Wenn Sie EMRFS weiterhin verwenden möchten, können Sie dies konfigurieren, indem Sie der Konfigurationsdatei die folgende Eigenschaft hinzufügen: `core-site.xml`

```
<property>
  <name>fs.s3.impl</name>
  <value>com.amazon.ws.emr.hadoop.fs.EmrFileSystem</value>
</property>
```

## Migration vorhandener EMRFS-Konfigurationen zu S3A-Konfigurationen
<a name="emr-s3a-migration-of-existing-emrfs-configurations"></a>

**Anmerkung**  
Amazon EMR implementiert die automatische Konfigurationszuweisung zwischen EMRFS und S3A, wenn bestimmte Bedingungen erfüllt sind. Der Zuordnungsprozess erfolgt automatisch, wenn S3A-Konfigurationen nicht definiert sind, während entsprechende EMRFS-Konfigurationen vorhanden sind. Diese automatische Zuordnungsfunktion erstreckt sich auf Konfigurationen auf Bucket-Ebene und ermöglicht eine nahtlose Integration zwischen EMRFS- und S3A-Einstellungen. Zur Veranschaulichung, wenn Sie in EMRFS mithilfe von 'fs.s3.bucket.amzn-s3-demo-bucket1 eine bucket-spezifische Verschlüsselungseinstellung konfigurieren. serverSideEncryption.kms.keyID' mit dem Wert „XYZ“, das System ordnet dies automatisch der entsprechenden S3A-Konfiguration zu, indem 'fs.s3a.encryption.key' für den angegebenen Bucket amzn-s3-demo-bucket1 auf „XYZ“ gesetzt wird.

Der folgende vordefinierte Satz von EMRFS-Konfigurationen wird automatisch in die entsprechenden S3A-Konfigurationsäquivalente übersetzt. Alle Konfigurationen, die derzeit über Cluster- oder Job-Overrides implementiert werden, werden nahtlos auf das S3A-Dateisystem umgestellt, ohne dass zusätzliche manuelle Konfigurationen oder Änderungen erforderlich sind.

Standardmäßig ist diese Funktion zur Konfigurationszuweisung automatisch aktiviert. Benutzer, die diese automatische Übersetzung deaktivieren möchten, können dies tun, indem sie der Konfigurationsdatei core-site.xml die folgende Eigenschaft hinzufügen.

```
<property>
  <name>fs.s3a.emrfs.compatibility.enable</name>
  <value>false</value>
</property>
```

**Anmerkung**  
Die Zuordnung der Verschlüsselungsschlüssel aus EMRFS (fs.s3. serverSideEncryption.kms.keyID oder fs.s3.cse.kms.keyID) zu S3A (fs.s3a.encryption.key) erfolgt nur, wenn entweder SSE-KMS- oder CSE-KMS-Verschlüsselung auf einem der Dateisysteme aktiviert ist.


**Zuordnung der Konfiguration von EMRFS zu S3A**  

| Name der EMRFS-Konfiguration | S3A-Konfigurationsname | 
| --- | --- | 
| fs.s3.aimd.AdjustWindow | fs.s3a.aimd.AdjustWindow | 
| fs.s3.aimd.aktiviert | fs.s3a.aimd.aktiviert | 
| fs.s3.aimd.Erhöhung erhöhen | fs.s3a.aimd.Erhöhen Sie das Inkrement | 
| fs.s3.aimd.Anfangsrate | fs.s3a.aimd.InitialRate | 
| fs.s3.aimd.max Versuche | fs.s3a.aimd.max-Versuche | 
| Rate fs.s3.aimd.min | Rate fs.s3a.aimd.min | 
| fs.s3.aimd.Reduktionsfaktor | fs.s3a.aimd.Reduktionsfaktor | 
| 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.s3. credentialsResolverClass | fs.s3a.credentials als.resolver | 
| fs.s3n.multipart.uploads.enabled | fs.s3a.multipart.uploads.enabled | 
| fs.s3n.multipart.uploads.split.size | fs.s3a.multipart.size | 
| fs.s3. serverSideEncryption. km. customEncryptionContext | fs.s3a.encryption.context | 
| fs.s3. enableServerSideVerschlüsselung | fs.s3a.encryption.algorithm | 
| fs.s3. 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. löschen. maxBatchSize | fs.s3a.bulk.delete.page.size | 
| fs.s3.filestatus.metadata.enabled | fs.s3a.metadata.cache.enabled | 
| fs.S3.max-Verbindungen | fs.s3a.Verbindung.Maximum | 
| fs.s3.max versucht es erneut | 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 hat .acl gescannt | fs.s3a.acl.default | 
| fs.s3.positionedRead.Optimization.Enabled | fs.s3a.positionedRead.Optimization.Enabled | 
| fs.s3. readFullyIntoPuffer.Optimierung.Aktiviert | fs.s3a. readFullyIntoPuffer.Optimierung.Aktiviert | 
| Typ fs.s3.signer | fs.s3a.Signierungsalgorithmus | 
| fs.s3.Storage-Klasse | fs.s3a.create.storage.class | 
| fs.s3.threadpool.maxSize | fs.s3a.threads.max | 
| fs.s3. useRequesterPaysKopfzeile | fs.s3a.requester.pays.enabled | 
| fs.s3n.block.size | fs.s3a.block.size | 
| fs.s3n.Endpunkt | fs.s3a.endpoint | 
| fs.s3n.ssl.enabled | fs.s3a.connection.ssl.enabled | 
| fs.s3. öffnen. acceptsFileStatus | fs.s3a.öffnen. acceptsFileStatus | 
| fs.s3-Verbindung. maxIdleMilliSekunden | fs.s3a.connection.idle.time | 
| fs.s3.s3 AccessGrants .aktiviert | fs.s3a.access.grants.enabled | 
| fs.s3.s3AccessGrants. Fallback zu IAM | fs.s3a.access.grants.fallback.to.iam | 

### Überlegungen und Einschränkungen
<a name="emr-s3a-migration-considerations-and-limitations"></a>
+ Alle EMR-Engines — Spark, Flink MapReduce, Tez, Hive usw. — verwenden S3A als Standard-S3-Anschluss, mit Ausnahme der Trino- und Presto-Motoren.
+ EMR S3A unterstützt keine Integration mit EMR Ranger. Erwägen Sie, nach AWS Lake Formation zu migrieren.
+ AWS Lake Formation Support mit RecordServer For EMR Spark with S3A wird nicht unterstützt. Erwägen Sie die Verwendung von Spark Native FGAC.
+ AWS S3 Select wird nicht unterstützt.
+ Die Option zur regelmäßigen Bereinigung von unvollständigen Multi-Part-Uploads (MPU) ist in S3A nicht verfügbar. Ziehen Sie in Erwägung, die [S3-Bucket-Lebenszyklusrichtlinie](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) so zu konfigurieren, dass nicht mehr gelöschte Dateien entfernt werden. MPUs
+ [Um von EMRFS zu S3A zu migrieren und dabei die S3 CSE-CUSTOM-Verschlüsselung zu verwenden, muss der benutzerdefinierte Schlüsselanbieter von Schnittstelle zu Keyring-Schnittstelle neu geschrieben werden. [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) [Weitere Informationen finden Sie unter S3A CSE-CUSTOM einrichten.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-s3a-cse-custom.html)
+ Amazon S3 S3-Verzeichnisse, die mit EMRFS erstellt wurden, sind mit dem Suffix '\$1\$1folder\$1' gekennzeichnet, während Verzeichnisse, die mit dem S3A-Dateisystem erstellt wurden, mit dem Suffix '/' enden, was mit Verzeichnissen übereinstimmt, die über die S3-Konsole erstellt wurden. AWS 
+ Um einen benutzerdefinierten S3-Anmeldeinformationsanbieter zu verwenden, legen Sie für die S3A-Konfigurationseigenschaft dieselbe Anbieterklasse für Anmeldeinformationen fest, die zuvor in der `fs.s3a.aws.credentials.provider` EMRFS-Konfiguration verwendet wurde. `fs.s3.customAWSCredentialsProvider`

### EMRFS-Konfigurationen werden nicht unterstützt
<a name="emr-s3a-migration-unsupported"></a>

Die folgenden EMRFS-Konfigurationen wurden als nicht unterstützt oder veraltet identifiziert. Daher wird keine direkte Zuordnung zu ihren Gegenstücken in der S3A-Konfiguration bereitgestellt. Diese spezifischen Konfigurationen werden während der Migration in das S3A-Dateisystem nicht automatisch übersetzt oder übernommen.


**Nicht unterstützte EMRFS-Konfigurationen und Gründe**  
<a name="unsupported-emrfs-configs"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ReleaseGuide/emr-s3a-migrate.html)