Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Gestire gli aggiornamenti degli schemi Questa sezione fornisce delle linee guida su come gestire gli aggiornamenti degli schemi per vari formati di dati. Athena è un motore di schema-on-read interrogazione. Ciò significa che quando si crea una tabella in Athena, applica schemi durante la lettura dei dati. Non modifica né riscrive i dati sottostanti. Se si prevedono delle modifiche agli schemi tabella, è consigliabile crearli in un formato di dati idoneo alle proprie esigenze. Il tuo obiettivo è riutilizzare query Athena esistenti anziché modificare gli schemi, evitando così errori di mancata corrispondenza tra gli schemi durante l'esecuzione di query su tabelle con partizioni. Per raggiungere questi obiettivi, scegli un formato di dati della tabella in base alla tabella nell'argomento seguente. **Topics** + [ ## Operazioni di aggiornamento degli schemi supportate in base al formato dei dati ](#summary-of-updates) + [ ## Comprendere l’accesso agli indici per Apache ORC e Apache Parquet ](#index-access) + [ # Effettuare aggiornamenti degli schemi ](make-schema-updates.md) + [ # Aggiornare tabelle con partizioni ](updates-and-partitions.md) ## Operazioni di aggiornamento degli schemi supportate in base al formato dei dati La tabella seguente riepiloga i formati di storage dei dati e le relative manipolazioni supportate per gli schemi. Utilizza questa tabella per scegliere più facilmente il formato che ti consenta di continuare a utilizzare le query Athena anche man mano che i tuoi schemi cambiano nel corso del tempo. In questa tabella, osserva che Parquet e ORC sono formati di colonna con diversi metodi di accesso predefiniti alle colonne. Per impostazione predefinita, Parquet accederà alle colonne in base al nome, mentre ORC in base all'indice (valore ordinale). Pertanto, Athena fornisce una SerDe proprietà definita durante la creazione di una tabella per attivare il metodo di accesso alle colonne predefinito che consente una maggiore flessibilità con l'evoluzione dello schema. Per Parquet, la proprietà `parquet.column.index.access` può essere configurata su `true`, impostando così il metodo di accesso alle colonne in base al numero ordinale della colonna. Impostando questa proprietà su `false`, il metodo di accesso alle colonne cambierà, impiegando il nome della colonna. Analogamente, per ORC utilizza la proprietà `orc.column.index.access` per controllare il metodo di accesso alle colonne. Per ulteriori informazioni, consulta [Comprendere l’accesso agli indici per Apache ORC e Apache Parquet](#index-access). CSV e TSV consentono di eseguire qualsiasi manipolazione degli schemi, eccetto il riordinamento di colonne o l'aggiunta di colonne all'inizio della tabella. Ad esempio, se l'evoluzione del tuo schema richiede solo la ridenominazione delle colonne ma non la loro rimozione, è puoi decidere di creare le tabelle in CSV o TSV. Se è invece necessaria la rimozione di colonne, non utilizzare CSV o TSV, ma impiega invece uno qualsiasi degli altri formati supportati, preferibilmente un formato di colonna, ad esempio ORC o Parquet. **Aggiornamenti di schemi e formati di dati in Athena** | Aggiornamento tipo di schema atteso | Riepilogo | CSV (con e senza intestazioni) e TSV | JSON | AVRO | PARQUET: lettura in base al nome (predefinito) | PARQUET: lettura in base a indice | ORC: lettura in base a indice (predefinito) | ORC: lettura in base al nome | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | [Rinomina colonne](updates-renaming-columns.md) | Archivia i tuoi dati in CSV e TSV oppure in ORC e Parquet se vengono letti in base all'indice. | Y | N | N | N | Y | Y | N | | [Aggiungi colonne all'inizio o al centro della tabella](updates-add-columns-beginning-middle-of-table.md) | Archivia i tuoi dati in JSON e AVRO oppure in ORC e Parquet se vengono letti in base al nome. Non utilizzare CSV e TSV. | N | Y | Y | Y | N | N | Y | | [Aggiungi colonne alla fine di una tabella](updates-add-columns-end-of-table.md) | Archivia i tuoi dati in CSV o TSV, JSON, AVRO, ORC o Parquet. | Y | Y | Y | Y | Y | Y | Y | | [Rimuovi colonne](updates-removing-columns.md) | Archivia i tuoi dati in JSON e AVRO oppure in Parquet e ORC se vengono letti in base al nome. Non utilizzare CSV e TSV. | N | Y | Y | Y | N | N | Y | | [Riordina colonne](updates-reordering-columns.md) | Archivia i tuoi dati in AVRO, JSON oppure in ORC e Parquet se vengono letti in base al nome. | N | Y | Y | Y | N | N | Y | | [Modifica il tipo di dati di una colonna](updates-changing-column-type.md) | Archivia i dati in qualunque formato, ma testa la query in Athena per verificare che i tipi di dati siano compatibili. Per Parquet e ORC, la modifica di un tipo di dati funziona solo per tabelle partizionate. | Y | Y | Y | Y | Y | Y | Y | ## Comprendere l’accesso agli indici per Apache ORC e Apache Parquet PARQUET e ORC sono formati colonnari di storage dei dati che possono essere letti per indice o per nome. Archiviando i dati in uno di questi formati è possibile eseguire tutte le operazioni sugli schemi ed eseguire le query Athena senza errori di mancata corrispondenza di schemi. + Athena legge *ORC per indice per impostazione predefinita*, come definito in `SERDEPROPERTIES ( 'orc.column.index.access'='true')`. Per ulteriori informazioni, consulta [ORC: lettura in base all'indice](#orc-read-by-index). + Athena legge *Parquet per nome per impostazione predefinita*, come definito in `SERDEPROPERTIES ( 'parquet.column.index.access'='false')`. Per ulteriori informazioni, consulta [Parquet: lettura in base al nome](#parquet-read-by-name). Poiché si tratta di impostazioni predefinite, la specificazione di queste SerDe proprietà nelle `CREATE TABLE` query è facoltativa, in quanto vengono utilizzate implicitamente. Quando sono utilizzate, consentono di eseguire alcune operazioni di aggiornamento dello schema, impedendone altre. Per abilitare tali operazioni, esegui un'altra `CREATE TABLE` query e modifica le impostazioni. SerDe **Nota** Le SerDe proprietà *non* vengono propagate automaticamente a ciascuna partizione. `ALTER TABLE ADD PARTITION`Utilizzate le istruzioni per impostare le SerDe proprietà per ogni partizione. Per automatizzare il processo, scrivi uno script che esegue le istruzioni `ALTER TABLE ADD PARTITION`. Le seguenti sezioni descrivono in dettaglio questi casi. ### ORC: lettura in base all'indice Una tabella in *ORC viene letta in base all'indice* per impostazione predefinita. Questo è definito dalla seguente sintassi: ``` WITH SERDEPROPERTIES ( 'orc.column.index.access'='true') ``` La *lettura per indice* consente l'assegnazione di un nuovo nome alle colonne. Tuttavia, in tal caso non sarà più possibile rimuovere colonne o aggiungerle al centro della tabella. Per fare in modo che ORC venga letto per nome, il che ti consentirà di aggiungere colonne al centro della tabella o rimuovere colonne in ORC, imposta la SerDe proprietà su `false` nell'`orc.column.index.access`istruzione. `CREATE TABLE` In questa configurazione, perderai la possibilità di rinominare le colonne. **Nota** Nel motore di Athena versione 2, quando le tabelle ORC sono impostate per la lettura per nome, Athena richiede che tutti i nomi delle colonne nei file ORC siano minuscoli. Poiché Apache Spark non utilizza nomi di campo minuscoli quando genera file ORC, Athena potrebbe non essere in grado di leggere i dati così generati. La soluzione alternativa consiste nel rinominare le colonne in modo che siano in minuscolo, oppure nell'utilizzare la versione 3 del motore Athena. L'esempio seguente spiega come modificare la lettura ORC in modo che avvenga in base al nome: ``` 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: lettura in base al nome Una tabella in *Parquet viene letta in base al nome* per impostazione predefinita. Questo è definito dalla seguente sintassi: ``` WITH SERDEPROPERTIES ( 'parquet.column.index.access'='false') ``` La *lettura per nome* consente di aggiungere colonne al centro della tabella e di rimuovere colonne. Tuttavia, in tal caso si non sarà più possibile rinominare le colonne. Per fare in modo che Parquet venga letto per indice, che consentirà di rinominare le colonne, è necessario creare una tabella con la `parquet.column.index.access` SerDe proprietà impostata su. `true` # Effettuare aggiornamenti degli schemi Questo argomento descrive alcune delle modifiche che è possibile apportare allo schema nelle istruzioni `CREATE TABLE` senza alterare effettivamente i dati. Per aggiornare uno schema, in alcuni casi puoi utilizzare un comando `ALTER TABLE`, ma in altri casi non è possibile modificare effettivamente una tabella esistente. Crea invece una tabella con un nuovo nome che modifica lo schema utilizzato nell'istruzione originale `CREATE TABLE`. A seconda dell'evoluzione prevista degli schemi, per continuare a utilizzare le query Athena, è necessario scegliere un formato di dati compatibile. Considera un'applicazione che legge le informazioni sugli ordini da una tabella `orders` esistente in due formati: CSV e Parquet. L'esempio seguente crea una tabella in formato Parquet: ``` 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/'; ``` L'esempio seguente crea la stessa tabella in formato CSV: ``` 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/'; ``` I seguenti argomenti, mostrano come gli aggiornamenti di queste tabelle influenzano le query Athena. **Topics** + [ # Aggiungi colonne all'inizio o al centro della tabella ](updates-add-columns-beginning-middle-of-table.md) + [ # Aggiungi colonne alla fine di una tabella ](updates-add-columns-end-of-table.md) + [ # Rimuovi colonne ](updates-removing-columns.md) + [ # Rinominare le colonne ](updates-renaming-columns.md) + [ # Riordina colonne ](updates-reordering-columns.md) + [ # Modifica il tipo di dati di una colonna ](updates-changing-column-type.md) # Aggiungi colonne all'inizio o al centro della tabella L'aggiunta di colonne è una delle modifiche più frequenti di uno schema. Ad esempio, è possibile aggiungere una nuova colonna per arricchire la tabella con nuovi dati. In alternativa, è possibile aggiungere una nuova colonna se è cambiata la fonte di una colonna esistente e mantenere la versione precedente di questa colonna per regolare le applicazioni che dipendono da essa. Per aggiungere colonne all'inizio o al centro della tabella e continuare a eseguire query su tabelle esistenti, utilizzate AVRO, JSON e Parquet e ORC se la loro SerDe proprietà è impostata su «Leggi per nome». Per informazioni, consulta [Comprendere l’accesso agli indici per Apache ORC e Apache Parquet](handling-schema-updates-chapter.md#index-access). Non aggiungere colonne all'inizio o al centro della tabella in CSV e TSV, poiché questi formati dipendono dall'ordinamento. L'aggiunta di una colonna in questi casi porterebbe a errori di mancata corrispondenza tra schemi quando lo schema di partizioni viene modificato. L'esempio seguente crea una nuova tabella che aggiunge una colonna `o_comment` al centro di una tabella basata su dati JSON. ``` 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/'; ``` # Aggiungi colonne alla fine di una tabella Se si creano tabelle in uno dei formati supportati da Athena, ad esempio Parquet, ORC, Avro, JSON, CSV e TSV, è possibile utilizzare l'istruzione `ALTER TABLE ADD COLUMNS` per aggiungere colonne dopo le colonne esistenti ma prima delle colonne di partizione. Nell'esempio seguente viene aggiunta una colonna `comment` alla fine della tabella `orders_parquet` prima di qualsiasi colonna di partizione: ``` ALTER TABLE orders_parquet ADD COLUMNS (comment string) ``` **Nota** Per visualizzare una nuova colonna di tabella nell'editor di query Athena dopo l'esecuzione di `ALTER TABLE ADD COLUMNS`, aggiornare manualmente l'elenco di tabelle nell'editor e quindi espandere nuovamente la tabella. # Rimuovi colonne Potrebbe essere necessario rimuovere colonne dalle tabelle se queste non contengono più dati o per limitare l'accesso ai dati in esse contenuti. + È possibile rimuovere colonne da tabelle in formato JSON, Avro e Parquet e ORC se la lettura è per nome. Per informazioni, consulta [Comprendere l’accesso agli indici per Apache ORC e Apache Parquet](handling-schema-updates-chapter.md#index-access). + Sconsigliamo di rimuovere colonne delle tabelle in CSV e TSV se si desidera conservare le tabelle già create in Athena. La rimozione di una colonna altera lo schema e richiede di ricreare la tabella senza la colonna rimossa. In questo esempio, si rimuove una colonna ``totalprice`` da una tabella in Parquet e si esegue una query. In Athena, il formato Parquet è letto per nome per impostazione predefinita e questo è il motivo per cui omettiamo la configurazione SERDEPROPERTIES che specifica la lettura per nome. Tieni presente che la seguente query va a buon fine anche se si modifica lo schema: ``` 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/'; ``` # Rinominare le colonne È possibile rinominare le colonne nelle tabelle per correggere l'ortografia, rendere i nomi delle colonne più descrittivi o riutilizzare una colonna esistente per evitare il riordinamento delle colonne. È possibile rinominare le colonne se si archiviano i dati in CSV e TSV o in Parquet e ORC con configurazione per la lettura per indice. Per informazioni, consulta [Comprendere l’accesso agli indici per Apache ORC e Apache Parquet](handling-schema-updates-chapter.md#index-access). Athena legge i dati in CSV e TSV nell'ordine delle colonne nello schema e li restituisce nello stesso ordine. Non utilizza i nomi delle colonne per la mappatura dei dati a una colonna e questo è il motivo per cui è possibile rinominare le colonne in CSV o TSV senza interrompere le query Athena. Una strategia per rinominare le colonne consiste nel creare una nuova tabella basata sugli stessi dati sottostanti, ma utilizzando nuovi nomi di colonna. Il seguente esempio crea una nuova tabella `orders_parquet` chiamata `orders_parquet_column_renamed`. L'esempio modifica il nome ``o_totalprice`` della colonna in ``o_total_price`` e quindi esegue una query in Athena: ``` 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/'; ``` Nel caso della tabella Parquet, la query seguente viene eseguita, ma la colonna rinominata non mostra i dati poiché l'accesso alla stessa è avvenuto per nome (impostazione predefinita in Parquet) anziché per indice: ``` SELECT * FROM orders_parquet_column_renamed; ``` Di seguito un esempio di query con una tabella in CSV: ``` 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/'; ``` Nel caso della tabella CSV, la query seguente viene eseguita e i dati vengono visualizzati in tutte le colonne, compresa quella che è stata rinominata: ``` SELECT * FROM orders_csv_column_renamed; ``` # Riordina colonne È possibile riordinare le colonne solo per tabelle con dati in formati che leggono per nome, ad esempio JSON o Parquet, i quali leggono per nome per impostazione predefinita. Se necessario, è possibile fare in modo che anche ORC legga per nome. Per informazioni, consulta [Comprendere l’accesso agli indici per Apache ORC e Apache Parquet](handling-schema-updates-chapter.md#index-access). L'esempio seguente crea una nuova tabella con le colonne in un ordine diverso: ``` 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/'; ``` # Modifica il tipo di dati di una colonna Potresti voler utilizzare un tipo di colonna diverso quando il tipo esistente non può più contenere la quantità di informazioni richieste. Ad esempio, i valori di una colonna ID potrebbero superare la dimensione del tipo di dati `INT` e richiedere l'uso del tipo di dati `BIGINT`. ## Considerazioni Quando si prevede di utilizzare un tipo di dati diverso per una colonna, considerare i seguenti punti: + Nella maggior parte dei casi, non è possibile modificare direttamente il tipo di dati di una colonna. Al contrario, si ricrea la tabella Athena e si definisce la colonna con il nuovo tipo di dati. + Solo alcuni tipi di dati possono essere letti come altri tipi di dati. Consulta la tabella in questa sezione per i tipi di dati che possono essere trattati in tal modo. + Per i dati in Parquet e ORC, non puoi utilizzare un tipo di dati diverso per una colonna se la tabella non è partizionata. + Per le tabelle partizionate in Parquet e ORC, il tipo di colonna di una partizione può essere diverso dal tipo di colonna di un'altra partizione e, se possibile, Athena eseguirà `CAST` per il tipo desiderato. Per informazioni, consulta [Evitare errori di mancata corrispondenza tra schemi per tabelle con partizioni](updates-and-partitions.md#partitions-dealing-with-schema-mismatch-errors). + Per le tabelle create utilizzando l'[LazySimpleSerDe](lazy-simple-serde.md)unico, è possibile utilizzare l'`ALTER TABLE REPLACE COLUMNS`istruzione per sostituire le colonne esistenti con un tipo di dati diverso, ma tutte le colonne esistenti che si desidera conservare devono essere ridefinite nell'istruzione, altrimenti verranno eliminate. Per ulteriori informazioni, consulta [ALTER TABLE REPLACE COLUMNS](alter-table-replace-columns.md). + Solo per le tabelle Apache Iceberg, puoi utilizzare l'istruzione [ALTER TABLE CHANGE COLUMN](querying-iceberg-alter-table-change-column.md) per modificare il tipo di dati di una colonna. `ALTER TABLE REPLACE COLUMNS` non è supportato per le tabelle Iceberg. Per ulteriori informazioni, consulta [Evoluzione dello schema della tabella Iceberg](querying-iceberg-evolving-table-schema.md). **Importante** Consigliamo vivamente di testare e verificare le query prima di modificare il tipo di dati. Se Athena non è in grado di utilizzare il tipo di dati di destinazione, la query `CREATE TABLE` potrebbe avere esito negativo. ## Utilizzare tipi di dati compatibili Quando possibile, utilizza tipi di dati compatibili. La tabella seguente elenca i tipi di dati che possono essere trattati come altri tipi di dati: | Tipo di dati originale | Tipi di dati di destinazione disponibili | | --- | --- | | STRING | BYTE, TINYINT, SMALLINT, INT, BIGINT | | BYTE | TINYINT, SMALLINT, INT, BIGINT | | TINYINT | SMALLINT, INT, BIGINT | | SMALLINT | INT, BIGINT | | INT | BIGINT | | FLOAT | DOUBLE | L'esempio seguente mostra l'utilizzo dell'istruzione `CREATE TABLE` per la tabella `orders_json` originale per creare una nuova tabella denominata `orders_json_bigint`. La nuova tabella utilizza `BIGINT` anziché `INT` come tipo di dati per la colonna ``o_shippriority``. ``` 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'; ``` La seguente query viene eseguita correttamente, in modo analogo alla query `SELECT` originale, prima della modifica del tipo di dati: ``` Select * from orders_json LIMIT 10; ``` # Aggiornare tabelle con partizioni In Athena, una tabella e le relative partizioni devono utilizzare gli stessi formati di dati, tuttavia i loro schemi possono differire. Quando si crea una nuova partizione, questa in genere eredita lo schema della tabella. Nel corso del tempo, gli schemi possono iniziare a differire. I motivi includono: + Se lo schema della tua tabella cambia, gli schemi delle partizioni non vengono aggiornati per mantenere la sincronizzazione con lo schema della tabella. + Il AWS Glue Crawler consente di scoprire dati in partizioni con schemi diversi. Ciò significa che se si crea una tabella in Athena con AWS Glue, dopo che il crawler ha terminato l'elaborazione, gli schemi per la tabella e le relative partizioni potrebbero essere diversi. + Se aggiungi partizioni direttamente utilizzando un'API. AWS Athena elabora correttamente le tabelle con partizioni se soddisfano i seguenti vincoli. Se tali requisiti non vengono soddisfatti, Athena emette un errore HIVE\$1PARTITION\$1SCHEMA\$1MISMATCH. + Ciascuno schema di partizione è compatibile con lo schema della tabella. + Il formato di dati della tabella consente il tipo di aggiornamento che si desidera eseguire: aggiunta, eliminazione, riordinamento o modifica del tipo di dati di una colonna. Ad esempio, per i formati CSV e TSV è possibile rinominare colonne, aggiungere nuove colonne alla fine della tabella e modificare il tipo di dati di una colonna se i tipi sono compatibili, ma non è possibile rimuovere colonne. Per altri formati, è possibile aggiungere o rimuovere colonne oppure modificare il tipo di dati di una colonna in un altro tipo se i tipi sono compatibili. Per ulteriori informazioni, consulta il [Riepilogo: aggiornamenti e formati di dati in Athena](handling-schema-updates-chapter.md#summary-of-updates). ## Evitare errori di mancata corrispondenza tra schemi per tabelle con partizioni All'inizio dell'esecuzione di una query, Athena verifica lo schema della tabella controllando che ogni tipo di dati colonna sia compatibile tra la tabella e la partizione. + Per i tipi di storage dei dati Parquet e ORC, Athena si avvale dei nomi delle colonne e li utilizza per la verifica del proprio schema basato sul nome di colonna. Ciò consente di eliminare gli errori `HIVE_PARTITION_SCHEMA_MISMATCH` per le tabelle con partizioni in Parquet e ORC. (Questo vale per ORC se la SerDe proprietà è impostata per accedere all'indice per nome:. `orc.column.index.access=FALSE` Per impostazione predefinita, Parquet legge l'indice per nome). + Per CSV, JSON e Avro, Athena usa una verifica dello schema basata sull'indice. Questo significa che, se si verifica un errore di mancata corrispondenza di schema, è necessario eliminare la partizione che provoca tale differenza e ricrearla, in modo che Athena possa eseguire le query senza errori. Athena confronta lo schema della tabella con gli schemi della partizione. Se crei una tabella in CSV, JSON e AVRO in Athena con AWS Glue Crawler, dopo che il Crawler ha terminato l'elaborazione, gli schemi per la tabella e le sue partizioni potrebbero essere diversi. Se non c'è corrispondenza tra lo schema della tabella e gli schemi delle partizioni, le query falliranno in Athena a causa dell'errore di verifica dello schema simile a questo: 'crawler\$1test.click\$1avro' è dichiarato come tipo "string", ma la partizione "partition\$10 = 2017-01-17" ha dichiarato la colonna "col68" come tipo "doppio"'. Una tipica soluzione per questi errori è eliminare la partizione che provoca l'errore e ricrearla. Per ulteriori informazioni, consultare [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md) e [ALTER TABLE ADD PARTITION](alter-table-add-partition.md).