# スキーマの更新を処理する
<a name="handling-schema-updates-chapter"></a>

このセクションでは、さまざまなデータ形式に対するスキーマ更新の処理に関するガイダンスを提供します。Athena はスキーマオンリード (schema-on-read) のクエリエンジンです。これは、Athena でテーブルを作成する場合、Athena がデータの読み込み時にスキーマを適用することを意味します。基盤となるデータに変更または書き直しが行われることはありません。

テーブルスキーマの変更が予想される場合は、ニーズに適したデータ形式で作成することを検討します。目的は、進化するスキーマに対して既存の Athena クエリを再利用し、パーティションがあるテーブルをクエリするときのスキーマの不一致エラーを回避することです。

これらの目的を達成するには、次のトピックの表に基づいてテーブルのデータ形式を選択してください。

**Topics**
+ [サポートされているスキーマ更新オペレーション (データ形式別)](#summary-of-updates)
+ [Apache ORC と Apache Parquet のインデックスアクセスを理解する](#index-access)
+ [スキーマを更新する](make-schema-updates.md)
+ [パーティションを使用してテーブルを更新する](updates-and-partitions.md)

## サポートされているスキーマ更新オペレーション (データ形式別)
<a name="summary-of-updates"></a>

以下の表は、データストレージ形式と、それらがサポートするスキーマ操作をまとめたものです。この表を使用して、スキーマがいずれは変更されるとしても、Athena クエリを引き続き使用できるようにする形式を選択するために役立ててください。

この表では、Parquet と ORC の列形式が、列へのデフォルトのアクセス方法が異なるものであることに注意してください。デフォルトで、Parquet は名前で列にアクセスし、ORC はインデックス (序数値) で列にアクセスします。このため、Athena はテーブルの作成時に定義される SerDe プロパティを提供して、列へのデフォルトのアクセス方法を切り替えます。これによって、スキーマの進化における柔軟性が大きく向上します。

Parquet では、`parquet.column.index.access` プロパティを `true` に設定することができます。これは、列の序数を使用するように列へのアクセス方法を設定します。このプロパティを `false` に設定すると、列へのアクセス方法が列名を使用するように変更されます。同様に、ORC では `orc.column.index.access` プロパティを使用して列へのアクセス方法を制御します。詳細については、「[Apache ORC と Apache Parquet のインデックスアクセスを理解する](#index-access)」を参照してください。

CSV と TSV を使用すると、列の並べ替えやテーブルの先頭に列を追加する以外のすべてのスキーマ操作を実行できます。例えば、スキーマの変更で列の名前を変更するだけで、列の名前を削除する必要がない場合は、CSV または TSV でテーブルを作成することができます。列を削除する必要がある場合は、CSV または TSV を使用せず、その他のサポートされている形式のいずれか (できれば、Parquet または ORC などの列形式) を使用します。


**Athena におけるスキーマ更新とデータ形式**  

| 予想されるスキーマ更新のタイプ | 概要 | CSV (ヘッダー有りまたはヘッダーなし) および TSV | JSON | AVRO | PARQUET: 名前で読み込む (デフォルト) | PARQUET: インデックスで読み込む | ORC: インデックスで読み込む (デフォルト) | ORC: 名前で読み込む | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | 
|  [列の名前変更](updates-renaming-columns.md) | データを CSV および TSV に保存するか、ORC および Parquet でインデックスに読み込んだ場合に保存します。 | Y | N | N | N  | Y | Y | N | 
|  [テーブルの先頭または中間に列を追加する](updates-add-columns-beginning-middle-of-table.md) | データを JSON、AVRO に保存するか、Parquet および ORC で名前に読み込んだ場合に保存します。CSV や TSV を使用しないでください。 | N | Y | Y | Y | N | N | Y | 
|  [テーブルの末尾に列を追加する](updates-add-columns-end-of-table.md) | CSV または TSV、JSON、AVRO、ORC、または Parquet 形式でデータを保存します。 | Y | Y | Y | Y | Y | Y | Y | 
| [列の削除](updates-removing-columns.md) |  データを JSON、AVRO に保存するか、Parquet および ORC で名前に読み込んだ場合に保存します。CSV や TSV を使用しないでください。 | N | Y | Y | Y | N | N | Y | 
| [列の順序変更](updates-reordering-columns.md) | データを AVRO、JSON に保存するか、ORC および Parquet で名前に読み込んだ場合に保存します。 | N | Y | Y | Y | N | N | Y | 
| [列のデータ型の変更](updates-changing-column-type.md) | 任意の形式でデータを保存します。ただし、Athena でクエリをテストして、データ型に互換性があることを確認するようにしてください。Parquet および ORC のデータ型を変更した場合は、パーティションされたテーブルでのみ機能します。 | Y | Y | Y | Y | Y | Y | はい | 

## Apache ORC と Apache Parquet のインデックスアクセスを理解する
<a name="index-access"></a>

PARQUET および ORC は、インデックス引または名前で読み込み可能な列データストレージ形式です。これらの形式のいずれかでデータを保存すると、スキーマですべてのオペレーションを実行し、スキーマの不一致エラーを生じることなく Athena でクエリを実行できるようになります。
+ Athena は、`SERDEPROPERTIES ( 'orc.column.index.access'='true')` で定義されているように、*デフォルトでインデックスによる ORC* の読み込みを行います。詳細については、「[ORC: インデックスで読み込む](#orc-read-by-index)」を参照してください。
+ Athena は、`SERDEPROPERTIES ( 'parquet.column.index.access'='false')` で定義されているとおり、*デフォルトで名前による Parquet* の読み込みを行います。詳細については、「[Parquet: 名前で読み込む](#parquet-read-by-name)」を参照してください。

これらはデフォルトであるため、これらの SerDe プロパティを `CREATE TABLE` クエリで使用するのはオプションで、暗黙的に使用されます。これらを使用すると、、他のオペレーションを防ぎながら、スキーマの更新オペレーションを実行することができます。これらのオペレーションを有効にするには、別の `CREATE TABLE` クエリを実行し、SerDe の設定を変更します。

**注記**  
SerDe のプロパティは、各パーティションに自動的に伝播*されません*。各パーティションに SerDe プロパティを設定するには、`ALTER TABLE ADD PARTITION` ステートメントを使用します。このプロセスを自動化するには、`ALTER TABLE ADD PARTITION` ステートメントを実行するスクリプトを記述します。

以下のセクションで、これらのケースについて詳しく説明します。

### ORC: インデックスで読み込む
<a name="orc-read-by-index"></a>

ORC 内のテーブルは、*デフォルトでインデックスで読み取られます*。これは、次の構文で定義されます。

```
WITH SERDEPROPERTIES ( 
  'orc.column.index.access'='true')
```

*インデックスで読み込むと*、列の名前を変更できます。ただし、列の削除やテーブルの中間での追加ができなくなります。

ORC を名前で読み込み、テーブルの中間に列を追加したり、ORC の列を削除したりするには、`orc.column.index.access` ステートメントで、SerDe プロパティ `false` を `CREATE TABLE` に設定します。この設定では、列の名前を変更する機能が失われます。

**注記**  
Athena エンジンバージョン 2 では、ORC テーブルが名前で読み込むように設定されている場合、Athena では ORC ファイル内のすべての列の名前を小文字にする必要があります。Apache Spark は ORC ファイルを生成するときにフィールド名を小文字にしないため、生成されたデータを Athena で読み込むことができない可能性があります。この問題を回避するためには、列の名前を小文字に変更するか、Athena エンジンバージョン 3 を使用します。

次の例は、ORC を変更して名前で読み込む方法を示しています。

```
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: 名前で読み込む
<a name="parquet-read-by-name"></a>

*Parquet のテーブルはデフォルトで名前で読み取られます*。これは、次の構文で定義されます。

```
WITH SERDEPROPERTIES ( 
  'parquet.column.index.access'='false')
```

*名前で読み込む*と、テーブルの中間に列を追加したり、列を削除したりできます。ただし、列の名前を変更することができなくなります。

Parquet にインデックスで読み取らせて列の名前を変更できるようにするには、 `parquet.column.index.access` SerDe プロパティを `true` に設定してテーブルを作成する必要があります。

# スキーマを更新する
<a name="make-schema-updates"></a>

このトピックでは、実際にデータを変更せずに `CREATE TABLE` ステートメントのスキーマに加えられるいくつかの変更について説明します。スキーマを更新するには、`ALTER TABLE` コマンドを使用できる場合もあれば、既存のテーブルを実際に変更しない場合もあります。代わりに、元の `CREATE TABLE` テートメントで使用したスキーマを変更する新しい名前のテーブルを作成します。

期待されるスキーマの進化方法に応じて、Athena クエリの使用を継続するために互換性のあるデータ形式を選択します。

CSV および Parquet の 2 つの形式で存在する `orders` テーブルからの注文情報を読み取るアプリケーションを考えます。

以下の例では、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/';
```

以下の例では、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/';
```

次のトピックでは、これらのテーブルの更新が Athena クエリにどのように影響するかを示します。

**Topics**
+ [テーブルの先頭または中間に列を追加する](updates-add-columns-beginning-middle-of-table.md)
+ [テーブルの末尾に列を追加する](updates-add-columns-end-of-table.md)
+ [列の削除](updates-removing-columns.md)
+ [列の名前変更](updates-renaming-columns.md)
+ [列の順序変更](updates-reordering-columns.md)
+ [列のデータ型を変更する](updates-changing-column-type.md)

# テーブルの先頭または中間に列を追加する
<a name="updates-add-columns-beginning-middle-of-table"></a>

列の追加は最も頻繁なスキーマの変更の 1 つです。たとえば、新しいデータでテーブルをエンリッチ化するために、新しい列を追加することがあります。または、既存の列のソースが変更された場合に新しい列を追加し、この列の以前のバージョンを保持してそれに依存するアプリケーションを調整することもあります。

テーブルの先頭または中間に列を追加し、既存のテーブルに対してクエリを実行するには、SerDe プロパティが名前で読み取るように設定されている場合は、AVRO、JSON、および Parquet と ORC を使用します。詳細については、「[Apache ORC と Apache Parquet のインデックスアクセスを理解する](handling-schema-updates-chapter.md#index-access)」を参照してください。

これらの形式は順序に依存するため、CSV および TSV のテーブルの先頭または中間に列を追加しないでください。このような場合に列を追加すると、パーティションのスキーマが変更されたときにスキーマの不一致エラーが発生します。

 次の例では、JSON データに基づいてテーブルの中央に `o_comment` 列を追加する新しいテーブルを作成します。

```
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/';
```

# テーブルの末尾に列を追加する
<a name="updates-add-columns-end-of-table"></a>

Parquet、ORC、Avro、JSON、CSV、および TSV などの Athena がサポートする形式のいずれかでテーブルを作成する場合は、`ALTER TABLE ADD COLUMNS` ステートメントを使用して、既存の列の後、かつパーティション列の前の位置に列を追加できます。

次の例では、パーティション `comment` 列の前の `orders_parquet` テーブルの末尾に列を追加します。

```
ALTER TABLE orders_parquet ADD COLUMNS (comment string)
```

**注記**  
`ALTER TABLE ADD COLUMNS` を実行した後で Athena クエリエディタに新しいテーブル列を表示するには、エディタのテーブルリストを手動で更新してから、テーブルをもう一度展開します。

# 列の削除
<a name="updates-removing-columns"></a>

列に含まれるデータがなくなった場合、あるいは列に含まれているデータへのアクセスを制限する場合に、これらの列を削除する必要があることがあります。
+ 名前で読み込まれている場合、JSON、Avro、および Parquet、ORC でテーブルから列を削除することができます。詳細については、「[Apache ORC と Apache Parquet のインデックスアクセスを理解する](handling-schema-updates-chapter.md#index-access)」を参照してください。
+ 既に Athena で作成したテーブルを保持する場合は、CSV および TSV のテーブルから列を削除することは推奨されません。列を削除するとスキーマが壊れ、削除された列がない状態でテーブルを再作成しなければならなくなります。

この例では、Parquet のテーブルから ``totalprice`` 列を削除して、クエリを実行します。Athena では、デフォルトで Parquet の読み取りが名前で行われます。名前での読み取りを指定する SERDEPROPERTIES 設定が省略されているのはこのためです。スキーマを変更しても、次のクエリは成功することに注意してください。

```
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/';
```

# 列の名前変更
<a name="updates-renaming-columns"></a>

綴りを修正する、列名をより分かりやすくする、または列の順序変更を回避するために、テーブルで列の名前変更が必要となる場合があります。

データを CSV および TSV に保存する場合は列の名前を変更できます。また、インデックスで読み取るように設定されている場合は、Parquet および ORC に保存できます。詳細については、「[Apache ORC と Apache Parquet のインデックスアクセスを理解する](handling-schema-updates-chapter.md#index-access)」を参照してください。

Athena は CSV と TSV のデータをスキーマの列順に読み取り、それらを同じ順序で返します。Athena は、列にデータをマップするために列名を使用しません。Athena クエリを破損することなく CSV または TSV で列名を変更できるのはこのためです。

列名を変更する戦略の 1 つは、同じ基盤データに基づく新しいテーブルを、新しい列名を使用して作成することです。以下の例は、`orders_parquet_column_renamed` という名前の新しい `orders_parquet` テーブルを作成します。この例は、列 ``o_totalprice`` の名前を ``o_total_price`` に変更してから、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/';
```

Parquet テーブルの場合、次のクエリは実行されますが、列がインデックスではなく名前でアクセスされているため (Parquet のデフォルト)、名前が変更された列にはデータが表示されません。

```
SELECT * 
FROM orders_parquet_column_renamed;
```

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/';
```

CSV テーブルの場合、次のクエリを実行すると、名前が変更された列を含むすべての列でデータが表示されます。

```
SELECT * 
FROM orders_csv_column_renamed;
```

# 列の順序変更
<a name="updates-reordering-columns"></a>

デフォルトで名前で読み取る JSON や Parquet など、名前で読み取る形式のデータを含むテーブルの列の順序を変更できます。必要に応じて、ORC を名前で読み取ることもできます。詳細については、「[Apache ORC と Apache Parquet のインデックスアクセスを理解する](handling-schema-updates-chapter.md#index-access)」を参照してください。

次の例では、列の順序が違う新しいテーブルを作成します。

```
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/';
```

# 列のデータ型を変更する
<a name="updates-changing-column-type"></a>

既存のタイプでは必要な量の情報を保持できなくなった場合は、別の列タイプを使用することをお勧めします。例えば、ID 列の値が `INT` データ型のサイズを超えているため、その `BIGINT` データ型を使用する必要があります。

## 考慮事項
<a name="updates-changing-column-type-considerations"></a>

列に別のデータ型を使用するときは、以下の点を考慮してください。
+ ほとんどの場合、列のデータ型を直接変更することはできません。代わりに、Athena テーブルを再作成し、新しいデータ型で列を定義します。
+ 一部のデータ型のみを他のデータ型として読み取ることができます。扱えるデータ型については、このセクションの表を参照してください。
+ Parquet および ORC のデータでは、テーブルがパーティション分割されていない場合、列に異なるデータ型を使用することはできません。
+ Parquet および ORC のパーティション分割されたテーブルでは、パーティションの列タイプが別のパーティションの列タイプと異なる場合があり、可能な場合は、Athena が望ましいタイプに `CAST` します。詳細については、「[パーティションがあるテーブルについて、スキーマ不一致エラーを回避する](updates-and-partitions.md#partitions-dealing-with-schema-mismatch-errors)」を参照してください。
+ [LazySimpleSerDE](lazy-simple-serde.md) のみを使用して作成されたテーブルでは、`ALTER TABLE REPLACE COLUMNS` ステートメントを使用して既存の列を別のデータ型に置き換えることができますが、保持したい既存の列もすべてステートメントに再定義する必要があります。これを行わないと、削除されます。詳細については、「[ALTER TABLE REPLACE COLUMNS](alter-table-replace-columns.md)」を参照してください。
+ Apache Iceberg テーブルの場合のみ、[ALTER TABLE CHANGE COLUMN](querying-iceberg-alter-table-change-column.md) ステートメントを使用して列のデータ型を変更できます。 `ALTER TABLE REPLACE COLUMNS` は Iceberg テーブルではサポートされていません。詳細については、「[Iceberg テーブルスキーマを進化させる](querying-iceberg-evolving-table-schema.md)」を参照してください。

**重要**  
データ型の変換を実行する前に、クエリをテストして検証することを強くお勧めします。Athena がターゲットのデータ型を使用できない場合、`CREATE TABLE` クエリは失敗する可能性があります。

## 互換性のあるデータ型を使用する
<a name="updates-changing-column-type-use-compatible-data-types"></a>

可能な場合は常に、互換性のあるデータ型を使用します。次の表は、他のデータ型として扱うことができるデータ型の一覧です。


| 元のデータ型 | 使用可能なターゲットデータ型 | 
| --- | --- | 
| STRING | BYTE, TINYINT, SMALLINT, INT, BIGINT | 
| BYTE | TINYINT, SMALLINT, INT, BIGINT | 
| TINYINT | SMALLINT, INT, BIGINT | 
| SMALLINT | INT, BIGINT | 
| INT | BIGINT | 
| FLOAT | DOUBLE | 

次の例では、元の `orders_json` テーブルの `CREATE TABLE` ステートメントを使用して、`orders_json_bigint` という新しいテーブルを作成します。新しいテーブルでは、``o_shippriority`` 列のデータ型として `INT` の代わりに `BIGINT` が使用されます。

```
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';
```

次のクエリは、元の `SELECT` クエリと同様に、データ型が変更される前に正常に実行されます。

```
Select * from orders_json 
LIMIT 10;
```

# パーティションを使用してテーブルを更新する
<a name="updates-and-partitions"></a>

Athena では、テーブルとそのパーティションが同じデータ形式を使用する必要がありますが、スキーマは異なる場合があります。新しいパーティションを作成するとき、このパーティションは通常テーブルのスキーマを継承します。時間の経過とともに、このスキーマが変わり始める場合があります。その理由には次のようなものがあります。
+ テーブルのスキーマの場合、パーティションのスキーマはテーブルのスキーマと同期するために更新されません。
+ AWS Glue クローラでは、異なるスキーマのパーティションからデータを検出することができます。これは、AWS Glue を使って Athena でテーブルを作成する場合、クローラの処理が終了した後で、テーブルのスキーマとそのパーティションのスキーマが異なる場合があることを意味します。
+ AWS API を使用して、直接パーティションを追加した場合。

Athena は、テーブルが以下の制約を満たす場合に、パーティションがあるテーブルを正常に処理します。これらの制約が満たされない場合、Athena は「HIVE\$1PARTITION\$1SCHEMA\$1MISMATCH」エラーを発行します。
+ 各パーティションのスキーマがテーブルのスキーマと互換性があること。
+ テーブルのデータ形式が実行する更新のタイプを許可すること (追加、削除、列の順序変更あるいは列のデータ型の変更)。

  たとえば、CSV および TSV 形式では列の名前変更、新しい列のテーブル末尾への追加および型に互換性がある場合の列のデータ型の変更のみを行うことができ、列を削除することはできません。その他の形式では、列の追加あるいは削除、型に互換性がある場合の列のデータ型の別への変更ができます。詳細については、「[概要: Athena における更新とデータ形式](handling-schema-updates-chapter.md#summary-of-updates)」を参照してください。

## パーティションがあるテーブルについて、スキーマ不一致エラーを回避する
<a name="partitions-dealing-with-schema-mismatch-errors"></a>

Athena は、クエリの実行開始時に、各列のデータ型にテーブルとパーティション間での互換性があることをチェックすることによってテーブルのスキーマを検証します。
+ Parquet および ORC のデータストレージタイプの場合、Athena は列名に依存し、列名ベースのスキーマ検証のためにそれらを使用します。これにより、Parquet および ORC のパーティションがあるテーブルの `HIVE_PARTITION_SCHEMA_MISMATCH` エラーが解消されます。(ORC では、名前でインデックスにアクセスするように SerDe プロパティが設定されている (`orc.column.index.access=FALSE`) 場合にこれが機能します。Parquet はデフォルトで、名前によるインデックスの読み取りを行います)。
+ CSV、JSON、および Avro の場合、Athena はインデックスベースのスキーマ検証を使用します。これは、スキーマの不一致エラーが発生した場合、スキーマの不一致の原因となっているパーティションをドロップして作成し直し、Athena で失敗なくクエリを実行できるようにする必要があることを意味します。

 Athena は、テーブルのスキーマとパーティションのスキーマを比較します。Athena の AWS Glue クローラで CSV、JSON、および AVRO でテーブルを作成した場合、クローラの処理が終了すると、テーブルのスキーマとそのパーティションは異なる場合があります。テーブルのスキーマとパーティションのスキーマ間に不一致がある場合、Athena でのクエリは、「'crawler\$1test.click\$1avro' is declared as type 'string', but partition 'partition\$10=2017-01-17' declared column 'col68' as type 'double'."」に似たスキーマ検証エラーが原因で失敗します。

このようなエラーを回避する一般的な対処法は、エラーの原因となるパーティションを削除して、再作成することです。詳細については、「[ALTER TABLE DROP PARTITION](alter-table-drop-partition.md)」および「[ALTER TABLE ADD PARTITION](alter-table-add-partition.md)」を参照してください。