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. # Schema-Updates verarbeiten In diesem Abschnitt finden Sie Anleitungen zum Umgang mit Schema-Updates für verschiedene Datenformate. Athena ist eine schema-on-read Abfrage-Engine. Dies bedeutet, dass beim Anlegen einer Tabelle in Athena Schemata beim Lesen der Daten angewendet werden. Dabei werden die zugrunde liegenden Daten nicht geändert oder überschrieben. Wenn Sie Änderungen in Tabellenschemata vorweg nehmen, sollten Sie diese in einem für Ihre Bedürfnisse geeigneten Datenformat anlegen. Ihr Ziel ist es, vorhandene Athena-Abfragen bei sich weiterentwickelnden Schemata wiederzuverwenden und beim Abfragen von Tabellen mit Partitionen Fehler aufgrund von Schemakonflikten zu vermeiden. Um diese Ziele zu erreichen, wählen Sie das Datenformat basierend auf der Tabelle im folgenden Thema. **Topics** + [Unterstützte Schemaaktualisierungs-Operationen nach Datenformat](#summary-of-updates) + [Indexzugriff für Apache ORC und Apache Parquet verstehen](#index-access) + [Schemaaktualisierungen vornehmen](make-schema-updates.md) + [Tabellen mit Partitionen aktualisieren](updates-and-partitions.md) ## Unterstützte Schemaaktualisierungs-Operationen nach Datenformat Die folgende Tabelle enthält eine Übersicht über die Datenspeicherungsformate und ihre unterstützten Schema-Manipulationen. Verwenden Sie diese Tabelle, um das Format zu wählen, mit dem Sie weiterhin Athena-Abfragen verwenden können, auch wenn sich Ihre Schemata im Lauf der Zeit ändern. Beachten Sie, dass Parquet und ORC in dieser Tabelle Spaltenformate mit unterschiedlichen Standard-Spaltenzugriffsmethoden sind. Standardmäßig greift Parquet dem Namen nach auf Spalten zu, ORC dem Index nach (Ordnungswert). Daher stellt Athena eine SerDe Eigenschaft bereit, die beim Erstellen einer Tabelle definiert wird, um die Standardmethode für den Spaltenzugriff umzuschalten, was eine größere Flexibilität bei der Schemaentwicklung ermöglicht. Für Parquet kann die `parquet.column.index.access`-Eigenschaft auf `true` gesetzt werden, sodass die Spaltenzugriffsmethode die Ordinalzahl für die Spalte verwendet. Wenn Sie diese Eigenschaft auf `false` setzen, ändert sich die Spaltenzugriffsmethode auf die Verwendung des Spaltennamens. Analog dazu verwenden Sie für ORC die `orc.column.index.access` -Eigenschaft, um die Spaltenzugriffsmethode festzulegen. Weitere Informationen finden Sie unter [Indexzugriff für Apache ORC und Apache Parquet verstehen](#index-access). Mit CSV und TSV können Sie alle Schema-Manipulationen durchführen, mit Ausnahme der Neuanordnung von Spalten oder des Hinzufügens von Spalten am Anfang der Tabelle. Wenn Ihre Schemaentwicklung z. B. nur das Umbenennen von Spalten, nicht aber deren Entfernung erfordert, können Sie Ihre Tabellen in CSV oder TSV erstellen. Wenn Sie Spalten entfernen möchten, verwenden Sie nicht CSV oder TSV, sondern eines der anderen unterstützten Formate, vorzugsweise ein Spaltenformat wie Parquet oder ORC. **Schema-Updates und Datenformate in Athena** | Erwarteter Typ des Schema-Updates | Zusammenfassung | CSV (mit und ohne Header) und TSV | JSON | AVRO | PARQUET: Lesen nach Namen (Standard) | PARQUET: Lesen nach Index | ORC: Lesen nach Index (Standard) | ORC: Lesen nach Namen | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | [Spalten umbenennen](updates-renaming-columns.md) | Speichern Sie Ihre Daten in CSV und TSV oder in ORC und Parquet, wenn sie nach dem Index gelesen werden. | Y | N | N | N | Y | Y | N | | [Hinzufügen von Spalten am Anfang oder in der Mitte der Tabelle](updates-add-columns-beginning-middle-of-table.md) | Speichern Sie Ihre Daten in JSON, AVRO oder in Parquet und ORC, wenn sie nach dem Namen gelesen werden. Verwenden Sie nicht CSV und TSV. | N | Y | Y | Y | N | N | Y | | [Hinzufügen von Spalten am Ende der Tabelle](updates-add-columns-end-of-table.md) | Speichern Sie Ihre Daten im CSV-, TSV-, JSON-, AVRO-, ORC- oder Parquet-Format. | Y | Y | Y | Y | Y | Y | Y | | [Spalten entfernen](updates-removing-columns.md) | Speichern Sie Ihre Daten in JSON, AVRO oder in Parquet und ORC, wenn sie nach dem Namen gelesen werden. Verwenden Sie nicht CSV und TSV. | N | Y | Y | Y | N | N | Y | | [Neuanordnen von Spalten](updates-reordering-columns.md) | Speichern Sie Ihre Daten in AVRO, JSON oder ORC und Parquet, wenn sie nach dem Namen gelesen werden. | N | Y | Y | Y | N | N | Y | | [Ändern des Datentyps einer Spalte](updates-changing-column-type.md) | Speichern Sie Ihre Daten in einem beliebigen Format, testen Sie Ihre Abfrage jedoch in Athena, um sicherzustellen, dass die Datentypen kompatibel sind. Für Parquet und ORC ist eine Änderung des Datentyps nur für partitionierte Tabellen möglich. | Y | Y | Y | Y | Y | Y | Y | ## Indexzugriff für Apache ORC und Apache Parquet verstehen PARQUET und ORC sind spaltenbasierte Dateiformaten, die nach Index gelesen werden können, oder nach Namen. Wenn Sie Ihre Daten in einem dieser Formate speichern, können Sie alle Operationen an Schemata durchführen und Athena-Abfragen ohne Schema-Fehler ausführen. + Athena *liest ORC standardmäßig nach dem Index*, wie in `SERDEPROPERTIES ( 'orc.column.index.access'='true')` definiert. Weitere Informationen finden Sie unter [ORC: Lesen nach Index](#orc-read-by-index). + Athena liest *Parquet standardmäßig nach dem Namen*, wie in `SERDEPROPERTIES ( 'parquet.column.index.access'='false')` definiert. Weitere Informationen finden Sie unter [Parquet: Lesen nach Namen](#parquet-read-by-name). Da es sich um Standardwerte handelt, ist die Angabe dieser SerDe Eigenschaften in Ihren `CREATE TABLE` Abfragen optional, sie werden implizit verwendet. Wenn sie verwendet werden, gestatten sie Ihnen die Ausführung einiger Schema-Update-Operationen, während sie andere solcher Operationen verhindern. Um diese Operationen zu aktivieren, führen Sie eine weitere `CREATE TABLE` Abfrage aus und ändern Sie die SerDe Einstellungen. **Anmerkung** Die SerDe Eigenschaften werden *nicht* automatisch auf jede Partition übertragen. Verwenden Sie `ALTER TABLE ADD PARTITION` Anweisungen, um die SerDe Eigenschaften für jede Partition festzulegen. Um diesen Prozess zu automatisieren, schreiben Sie ein Skript, das `ALTER TABLE ADD PARTITION`-Anweisungen ausführt. In den folgenden Abschnitten werden diese Fälle ausführlich beschrieben. ### ORC: Lesen nach Index Eine Tabelle wird in *ORC standardmäßig nach dem Index gelesen*. Dies wird durch die folgende Syntax definiert: ``` WITH SERDEPROPERTIES ( 'orc.column.index.access'='true') ``` *Lesen nach Index* erlaubt, die Spalten umzubenennen. Sie verlieren damit jedoch die Möglichkeit, Spalten zu entfernen oder in der Mitte der Tabelle hinzuzufügen. Damit ORC nach Namen gelesen wird, was es Ihnen ermöglicht, Spalten in der Mitte der Tabelle hinzuzufügen oder Spalten in ORC zu entfernen, setzen Sie die SerDe Eigenschaft `false` in der `orc.column.index.access` `CREATE TABLE` Anweisung auf. In dieser Konfiguration verlieren Sie die Möglichkeit, Spalten umzubenennen. **Anmerkung** Wenn in Athena-Engine-Version 2 ORC-Tabellen so eingestellt sind, dass sie nach Namen lesen, erfordert Athena, dass alle Spaltennamen in den ORC-Dateien in Kleinbuchstaben sind. Da Apache Spark beim Generieren von ORC-Dateien keine Feldnamen in Kleinbuchstaben enthält, kann Athena die so generierten Daten möglicherweise nicht lesen. Die Abhilfe besteht darin, die Spalten in Kleinbuchstaben umzubenennen oder Athena-Engine-Version 3 zu verwenden. Das folgende Beispiel zeigt, wie Sie die ORC abändern, um nach Namen zu lesen: ``` CREATE EXTERNAL TABLE orders_orc_read_by_name ( `o_comment` string, `o_orderkey` int, `o_custkey` int, `o_orderpriority` string, `o_orderstatus` string, `o_clerk` string, `o_shippriority` int, `o_orderdate` string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.orc.OrcSerde' WITH SERDEPROPERTIES ( 'orc.column.index.access'='false') STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/orders_orc/'; ``` ### Parquet: Lesen nach Namen Eine Tabelle wird in *Parquet standardmäßig nach dem Namen gelesen*. Dies wird durch die folgende Syntax definiert: ``` WITH SERDEPROPERTIES ( 'parquet.column.index.access'='false') ``` *Lesen nach Namen* ermöglicht Ihnen das Hinzufügen von Spalten in der Mitte der Tabelle und das Entfernen von Spalten. Aber dann verlieren Sie die Möglichkeit, Spalten umzubenennen. Um Parquet nach Index lesen zu lassen, sodass Sie Spalten umbenennen können, müssen Sie eine Tabelle mit der `parquet.column.index.access` SerDe Eigenschaft auf erstellen. `true` # Schemaaktualisierungen vornehmen In diesem Thema werden einige der Änderungen beschrieben, die Sie in `CREATE TABLE`-Anweisungen am Schema vornehmen können, ohne Ihre Daten tatsächlich zu ändern. Um ein Schema zu aktualisieren, können Sie in einigen Fällen einen `ALTER TABLE`-Befehl verwenden, in anderen Fällen ändern Sie jedoch nicht wirklich eine vorhandene Tabelle. Stattdessen erstellen Sie eine Tabelle mit einem neuen Namen, der das Schema ändert, das Sie in Ihrer ursprünglichen `CREATE TABLE`-Anweisung verwendet haben. Je nachdem, wie sich Ihre Schemata voraussichtlich weiterentwickeln, verwenden Sie ein kompatibles Datenformat, um weiterhin Athena-Abfragen verwenden zu können. Untersuchen wir als Erstes eine Anwendung, in der Bestellinformationen aus einer `orders`-Tabelle gelesen werden, die in zwei Formaten existiert: CSV und Parquet. Mit dem folgenden Beispiel wird eine Tabelle in Parquet erstellt: ``` CREATE EXTERNAL TABLE orders_parquet ( `orderkey` int, `orderstatus` string, `totalprice` double, `orderdate` string, `orderpriority` string, `clerk` string, `shippriority` int ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_ parquet/'; ``` Mit dem folgenden Beispiel wird die gleiche Tabelle in CSV erstellt: ``` CREATE EXTERNAL TABLE orders_csv ( `orderkey` int, `orderstatus` string, `totalprice` double, `orderdate` string, `orderpriority` string, `clerk` string, `shippriority` int ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION 's3://amzn-s3-demo-bucket/orders_csv/'; ``` Folgende Themen zeigen wie sich Aktualisierungen für diese Tabellen auf Athena-Abfragen auswirken. **Topics** + [Hinzufügen von Spalten am Anfang oder in der Mitte der Tabelle](updates-add-columns-beginning-middle-of-table.md) + [Hinzufügen von Spalten am Ende der Tabelle](updates-add-columns-end-of-table.md) + [Spalten entfernen](updates-removing-columns.md) + [Spalten umbenennen](updates-renaming-columns.md) + [Neuanordnen von Spalten](updates-reordering-columns.md) + [Datentyp einer Spalte ändern](updates-changing-column-type.md) # Hinzufügen von Spalten am Anfang oder in der Mitte der Tabelle Das Hinzufügen von Spalten ist eine der am häufigsten vorkommenden Schemaänderungen. Beispielsweise können Sie eine neue Spalte hinzufügen, um die Tabelle um neue Daten zu erweitern. Alternativ können Sie eine neue Spalte hinzufügen, wenn sich die Quelle für eine vorhandene Spalte geändert hat, und die vorherige Version dieser Spalte beibehalten. So haben Sie Zeit, Anwendungen anzupassen, die von dieser Spalte abhängig sind. Um Spalten am Anfang oder in der Mitte der Tabelle hinzuzufügen und weiterhin Abfragen für bestehende Tabellen auszuführen, verwenden Sie AVRO, JSON sowie Parquet und ORC, wenn deren SerDe Eigenschaft auf Lesen nach Namen gesetzt ist. Weitere Informationen finden Sie unter [Indexzugriff für Apache ORC und Apache Parquet verstehen](handling-schema-updates-chapter.md#index-access). Fügen Sie keine Spalten am Anfang oder in der Mitte der Tabelle in CSV und TSV hinzu, da diese Formate von der Reihenfolge abhängen. Das Hinzufügen einer Spalte führt in diesen Fällen zu Schemakonflikten, falls sich das Schema der Partitionen ändert. Im folgenden Beispiel wird eine neue Tabelle erstellt, die eine `o_comment`-Spalte in der Mitte einer auf JSON-Daten basierenden Tabelle hinzufügt. ``` CREATE EXTERNAL TABLE orders_json_column_addition ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_comment` string, `o_totalprice` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' LOCATION 's3://amzn-s3-demo-bucket/orders_json/'; ``` # Hinzufügen von Spalten am Ende der Tabelle Wenn Sie Tabellen in einem der von Athena unterstützten Formate wie Parquet, ORC, Avro, JSON, CSV und TSV erstellen, können Sie mit der `ALTER TABLE ADD COLUMNS`-Anweisung Spalten nach vorhandenen Spalten, aber vor Partitionsspalten hinzufügen. Im folgenden Beispiel wird eine `comment`-Spalte am Ende der `orders_parquet`-Tabelle vor allen Partitionsspalten hinzugefügt: ``` ALTER TABLE orders_parquet ADD COLUMNS (comment string) ``` **Anmerkung** Um im Athena-Abfrage-Editor nach der Ausführung von `ALTER TABLE ADD COLUMNS` eine neue Tabellenspalte anzuzeigen, aktualisieren Sie die Tabellenliste im Editor manuell und erweitern die Tabelle anschließend erneut. # Spalten entfernen Möglicherweise müssen Sie Spalten aus Tabellen entfernen, wenn sie keine Daten mehr enthalten, oder zum Einschränken des Zugriffs auf die darin enthaltenen Daten. + Sie können Spalten aus Tabellen in JSON, Avro und Parquet und ORC entfernen, wenn diese dem Namen nach lesen. Weitere Informationen finden Sie unter [Indexzugriff für Apache ORC und Apache Parquet verstehen](handling-schema-updates-chapter.md#index-access). + Wir raten davon ab, Spalten aus Tabellen in CSV und TSV zu entfernen, wenn Sie die Tabellen, die Sie bereits in Athena angelegt haben, beibehalten möchten. Das Entfernen einer Spalte stört das Schema und erfordert, dass Sie die Tabelle ohne die entfernte Spalte neu anlegen. In diesem Beispiel entfernen Sie eine Spalte ``totalprice`` aus einer Tabelle in Parquet und führen eine Abfrage aus. In Athena wird Parquet standardmäßig dem Namen nach gelesen. Deshalb lassen wir die Konfiguration SERDEPROPERTIES weg, die das Lesen dem Namen nach angibt. Beachten Sie, dass die folgende Abfrage erfolgreich ist, obwohl Sie das Schema geändert haben: ``` CREATE EXTERNAL TABLE orders_parquet_column_removed ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_parquet/'; ``` # Spalten umbenennen Möglicherweise möchten Sie in Ihren Tabellen Spalten umbenennen, um die Schreibweise zu korrigieren, Spalten mit besser verständlichen Namen zu versehen oder eine vorhandene Spalte erneut nutzen, um eine Änderung der Reihenfolge für die Spalten zu vermeiden. Sie können Spalten umbenennen, wenn Sie Ihre Daten in CSV und TSV speichern, oder in Parquet und ORC, wenn diese so konfiguriert sind, dass sie dem Index nach lesen. Weitere Informationen finden Sie unter [Indexzugriff für Apache ORC und Apache Parquet verstehen](handling-schema-updates-chapter.md#index-access). Athena liest Daten in CSV und TSV in der Reihenfolge der Spalten in das Schema und gibt sie in der gleichen Reihenfolge aus. Hierbei werden keine Spaltennamen für das Mapping von Daten in einer Spalte verwendet. Aus diesem Grund können Sie keine Spalten in CSV oder TSV umbenennen, ohne Athena-Abfragen zu beschädigen. Eine Strategie zum Umbenennen von Spalten besteht darin, eine neue Tabelle zu erstellen, die auf denselben zugrunde liegenden Daten basiert, jedoch unter Verwendung neuer Spaltennamen. Im folgenden Beispiel wird eine neue `orders_parquet`-Tabelle `orders_parquet_column_renamed`erstellt. Im Beispiel wird der Spaltenname ``o_totalprice`` zu ``o_total_price`` und führt dann eine Abfrage in Athena aus: ``` CREATE EXTERNAL TABLE orders_parquet_column_renamed ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_total_price` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_parquet/'; ``` Im Fall der Parquet-Tabelle wird die folgende Abfrage erfolgreich ausgeführt, aber die umbenannte Spalte zeigt keine Daten an, da auf die Spalte nicht über den Index, sondern über den Namen zugegriffen wurde (ein Standard in Parquet): ``` SELECT * FROM orders_parquet_column_renamed; ``` Eine Abfrage mit einer Tabelle in CSV sieht ähnlich aus: ``` CREATE EXTERNAL TABLE orders_csv_column_renamed ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_total_price` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION 's3://amzn-s3-demo-bucket/orders_csv/'; ``` Bei der CSV-Tabelle wird die folgende Abfrage ausgeführt und für alle Spalten erscheinen Daten, auch für die umbenannte Spalte: ``` SELECT * FROM orders_csv_column_renamed; ``` # Neuanordnen von Spalten Sie können Spalten nur für Tabellen mit Daten in Formaten neu anordnen, die dem Namen nach lesen, wie JSON oder Parquet, die standardmäßig dem Namen nach lesen. Sie können ORC bei Bedarf auch nach Namen lesen lassen. Weitere Informationen finden Sie unter [Indexzugriff für Apache ORC und Apache Parquet verstehen](handling-schema-updates-chapter.md#index-access). Das folgende Beispiel erstellt eine neue Tabelle mit den Spalten in einer anderen Reihenfolge: ``` CREATE EXTERNAL TABLE orders_parquet_columns_reordered ( `o_comment` string, `o_orderkey` int, `o_custkey` int, `o_orderpriority` string, `o_orderstatus` string, `o_clerk` string, `o_shippriority` int, `o_orderdate` string ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_parquet/'; ``` # Datentyp einer Spalte ändern Möglicherweise möchten Sie einen anderen Spaltentyp verwenden, wenn der vorhandene Typ nicht mehr die erforderliche Menge an Informationen aufnehmen kann. Beispielsweise könnten die Werte einer ID-Spalte die Größe des `INT`-Datentyps überschreiten und die Verwendung des `BIGINT`-Datentyps erfordern. ## Überlegungen Berücksichtigen Sie bei der Verwendung eines anderen Datentyps für eine Spalte die folgenden Punkte: + In den meisten Fällen können Sie den Datentyp einer Spalte nicht direkt ändern. Stattdessen erstellen Sie die Athena-Tabelle neu und definieren die Spalte mit dem neuen Datentyp. + Nur bestimmte Datentypen können als andere Datentypen gelesen werden. In der Tabelle in diesem Abschnitt finden Sie die Datentypen, die so behandelt werden können. + Für Daten in Parquet und ORC können Sie keinen anderen Datentyp für eine Spalte verwenden, wenn die Tabelle nicht partitioniert ist. + In partitionierten Tabellen in Parquet und ORC kann sich der Spaltentyp einer Partition vom Spaltentyp einer anderen Partition unterscheiden und Athena wendet `CAST` auf den gewünschten Typ an, wenn dies möglich ist. Weitere Informationen finden Sie unter [Vermeiden von Schemakonflikt-Fehlern für Tabellen mit Partitionen](updates-and-partitions.md#partitions-dealing-with-schema-mismatch-errors). + Bei Tabellen, die [LazySimpleSerDe](lazy-simple-serde.md)nur mit der Anweisung erstellt wurden, ist es möglich, die `ALTER TABLE REPLACE COLUMNS` Anweisung zu verwenden, um vorhandene Spalten durch einen anderen Datentyp zu ersetzen. Alle vorhandenen Spalten, die Sie behalten möchten, müssen jedoch ebenfalls in der Anweisung neu definiert werden, andernfalls werden sie gelöscht. Weitere Informationen finden Sie unter [ALTER TABLE REPLACE COLUMNS](alter-table-replace-columns.md). + Nur für Apache-Iceberg-Tabellen können Sie die [ALTER TABLE CHANGE COLUMN](querying-iceberg-alter-table-change-column.md)-Anweisung verwenden, um den Datentyp einer Spalte zu ändern. `ALTER TABLE REPLACE COLUMNS` wird für Iceberg-Tabellen nicht unterstützt. Weitere Informationen finden Sie unter [Iceberg-Tabellenschema weiterentwickeln](querying-iceberg-evolving-table-schema.md). **Wichtig** Wir raten Ihnen dringend, Ihre Abfragen zu testen und zu überprüfen, bevor Sie Datentyp-Änderungen vornehmen. Wenn Athena den Zieldatentyp nicht verwenden kann, schlägt die `CREATE TABLE`-Abfrage möglicherweise fehl. ## Kompatible Datentypen verwenden Verwenden Sie nach Möglichkeit kompatible Datentypen. In der folgenden Tabelle sind Datentypen aufgeführt, die wie andere Datentypen behandelt werden können: | Original-Datentyp | Verfügbare Ziel-Datentypen | | --- | --- | | STRING | BYTE, TINYINT, SMALLINT, INT, BIGINT | | BYTE | TINYINT, SMALLINT, INT, BIGINT | | TINYINT | SMALLINT, INT, BIGINT | | SMALLINT | INT, BIGINT | | INT | BIGINT | | FLOAT | DOUBLE | Im folgenden Beispiel wird die `CREATE TABLE`-Anweisung für die `orders_json`-Originaltabelle verwendet, um eine neue Tabelle mit dem Namen `orders_json_bigint` zu erstellen. Die neue Tabelle verwendet `BIGINT` statt `INT` als Datentyp für die ``o_shippriority``-Spalte. ``` CREATE EXTERNAL TABLE orders_json_bigint ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_totalprice` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` BIGINT ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' LOCATION 's3://amzn-s3-demo-bucket/orders_json'; ``` Die folgende Abfrage wird erfolgreich ausgeführt, ähnlich wie die `SELECT`-Originalabfrage vor dem Ändern des Datentyps: ``` Select * from orders_json LIMIT 10; ``` # Tabellen mit Partitionen aktualisieren In Athena müssen eine Tabelle und ihre Partitionen die gleichen Datenformate verwenden, ihre Schemata können aber unterschiedlich sein. Wenn Sie eine neue Partition erstellen, erbt die Partition in der Regel das Schema der Tabelle. Im Laufe der Zeit können sich die Schemas ggf. unterscheiden. Gründe sind u. a.: + Wenn sich das Schema der Tabelle ändert, werden die Schemas für Partitionen nicht aktualisiert, um weiterhin dem Schema der Tabelle zu entsprechen. + Der AWS Glue Crawler ermöglicht es Ihnen, Daten in Partitionen mit unterschiedlichen Schemas zu entdecken. Das heißt, wenn Sie eine Tabelle in Athena mit erstellen AWS Glue, nachdem der Crawler die Verarbeitung abgeschlossen hat, können die Schemas für die Tabelle und ihre Partitionen unterschiedlich sein. + Wenn Sie Partitionen direkt über eine API hinzufügen. AWS Athena verarbeitet Tabellen mit Partitionen erfolgreich, wenn sie die folgenden Beschränkungen erfüllen. Wenn diese Beschränkungen nicht erfüllt sind, gibt Athena einen HIVE\$1PARTITION\$1SCHEMA\$1MISMATCH-Fehler aus. + Das Schema jeder Partition ist kompatibel mit dem Tabellenschema. + Das Datenformat der Tabelle ermöglicht die Art der Aktualisierung, die Sie ausführen möchten: Spalten hinzufügen, löschen, ihre Reihenfolge ändern oder den Datentyp einer Spalte ändern. Beispiel: In den Formaten CSV und TSV können Sie Spalten umbenennen, neue Spalten am Ende der Tabelle hinzufügen und den Datentyp einer Spalte ändern, falls die Typen kompatibel sind. Sie können aber keine Spalten entfernen. Bei anderen Formaten können Sie Spalten hinzufügen oder entfernen oder den Datentyp in einen anderen ändern, wenn die Typen kompatibel sind. Weitere Informationen finden Sie unter [Zusammenfassung: Updates und Datenformate in Athena](handling-schema-updates-chapter.md#summary-of-updates). ## Vermeiden von Schemakonflikt-Fehlern für Tabellen mit Partitionen Zu Beginn der Abfrageausführung überprüft Athena das Schema einer Tabelle, indem überprüft wird, dass der Datentyp jeder Spalte in der Tabelle und der Partition kompatibel ist. + Für Parquet- und ORC-Datenspeichertypen stützt sich Athena auf die Spaltennamen und verwendet sie für die auf Spaltennamen basierte Überprüfung des Schemas. Dadurch werden `HIVE_PARTITION_SCHEMA_MISMATCH`-Fehler für Tabellen mit Partitionen in Parquet und ORC verhindert. (Dies gilt für ORC, wenn die SerDe Eigenschaft so eingestellt ist, dass sie namentlich auf den Index zugreift:`orc.column.index.access=FALSE`. Parquet liest den Index standardmäßig nach Namen). + Für CSV, JSON und Avro verwendet Athena eine Index-basierte Schemaverifizierung. Das bedeutet: Wenn bei Ihnen ein Schemakonflikt-Fehler auftritt, sollten Sie die Partition löschen, die einen Schemakonflikt auslöst, und sie erneut erstellen. So kann Athena sie ohne Fehler abfragen. Athena vergleicht das Schema der Tabelle mit den Partitionsschemata. Wenn Sie mit AWS Glue Crawler eine Tabelle in CSV, JSON und AVRO in Athena erstellen, können die Schemas für die Tabelle und ihre Partitionen nach Abschluss der Verarbeitung durch den Crawler unterschiedlich sein. Tritt ein Konflikt zwischen dem Tabellen- und dem Partitionsschema auf, scheitern Ihre Abfragen in Athena wegen eines Fehlers beim Überprüfen des Schemas, ähnlich dem Folgenden: „‚crawler\$1test.click\$1avro‘ ist als Typ ‚string‘ deklariert, in der Partition ‚partition\$10=2017-01-17‘ ist die Spalte ‚col68‘ aber mit dem Typ ‚double‘ deklariert.“ Eine typische Behelfslösung für diesen Fehler besteht darin, dass die Partition entfernt wird, die den Fehler auslöst, und Sie sie dann erneut erstellen. Weitere Informationen erhalten Sie unter [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md) und [ALTER TABLE ADD PARTITION](alter-table-add-partition.md).