

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.

# Leistungsoptimierung
<a name="EMRforDynamoDB.PerformanceTuning"></a>

Wenn Sie eine externe Hive-Tabelle erstellen, die einer DynamoDB-Tabelle zugeordnet ist, wird keine Lese- oder Schreibkapazität von DynamoDB belegt. Lese- und Schreibaktivitäten in der Hive-Tabelle (wie `INSERT` oder `SELECT`) wirken sich jedoch direkt als Lese- und Schreibvorgänge in der zugrunde liegenden DynamoDB-Tabelle aus.

Apache Hive auf Amazon EMR implementiert eine eigene Logik für den I/O Lastausgleich in der DynamoDB-Tabelle und versucht, die Möglichkeit zu minimieren, dass der bereitgestellte Durchsatz der Tabelle überschritten wird. Am Ende jeder Hive-Abfrage gibt Amazon EMR Laufzeitmetriken zurück, einschließlich der Anzahl von Überschreitungen des bereitgestellten Durchsatzes. Sie können diese Informationen zusammen mit CloudWatch Metriken in Ihrer DynamoDB-Tabelle verwenden, um die Leistung bei nachfolgenden Anfragen zu verbessern.

Die Amazon-EMR-Konsole bietet grundlegende Überwachungstools für Ihren Cluster. Weitere Informationen finden Sie unter [Anzeigen und Überwachen eines Clusters](https://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-manage-view.html) im *Managementleitfaden für Amazon EMR*.

Außerdem können Sie Ihren Cluster und Hadoop-Aufträge mithilfe von webbasierten Tools wie Hue und Ganglia sowie der Hadoop-Webschnittstelle überwachen. Weitere Informationen finden Sie unter [Anzeigen von auf Amazon-EMR-Clustern gehosteten Webschnittstellen](https://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-web-interfaces.html) im *Management Guide für Amazon EMR*.

In diesem Abschnitt werden Schritte beschrieben, wie Sie die Leistung von Hive-Operationen für externe DynamoDB-Tabellen optimieren können. 

**Topics**
+ [DynamoDB – Bereitgestellter Durchsatz](EMRforDynamoDB.PerformanceTuning.Throughput.md)
+ [Anpassen der Mapper](EMRforDynamoDB.PerformanceTuning.Mappers.md)
+ [Weitere Themen](EMRforDynamoDB.PerformanceTuning.Misc.md)

# DynamoDB – Bereitgestellter Durchsatz
<a name="EMRforDynamoDB.PerformanceTuning.Throughput"></a>

Wenn Sie HiveQL-Anweisungen für die externe DynamoDB-Tabelle erstellen, nimmt die Klasse `DynamoDBStorageHandler` die entsprechenden DynamoDB-Low-Level-API-Anforderungen vor, die den bereitgestellten Durchsatz verbrauchen. Wenn nicht genügend Lese- und Schreibkapazität für die DynamoDB-Tabelle zur Verfügung steht, wird die Anforderung gedrosselt und die HiveQL-Leistung so beeinträchtigt. Aus diesem Grund sollten Sie sicherstellen, dass die Tabelle über ausreichende Durchsatzkapazität verfügt.

Nehmen Sie zum Beispiel an, dass Sie 100 Lesekapazitätseinheiten für Ihre DynamoDB-Tabelle bereitgestellt haben. Mit dieser Kapazität können Sie 409 600 Byte pro Sekunde (100×4KB Lesekapazitätseinheitsgröße) lesen. Angenommen, die Tabelle enthält 20 GB Daten (21 474 836 480 Byte) und Sie möchten mit der `SELECT`-Anweisung alle Daten unter Verwendung von HiveQL auswählen. Sie können wie folgt schätzen, wie lange die Abfrage dauert:

 * 21 474 836 480/409 600 = 52 429 Sekunden = 14,56 Stunden * 

In diesem Szenario stellt die DynamoDB-Tabelle einen Engpass dar. Das Hinzufügen weiterer Amazon-EMR-Knoten würde keine Abhilfe schaffen, da der Hive-Durchsatz auf nur 409,600 Byte pro Sekunde beschränkt ist. Die einzige Möglichkeit, um die Bearbeitungsdauer der `SELECT`-Anweisung zu verkürzen, besteht darin, die bereitgestellte Lesekapazität der DynamoDB-Tabelle zu erhöhen. 

Sie können eine ähnliche Berechnung anstellen, um zu schätzen, wie lange es dauert, um Daten in eine externe Hive-Tabelle, die einer DynamoDB-Tabelle zugeordnet ist, massenzuladen. Ermitteln Sie die Gesamtzahl der pro Element benötigten Schreibkapazitätseinheiten (weniger als 1 KB = 1, 1 bis 2 KB = 2 usw.) und multiplizieren Sie diese mit der Anzahl der zu ladenden Elemente. Dadurch erhalten Sie die Anzahl der erforderlichen Schreibkapazitätseinheiten. Teilen Sie diese Anzahl von Schreibkapazitätseinheiten, die pro Sekunde zugewiesen werden. Daraus ergibt sich die Anzahl von Sekunden, die für das Laden der Tabelle benötigt wird.

Sie sollten die CloudWatch Metriken für Ihre Tabelle regelmäßig überwachen. Um einen kurzen Übersicht in der DynamoDB-Konsole zu erhalten, wählen Sie Ihre Tabelle und dann die Registerkarte **Metrics** aus. Hier können Sie verbrauchte Lese- und Schreibkapazitätseinheiten sowie gedrosselte Lese- und Schreibanforderungen einsehen.

## Lesekapazität
<a name="EMRforDynamoDB.PerformanceTuning.Throughput.ReadCapacity"></a>

Amazon EMR verwaltet die Anforderungslast für Ihre DynamoDB-Tabelle entsprechend der bereitgestellten Durchsatzeinstellungen der Tabelle. Wenn in der Auftragsausgabe eine große Zahl von `ProvisionedThroughputExceeded`-Nachrichten enthalten ist, können Sie die Standardleserate anpassen. Ändern Sie dazu die Konfigurationsvariable `dynamodb.throughput.read.percent`. Mit dem Befehl `SET` können Sie diese Variable an der Hive-Eingabeaufforderung festlegen:

```
1. SET dynamodb.throughput.read.percent=1.0;
```

Diese Variable gilt nur für die aktuelle Hive-Sitzung. Wenn Sie Hive beenden und später erneut aufrufen, erscheint für `dynamodb.throughput.read.percent` wieder der Standardwert.

Der Wert von `dynamodb.throughput.read.percent` kann einschließlich zwischen `0.1` und `1.5` sein. `0.5` stellt die Standardleserate dar. Dies bedeutet, dass Hive versucht, die Hälfte der Lesekapazität der Tabelle zu verbrauchen. Wenn Sie den Wert über `0.5` anheben, erhöht Hive die Anforderungsrate. Durch Senken des Werts unter `0.5` wird die Leseanforderungsrate verringert. (Die tatsächliche Leserate variiert abhängig von Faktoren wie der Tatsache, ob eine einheitliche Verteilung des Schlüssels in der DynamoDB-Tabelle vorliegt.)

Wenn Sie feststellen, dass Hive die bereitgestellte Lesekapazität der Tabelle häufig aufbraucht oder Ihre Leseanforderungen zu stark gedrosselt werden, versuchen Sie `dynamodb.throughput.read.percent` unter `0.5` zu reduzieren. Wenn die Lesekapazität der Tabelle ausreicht und Sie reaktionsfähigere HiveQL-Operationen wünschen, können Sie den Wert über `0.5` festlegen.

## Schreibkapazität
<a name="EMRforDynamoDB.PerformanceTuning.Throughput.WriteCapacity"></a>

Amazon EMR verwaltet die Anforderungslast für Ihre DynamoDB-Tabelle entsprechend der bereitgestellten Durchsatzeinstellungen der Tabelle. Wenn in der Auftragsausgabe eine große Zahl von `ProvisionedThroughputExceeded`-Nachrichten enthalten ist, können Sie die Standardschreibrate anpassen. Ändern Sie dazu die Konfigurationsvariable `dynamodb.throughput.write.percent`. Mit dem Befehl `SET` können Sie diese Variable an der Hive-Eingabeaufforderung festlegen:

```
1. SET dynamodb.throughput.write.percent=1.0;
```

Diese Variable gilt nur für die aktuelle Hive-Sitzung. Wenn Sie Hive beenden und später erneut aufrufen, erscheint für `dynamodb.throughput.write.percent` wieder der Standardwert.

Der Wert von `dynamodb.throughput.write.percent` kann einschließlich zwischen `0.1` und `1.5` sein. `0.5` stellt die Standardschreibrate dar. Dies bedeutet, dass Hive versucht, die Hälfte der Schreibkapazität der Tabelle zu verbrauchen. Wenn Sie den Wert über `0.5` anheben, erhöht Hive die Anforderungsrate. Durch Senken des Werts unter `0.5` wird die Schreibanforderungsrate verringert. (Die tatsächliche Schreibrate variiert abhängig von Faktoren wie der Tatsache, ob eine einheitliche Verteilung des Schlüssels in der DynamoDB-Tabelle vorliegt.)

Wenn Sie feststellen, dass Hive die bereitgestellte Schreibkapazität der Tabelle häufig aufbraucht oder Ihre Schreibanforderungen zu stark gedrosselt werden, versuchen Sie `dynamodb.throughput.write.percent` unter `0.5` zu reduzieren. Wenn die Kapazität der Tabelle ausreicht und Sie reaktionsfähigere HiveQL-Operationen wünschen, können Sie den Wert über `0.5` festlegen.

Wenn Sie mit Hive Daten in DynamoDB schreiben möchten, stellen Sie sicher, dass die Anzahl der Schreibkapazitätseinheiten größer als die Anzahl der Mapper im Cluster ist. Betrachten Sie z. B. einen Amazon-EMR-Cluster mit 10*m1.xlarge*-Knoten. Der Knotentyp *m1.xlarge* stellt 8 Mapper-Aufgaben bereit, sodass der Cluster insgesamt 80 Mapper (10 × 8) enthält. Wenn Ihre DynamoDB-Tabelle weniger als 80 Schreibkapazitätseinheiten umfasst, kann ein Hive-Schreibvorgang möglicherweise den gesamten Schreibdurchsatz für diese Tabelle aufbrauchen.

Um die Anzahl der Mapper für Amazon-EMR-Knotentypen zu ermitteln, lesen Sie den Abschnitt [Aufgabenkonfiguration](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hadoop-task-config.html) im *Amazon-EMR-Entwicklerhandbuch*.

Weitere Informationen zu Mappern finden Sie unter [Anpassen der Mapper](EMRforDynamoDB.PerformanceTuning.Mappers.md).

# Anpassen der Mapper
<a name="EMRforDynamoDB.PerformanceTuning.Mappers"></a>

Wenn Hive einen Hadoop-Auftrag startet, wird dieser von einer oder mehreren Mapper-Aufgaben verarbeitet. Unter der Voraussetzung, dass Ihre DynamoDB-Tabelle über genügend Durchsatzkapazität verfügt, können Sie die Anzahl von Mappern im Cluster ändern und die Leistung so möglicherweise verbessern.

**Anmerkung**  
Die Anzahl von Mapper-Aufgaben, die in einem Hadoop-Auftrag verwendet werden, wird von *Input Splits* beeinflusst, d. h. Hadoop teilt die Daten in logische Blöcke auf. Wenn Hadoop nicht genügend Input Splits vornimmt, können Ihre Schreibvorgänge möglicherweise nicht die gesamte Schreibdurchsatzkapazität der DynamoDB-Tabelle nutzen. 

## Erhöhen der Anzahl der Mapper
<a name="EMRforDynamoDB.PerformanceTuning.Mappers.Increasing"></a>

Jeder Mapper in einem Amazon EMR verfügt über eine maximale Leserate von 1 MiB pro Sekunde. Die Anzahl der Mapper in einem Cluster hängt von der Größe der Knoten in Ihrem Cluster ab. (Informationen über Knotengrößen und die Anzahl der Mapper pro Knoten finden Sie unter [Aufgabenkonfiguration](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hadoop-task-config.html) im *Amazon EMR-Entwicklerhandbuch*.)

Wenn Ihre DynamoDB-Tabelle über ausreichend Durchsatzkapazität für Lesevorgänge verfügt, können Sie versuchen, die Anzahl der Mapper erhöhen, indem Sie einen der folgenden Schritte ausführen:
+ Erhöhen Sie die Größe der Knoten in Ihrem Cluster. Wenn Ihr Cluster z. B. Knoten vom Typ *m1.large* (drei Mapper pro Knoten) verwendet, können Sie auf *m1.xlarge*-Knoten (acht Mapper pro Knoten) erhöhen.
+ Erhöhen Sie die Anzahl der Knoten in Ihrem Cluster. Wenn Sie z. B. über ein Drei-Knoten-Cluster mit *m1.xlarge*-Knoten verfügen, stehen insgesamt 24 Mapper zur Verfügung. Wenn Sie die Größe des Clusters mit demselben Knotentyp verdoppeln, erhalten Sie 48 Mapper.

Sie können den verwenden AWS-Managementkonsole , um die Größe oder Anzahl der Knoten in Ihrem Cluster zu verwalten. (Sie müssen den Cluster möglicherweise neu starten, damit diese Änderungen wirksam werden.)

Eine andere Möglichkeit, die Anzahl der Mapper zu erhöhen, besteht darin, den `mapred.tasktracker.map.tasks.maximum` Hadoop-Konfigurationsparameter zu ändern. (Dies ist ein Hadoop- und kein Hive-Parameter. Sie können ihn nicht interaktiv an der Eingabeaufforderung ändern.) Wenn Sie den Wert `mapred.tasktracker.map.tasks.maximum` erhöhen, steigern Sie die Anzahl der Mapper ohne die Größe oder Anzahl der Knoten zu ändern. Allerdings kann es passieren, dass der Speicherplatz der Cluster-Knoten nicht mehr ausreicht, wenn Sie den Wert zu hoch festlegen.

Sie legen den Wert für `mapred.tasktracker.map.tasks.maximum` als Bootstrap-Aktion fest, wenn Sie Ihren Amazon-EMR-Cluster das erste Mal starten. Weitere Informationen finden Sie unter [(Optional) Erstellen von Bootstrap-Aktionen zum Installieren zusätzlicher Software](https://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-bootstrap.html) im *Management Guide für Amazon EMR*.

## Reduzieren der Anzahl der Mapper
<a name="EMRforDynamoDB.PerformanceTuning.Mappers.Decreasing"></a>

Wenn Sie die `SELECT`-Anweisung verwenden, um Daten aus einer externen Hive-Tabelle auszuwählen, die DynamoDB zugeordnet ist, kann der Hadoop-Auftrag so viele Aufgaben nutzen wie erforderlich, und zwar bis zur maximalen Anzahl der Mapper im Cluster. In diesem Szenario ist es möglich, dass eine zeitaufwändige Hive-Abfrage die gesamte bereitgestellte Lesekapazität der DynamoDB-Tabelle nutzt, was negative Auswirkungen auf andere Benutzer hat.

Sie können den Parameter `dynamodb.max.map.tasks` nutzen, ob eine Obergrenze für Zuordnungsaufgaben festzulegen:

```
SET dynamodb.max.map.tasks=1
```

Dieser Wert muss gleich oder größer 1 sein. Wenn Hive Ihre Abfrage verarbeitet, verbraucht der entsprechende Hadoop-Auftrag beim Lesen aus der DynamoDB-Tabelle nicht mehr als `dynamodb.max.map.tasks`.

# Weitere Themen
<a name="EMRforDynamoDB.PerformanceTuning.Misc"></a>

Im Folgenden werden weitere Möglichkeiten zum Optimieren von Anwendungen beschrieben, die Hive für den Zugriff auf DynamoDB verwenden.

## Retry duration
<a name="EMRforDynamoDB.PerformanceTuning.Misc.RetryDuration"></a>

Standardmäßig führt Hive einen Hadoop-Auftrag erneut aus, wenn innerhalb von zwei Minuten keine Ergebnisse von DynamoDB zurückgegeben werden. Sie können diesen Zeitraum durch Ändern des Parameters `dynamodb.retry.duration` anpassen:

```
1. SET dynamodb.retry.duration=2;
```

Der Wert muss eine Ganzzahl ungleich Null sein, die die Anzahl der Minuten im Wiederholungsintervall darstellt. Der Standardwert für `dynamodb.retry.duration` ist 2 (Minuten).

## Parallele Datenanforderungen
<a name="EMRforDynamoDB.PerformanceTuning.Misc.ParallelDataRequests"></a>

Mehrere Datenanforderungen, entweder von mehr als einem Benutzer oder mehr als einer Anwendung, an eine einzelne Tabelle kann den bereitgestellten Lesedurchsatz erschöpfen und die Leistung beeinträchtigen. 

## Prozessdauer
<a name="EMRforDynamoDB.PerformanceTuning.Misc.ProcessDuration"></a>

Die Datenkonsistenz in DynamoDB hängt von der Reihenfolge der Lese- und Schreibvorgänge auf den einzelnen Knoten ab. Während eine Hive-Abfrage verarbeitet wird, kann eine andere Anwendung neue Daten in die DynamoDB-Tabelle laden oder vorhandene Daten ändern oder löschen. In diesem Fall enthalten die Ergebnisse der Hive-Abfrage möglicherweise nicht die Datenänderungen, die vorgenommen wurden, während die Abfrage ausgeführt wurde. 

## Abfragezeit
<a name="EMRforDynamoDB.PerformanceTuning.Misc.RequestTime"></a>

Wenn Hive-Abfragen, die auf eine DynamoDB-Tabelle zugreifen, für Zeiten geplant werden, in denen wenig Anforderungen an die DynamoDB-Tabelle gerichtet werden, verbessert das die Leistung. Beispiel: Wenn die Mehrzahl der Benutzer Ihrer Anwendung in Hamburg leben, können Sie die täglichen Daten um 04:00 Uhr MEZ exportieren, wenn die meisten Benutzer schlafen und keine Datensätze in Ihrer DynamoDB-Datenbank aktualisieren. 

